Kpi программиста – KPI, или пособие по командному самоубийству / Habr

Содержание

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 выступает в роли третейского судьи и следит за тем, чтобы стороны договорились и не переходили границ личного пространства. Не обязательно делать это первым лицам. Даже программ-менеджерам не обязательно, если Вы считаете, что их время для такой задачи слишком дорого.

www.softsource.org

Показатели эффективности (KPI) для сотрудников ИТ

Эта статья родилась из вопроса мего друга — ИТ директора компании Балтмикс (крупнейший производитель техники в России, основной поставщик техники для сети Эльдорадо) о измерении эффективности работы своих сотрудников.

Не без моих усилий был создан клуб ИТ директоров Калининградской области. Собственно, письмо было отправлено членам клуба.

Мой ответ:

Как и обещал, отвечаю 🙂 как всегда с небольшим опозданием.

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

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

Я могу рассказать, каким образом я разрабатывал систему контроля и управления процессом разработки для своих сотрудников, как местных, так и удаленных на сотни, а иногда и на тысячи километров. Если судить по увеличению моей зп и законченным продуктам, могу сказать уверенно, у меня это получилось.

Что я делал для создания KPI:

  • Нашел, относительно чего можно оценивать эффективность
  • Понял, как можно оценивать
  • Сделал прозрачную систему оценки эффективности в числах

Как я предполагаю, мало кого заинтересует мой непосредственный опыт. Т.к. я управляю процессами разработки и создания программных продуктов и специализируюсь в этом. И далее также планирую развивать себя как специалиста в этой области. Это моя сильная сторона. Я расскажу общие принципы, которыми я пользовался для оценки деятельности своих специалистов.

Как найти точку опоры для KPI

Я определил цель работы каждого подразделения и сотрудника в двух аспектах:

  1. внутри проекта (если мы подразумеваем проектную деятельность)
  2. в деятельности (если речь идет о процессе, например, поддержке)

Не менее важно определить результаты деятельности специалистов. Для этого достаточно ответить на два вопроса:

  1. Что должно получиться в результате его работы?
  2. Каким должен быть процесс? (если процесс бесконечен, например, поддержка)

Так же важно понимать временной интервал контроля. Для себя я его определил как неделю — 40 часов.

Что является объектом контроля

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

Контроль в числах

Как я уже писал, общей формулы у меня нет и я сомневаюсь в возможности её составить. Но точно можно и необходимо вывести её для любой позиции, в том числе в нашей сфере — ИТ. Я предложу только предметы для оценки. Теперь по пунктам вопроса.

Системные администраторы

Безопасность

может быть оценена внешним, независимым, агенством

Часы бесперебойной работы

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

Администраторы баз данных

Скорость получения данных (отклика)

Это относительная цифра, необходимо считать её в зависимости от задачи. У меня это 0.2с

Скорость обновления данных — актуальность данных

Аналогично

Скорость восстановления данных

Это количество часов, которое потребуется администратору для восстановления системы. Я всегда рассматриваю несколько сценариев: от потери одного диска в рейде до потери сервера.

Бесперебойная работа — надёжность и безопасность

аналогично сис.админу

Тех поддержка, Скорость ответа, Количество решенных задач, к не решенным, Количество задач, которые удалось решить, не прибегая к помощи других отделов, Удовлетворенность пользователей

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

Программисты

Безопасность

не буду повторяться

Скорость работы приложений

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

Отказоустойчивость

Необычайно легко измерима, если есть система контроля требований и баг репортов. Такие системы я создаю вначале работы над проектом или процессом.

Соответствие прототипу и тз

Честно говоря не нашёл численных методов оценки этой немаловажной характеристики. Мне повезло с тестером, он отлично чувствует и пинает программистов, если что-то не так.

Количество эффективных часов
  1. Это часы адекватно оцененные при планировании деятельности
  2. Сколько таких часов у программиста в неделю, месяц, год

