KPI для любимых разработчиков от Юрия Лозинского

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

 

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

 

 

Начнем с причин, или как говорят в 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% :

 

KPI Name

KPI Weight

Deliverables quality

35%

Deliverables ETA (%)

50%

Qualitative goals

15%

Total

100%

 

Для каждого из пожеланий определяем граничные значения.

 

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

 

Deliverables quality

 

KPI Name

Target Value

Bugs per iteration (+/-)

3

 

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

 

Deliverables ETA (%)

 

KPI Name

Target

Time to Delivery Deviation

5.0%

 

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

 

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

 

Qualitative goals

 

Deliverable
Statement

Task Weight

Certification

20%

English

80%

 

100%



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

 

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

 

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

 

После того, как вы с разработчиком достигли понимания, вводите инструмент трекинга показателей и расчета будущей премии:

 

Deliverables quality

       

KPI Name

Target Value

Actual

Actual vs Target

KPI Execution

Bugs per iteration (+/-)

3

1

167%

167%

 

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

 

Deliverables ETA (%)

           

KPI Name

Target

Min
Cutoff

Max
Cutoff

Actual

Actual vs Target

KPI Execution

Time to Delivery Deviation

5.0%

70%

125%

6.0%

80%

80%

 

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

 

Если разработчик в превышает оценку более чем на 70%, премии ему по данному показателю не видать.

 

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

 

Qualitative goals

   

Deliverable
Statement

Task Weight

Weighed KPI Execution

Certification

20%

1

English level: +1

80%

1

 

100%

100%

 

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

 

В конечном итоге, получаем прозрачную модель, мотивирующую разработчика:

 

1.

Bonus

           
 

Bonus Base

$6,000

 

 

-filled by employee (actuals)

               
 

Bonus calculation

           
 

KPI Name

KPI Weight

Target Bonus

Actual KPI Executoin

Actual Bonus

   
 

Deliverables quality

35%

$2,100.00

167%

$3,500

   
 

Deliverables ETA (%)

50%

$3,000.00

80%

$2,400

   
 

Qualitative goals

15%

$900

100%

$900

   
 

Total

100%

$6,000

113%

$6,800

   
               

2.

Deliverables quality

           
 

KPI Name

Target Value

Actual

Actual vs Target

KPI Execution

   
 

Bugs per iteration (+/-)

3

1

167%

167%

   
               

3.

Deliverables ETA (%)

           
 

KPI Name

Target

Min
Cutoff

Max
Cutoff

Actual

Actual vs Target

KPI Execution

 

Time to Delivery Deviation

5.0%

70%

200%

6.0%

80%

80%

               

4.

Qualitative goals

           
 

Deliverable
Statement

Task Weight

Weighed KPI Execution

       
 

Certification

20%

1

       
 

English

80%

1

       
   

100%

100%

       



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

 

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

 

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

 

1.

Bonus

           
 

Bonus Base

$6,000

 

 

-filled by employee (actuals)

               
 

Bonus calculation

           
 

KPI Name

KPI Weight

Target Bonus

Actual KPI Executoin

Actual Bonus

   
 

Deliverables quality

35%

$2,100.00

33%

$700

   
 

Deliverables ETA (%)

50%

$3,000.00

0%

$0

   
 

Qualitative goals

15%

$900

80%

$720

   
 

Total

100%

$6,000

24%

$1,420

   
               

2.

Deliverables quality

           
 

KPI Name

Target Value

Actual

Actual vs Target

KPI Execution

   
 

Bugs per iteration (+/-)

3

5

33%

33%

   
               

3.

Deliverables ETA (%)

           
 

KPI Name

Target

Min
Cutoff

Max
Cutoff

Actual

Actual vs Target

KPI Execution

 

Time to Delivery Deviation

5.0%

70%

200%

10.0%

0%

0%

               

4.

Qualitative goals

           
 

Deliverable
Statement

Task Weight

Weighed KPI Execution

       
 

Certification

20%

0

       
 

English

80%

1

       
   

100%

80%

       



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

 

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

 

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

 

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



Назад


  • photo
    • Aleks L
    • 28 августа 2015, 23:58

    спасибо за интересную статью. подскажите а как вы предлагаете контролировать правильность оценки времени необходимого на задачу\итерацию. ведь все показатели сводятся к тому чтобы вложится в оценку (собсвенную?) и потратить достаточное время на контроль качества. Соотвественно в редко повторяемых задачах в рамках одной компании ета переменная "оценка времени" будет слабым звеном которое все KPI сведет на нет..

    • photo

      Здравствуйте Оценка не собственная, оценку каждой user story дает команда Ну, а контролем качества занимаются ребята из QA/QC