Нужны ли метрики? Казалось бы, вопрос очевидный. Старая азбучная истина: «Если Вы не можете что-то измерить, то Вы не можете этим управлять». Тем не менее, хочу еще раз проговорить ответ на него, поскольку отсутствие метрик является одной из самых распространенных проблем в российской ИТ-среде.

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

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

Даже первые уточняющие вопросы ведут к интересным результатам. Если спросить менеджеров ИТ про скорость их работы, то они скажут, что не мерили и не знают, какая она сейчас и какая должна быть. А вот Заказчики сразу скажут: «Заявки в бэклоге висят по 2 года без движения. А сам бэклог на 5 лет вперед расписан».

Получается, Заказчики все-таки оперируют метриками. И эти, хорошо понятные им метрики: размер бэклога и время нахождения задач в бэклоге.

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

Как посчитать срок выполнения задачи? Для этого нам, как в школьной задаче с автомобилем, который движется из пункта А в пункт Б, надо точно знать: Скорость выработки и Размер бэклога.

Размер бэклога мы можем оценить экспертно. Скорость выработки мы можем оценить по факту, если будем замерять Фактические трудозатраты разработчиков и соотносить их с объемом сделанной работы и затраченным временем.

Учет фактических трудозатрат важен по нескольким причинам. Во-первых, как уже говорилось выше, Вы сможете рассчитать скорость выработки Вашей команды. Во-вторых, Вы сможете численно оценить отношение полезной работы к вспомогательной. Ваши разработчики, помимо разработки ПО, участвуют в совещаниях, обучениях, передаче опыта, отпусках и другой деятельности, которая также важна и которую нельзя отменить. Но она «отъедает» время от полезной работы. Вы знаете, сколько Ваши люди на самом деле занимаются разработкой, а сколько – другой работой?

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

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

Третий аргумент – обоснование тех или иных действий для вышестоящего руководства.

И, наверное, самый интересный из всех аргументов в пользу метрик – это их влияние на людей, на их восприятие собственной работы и постановку личных приоритетов. Люди подстраивают свое поведение под то, как их оценивают.

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

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

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

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

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