SoftSource начинает серию статей на тему: как определять KPI (ключевые показатели эффективности) для главных сотрудников IT-компании. Это поможет создать атмосферу принятия ответственности и поддержки инноваций в вашей компании.

Автор статьи: Юрий Лозинский, CEO at DIGITALOUTLOOKS, г. Днепропетровск.

Мини книга “Тайм-менеджмент и личная эффективность”

Скачайте книгу сейчас

 

Marketing by

Начнем с причин, или как говорят в IT-отрасли, с «боли». Идея внедрения KPI для разработчиков используется не для того, чтобы заставить их работать, или как правильно говорить, – «промотивировать». Разработчики, в общем-то, и без KPI работают замечательно. Или не работают. Основная задача руководителя – построить бизнес-модель компании и иметь инструментарий для what-if анализа. Чтобы понять, как построить систему сбалансированных показателей для IT-компании, коротко рассмотрим устройство бизнеса в общем. Традиционно у компании есть центры затрат и центры генерации прибыли.

К центрам генерации прибыли относят:

1. Отдел продаж (прямо)
2. Отдел маркетинга (косвенно)
3. Отдел поддержки Клиента (апсейл и кросс-сейл)

К центрам затрат относят:

1. Производство.

Увязывая отношения между подразделениями генерации прибыли и центрами затрат, мы приходим к той или иной модели функционирования компании и понятиям эффективности и прибыльности.

Проецируем общие принципы на суровые будни IT компании и получаем:
Центры генерации прибыли:

1. Продавцы со своими бюджетами на технический присейл и маркетинг

Что касается центров затрат, то в случае IT-компании, производство объединяет разработчиков и всякого рода производственных менеджеров, которые осуществляют так же апсейл и кросс-сейл, частично выполняя функции генерации прибыли:

1. Разработчики
2. Руководители проектов
3. Руководители программ проектов

При этом, генерация прибыли от производства всячески приветствуется и культивируется, но в обязанности не ставится.   Производственные менеджеры от компании к компании могут наделяться разными уровнями полномочий и соответственно, – разным набором метрик и показателей для контроля эффективности.  

В нескольких статьях мы рассмотрим KPI для всех четырех бизнес-ролей и увяжем их в общую систему, отражающую положение дел в IT-компании.

Начнем с разработчиков.

От разработчика я, как управленец ожидаю не чудес сверхпроизводительности в течении итерации(с последующей трёхмесячной реабилитацией в клинике для душевно-больных) , а прежде всего предсказуемости.  Это необходимо для планирования и оценки, чтобы отдел продаж имел инструмент оценки объемов работ (назовем его Project evaluation score card) и мог в любой момент ответить на вопрос «Сколько?». Разумеется, с некоторой точностью.

Итак, я спокоен, если понимаю, что могу ожидать от своих разработчиков:

1. Выполнения работ с некоторым качеством. Качество мы измеряем количеством багов в итерацию.
2. Выполнения работ в некоторые сроки. Отклонение от первоначальных сроков мы измеряем в процентах.
3. Желание двигаться в перед и развиваться.

Если у Вас есть более трёх пунктов, с Вами что-то не так и вы не можете определиться с тем, чего хотите от своего производства.

Итак, выписываем в таблицу и ранжируем наши пожелания. При этом понимаем, что сумма весов каждого из пожеланий должна составлять 100% :

Для каждого из пожеланий определяем граничные значения.
Предположим я считаю, что 3 бага за итерацию, это вполне нормально.

Отклонение от заявленного срока 5% -это тоже вполне приемлемо.

Личные планы развития разработчика должны совпадать с ценностями компании. Человек мог бы подтвердить свою квалификацию сертификацией и постоянно совершенствовать английский.

При этом стратегические показатели по сертификации (поможет мне в будущем продавать) явно проигрывают тактическим потребностям в ежедневном общении с заказчиком или работе с требованиями и прочей документацией.

Теперь – самое важное: «коммитмент»

Несмотря на то, что «колхоз – дело добровольное», рекомендую все же ознакомить разработчика с его целями и задачами на ближайший период.

Чтобы объяснить разработчику, почему он должен «закоммититься» на выполнение этих показателей, мы предлагаем самую эффективную мотивацию. Денежную. После того, как вы с разработчиком достигли понимания, вводите инструмент трекинга показателей и расчета будущей премии:

Итак, по итогам прошлого периода, разработчик допускал в среднем 1 баг за итерацию, что ведет к перевыполнению этого показателя: 167%

Немного хуже обстоят дела с попаданием в сроки – актуальные 6% выше запланированного 5% значения. При этом для данного показателя вводится понятие минимальной и максимальной границы. Если разработчик в превышает оценку более чем на 70%, премии ему по данному показателю не видать.

С другой стороны, чтобы разработчик не завышал оценку, выполнение задач быстрее более чем на 25% к бесконечному линейному росту премии не приведут. Таким образом нет смысла завышать сложность работ, но при этом остается желание сделать работу чуть быстрее.

С качественными показателями еще проще. Сертификат либо получен, либо нет. Уровень английского либо повышен, либо нет. Ставим 1 или 0. В конечном итоге, получаем прозрачную модель, мотивирующую разработчика:

Разработчик всегда может ввести актуальные показатели и посмотреть, на какую премию он может рассчитывать по истечении отчетного периода. Наибольшую гибкость дает трёхмесячный контроль показателей.

Для примера хочу показать менее красивую картинку по выполнению показателей и соответственно, рассчитанную премию:

Хочу особо отметить, что данная модель никак не является заменой плановой аттестации. Скорее хорошим дополнение по существу: садимся, составляем набор KPI которые интересно выполнять разработчику и компании, проставляем значения и идем работать.

В завершении скажу, что если Вы действительно хотите использовать этот инструмент эффективно, поищите время для подбора индивидуальных метрик для каждого вашего разработчика.

Если мы хотим точной оценки, то не нужно всех разработчиков – под одну гребенку. Предлагать нужно, конечно, «среднее по больнице», но лишь в качестве отправной точки. А вот конкретно какие будут у каждого показатели прописаны – это предмет «торга» на аттестации.

Что касается индивидуального подхода, то аттестацию проводят ведь PM-ы в присутствии HR-а (рентеншен-консультант) – всегда очень даже индивидуально. При этом HR выступает в роли третейского судьи и следит за тем, чтобы стороны договорились и не переходили границ личного пространства. Не обязательно делать это первым лицам. Даже программ-менеджерам не обязательно, если Вы считаете, что их время для такой задачи слишком дорого.

И приглашаем в наш клуб “Growth Factory Academy” где мы помогаем компаниям размером от 5 до 200 развивать свои бизнесы даже в это не простое время с помощью:

• регулярных занятий и мастерклассов (8 в месяц)
• доступ к закрытой библиотеке конференций Outsource People и тренингов за 8 лет
• закрытое сообщество из 150+ директоров

Для тех, кто только хочет или запускает компанию – изучите возможности “Аутсорс Инкубатора” – аналогичный клуб, только для начинающих.

И если в вашей компании оборот от $1mln/год, то можете подать заявку на MasterMind

Павел Обод Партнер и основатель “Growth Factory”

Соц. сети: