×Закрыть

Team Performance Dashboard, или Как измерить реальную продуктивность сотрудников

Я работаю в компании Devart на позиции Senior Technical Project Manager в отделе, состоящим из 4 команд. Общая численность отдела — около 50 сотрудников, занимающимися 35 проектами. Помимо нашего есть и много других небольших отделов.

Как и любая другая продуктовая компания, мы заботимся о качестве и успешности своих продуктов на рынке. Кроме всего прочего, один из залогов успеха продукта — заинтересованные в нем сотрудники. Они не должны быть равнодушными к судьбе разрабатываемого продукта и должны стараться, по мере своих сил, сделать его лучше. Со своей стороны тимлидам, сеньорам стоит помогать развиваться начинающим специалистам, менторить и выполнять code review написанного кода. Другими словами, выступать в роли «фильтра», пропускающего в проект только качественные части программного кода.

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

Team Performance Dashboard — инструмент, предназначенный для определения эффективности работы как команд, так и отдельных сотрудников. Оценка, которую можно получить, используя Team Performance Dashboard, будет полезна в первую очередь менеджерам проектов, тимлидам, HR-ам, PP-ам, и, конечно же, CTO. В статье я расскажу о том, как мы в компании сами разработали, внедрили и как сейчас используем этот инструмент.

С чего все началось

Выполняя обязанности PMа в разных IT-компаниях, часто мне приходилось слышать от сотрудников разного уровня следующие вопросы:

  • Какой в компании предусмотрен план роста для меня как для начинающего специалиста?
  • Какие в дальнейшем будут бонусы, если я изучу определенную технологию?
  • Когда и при каких условиях смогу перейти на следующий уровень?
  • Какой стек технологий наиболее важен и ценен для компании?
  • Насколько уровень новичка в компании соответствует уровню junior на рынке?

Перечисленный набор вопросов далеко не новый или необычный для IT-компаний, но наиболее актуальны эти вопросы именно для продуктовых компаний. В них каждый сотрудник, проработавший в компании более пары-тройки лет, является носителем большого объема знаний. Часто бывает так, что только конкретный сотрудник может однозначно ответить на тот или иной вопрос. Это, конечно, не является хорошей практикой, но реальность такова. Поэтому ценность сотрудников в продуктовых компаниях должна быть выше, чем в аутсорсных компаниях. Работая в последних, мне не представлялось вести проекты, длящиеся более пары лет, тогда как в продуктовых приходится заниматься проектами (и продуктами), которым уже больше десятка лет.

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

Приходит момент, когда сотрудник, «тянущий на себе» проект, замечает коллегу, не особо старающегося, и задается вопросом: «Почему мне нужно выкладываться по полной, выполнять огромный объем работ, тогда как кому-то позволено работать спустя рукава и точно так же получать свою оплату труда? Может стоит также себя вести?». В результате таких мыслей менеджмент получает еще одного сотрудника, про которого можно сказать, что он «перешел на темную сторону мышления» :)

Для выявления на ранних этапах зарождения такого мышления и своевременного предотвращения таких переходов «со светлой стороны на темную» и разрабатывалась система оценивания производительности каждого из сотрудников, которую мы назвали Team Performance Dashboard.

Вот чем оказалась полезна эта система для меня как для PMа, для тимлидов команд и для топ-менеджеров в целом:

  • формирование общей картины эффективности кадрового состава;
  • определение динамики работы конкретного сотрудника и команды в целом;
  • сравнение качества работы сотрудников на одинаковых позициях;
  • определение, насколько изменилось качество работы сотрудника за выбранный период времени;
  • понимание морального климата во время релизов и того, как сотрудники могут «активизироваться» к релизу продукта;
  • понимание того, насколько и какие знания наиболее ценны в компании, отделе, команде;
  • выявление сотрудников, не особо стремящихся работать;
  • текучка персонала (кто и после какой активности обычно уходит);
  • мотивация сотрудников.

Но это мы забежали немного наперед...

Как создавали комплекс оценивания

Как это часто бывает, началось все с идеи и листка бумаги :) Туда записывались идеи о критериях оценки и чего не хватает для эффективного применения выбранных критериев.

Далее перечислены пройденные этапы:

  • определены уровни градаций для следующих типов сотрудников: Dev, QA, TW;
  • описаны требования для перехода сотрудника на следующий уровень (например от junior до strong junior);
  • разработана система оценивания issue по сложностям (для Feature, Task, SubTask, Bug и др.);
  • введен учет количества переоткрытий задач сотрудником и командой;
  • сформирован процесс определения общего балла сотрудника, составленный с учетом как динамических, так и статических критериев оценки сотрудников;
  • составлен список критериев, по которым будет выполняться оценка Dev, QA, TW;
  • определен период и частота оценивания сотрудников;
  • сформированы виды оценок, применяющиеся при формировании общего балла (рейтинга сотрудников).

Сами же уровни градации сотрудников были утверждены руководством и сформированы требования перехода с уровня на уровень.
Для оценивания сотрудников использовали статические и динамические критерии.

Так, за статические критерии оценки приняли критерии (набор знаний), с которыми пришел сотрудник в компанию и которые нужно пересматривать ориентировочно каждые 3-6 месяцев.

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

Пример формирования статических критериев и рейтинг сотрудников (на примере QA) можно увидеть на рисунке ниже:

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

Практическое применение системы в реальных условиях

Для использования этой системы на практике понадобилось добавление некоторых полей (для динамической оценки), например, complexity, business value, в задачи таск-трекинговой системы Jira. И, конечно же, добавленные поля должны быть не пустыми :) Поэтому нужно время для формирования оценки. Этот период может быть любым: от одного дня и до нескольких лет, но чем дольше будет такой период, тем интереснее получаются данные.

Приведу несколько примеров из практики.

Повышение сеньора до тимлида

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

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

В оранжевом прямоугольнике можно увидеть, что бывший сеньор уже «смирился» с тем, что он в первую очередь тимлид команды, а только потом девелопер. Сильный спад продуктивности, почти до «нуля» — он был в отпуске :) А дальше следуют равномерные колебания в зависимости от релизов, джунов и так далее.

Из приведенного примера видно, что если продолжать оценивать лида как senior девелопера, то он несомненно будет «проигрывать» в такой оценке.

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

Ниже приведен график изменения производительности по типам задач всей команды после назначения нового лида.

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

Запрос на пересмотр оплаты труда

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

Ниже приведен результат сравнения двух этих разработчиков по одинаковым критериям за выбранный период времени:

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