Эффективные часы — это время, которое уходит только на решение задачи. Когда ничто не отвлекает, никто не мешает. Далее, соотнося эти часы с длиной итерации (в моём случае это с 40-часовой рабочей неделей), можно легко найти причины неэффективности работы и повлиять на них.

Аналитики

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

Окончание

Я знаю и понимаю компании в, которых подобный учёт не ведется. Мой подход сформировался при жестких ограничениях со стороны основного заказчика — инвестора. Я действительно считаю часы эффективной работы своих сотрудников и контролирую процессы разработки. У меня есть свой «прогресс бар» движения проектов, а так же то, что я отмечаю отдельно. Я добился минимизации затрат, на счет «ворон» сотрудниками. То есть максимальной эффективности и осознанности при работе в проекте.

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

Какие темы нуждаются в более детальном раскрытии на ваш взгляд?

PS: хочу сделать свой блог в стиле «Я CIO»

im-cio.blogspot.com

Программисты и KPI: fixin — LiveJournal

Имеет ли смысл сажать программиста на KPI? Т.е. ставить ему оклад, исходя их достижения определенных, изначально заданных целей?

Весьма сомнительное решение.

Хорошо зарекомендовали себя два способа оплаты труда программиста:

1. Оклад — хорошо, когда известно, что программист вменяем, работает не отлынивая и занят полезным трудом минимум 80% времени. Тогда нагружать его дополнительной отчетностью бессмысленно.
2. Почасовка — программист должен писать отчеты о проделанной работе и измерять ее в часах. Эти отчеты проверяются и делается зачет некоторого времени.

Сейчас я работаю на окладе, были времена, что работал на почасовке. Обычно нормой является 150 часов за 25 рабочих дней, т.к. и ежу понятно, что в день эффективно можно работать 6 часов, остальное время уходит на транзакционные издержки.

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

А теперь предположим, что программисту поощряют по KPI, т.е. от результатов действия фирмы:

1. Этот результат зависит не только от него, даже если он и выложится, то другие могут подкачать и это расхолодит.
2. Когда программист работает в авральном, а не спокойном режиме, появляются баги и проблемы.
3. Легко найти работу на фиксированный оклад. Плавающий оклад обычно показывает коррекцию в сторону уменьшения оклада, а не в сторону его увеличения. Поэтому программист воспринимает такой подход, как способ снизить ему зарплату и делает соответствующие выводы.

Поэтому не надо изобретать велосипед и сажать программиста на KPI, господа хорошие.

P.S.: что касается меня, то покупательная способность моих 120 тыщ-пыщ за последние три года (оклад не менялся) снизилась на 21% (7% в год * 3 года), т.е. сейчас я получаю 95 000 по меркам 2010 года. При таком понижении зарплаты никакой KPI не страшен!

fixin.livejournal.com

[prog.work] Вновь о теме KPI для программистов

Сегодня получил очередной комментарий к довольно старой теме “Интересная дискуссия о KPI для программистов”:

Любой человек «очкует» когда его пытаются оценить. У программистов это явно выражено. Да, программирование сродни хотьбе по лабиринту, я соглашусь с этим. Но а что. работа менеджера по продажам не сложна? А работа врача? Почему-то для продавцов можно KPI разрабатывать а для программеров нет.

Я руковожу программистами и знаю как это непросто. Но я уверен, что «неоценивать» работу разработчиков нельзя. Должны быть критерии.

Вообще, судя по статистике, с поисковых сайтов по запросу “KPI программиста” ко мне в блог заходит изрядное количество посетителей (в Yandex-е по этой фразе я вообще затесался на третье место среди результатов, что свидетельствует, имхо, о крайней нераскрытости темы). Посему я решил дать ответ на комментарий в виде отдельной заметки.

