Вы тимлид, и у вас полный порядок с проектом. А если проектов будет несколько? Сможете сохранить контроль?
У 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. Отвечаю на ваши вопросы и разбираю ваши кейсы.
