Свой первый отчёт с данными о работе процесса в ИТ я сделал где-то в самом конце 90-х годов. Я тогда работал в поддержке, мне было важно понять как быстро мы выполняем заявки, сколько заявок приходит от какого филиала, сколько распределяется на какого специалиста поддержки, что чаще всего ломается и требует внимания. Понять объективно, а не в ощущениях. И понимать регулярно.

Нет, я не помешан на метриках и отчётах. Знаю много случаев, когда управленческие решения принимаются вовсе без данных, и оно срабатывает. Что уж там говорить, с 2009 года, когда появилась компания, мы в нашей компании принимаем сотни решений каждый год, и только часть из них основана на каких-либо измеримых показателях.

С другой стороны, всегда, когда речь идёт про часто повторяющийся процесс, опирающийся на труд персонала, я агитирую за наличие разумного набора метрик. Так можно убрать разрыв между «я думаю» и «на самом деле», так можно увидеть где теряются деньги и другие ресурсы, так можно проще запустить процесс и сделать его лучше. Вот почему в первых же консалтинговых проектах в 2005-м мы с клиентами проектировали для каждого процесса метрики его эффективности, производительности и прочего. Вот почему сейчас для каждой новой команды разработки ПО вопрос измерения я с клиентами начинаю обсуждать как только речь заходит об организации работы. Без фанатизма, а как один из инструментов наладки.

Кроме метрик, вторая моя любимая тема — поток создания ценности. Этой идеей я увлёкся намного позже, когда до меня, наконец-то, дошло, как можно построить работающий (а не декларируемый) поток в интеллектуальной работе по разработке программного обеспечения. Спасибо ребятам из IT Revolution, они (в числе прочих) помогли мне сложить для себя новую, понятную, непротиворечивую и весьма прикладную картину мира. Многое встало на свои места. Несколько десятков команд мы помогли организовать по принципам потока создания ценности и я вижу, насколько мощный это инструмент.

Опять же, без фанатизма. Никто никого ни в какую религию не конвертирует. Просто так удобнее и комфортнее — как для «заказчиков», так и для самой команды.

Теперь складываем первое (метрики) и второе (поток), получаем странность. На словах, методически, всё очень понятно: если строишь поток, то будь добр его измерять и действовать в том числе на основе данных. На деле всё спотыкается о следующее:

• тим-лиды не всегда понимают зачем нужно измерять поток и как это им поможет;

• команды не всегда понимают как именно измерять поток и почему этим должны заниматься они, а не какие-то специальные люди;

• руководители, особенно в Enterprise, не всегда понимают вообще что такое поток и как можно им управлять, тем более на основе данных;

• методологи, коучи и Scrum-мастеры переоценивают свои знания, не распознают базовые паттерны, разглядывают множество диаграмм вместо трёх-четырёх ключевых;

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