Перформанс — это результативность команды. Начиная с этого места понятийный аппарат разваливается. Чтобы измерять результативность, нужно знать какую-то метрику. Метрика «строчки кода» определённо не подходит, а метрика «готовые фичи» измеряет продуктолога или команду, а не индивидуального разработчика. И вот этим «чем-то» ещё нужно управлять. Логика в том, чтобы разработчик разрабатывал нужное и с понятной скоростью, чтобы на него можно было полагаться в задачах.

Управлять можно, например:

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

Например, хорошие метрики, следующие из этого — это доступность сервиса, максимальное время ответа сервиса, размер техдолга (хотя его тоже сложно измерить), процент покрытия автотестами и так далее.

Но вы не управляете даже этим! Этим всем управляет сам разработчик. Вы же управляете тем, как он понимает текущую ситуацию с компанией, продуктом, командой и своим развитием.

Собственно, вот эта тонкая грань и есть перформанс-менеджмент.

Управление результативностью

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

1. Попытаться сопоставить размер «хотел сделать» с реальностью. Часто получается так, что разработчик хочет сделать всё и сразу, и вначале это выглядит реалистичным. Но по мере погружения в глубь задач всплывают совершенно неожиданные издержки и проблемы. Да, senior+, наверное, оценивает всё более-менее реалистично и повидал всякое. А вот для остальных грейдов, скорее, важно попросить сделать меньше, но доделать, чем много, но на 30%. В реальном мире разработчики, у которых всегда 10 задач, на 90% не дают результата, а разработчики, у которых 1 задача выполнена к концу каждого спринта — дают этот результат. Можно управлять тем, что человек не рассыпает свою фокусировку на разные цели.
2. Можно управлять тем, что разработчик непосредственно делает. Речь не про стояние у него за спиной, а, скорее, стандарты. Например, что считается хорошим ревью, какой код можно отдавать тестировщикам, а какой ещё достаточно сырой и так далее. Тут всё может печально кончиться какими-то довольно плохими KPI, что демотивирует, но гораздо важнее корректировать способ решения той или иной проблемы. Про это будет чуть ниже.

Основной цикл управления результативностью выглядит так:

1. Формирование ожиданий: каких результатов сотрудник должен достичь, как это будет измеряться и какие компетенции нужны. Вы разговариваете и обсуждаете, что человек будет делать, как будет это делать и не нужно ли ему что-то ещё подучить. Идеальная ситуация — ожидания человека сопоставляются с тем, как это представляет руководитель, плюс появляется какой-то план развития, куда копать в собственной карьере.
2. Составление плана развития: какие компетенции нужно развивать сотруднику для достижений целей, и как именно он будет это делать. Почему это важно — потому что самая высокая текучка бывает от остановки в развитии.
3. Работа над достижением результатов: здесь важен регулярный мониторинг и обратная связь. «Регулярный мониторинг» — это не съёмка экрана или скриншоты, не тайм-трекер, а встречи раз в пару недель для обсуждения, всё ли хорошо получается и не нужна ли помощь, не нужно ли позвать эксперта из другой части компании, не нужно ли купить какие-то курсы и так далее.
4. Подведение итогов: оценка результатов сотрудника — что получилось хорошо, а чего достичь не удалось, а также корректировка трека развития.
5. GOTO 1.

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

Ожидания можно согласовывать как по конкретным вещам вроде «я доделаю это к такому-то сроку», так и по метрикам. С метриками часто очень сложно, но, повторюсь, иногда можно их придумать. Например, часто хорошо выглядит управление техдолгом, доступность сервиса или покрытие тестами. Очень хорошо выглядят различные SLA: например, на время ревью — для команды это будет метрика «время поставки», а для разработчика — «время на ревью». Можно считать количество возвратов от тестировщиков и количество серьёзных багов, если вы исповедуете что-то близкое к TDD или хотя бы хотите это исповедовать.

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

Частые ошибки

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

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

