Контроль исполнения и извлечённые уроки: отчётность, освоенный объём, health check, база знаний

Тринадцать предыдущих глав трека были про то, как проект устроить: жизненный цикл, свод знаний, устав, оценка, декомпозиция, делегирование, решения. Эта — про единственный вопрос, который остаётся, когда всё уже запущено и работает: как мы узнаем, что идём не туда, — и узнаем ли раньше, чем это станет очевидно всем.

Провальные проекты редко проваливаются внезапно. Почти всегда есть период — от нескольких недель до нескольких месяцев, — когда данные уже говорят правду, а организация её ещё не слышит. Стоимость проекта определяется не самой ошибкой, а задержкой её обнаружения: та же ошибка, найденная на втором месяце, стоит дневного разговора, а найденная на восьмом — половины бюджета. Поэтому цель контроля формулируется не как «знать статус», а как сокращение времени между «пошло не так» и «мы это знаем».

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

1. Контроль как контур обратной связи, а не как отчётность

Контроль часто путают с отчётностью. Отчётность — это передача информации наверх; контроль — это замкнутый контур, у которого есть измерение, сравнение с эталоном, решение и воздействие. Отчёт без решения не контроль, а ритуал: сигнал уходит в систему, из которой не возвращается воздействие.

Ветка «ничего не делаем» — полноправная и самая частая. Контур, который на каждое колебание отвечает вмешательством, раскачивает систему: менеджер реагирует на шум, команда переключается, следующий замер хуже предыдущего, и цикл повторяется. Именно поэтому допуски из главы про решения нужны в контуре контроля не меньше, чем в контуре полномочий: они задают порог срабатывания.

Статус — не прогноз, и это главное различие в главе. Статус отвечает на вопрос «что уже сделано» и обращён в прошлое; прогноз отвечает на «когда закончим и сколько это будет стоить» и обращён в будущее. Организации собирают статусы и думают, что получают прогнозы. Не получают: сумма выполненных задач ничего не говорит о дате, пока не известны оставшийся объём и темп. Практическое правило: любой отчёт, где нет ни одного числа про будущее, бесполезен для решения.

Отсюда же знаменитый синдром 90 процентов: проект держится на «почти готово» месяцами. Механика простая и не связана с ленью. Готовность оценивает исполнитель, а исполнитель оценивает видимую часть работы: код написан — значит, 90%. Невидимая часть — интеграция, обработка ошибок, миграция данных, приёмка, документация, нагрузка — не оценивается, потому что её не видно. Плюс психология: 90% — социально приемлемый ответ, он не требует объяснений. Итог сформулировал Том Каргилл в «Programming Pearls» Джона Бентли: первые 90% кода занимают 90% времени, оставшиеся 10% кода — ещё 90% времени (CACM, 1985). Единственное известное лекарство — не спрашивать про проценты вообще, а спрашивать про бинарные факты.

2. Что измерять: базовый план, вехи и правила готовности

Базовый план (baseline) — зафиксированная версия объёма, срока, бюджета и качества, относительно которой считаются отклонения. Ключевое слово — «зафиксированная»: план, который тихо правится по факту, не базовый, и отклонений относительно него не бывает никогда. Правило: базовый план меняется только через явное решение (запрос на изменение, гейт, пересмотр), старая версия сохраняется, а число пересмотров само по себе метрика — проект, где план переутверждали пять раз за квартал, не управляется, а догоняет реальность.

Веха — бинарный факт, а не дата в календаре. Хорошая веха формулируется так, что двое независимых людей одинаково ответят «да» или «нет»: «первый реальный клиент провёл платёж через новый маршрут в проде», а не «завершена интеграция с биллингом». Вехи «на 80% готова» не существует — либо факт наступил, либо нет. Из этого следует неприятное: если у проекта нет ни одной вехи ближе, чем через два месяца, у него нет и обратной связи на этот срок.

С процентом готовности всё сложнее. Число «65% готово» само по себе не значит ничего, пока не названо правило, по которому оно получено.

