3 показателя продуктивности любой команды по разработке

0
885
views

Перевод статьи “3 simple productivity metrics for every software team”.

Команда и показатели продуктивности

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

Но когда речь заходит об измерении продуктивности команды, все становится очень печальным. Скорость, выработка, сроки разработки, продолжительность цикла, MTTR (среднее время восстановления работоспособности), охват… Недостатка показателей не наблюдается, но они зачастую технические, зависящие от сферы деятельности и тяжелые для понимания.

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

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

Частота выпуска: насколько часто вы поставляете улучшения своим клиентам?

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

Итак, первый вопрос, который можно задать команде, это как часто вы вручаете изменения клиентам. Это важный показатель по многим причинам. Прежде всего, это сказывается на конкурентоспособности. Технологии полностью изменили темп внедрения инноваций, и теперь у нас есть компании, которые могут за пару лет разрушить отрасли, существовавшие десятилетия (Uber, Airbnb, Netflix). Чем чаще вы получаете обратную связь касательно ваших идей, тем больше у вас данных для улучшения своего продукта.

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

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

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

Иногда команды могут поставлять код часто, но изменения, идущие в продакшн, перед этим выдерживаются несколько недель на промежуточном этапе. Для этого могут быть уважительные причины, но я бы уменьшал время, которое уходит на то чтобы разработчик узнал, как его работа влияет на прод. Так вы не только минимизируете неудобство переключения разработчиков с одной задачи на другую. Это также хороший старт для прививания лучшей DevOps-культуры.

Движение DevOps это понимание того, что команды действуют более эффективно, когда они разделяют ответственность производственного окружения, а не просто перебрасывают код через стенку Ops-команде. Короткое время цикла позволяет вам изменить понимание слова «сделано» с «вы достигли стадии…» на «ваш код в руках потребителей». Это тонкое, но критически важное различие, которое помогает фокусироваться на пользователе и повышать качество работы.

Баги/пользователь

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

Чтобы убедиться в том, что вы движетесь быстро, но не ломаете все вокруг (по крайней мере, не слишком сильно), вы можете воспользоваться простой формулой. Возьмите число багов, обнаруженных или таких, о которых сообщили в продакшене, и разделите на общее число пользователей вашей системы.

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

Целое лучше, чем сумма его составляющих

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

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



ОСТАВЬТЕ ОТВЕТ

Please enter your comment!
Please enter your name here