Определение оптимальных сотрудников для завершения релиза

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

Дополнительный функционал для People Partners и HR компании

Для HR отдела добавлен функционал «личная карточка сотрудника», которая содержит следующую информацию:

  • список всех сотрудников компании, сгруппированных по командам и по должностям (Dev, QA, TW и т. д.);
  • дата приема сотрудника в компанию, общий стаж работы на аналогичной позиции, фото сотрудника, дата его рождения, текущий уровень квалификации (junior, middle и т. д.) и его контактная информация (email, skype, cell-phone и др.);
  • проекты, в которых принимал участие сотрудник, и какие технологии использовал в них, сколько задач было сделано по проектам и сколько времени на это было затрачено (суммарное значение);
  • результаты проведения one-to-one митингов с сотрудником и сделанные выводы по ним.

В системе определены уровни доступа, разграничивающие получение и редактирование информации. Так, на данный момент в системе предусмотрено 4 уровня доступа:

  • Сотрудник. Этот уровень позволяет просматривать текущий рейтинг, как статической, так и динамической оценки сотрудника (только своей). Также контактную информацию о сотруднике с возможностью ее редактирования.
  • Team Lead. Предназначен для тимлидов команд и позволяет просматривать как свою оценку и контактную информацию, так и всех сотрудников своей команды. Кроме этого, он может посмотреть, как работала команда за выбранный период времени.
  • HR/PP компании. Этот уровень позволяет просматривать «личную карточку сотрудника» и модифицировать её, а также динамическую оценку выбранного сотрудника за выбранный период.
  • Менеджмент. Этот уровень аналогичен уровню «администратора» и имеет доступ ко всей информации системы.

Подведем черту

Для компании использование этой системы оказалось весьма полезным. Почему? Да все просто:

  • возросла производительность команд (примерно на треть);
  • уменьшилось количество сотрудников, которые пытались «увильнуть» от работы;
  • пересмотр оплаты труда стал более прозрачным и понятным для всех категорий сотрудников;
  • менеджмент получил возможность лучше понимать производительность команд.

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

LinkedIn

Лучшие комментарии пропустить

Есть гипотеза что при введении любых KPI сотрудники начинают страться улучшать их а не продукт.

Как измерить реальную продуктивность сотрудников

никак

KPI просел из-за того что разработчик занимался ревью? что за ерунда?

сколько я видел KPI систем, у все одни и еже проблемы
— система не прозрачная
— формулу расчета никто тебе не даст
— нельзя смотреть KPI других сотрудников (а на многих еще она и не распространяется, дада, некоторые равнее)

кто сторожит сторожей?

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

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

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

Критически отношусь к измерению производительности в отрыве от оплаты и рыночной ситуаци, по таким причинам.
1. Нет каких-либо абсолютных единиц, дескать этот делает пять попугаев в день — этот десять поэтому можно сравнивать только с другими людьми работающими на одном и том-же оборудовании
2. В АйТи и людей сравнивать нельзя и вот почему: есть джуниор, работает за $500, овертаймит, глаза горят. И есть я, делаю работу которую не могут другие(иначе меня не берут), глаза не горят, проект вертел на одном месте, стою в час как хороший джуниор, почти миддл, в день(или больше). Кто из нас производительней?
3. Зачем эта производительность вообще? Что она даёт? Имхо, ответ на вопрос: кому повысить, зарплату — кого уволить. Чтобы ответить на него нужно понять могу-ли я взять с рынка труда работника лучше, но на те-же деньги и сколько мне это будет стоить(найм тоже не бесплатный)?

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

123 комментария

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

Подскажите пожалуйста, это ваша внутренняя самописная тулза, или есть где-то готовое решение? А то толком ничего похожего на то что в вашей статье я не нашел, заранее спасибо! :)

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

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

Как на счет релиза iOS 13? Много ли багов в этом релизе? Перестали ли пользоватся устройствами на этой операционке из-за «неприятного опыта»?

Как на счет релиза iOS 13?

Я думал статья про Devart а не про Apple.

Перестали ли пользоватся устройствами на этой операционке из-за «неприятного опыта»

Не знаю какой опыт у пользователей iOS, но имею опыт пользования dbForge, и этот опыт оказался довольно болезненным, и в данном контексте могу ответить — перестал.

Тогда что на замену dbForge было выбрано?

Вообще-то статья и не про команию Devart и не про его продукцию dbForge.

Ух, даже не знаю, что тут сказать. Выглядит дико. Не сама система, а предложенные KPI и сделанные на их основе выводы. Полностью согласен с анализом Sergii Sichynskyi. На первый взгляд этот набор KPI выглядит бесполезным, на второй взгляд — зловредным.

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

Предложу начать с этого:
1) User Experience/Satisfaction. Даже банальной динамики оценок пользователей в магазинах приложений для начала будет достаточно. Потом можно начать анализировать отзывы пользователей и ревью прессы. Потом проводить опросы и исследования.

2) Производительность сервисов и приложений. Время запуска, время обработки запросов, FPS, размер бинарников, количество кликов на задачу и т.д.

3) Качества кода . Статический анализ, процент покрытия тестами, количество зависимостей, процент крэшей и утечек памяти и т.д.

4) Developer Experience/Happiness .
Качество рабочего места сотрудников. Время ожидания билдов и степень автоматизации. Количество овертаймов. Количество выделенных часов на самообразование (в рабочее время), количество выделенных часов на опен-сорс (в рабочее время), количество внутренних и внешних тренингов и отзывы участников и т.д.

Это неплохой стартовый набор метрик. Ими тоже, безусловно, можно манипулировать, но куда сложнее, чем количеством закрытых тасок в джире.

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

Ещё, 50 человек — это вообще ничто. На таком мелком масштабе почти всё можно делать с индивидуальным подходом. По-сути, чтобы перманентно мониторить каждый аспект работы 50-ти человек, вам надо всего около 150 часов в квартал. 3 часа раз в квартал на каждого сотрудника достаточно, чтобы проанализировать каждую его таску в джире и каждый замерженный pull request и обсудит персонально остальную деятельность.
Для этого достаточно пары-тройки PMв, тимлидов и HRв.

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