Практический вывод: в IT по умолчанию берите 0/100 и мелкие куски. Это то же самое решение, что ограничение размера партии в потоке (Kanban и поток): чем мельче единица, тем меньше нужно верить в проценты и тем чаще приходит достоверный сигнал. Правило записывается один раз в план и не меняется по ходу — иначе отчёты разных месяцев несопоставимы.

Сравнение базового плана с фактом полезно рисовать буквально: расхождение видно раньше, чем оно попадёт в числа.

Каждая полоса факта длиннее плановой на 15–40%, при этом ни в одном месяце отставание не выглядело катастрофой: «ну на неделю». Именно так и накапливается сдвиг на два месяца — не одним событием, а систематическим смещением, которое видно только на длинной картинке.

3. Метод освоенного объёма (Earned Value Management)

EVM — классический аппарат, отвечающий на вопрос «сколько ценности мы уже создали за потраченные деньги». Он появился в оборонных закупках США (стандарт ANSI/EIA-748), вошёл в PMBOK и остаётся самым распространённым способом свести срок и бюджет в одну систему координат. Три базовые величины считаются нарастающим итогом и в одних и тех же единицах — обычно в деньгах:

• PV (Planned Value) — сколько работы по базовому плану должно быть выполнено к отчётной дате, в деньгах бюджета.
• EV (Earned Value) — сколько работы фактически выполнено, оценённой по бюджетной стоимости, а не по фактическим затратам.
• AC (Actual Cost) — сколько денег фактически потрачено на выполненную работу.

Ключ ко всему методу в определении EV: выполненная работа оценивается по плановой цене. Именно это разводит два разных вопроса — «отстаём ли мы» и «перерасходуем ли мы», — которые в обычных отчётах слиты в одну строку «потрачено 58% бюджета».

$$SV = EV - PV \qquad CV = EV - AC \qquad SPI = \frac{EV}{PV} \qquad CPI = \frac{EV}{AC}$$

$$EAC_{CPI} = \frac{BAC}{CPI} \qquad EAC_{плоский} = AC + (BAC - EV) \qquad EAC_{оба} = AC + \frac{BAC - EV}{CPI \cdot SPI} \qquad TCPI = \frac{BAC - EV}{BAC - AC}$$

Здесь BAC (Budget at Completion) — весь бюджет по базовому плану, EAC (Estimate at Completion) — прогноз итоговой стоимости, TCPI — эффективность, которую нужно показывать на остатке работ, чтобы всё-таки уложиться в BAC. Отрицательные SV и CV означают отставание и перерасход; индексы меньше единицы — то же самое в относительной форме.

Разберём на числах. Проект «Личный кабинет 2.0»: BAC = 12 000 тыс. руб., базовый срок 8 месяцев. Отчётная дата — конец пятого месяца.

На конец пятого месяца: SV = 5 600 − 7 000 = −1 400 тыс. руб., CV = 5 600 − 7 000 = −1 400 тыс. руб., SPI = CPI = 0,80. Прогноз EAC = 12 000 / 0,80 = 15 000 тыс. руб. при бюджете 12 000 — перерасход 25%. TCPI = 1,28: чтобы уложиться в исходный бюджет, оставшуюся работу нужно делать в 1,6 раза эффективнее, чем всю предыдущую. Так не бывает, и в этом главная ценность TCPI: он превращает разговор «мы наверстаем» в проверяемое утверждение.

Картинка показывает то, что таблица прячет: AC догнал PV. Денег потрачено ровно столько, сколько планировалось на пятый месяц, и обычный отчёт «бюджет освоен по плану» выглядел бы благополучно. Работ при этом сделано на 5 600 из 7 000. Ровно эту подмену EVM и ловит.

Второе наблюдение важнее: CPI стабилизировался ко второму-третьему месяцу и дальше не улучшался. Это не совпадение — исследования крупных контрактов (Дэвид Кристенсен и коллеги по данным Министерства обороны США) показали, что накопленный CPI после примерно 20% выполнения меняется мало и почти никогда не растёт. Практический смысл: прогноз, построенный на CPI первой пятой части проекта, обычно точнее любых обещаний наверстать.

