Считаю, что KPI для IT направления не подходит. Если его применять, то можешь потерять хороших сотрудников и принести убытки своей компании.
Рассмотрим несколько примеров:
1.Есть команда разработчиков со своим #стартапом и инвестор, который дает ресурсы для его реализации. Инвестор хочет как можно быстрей получить прибыль от своих вложения и назначает разработчикам какие-то KPI. Например, KPI затрат и KPI результата, чтобы следить какой получен результат за некий промежуток времени и какие были потрачены ресурсы. Обратите на важную деталь, что инвестор не всегда знает все детали и тонкости разработки продукта, он решает задачи совсем на другом уровне - предположим, как этот продукт продвигать.
В итоге что получается. Инвестор назначает жесткие сроки и указывает какой должен быть за этот срок результат. Любой стартап - это продукт, для реализации которого большая часть времени уходит на изучение, точный срок никто не скажет, но #инвестор требует. Пройдет срок, девелоперы на нервах торопились, не успели и предоставят большой технический отчет, чтобы оправдать вложения инвестора. Инвестор ничего в этом отчете толком не поймет, скажет, что вы не справились. Результат - стороны разрывают между собой отношения и терпят убытки (денежные и временные и др.).
P.S. Инвестору - не надо ставить жестких сроков и какой конкретно нужно получить результат. Девелоперу - не надо соглашаться и думать только о #деньгах, которые планирует дать вам инвестор, нужно думать и о последствиях. Считаю, что нужно работу разбивать на определенные итерации по разработке #продукта, которые будут устраивать обе Стороны. При этом Заказчик знает над чем трудятся исполнители, а девелоперы - не бегут сломя голову, чтобы успеть в срок, а решают поставленную нетривиальную задачу. KPI - НЕ ПОДХОДИТ.
2.Рассмотрим другой пример. Руководитель назначает #KPI по написанию кода программистам. Например, чем больше код, тем лучше и специалист получит бонус. В итоге, разработчик тебе такие коды предоставит, которые будут занимать не одну строчку, чтобы получить бонус, хотя можно было этого избежать. KPI - НЕ ПОДХОДИТ.
3.Пример тестирования приложения. Руководитель назначает KPI - чем меньше будет багов, тем лучше и получает бонус как тестировщик, так и разработчик приложения. Тестировщики оперативно договорятся с программистами о том, сколько багов писать, а сколько - нет, чтобы это было не в ущерб обеим сторонам. KPI - НЕ ПОДХОДИТ.
В сфере IT больше подойдет термин “предметы оценки” и “предметы контроля”, как писали в одной из умных статей.
Это может быть:
1.Промежуточные результаты, внутри итераций.
2.Достижение и поддержание качества сервиса.
3.Скорость работы приложений.
4.На сколько оптимизировано приложение.
5.Насколько продукт соответствует прототипу и приложению
6.Количество эффективных часов, потраченных на определенную итерацию.
Завершу статью словами из интернета, которые считаю нужно знать каждому руководителю, тем более в IT направлении.
Разработчик состоит из четырех компонентов: тело, сердце, разум и душа.
1.Телу необходимы деньги и безопасность.
2.Сердцу - любовь и признание.
3.Разуму - развитие и самосовершенствование.
4.Душе - самореализация.”
IT-специалисту не только важны деньги, но и атмосфера, отношение и понимание. Стараюсь создавать комфортные условия для нашей команды и всем советую. Мы креативные люди - народ творческий. Где есть творчество - там неуместен контроль. Находите компромиссы.
Еще одно, стараюсь использовать термины “Мы” и “Команда”, а не “Я” и “Сотрудники”. Считаю это правильным, продукт делает не один человек, а команда и каждый занимается своим делом. Только командой можно добиться результата и идти вперед покорять вершины.