Система KPI это просто прекрасно. Особенно хорошо она работает на распиле чужих денег(например бонусы гос чиновников, в % чуть ли не от ВВП и прописанные как попало).
Но лучше всего—это пилить бабло на внедрении такой системы. Крайне желательно, чтобы периоды не совпадали с финансовыми.
В таком случае вы уходите от довольного заказчика, который радуется растущим графикам надоев с быка)
В реале сформулировать равновесомые показатели для разных людей невозможно. Годовые цели? Да будьте честны с собой, Вы сами не знаете, чего хотите добиться по концу года. Максимум вектор приложения усилий, и тот меняется.
Подходит достаточно неплохо при обучении и росте до уровня миддла. Тоесть исключительно пока нет уникальности знаний и скиллов. При дальнейшем росте «исключения» похоронят все начинание.

Система неплоха, но надо четко понимать для чего она нужна. Она нужна старшим пацанам, которые требуют «прозрачности» снизу наверх: это 4й пункт в «подведем черту». По остальным пунктам:
— возросла производительность команд
Неудивительно, ибо производительность как раз и зависит от того как ее считают.
— уменьшилось количество сотрудников, которые пытались «увильнуть»
Пардон, это зависит не только от контроля, но еще и от ПМа, тим-лидов и грамотных естимейтов
— пересмотр оплаты труда стал более прозрачным и понятным
А вот это сказка. Зарплата определяется рынком и ситуацией на проекте, и если дев просит «+пиццот» за два месяца до релиза версии, Вы киваете на графики и отказываете ему, он увольняется, релиз гремит ... угадайте кто виноват? я уверен что не система :)

я уверен что не система :)

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

Более того, ширма этой системы не позволит понять реальные причины фейла.

Я ж не сказал — кого назначат виноватым :) Хотя если навернется не только релиз, но и проект, думаю с вероятностью до 90% пострадает ПМ, даже если решения принимал не он.

Нет, если прикроется Системой. Он все делал правильно в соответствие с Системой. За что его наказывать, его поощрять надо.

этот инструмент будет полезен всем компаниям,

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

ЗЫ. Вот так и теряет индустрия сеньеров )))

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

Чем плоха предложенная система?
1. Рост продуктивности команд система показывает используя свои же метрики. Т.е. нельзя понять был ли реальный рост или просто адаптация сотрудников под нее. Например, путем оверэстимейта тасков.
2. Система измеряет не все важное, а то из важного, что можно легко измерить. Как измеряется, например, помощь коллегам в понимании кода? Как учитываются код-ревью (из статьи понятно, что никак)? Количество правок после ревью? Количество переоткрытий бага? Качество кода? (говнокод может отлично и без багов работать, но не поддерживаться и не масштабироваться). В силу этого точность системы вряд ли больше +/- 20%, даже если постулировать, что в остальных частях все идеально (мы мерием и взвешиваем именно то, что нужно).
3. Какие у системы есть предохранители против жульничества? Например, систематических оверэстимейтов по времени выполнения и сложности? Маскировку багов под фичи и наоборот? Заведения нескольких багов вместо одного и наоборот? Заведение нового бага вместо переоткрытия старого и наоборот?
4. Аргументация, что если более продуктивный сотрудник не просит повышения, то менее продуктивному не надо повышать, ущербна по своей сути. Работодатель соревнуется со внешним рынком, а не между сотрудниками внутри компании. Поэтому вопрос повышения завязан на то, что для компании будет дешевле: продолжать удерживать этого сотрудника с зарплатой Х или нанять с рынка с аналогичной продуктивностью учитывая все попутные расходы на хайринг и рэмп-ап и риски. Несправедливость такого подхода также деморализует команду.
5. Для оценки лидов система также не подходит, т.к. оперирует относительными характеристиками. К примеру, в двух командах сменились лиды. В первом случае производительность команды не изменилась. Во втором увеличилась на 30%. Значит ли это, что второй лид лучше? Совсем нет. Возможно первая команда и так работала на 110% и сохранение ее производительности величайшее достижение. Тогда как вторая команда перформила на 50%, а стала на 65%. А в худшем случае новый лид просто пришел и объяснил команде, что нужно просто завышать сложность и эстимейты задач и все будут в шоколаде. Т.е. по факту даже возможно падение продуктивности в то время как процент жиров в масле резко вырос.

Как правильно использовать систему, чтобы было эффективно
1. Повышения зарплат должны быть завязаны на их экономическую обоснованность, а не на сравнительные характеристики сотрудников. Это и эффективно и справедливо. В идеале вообще все перевести в $ и иметь картину: юнит майнит $10000 в месяц, и потребляет $5000. Такой аргумент поймут все. Правда, даже тут могут быть исключения. Если сейлзы с ПМами загнали проект в убыточную зону, то этот аргумент может быть не применим.
2. Результаты мониторинга производительности не должны быть истиной в последней инстанции. Это важный инструмент перформанс-ревью, но не единственный. Нужно включать качественные и субъективные оценки, например, инспекция качества кода внешними (по отношению к команде) архитекторами.
3. Точность системы низка. По сути она такова, что в лучшем случае позволяет лишь сгруппировать сотрудников в группы Low performers, Mid Performers и Top performers. Для сравнения результатов отдельных людей в рамках одной группы она не подходит.

Как правильно использовать систему, чтобы было эффективно

А для этого нужно где-то найти идеальных менеджеров.

Зачем не идеальным (а из костей и мяса) разработчикам идеальные манагеры?
Достаточно — компетентных, как и для всех остальных специализаций.

У неидеальных меняется настроений, субьективные предпочтения и т.п.

Для разрабов это не сильно важно — ибо компу на это все похер.
Для менеджеров важно — ибо работают с людьми, а тем не пофиг.

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

И да. Был один человек, которому удалось что-то в этом плане — Генри Форд. Но у него рабочие должны были тупо крутить каждый свою гайку на конвейере. Сейчас это делают роботы.
Но работа программистов в корне отличается от работы тех рабочих.
Применения подхода Форда мы видим на галерах, но там работники работают хорошо, если на 3-5% процентов своих возможностей в среднем. Да, методами промывания мозгов инфантильную школоту можно уговорить поработать интенсивнее, но в этом случае эту школоту нужно менять через 3-4 года, как поймет, что к чему. Типичный же мидл и сеньор на галере просто не будет напрягаться и работать минимально и хрен ты его заставишь работать интенсивнее. Тут еще срабатывает такой момент, что производительность июня и сеньора может различаться в 1000 раз.

Для разрабов это не сильно важно — ибо компу на это все похер.
Для менеджеров важно — ибо работают с людьми, а тем не пофиг.

Слишком «резкое» разделение. Все люди так или иначе работают с людьми, разнится количество и разнообразие «контактов» ))

