Дек. 03

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

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

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

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

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