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 компании. Этот уровень позволяет просматривать «личную карточку сотрудника» и модифицировать её, а также динамическую оценку выбранного сотрудника за выбранный период.
  • Менеджмент. Этот уровень аналогичен уровню «администратора» и имеет доступ ко всей информации системы.

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

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

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

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

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному5
LinkedIn

Схожі статті




Найкращі коментарі пропустити

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

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

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

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

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

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

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

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

никак

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

146 коментарів

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.

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

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

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

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

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

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

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

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

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

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

я так смотрю не только у меня есть «прекрасный» опыт работы с девартовскими продуктами :)))
прошлым летом пробовал девартовские компоненты для SSIS что бы грузить данные в BigQuery. печаль-тоска. суппорт в принципе относительно оперативно отвечал, но часть ответов-советов такое ощущение что писал человек мягко говоря недалекий. В общем неюзабельные компоненты были, мягко говоря сырые. правда дешевые :))))
справедливости ради, я тогда пробовал компоненты 4-х различных компаний (включая деварт) и только у одной компоненты работали нормально и можно было без мата использовать в продакшине. правда раза в три дороже чем девартовские
но вообще, судя по написаному в этой статье становится понятно почему такое убогое качество было у компонентов
https://******.it/2020/02/21/devart-review/

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Это (я про первое предложение, что с чем сравнивать) — аксиома 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? Исключительно субъективная оценка?

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

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

Чьи интересы на ваш взгляд должен представлять Project Manager, нанятый компанией управлять процессом разработки?

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

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

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

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

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

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

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

плюсую! :)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

И согласно «закону», любой КПИ будет взломан ;)

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

Их миллионы.
— Наверное, самый первый — это законы Хаммурапи. Фиксация обычаев и правил в более объективной форме — записанные законы. Тут, на всякий случай уточню еще раз, что речь не идет о 100% объективизации, которая невозможна в принципе, а о том, что большая объективизация, как правило, дает лучший результат и к этому надо стремиться. Также любые законы и правила.
— «Security analysis» by Benjamin Graham — объективизация подхода к оценке ценных бумаг, которая принесла очень много денег как самому автору, так и его ученику — Уоррену Баффету. Также миллиардные состояния принесла объективизация критериев отбора объектов инвестирования и выбора времени Рэю Далио, Джим Симмонс
— Подбор игроков у Лобановского или у Билли Бина
Как видим, в каждом случае объективизация приводила к серьезному прорыву.

Есть и обратные примеры. Когда объективные критерии игнорировались в угоду субъективным
— Вычисление сроков начала ВОВ (по объективным критериям, таким как график захода немецких кораблей в советские порты, начало войны предсказывалось с точностью до дня. Но эти объективные факторы игнорировались Сталиным и его окружением в угоду субъективному убеждению, что Гитлер-братюня, главный враг — Британская Империя, а Сталин всех переиграет)
— Нападение Японии на США в 1941 (объективные факторы как соотношение промышленного и научного потенциала уступило субъективной оценке «небойцовского» характера американцев)
— Экономический кризис 2008 года
и т.д.

И согласно «закону», любой КПИ будет взломан ;)

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

Конечно. Зубов бояться.. в лес не ходить :-)
Вот только альтернативы нет. Если цели не выставить, то провал будет в 100% случаев, а так есть шансы.

Твои личные домыслы неподтверждающиеся нигде. Все компании входящие в тот же Fortune 500 имеют конкретные, измеримые цели.

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

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

законы Хаммурапи
Также любые законы и правила.

Только это не KPI.

У «преступления» 2 состояния — совершено/не совершено и т.д.
Тогда как KPI — это показатель «больше значит лучше».

Security analysis

Компании в целом вполне себе описываются с помощью KPI — выручка, прибыль и т.п.

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

Уточню, что имел ввиду.

В посте шла речь о показателях на конкретной позиции.

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

Для производства достаточно легко — «100 втулок по ГОСТу за смену».
Для продавцов тоже — «1М продаж в месяц».
Или «100 лидов в месяц» для маркетолога.

Но вот практически невозможно получить «интегральные показатель ох**ности разработчика».

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