from dataclasses import dataclass

BAC = 12_000                       # бюджет по завершении, тыс. руб.

@dataclass
class Period:
    """Отчётный период; все величины — нарастающим итогом, в тыс. руб."""
    month: int
    pv: float                      # плановый объём
    ev: float                      # освоенный объём (сделанная работа по плановой цене)
    ac: float                      # фактические затраты

def metrics(p: Period, bac: float = BAC) -> dict:
    """Показатели EVM за один период. O(1) по времени и памяти; на ряде из n периодов — O(n)."""
    spi = p.ev / p.pv if p.pv else 1.0
    cpi = p.ev / p.ac if p.ac else 1.0
    return {
        "SV": round(p.ev - p.pv),                                # отставание в деньгах
        "CV": round(p.ev - p.ac),                                # перерасход
        "SPI": round(spi, 2), "CPI": round(cpi, 2),
        "EAC_cpi": round(bac / cpi),                             # темп перерасхода сохранится
        "EAC_flat": round(p.ac + (bac - p.ev)),                  # остаток пойдёт по плану — оптимизм
        "EAC_both": round(p.ac + (bac - p.ev) / (cpi * spi)),    # пессимизм: и темп, и срок
        "TCPI": round((bac - p.ev) / (bac - p.ac), 2),           # нужная эффективность остатка
    }

series = [Period(1, 1_000, 900, 1_100), Period(2, 2_200, 1_900, 2_400),
          Period(3, 3_600, 3_000, 3_900), Period(4, 5_200, 4_200, 5_400),
          Period(5, 7_000, 5_600, 7_000)]

for p in series:
    m = metrics(p)
    print(f"м{p.month}  SPI={m['SPI']:<5} CPI={m['CPI']:<5} "
          f"EAC: опт={m['EAC_flat']:>6} база={m['EAC_cpi']:>6} песс={m['EAC_both']:>6}  TCPI={m['TCPI']}")
# м1  SPI=0.9   CPI=0.82  EAC: опт= 12200 база= 14667 песс= 14156  TCPI=1.02
# м2  SPI=0.86  CPI=0.79  EAC: опт= 12500 база= 15158 песс= 17275  TCPI=1.05
# м3  SPI=0.83  CPI=0.77  EAC: опт= 12900 база= 15600 песс= 17955  TCPI=1.11
# м4  SPI=0.81  CPI=0.78  EAC: опт= 12800 база= 15429 песс= 17800  TCPI=1.18
# м5  SPI=0.8   CPI=0.8   EAC: опт= 13400 база= 15000 песс= 17000  TCPI=1.28

Три версии EAC дают вилку, и это правильный способ ими пользоваться: оптимистичная предполагает, что остаток пойдёт ровно по плану (почти никогда), базовая — что сохранится текущая эффективность затрат, пессимистичная — что сохранятся обе проблемы. Отчёт, где EAC одно число без вилки, врёт точностью.

Честная критика EVM

EVM измеряет соответствие плану, а не ценность. Освоенный объём — это стоимость выполненной работы по бюджету, а не польза, которую она принесла. Проект, идеально выполняющий бесполезный план, покажет SPI = CPI = 1,0. В отрасли, где половина функций не используется, это не мелкий недостаток, а смена системы координат: EVM отвечает на вопрос «делаем ли мы то, что обещали», и не отвечает на вопрос «стоило ли обещать».

В адаптивных проектах EVM даёт ложную уверенность. Метод требует полного объёма работ, оценённого в деньгах, до старта. Если объём по замыслу уточняется по ходу (а именно так работает продуктовая разработка), знаменатель у всех показателей — фикция. Тогда SPI = 0,95 означает не «идём по плану», а «идём по плану, который устарел» — и это опаснее отсутствия показателя, потому что выглядит как знание.

SPI ведёт себя неадекватно в конце проекта. К моменту, когда весь объём выполнен, EV = PV и SPI = 1,0 автоматически — даже если проект опоздал на полгода. Показатель, который в конце всегда показывает норму, для срока непригоден; отсюда практика смотреть не SPI, а отставание во времени (сколько недель назад план был на текущем уровне EV) — на диаграмме выше это горизонтальный отрезок, а не вертикальный.

