Про метрики: как эффективно управлять несколькими проектами
Вы тимлид, и у вас полный порядок с проектом. А если проектов будет несколько? Сможете сохранить контроль?
У Delivery Manager-а уже не один проект, приходится гораздо меньше погружаться в каждый. Контекст не тот, времени меньше, да еще и управлять приходится не самому, а руками тимлида.
В такой ситуации нужна хорошая система контроля. И лучше всего с этой задачей справляются данные — метрики. Про выбор метрики и их эффективность предлагаю почитать в этой статье.
Привет! Меня зовут Илья Прахт, я тренер в OTUS и руководитель нового курса Delivery Manager. Я прошел классический путь тимлид → Delivery Manager → CTO, и прекрасно помню чувства, которые испытывал на каждом переходе.
Особенно ярко помню переход на роль Delivery Manager-а: у тебя теперь свой портфель проектов и за каждым нужно следить. А времени и ресурсов, чтобы делать это также, как раньше, не хватает. И вот ты пытаешься балансировать между микроменеджментом и полной свободой. Иногда получается, иногда — нет. Но все это ненадежно.
Я для себя нашел решение в метриках. Тема довольно заезженная, холиварная. Кому-то они подходят, кто-то от них плюется. Данные — это просто данные. Важно уметь их правильно интерпретировать и использовать. Вот про это сегодня и поговорим.
Проект vs Портфель
В чем разница управления проектом от управления портфелем проектов? Если упростить, то есть 3 основных различия:
Степень погружения — невозможно ходить на каждый дейлик, быть в постоянном контакте с командой, ревьюить каждый пулл-реквест. Приходится ограничивать свой «квант внимания» к каждому проекту, что неминуемо приводит к потере информации.
Управляемость — вы теперь не сами принимаете решения и тут же их имплементируете. Теперь вы управляете тимлидом, а уже он управляет проектом. В управлении тимлидами есть свои особенности, мы подробно разбирали их в этой статье. Но главная идея в том, что между вами и проектом есть еще один уровень менеджмента.
Доверие — дефицит доверия гораздо выше. Это, во многом, следствие первых двух пунктов: не получается держать под контролем всю информацию, не получается нормально по-старому управлять проектом. Как итог — вообще непонятно, команда справляется с работой или им уже нужна помощь.
Чаще всего это выливается в 2 крайности: микроменеджмент или полное делегирование, без попыток хоть как-то следить за проектами. И то, и то — не то. А нужно что-то между, некоторый баланс между этими двумя состояниями.
Есть несколько вариантов, как этого добиться. Давайте их разберем.
Варианты управления портфелем проектов
Вариант 1 — Верить «наслово»
Основа модели — постоянная коммуникация с тимлидом и другими участниками команды. Таким образом складывается ваша собственная картина по состоянию дел на проекте, и можно принимать грамотные решения. Проблемы тут две.
Первая проблема — очень много времени тратится на разговоры. И заметьте, не только вашего времени. Вам же еще и команду приходится постоянно отвлекать.
Вторая проблема — как говорил доктор Хаус: «Все врут». Не-не, я ни в коем случае не хочу сказать, что тимлиды хотят вас обмануть. Может и не хотят. Но они будут доносить до вас свою точку зрения, субъективную реальность. И далеко не факт, что она совпадает с реальным положением дел. Так уж вышло, люди бывают излишне оптимистичны.
Вариант 2 — Масштабированная методология
Многое уже давно придумано, велосипед изобретать не стоит. Фреймворк SAFe может помочь в данном вопросе. Из наиболее популярных методологий здесь LESS, Scrum of Scrums и т п. На мой взгляд, решение едва ли не идеальное. Но есть в нем серьезный такой недостаток.
Взять ради примера Scrum of Scrums. Он будет работать, только если во всех проектах портфеля развернут канонический Scrum. Во всех остальных случаях получаем игрушку с напильником. И получится ли в итоге сделать работающий процесс — большой вопрос. Может — да, может — нет. И главное преимущество — взять готовое решение из коробки, сразу же разваливается.
Вариант 3 — Система метрик
Метрики универсальнее. Здесь можно выбрать такой набор метрик, который будет доступен на всех проектах портфеля, какими бы разными они ни были с точки зрения управления. При должной сноровке можно даже собрать под единый интерфейс проекты на Scrum-е, Kanban-е и водопады. Не скажу, что задача простая, но выполнимая.
При этом, сбор метрик можно автоматизировать. Можно собрать все показатели в единой системе и строить на базе них графики и дашборды. Что дает ту самую объективную картину реальности без необходимости тратить кучу времени самому руководителю, и отвлекать для этого команду.
Конечно, проблемы есть и здесь. Я бы выделил две основные: отсутствие готового решения и сложность реализации. Здесь приходится самому выбирать метрики, самому выстраивать процесс их сбора и контроля. Есть разные рекомендации, но это только советы. А готовых рецептов, к сожалению, практически нет. Помогают методологии, которые используются в проектах. Но это не все фокусы, за которыми нужно следить.
И тем не менее, если у вас разные проекты и нужно построить общую систему для их контроля, лучшим вариантом, на мой взгляд, будут метрики.
Построение системы метрик
Шаг 1 — Выбрать метрики
Как выбрать метрики для своих проектов? У меня есть 2 рекомендации по этому поводу:
Не изобретать велосипед.
Убедиться в сбалансированности.
Начнем с первого. Великое множество метрик уже давно придумано до нас. Не меньшее множество метрик уже давно реализовано в популярных информационных системах. Взять ту же Jira — все, что касается метрик Scrum-а, Kanban-а, уже собирается в ней, если настроить правильно проект. Вот этим и нужно в первую очередь пользоваться.
Основные метрики Scrum:
Аккуратность оценки зада;
Burnout time — время сгорания;
Velocity — скорость команды;
Estimated time of delivery — оценочное время поставки.
Основные метрики Kanban:
Lead Time — время, которое задача проходит от момента создания до релиза;
Cycle Time — время, которое задача проходит от момента старта работ до релиза;
WIP — количество задач/SP в работе;
Wasted Time — время, которое задача находится в ожиданиях;
Effectiveness — время, которое задача находится в полезной работе;
Throughput — пропускная способность команды.
Основные метрики PMBOK:
Плановый объем бюджета;
Освоенный объем бюджета;
Прогнозный объем бюджета;
Отклонение по срокам;
Отклонение по стоимости.
Основные продуктовые метрики:
ARPU — средний доход на пользователя;
LTV — пожизненная ценность клиента;
Метрики привлечения клиентов;
Метрики вовлеченности клиентов;
Метрики удержания клиентов;
Метрики производительности и надежности.
Согласитесь, списочек внушительный. Взять по 1–2 из каждого блока и уже проект под наблюдением. Главное выбрать их правильно. А вот для этого вторая рекомендация — весь ваш набор метрик должен покрывать основные сферы внимания проекта. Чтобы проверить это есть 2 фреймворка-чеклиста.
Фреймворк HEART (больше подходит для продуктов):
H → Happiness — польза для клиента;
E → Engagement — вовлеченность ЦА;
A → Adoption — привлечение клиентов;
R → Retention — удержание клиентов;
T → Task Success — успех продукта.
Фреймворк PROJECT (больше подходит для проектов):
P → People — команда проекта и ее состояние;
R → Reliability — надежность, качество;
O → Operations — операционные показатели;
J → Job — состояние скоупа;
E → Economy — финансовые показатели;
C → Customer — удовлетворенность клиента;
T → Timetable — расписание.
Если у вас есть хотя бы по одной метрике из каждого пункта, значит за проектом вы следите достаточно комплексно. Если где-то не хватает метрик, то оттуда могут прилететь проблемы, пока весь фокус внимания будет на других показателях. Так что, лучше это исправить.
Фреймворк PROJECT — мое собственное изобретение, результат модели, которую мы применяли в своей компании продолжительное время.
Пример нашей компании:
P → People — Тим-мораль (оцифрованный уровень морали команды, собирался вручную с помощью специальных вопросов);
R → Reliability — Bug leakage rate (доля багов, долетевших до прода);
O → Operations — Commitment/Velocity (именно их соотношение);
J → Job — Прогноз по дате завершения (метрика из Scrum, поделить весь оставшийся скоуп на среднее velocity);
E → Economy — Бюджет + маржа;
C → Customer — NPS (собирали аккаунты вручную);
T → Timetable — Текущий майлстоун/релиз (успеваем или нет).
Шаг 2 — Запустить сбор метрик
Собирать метрики можно вручную, можно автоматизировать этот процесс. Очевидно, что чем больше будет автоматизации, тем лучше. Не забывайте, что метрики должны куда-то складываться и отображаться, нужна система репортинга. И ответственность за сбор и качество метрик нужно сразу кому-то отдать, например, тимлиду или скрам-мастеру проекта.
Шаг 3 — Запустить процесс контроля
Мало собирать метрики, надо еще их проверять. Причем, на постоянной основе. Например, раз в неделю собираться с тимлидами и смотреть, что с проектами происходит. Либо озадачить их писать отчеты пару раз в неделю со всеми показателями и объяснениями по отклонениям.
Хорошей дополнительной практикой здесь может стать проектный статус. Это некоторая агрегированная метрика состояния проекта — такая единственная лампочка, по которой становится понятно, хорошо ли все с проектом или требуется вмешаться.
Проектный статус, как правило, собирается по всем метрикам. И в зависимости от отклонений метрик от нормы, будет выставляться и сам статус проекта. Также стоит учитывать кризисы проекта: конфликты, увольнения, высокий техдолг — все, что может повлиять на процесс delivery. Лучше, если для определения проектного статуса будет четкий алгоритм, прям блок-схема, по которой все будут одинаково понимать, как его определять и интерпретировать. Ну и каждый проектный статус должен подразумевать определенный алгоритм действий: предоставить план, информировать, эскалировать и т д.
Пример нашей компании
Мы формировали проектный статус по метрикам и по наличию кризисов. По сути, статус формировался по самой худшей метрике. Это могли быть значения Good, Warn, Critical и Uncertain (да, бывает такое, когда совершенно непонятно и нужно собирать информацию).
При статусе Warn мы должны были все исправить за неделю. При статусе Critical — предоставить план по исправлению и поддерживать ежедневно информированность стейкхолдеров.
Для контроля мы собирались еженедельно на встречу. Там были все Delivery Manager-ы, аккаунты, топы. На этих встречах происходили эскалации, а также могли решаться некоторые оперативные вопросы по проектам. А главное — раз в неделю подбивались все метрики и данные, мы получали четкую картину, что происходит с проектами. Хотя бы раз в неделю.
Шаг 4 — Добавить мотивацию
Чтобы все окончательно заработало, нужно продумать мотивацию для тимлидов и Delivery Manager-ов. Они должны отвечать за состояние проектов, за метрики, иметь возможность на них влиять и исправлять проблемы. Поэтому здесь нужны классические кнут и пряник, чтобы был баланс.
Итого
Система контроля проектов на базе метрик далеко не идеальна. В ней есть немало проблем и подводных камней, о которых нужно знать и помнить. Но тем не менее, она является хорошим и надежным решением по управлению портфелем проектов, если вам нужно собрать и унифицировать информацию по разным проектам и иметь возможность постоянно «держать руку на пульсе».
Быть Delivery Manager-ом непросто. Здесь и новый режим работы, и возросшая зона ответственности, и новые подчиненные, которые сами менеджеры и требуют специального подхода. Чтобы помочь тем, кто только ступает на этот путь, мы сделали новый курс Delivery Manager в OTUS. Его идея — помочь вам получить необходимые знания и трансформировать свое управленческое сознание, чтобы большинство шишек осталось здесь, на обучении.
А по теме метрик и управления портфелем проектов мы проведем открытый урок 20 июня. Регистрируйтесь и приходите, обсудим этот вопрос подробнее.
Присоединяйтесь к моему телеграмм-каналу Седой директор. Пишу там про управление людьми, про менеджмент в IT. Отвечаю на ваши вопросы и разбираю ваши кейсы.
