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

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

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

Типы метрик

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

Качественные метрик

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

Многие компании-разработчики программного обеспечения используют NPS (Net Promoter Score) для измерения удовлетворенности клиентов. Анализ метрик, ориентированных на клиентов, гарантирует, что ваша команда разработчиков программного обеспечения будет приносить пользу бизнесу и клиентам.

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

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

Есть несколько причин, по которым они могут работать плохо. Некоторые из них:

• Отсутствие вовлеченности  в работу (нет интереса к технологиям, к целям команды)

• Другие личные вопросы, влияющие на них

• Нет чувства принадлежности к своей команде

• Не владеет необходимой компетенцией

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

Возможные действия:

• Дать возможность перейти в другую команду или проект

• Дать сотруднику перезарядку

• Обеспечить соответствующее обучение / ресурсы для повышения его квалификации

• Соединить его с другими более опытными инженерами

• Предоставить ему меньший объем работы

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

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

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

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

Это всего лишь один пример того, насколько важна качественная обратная связь для выявления проблем и эффективной работы с ними.

Количественные метрики

Второй тип метрик - количественные. Их можно представить численно и получить научно.

Примеры количественных метрик, которые можно использовать для измерения/управления качеством, доставкой и производительностью при разработке программных продуктов:

Время доставки:

• Время цикла (время от начала до завершения разработки)

• Время выполнения заказа (время от создания задачи до её доставки конечным пользователям)

Качество:

• Процент дефектов

• Процент покрытия тестами

Время безотказной работы (надежность):

•  Задержка

•  Время на восстановление

•  Время обнаружения инцидентов (среднее время до обнаружения)

•  Время восстановления после инцидента (среднее время восстановления)

Скорость доставки:

•  Средний возраст закрытых багов 

•  Производительность команды

•  Количество релизов

•  Количество завершенных story points

•  Скорость завершения story

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

С чего начать

Ниже приведены рекомендуемые шаги по составлению метрик для вашей команды инженеров.

• Начните с цели - примером вашей цели может быть доставка надежных функций с более высокой скоростью.

• Подумайте, какие метрики в рамках своей цели вы хотите измерить и как вы хотите их измерять. После определения метрик, которые будут соответствовать поставленной перед командой инженеров цели, важно отслеживать их постоянно. Без отслеживания метрики будут бесполезны. 

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

• Соберите инструменты и механизмы. Доверяй, но проверяй. Автоматизация и оповещения, Slack, Если Это Значит То (If This Then That - ITTT) для настройки умных оповещений.

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

• Продолжайте следить, анализировать и улучшать!

Для вас подготовил перевод Никита Ульшин, Team Lead & JS-разработчик, веду блог ulshin.me и ТГ-канал @ulshinblog.

Комментарии, пожелания и конструктивная критика приветствуются :)