понедельник, 20 сентября 2010 г.

[prog.work] Ну и еще несколько слов о KPI

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

У разработчика есть фиксированный оклад, прописанный в трудовом договоре. За хорошую работу разработчика можно премировать, скажем, на 1%-50% от оклада. Премии выплачиваются в двух случаях:

  • успешное завершение проекта (это очень важно);
  • ударная работа над срочными и неожиданными задачами.

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

Оценка успешности работы субъективная. Выполняется тим-лидом или начальником отдела, под непосредственным руководством которого трудится разработчик. Да, это потенциально черевато “землячеством”, “кумовством” и пр. негативными явлениями, но человеческий фактор есть человеческий фактор. Имхо, проще, когда приходится иметь дело только с человеческим фактором, без усугубления ситуации всякими формальными системами оценок и показателей.

В завершение расскажу о небольшом своем опыте в этой области. Год назад на мою команду (в которой тогда было всего три человека, включая меня) упал на реанимацию старый и сильно запущенный проект. Поскольку работы было много, людей мало, а время и ответственность давили очень сильно, то я согласовал с начальством такую схему. Разработчикам устанавливалась дополнительная премия (где-то в размере 1/3 от их тогдашнего оклада). Но ее размер уменьшался в зависимости от наличия претензий к качеству их работы с моей стороны (я делал code review и заставлял переделывать особенно плохие куски) и со стороны техподдержки (которые выявляли проблемы уже при эксплуатации). Если претензий не было, то человек получал премию в полном размере. Если были, то премия урезалась на 25%, 50% или больше.

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

2 комментария:

night beast комментирует...

Тута на habre заметку выложили
http://habrahabr.ru/company/intel/blog/106082/
может заинтересует

eao197 комментирует...

Такие статьи время от времени на разных ресурсах проскакивают. В последние раз я что-то подобное читал на IBM alphaWorks.

Мое мнение, что метрики кода не могут быть источником KPI в принципе. Разве что в оффшорных шарагах, которые заинтересованы в продажах жопочасов, а не продуктов.