Predictable Delivery Operating System
Операционный слой delivery из пяти компонентов, работающих вместе. Каждый закрывает конкретный разрыв между тем, что руководство думает о проектах, и тем, что реально происходит. Вместе они делают delivery-риски, скоуп-дрейф и несогласованность PM видимыми до того, как доходят до клиентов.
Delivery-инфраструктура, не раскатка методологии.
Чем это не является
- — Не PMO-трансформация.
Никакой новой оргструктуры, никаких изменений линий подчинения. Я работаю внутри сетапа, который у вас есть. - — Не общий Agile-коучинг.
Никакой сертификации фреймворка, никаких Scrum-церемоний, поставленных потому что это «лучшие практики». Процесс подгоняется под то, что реально нужно вашим проектам. - — Не упражнение с дашбордами.
Инструменты не чинят проблему. Проблема обычно в том, что никто не договорился, что данные должны значить — или кто за них отвечает, когда что-то идёт не так.
Чем это является
- Еженедельный операционный ритм, встроенный в ваш delivery-процесс
- Пять компонентов, закрывающих конкретные, названные разрывы в видимости delivery
- Построено для работы с PM и инструментами, которые уже есть, — а не на замену
- Калибруется под ваш портфель в первые две недели до того, как что-либо станет стандартом
Каждый слой закрывает конкретный разрыв в видимости delivery.
Все проекты, одно представление, каждую неделю
Статус, уверенность в сроках, давление на бюджет, настроение клиента — по всем активным проектам, в едином формате. Руководство сравнивает здоровье без перевода между стилями отчётности PM.
Названные риски с владельцами и триггерами эскалации
Еженедельный список рисков, не зависящий от личного мнения PM. У каждого риска обозначен владелец, уровень серьезности риска и явный триггер эскалации — так что вопрос «когда это идёт к руководству» имеет ответ, не требующий каждый раз нового решения.
Неутверждённые изменения трекаются по мере появления
Лёгкая проверка, идущая параллельно с delivery: подсвечивает изменения объема работ до того, как их согласовали неформально и забыли. Бюджетный дрейф становится виден на той же неделе, когда начинается, а не на инвойсе.
Согласованный язык отчётности по команде PM
PM знают, как репортить статус, как классифицировать риск и когда эскалировать — в одних терминах, по одной структуре. Регулярные чек-ины держат формат откалиброванным без превращения в performance review.
Месячный отчет того, что требует решения
Месячный отчет, отделяющее то, что идёт нормально, от того, что требует внимания основателя или CEO. Достаточно короткое, чтобы прочитать за 10 минут. Достаточно конкретное, чтобы по нему действовать. Не пересказ статусов, которые руководство уже знает.
Как выглядит типичная неделя, когда ритм работает.
Сбор статус-апдейтов от PM
Каждый PM сдаёт еженедельный апдейт в общем формате — здоровье проекта, бюджетная позиция, текущие риски, настроение клиента. 20–30 минут на PM, когда формат ясен.
Delivery-ревью по всем проектам
Прохожу по активным проектам — ищу разрывы между отчётом и тем, что знаю из разговоров с PM, сравниваю риск-экспозицию между проектами, флагую то, что требует внимания до конца недели.
Список рисков обновлён, владельцы подтверждены
Центральный список рисков обновляется новыми рисками с валидацией. Существующие проверяются — владелец актуален, план митигации актуален, триггер эскалации уместен. Что устарело — подсвечивается.
Чек-ины с PM
Рабочие сессии с PM по всему, что всплыло на ревью — неясные сигналы статуса, риски, которые нужно переформулировать, изменения объема работ, которые нужно начать трекать. Async для рутинных недель, live — для срочного.
Еженедельный отчет для руководства
Короткий отчет здоровья портфеля идёт основателю или Head of Delivery. Что изменилось на этой неделе, что под риском, какое решение нужно до следующей. Написано для того, у кого 10 минут, а не 60.
Четыре рабочих документа, не система записи.
Это не шаблоны. Каждый калибруется под ваш портфель в первые две недели. Формат служит ревью — а не наоборот.
Представление здоровья проекта
Одна страница на проект. Те же четыре секции каждую неделю: статус, уверенность в сроках, бюджетная позиция, настроение клиента. Red/amber/green — отправная точка, важна письменная оценка.
- – Общий статус с кратким письменным обоснованием
- – Сроки: на треке, под риском или сдвинуто (с деталями)
- – Бюджет: утверждено vs факт vs прогноз
- – Клиент: последний контакт, настроение, следующая точка
Формат риск-ревью
Живой документ, обновляемый еженедельно. Каждая строка — один риск: что это, насколько серьёзен, кто владеет, последнее действие и как выглядит триггер эскалации. Когда риск уходит из лога — записана причина, почему.
- – Описание риска (конкретное, не «проблемы с ресурсами»)
- – серьезность: high / medium / watch
- – Владелец (один конкретный человек)
- – Последнее действие + триггер эскалации, если не решено
Чеклист ревью объема работ и маржи
Короткий чеклист, идущий параллельно с delivery каждую неделю. Заставляет задавать вопрос: поменялось ли что-то в объеме работ с прошлой недели, и если да — было ли это утверждено? Маленькое, но последовательное.
- – Новый объем работ: утверждён / в процессе / отклонён
- – Бюджет vs факт vs прогноз (на этой неделе)
- – Неутверждённые работы флагуются до продолжения
- – Дельта маржи с прошлой недели, если есть
Месячный отчет для руководства
Отправляется в конце каждого месяца. Максимум две страницы. Сделано для основателя или CEO, у которого нет времени на полный обзор портфеля, но нужно знать, что под риском и какие решения принадлежат его уровню.
- – Снимок портфеля: проекты по статусу
- – Что изменилось за месяц (риски решены / новые)
- – Решения, нужные от руководства до следующего месяца
- – Что я наблюдаю, но пока не эскалирую
Первые две недели калибруют всё под ваш портфель.
Ни один из артефактов выше не ставится в первый день. Первые две недели — диагностика: ревью текущих проектов, расстановки PM и delivery-дыр. То, что строится потом, отражает реальные потребности вашей ситуации, а не общий шаблон, наложенный извне.
К концу 2-й недели у вас выводы, quick wins и ясная оценка, продолжать или нет. Если диагностика не вытаскивает достаточно, чтобы оправдать постоянный engagement — скажу.
Стартуйте с диагностики. Посмотрите, как это ложится на ваш сетап, до решения.
Две недели. Ревью проектов, команды PM и delivery-дыр. На выходе — карта рисков, наблюдения по PM и конкретные quick wins, плюс рекомендация, имеет ли смысл постоянный engagement. Если выводы не полезны — останавливаетесь. Остаток месяца не выставляется.