Не могу объективно сравнивать критерии оценки работы программиста с другими областями деятельности, поскольку мало в них разбираюсь. Не имею понятия о том, как оценивается работа врача (опять же, какого – ведущего прием участкового терапевта или анестезиолога в кардиологическом центре?) И о том, как оценивают агентов по продажам. Слегка наслышан об оценке рабочих на производствах, где есть нормы выработки и нормативы на время производства конкретных изделий по конкретным спецификациям. Так же приходилось слышать об оценке научной деятельности по количеству публикаций статей/монографий и количеству докладов на конференциях (что так же не слишком тепло встречалось самими научными работниками).

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

В вопросе о KPI для меня самым непонятным моментом является цель этого дела. Зачем нужен KPI программистам вообще? Допустим, у вас есть коллектив разработчиков, который справляется со своей работой – укладываются и в допустимые сроки, и в приемлемый бюджет, и проекты с должным качеством выполняются, и приносит компании прибыль.

На мой далекий от бизнеса взгляд это уже зашибись! И тут в пору вспомнить основной принцип программизма – если что-то работает, то не трогай – пусть работает дальше. А то ведь время от времени встречается информация о том, что по каким-то там оценкам изрядный процент программных проектов превышает сроки и бюжеты, а то и вовсе закрывается как провальные. Если к такой информации прислушиваться, то вокруг все просто жуть как плохо, а у вас все хорошо. Ну так и не трогайте 🙂

Если же все не так радужно и с проектами беда, то нужно ли пытаться решить проблемы начиная с KPI самого нижнего слоя пирамиды – с разработчиков? Рыба известно откуда гниет. И если проект трещит по швам, то может лучше начать с другой стороны? Вдруг это кто-то там наверху выбрал сроки и бюджет из политических, а не реалистических соображений? Или проект был поручен горе-менеджеру, который знает очень много правильных слов и блестяще ораторствует на советах директоров, но не может донести до команды точные цели проекта и конкретные пожелания заказчиков? А если все руководство, включая непосредственно работающих с программистами тим-лидов, супер-пупер профессиональное, то как тогда получилось, что у них в подчинении совершенно бестолковые разработчики, не способные писать нормальный код?

Или может KPI нужен для того, чтобы размер зарплаты и премий рассчитывать? Если у Феди показатели по KPI на 15% выше, чем у Васи, то Федя получит премию, а Вася нет. Уж не в этом ли цель KPI?

Эту цель хотя бы понять можно. Однако, почему такой подход лучше, чем делегирование распределения премиальных конкретному менеджеру или тим-лиду? Тем, что объективнее? Да фигня это все! В управлении субъективизма изначально настолько много, что попытка подвести какой-то формальный базис под распределение премии выглядит… Как трусость она выглядит. Потому что если руководителю нужны какие-то формальные отмазки для ответа на прямой вопрос “Почему мне премию не дали?”, то руководитель этот такой же формальный.

Ну да все это лирика и риторика. Суть-то в другом.

Как ни крути, но руководителю все равно приходится оценивать своих подчиненных. Чтобы решать, кто и чем будет заниматься в очередном проекте. Кому можно поручить самые важные куски, кто будет заниматься рутиной, кто будет гоняться за злобными багами. Очень нужны оценки для предсказания сроков разработки. Поскольку Федя может сделать за месяц, а Вася за полтора. А Гена за две недели, но только если ему задача понравится.

Поэтому руководитель вынужден заниматься оценкой работы своих подчиненных. Пообещал Гена уложиться в две недели, а реально потребовалось три. Значит для его оценок нужно вводить коэффициент поправки 1.5, а то и больше. Уложился Вася в срок – хорошо, на баги затем пришлось десятками ловить, значит в следующий раз за Васей более серьезный присмотр нужен. Федя может сделать все быстро и качественно. Если не забудет и не отвлечется на очередной pet project. Поэтому для Феди нужно выделять по 15 минут в день для раздачи поджопников напоминаний.

Но все это проблемы руководителя. И пусть он сам выбирает для себя критерии, которые считает нужными. Подберет удачно – хорошо. Не подберет, команда перестанет работать, придется выдумывать что-нибудь другое. Нормальный процесс проб и ошибок. Который, однако, должен быть скрыт от программиста.

