Как и зачем Владимир Малов выстраивает систему развития разработчиков в «Утконосе»

Этот пост написан Владимиром Маловым, CTO компании «Утконос».

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

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

Однажды сотрудник принес мне оффер с цифрой, ощутимо превышающий его текущий уровень.Чтобы удержать его мне нужно было:

• перебить оффер
• убедить HR-отдел сделать повышения вне принятых рамок
  
• сделать так, чтобы сотрудник снова открыл нам сердце и освободился от мыслей о новом и интересном приключении с новым работодателем.
  

Я задумался: а что, если мне принесет оффер не один человек, а несколько или целая команда?Стало понятно, что нужно сотрудникам дать развитие внутри Утконоса, чтобы эту ценность не перебивали другие офферы.

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

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

• Как руководителю понять, что оффер из другой компании не перегрет, и сотрудник стоит таких денег?

• Как сотруднику построить карьерный путь внутри Утконос?

• Как установить в компании процесс согласования зарплатных вилок, которые будут равны рыночному уровню?
  

• Как не заложить бомбу зарплатного неравенства под собственный отдел, когда люди одного уровня получают разные зарплаты?

Итак, сотрудник принес вам рыночный оффер, зная, что несет на себе bus-factor over-9000.

Мы не рассматриваем это как шантаж со стороны сотрудника, а считаем, что он действительно имеет такую ценность на рынке, и мы сами упустили момент, когда на сотруднике начало “держаться все”.

И начинается челночная дипломатия: бежим в кадры, пытаемся обойти правила повышения ЗП, ищем подводные камни такого повышения. Как отреагируют сотрудники, что их коллега, стал сеньором, а они нет? Какие мотиваторы у сотрудника на самом деле? Какие задачи/уровень ЗП/уровень всего коллектива?

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

Для решения этих задач мы обратились в Vectorly. Vectorly – это единый инструмент для оценки и развития сотрудников, включающий в себя карты навыков, грейды, оценку компетенций, OKR, планы развития и. т.д, своеобразный швейцарский нож для тимлидов. (https://vectorly.team)

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

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

Для начала нужно было составить карту скиллов с уровнями, которые однозначно могут указать на уровень сотрудника, является ли он Junior, Middle или Senior специалистом. Карта должна включать в себя как общепринятые в направлении навыки, так и навыки, характерные конкретно для вашего написанного кода (фреймворки, библиотеки, паттерны).

Для составления такой карты мы вовлекли команду, потому что:

• Это трудоемкий процесс, в одиночку вы легко сожжете на это 2-х недельный спринт.

• Вы сразу сделаете карту, которая будет устраивать вашу команду.

Каждый тимлид взял на себя соответствующую карту компетенций: Angular, Go, Android и расписал необходимые навыки. Команда Vectorly на старте предоставила нам готовые шаблоны карт компетенций, часть из которых мы адаптировали под наши реалии, что помогло существенно сократить время.Карьерные векторы и позиции

Внутри карты мы создаете карьерные векторы и позиции с необходимыми навыками, которые помогают определить уровень сотрудника. Является ли он Junior, Middle или Senior специалистом.

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

Важно состыковать скиллы с уровнями так, чтобы они соответствовали рынку.

Наконец-то добрались до самого процесса ревью. Оно разделено на 3 принципиальных процесса.

• Ревью себя
• Ревью руководителем
• Ревью внутри команды
  

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

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

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

Отлично, мы провели ревью сотрудника, результаты появились в системе, пора сделать выводы.

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

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

Третье: мы делали этот процесс открытым для команды, а значит уровень сотрудника известен всем. Это очень пригодится нам, когда ребята решат поделиться уровнями ЗП и обнаружат, что они откалиброваны по результатам ревью и тем самым снимаем вопрос “зарплатного неравенства”.

Чтобы инструмент “взлетел” в компании и был аргументом для HR-отдела, нам было необходимо:

1. Утвердить матрицы с HR-отделом. Для них было важно, чтобы уровни навыка имели четкое определение.

2. Иметь маппинг позиций на то, что будет записано в трудовой.

3. Иметь маппинг позиций на зарплатные вилки.

4. Сохранять объективность оценки внутри команды.

Если 1 и 2 пункт является достаточно рутинным, то 3 и 4 пункт имеет важные аспекты.

Очень желательно поддерживать актуальность вилок на стороне HR-отдела. Желательно 2 раза в год обновлять вилки до уровня рынка, а через регулярный процесс ревью подтягивать ЗП сотрудников до уровня рынка.

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

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

При слове “грейды” HR-отдел вздрагивал, говоря что это колоссальная работа. Благодаря Vectorly мы собрали матрицу скиллов и лесенку позиций, передали в HR.

Теперь у каждой позиции 3 ступеньки, итого 9 грейдов разработчика, и к каждому грейду даны соответствующие ожидания по компетенциям от сотрудника.

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

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

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

Если вам интересна тема и хочется подробностей, дайте знать в комментариях, я расскажу подробнее:

• О наших картах, по которым мы проводим ревью.

• Как ревью выглядит изнутри в нашей команде разработке Go?

• Как разделять повышение ЗП за накопленный опыт и компетенции?

• Как понимать, где сосредоточен bus-factor в вашей команде?

• Как использовать vectorly не только для ревью компетенций разработчика, но и ревью знаний бизнес-процессов компании?

• Как внедрять новую технологию и мягче онбордить на нее сотрудников (Для нас такой технологией стал Kubernetes.)