26 апреля на конференции KnowledgeConf 2019 ^[1] прозвучал доклад «Performance Review и выявление тайного знания». Обычно мы рассказываем про технологии, однако, чтобы развиваться как компания, занимаемся далеко не только этим. Данное выступление, посвящённое инженерам и их развитию, — хороший тому пример. Если вы тимлид или думаете о том, как обеспечить рост сотрудников в команде, эта статья (и сам доклад) может оказаться полезной.

По традиции рады представить видео с докладом ^[2] (50 минут, гораздо информативнее статьи), а ниже — его выжимка в текстовом виде, обогащённая некоторыми деталями, не прозвучавшими в самом докладе.

Зачем Performance Review?

До «Фланта» я был техническим директором в компании-разработчике. Мне хотелось, чтобы команда росла, становилась способна решать всё более сложные задачи и сотрудники повышали квалификацию. А для этого требовались две вещи:

1. Прозрачные правила роста.
2. Обратная связь.

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

Просто ли построить карьерную лестницу?

Как оказалось, нет. Даже если у вас есть описания вакансий сотрудника более высокого уровня, нельзя просто взять набор ключевых слов из неё и сказать, что это и есть необходимые шаги для повышения карьеры. Если вы скажете сотруднику: «Выучи Symfony 4, PostgreSQL и MySQL», — ему это не сильно поможет. Не учить же ему весь MySQL! Важны детали, поэтому потребуется какое-то средство измерения навыков человека… что-то вроде линейки.

Представьте себе линейку, но у неё вместо делений — качественные уровни владения навыком, которые естественным образом можно выделить. Если бы у нас была такая линейка, мы смогли бы привязать к ней реальные задачи, реальный опыт и конкретные обучающие материалы. Так?

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

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

Просто ли давать обратную связь?

Звучит логично, что нужно периодически (например, раз в квартал) встречаться с сотрудником и давать ему обратную связь. И постараться организовать это так, чтобы процесс был наполнен смыслом, а не карго-культом. Неплохой идеей кажется взять наши «линейки» с навыками:

… организовать из них N-мерное пространство и сказать человеку, где он в этом пространстве находится, после чего договориться, куда будет двигаться дальше:

N-мерное пространство представить тяжело, поэтому можем использовать для этих целей таблицу. Рядами в ней будут наши навыки, а в колонках — уровень развития навыка. Если мы проведём две такие сессии, то сможем увидеть примерно следующую картину:

… что, казалось бы, убедит нас в верности выбранного пути и выбранных инструментов — ведь люди развиваются. А когда изменений наберётся критическая масса, можно поднять сотруднику зарплату и поменять шилдик на его должности, сказав, например, что он теперь Middle PHP Developer.

Но как всё происходит на практике?

В теории это звучит классно и прозрачно. Я делал попытки запустить механизм в таком виде — и они были… прямо скажем, не очень. Известные мне попытки коллег по цеху также не вдохновляли. Основные проблемы таковы:

• Не все сотрудники одинаково хорошо реагируют на обратную связь. Легко оказаться в ситуации, когда остро встаёт вопрос отсутствия авторитета, а в таких условиях сложно давать экспертную оценку.
• Выделение ключевых навыков, по которым производится оценка, на практике оказывается нетривиальной историей — особенно, если ты сам человек «от сохи». Сложно абстрагироваться от деталей и соблюсти баланс между точностью и обобщением.
• Наличие подобной «обратной связи» и «лестницы» никак не коррелировало с мотивацией сотрудников. Если они развивались, то скорее вопреки системе, чем благодаря ей.

Потребность «Фланта» в Performance Review

Когда я пришёл во «Флант», то увидел ряд проблем, которые заставили меня задуматься о Performance Review, а именно:

• У инженеров не было понимания, к чему им расти, в каком направлении развиваться. Этот вопрос иногда озвучивался, но внятный ответ можно было получить достаточно редко.
• Инженеры не чувствовали сопричастности к компании, не чувствовали отдачи от неё и её участия в своей карьере.
• Компания начала активный рост, а в этих условиях особенно необходимо выстраивать понятные и работающие механизмы для превращения новичков в опытных инженеров и руководителей.

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

Но всё оказалось не так очевидно…

В поисках списка навыков

Выяснилось, что никто не может выделить требования к навыкам DevOps-инженеров и вообще выделить какие-либо «уровни квалификации». Наиболее близкое описание этой позиции — у бессмертного Роберта Хайнлайна:

