Команды разработчиков являются сейчас менее монолитными и управляемыми, чем когда-либо. Почти 70% открытых инженерных позиций в разработке, гласит недавнее исследование, допускают дистанционный формат. Коллектив программистов типичной компании представляет собой пестрый конгломерат удаленных сотрудников, специалистов с гибридным и свободным графиком, фрилансеров. Встает вопрос: как в этих условиях IT-менеджменту создать единую систему оценки результативности?
Система управления результативностью команд
На первый взгляд, ответом на вопрос о создании системы отслеживания и повышения результативности служит внедрение специальных стандартов в этой сфере, усиленное программными продуктами автоматизации управления по соответствующим стандартам. Сводов лучших практик и связанного с ними программного обеспечения, которое «встраивает» соответствующие требования в процессы, избавляя эту сферу от человеческого фактора, достаточно много. В качестве примеров можно привести Scrum, DORA (DevOps Research and Assessment).
Работа большинства из таких систем построена на циклах регулярно повторяющихся действий. Частично автоматизированных, а частично требующих внимания руководства. Циклы, независимо от использованной концепции менеджмента результативности, всегда включают следующие стадии:
- планирования;
- сбора информации о текущей ситуации с результативностью разработки (tracking);
- действий по изменению текущих процедур, чтобы добиться более высокого результата на следующем витке цикличных действий.
Информацию о результативности команд программистов в целом и отдельных инженеров, можно получать из многочисленных сред разработки, которые используются для поддержки проектов и оркестровки коллективной работы.
Ситуация любой технологической и технологической компании уникальна. В методологиях, вроде DORA, конечно, есть обобщенные рекомендации: например, измерять количество заливаемого на сервер кода (deploy frequency), однако этот и другие критерии не получится применить автоматически, без адаптации под специфику вашего коллектива. Практика показывает, что если отслеживать производительность отдельных разработчиков только по количеству кода, то они построят под изменившуюся ситуацию свою работу. Но не так, как вы этого ожидаете. Приоритет будет отдаваться простым задачам, так как их можно выполнить быстро. Тем временем, написание сложных приложений будет тормозиться, хотя, возможно, именно эти модули в проекте могли бы вывести бизнес в целом к новым горизонтам.
Оценка и повышения результативности: как подобрать ключевые метрики для анализа?
Чтобы адаптировать универсальные подходы под ситуацию конкретного бизнеса и конкретного коллектива разработчиков, необходимо общие критерии, вроде того же количества кода, дополнять рядом более тонких метрик. Сравнение между собой их показателей позволит сделать правильные выводы и разработать действенные меры повышения результативности. Наряду с таким показателем, как количество кода, который разработчик «заливает» на сервер, можно использовать, если это уместно в вашей ситуации, метрику MLTC (Mean Lead Time for Changes), которая показывает среднее время внесения разработчиком коммитов, то есть изменений в кодовой базе. Также картину дополнит так называемое время цикла разработки (Cycle Time).
С помощью этого показателя измеряют время между двумя любыми этапами производства программного обеспечения. Во многих случаях пригодится измерять «время открытия» (time to open). Это ни что иное, как время между pull request (термин из Git), то есть запросом от руководства на внесение изменения и первым коммитом (то есть «заливкой» кода от разработчика в ответ на запрос). В отдельных случаях показательными будут статистика «мерджей» (Time to Merge) – объединения локально готовящегося кода с общим проектом на боевом сервере, а также Time to First Review. Это время от заливки кода до code review, то есть оценки со стороны руководства того, что разработчик написал. Приведем несколько примеров того, как сравнение показателей ключевых метрик, которые вы выбрали, помогает провести анализ и разработать улучшения, которые повысят результативность.
Ежегодные отчеты по результативности vs квартальные KPI
Это полезные метрики, которые позволяют возвращаться к вопросу результативности через достаточно большие промежутки времени и рассматривать динамику в общем, перспективно и на стратегическом уровне. Сравнение квартальных KPI результативности с годичным показателем покажет “big picture” производительности инженерной команды. C другой стороны, многие руководители ошибаются, полагая, что этих стратегических показателей для управления результативностью.
Разработчики знают, что ежегодный отчет используется для формирования премий по результатам работы, поэтому его использование скорее носит контрольный, чем управленческий смысл. Суть менеджмента результативности в воздействии на процессы, а не в контроле и фиксации проблем в чьей-либо работе. Поэтому кроме крупных показателей нужны и метрики, измеряющие, что происходит каждый день, при каждом изменении проекта, дают ситуацию в разрезе под необычным углом, который дополняет картину.
Процент мерджей в pull requests vs процент pull requests, которым уже провели code review
Сравнение данных двух коэффициентов по отдельным разработчикам и целым командам дает взаимосвязь между двумя важнейшими сторонами разработки. Во-первых, это написание и заливка кода, чем занимаются программисты, занятые написанием проекта. Во-вторых, проверка внесенных в код изменений и дополнений со стороны руководства. Сопоставление двух показателей способно показать, например, не тормозит ли процесс проверки процесс разработки. Таким образом можно сделать и много других важных выводов.
Review Coverage (покрытие кода code review) vs Review Influence – воздействие code review
C RC все понятно, ведь эта метрика просто показывает, по какому количеству кода тим-лид или технический директор разработчиков успевает дать обратную связь. RI – сложный показатель, который вычисляется экспертным способом. Есть несколько альтернативных способов его получения. Так или иначе, пропорция RC и RI дает исчерпывающее представление о том, насколько code review в проекте трансформируется в рефакторинг, то есть улучшение кода программистом.
Периодичность code review (Review Cycles) vs Cycle Time (время цикла)
И снова благодаря сравнению времени, которое пошло на преодоления очередной стадии подготовки приложения или программного продукта и времени между code review мы может получить представление об эффективности управления процессом разработки. Виновен ли менеджмент в том, что производительность программистов хромает?
Impact vs Коэффициент переделок в проекте
Impact – это также экспертный показатель, в вычислении которого для которого для отдельного разработчика и целой команды участвует несколько переменных. Для получения этого аналитического коэффициента служит специальная процедура – impact mapping. Impact показывает влияние конкретной работы на судьбу проекта в целом. Будучи полученным, этот индекс может быть сопоставлен с данными о переделках и изменениях в определенном проекте. Вы узнаете, насколько изменения мотивированы и продвигают проект вперед. А может быть, они – сигнал наличия проблем?
Другими важными метриками, которые могут пригодиться той или иной компании, в зависимости от специфики ее работы, служат Change Failure Rate, Consistency of Story Point Delivery, DevEx, ряд других критериев и показателей.
Анализ метрик: что делать с выводами?
Сопоставление метрик дает возможность провести анализ. И в Scrum, и в других методологиях, он проводится на стадии планирования, но после сбора статистики о ходе процессов разработки. Далее следует выработка мер повышения результативности. Тут крайне важно правильно осуществлять коммуникацию с коллективом. Независимо от того, является ли ваш офис виртуальным, в котором все разработчики трудятся удаленно, или у вас есть специалисты в офисе и на фрилансе, для всех одинаково хорошо должна быть налажена система донесения обратной связи по результативности.
Чтобы убедиться в эффективности коммуникации по этому вопросу, менеджменту следует поддерживать адекватные диалогические формы взаимодействия с коллективом: Планерки, опросы, беседы. Вдобавок, коммуникация должна быть стандартизированным процессом, чтобы ее результат был стабильным и приводил к тому, что инженеры понимают обращенные к ним требования. Разумеется, такие формы коммуникации возможны только в среде, где ошибки – не преступление, а руководство помогает работать, а не ищет виновных.
Параллельно стоит внедрить систему УРВ, принимая ее данные во внимание, и не делая их решающими.
И последняя ремарка!
В заключении стоит напомнить о существовании консалтинговых компаний в сфере внедрения программного обеспечения и стандартов повышения результативности разработки. Стоит сразу определить, есть ли у руководства возможность проделать всю вышеописанную работу с достаточной тщательностью. Если нет, возможно, правильным решением будет передача этих функций внешним консультантам на договорной основе.
Главное, чтобы мероприятия по повышению результативности сами оказались результативны.
Попробуете систему в деле? (это бесплатно)
👉 Щелкните здесь, чтобы создать аккаунт 👈
Пробная версия доступна сразу же после создания аккаунта + мы пришлем письмо с подробными инструкциями.