Вы и 100500 до вас уже лет 100 пытаются алгоритмизировать и механизировать работу с людьми.

Не обобщай. Я не пытаюсь. И если бы делал (или буду делать), то не «алгоритмически» и не «механически». Я вообще не «механист» и слово «технократ» считаю ругательным.

Был один человек, которому удалось что-то в этом плане — Генри Форд.

Форд просто воплотил «организационную систему».

Но работа программистов в корне отличается от работы тех рабочих.

Нет. С точки зрения организации, не отличается. Программист тоже — крутит гайку, просто делает это не «руками», а внутри «головы». Инструмент нежнее и капризнее, но принципы организации одни и те же. Иначе бы не было бы ни скраму, ни канбану, ни водопаду )))

Есть понятийная разница между «системой» и «ее кривым воплощением».

Если честно, дальше у тебя там «бла бла бла, все умерли». Из разряда «вот раньше... трава была зеленее и июни июнистее». Эмоциональные суждения. Имеешь полное право. Но я соглашаться с ними не буду, где то что то так, а где то иначе, а еще где то — намного лучше, просто «кто то пессимист».

Программист тоже — крутит гайку, просто делает это не «руками», а внутри «головы»

Только все гайки каждый раз разные и более того та же самая гайка чаще всего на то же самое место не закрутиться через 1 минуту уже.
Вот этого понимания почему-то у подавляющего большинства манагеров в ИТ нет. Они все живут во временах Форда.

Слишком «резкое» разделение.

Потому что иначе будет написан просто балшит ни-о-чем. Вот и приходится гиперболизировать.
Ты же сам пишешь

разнится количество и разнообразие «контактов»

.
Вот в этом нюансе и спрятался дьявол.
Более того, компьютер не человек, а программист с ним общается постоянно — это накладывает свой отпечаток на программиста.

Вот этого понимания почему-то у подавляющего большинства манагеров в ИТ нет.

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

Потому что иначе будет написан просто балшит ни-о-чем. Вот и приходится гиперболизировать.

Ну да, если громче кричать, то быстрее объяснишь ))) логичная логика, экономная экономика и так далее ))

компьютер не человек, а программист с ним общается постоянно

Знаешь, это уже что то из медицины однако ))) Я с компьютером не общаюсь, это предмет которым я пользуюсь (и зачастую, более 12 часов в сутки). Голоса в голове... нет, не надо про это.
А если чуть серьезно, то «проблемы общения» (его недостатка или реакция на избыток и прочее) решаются через обращение к психологу. За здоровьем нужно следить, за ментальным — особенно. Я через разные стадии в своей жизни прошел и некоторые из них, не назвать приглядными (и тем более приятными), так что чуть чуть в курсе как оно бывает. А что то и наблюдал в том или ином виде.

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

Готов также работать с программистами?
Вот програмер тебе задача. А в ответ «пошел нах, иди чини свое ДНК и вот тебе простыни из инета, что я думаю о твоем ДНК». Уже на этом этапе ты уволишь программиста.
Благо програмеров не 1 штука, что 10000 в ближайшей окрестности.

эм... а что заставляет тебя считать твой персональный опыт массово релевантным, а не системной аномалией? ))) есть цифры?

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

не довел, а вывел тебя на эту мысль))))

Неа, довел. Но мне дальше не интересно.
Любую хрень, связанную с отношениями между людьми элементарно свести до свести до подобного и после обсуждать нечего.

....не на сравнительные характеристики сотрудников

скажем так: по современным представлениям, это — грубая ошибка. Дева сравнивают не с соседом и не с тех-лидом, а с ним самим в определенный момент раньше (квартал, полгода, год). И только если «сравнение» (как его делать — отдельный срач на стопиццот страниц) показывает отсутствие прогресса, есть основания отказывать... и дарить сотрудника другой компании :)

Это, может, хорошо работает в США, где сотрудника в любой момент можно легко уволить. Для, например, Германии это не применимо т.к. увольнение возможно, фактически, только во время испытательного срока. Да и вообще, это работает только на длительных отрезках времени при условии, что контент работы мало изменяется. Как быть, если каждые полгода-год новый проект? Затем смена позиции?

Это (я про первое предложение, что с чем сравнивать) — аксиома competency management-а, и работает она по всему шарику. Дальше, я ж грю: отдельная тема на несколько диссертаций — как, куда сравнивать. По поводу «что» — речь идет не о некой «продуктивности», а о наборе хард-скиллов плюс софт-скиллы.

это работает только на длительных отрезках времени при условии, что контент работы мало изменяется

Как раз наоборот: если контент работы НЕ изменяется, специалист мало развивается непосредственно на проекте.

Ну так а как трэкать изменение перформанса человека со временем, если состав работы постоянно меняется? Полгода назад он закрывал 20 стори поинтов за квартал в команде А, сегодня он фиксит 4 бага в неделю в команде Б. Какие выводы можно сделать об изменении его перформанса за последний год?

Сергей, перечитайте внимательно пост вверху, пожалуйста; там где «по поводу что». «Трекать перформанс» — это к представленной ТС системе, а в competency management-е сравнивается компетенция, грубо говоря знания и умения человека, допустим раз в полгода. Поменял команду — значит с большой вероятностью научился чему-то новому, и это должно вылезть на свет Божий при «сравнении».

Ок, но а при чем здесь это, если вся статья о замерах перформанса, а не компетенций.

Если посмотреть вверху на Ваш пост и мой ответ, то я з доброго дива :) поддержал Вашу мысль:

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

и добавил, что сравнивать сотрудников — это по современным понятиям смертный грех :) Вы почему-то решили, что я с Вами спорю.

Так я не согласен, что сравнивать разных сотрудников — это смертный грех :-)
Поэтому спорю с вами (а не думаю, что вы со мной спорите).
Это можно, если нет абсолютной величины для сравнения. Само собой, эти люди должны выполнять похожую работу в похожих условиях. Само собой, что лучше иметь абсолютную планку. Но очень часто (если не «как правило») это невозможно.

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

Может это к немцам конечно и не относится, но нармальный пардон чел в таких условиях часто забивает на конкуренцию по двум причинам: (а) он и так самый лучший, и «нас не догонют» (б) у него все равно нет никаких шансов догнать [например Месси и Роналду, и получить Золотой мяч]. А вот если человека сравнивать с самим собой — тут оба варианта вряд ли возможны. Работник не уязвляется таким сравнением, в этом смысл.

эти люди должны выполнять похожую работу в похожих условиях.