Любой человек должен уметь менять пеленки, планировать вторжения, резать свиней, конструировать здания, управлять кораблями, писать сонеты, вести бухгалтерию, возводить стены, вправлять кости <...>, программировать компьютеры, вкусно готовить, хорошо сражаться, достойно умирать.

То есть руководители команд ожидали и растили своих людей как fullstack-инженеров, способных и корректно выяснить детали о задаче, и решить все технические вопросы, и довести это до production’а.

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

Как вы, возможно, догадались, под капотом оказались десятки технологий с сотнями нюансов. Мы не ограничиваем своих клиентов в выборе технологического стека для своих приложений, поэтому наш инженер сталкивается с большим разнообразием баз данных, серверов очередей, фреймворков и языков, инструментов диагностики, разработки и отладки, а также особенностями разных ЦОДов и платформ.

За последние 5 лет я стал свидетелем фундаментального изменения: если раньше почти нормой считалось, когда техдир заявлял: «Мы работаем на платформе Х с базой данных Y и ни на чём другом мы работать не будем», — то теперь некоторые СТО могут и вовсе отпустить контроль за стеком, уповая на микросервисы и (довольно спорный ^[3]) лозунг: «Если сломается, проще переписать всё с нуля».

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

Переосмысляя PR

Мы решили попробовать другой путь, но для начала переосмыслить свои действия и ожидания. Запуская Review, мы бы:

• … пытались делать измерения performance’а сотрудников;
• … разговаривали с ними;
• … ожидали, что в итоге они станут более счастливыми, лучше понимающими свои перспективы и предполагаемый карьерный рост.

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

Оценка производительности

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

И в какой-то момент пришла интересная мысль: здесь изображено избыточное количество информации. На самом деле, не так важны конкретные «деления» — картинку можно упростить до такой:

Нас интересует скорость развития, а не факт того, что человек достиг какого-то конкретного уровня. Было ли вообще развитие? Много изучил человек или мало? Вот что настоящий показатель!

Расследование тайны списка навыков

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

Один из способов выявить тайное знание — «по следам», то есть: фиксируя происходящее, чтобы потом его проанализировать.

Подобно тому, как мы можем по следам в лесу понять, что там водятся белки, лисицы и медведи, попробуем выявить и тайное знание…

Пилотный проект

Тимлид Пётр любезно согласился поучаствовать в пилотном проекте по запуску Review в обновлённом виде. Пётр вник в идеи, и мы с ним запланировали встречи с сотрудниками. В результате самостоятельной подготовки, Пётр сформулировал вот такую обратную связь об одном из своих инженеров — Леониде:

Это пример некачественной обратной связи: если бы вы услышали о себе такое в подобных формулировках, то вряд ли бы это сильно вам помогло. Даже если в голове у тимлида всё сформулировано более чётко (что совершенно не факт), фиксировать информацию в таком виде не очень полезно, потому что спустя полгода такие «следы» не принесут пользы — даже автор не вспомнит, о чём речь.

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

Подготовка ведущего PR

В итоге, мы сформулировали следующие правила подготовки к PR для тимлидов:

1. Перед каждым ревью нужно выделить от получаса до полутора часов на подготовку. Лучше готовиться днём ранее, а не в тот же день.
2. Пройтись по всем трекерам (тикет-системы, мессенджеры, карма-системы и т.п.), даже если руководителю лень и он сопротивляется, аппелируя к своей прекрасной памяти. Посмотреть заметки с предыдущего ревью.

   

3. Выписать ряд тезисов для обсуждения. Эти тезисы обязательно должны содержать:
   • Факты, с обоснованием в виде ссылок на трекеры;
   • Личное отношение ревьювера: объяснение, почему он(а) выделил(а) этот пункт, и что в нём такого важного.

Кстати, примеры плохих и хороших формулировок мы выложили здесь ^[4].

Процесс PR

Само ревью проходит всегда очно. Несмотря на то, что мы работаем удалённо, ни о каком ревью через документы/опросники/сервисы речь идти не может. В нашем случае общение идёт через Google Hangouts и присутствуют тимлид, инженер, HR и, по необходимости, другие заинтересованные.

Ревью проходит через несколько этапов:

