26 апреля на конференции KnowledgeConf 2019 прозвучал доклад «Performance Review и выявление тайного знания». Обычно мы рассказываем про технологии, однако, чтобы развиваться как компания, занимаемся далеко не только этим. Данное выступление, посвящённое инженерам и их развитию, — хороший тому пример. Если вы тимлид или думаете о том, как обеспечить рост сотрудников в команде, эта статья (и сам доклад) может оказаться полезной.
По традиции рады представить видео с докладом (50 минут, гораздо информативнее статьи), а ниже — его выжимка в текстовом виде, обогащённая некоторыми деталями, не прозвучавшими в самом докладе.
Зачем Performance Review?
До «Фланта» я был техническим директором в компании-разработчике. Мне хотелось, чтобы команда росла, становилась способна решать всё более сложные задачи и сотрудники повышали квалификацию. А для этого требовались две вещи:
- Прозрачные правила роста.
- Обратная связь.
Нужно было получить некие правила, по которым сотрудник мог бы развиваться в компании и по которым можно давать ему своевременную обратную связь, чтобы помогать с проблемами на этом пути.
Просто ли построить карьерную лестницу?
Как оказалось, нет. Даже если у вас есть описания вакансий сотрудника более высокого уровня, нельзя просто взять набор ключевых слов из неё и сказать, что это и есть необходимые шаги для повышения карьеры. Если вы скажете сотруднику: «Выучи Symfony 4, PostgreSQL и MySQL», — ему это не сильно поможет. Не учить же ему весь MySQL! Важны детали, поэтому потребуется какое-то средство измерения навыков человека… что-то вроде линейки.
Представьте себе линейку, но у неё вместо делений — качественные уровни владения навыком, которые естественным образом можно выделить. Если бы у нас была такая линейка, мы смогли бы привязать к ней реальные задачи, реальный опыт и конкретные обучающие материалы. Так?
К сожалению, нет: на практике подобная линейка оказывается отдельной темой для «священных войн», поскольку не получается с математической точностью сказать, умеет человек реализовывать сложную бизнес-логику или ещё нет. Но есть и хорошая новость: на той же практике математическая точность не так нужна. Можно воспользоваться методом экспертной оценки: дать наиболее опытному и наиболее погруженному в ситуацию сотруднику возможность принимать решение о принадлежности к уровню навыков, и от этого уже отталкиваться.
Придётся закрыть глаза на плохую точность, на посредственную масштабируемость метода и много чего ещё, но в то же время можно признать, что этот способ вполне неплохо справляется со своей задачей. Мало того — и по сей день он очень много где используется. Зачастую тимлид вполне может выступать в качестве такого «эксперта» в своей команде, и это ок.
Просто ли давать обратную связь?
Звучит логично, что нужно периодически (например, раз в квартал) встречаться с сотрудником и давать ему обратную связь. И постараться организовать это так, чтобы процесс был наполнен смыслом, а не карго-культом. Неплохой идеей кажется взять наши «линейки» с навыками:
… организовать из них N-мерное пространство и сказать человеку, где он в этом пространстве находится, после чего договориться, куда будет двигаться дальше:
N-мерное пространство представить тяжело, поэтому можем использовать для этих целей таблицу. Рядами в ней будут наши навыки, а в колонках — уровень развития навыка. Если мы проведём две такие сессии, то сможем увидеть примерно следующую картину:
… что, казалось бы, убедит нас в верности выбранного пути и выбранных инструментов — ведь люди развиваются. А когда изменений наберётся критическая масса, можно поднять сотруднику зарплату и поменять шилдик на его должности, сказав, например, что он теперь Middle PHP Developer.
Но как всё происходит на практике?
В теории это звучит классно и прозрачно. Я делал попытки запустить механизм в таком виде — и они были… прямо скажем, не очень. Известные мне попытки коллег по цеху также не вдохновляли. Основные проблемы таковы:
- Не все сотрудники одинаково хорошо реагируют на обратную связь. Легко оказаться в ситуации, когда остро встаёт вопрос отсутствия авторитета, а в таких условиях сложно давать экспертную оценку.
- Выделение ключевых навыков, по которым производится оценка, на практике оказывается нетривиальной историей — особенно, если ты сам человек «от сохи». Сложно абстрагироваться от деталей и соблюсти баланс между точностью и обобщением.
- Наличие подобной «обратной связи» и «лестницы» никак не коррелировало с мотивацией сотрудников. Если они развивались, то скорее вопреки системе, чем благодаря ей.
Потребность «Фланта» в Performance Review
Когда я пришёл во «Флант», то увидел ряд проблем, которые заставили меня задуматься о Performance Review, а именно:
- У инженеров не было понимания, к чему им расти, в каком направлении развиваться. Этот вопрос иногда озвучивался, но внятный ответ можно было получить достаточно редко.
- Инженеры не чувствовали сопричастности к компании, не чувствовали отдачи от неё и её участия в своей карьере.
- Компания начала активный рост, а в этих условиях особенно необходимо выстраивать понятные и работающие механизмы для превращения новичков в опытных инженеров и руководителей.
Поэтому очень хотелось выделить навыки, которые нужны для каждой из позиций, и создать условия для карьерного роста.
Но всё оказалось не так очевидно…
В поисках списка навыков
Выяснилось, что никто не может выделить требования к навыкам DevOps-инженеров и вообще выделить какие-либо «уровни квалификации». Наиболее близкое описание этой позиции — у бессмертного Роберта Хайнлайна:
Любой человек должен уметь менять пеленки, планировать вторжения, резать свиней, конструировать здания, управлять кораблями, писать сонеты, вести бухгалтерию, возводить стены, вправлять кости <...>, программировать компьютеры, вкусно готовить, хорошо сражаться, достойно умирать.
То есть руководители команд ожидали и растили своих людей как fullstack-инженеров, способных и корректно выяснить детали о задаче, и решить все технические вопросы, и довести это до production’а.
Меня, конечно, это вдохновило. Здорово работать в компании, где каждый — универсальный боец, разносторонняя личность и отличный инженер! Омрачалось это только тем, что всё выглядело как огромная тёмная пещера с тайным знанием, в которую страшно входить. Не хотелось обрекать инженеров на подобные путешествия.
Как вы, возможно, догадались, под капотом оказались десятки технологий с сотнями нюансов. Мы не ограничиваем своих клиентов в выборе технологического стека для своих приложений, поэтому наш инженер сталкивается с большим разнообразием баз данных, серверов очередей, фреймворков и языков, инструментов диагностики, разработки и отладки, а также особенностями разных ЦОДов и платформ.
За последние 5 лет я стал свидетелем фундаментального изменения: если раньше почти нормой считалось, когда техдир заявлял: «Мы работаем на платформе Х с базой данных Y и ни на чём другом мы работать не будем», — то теперь некоторые СТО могут и вовсе отпустить контроль за стеком, уповая на микросервисы и (довольно спорный) лозунг: «Если сломается, проще переписать всё с нуля».
Составить в этих условиях список технологий для оценки сотрудников — нетривиальная задача. А поддерживать его постоянно актуальным слишком трудозатратно и сложно организационно. Поэтому мы попробовали найти решение и хотим поделиться им.
Переосмысляя PR
Мы решили попробовать другой путь, но для начала переосмыслить свои действия и ожидания. Запуская Review, мы бы:
- … пытались делать измерения performance’а сотрудников;
- … разговаривали с ними;
- … ожидали, что в итоге они станут более счастливыми, лучше понимающими свои перспективы и предполагаемый карьерный рост.
Мы вложили около полутора месяцев на переосмысление этих пунктов и ниже я расскажу, что же из этого получилось.
Оценка производительности
Мне довелось смотреть на примерно такую картинку в попытках понять, что здесь может быть не так:
И в какой-то момент пришла интересная мысль: здесь изображено избыточное количество информации. На самом деле, не так важны конкретные «деления» — картинку можно упростить до такой:
Нас интересует скорость развития, а не факт того, что человек достиг какого-то конкретного уровня. Было ли вообще развитие? Много изучил человек или мало? Вот что настоящий показатель!
Расследование тайны списка навыков
Ранее мы пришли к тому, что список навыков является для нас тайным знанием: инженеры что-то умеют, что-то делают каждый день, но что именно — сформулировать сложно.
Один из способов выявить тайное знание — «по следам», то есть: фиксируя происходящее, чтобы потом его проанализировать.
Подобно тому, как мы можем по следам в лесу понять, что там водятся белки, лисицы и медведи, попробуем выявить и тайное знание…
Пилотный проект
Тимлид Пётр любезно согласился поучаствовать в пилотном проекте по запуску Review в обновлённом виде. Пётр вник в идеи, и мы с ним запланировали встречи с сотрудниками. В результате самостоятельной подготовки, Пётр сформулировал вот такую обратную связь об одном из своих инженеров — Леониде:
Это пример некачественной обратной связи: если бы вы услышали о себе такое в подобных формулировках, то вряд ли бы это сильно вам помогло. Даже если в голове у тимлида всё сформулировано более чётко (что совершенно не факт), фиксировать информацию в таком виде не очень полезно, потому что спустя полгода такие «следы» не принесут пользы — даже автор не вспомнит, о чём речь.
Нам бы хотелось, чтобы обратная связь была максимально объективной, вежливой и скорее помогала узнать больше друг о друге, чем являлась средством «замотивировать».
Подготовка ведущего PR
В итоге, мы сформулировали следующие правила подготовки к PR для тимлидов:
- Перед каждым ревью нужно выделить от получаса до полутора часов на подготовку. Лучше готовиться днём ранее, а не в тот же день.
- Пройтись по всем трекерам (тикет-системы, мессенджеры, карма-системы и т.п.), даже если руководителю лень и он сопротивляется, аппелируя к своей прекрасной памяти. Посмотреть заметки с предыдущего ревью.
- Выписать ряд тезисов для обсуждения. Эти тезисы обязательно должны содержать:
- Факты, с обоснованием в виде ссылок на трекеры;
- Личное отношение ревьювера: объяснение, почему он(а) выделил(а) этот пункт, и что в нём такого важного.
Кстати, примеры плохих и хороших формулировок мы выложили здесь.
Процесс PR
Само ревью проходит всегда очно. Несмотря на то, что мы работаем удалённо, ни о каком ревью через документы/опросники/сервисы речь идти не может. В нашем случае общение идёт через Google Hangouts и присутствуют тимлид, инженер, HR и, по необходимости, другие заинтересованные.
Ревью проходит через несколько этапов:
- Разговор об отвлечённом, чтобы настроиться на беседу друг с другом.
- Рассказ о том, что человек сделал хорошего, за что хочется его поблагодарить и объяснить, почему это важно. Мы ведь хотим, чтобы такое хорошее делали и дальше?
- Обозначить однозначно плохое: нарушения договорённостей, дисциплины и прочие вещи, которые вы считаете непростительными и вина по которым неоспорима.
- Обсудить непонятное или спорное по следующим правилам:
- Обозначить факты и личное отношение к этим фактам.
- Задать общий вопрос (вроде «Что ты об этом думаешь?»), чтобы получить больше информации от сотрудника о проблеме.
- Поставить вопрос: считает ли сотрудник, что существует проблема? Может выясниться, что он по каким-то личным причинам не считает это важным. Нам нужно убедиться, что он разделяет наше восприятие.
- Поставить вопрос: что конкретно сам сотрудник собирается делать, чтобы решить проблему?
- Если сотрудник не разделяет вашу проблему, предлагает невнятные решения — высока вероятность, что делать с ней он ничего не будет. И давить в этой ситуации на него бессмысленно — лучше попытаться понять, почему дело обстоит именно так.
- Попросить обратную связь от сотрудника. Соответствовала ли его жизнь в компании за этот цикл его ожиданиям? Если вы до этого действительно смогли выстроить диалог, то на этом этапе получите фидбэк, а не невнятное мычание, как это часто бывает.
- Поговорить о зарплате: повышаете ли вы её, а если нет — что конкретно нужно исправить, чтобы её повысить. Вопрос зарплаты очень важен и сложен и в общем случае является главным мотивом для сотрудника участвовать в Performance Review. Есть подозрение, что нет большого смысла пытаться запустить какие-то процессы ревью, если это никак не влияет на зарплату, но это не 100%…
Итого:
Итоги первого года
Анализ накопленных за первый год записей помог нам:
- приоткрыть завесу тайны личности наших инженеров;
- пополнить базу знаний инструкциями и сведениями, вызывающими больше всего проблем у сотрудников;
- улучшить климат в командах.
Инженеры стали гораздо более ощутимо и быстро расти, у них появилось понимание направления для построения своей карьеры.
Другие знаменательные моменты:
- Более конструктивно стали решаться проблемы у новичков при их адаптации: руководители внезапно для себя обнаружили, что они могут пообщаться с новичком о проблемах… и он исправится!
- Стало понятнее, каких сотрудников мы ждём в компании, поэтому скорректировались требования при найме.
- Самим сотрудникам стало более очевидно, чего от них могут хотеть и какая перспектива развития у них есть.
- Появились наброски на матрицу компетенций, причём есть и механизм постоянной её актуализации.
Портрет инженера
Может показаться очевидным, что инженер, например, должен действительно любить то, чем занимается, и получать удовольствие от работы… Так или иначе — вот четыре навыка, которые оказались самыми востребованными (с большим отрывом):
Другими важными навыками оказались:
Попробуем выяснить во второй год
Тем временем, внимательный к деталям читатель мог заметить, что мы не очень-то измеряли performance… Возможно, со временем устаканится список навыков и оформится годная матрица компетенций, либо мы внедрим какую-то другую систему оценки.
Кроме того, прямо сейчас мы ищем способы поставить на поток обучение проведению ревью среди руководителей — готового решения у нас ещё нет.
Отдельный сложный вопрос, который не так просто формализовать, — это связь системы оценки и вопроса зарплат сотрудников. Как нам кажется, этот вопрос напрямую обусловлен бизнес-моделью компании, и решение для одного бизнеса может не очень подойти для другого. (О нашей модели уже рассказывали на хабре: мы построены почти как франшиза, и по мере роста эффективности и компетентности команды у неё появляются деньги на зарплаты.)
Видео и слайды
Видео с выступления (~50 минут):
Презентация доклада:
P.S.
Возможно, вас также заинтересуют следующие публикации:
- «Как „Флант“ помогает новичкам»;
- «Как „Флант“ нанимает сотрудников»;
- «7 привычек успешных Site Reliability Engineers (по версии New Relic)».
Среди других докладов в нашем блоге:
- «Расширяем и дополняем Kubernetes» (Андрей Половов; 8 апреля 2019 на Saint HighLoad++);
- «Базы данных и Kubernetes» (Дмитрий Столяров; 8 ноября 2018 на HighLoad++);
- «Мониторинг и Kubernetes» (Дмитрий Столяров; 28 мая 2018 на RootConf);
- «Лучшие практики CI/CD с Kubernetes и GitLab» (Дмитрий Столяров; 7 ноября 2017 на HighLoad++);
- «Наш опыт с Kubernetes в небольших проектах» (Дмитрий Столяров; 6 июня 2017 на RootConf).