Как — и зачем!? — Вы сравниваете двух работников, если один из них неженатый мужик, а вторая — кормящая мать? но тот первый мужик, например, глух? или аутист? [я не фантазирую, это реальные случаи из моей практики].
Давным-давно, я учился по книге Генри Форда My Life & Work. Там есть мысль: если у меня есть сотрудник, который на все 100% и всегда со мной согласен, то один из нас лишний. Т.е. можно конечно трактовать так, что Генри Форд довел теорию сравнений до необходимости увольнений двойников :) но ИМХО имеется в виду, что все люди и как люди и как специалисты разные, и нет смысла их равнять и искать похожих.

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

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

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

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

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

Аутист и мать-одиночка работают на одном и том же проекте — ? Если Вы считаете, что у них личные условия различны, то — с кем же персонально их сравнивать в таком случае?

Сравнивать текущего хэда с предыдущим можно только если условия их работы существенно не менялись.

Допустим все продержались по полгода :) , т.е. условия существенно не менялись. Допустим шеф оперирует только рабочими качествами. Тогда его замечание, что Ваш предшественник в отличие от Вас ни разу не опоздал на колл, уместно? в такой форме?

сравнение должно идти по рабочим качествам

И подошли к главному вопросу: как сравнивать. Если это будет делать условный шеф, то он вполне может быть уверен, что любофь к работе, любофь к его персоне и кохве в постель — как раз куда более важные рабочие качества, чем овладение какими-то системами менеджмента.

...сравнивать надо не с конкретным сотрудником, а со средним показателем всех, кто делает то же в тех же условиях.

И тут Вы идете против мирового тренда :) CM предполагает ранжирование и подробное описание обязанностей в job profile-ах. И если мы хотим повесить на человека лейбак типа «синьор», мы его сравниваем с виртуальным пацаком, который все эти обязанности из профайла выполняет на 100%, а не «в среднем». А если мы хотим трекать как чел растет над собой, тогда сравниваем с предыдущими «замерами». Мерилом как правило выступают тесты. Хотя у них есть много недостатков, они все же хотя бы создают иллюзию обЪективности. Либо мнение эксперта(тов), но последнее — более дорогое удовольствие.

Аутист и мать-одиночка работают на одном и том же проекте — ? Если Вы считаете, что у них личные условия различны, то — с кем же персонально их сравнивать в таком случае?

Не надо смешивать личное с рабочим. Вообще не важно что у человека дома, важно что он делает по работе. Что аутист, что мать одиночка на одинаковой позиции и зарплате должны выполнять одинаковый объем работ. За пределами работы могут быть кем угодно и заниматься чем угодно. Равное вознаграждение за равный труд это единственная социальная справедливость.

Допустим все продержались по полгода :) , т.е. условия существенно не менялись. Допустим шеф оперирует только рабочими качествами. Тогда его замечание, что Ваш предшественник в отличие от Вас ни разу не опоздал на колл, уместно? в такой форме?

Здесь 2 ошибки.
1. В данном случае сравнение неуместно, т.к. для шефа существует абсолютная метрика — допустимо 0 опозданий за полгода. Сравнения имеет смысл делать, если этой метрики нет.
2. «Рабочие качества» и перформанс — разные вещи (см. ниже). Сравнительный анализ применим к перформансу, но не к рабочим качествам. С небольшими исключениями всем вообще должно быть все равно какими компетенциями и качествами обладает человек. Важно, какой продукт он производит на рабочем месте.

И подошли к главному вопросу: как сравнивать. Если это будет делать условный шеф, то он вполне может быть уверен, что любофь к работе, любофь к его персоне и кохве в постель — как раз куда более важные рабочие качества, чем овладение какими-то системами менеджмента.

Признаю, я неверно выразился, не «рабочие качества», а «результаты работы». Если шеф официально вобьет кофе в постель в перформанс-менеджмент систему или задокументирует это во время перформанс ревью, то с ним можно, судиться. А с конторы. которая такое допускает над валить. Если не вобьет, значит оценка производилась субъективно и непрозрачно и именно объективизация оценки перформанса эффективно с этим борется. Так что тут вы подтверждаете необходимость измерения перформанса :-)

CM предполагает ранжирование и подробное описание обязанностей в job profile-ах. И если мы хотим повесить на человека лейбак типа «синьор», мы его сравниваем с виртуальным пацаком, который все эти обязанности из профайла выполняет на 100%, а не «в среднем».

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

Не надо смешивать личное с рабочим.

Это не я мешал :), я спросил. А Вы так и не ответили: что делать с большим количеством исключений в Вашей системе. С людьми, которые на разной работе и в разных условиях, и которых сравнивать вроде как и нельзя.

Равное вознаграждение за равный труд это единственная социальная справедливость.

Если Вы это серьезно, то становится понимаемо почему Вы против компетенси менеджмента :) - «все люди изначально равны», да? Но допустим сроки горят, а одна тестерша ушла в декретный, замену Вы нашли, но кандидат прознал о Ваших трудностях и просит на 50% бОльшую зарплату. Вы будете думать про социальную справедливость, или все же про «экономическую обоснованность», как Вы это утверждали днем раньше:

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

Сори, Вы опять сЪежжаете :( Факт в том, что такие сравнения, по перформансу или по чем бы то ни было, неприятны для любого человека. Т.е., как и КРІ, Ваша схема удовлетворительно работает только при условии, что до работника результаты сравнений не доводятся.

Важно что человек фактически делает на рабочем месте (результат), а не что он умеет...

Значит, Вы еще не наступали на «дурака с фантазией». Во-вторых, человек может не уметь-не знать-не мочь делать чего надо, и перформанс его будет близок к нулевому. В то время, как на проекте, где его знания востребованы, и перформанс будет высок.
И я конечно не утверждаю, что перформанс менеджмент не нужен. Нужен, но его оценочные суждения субЪективны по его природе, и никак иначе. Точно так же нужна оценка софт-скилов, и в идеале ИМХО эти две субъективные оценки дополняют ± обЪективную оценку компетенции человека.

Идея конечно американская, родом из НАСА, Боинга и какого-то из Дженерал...-не-помню-точно, требует бабла и выросла в т.ч. из матричной системы руководства, с которой у меня свои счеты :) Но мне чессгря странно, что есть мультинациональные конторы, которые ее напрочь отвергают.

Я не буду продолжать этот спор. Вы сами придумываете утверждения, приписываете их мне, затем опровергаете, а мне на все это нужно отвечать? Не интересно.