Что использовать вместо или вместе. В потоковых системах прогноз строится не по освоенному объёму, а по пропускной способности и распределению времени цикла: сколько элементов команда завершает в неделю, каков разброс, сколько осталось — и отсюда вероятностная дата по перцентилям вместо одной цифры (Kanban и поток). Для инженерного здоровья поставки — метрики DORA, которые измеряют способность доставлять, а не соответствие смете (DORA и инженерные метрики). Разумная комбинация: EVM там, где объём действительно зафиксирован контрактом или регулятором; поток и DORA — везде, где объём живой.

4. Отчётность: три уровня, три горизонта, три вопроса

Один отчёт для всех не работает, потому что у уровней разные вопросы и разные горизонты. Команда живёт в днях, менеджер — в неделях, спонсор — в месяцах; попытка показать спонсору доску задач так же бессмысленна, как показать команде диаграмму освоенного объёма.

В PRINCE2 это оформлено явно: Checkpoint Report — регулярный отчёт команды менеджеру о ходе работ внутри пакета; Highlight Report — регулярный отчёт менеджера управляющему совету о стадии; Exception Report — внеочередной отчёт, который выпускается, когда прогноз выходит за допуск. Разделение полезно даже вне PRINCE2, потому что оно фиксирует главное: регулярный отчёт и сигнал о выходе за допуск — разные документы с разной срочностью. Дожидаться пятницы, чтобы сообщить о пробитом допуске, — процессная ошибка.

Правило, которое стоит всех шаблонов: отчёт должен предлагать решение, а не описывать активность. «Команда работала над интеграцией» — активность. «Интеграция даёт 120 запросов в секунду при требуемых 400; предлагаю вариант с кэшем, нужно ваше согласие до 24.06» — решение.

# Личный кабинет 2.0 — статус на 05.07.2026 (неделя 22 из 35)

**Общий статус: ЖЁЛТЫЙ** (был жёлтый). Прогноз запуска 08.12 против базового 30.09.

## Прогноз и отклонения
- Срок: прогноз 08.12 (85-й перцентиль — 22.12). Отклонение +10 недель, допуск 2 недели — пробит.
- Бюджет: EAC 15 000 тыс. руб. при BAC 12 000. CPI 0,80 держится с марта, TCPI 1,28.
- Объём: 9 обязательных сценариев из 21 в работе, 12 отложены решением ADR-021.
- Качество: открытых S1 — 0, S2 — 3 (допуск 2), регресс зелёный 6 недель подряд.

## Что изменилось за неделю
- Первый реальный клиент прошёл платёж через новый маршрут в проде (веха M4 закрыта).
- Нагрузка биллинга подтверждена на 380 запросов/с — риск R-12 закрыт.
- Ушёл инженер по интеграциям; замена выходит 20.07, знание передано за 3 дня (риск R-19 открыт).

## Решения, которые нужны от вас
1. Срок 08.12 против 30.09: подтвердить перенос ИЛИ урезать объём до 6 сценариев (даёт 25.10).
   Рекомендую перенос: 3 сценария из 9 обязательны по требованию регулятора. Нужно до 12.07.
2. Допуск по дефектам S2: расширить с 2 до 4 до конца стабилизации либо остановить новые функции
   на две недели. Рекомендую остановку: копится долг по регрессу. Нужно до 12.07.

## Риски, которые могут изменить прогноз
- R-19 (уход второго инженера по интеграциям): вероятность средняя, влияние 3 недели. Митигация —
  парное сопровождение с 08.07.
- R-21 (изменение требований регулятора в сентябре): вероятность низкая, влияние до 6 недель.
  Следим, решение не требуется.

Половина страницы, четыре секции, и в каждой есть будущее. Обратите внимание на две детали: статус сопровождается предыдущим значением (жёлтый был жёлтым — значит, три недели не двигается, это само по себе сигнал), а секция решений содержит рекомендацию и дедлайн, как в эскалации.

Светофоры RAG и почему они врут