• Разговор об отвлечённом, чтобы настроиться на беседу друг с другом.
• Рассказ о том, что человек сделал хорошего, за что хочется его поблагодарить и объяснить, почему это важно. Мы ведь хотим, чтобы такое хорошее делали и дальше?
• Обозначить однозначно плохое: нарушения договорённостей, дисциплины и прочие вещи, которые вы считаете непростительными и вина по которым неоспорима.
• Обсудить непонятное или спорное по следующим правилам:
  • Обозначить факты и личное отношение к этим фактам.
  • Задать общий вопрос (вроде «Что ты об этом думаешь?»), чтобы получить больше информации от сотрудника о проблеме.
  • Поставить вопрос: считает ли сотрудник, что существует проблема? Может выясниться, что он по каким-то личным причинам не считает это важным. Нам нужно убедиться, что он разделяет наше восприятие.
  • Поставить вопрос: что конкретно сам сотрудник собирается делать, чтобы решить проблему?
  • Если сотрудник не разделяет вашу проблему, предлагает невнятные решения — высока вероятность, что делать с ней он ничего не будет. И давить в этой ситуации на него бессмысленно — лучше попытаться понять, почему дело обстоит именно так.
• Попросить обратную связь от сотрудника. Соответствовала ли его жизнь в компании за этот цикл его ожиданиям? Если вы до этого действительно смогли выстроить диалог, то на этом этапе получите фидбэк, а не невнятное мычание, как это часто бывает.
• Поговорить о зарплате: повышаете ли вы её, а если нет — что конкретно нужно исправить, чтобы её повысить. Вопрос зарплаты очень важен и сложен и в общем случае является главным мотивом для сотрудника участвовать в Performance Review. Есть подозрение, что нет большого смысла пытаться запустить какие-то процессы ревью, если это никак не влияет на зарплату, но это не 100%…

Итого:

Итоги первого года

Анализ накопленных за первый год записей помог нам:

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

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

Другие знаменательные моменты:

• Более конструктивно стали решаться проблемы у новичков при их адаптации: руководители внезапно для себя обнаружили, что они могут пообщаться с новичком о проблемах… и он исправится!
• Стало понятнее, каких сотрудников мы ждём в компании, поэтому скорректировались требования при найме.
• Самим сотрудникам стало более очевидно, чего от них могут хотеть и какая перспектива развития у них есть.
• Появились наброски на матрицу компетенций, причём есть и механизм постоянной её актуализации.

Портрет инженера

Может показаться очевидным, что инженер, например, должен действительно любить то, чем занимается, и получать удовольствие от работы… Так или иначе — вот четыре навыка, которые оказались самыми востребованными (с большим отрывом):

Другими важными навыками оказались:

Попробуем выяснить во второй год

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

Кроме того, прямо сейчас мы ищем способы поставить на поток обучение проведению ревью среди руководителей — готового решения у нас ещё нет.

Отдельный сложный вопрос, который не так просто формализовать, — это связь системы оценки и вопроса зарплат сотрудников. Как нам кажется, этот вопрос напрямую обусловлен бизнес-моделью компании, и решение для одного бизнеса может не очень подойти для другого. (О нашей модели уже рассказывали ^[5] на хабре: мы построены почти как франшиза, и по мере роста эффективности и компетентности команды у неё появляются деньги на зарплаты.)

Видео и слайды

Видео с выступления (~50 минут):

Презентация доклада:

P.S.

Возможно, вас также заинтересуют следующие публикации:

• «Как „Флант“ помогает новичкам ^[6]»;
• «Как „Флант“ нанимает сотрудников ^[7]»;
• «7 привычек успешных Site Reliability Engineers (по версии New Relic) ^[8]».

Среди других докладов в нашем блоге:

• «Расширяем и дополняем Kubernetes ^[9]» (Андрей Половов; 8 апреля 2019 на Saint HighLoad++);
• «Базы данных и Kubernetes ^[10]» (Дмитрий Столяров; 8 ноября 2018 на HighLoad++);
• «Мониторинг и Kubernetes ^[11]» (Дмитрий Столяров; 28 мая 2018 на RootConf);
• «Лучшие практики CI/CD с Kubernetes и GitLab ^[12]» (Дмитрий Столяров; 7 ноября 2017 на HighLoad++);
• «Наш опыт с Kubernetes в небольших проектах ^[13]» (Дмитрий Столяров; 6 июня 2017 на RootConf).

Автор: Цупко Игорь

Источник ^[14]