KPI для «хакеров»: как в Preply пересмотрели подход к метрикам по разработке

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

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

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

Так что мы отошли исключительно от технических показателей и сосредоточились на том, что действительно важно. На целях. Для этого нужна была прочная система процессов во всей компании. Выбирая среди фреймворков, помогающих каскадировать цели компании на команду, остановились на OKR (Objectives and Key Results). Это означает, что каждые три месяца мы ставим цели, а потом анализируем, как они выполняются или не выполняются и почему. 

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

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

Количество проведённых A/B-тестов – один из самых важных показателей для нас, потому что если из ста тестов будут успешными хотя бы пять, то они принесут по 1% роста бизнеса. Получается, что команда, которая проведёт эти сто A/B-тестов, вырастет на 5% за квартал. Поэтому когда мы решаем, что нужно увеличить бизнес-метрику, то измеряем её запущенными тестами. Preply в этом отношении опирается на глобальную статистику, потому что 70% компаний, по данным Invesp, проводят A/B-тесты как минимум дважды в месяц и считают их ценным инструментом повышения конверсии. 

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

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

• Цель;

• Процесс;

• Человек. 

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

Массовая культура создала образ бездушного и роботизированного «хакера», который никогда не ошибается, не тратит времени на лишние эмоции и функционирует по написанным алгоритмам в обход всех законов психологии. Стоит ли говорить, что в жизни это совсем не так? 

Мои сотрудники очень эмоциональны, я бы даже сказал, ранимы. Они переживают о каждой строчке кода, о каждом A/B-тесте, о каждом баге. Когда удаётся апгрейднуть продукт, мы радуемся так, будто каждый из нас выиграл по миллиону долларов. 

Кстати, о миллионе. Однажды мы потеряли целых 50 тысяч долларов из-за эмоций, а точнее, из-за моей самоуверенности.

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

В итоге, мой «фикс» абсолютно не решил проблему, хотя все думали, что всё решено. Через 7 дней оказалось, что мы потеряли 50 тысяч долларов из-за неправильной атрибуции платного маркетинга. На скриншоте показываю Pull Request, который решает созданную мной проблему и состоит всего из четырёх пробелов. 

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

Если кратко, то эта ситуация показала мне, что СТО не должен писать код, даже когда кажется, что работы на 30 секунд. Нужно полагаться на разработчиков целиком и полностью, и не штрафовать их, если что-то пойдёт не так. У каждого функционала должен быть свой ответственный, который тратит время на создание и/или изменения, а не на переживания «уволят/не уволят» из-за ошибок. В этом и заключается ценность чётких KPI: сотрудники знают, по каким параметрам их будут оценивать и чувствуют безопасность, беря на себя ответственность за решения.

Чтобы не пропустить интересную и полезную для вас статью о малом бизнесе, подпишитесь на наш Telegram-канал, страницу в Facebook и канал на «Яндекс.Дзен».
biz360