Зачем нужны метрики
Ха, самым сложным вопросом оказался вопрос о том, зачем нужны метрики. Я не профессионал в этом деле, поэтому ответ могу дать такой – для того, чтобы вовремя понимать, что происходит с проектом. Наверное даже акцент поставлю – не контролировать ход проекта (для этого есть другие, более подходящие инструменты), а более объективно ощущать, что с ним происходит.
Что я имею в виду? Ведь по логике вещей управление проектом осуществляется на основе проектного плана. А план представляет собой некоторую структуру работ со сроками выполнения и заассайненными ресурсами.
По, казалось бы, логике вещей проектный план, постоянно поддерживаемый в актуальном состоянии, и есть тот артефакт, который должен давать возможность понимать ситуацию на проекте. Но этого не происходит по одной простой причине – в плане нет ничего, кроме ресурсов и работ. Скажу даже больше - совершенно не факт, что структура работ в плане должна дублировать структуру продукта, который необходимо получить в результате выполнения проекта. Она вообще может включать в себя какие угодно задачи, выбираемые менеджером исходя из двух (по большему счету) критериев: соответствие плана принятой в компании методологии работ и удобство планирования (читай – удобство определения временных границ задач и назначения ресурсов) / контроля выполнения задач.
Недостаточность проектного плана как механизма контроля во всей своей красе раскрывается в тот момент, когда руководитель проекта пытается замкнуть цикл Деминга: совершенно ожидаемо получается, что на этапе принятия корректирующих действий план в чистом виде не позволяет сделать ничего, кроме перетасовки людей и игры со сроками. Чтобы принять более мудрые решения, нужно садиться, брать лопату и в поиске причинно-следственных связей зарываться в глубины проекта. А это уже время.
И не просто время, а время, порождающее в цикле управления инерционность. Как следствие – принятие быстрого точечного корректирующего решения становится весьма затруднительным, хотя и возможным.
А правильно выбранная метрика – она как поплавок. Крючок болтается где-то глубоко внутри проекта, а поплавок – вот он, на поверхности. Если все идет нормально, то поплавок тихо лежит. Но стоит чему-то пойти наперекосяк, и поплавок тут-же задрыпыхается. Но ведь мы знаем, где крючок. И понимаем, что причина где-то там-же. Соответственно и реакция быстрее. Как-то так.