Аналогично с тестировщиками, дизайнерами, аналитиками, копирайтерами и т.д.

Максимум — это формально описать критерии «явно плохо», своего рода «стандарты качества».

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

Поэтому и существует альтернативная стратегия — пытаться укомплектовать максимально качественными кадрами, которые мотивированны на достижения, ставить им прозрачные цели и не мешать им со всякими отчетами и KPI ;)

Только это не KPI.

Я и не говорил что это KPI. Здесь уже речь шла о том, что объективизация критериев оценки всегда полезна. И, по просьбе комментатора, я привел примеры успешной объективизации критериев. Следите за обсуждением ;-)

Но вот практически невозможно получить «интегральные показатель ох**ности разработчика».

Возможно. А главное, что к этому нужно стремиться, а не забивать болт даже не пытаясь. Не стоит переоценивать творческую составляющую работы разработчика. Она велика и сложно измерима. Но это означает неточность оценки, а не их принципиальную невозможность. Я, собственно и озвучивал мысль, что метрики могут помочь разделить сотрудников на 3 категории — low performers, mid performers и top performers. На большее они не способны.

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

1. Потому что менеджер может не разбираться во всех аспектах работы сотрудников. К примеру, менеджер из девелоперов редко разбирается в том, что значит правильная и эффективная работа тестировщика.
2. Direct manager (т.е. именно тот, которому все должно быть очевидно) не всегда имеет право принимать кадровые решения в отношении сотрудника. Как правило это право делегировано на уровень (а то и два-три) выше, где это уже не очевидно. Когда Direct менеджер приходит к своему начальству с просьбой уволить/перевести/понизить и т.д., то, вполне логично от него требуют каких-то объективных доказательств. Т.е. метрик.

Поэтому и существует альтернативная стратегия — пытаться укомплектовать максимально качественными кадрами, которые мотивированны на достижения, ставить им прозрачные цели и не мешать им со всякими отчетами и KPI ;)

Да. Но выполняется оно только в FAANG, ну, и, может, еще десятке компаний, которые могут себе позволить таких сотрудников. Хотя и там есть перформанс ревью, KPI (которые названы OKR) и прочие атрибуты погонщика ;-)

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

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

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

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

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

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

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

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

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

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

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

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

Если быть более точным: субъективно кто-то решил, что система с КПИ описанная выше должна быть «такой»
К этому уже есть достаточно большой вопрос «Почему?»
Приведу простой пример как подобный подход НЕ работает: соционика «у людей есть 16 типов. они взаимдействуют следующим образом:...», «астрология: у людей есть 12 знаков, люди с определенным знаком ведут себя следующим образом:..»
Свести это все к КПИ описанному в статье или пример достаточно прозрачен?

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

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

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

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

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

бег на 100 метров -> прыжки в воду -> фигурное катание -> экономическая деятельность.

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

Короче. Вот просто. ПРУФЫ к этому примеру? У твоего оппонента не буду спрашивать, хотя вопросы тоже есть. Но у тебя присутствует четкое ранжирование. Можешь объяснить нормальным людям на основе чего оно взято? например от последнего пункта и итога я выпал в осадок на пару минут

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

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

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

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

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

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

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

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

4. Согласно идее ОКР, их выполнение не должно быть привязано к вознаграждению (чтобы избежать проблемы КПИ, когда все улучшают КПИ, а не продукт).

felipecastro.com/...​ate-okr-and-compensation

Правильная система мотивации учитывает влияние вклада конкретного сотрудника на компанию в целом.

Поэтому вознаграждение все-таки привязано к OKR компании.

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

То есть привязано. А значит один из основных постулатов ОКР и основное их идеологическое отличие от «контрпродуктивных KPI» по факту не выполняется. Вот поэтому и говорю, что разницы между ними почти нет ;-)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ці гроші краще заплатити людині за роботу або збільшити соцпакет за рахунок цього бюджету і це буде набагато ефективніше. А поки це нагадує старий анекдот — Батьку, я вилікував Мадам ххх яку ти та дід лікували 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? Чёт не нашёл...

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

никак

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

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

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

Есть. Даже несколько. На сайте ******.it (Я сюда какраз оттуда по линкам в коментах попал)

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

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