Когда сегодня говорят об инженерных показателях, то имеют в виду показатели, появившиеся в последние десятилетия, которые используются в разработке ПО, такие как DORA или продолжительность цикла PR. Исследования подтверждают, что все они серьезно влияют на процесс разработки.
На самом деле ключевые показатели эффективности (KPI) предназначены для анализа различных процессов и в индустрии ПО нет единого мнения по поводу их использования в разработке. Многие команды разработчиков ПО применяют собственные методы, это затрудняет формулирование каких-то общих правил улучшения процессов разработки и развития продуктов.
Несмотря на это, я считаю, что наступил переломный момент, когда сообщество разработчиков достигло большой консолидации, многие рабочие процессы отлажены и мы лучше понимаем, как должна работать элитная команда. Мне кажется, что в использовании инженерных показателей мы уже перешли от стадии экспериментов к начальной стадии внедрения методики и большинство команд разработчиков от этого только выиграет.
Многое еще предстоит освоить, но преимущества, которые новые методы предоставляют командам разработчиков и менеджерам, игнорировать невозможно.
Эта статья — методическое руководство по работе с инженерными показателями. Если вы никогда их не использовали, то получите основное представление о них и о том, как начать с ними работать.
Вот что мы будем рассматривать:
- 🎯 Назначение показателей — для чего они нужны, а в каких случаях бесполезны. Давайте сформулируем, чего мы можем от их использования ожидать.
- 🚦 Типы показателей — представляем простую классификацию — БВП.
- 🏁 С чего начать — внедрение инженерных показателей в работу вашей команды.
Итак, приступим!
🎯 Назначение показателей
Давайте сразу уясним: никто кроме вас не сможет точно сказать, насколько эффективна ваша команда. Вы можете это выяснить только на собственном опыте. Разработка — это не использование некой абстрактной технологии, а труд коллектива людей, работающих при этом совместно с продакт-менеджерами, дизайнерами и другими участниками процесса.
Таким образом, инженерные показатели не отражают общую картину, они для этого не предназначены.
“Показатели не отражают усилий команды, направленных на создание продукта и на то, чтобы удовлетворить желания пользователей. Эти усилия проявляются в незапланированных улучшениях и в нестандартных возможностях использования продукта.
Также они видны, когда команда помимо выполнения требований, заложенных в проекте, проявляет инициативу. Мне было бы интересно знать, возможно ли это как-то измерить”.
Показатели — это подсказки. Они помогают улучшить процессы и понять, что происходит. 👇
“Не существует единого набора показателей, которые точно показывали бы эффективность, однако несколько показателей, объединенных вместе, помогают понять, как идут дела”.
Я много лет использую инженерные показатели, и вот для чего они наиболее полезны:
1) 📈 Отслеживание тенденций
Иногда сложно определить, на что конкретно повлияли KPI, но можно понять, есть ли улучшения в целом.
Например, количество коммитов за день может ни о чем не говорить, но если за три месяца показатели стабильно снижаются, то не значит ли это, что цикл PR замедлился? Может быть, потому, что у вас слишком много встреч, или потому, что вы просто не успеваете закончить работу?
2) 💬 Повод для обсуждения
Когда вы заметите какую-либо тенденцию, будет легче начать разговор об этом с вашей командой, имея конкретные цифры.
Показатели помогают понять, что происходит в процессе разработки и как это способствует развитию опыта разработчика, а также на что следует обратить особое внимание.
Подобные обсуждения могут быть посвящены разным поводам — от празднования успеха в работе до изучения обстоятельств возникшей проблемы и выяснения ее причины. Что приводит нас к последнему пункту. 👇
3) 📣 Поддержка инициатив
Демонстрация показателей — отличное подспорье для поддержания инициативы. Например, если ваша команда тратит на техподдержку 40% рабочего времени, это веский аргумент в пользу продвижения активностей по сокращению техдолга.
Итак, какие показатели вы должны отслеживать?
📋 Типы показателей
Существуют различные классификации инженерных показателей.
Я использую простую модель БВП, состоящую из трех категорий :
- ❤️ Благополучие — удовлетворенность людей работой. Вы можете это выяснять, проводя опросы в команде и индивидуальные беседы с каждым сотрудником, отслеживать изменения их настроений и так далее.
- ⚖️ Вклад в работу — данные о том, как члены команды распределяют свое время. Это зависит от индивидуального стиля работы каждого сотрудника, поэтому здесь не всегда возможно однозначно сказать, кто распределяет время правильно, а кто неправильно.
- 📈 Производительность — данные об эффективности различных этапов процесса разработки, такие как показатели DORA.
Все эти показатели нужны, чтобы вы получали максимально полезную для работы информацию. Я считаю, что для каждой из категорий вам нужно определить минимально допустимые рабочие значения показателей.
Давайте рассмотрим, что входит в каждую категорию👇
❤️ Показатели благополучия
Задайте себе вопрос, легко ли вам общаться с вашей командой, — думаю, это отличный способ понять, насколько вы хороший руководитель.
Всегда есть что обсудить с коллективом: должностные изменения, CI /CD, на которые уходит вечность, или того парня, который всегда затягивает проверку кода на два дня (привет, Коля!).👋.
Подобные непростые обсуждения приносят пользу, люди чувствуют, что вы всегда готовы помочь им решить возникающие проблемы. Нередко эти беседы начинаются с каких-то жалоб. Удовлетворенность сотрудников работой важнее цифр — вы можете думать, что все идет отлично, но если люди чем-то недовольны, надо принимать меры.
Итак, начать улучшать работу следует не с использования каких-то данных или методик — просто поговорите с сотрудниками! Вот несколько вопросов, которые вы можете им задать:
- Как вы думаете, мы занимаемся чем-то полезным?
- Вы сильно устаете?
- Вы довольны тем, как организовано снабжение?
- Что вы думаете о том, как мы проводим проверку кода?
- Вас устраивает, как происходит взаимодействие с продакт-менеджерами и дизайнерами?
Вы можете обсуждать это по-разному:
- 🗳️ Опросы — можно регулярно проводить опросы команды (например, раз в квартал или два раза в год) чтобы убедиться, что работа идет как надо.
- 🧑🤝🧑 Встречи 1-на-1 — на них люди могут, скажем, раз в неделю делиться своими мыслями и проблемами.
- ↩️ Отслеживание изменений — вы можете устраивать обзоры проделанной работы и обсуждать ее с командой. Я хочу еще раз подчеркнуть, что это незаменимый показатель. Если надо выбрать только один, то это именно он.
“Я рекомендую уделять первоочередное внимание вашей команде, полностью доверять людям, которыми вы руководите, и создавать условия для того, чтобы они были увлечены работой и относились к ней ответственно. После этого можете уделить время изучению других показателей”.
⚖️ Показатели вклада в работу
Эти показатели предназначены для определения, как расходуется время в вашем коллективе. Например, на что уходит больше времени: на техподдержку или на разработку, на внедрение новых функций или на небольшие улучшения. По моему опыту, соблюдение баланса между различными процессами дает невероятные результаты. Таким образом укрепляется взаимодействие с бизнесом и доверие в коллективе и устраняется предубеждение сотрудников по отношению к некоторым видам работы.
На самом деле по своей природе большинство команд склонно к перегибам в работе. Например:
- 📊 Оптимизаторы — сосредоточиваются на небольших улучшениях, а не на крупных изменениях.
- 🏗️ Перфекционисты — тяжеловесные инженерные команды, которые чрезмерно сосредоточены на рефакторинге.
Лучший способ противостоять этому — отслеживать, на что уходит ваше время, и корректировать его. Поэтому я считаю нужным поддерживать баланс между четырьмя направлениями:
- 🩺 KTLO — работа техподдержки (Keeps The Lights On).
- 🔨 Новая разработка — стремитесь разрабатывать новые продукты или функции.
- 🔧 Улучшения — работайте над улучшением существующих функций, а также над увеличением производительности, надежности и безопасности.
- ⚙️ Производительность — старайтесь улучшить работу разработчиков, а также выполнение операций и работу других отделов.
Отслеживание показателей поможет вам оперировать реальными данными и выстраивать баланс в работе. Например, если вы тратите более 30% времени на KTLO, вы можете проанализировать данные, выяснить, что замедляет работу команды и принять меры по исправлению ситуации.
📈 Показатели производительности
Показатели производительности играют важную роль в работе инженеров и помогают определить эффективность работы.
Некоторые из таких показателей, например, DORA (количество коммитов в час), размер коммитов, PRS (показатель совместной работы), могут помочь оценить качество кода и коммуникацию между участниками.
Однако не все показатели полезны для отдельно взятого проекта, выбор должен зависеть от конкретных условий.
Вот мои любимые показатели:
DORA🌟
Николь Форсгрен, Джез Хамбл и Джин Ким провели опрос сотрудников более 2000 технологических компаний в период с 2013 по 2017 год. Опрос касался качества поставок программного обеспечения и был нацелен на определение методов, ускоряющих разработку и таким образом приносящих наибольшую пользу компаниям.
Результаты, опубликованные в сборнике Accelerate, подтвердили два основных тезиса:
- Эффективность доставки программного обеспечения может быть измерена.
- От хорошо организованной доставки программного обеспечения зависит общая эффективность работы.
Исследование Accelerate стало краеугольным камнем разработки программного обеспечения, поскольку подтвердило десятилетия теоретических разработок. В нем определены четыре основных показателя для измерения эффективности доставки, которые сегодня называются показателями DORA:
- ⏱️ Время внесения изменений (Lead Time) — время, прошедшее с начала разработки функции до ее выпуска в производство.
- 🚀 Частота выпуска — как часто организация внедряет код для своего основного сервиса.
- 🔨 Среднее время восстановления — сколько времени требуется для восстановления после простоя или возникших в последней версии проблем.
- 🔥 Частота сбоев — процент выпусков, которые приводят к простоям или серьезным проблемам.
В Accelerate собраны контрольные значения производительности для каждого показателя, определяющие категории элитных, высоких, средних и низких показателей.
Вот три основных вывода:
- Эффективность доставки программного обеспечения имеет значение. При высокой эффективности компания может получить прирост рыночной капитализации до 50%, а показатели могут быть вдвое выше запланированных. Это приведет к более эффективному управлению бизнесом.
- Скорость и стабильность не являются взаимоисключающими. Благодаря высоким показателям удается получить лучшие результаты по всем параметрам. На самом деле высокая скорость доставки — гарантия стабильности, так как обеспечивает быстрое восстановление после сбоев.
- Разрыв между высокими и низкими показателями огромен, иногда он достигает разницы в 100 раз по одному показателю. Есть компании, внедряющие программное обеспечение несколько раз в месяц, в то время как другие компании того же уровня, обладающие такими же технологическими ресурсами, делают это несколько раз в день.
В последующие годы той же командой Accelerate были проведены дополнительные исследования и опросы, с которыми вы можете ознакомиться на сайте DORA.
Время цикла 🔄
Если бы из четырех показателей DORA пришлось для начала выбрать один, это было бы время выполнения изменений, которое чаще называют временем цикла.
Зачем измерять именно это, а не что-то другое?
Время выполнения (Lead Time) включает этапы анализа и проектирования, продолжительность которых может сильно варьироваться в зависимости от масштабов инициативы. Однако как только сама инициатива будет разбита на несколько понятных результатов, то процесс реализации должен осуществляется короткими и предсказуемыми циклами, ценность от которых проще измерять.
Время цикла, вероятно, является сегодня самым популярным инженерным показателем и на то есть веские причины. Фактически этот показатель обладает всеми признаками важнейших ключевых показателей эффективности:
- Это объективный показатель, для его интерпретации не нужен контекст, вы точно знаете, что он означает.
- Его легко понять, объяснить, обсудить с руководством, поскольку это своего рода инженерный эквивалент показателей цикла продаж и продуктовой воронки.
- Он остается актуальным по мере роста компании — не зависит от размера команды.
- Он действенный и не должен сильно колебаться. Значительное его увеличение обычно указывает на конкретные проблемы, которые должны быть выявлены и решены.
Оптимальное время цикла в реальных сценариях — в пределах пары дней. Дальнейшие улучшения — это прекрасно, но я заметил, что стремление уменьшить его до одного дня снижает отдачу.
Разбивать работу на небольшие этапы важно, но существует оптимальная продолжительность каждого этапа, дальнейшее уменьшение которой не приводит к увеличению эффективности работы. Так что оптимизировать время цикла — это нормально, но я бы не стал зацикливаться на сокращении его до нескольких часов.
🔍 Время цикла PR
Время цикла PR (Pull Request)— это агрегированный показатель, который объединяет несколько этапов процесса разработки.
При увеличении масштаба проекта критическим показателем для большинства команд является время цикла PR — среднее время, которое проходит с момента открытия PR до момента слияния с мастер-веткой.
Вы можете подумать, что это очень специфичный показатель по сравнению с теми, которые мы обсуждали ранее. Я включаю его, потому что по моему опыту проверка кода (Code Review) часто оказывается самым узким местом в разработке программного обеспечения.
Меня всегда поражает, когда команды прилагают героические усилия, чтобы сократить CI / CD на 10 минут, а затем совершенно спокойно несколько дней ожидают, пока код пройдет проверку.
🤷♂️ Скорость
Скорость заслуживает почетного упоминания, потому что это по-прежнему самый известный инженерный показатель, поэтому я счел необходимым сказать о нем несколько слов. И вот эти слова: стремление все сделать быстро не очень полезно.
По моему опыту, этот показатель может принести ограниченную пользу при планировании работ — вы можете использовать его для приблизительного определения размеров, но не более; в отношении всего остального он просто вводит в заблуждение.
Факты таковы:
- Это не показатель производительности — вы не можете оптимизировать скорость работы; по крайней мере, она будет нестабильна. Поскольку баллы за историю (или размеры футболок) произвольны, люди в конечном итоге просто завышают баллы. И это не потому, что люди злые, это естественная, даже бессознательная реакция на плохой способ определения производительности.
- Показатель скорости одной команды может совершенно не подходить для другой — из-за индивидуального подхода к оценке.
- Скорость - высокоуровневый показатель: если вы набираете плохую скорость в спринте, довольно сложно выяснить, что пошло не так, как, например, с помощью времени цикла.
Итак, как начать использовать показатели в работе с учетом всего вышесказанного?
🏁 Как начать работу с показателями
Давайте сразу проясним: использование показателей — это большая работа. Это верно для любых показателей, не только инженерных. Фактически для каждого отдельного KPI, который вы решите отслеживать, вы должны:
- Осуществлять контроль регулярно — это главное. Вам придется постоянно изучать показатели на панели мониторинга, анализировать их и соотносить с текущей работой.
- Обсуждайте производительность работы с коллективом — инженерные показатели лучше всего изучать вместе с командой. Ваши сотрудники имеют наиболее полное представление о том, как идет работа. Если вы проигнорируете этот совет, вы не только будете хуже понимать, что происходит, но и команда начнет к вам относиться со скепсисом. Не превращайте показатели в “менеджерские штучки”.
- Предпринимайте действия для улучшения работы — разговоры бессмысленны, если вы этого не делаете. Когда возникают проблемы, вам следует находить способы их решения.
Это непрерывный процесс: вы изучаете показатели, обсуждаете их с сотрудниками, выясняете, что можно улучшить, снова анализируете ситуацию, опять обсуждаете и так далее.
Начните с малого. Вот минимальный набор показателей, которые я бы порекомендовал использовать: 👇
1) Расспросите людей, удовлетворены ли они работой ❤️
Поговорите с сотрудниками: инженерами, менеджерами, прочим персоналом,не только техническим. Выясните, какие проблемы мешают им работать.
Вы можете побеседовать с каждым индивидуально, но я также рекомендую проводить обсуждения со всей командой. Сконцентрируйтесь,например, на проблемах DX и отдельно на аспектах бизнеса. Запишите основные проблемы, о которых говорят все.
2) Выберите один показатель 🤏
Начните с одной из обнаруженных вами проблем и выясните, как ее измерить. Вероятно, вы сможете найти какие-нибудь ключевые показатели эффективности, связанные с нею.Вот некоторые подсказки как это сделать:
- Работа идет слишком медленно → время выполнения (Lead Time) или цикла.
- Не знаете, как распределить свое время → баланс вклада в работу.
- Медленный или нестабильный процесс выпуска → показатели DORA.
- Неверные результаты → показатели внедрения функций.
Возьмите за правило делать это регулярно (например, раз в две недели).
Вначале сосредоточьтесь на том, чтобы добиться улучшения, а не какого-то окончательного результата. Гораздо важнее запустить правильно процесс, а не достичь конкретной цели.
3) Меняйте фокус 🔄
В более долгосрочной перспективе (например, раз в квартал) решайте, стоит ли продолжать прикладывать усилия для улучшения этого ключевого показателя или следует переключиться на другие важные задачи. Не забывайте общаться с коллегами, чтобы быть в курсе событий и находить новые решения. Возможно, придется уделять больше внимания некоторым этапам процесса, требующим вашего участия, и отслеживать множество ключевых показателей.
