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

Дмитрий Волошин

Согласно результатам опроса сервиса GetPrime, около 90% разработчиков считают, что есть точные метрики, способные оценить их эффективность. Например, количество исправленных багов, уровень вовлечения в код-ревью и объем созданного кода.

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

С чего начать

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

Для этого существуют специальные фреймворки: MBO (Management by Objectives), SMART (Specific, Measurable, Attainable, Realistic, Timely) и OKR (Objectives and Key Results).

В Preply мы используем последний — с помощью OKR ставим квартальные цели, а затем анализируем их выполнение. С одной стороны у нас есть Objectives (цели), которых нужно достичь, а с другой — Key Results (результаты), которыми мы измеряем прогресс.

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

Как правильно ставить метрики

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

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

У нас есть правило: если мы не отслеживаем какой-либо показатель, значит его не существует. Numbers are king. Поэтому когда мы празднуем успех, он всегда подкреплен числом.

В то же время сотрудники должны видеть показатели продукта. Тот же опрос GetPrime показывает, что более чем 90% работникам важно, чтобы их метрики были прозрачными.

В процессе развития компании мы всегда меняли метрики и отказались от оценки многих показателей. Конкретно у разработчиков перестали смотреть на количество написанных end-to-end тестов (тестирование на всех уровнях продукта), а в целом в компании — сместили фокус с сухого зарабатывания денег на повышение ценности продукта.

На наш взгляд, самые подходящие метрики — те, которые согласуются с долгосрочными целями бизнеса. Если компания ставит себе цель стать следующим единорогом, то показатели должны четко демонстрировать, к чему придет команда, если в первый год сделает A, во второй — B, а в третий — C.

Исходя из этого, мы верим, что цели нужно каскадировать сверху вниз. То есть, сначала мы ставим задачу на уровне CEO, а затем адаптируем ее для CTO, техлидов и разработчиков.

Как измерять эффективность разработчиков

Изначально мы пытались оценивать работу разработчиков по техническим метрикам. В основном смотрели на количество обработанных pull request и написанных строчек кода. Но эти метрики несут мало пользы, так как девелоперы прежде всего хакеры. Они всегда будут пытаться сломать систему оценки их эффективности.

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

У нас такая метрика — количество проведенных A/B-тестов. Это важный инструмент: по данным Invesp, около 70% компаний проводят их два раза в месяц и чаще, а больше половины считают этот инструмент ценным для повышения конверсии.

Мы в Preply понимаем, что из 100 запущенных одной командой A/B-тестов 5 будут успешными и принесут по 1% роста бизнеса. Дальше можно прогнозировать, что за квартал благодаря этой команде компания вырастет на 5%. Соответственно, когда наша цель — увеличить определенную бизнес-метрику, мы измеряем ее, в том числе, количеством запущенных тестов.

Что делать, если метрики не выполняются

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

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

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

Если дело в процессе, то это задача менеджера — сделать так, чтобы сотрудник мог работать эффективно. Убедитесь, что у работника есть необходимые инструменты, если нет — купите их.

Наконец, проблема может быть в самом человеке. В таких случаях мы не рубим с плеча, hire slow, fire quickly. Мы пытаемся решить проблему человека, и для этого у нас есть несколько методик — начиная с 7 why и заканчивая более сложными техниками.

Источник: vctr.media