Схема «зелёный — жёлтый — красный» удобна и повсеместна, и у неё есть системный дефект: цвет выставляет тот, кого за красный цвет спросят. Возникает эффект арбуза (watermelon reporting) — зелёный снаружи, красный внутри: проект остаётся зелёным до момента, когда скрывать уже нельзя, и переходит сразу в красный, минуя жёлтый. Диагностика в одну строку: если в вашей организации проекты не бывают жёлтыми по месяцу, светофор не работает.

Четыре правила, которые делают светофор честным. Цвет определяется правилом, а не человеком: прогноз за допуском — жёлтый, два допуска или отсутствие плана восстановления — красный. Цвет ставится по прогнозу, а не по факту на сегодня. У жёлтого обязателен план восстановления с датой, иначе он мгновенно превращается в вечный. И главное — за жёлтый не наказывают, а за поздний красный спрашивают: пока цена плохой новости выше цены её сокрытия, никакая методика не поможет.

5. Health check проекта

Health check — структурированный самоосмотр по фиксированному списку вопросов, который проводят раз в квартал или на переходе между фазами. Он отличается от аудита принципиально: аудит проверяет соответствие правилам и ищет нарушения, health check ищет риски и делается для самой команды. У аудита внешний заказчик и письменное заключение; у health check заказчик — менеджер и спонсор, а результатом являются три-пять действий с именами. Смешивать их нельзя: как только health check начинает влиять на премию, ответы становятся правильными, а не честными.

Двадцать четыре вопроса по восьми осям, каждый — с ответом «да / нет / не знаю». «Не знаю» считается как «нет»: неизвестность про собственный проект — это и есть находка. Проводит health check менеджер вместе с командой (полтора-два часа), полезно приглашать одного внешнего человека — менеджера соседнего проекта, который задаст неудобные вопросы, не заражённые контекстом. Результат — не отчёт, а три-пять действий с именами и датами; ещё один документ никому не нужен.

6. Ранние индикаторы беды

Хорошие индикаторы срабатывают до того, как отклонение попадёт в срок или бюджет, — они видны в поведении, а не в числах.

• Растёт незавершёнка. Задач в работе больше, чем людей; «почти готово» становится массовым. Работает потому, что незавершённая работа — это невыясненные проблемы: пока элемент не завершён, вы не знаете, что в нём не так. Рост WIP всегда предшествует росту времени цикла (закон Литтла).
• Вехи двигаются «на неделю» каждую неделю. Один сдвиг — событие, четыре подряд — это уже темп, и он говорит, что оценка остатка систематически смещена. Правильная реакция — не требовать «уложиться», а пересчитать остаток заново снизу вверх и сравнить с исходной оценкой.
• Растёт доля внепланового. Поддержка, инциденты, срочные просьбы съедают больше 30% времени. Мощность падает вдвое, а план продолжает считаться по номинальной численности — расхождение накапливается молча.
• Никто не задаёт вопросов на статусах. Тишина на встрече означает не согласие, а отсутствие интереса или страх. Проверяется мгновенно: назовите на статусе заведомо неверное число и посмотрите, поправят ли вас.
• Спонсор перестал ходить. Самый недооценённый сигнал: он означает либо, что проект перестал быть важным (и скоро потеряет ресурсы), либо что решения теперь принимаются в другом месте. И то и другое надо знать сразу.
• Тесты выключены или регресс красный неделями. Команда перешла в режим «доделать любой ценой», и цена — невидимая работа, которая всплывёт на приёмке. Отключённый тест — это не экономия времени, а перенос его на потом с процентами.
• Оценки перестали обновляться. Задача с оценкой «3 дня» висит третью неделю, и оценку никто не трогает. Это отказ от прогнозирования: если оценки не пересматриваются, ни одно число в плане не отражает реальность.
• Растёт время между «сделано» и «в проде». Готовые вещи копятся перед релизом. Обратная связь удлиняется, а вместе с ней растёт цена любой ошибки.

Ни один индикатор не является доказательством. Но два-три одновременно — это повод внепланово провести health check, а не ждать следующего отчётного периода.