И именно это является основной мыслью данного поста. А именно:

Критерии оценки работы программиста не должны быть известны программистам.

Только так.

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

Зависит зарплата от количества строк написанного за день кода? Нет проблем – copy-and-paste. И нафиг мне два дня думать, как сделать что-то 10 строчками кода, если я могу за три дня написать то же самое в 1500 стоках говнокода.

Поставили зарплату в зависимость от количества багов? Ну тогда сложные задачи идут лесом. Пусть их Пушкин делает и баги затем расхлебывает. А уж если поручили, то я лучше буду на каждый чих разрешение у тим-лида или менеджера спрашивать – пусть эти баги будут и на их совести, да и в следующий раз подумают, следует ли меня чем-нибудь нетривиальным грузить.

Оценивается точность предсказания сроков? Отлично, будем их изначально завышать в 2*PI раза.

Почему так? Да потому что так! Я ведь не ящики с места на место таскаю. Мне нужно выдумать что-то, чего нет. Зачастую убив кучу сил и времени на то, чтобы выяснить, что же именно надо. После чего воплощаю это в коде и заставляю работать как нужно. И то, чего изначально не было вовсе, вдруг появляется и, зачастую, работает!

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

eao197.blogspot.com

Какие KPI можно измерять, если расписание и бюджет проекта не очень важны? / Habr

Конечно же расписание и бюджет важны. Если расписание проекта не важно, попросите ваших коллег позвонить вам через два года, когда проект закончится :).

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

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

Преимущества или поставки — если они материализуются, то продолжают накапливаться по ходу проекта. В разрезе проекта –KPI ориентированные на получение выгоды или поставок являются очень важными показателями. Они являются ответом на вопрос – «Имеют ли продукт или услуга производимые в рамках проекта, какую либо ценность?»

Для менеджера проекта, в большинстве случаев, производство чего-либо ценного, может быть намного более важным, чем быть в пределах расписания или бюджета. Таким образом, даже если на управление расписанием и бюджетом проекта не уделяется должного внимания, вы можете отслеживать ценность проекта.

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

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

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

Как итог хочу подвести некоторые показатели, которые все таки можно отслеживать помимо расписания и бюджета:
• Поставки
• Загруженность ресурсов
• Качество
• Количество дефектов
• Количество итераций
• Риски
• Удовлетворённость заказчика
• …

habr.com

ключевые показатели эффективности: пример расчета +цель

Здравствуйте! В этой статье мы поговорим о системе KPI.

Сегодня вы узнаете:

  1. Что такое KPI.
  2. Как рассчитать этот показатель.
  3. Как внедрить систему KPI на предприятии.
  4. О плюсах и минусах данной системы.

Что такое KPI простыми словами

KPI — это коэффициент, определяющий эффективность работы того или иного предприятия: насколько оно удачно функционирует, достигает ли поставленных целей.

Расшифровка этой аббревиатуры выглядит следующим образом — Key Performance Indicators, что на русский принято переводить как «ключевые показатели эффективности».

Если переводить дословно, то слово «key» означает «ключевой», «существенный», «indicators» — «показатели», «индикаторы», а вот со словом «performance» возникают трудности при переводе, поскольку здесь его сложно трактовать однозначно. Существует стандарт, который дает наиболее правильный перевод этого слова, разделяя его на два термина: эффективность и результативность. Эффективность показывает, как соотносятся затраченные средства и достигнутые результаты, а результативность — в какой степени компании удалось достигнуть того результата, который был намечен.

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

Индикаторы KPI бывают следующие:

  • KPI производительности — показывает соотношение затраченных денежных и временных ресурсов с достигнутым результатом;
  • KPI затрат — показывает, сколько задействовано ресурсов;
  • KPI результата — иллюстрирует полученный в ходе выполнения задач итог.

Есть система KPI и в инте

kakzarabativat.ru

Отправить ответ

avatar
  Подписаться  
Уведомление о