Про performance review в командах разработки

В этой статье я решил рассказать о том, как у меня был выстроен привычный уже всем процесс performance review:) Я принес его в свои команды разработки порядка 5 лет назад, но тогда я еще не вел Medium, поэтому поделиться им было негде. Интересно, что тогда этот процесс еще не был принят у нас во всей компании.

Мне этот процесс нужен был для повышения эффективности моих команд, а также для мотивации и объяснения моим разработчикам того, как они могут расти у нас в компании. Интересно, что около трех лет назад я рассказывал на конференции как у меня в привлечении Tinkoff была выстроена часть с наймом и мотивацией сотрудников, где я достаточно подробно рассказывал про performance review как часть этих процессов. Ниже ссылка на выступление, а дальше в статье будет текстовая версия этой истории.

Что такое performance review?

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

Рис.1 “Схематичный рост оценки”

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

Ценности

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

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

В других компаниях, таких как Tinkoff, которые работают на динамичном рынке, где стоимость ошибки высока, в ценностях могут быть

Рис.2 “Пример ценностей”

• Скорость доставки изменений (time-to-market)
  Нам важно быстро доставлять рабочий продукт до пользователей. Мы тратим много ресурсов на AB-тестирование и хотим проверять гипотезы быстро. Для этого у каждого продукта есть свой владелец, который генерирует идеи и вкидывает их в команду разработки, которая реализует и доставляет ее максимально быстро
• Качество решения (product quality, external and internal)
  Любая наша ошибка на production— это потеря денег компании. Для ускорения доставки рабочего продукта мы должны встраивать quality assurance в процессы разработки, привлекая qa-инженеров максимально рано к разработке фич, автоматизируя тестирование фич, тем самым сокращая время регресса (shift)…
• Эффективная команда (effective team)
  В современном IT мире часто команда, которая делает продукт для конечного пользователя, сама является продуктом — компании важно
  - Правильно ставить цели командам
  - Эффективно организовывать процессы командной работы
  - Качественно подбирать людей, которые могут и хотят вместе работать в команде
  - Сделать так, чтобы люди оставались в компании надолго, так как поиск и онбординг нетривиальный процесс, который очень недешево обходится компании

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

Кому и для чего нужно ревью?

Дайте теперь вернемся к performance review. Какие бы хорошие люди в компании ни работали, чем больше она становится, тем сильнее усложняется взаимодействие. Если представить любую компанию в виде графа взаимосвязей, то мы получим сложную сеть, когда из одной части компании в другую идёт много условных стрелочек. Чем больше компания, тем больше этих стрелочек и тем больше потерь на этих стрелочках — на взаимодействии, коммуникации.

Если у вас маленькая компания, вам достаточного одного человека — лидера, энтузиаста — который в состоянии всех обежать и «зажечь». Когда компания большая, очень важно иметь «прослойку» лидеров, желательно синхронизированных между собой, каждый из которых решает задачи в своей области. Если что-то в этой схеме не работает — нечеткие цели, слабые неактивные лидеры, криво разделенные полномочия, провоцирующие вялое сотрудничество либо вовсе вражду и саботаж — производительность начинает проседать, а в особенно запущенных случаях компания попросту начинает “протухать”.

Процесс ревью

Performance review — это периодические личные встречи (1 раз в полгода) разработчиков с руководителем разработки, на которых обсуждаются вопросы:

• Итоги работы за прошедший период
  - Бизнес результаты по продуктам, в создании/развитии которых участвовал разработчик (руководитель разработки заранее собирает фидбек с бизнес-заказчиков)
  - Качество выполнения работ (руководитель заранее собирает фидбек с qa-инженеров и членов той же команды разработки)
  - Выполнение личного плана развития
  - Приобретенные знания и опыт, навыки и качества
• Двухстороннее общение
  - Фидбэк от руководителя разработки по выполненным планам: что хорошо сделано, что нужно подтянуть, …
  - Фидбэк от самого участника команды: все ли нравится, что мешает в работе, что хотелось бы улучшить, …
• План на следующий период
  - Продукты/проекты, в которых бы хотелось поучаствовать сотруднику
  - Обсуждение личного плана развития, например, изучение нового языка или фреймворка, посещение конференции, подготовка доклада …

Навыки и качества

Помимо приобретения знаний и опыта в процессе работы ожидается соответствующее развитие след. личностных качеств и навыков:

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

Профессиональный рост

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

Рис.3 “Пути карьерного развития условного разработчика”

Подробнее про этот базовый карьерный путь разработчика я уже рассказывал в статье Профессиональный рост программистов (junior, middle, senior, …), здесь я его упомянул из-за важности такого роста для процесса performance review. Критично, чтобы руководителя и сотрудника было одинаковое понимание ожиданий от разных уровней сотрудников. Тогда планируя следующий период они могут подбирать цели и результаты так, чтобы сотрудник, проявив себя, мог показать что достоин перехода на следующий уровень.

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

Компенсация

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

Без труда не выловишь и рыбку из пруда

А значит само по себе, без усилий, просто с течением времени повышение не придет, необходимо вкладываться в свое развитие. В некоторых компаниях и для некоторых грейдов есть своеобразный TTL (time to live), который задает минимальные темпы роста. Но даже если его нет, то performance review позволяет понять пересекаются ли интересы и ожидания руководителя и кандидата и если они не пересекаются, то как правило дальше идет прощание друг с другом по обоюдному согласию.

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

Ну и напоследок могу подкинуть такой список вопросов.

Вопросы для подготовке к встрече по performance review

1. Чего вы добились со времен предыдущего ревью?
2. Какие проблемы и интересные задачи довелось решать и насколько успешно это было?
3. Какие цели были перед вами поставлены руководством и соответственно какие результаты получены?
4. Какие цели вы ставили сами перед собой и каковы достижения?
5. Что как вам кажется вы делаете не так и что следует изменить?
6. Насколько вообще было интересно заниматься запланированными задачами?
7. Все ли устраивает в выбранном направлении?
8. Что хотелось бы изменить?
9. Что планируем сделать в течение следующего полугода по продукту?
10. Что планируем освоить и изучить по личному/профессиональному плану?
11. Какие планируются изменения в ближайшее время (должность, оклад/премия, зона ответственности)?
12. Комфортные ли сейчас условия (позиция, доход, ответственность), какие ожидания, планы?
13. Какие вопросы еще хотим обсудить?