7. Извлечённые уроки: почему «мы всё обсудили на ретро» не работает

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

Причина не в лени. Урок живёт там, где его прочитают принудительно. Документ в вики читают, только если специально пошли искать, — а в начале проекта никто не идёт искать чужие ошибки. Отсюда единственное работающее правило: урок, не изменивший артефакт, не существует. Артефакт — это шаблон, чек-лист, значение по умолчанию, автоматическая проверка, пункт в Definition of Done, коэффициент в базе оценок.

Второе структурное изменение — Lessons Log как непрерывный документ, а не финальный. В PRINCE2 журнал уроков ведётся с первого дня и пополняется по ходу, а не пишется в конце. Разница принципиальна: урок, записанный через шесть месяцев после события, состоит из того, что запомнилось, — то есть из выводов, а не из фактов. Урок, записанный в тот же день, содержит контекст, который через полгода уже никто не восстановит.

Три формата разбора часто путают, хотя у них разные объекты и разные результаты.

Техника постмортемов подробно разобрана в статье про постмортемы, а приёмы ведения самой встречи — в фасилитации. Общее у всех трёх — безобвинительность как условие получения данных: там, где ищут виноватого, никто не расскажет, что знал о проблеме за два месяца до эскалации, а именно это знание и есть самое ценное. Формулировка Норма Керта («независимо от того, что мы обнаружим, мы исходим из того, что каждый делал лучшее, на что был способен при имеющихся знаниях и ресурсах») — не вежливость, а инженерное условие работы метода.

Главный вопрос разбора проекта стоит выделить отдельно, потому что его почти никогда не задают: не «что пошло не так», а «когда мы узнали правду и могли ли узнать раньше». Цена проекта определяется задержкой обнаружения. Если выяснилось на седьмом месяце, что смежная система не тянет нагрузку, полезный вывод не «биллинг плохой», а «это можно было проверить на второй неделе спайком за три дня, и вот что нам помешало».

8. Организационная память

Уроки живут в четырёх местах, и ни одно из них не называется «папка с отчётами».

• Шаблоны и чек-листы — устав, план, чек-лист старта, чек-лист готовности к запуску, Definition of Done. Их читают принудительно, потому что без них не начинают работу.
• Значения по умолчанию и автоматизация — самая сильная форма: пайплайн, который не пускает без прогона миграции на копии продовых данных, помнит урок лучше любого документа и не требует, чтобы кто-то вспомнил.
• Записи решений (ADR) и журнал решений — то, что объясняет, почему система и процесс такие; без них следующая команда переигрывает решения заново.
• База пар «план — факт» — архив оценок и фактических длительностей по классам работ. Это фундамент для взгляда снаружи и эталонного прогнозирования (оценка проекта): организация, два года сверявшая прогнозы с фактом, оценивает заметно точнее без единого тренинга — просто потому, что авторы оценок знают о будущей сверке.

Как не превратить это в кладбище документов: у каждого артефакта есть владелец и дата пересмотра; новый пункт добавляется только вместе с удалением устаревшего (чек-лист длиннее страницы не читают); артефакт лежит там, где работа, а не в отдельной вики — шаблон устава в репозитории рядом с кодом переживает три реорганизации, шаблон на корпоративном портале не переживает одну. И самое неприятное: если за год ни один пункт чек-листа не был вычеркнут как неактуальный, чек-лист не живёт — его никто не читает достаточно внимательно, чтобы заметить устаревание.

9. Закрытие проекта: коротко

Полный разбор запуска и закрытия — в соответствующей статье трека Project Management; здесь только контрольный список того, без чего проект не закрыт. Административное закрытие: приёмка подписана по тем же критериям, что записаны в уставе; открытые дефекты переданы с приоритетами; доступы отозваны, стенды погашены, подписки закрыты; договорные обязательства закрыты. Передача в эксплуатацию: у результата есть владелец поимённо, дежурство, алерты, проверенный откат и runbook, а также известная стоимость эксплуатации — система без владельца не результат, а сирота, чьё содержание оплатит кто-то другой. Проверка выгод через N месяцев: через три-шесть месяцев кто-то берёт бизнес-кейс, измеряет те же метрики и честно отвечает, сбылось ли; дата этой встречи ставится в календарь в день закрытия, а имя ответственного пишется в уставе. Без последнего пункта качество бизнес-кейсов не улучшается никогда — не из-за недобросовестности, а из-за отсутствия обратной связи.

