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