Я Вам придумываю тест-кейсы. Вам, как Head QA, уже не интересно их проходить. Успехов в построении социализма.

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

«Поздравляю вас, гражданин соврамши!», еще раз. Смотрим выше.

...отрицая необходимость перформанс менеджмента

На самом деле: «я конечно не утверждаю, что перформанс менеджмент не нужен. Нужен, но его оценочные суждения субЪективны по его природе, и никак иначе»

Коммунизм строите как раз вы...

На самом деле, это Ваши слова: «Равное вознаграждение за равный труд это единственная социальная справедливость.» Сравните плз: «Социальная справедливость воплощена у нас в ... равном отношении к средствам производства, в таких фундаментальных ценностях, как равное право на труд и его вознаграждение...», М.С. Горбачев, пленум ЦК КПСС,1987 г.

...притягиванием социального положения к рабочим вопросам.

на самом деле, я Вас спросил: «Как — и зачем!? — Вы сравниваете двух работников, если один из них неженатый мужик, а вторая — кормящая мать?..»

Сергей, надергать у Вас противоречий — плевое дело. Закончили спор — заканчивайте плз.

Нужно включать качественные и субъективные оценки

правильно говорить — оценка на основании выводов нейронной сети )))

все ж таки вирішив написати... не витримав :)
дещо про KPI:
1. це найбезглуздіша система та ідея
2. вона приносить надто багато шкоди і жодної користі
3. на заході в нормальних конторах давно відмовились від цього дебілізму з багатьох причин (основні це падіння фінансових показників — зменьшується чистий прибуток але значно виростають витрати)
4. сабж придумали ейчари для виправдання своєї круті та свого існування, щоб нічого не робити і корчити з себе крутих
5. ейчар що «топить» за сабж повинен бути четвертований або хочаб на дибу посаджений.
всі камменти ейчарів в топку бо вони самі знають що сабж нікуди не годиться але виправдаати себе та створити уяву крутості все ж хочеться.

Вы правы. Но тут как с демократией. Демократия плоха, но какая есть альтернатива? Какая есть альтернатива KPI? Исключительно субъективная оценка?

Исключительно субъективная оценка?

Да.

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

Если оценщик мотивирован интересами компании

И вот полился балшит.
Нет такого «интересы компании», просто нет.
Есть интересы конкретных людей, иногда они частично совпадают иногда противоположны. Более того эти интересы постоянно меняются.

Поэтому я и ответил тебе «Да», на субъективность. В этом случае хотя бы честно и субъективно принимаешь решения, а не пытаешься спрятаться за фиктивными циферками и красивыми графиками и снять с себя отвественность.

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

А это уже другой вопрос и тут я с тобой согласен. Да, многие цифры — это помощь для принятия субьективных решений. Это лучше, чем угадывать случайно.
И если собирать цифры, что помогают принимать решения для достижения своей личной цели, то все ОК.

Если оценщик мотивирован интересами компании ...Но как часто это так?

Наворачивать систему KPI, потому что оценщик играет против компании — это лечение подорожником перелома.
Корневая причина — это отсутствие доверия к оценщику. Надо сменить или оценщика или отношение к нему.

Доверие кадрам — это ключевой вопрос.

Если оценщик не мотивирован интересам компании, то что ему мешает подделывать результаты?

Критерии оценки производительности и качества интеллектуального труда на данном этапе развития цивилизации невозможно формализовать.

Поэтому даже есть «закон» (к сожалению, не могу вспомнить автора): при введении метрики оценки производительности сотрудника он всегда найдет такой способ работы, который максимизирует метрику и при этом минимизирует свои затраты на достижения максимальных показателй. (В другом варианте — максимизирует метрику и минимизирует пользу для компании).

Критерии оценки производительности и качества интеллектуального труда на данном этапе развития цивилизации невозможно формализовать.

плюсую! :)

що до іншого то про яку довіру може бути мова коли оцінююи підрозділ зверху приходить вказівка: 10% повинні бути жорстоко наказані і виглядати погано щоб «поставити на вид» та посоромити перед всіма. А соромити немає кого навіть якщо докопатись. У мене була ситуація коли мої підлеглі в прямому сенсі слова рятували компанію і у кожного за рік був як мінімум один такий випадок. Кого соромити і що це взагалі за підхід?! Людина повинна не боятись покарання а радіти розвитку та успіхам. а ці пострадянські замаашки катять тільки для піонерського табору.

Власне стикаємось з цим в великих компаніях , коли топ-менеджмент не знає навіть чим займається контора... отже і маємо кіпіаї, ще якісь дичину. Там де компанія невелика (умовно до 100 людей) то там більш щільне спілкування і ті кіпіаї нікому не треба, керівники є мабуть найкращими оцінювачами

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

Корневая причина — это отсутствие доверия к оценщику. Надо сменить или оценщика или отношение к нему.
Доверие кадрам — это ключевой вопрос.

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

Если оценщик не мотивирован интересам компании, то что ему мешает подделывать результаты?

Для этого существуют КПИ более высоких уровней. И если вверху показатели плохие, а внизу хорошие есть повод провести более глубокое исследование и докопаться до сути.

Критерии оценки производительности и качества интеллектуального труда на данном этапе развития цивилизации невозможно формализовать.

Не невозможно, а трудно. И это не значит, что не нужно стараться это сделать. Везде, где можно, нужно субъективные критерии объективизировать. Главное — трезво оценивать применимость модели и последствия ее применения.

Поэтому даже есть «закон»

Конечно, поэтому КПИ надо ставить таким образом, чтобы они максимально отражали пользу для компании.

на привеликий жаль Ви праві в тому, що дуже не часто такі люди у керівництві і часто менеджер середньої ланки займається не роботою а виконує роль профсоюза і бігаєвибиває людям адекватну зп. можно довго гадати ому так але вважаю що це пережитки совка, некомпетентність топкерівництва, розрив між керівництвом і виконавцями, низька повага до співробітників.

Так почти везде. Тот же принцип «я начальник, ты — дурак» отлично работает и в традиционных немецких компаниях и в корпорациях с американскими корнями.

Но тут как с демократией.

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

Согласен с вами полностью. Я, наверное, не совсем верно выразился. Под KPI я имел в виду ведение любых измерений, связанных с работой и формировании на их базе выводов относительно перформанса. Сама эта идея, как и демократия, пока достойных альтернатив не имеет. В ней самой нет ущербности. Именно это я имел в виду.