1. Размытые ожидания. Это когда руководитель имеет в виду одно, сотрудник — другое. Например, если вы договорились «проработать архитектуру и долгосрочные планы», но не сформулировали это в виде понятной метрики или хотя бы чего-то похожего на техзадание, то для вас это может быть «план развития на 2 года с глобальными изменениями архитектуры», а для разработчика «оптимизация того, что есть, чтобы сервис не валился в следующие 3 месяца». Хотя вы оба имели в виду «долгосрочную техническую стратегию». Я в такую ситуацию попадал, когда подводили итоги — стало понятно, что друг друга не поняли.
2. Нет регулярной обратной связи. Это очень важно, но раз за разом руководители это забывают. Вернулся через квартал и спросил «Ну как дела?» — выстрел в ногу. Нужно чаще, регулярнее и стабильнее. Так можно сэкономить месяц, который иначе придётся выкинуть. Кстати, разница между командой и обратной связью в том, что обратная связь не лишает самостоятельности. Она просто оценочная, а не директивная.
3. Упёртость и инертность. Как только появляется понятие «план», часто он начинает восприниматься как константа. А мир меняется, и у вас то ковид, то февраль, то нашествие инопланетян. Нужно уметь вовремя пересматривать текущие цели прямо внутри цикла. Ситуация поменялась? Не надо упираться, надо заново сделать согласование ожиданий хоть в каком-то виде.
4. Страх говорить, что что-то плохо. Часть конструктивной обратной связи — это чётко показать, где плохо. Суть перформанс-менеджмента — в обратной связи. Я уже приводил этот пример, но более приземлённо он выглядит так: человек приходит с целями на квартал. Их должно быть 3–4. У него их 20. Смотрим предыдущие кварталы — там примерно такая же история, два десятка целей в начале и 2–3 выполненных в конце, а остальные надкусаны. Можно поговорить, скорее всего, разработчик скажет «да-да, я понял», но он ровно это же говорил и прошлый раз. Нужно давать негативную обратную связь: смотри, здесь и здесь не вышло, давай разбираться. Хочешь микроменеджмент? Хочешь KPI? Нет? Давай тогда сокращать цели и обсуждать оставшиеся 3 чаще. Естественно, разработчику тоже очень нужна прозрачность, понимание, насколько хорошо он работает с точки зрения руководителя. Потому что вполне может оказаться, что части вашей работы вообще не видно, а вы считаете её главной.
5. Непопадания в оценку. Вот разработчик решил, что затащит задачу за 2 спринта, а идёт уже пятый, и всё ещё куча проблем, сложностей, он копает, фреймворк подбирает, а руководитель считает, что слишком долго. Нужно заранее обсудить, что делать в такой ситуации. Senior, скорее всего, придёт на встречу и скажет: вот тут непопадание в оценку, я там договорился, если есть ещё неделя — всё будет. Джун же должен сразу сказать, что у него блокер, и уже потом пытаться решить самому, но с помощью кого-то. Иначе есть шансы колупать вопрос ещё 3–4 спринта.
6. Не превращать команду в болото. Ожидания должны быть чуть выше, чем текущий уровень, чтобы было развитие. Нужно понимать, что хочет человек: архитектуру, менеджмент, заниматься продуктом. Нужно видеть, какие есть потребности у команды и у компании. Если разработчик хочет двигаться в архитекторы, а нам не хватает компетенций по качественному проектированию, можем давать задачи по проектированию или архитектуре. Давайте дадим ему задачу почитать материалы, показать инструменты, найти ментора внутри компании. Если ему интересно, то важно, чтобы его не бросали в воду. Понятно, что не всегда в команде есть потребности в таких задачах — тогда очень важно смотреть на потребности других команд, потому что лучше пусть разработчик перейдёт туда, где ему интереснее, чем уйдёт из компании вообще от скуки. У нас есть команда, которая верстает лендинги: понятно, что там нет сложных задач, это фактически поддержка. Или есть команда админов: они тоже про поддержку, но у них постоянно новые технологии и железо. Поменять систему сбора логов — это не совсем рутина.
7. Давать время на развитие. Проще говоря, если вы ставите задачу что-то изучить, нужно выделять на неё время и сопоставлять это с задачами команды. Если рутины много, все задачи срочные, отдельного времени на изучение инструмента нет — через полгода-год будет ровно такая же встреча, как и прошлый раз с таким же планом развития. Только вот глаза у разработчика уже не будут гореть.
8. «KPI — зло». Да, зло. Но иногда они нужны и даже работают. Многие никак не оценивают результативность, и это работает. Некоторые вводят командные метрики и коллективную ответственность. Тоже иногда работает. Нужно понимать особенности каждого инструмента управления и его применимость в вашей ситуации. Ну и долговременные последствия.
9. Не все хотят расти. Весь план управления результативностью предполагает, что человек хочет развиваться. Это не всегда так, и это не всегда в той профессиональной сфере, где вы управляете разработчиком. Я знаю мидла, который в этом грейде уже 17 лет подряд, и его всё устраивает. Я знаю людей, которые могли вырасти до архитекторов, но увлекались хобби и росли уже там.
10. Оценка только по результатам продукта (когда важно, что получилось только по бизнес-показателям). Нет: важно не что на выходе, а какой использовался подход к решению задачи, например, какие риски предотвращались и так далее.

В итоге управление людьми — это постоянное общение, согласование ожиданий и обратная связь.

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

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