Вы тимлид, и у вас полный порядок с проектом. А если проектов будет несколько? Сможете сохранить контроль?
У Delivery Manager-а уже не один проект, приходится гораздо меньше погружаться в каждый. Контекст не тот, времени меньше, да еще и управлять приходится не самому, а руками тимлида.
В такой ситуации нужна хорошая система контроля. И лучше всего с этой задачей справляются данные – метрики. Про выбор метрики и их эффективность предлагаю почитать в этой статье.

Привет! Меня зовут Илья Прахт, я тренер в OTUS и руководитель нового курса Delivery Manager. Я прошел классический путь тимлид → Delivery Manager → CTO, и прекрасно помню чувства, которые испытывал на каждом переходе.

Особенно ярко помню переход на роль Delivery Manager-а: у тебя теперь свой портфель проектов и за каждым нужно следить. А времени и ресурсов, чтобы делать это также, как раньше, не хватает. И вот ты пытаешься балансировать между микроменеджментом и полной свободой. Иногда получается, иногда – нет. Но все это ненадежно.

Я для себя нашел решение в метриках. Тема довольно заезженная, холиварная. Кому-то они подходят, кто-то от них плюется. Данные – это просто данные. Важно уметь их правильно интерпретировать и использовать. Вот про это сегодня и поговорим.

Проект vs Портфель

В чем разница управления проектом от управления портфелем проектов? Если упростить, то есть 3 основных различия:

1. Степень погружения – невозможно ходить на каждый дейлик, быть в постоянном контакте с командой, ревьюить каждый пулл-реквест. Приходится ограничивать свой “квант внимания” к каждому проекту, что неминуемо приводит к потере информации.

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

3. Доверие – дефицит доверия гораздо выше. Это, во многом, следствие первых двух пунктов: не получается держать под контролем всю информацию, не получается нормально по-старому управлять проектом. Как итог – вообще непонятно, команда справляется с работой или им уже нужна помощь.

Чаще всего это выливается в 2 крайности: микроменеджмент или полное делегирование, без попыток хоть как-то следить за проектами. И то, и то – не то. А нужно что-то между, некоторый баланс между этими двумя состояниями.

Есть несколько вариантов, как этого добиться. Давайте их разберем.

Варианты управления портфелем проектов

Вариант 1 – Верить “наслово”

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

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

Вторая проблема – как говорил доктор Хаус: “Все врут”. Не-не, я ни в коем случае не хочу сказать, что тимлиды хотят вас обмануть. Может и не хотят. Но они будут доносить до вас свою точку зрения, субъективную реальность. И далеко не факт, что она совпадает с реальным положением дел. Так уж вышло, люди бывают излишне оптимистичны.

Вариант 2 – Масштабированная методология

Многое уже давно придумано, велосипед изобретать не стоит. Фреймворк SAFe может помочь в данном вопросе. Из наиболее популярных методологий здесь LESS, Scrum of Scrums и т п. На мой взгляд, решение едва ли не идеальное. Но есть в нем серьезный такой недостаток.

Взять ради примера Scrum of Scrums. Он будет работать, только если во всех проектах портфеля развернут канонический Scrum. Во всех остальных случаях получаем игрушку с напильником. И получится ли в итоге сделать работающий процесс – большой вопрос. Может – да, может – нет. И главное преимущество – взять готовое решение из коробки, сразу же разваливается.

Вариант 3 – Система метрик

Метрики универсальнее. Здесь можно выбрать такой набор метрик, который будет доступен на всех проектах портфеля, какими бы разными они ни были с точки зрения управления. При должной сноровке можно даже собрать под единый интерфейс проекты на Scrum-е, Kanban-е и водопады. Не скажу, что задача простая, но выполнимая.

При этом, сбор метрик можно автоматизировать. Можно собрать все показатели в единой системе и строить на базе них графики и дашборды. Что дает ту самую объективную картину реальности без необходимости тратить кучу времени самому руководителю, и отвлекать для этого команду.

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

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

Построение системы метрик

Шаг 1 – Выбрать метрики

Как выбрать метрики для своих проектов? У меня есть 2 рекомендации по этому поводу:

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. Отвечаю на ваши вопросы и разбираю ваши кейсы.