10. Типичные ошибки

11. Как это выглядит в проде

Регуляторный проект в банке, фиксированный объём, 14 месяцев. EVM здесь уместен: объём задан требованием регулятора и почти не меняется. CPI ушёл ниже 0,85 на третьем месяце и не поднялся. На пятом месяце менеджер принёс комитету не «мы наверстаем», а TCPI = 1,3 с расчётом: чтобы уложиться в бюджет, остаток нужно делать в полтора раза эффективнее всей предыдущей работы. Комитет добавил 20% бюджета и снял два необязательных сценария. Проект закончился с перерасходом 11% вместо прогнозных 25% — не потому, что EVM что-то починил, а потому, что разговор случился на пятом месяце, а не на одиннадцатом.

Продуктовая команда, EVM отменили. Попытка считать освоенный объём при живом бэклоге давала SPI около единицы каждый месяц и ноль полезной информации. Заменили на прогноз по пропускной способности: сколько элементов закрывается в неделю, каков разброс, сколько осталось, дата по 50-му и 85-му перцентилям. Первое, что выяснилось, — разброс времени цикла оказался больше самого времени цикла, и главной задачей стал не «ускориться», а сократить хвост.

Health check, который сработал. Внеплановый осмотр провели после трёх сигналов: незавершёнка выросла вдвое, спонсор пропустил два комитета подряд, вехи двигались «на неделю» четвёртую неделю. Восемь ответов «не знаю» из двадцати четырёх, из них пять — про стейкхолдеров: никто не мог назвать, кто принимает результат. Нашли и назначили за две недели; выяснилось, что критерии приёмки у принимающей стороны другие. До обнаружения оставалось около трёх месяцев работы, которую пришлось бы переделывать.

Как делать не надо. Программа на 18 месяцев, еженедельные статусы по 40 слайдов, светофор зелёный 14 месяцев подряд. На пятнадцатом месяце — красный и перенос на полгода. Разбор показал: интеграционные проблемы были известны команде с четвёртого месяца, но красный цвет требовал объяснений на уровне правления, и никто не захотел быть первым. Формально процесс контроля работал безупречно — отчёты выходили в срок все 14 месяцев.

Мини-итог

• Цель контроля — сократить время между «пошло не так» и «мы это знаем». Отчёт без решения — ритуал; контур замыкается воздействием, а ветка «ничего не делаем» в нём полноправна.
• Статус — не прогноз. Отчёт без единого числа про будущее не годится для решения; синдром 90 процентов лечится не давлением, а бинарными фактами.
• Процент готовности без правила — фикция. По умолчанию 0/100 и мелкие куски; правило фиксируется один раз и не меняется по ходу.
• EVM разводит «отстаём» и «перерасходуем», потому что EV считается по плановой цене. CPI стабилизируется рано, и прогноз по нему честнее обещаний наверстать; TCPI превращает «мы наверстаем» в проверяемое утверждение, а EAC даётся вилкой из трёх версий.
• EVM измеряет соответствие плану, а не ценность, требует зафиксированного объёма и ломается в конце (SPI всегда стремится к единице). Для живого объёма — прогноз по потоку и метрики DORA.
• Три уровня отчётности отвечают на три разных вопроса. Регулярный отчёт и сигнал о выходе за допуск — разные документы; отчёт предлагает решение, а не описывает активность.
• Светофор честен, только когда цвет ставит правило, а не человек, и когда за жёлтый не наказывают, а за поздний красный спрашивают.
• Health check — не аудит: его заказчик команда, результат — три-пять действий с именами, а «не знаю» считается за «нет».
• Ранние индикаторы лежат в поведении, а не в числах: растущая незавершёнка, вечный сдвиг «на неделю», рост внепланового, тишина на статусах, исчезнувший спонсор, выключенные тесты, замороженные оценки.
• Урок, не изменивший артефакт, не существует. Lessons Log ведётся непрерывно; ретроспектива, постмортем и разбор проекта — три разных инструмента, и главный вопрос разбора — «когда мы узнали правду и могли ли раньше».