А вот непосредственное применение как KPI, так и демократии может существенно отличаться. И обреать разные формы от вполне приемлимой до уродливо-катастрофической. В Украине демократия, в США — тоже. Даже в России и в Белорусии официально демократия. Но есть нюанс.

я имел в виду ведение любых измерений, связанных с работой и формировании на их базе выводов

Big Data, если уж называть своими именами. И можно без Биг. И для этого давно есть название: PDCA («планируй — делай — проверяй — воздействуй»), или PDSA («планируй — делай — изучай — воздействуй»), если по Демингу. KPI это один из методов для «проверяй/изучай», применять который нужно мозгом, а не в режиме карго.

Big Data и PDCA это вообще ни при чем. Они могут быть связаны с КПИ, но это не одно и то же.

я не кадровик і скажу що альтернатива це мабуть інд. підхід + премія за фін. результатами роботи. У ввсякому разі ціі схеми показують дійсно свою ефективність. на 100% всі задоволені небудуть, в колективі завжди є люди які як в тому анекдоті про сірникі — то у вас 59 то 60 сірників в коробочці.

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

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

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

OKR это те же KPI, только названы по-другому. Так что это не альтернатива. Вся прожарка «новомодного» решения здесь: dou.ua/...​/articles/5-okr-mistakes

Нет, это не тоже самое. Об этом и говорится в статье.

Другого ответа от эджайл-коуча я и не ожидал )))

Ну разумеется)))) Там, в статье, много чего интересного, что сразу отличает KPI and OKR, например фраза «70% и более целей установлено „снизу вверх“;». Есть же разница в позициях — снизу или сверху?))))

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

Дано:
1. У компании есть Обжективз, которые отражают главное, чего она хочет достичь на ближайший период (или больше).
2. У сотрудника есть спущенные сверху Обджективз, которые отражают Обджективз компании.
3. В компании есть процесс перформанс ревью.
4. Согласно идее ОКР, их выполнение не должно быть привязано к вознаграждению (чтобы избежать проблемы КПИ, когда все улучшают КПИ, а не продукт).

Складывая эти 4 утверждения, получаем, что:
Оценка работы сотрудника и связанный с этим пересмотр компенсации, промоушена и т.д. происходит по каким угодно аспектам работы, кроме тех, что связаны с самыми важными задачами компании. Очевидно, что сотрудник будет с наивысшим приоритетом заниматься тем, что важно для пересмотра компенсации. Т.е. задачами не связанными с главными задачами компании. Т.е. введение ОКР саботирует выполнение главных целей компании.

Вот как разрешите этот парадокс, тогда я готов буду дальше разговаривать про снизу-вверх, сверху-вниз и справа-на-лево.

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

это не штуки, а инструменты, которые могут быть использованы «правильно» и «нет», которые могут быть «подходящими под условия применения/ситуацию» и «нет», которые могут «иметь хорошую реализацию» или «кривую» и так далее.

Всі ці системи або їх переважна

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

это не штуки, а инструменты, которые

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

это крайне глупое обобщение.

ви явно представник близький до кадрів :)
я не буду сперечатись бо немаю бажання, пережив тих кіпіаїв і систем і знаю що вони не працюють на користь.

Ну ну. «все в жизни видел, можно и помирать» ))))

то була метафора, как описание типажа )))

«сложный», кстати, типаж... внедрять какие либо изменения с таким человеком/людьми — только за отдельно большие деньги.

«сложный», кстати, типаж...

якщо Ви про мене то помиляєтесь. складним" типажем вважають той типаж який не вписується під якісь фантастичний стандарт кадровиків, а їм всі люди не такі. :)

только за отдельно большие деньги.

ці гроші краще заплатити людині за роботу або збільшити соцпакет за рахунок цього бюджету і це буде набагато ефективніше. А поки це нагадує старий анекдот — Батьку, я вилікував Мадам ххх яку ти та дід лікували 50 років! Ну і дурень за рахунок її хвороби у нас у всіх будинки, освіта, машини, яхти... :)

Мне понравилось. Система обязательно должна быть внедрена на всех галерах.

Почитав дискуссію у коментарях.

Думаю, що автору трохи не вистачило висновків і вступу.
Інструтент складний, бо орієнтований на багато внутрішніх замовників.

1. Керівництво хоче знати чи переплачують вони співробітникам і наскільки.
2. Співробітники хочуть розуміть чи буде у них премія та річна надбавка і як їх отримати.
3. Рекрутери хочуть бачити чи схильний співробітних піти з продуктової компанії.

Наприклад ось швидкі відповіді («у звичайномупроекті роблять так ...»):
1. Замовити чи купити дослідження ринку праці по місту / країні. (навіть на ДОУ є просте опитування, щоб зорієнтуватись)
2. Сформулвати 1-3 пріорітети (фічі, інтергаціх) на рік для кожного співробітника. І мініум поточних задач розв’язаних на місяць.
3. Спостерігати на мітінгах чи за обідом, що людина не подає ідей, критикіє чужі, веде себе деструктивно.

Тепер можемо порівняти ці дві системи і приймати рішення про впровадження:
а) наскільки більш точна інформация від запроповованої системи?
б) наскільки ця точність критична — я якісне покращення знанні про ринок і колектив, а також задоволенності співробітників прозорісстю КПІ?
в) скільки часу (грошей) треба для підтримання цієї системи у рамках організації?

На якому періоді часу проведено експеримент? (Хоча б рік минув)
Скільки часу зайняло впровадження? (Інталяція, тюнінг параметрів, навчання користувачів)

Ну і класичні проблема будь яких КПІ:
— що міряємо — те люди і нарощують, причому дуже творчо :) з мініумом зусиль
— якщо показників стає забагато, то люди припиняють паритися взагали. Занадто складно цілеспрямовано впливати на премію/підвищення

«скільки часу (грошей) треба для підтримання цієї системи у рамках організації?» — сбор данных организован автоматически. Если не выделить место для системы с учетом роста данных и не добавлять критериев и др. функционала, то просто использование, как и любой тасктрекинговой системы.
«На якому періоді часу проведено експеримент?» — Данные для тула собираются постоянно, выборка данных больше года.
«Скільки часу зайняло впровадження?» Внедрение проводили на своем отделе, теперь на очереди другие ... так что можно сказать, что полное внедрение еще не завершено. Так же как и еще не проработан весь возможный функционал данной тулы.

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

