company_banner

Performance Review и выявление тайного знания (обзор и видео доклада)



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

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

    Зачем Performance Review?


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

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

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

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


    Как оказалось, нет. Даже если у вас есть описания вакансий сотрудника более высокого уровня, нельзя просто взять набор ключевых слов из неё и сказать, что это и есть необходимые шаги для повышения карьеры. Если вы скажете сотруднику: «Выучи 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 для тимлидов:

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

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



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

    Процесс PR


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

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

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

    Итого:



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


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

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

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



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

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

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


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



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



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


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

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

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

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


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



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



    P.S.


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


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

    • +41
    • 6,9k
    • 8
    Флант
    724,45
    Специалисты по DevOps и Kubernetes
    Поделиться публикацией

    Комментарии 8

      0
      На словах-то всё отлично. Но многие люди не любят, когда с ними говорят начистоту, вслух называя очевидные мотивы их поведения.
      Вот на планёрке я скажу:
      "- Пользователи жалуются, что на главной форме слишком много вкладок с фильтрами. Предлагаю доработать UI, сгруппировав вкладки по смыслу.
      — Это слишком долго, я просто выделю их цветами, по смыслу.
      — Ты предлагаешь пользователям наждачную бумагу вместо туалетной ежедневно терять сотни человеко-часов на копание во вкладках, чтобы самому не тратить четыре часа на UI? Я понимаю, что для тебя это гораздо проще и быстрее, но такое отношение к нуждам пользователей не приведёт нас к хорошему продукту".
      И затаит разраб на меня злобу. За то, что я вскрыл его лень и наплевательское отношение к пользователю истинные мотивы.
        0
        Да, и у нас есть люди, которым тяжело говорить открыто о том, что у них на душе. И как правило руководители прекрасно знают об этом. И либо человека увольняют из-за несовместимости, либо знают к нему подход.
        Поговорить откровенно и так, чтобы человек действительно принял фидбэк — сложно.

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

        — Это слишком долго, я просто выделю их цветами, по смыслу.
        — Скажи, пожалуйста, а почему ты хочешь выбрать такой путь? Мне кажется, это усложнит жизнь нашим пользователям, ведь они будут тратить много времени на копание во вкладках.
          0
          Вот Вы реально думаете, что тот, кто бьёт Вас лопатой по голове, не понимает, что делает Вам больно? Да понимает он, просто ему плевать на Вашу боль.
          Всё ему объяснили. И почему пользователю не подходит механизм сокрытия вкладок — тоже (потому, что каждый раз — новая задача, и пресетов не напасёшься).
          Он ничего не слышит, ибо ему не «прилетит», пока кто-то не озвереет и не напишет гневное письмо.
          0
          Я всегда, когда человек теряет ориентир для чего ему поручается это делать — говорю: Давай ты этим освободишь людей от проблемы ххх, чтобы они нам больше денег для нашей зарплаты принесли. И указываю, как это повлияет на денежный поток нам.
          Я вообще удивляюсь, когда люди делают фичи ради фич, или ставятся такие задачи без понимания того, как эта штука принесет больше денег.
          И конфликта тут никакого не возникает — ему не на лень указали, что является не очень хорошей практикой, так как лень — двигатель прогресса и за неё ругать не стоит. А указали на важность этой задачи в рамках всей деятельности фирмы.
            0
            Фичу делает разраб, а деньги сэкономит техподдержка. И ошибок станет меньше, а прибыль от операций — больше. Никогда мы не увидим тех денег! И что, делать эту фичу не надо?
            Если главные разработчики станут реагировать лишь на деньги, что идут к нам или бьют нас по карману, то компании — каюк.
              0
              Если человек на окладе и его ЗП не зависит от его усилий, то только его собственное удовольствие от того, что пользователи благодарны ему за доработку, способно мотивировать.
              Если ему «обыдро» кодить и удовольствия нет, значит ему не подходит окладная система оплаты. Ну и не вижу здесь работы руководителя, который ставит задачу, а подчиненный идет делать вместо споров.
                0
                Нет, не похоже, что обрыдло. Просто есть более приятные задачи, чем копание в legacy-коде.
                А руководители у нас не любят, когда ты часто ходишь к ним за стимулированием кого-либо. К тому же, выходит, что ты капаешь на своих товарищей. Типа, выскочка, больше всех надо.
                Вот и живём, как в британской семье: семейное счастье на грани инфаркта. :-)
                  0
                  Ну тогда я не вижу, чтобы у вас использовалась система постановки задачи, тикеты там или задачи.
                  Как и работы UI разработчика, который и должен брать на себя постановку задач по интерфейсам.
                  В общем, знакомо. Когда минуя меня ставятся задачи программистам на моей работе, происходит так же. Программист делает, берет деньги, но этим не пользуются, так как сделаны пункты ТЗ(конкретные функции) а не взаимодействие с пользователем.

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

        Самое читаемое