Что мы прошли за трек

Начали с карты трека и трёх контуров управления и с того, чем проект отличается от продукта, а его жизненный цикл — от жизненного цикла продукта. Разобрали модели процесса от code-and-fix до спирали и семейство подходов — предиктивный, итеративный, гибкий, после чего взялись за своды знаний и стандарты: PMBOK с его переходом от 49 процессов к 12 принципам, PRINCE2 с управлением по отклонениям и ландшафт ISO, IPMA, ГОСТ и CMMI. Дальше пошла практика: устав, содержание и WBS, предварительная оценка с PERT и конусом неопределённости, декомпозиция и границы дробления, делегирование и распределение ответственности. Завершили тремя главами про мышление менеджера: методы решения проблем и генерации идей, принятие и фиксацию решений и эту — про контроль и память. Сквозная линия у всех четырнадцати одна: классика управления — это набор ответов на вопросы, которые никуда не делись, и знать их надо не чтобы следовать, а чтобы понимать, что именно вы отменяете, когда отменяете.

Источники

• PMBOK Guide и Practice Standard for Earned Value Management, PMI — каноническое изложение EVM и контроля исполнения; базовый стандарт метода — ANSI/EIA-748.
• PRINCE2 — Checkpoint, Highlight и Exception Report, управление по отклонениям, непрерывный Lessons Log.
• ISO 21502:2020 — контроль, отчётность и извлечённые уроки в нейтральном к методологии виде.
• Fleming Q., Koppelman J., «Earned Value Project Management», PMI, 4-е изд., 2010 — практическая книга по EVM с разбором правил освоения.
• Christensen D. S., «The Estimate at Completion Problem: A Review of Three Studies», Project Management Journal, 1993 — исследования стабильности CPI после 20% выполнения по данным оборонных контрактов.
• Bentley J., «Programming Pearls: Bumper-Sticker Computer Science», CACM 1985 — правило девяноста-девяноста Тома Каргилла.
• Vacanti D., «Actionable Agile Metrics for Predictability» — прогноз по пропускной способности и распределению времени цикла вместо освоенного объёма.
• Reinertsen D. G., «The Principles of Product Development Flow», 2009 — экономика очередей, размер партии и цена задержки обратной связи.
• DORA — инженерные метрики поставки; разбор на портале — DORA и инженерные метрики.
• Google SRE Book, «Postmortem Culture» — безобвинительный разбор как условие получения данных.
• Derby E., Larsen D., «Agile Retrospectives», 2006; Керт Н., Prime Directive — формулировка безобвинительности.
• Flyvbjerg B., «From Nobel Prize to Project Management» — эталонное прогнозирование и база пар «план — факт» как организационный актив.

Что дальше

На этом классический фундамент закончен. Вы прошли путь от жизненного цикла и сводов знаний до контроля исполнения и организационной памяти — то есть освоили набор ответов, выработанных индустрией за пятьдесят лет и оформленных в стандарты. Дальше начинается то, что эти ответы уточняет и во многом переписывает: современная операционная механика — итеративная поставка, поток и ограничение незавершёнки, вероятностные прогнозы вместо точечных дат, риски как непрерывная работа, инженерные метрики, экономика запуска и остановки. Именно там классические конструкции из этого трека получают рабочую форму для продуктовой разработки.

Основное продолжение — трек Управление проектами: Agile, поток и поставка. Если вас больше интересуют люди и команда — механика роста, обратной связи, найма, топологий и техстратегии — смотрите Инженерное лидерство. А если главный вопрос для вас не «как сделать», а «что и зачем делать», то есть ценность, гипотезы, метрики и рынок, — идите в Продуктовый менеджмент.

Читайте: Управление проектами: карта трека и современная операционная механика