Требования к позициям формировалась лидами соответствующих команд и утверждалось у руководства. На первом слайде приведены «статические критерии» на основании, которых формировалась дельта для каждого из уровней (junior QA, strong junoir QA .. и т.д. так же для dev- ов) .Так же это можно увидеть и на последнем слайде «уровень начинается с 683» и «Текущее значение ». Переоценка знаний/уровня/компетенций производится регулярно см. первый слайд «список точек переоценки». Возможно не четко видно на слайдах...

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

Критически отношусь к измерению производительности в отрыве от оплаты и рыночной ситуаци, по таким причинам.
1. Нет каких-либо абсолютных единиц, дескать этот делает пять попугаев в день — этот десять поэтому можно сравнивать только с другими людьми работающими на одном и том-же оборудовании
2. В АйТи и людей сравнивать нельзя и вот почему: есть джуниор, работает за $500, овертаймит, глаза горят. И есть я, делаю работу которую не могут другие(иначе меня не берут), глаза не горят, проект вертел на одном месте, стою в час как хороший джуниор, почти миддл, в день(или больше). Кто из нас производительней?
3. Зачем эта производительность вообще? Что она даёт? Имхо, ответ на вопрос: кому повысить, зарплату — кого уволить. Чтобы ответить на него нужно понять могу-ли я взять с рынка труда работника лучше, но на те-же деньги и сколько мне это будет стоить(найм тоже не бесплатный)?

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

1. мы используем набор критериев с весовыми значениями. Критерии можно добавлять, чтобы оценка была более «адекватной».
2. у каждой медали две стороны... «горят глаза», овертаймит и плюс к этому делает в каждой задаче по 10 багов на исправление которых уходит x*2 времени, не вкладывается в свои эстимейты и не может делать задачи средней сложности и есть мидл, который без «горящих глаз» выполняет простые задачи, средней сложности задачи и делает по 5 багов на исправление которых тратиться x времени.
Как лид команды /менеджер /владелец компании, кого ты будешь ценить больше?
3. чтобы про вот такого сотрудник с потенциалом к росту и «горящими глазами» не забыли и поддержали его, отметили и помогли.

Ты опять попытался их сову натянуть на себя.
Это система для галер. Инструмент погонщикам, чтобы погонять гребцов сильнее.

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

Как говорит американская поговорка: «Из свиней добывают сало, а из людей деньги».

Где продуктивность PM-a? Чёт не нашёл...

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

Как измерить реальную продуктивность сотрудников

никак

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

Интересно — а есть фидбек от самих сотрдников?

Если гребцам не нравиться, то их никто не держит. Да и на соседней галере +500.

Да, и как этот фидбек учитывается.

Судя по 70 балам в рейтинге jobs.dou.ua/companies/devart/poll «Я получаю обратную связь о своей работе», что-то пошло не так...

Насчет продуктивности спорить не буду, а вот репродуктивность вполне измерима.

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

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

KPI просел из-за того что разработчик занимался ревью? что за ерунда?

сколько я видел KPI систем, у все одни и еже проблемы
— система не прозрачная
— формулу расчета никто тебе не даст
— нельзя смотреть KPI других сотрудников (а на многих еще она и не распространяется, дада, некоторые равнее)

кто сторожит сторожей?

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

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

Есть гипотеза что при введении любых KPI сотрудники начинают страться улучшать их а не продукт.

если эти KPI не рассчитаны на улучшение продукта ;) и не модифицируются.

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

Вы не указали самое главное условие работоспособности KPI: сотрудники не должны быть с ними ознакомлены. А в этом случае автоматически теряется рекламная фишка «прозрачности».

Есть анегдодтический прецедент когда гребцам Амазона ввели KPI «количество принятых звонков». Закончилось жалобами клиентов, что практически каждый второй звонок на Амазон обрывается :) Именно мнение клиента есть ИМХО единственный критерий «успешности» работы команды. А для девов остается суммарное мнение ПМа, техлида, тимлида и пр. В кавычках потому, что «успешность» вовсе не равняется «продуктивности».

Спасибо за статью! Не совсем понятно — как собственно считается производительность сотрудника, что на оси Y?

как собственно считается производительность сотрудника

да как обычно, наверно — собираются менеджеры и www.youtube.com/watch?v=sCq-Lo6NbK4

Оперируя такими показателями как: сложность задач, количество задач, скорость выполнения задач, количество багов по задаче, и другие, можно получить так называемый «индекс программиста». У QA показатели другие, у TW показатели тоже свои.

Формулу в студию :)

сложность задач, количество задач, скорость выполнения задач

Стимулирует оверэстимейтить и «подкручивать метрики» же, особенно когда некий старожил может продавливать свои эстимейты и брать на себя определённый круг задач всегда. Может вообще привести к некоей круговой поруке кода круг людей будет мутить с этими метриками как угодно. Фактически система будет карать за честность и поощрять мутки.

количество багов по задаче

Стимулирует скрывать баги под «импрувментами», фиксить в обход трекера задач и подобные вещи.

сложность задач, количество задач, скорость выполнения задач

Вот так, одним движением можно поиметь весь скрамо-аджайл.

количество багов по задаче

Да-да. Помню такое — в одной конторе был прямой запрет заводить дефекты в треккере, что бы не портить KPI.

Можно конечно догадаться по фразе "

complexity, business value

" и скриншоту. Тогда сразу еще один вопрос — не создается ли при этом ситуация что все хотят брать задачи с самыми высокими значениями complexity и business value? Кто и как разруливает — вот ты Вася крут — бери вот это а ты Петя бери это и не выделывайся?

с самыми высокими complexity взять можно, а вот сделать далеко не всегда :) . У нас существует система правил кто и какие задачи и какой сложности может взять в спринт. Перескочить конечно можно но не на несколько порядков. Например предполагается, что junior может взять задачи с «complexity» от 1 до 3 и сможет без особых проблем их выполнить, если он берет задачи 4 −5 он должен об этом сообщить так как есть вероятность того, что он может с ними не справиться.
Работа по scrum предполагает решать кто и какие задачи берет самой команде.

Тут согласен. Но если уже говорить о Scrum — в нем нет понятия Junior или Senior

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

Есть два бекенд программиста:
один боженька в связывании бекенда и фронтенда
второй в работе со структурами апи и сторонними сервисами

как их вы посчитаете?

А третий ещё и с инфраструктурой работать умеет и тюнит перформанс какого-нибудь tcp стека на вмке.

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

Прикольно! У нас похожий софт есть, правда перформанс там анализируется для всего проекта, а не его отдельного члена.

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

Подписаться на комментарии