Опять вернусь к теме KPI. Поскольку "Карфаген должен быть разрушен" ключевые показатели эффективности, в принципе, не должны применяться к задачам, где присутствует хоть какой-то элемент творчества. В особенности, к задачам разработки программного обеспечения. В особенности в случае, когда компания разрабатывает собственные инновационные продукты и обеспечивает свое существование за счет их продажи и/или эксплуатации.
Ниже я затрону две проблемы, связанные с введением KPI в софтверных компаниях. Но текста будет много, поэтому пост будет разбит на несколько частей, каждая из которых будет публиковаться по мере готовности. Сегодня читатели увидят первую часть, посвященную подмене понятий в определении ключевых показателей эффективности.
Итак, проблема первая: что же сейчас выдают за KPI?
Под KPI уже понимают не эффективность сотрудника, а, грубо говоря, степень соответствия сотрудника занимаемой должности. На эту тему я уже писал год назад и за прошедшее время еще раз убедился в том, что эта проблема актуальна и подмена понятий действительно существует.
Суть проблемы в том, что KPI (т.е. ключевые показатели эффективности или производительности) должны показывать эффективность сотрудника по отношению к каким-либо установленным в организации нормативам или к другим сотрудникам. Например, если Петя и Вася клеят коробки для спичек и за 8 часов рабочей смены Петя склеивает 500 коробок, а Вася всего 400, то производительность Пети объективно выше производительности Васи. Если мы добавим сюда еще процент брака, производимого Петей и Васей, их зарплаты (а так же больничные, отгулы и пр.), то можно будет более-менее объективно оценить эффективность работы каждого из них.
Для того, чтобы KPI можно было рассчитать и добиться правдоподобной степени объективности и правдивости, требуется, как минимум, две вещи. Во-первых, успешное достижение рабочих целей. Если Петя и Вася не могу клеить коробки для спичек, то смысла в расчете KPI нет. Во-вторых, в наличии должна быть повторяющаяся рутинная операция, одинаковая и для Пети, и для Васи. И это самое важное: именно замеры параметров выполнения этой однотипной, повторяющейся снова и снова операции, дают данные для расчета KPI.
Насколько я могу судить, разработка ПО пока еще не достигла той степени зрелости, когда программисты/тестировщики/техписатели/внедренцы/техподдержка снова и снова выполняют одни и те же рутинные операции в одних и тех же условиях. Может, на мой дилетантский взгляд, бюджетное сайтостроительство на PHP/RoR/Django уже где-то рядом с массовым производством, но, подозреваю, что там своих нюансов выше крыши.
Соответственно, если рассматривать Петю и Васю, которые не склеивают коробки для спичек, а разрабатывают софт для обработки финансовых транзакций, то откуда брать параметры для оценки их эффективности? В особенности, если Петя занимается оптимизацией способа хранения больших потоков подлежащей долговременному хранению исторической информации, а Вася -- пишет софт для банкоматной сети. Как сравнивать Петю и Васю между собой?
Думаю, что многие управленцы, вышедшие из разработки ПО, согласятся с тем, что хороших, объективных, формализованных критериев здесь не будет. Более того, если данные критерии станут известны оцениваемым разработчикам (а рано или поздно станут), то неизбежно начнется подгонка показателей работы под удовлетворение критериев (закон Гукхарда).
Итак, если нет нормальных критериев для оценки эффективности повседневной, обыденной, рутинной деятельности разработчиков ПО, то может есть хоть что-то, что можно было бы хоть как-то привязать к "эффективности"?
По мнению эффективных менеджеров есть. Это -- сам факт выполнения сотрудником поставленной перед ним задачи. Например, если стоят перед Петей задачи по журналированию операций списания средств, пополнения и просмотра баланса по банковской карточке, то почему бы не объявить выполнение этих задач его KPI? Т.е. сделал за отведенное время все три задачи, значит его KPI -- 100%. А если сделал только одну -- значит всего 33%. Вот, казалось бы, и решение, которое дает какую-то объективную цифирь.
Да только все это фигня. По меньшей мере по двум причинам.
Во-первых, с точки зрения здравого смысла, критерии эффективности должны высчитываться на многократно повторяемых операциях. Но если Петя впервые реализовывал журналирование операций просмотра баланса и в течении следующих 3-х лет никто в компании к этой задаче возвращаться не будет, то каким боком здесь вообще эффективность? Если задача сделана, значит с эффективностью все нормально. А вот если не сделана, тогда переходим к следующему пункту.
Во-вторых, разработка ПО -- это недетерминированный процесс. Рецептов, гарантирующих качественное решение задачи в точный срок и в рамках бюджета, до сих пор, насколько я знаю, не найдено. Слишком много здесь неопределенностей, зависимостей, случайностей и пр. неконтролируемых факторов. Может Петя и рад был бы сделать вовремя журналирование, но технический отдел не смог оперативно собрать тестовый стенд с нужным железом, объемами памяти, с соответствующим ПО. Поэтому, когда пришло время проверять работоспособность на больших объемах данных, то узкие места обнаружились слишком поздно. Или же Петя потратил слишком много времени на сбор информации от партнеров, которые должны были предоставить актуальное описание протоколов своей АБС и вовремя дать тестовый доступ к АБС, но не сделали этого и пришлось задействовать серьезный административный ресурс и ждать результатов разборок "в верхах". Или же Петя был отвлечен на устранение жесткого факапа на другом проекте, где он раньше работал и где срочно потребовалась его экспертиза. Или же внезапно заболел тестировщик, который должен был заниматься интеграционным тестированием написанных Петей модулей и на момент расчета KPI не известно, работают ли Петины модули или же в них баг на баге сидит и багом погоняет...
В общем, когда достижение производственных целей выдают за формализованный KPI, то ценность KPI как объективного показателя, на мой взгляд, падает до нуля. Ведь если человек не справляется с поставленными перед ним задачами, то зачем он вообще нужен? Здесь речь должна идти не об его эффективности, а о соответствии занимаемой должности. А если невыполнение целей обусловлено внешними факторами, а сотрудник вкалывал в поте лица и всеми доступными и недоступными способами пытался вытащить проект, но это оказалось невозможно в принципе, то как его оценивать? Был ли он эффективен? Или не был? И о какой объективности KPI вообще может идти речь, если оцениваются уже не объективные, формальные показатели (т.е. факты достижения целей), а субъективные вещи, вроде прилежания, старания и усилий сотрудника по их достижению?
Таким образом, современная трактовка KPI по отношению к разработке ПО -- это фигня, и это не есть правильно. И тем более не есть хорошо. Но какой же выход из сложившейся ситуации?
Если речь идет о больших организациях, насчитывающих тысячи программистов, да еще и живущих за счет продажи ресурсов, то не знаю. Проблемы индейцев шерифа не волнуют ;)
А вот в небольших продуктовых софтверных компаниях нужно забыть про KPI и отталкиваться от вполне простых показателей: сроков и качества. Если компания вовремя выводит новые версии продукта на рынок и обеспечивает своим продуктам должное качество, то нужно ли компании заниматься внедрением у себя KPI? Может гораздо лучше сконцентрироваться на том, чтобы понять, как компании удается выпускать софт вовремя? Наверняка дело в людях, в передаче знаний между ними, в распределении ответственности, в эффективности коммуникаций. Следует выделить ключевых сотрудников, постараться предоставить им максимально комфортные и интересные условия работы. Нужно осознать, что помогает им справляться с работой и постараться выяснить, а затем и устранить то, что мешает. Нужно предположить, что будет с вашими самыми ценными людьми через какое-то время. Понять, что вы будете им предлагать, кем вы будете их заменять, кого будете давать им в помощь... В общем, обычный набор банальностей.
Если же ваш софтверный бизнес из-за проблем с производством ПО под угрозой, если вы опаздываете с выходом новых версий, если их выпуск обходится вам слишком дорого, если качество вашего софта ниже плинтуса, то введение KPI, скорее всего, находится где-то самом конце списка возможных мероприятий по оздоровлению вашего производства. Если в производстве софта что-то идет не так, то, вероятнее всего, дело в людях. Либо кто-то находится не на своем месте. Либо кто-то просто не хочет работать. Либо же кто-то просто не умеет работать. Но, главное, у вас нет тех людей, которые хотели бы и могли бы разобраться с проблемами.
Ключевой момент здесь: обязательное сочетание "хотели бы" и "могли бы". Очень плохо, когда есть люди, искренне желающие исправить ситуацию и понимающие, что для этого нужно, более того, готовые взять на себя ответственность за это, но не имеющие полномочий для решительных действий. Не менее плохо, когда те, кто располагает нужными полномочиями, не имеют желания или способностей к поиску и устранению проблем организации. Еще хуже, когда облеченный соответствующими полномочиями, неправильно диагностирует проблему и/или выбирает/навязывает неправильное лечение. В любом случае, все опять же сводится к кадровым вопросам, а не к методикам расчета KPI...
Блин, не могу отделаться от ощущения, что снова и снова повторяю простые и очевидные, буквально прописные истины. Да только воз и ныне... Поэтому продолжение следует.
Комментариев нет:
Отправить комментарий