Запуск и закрытие проекта: бизнес-кейс, устав, контроль изменений, остановка

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

Стоит ли это делать? На каких условиях мы продолжаем? Как мы поймём, что закончили, и что в итоге получили?

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

1. Асимметрия краёв

Верхние строки — ежедневная работа менеджера. Нижние — несколько решений за проект, и именно они определяют экономику портфеля. Исследование McKinsey и Оксфорда по 5400 крупным проектам (цифры — в карте трека) показало перерасход бюджета на 45%, срока — на 7%, но недобор обещанной ценности на 56%. Несимметричность важнее самих чисел: исполнение отклоняется умеренно, ценность — катастрофически. Ценность теряется не в исполнении, а в выборе, что исполнять, и в неспособности остановиться, когда выбор оказался неверным. Ключевой вопрос поэтому не «как точнее спланировать», а сколько денег мы обязаны потратить до момента, когда узнаем правду. Это экспозиция, и ею управляют формой обязательства.

Обе схемы тратят одинаково, если проект доходит до конца. Разница проявляется только в плохом сценарии — поэтому её систематически недооценивают: в момент старта плохой сценарий кажется чужой историей. Формально транш плюс гейт — это покупка права не платить остаток: цена опциона — накладные расходы на гейт и паузу, выплата — отсечённый хвост распределения перерасходов (разбор идеи применительно к разработке — у Криса Маттса и Олава Маассена, «Real Options Underlie Agile Practices»). Отсюда три следствия: решение начать выгоднее разбить на серию, чем уточнять; право сказать «нет» должно быть записано, обеспечено нераспределённым бюджетом и хоть раз применено; информация имеет цену — спайк, прототип, пилот на одном регионе покупаются и считаются как любая другая покупка.

2. Бизнес-кейс, который не врёт

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

Дисконтирование нужно потому, что рубль сегодня и рубль через два года — разные рубли: $NPV = \sum_{t=0}^{T} CF_t / (1+r)^t$, где $CF_t$ — чистый поток периода, $r$ — ставка. Горизонт в IT берут короткий (2–3 года): дальше прогноз неотличим от фантазии. Но важнее самого NPV — анализ чувствительности: какое допущение двигает ответ сильнее всего и, значит, что проверять первым.

from dataclasses import dataclass, replace

@dataclass(frozen=True)
class Case:
    """Допущения бизнес-кейса. Суммы — в тысячах условных единиц."""
    dev_cost: float; run_cost_year: float      # разработка целиком; эксплуатация в год
    users: float; effect_per_user: float       # охват; эффект на пользователя в год
    adoption: float; ramp_months: float        # доля реально начавших; месяцы до планового эффекта
    horizon_years: int = 3; rate: float = 0.18 # горизонт и годовая ставка дисконтирования

def npv(c: Case) -> float:
    """Год 0 — только затраты, дальше эффект с учётом разгона. O(n) по времени, O(1) по памяти."""
    full, total = c.users * c.adoption * c.effect_per_user, -c.dev_cost
    for year in range(1, c.horizon_years + 1):
        ramped = min(1.0, max(0.0, (12 * year - c.ramp_months) / 12))   # доля года на плановом эффекте
        total += (full * ramped - c.run_cost_year) / (1 + c.rate) ** year
    return total

def tornado(c: Case, spread: dict[str, tuple[float, float]]) -> list[tuple]:
    """Гоняем каждое допущение по его диапазону, остальные держим. O(k·n) по времени, O(k) по памяти."""
    rows = [(f, round(npv(replace(c, **{f: lo}))), round(npv(replace(c, **{f: hi}))))
            for f, (lo, hi) in spread.items()]
    return sorted(rows, key=lambda r: -abs(r[2] - r[1]))     # самое влиятельное допущение — первым

case = Case(dev_cost=9_000, run_cost_year=1_200, users=4_000,
            effect_per_user=1.4, adoption=0.55, ramp_months=9)
print(round(npv(case)))                                      # -5762 — за три года не окупается
for row in tornado(case, {"adoption": (0.25, 0.85), "effect_per_user": (0.9, 2.2),
                          "dev_cost": (13_000, 6_500), "users": (2_500, 7_000)}):
    print(row)
# ('users', -8039, -1214)            <- разброс по охвату решает всё
# ('dev_cost', -9762, -3262)
# ('effect_per_user', -7407, -2210)
# ('adoption', -7838, -2896)

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

Числа при этом берут снаружи: оценка снизу вверх систематически оптимистична (механику разбирает оценка и планирование), а противоядие Канемана и Ловалло — взгляд снаружи, базовая ставка из класса похожих проектов вместо прогноза из деталей своего («Delusions of Success», HBR 2003; у Флювбьерга это оформлено как эталонное прогнозирование). Организация с архивом пар «план — факт» оценивает новые проекты в разы точнее; такой архив создаётся в разделе 8 и является активом, а не бюрократией. Отдельно про стратегическое искажение: часто числа завышены не по ошибке, а потому что инициатор знает — с честными числами проект не одобрят. Лекарство не «требовать честности», а менять систему: назначенный оппонент, премортем (см. управление рисками), публичная сверка факта с прогнозом.

3. Устав: одна страница, которая экономит квартал

Устав (project charter, в PRINCE2 — Project Brief) нужен ровно для одного: чтобы через три месяца никто не спорил, зачем это делалось и кто решает. Всё, что не помещается на страницу, не будет прочитано, а значит, не существует.

# charter.yaml — устав проекта, лежит в репозитории, меняется через pull request
project: "Самообслуживание для корпоративных клиентов"
sponsor: "Директор по операциям — Смирнова А."   # ОДНО имя, а не комитет
problem: >
  Поддержка тратит 340 часов в месяц на ручную смену тарифов и реквизитов корпоративных
  клиентов. Очередь растёт быстрее найма, срок ответа вырос с 4 до 19 часов.  

success_criteria:                   # не «улучшить», а «с X до Y к дате»
  - "доля тарифных изменений, выполненных клиентом самостоятельно: 0% -> 60% за 3 месяца"
  - "медианный срок ответа поддержки по этому классу: 19 ч -> 4 ч"
  - "ручные часы поддержки на класс: 340 -> 120 в месяц"

out_of_scope:                       # эта секция сокращает scope creep сильнее прочих
  - "миграция исторических данных старше 2 лет"
  - "мобильное приложение — только адаптивный веб"
  - "интеграция с 1С — отдельный проект после этого"
  - "сегмент SMB — другой сценарий и другой интерфейс"

assumptions:                        # у каждого допущения есть владелец и способ проверки
  - { claim: "не менее 60% клиентов готовы работать самостоятельно",
      owner: "продуктовый аналитик", check: "12 интервью + анализ обращений, до гейта 1" }
  - { claim: "биллинг выдерживает 40 запросов в секунду на смену тарифа",
      owner: "тимлид биллинга", check: "нагрузочный тест на стенде, до гейта 1" }

decision_rights:                    # снимает 80% будущих эскалаций
  scope_change_up_to_5_days: "менеджер проекта"
  scope_change_up_to_20_days: "спонсор"
  go_live: "спонсор по чек-листу готовности"
budget: { total_cap: "9 000 тыс. у.е.", tranche_now: "1 200 тыс. у.е. до гейта 1" }

stop_criteria:                      # самая ценная секция: пишется ДО старта, пока не жалко
  - "готовность клиентов работать самостоятельно ниже 35% по итогам интервью"
  - "нагрузочный тест показывает необходимость переписать биллинг (> 3 месяцев)"
  - "прогноз по 85-му перцентилю выходит за 8 месяцев на гейте 2"
  - "спонсор сменился и новый не подтвердил цели в течение 3 недель"

review_gates:                       # вопрос гейта, а не «отчитаться о статусе»
  - { id: 1, when: "через 6 недель", question: "подтверждены ли оба допущения" }
  - { id: 2, when: "после первого сценария в проде", question: "пользуются ли реальные клиенты" }
  - { id: 3, when: "через 3 месяца после запуска", question: "сошёлся ли бизнес-кейс" }

Четыре места, где это отличается от типового шаблона на 14 страниц. Спонсор — одно имя: если подписать некому, проекта нет, есть желание нескольких людей; комитет не может нести ответственность за решение остановить. «Вне объёма» важнее, чем «в объёме»: «делаем самообслуживание» допускает любое расширение, а «1С — отдельный проект» закрывает трёхнедельный спор заранее; пока список исключений короче списка целей, устав недописан. Допущения с владельцем и способом проверки превращают бизнес-кейс в план работ: первые недели уходят на проверку самых влиятельных допущений, а не на «начало разработки, потому что все уже сидят». Критерии остановки, написанные заранее, — единственная работающая защита от эффекта необратимых затрат: Улисс привязал себя к мачте до того, как услышал сирен, а не после.

4. Гейты и транши: покупать информацию, а не строить сразу

Стадийно-гейтовый подход придумал Роберт Купер для новых продуктов (Stage-Gate, обзор в JPIM 2008), а Марк Денн и Джейн Клеланд-Хуанг перенесли идею на софт как incremental funding («Software by Numbers»). В IT слово «гейт» получило дурную репутацию заслуженно, но не из-за идеи, а из-за двух её искажений: гейт требовал полного плана вперёд и никогда не заканчивался отказом. У здорового гейта пять законных исходов — если исход один, гейта нет.

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

Транш не бесплатен. Критерий простой: гейт окупается, если $P_{\text{отказа}} \cdot C_{\text{остаток}}$ больше накладных расходов на подготовку и паузу. Перед остатком в 7800 тыс. у.е. гейт стоимостью 100 оправдан уже при вероятности отказа 1,3%; перед задачей на 120 тыс. у.е. тот же гейт требует уверенности 83%, чего не бывает. Отсюда два правила: гейты ставят перед крупными тратами и не ставят перед мелкими, и гейт ставится там, где снимается неопределённость, а не по календарю — ежеквартальный гейт, попавший в середину исследования, соберёт незрелые данные и выродится в формальность. Возражение «гейты — это водопад» относится к одному конкретному искажению: гейту, требующему утверждённого детального плана на весь проект. Гейт, требующий фактов вместо планов («что мы теперь знаем, чего не знали три месяца назад»), итеративности не противоречит: спиральная модель Боэма — это ровно гейты по риску, а не по фазам (см. RAD, спиральную модель и RUP и сравнение методологий). Внутри транша команда работает как обычно; на гейте меняется только уровень разговора: не «что сделано», а «что подтвердилось и сколько теперь стоит остаток».

5. Контроль изменений: у изменения всегда есть цена

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

Изменение принимается вместе с ответом на вопрос «что выпадает или что сдвигается». Не «нет», а «да, ценой вот этого».

Это перевод разговора из плоскости желаний в плоскость выбора. Заказчик обычно не хочет сорвать проект — он просто не видит, что его просьба с чем-то конкурирует. Как только альтернатива названа вслух, около половины запросов отзываются их же авторами.

# CR-042: Экспорт истории тарифов в Excel

- Автор: руководитель поддержки · Дата: 2026-07-16 · Статус: на оценке
- Зачем (проблема, а не решение): при спорах с клиентом поддержка вручную собирает историю
  из трёх систем, 40–60 минут на случай, около 25 случаев в месяц.
- Влияние на цели устава: прямого нет; косвенно снижает ручные часы (цель 3) на ~20 ч/мес.
- Оценка: 4 дня разработки + 1 день тестирования, 85-й перцентиль — 8 дней.
- Что выпадает: массовая смена реквизитов (CR-031) уезжает за гейт 2, ИЛИ дата +1 неделя.
- Альтернативы: (а) SQL-отчёт по запросу — 0,5 дня, закрывает 80% случаев;
  (б) не делать, дождаться данных о частоте после запуска.
- Решение: принято по варианту (а), полный экспорт — в бэклог после гейта 2. Спонсор, 18.07.

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

Пороги полномочий из устава существуют, чтобы поток не упирался в спонсора. Без них получается один из двух отказов: либо всё утверждает спонсор — и очередь запросов имеет лид-тайм в две недели (см. закон Литтла в Kanban), либо не утверждает никто. Change control board, заседающий раз в две недели, — это очередь с фиксированной каденцией обслуживания: если поток запросов больше пропускной способности заседания, очередь растёт неограниченно, и обходной путь («договорились в коридоре») появляется сам. При этом одна и та же просьба обсуждается совершенно по-разному в зависимости от того, кто несёт риск неопределённости.

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

Одно число для проверки, работает ли контроль вообще, — churn объёма: сумма добавленного и снятого, делённая на исходный размер периода, плюс отдельно чистый рост. Churn 0,4 при чистом росте 0,05 — здорово: содержание меняли, размер держали, так выглядит фиксация мощности при плавающем объёме. Churn 0,4 при чистом росте 0,3 — контроля нет: добавляют, не снимая. Churn около нуля подозрителен: либо объём и правда был известен (редко), либо изменения идут мимо учёта. Метрика мгновенно портится, если сделать её целевой, — обычный закон Гудхарта, разобранный в статье про DORA и метрики.

6. Решение остановиться

Эффект необратимых затрат — самое хорошо задокументированное искажение в управлении проектами: эксперименты Аркеса и Блумера показали, что люди продолжают заведомо худший вариант просто потому, что уже заплатили («The Psychology of Sunk Cost», 1985). Барри Стоу описал организационную версию — эскалацию обязательств: чем публичнее было решение начать, тем больше ресурсов человек вкладывает в его оправдание (Staw, 1976; обзор в AMR, 1981). К психологии добавляется арифметика организации: остановленный проект выглядит как провал менеджера, а тянущийся — как работа. Пока система устроена так, призывы «принимать трудные решения» не работают: она наказывает ровно за то, чего требует.

Правильное сравнение смотрит вперёд и не содержит потраченного: $V_{\text{ост}} \cdot P_{\text{успеха}} > C_{\text{ост}} + C_{\text{альт}}$, где $V_{\text{ост}}$ — ценность, которую ещё можно получить, $C_{\text{ост}}$ — затраты на остаток, $C_{\text{альт}}$ — что эта команда сделала бы вместо. Потраченные девять миллионов в формуле отсутствуют: при любом решении они уже потрачены.

from dataclasses import dataclass

@dataclass
class Position:
    spent: float                 # потрачено — в решении НЕ участвует, приведено для честности
    remaining_cost: float        # оценка остатка, 85-й перцентиль
    remaining_value: float       # ценность, которую ещё можно получить
    p_success: float             # вероятность, что она будет получена
    best_alternative: float      # чистая ценность лучшего применения той же команды
    salvage: float = 0.0         # что останется при остановке: код, данные, знание

def decide(p: Position) -> dict:
    """Вперёд смотрящее решение: три варианта, потраченное игнорируется. Сложность O(1)."""
    options = {
        "продолжать": p.remaining_value * p.p_success - p.remaining_cost,
        "урезать до ядра": p.remaining_value * 0.6 * min(1.0, p.p_success * 1.4) - p.remaining_cost * 0.35,
        "остановить": p.salvage + p.best_alternative,
    }
    best = max(options, key=options.get)
    return {"оценки": {k: round(v, 1) for k, v in options.items()}, "решение": best,
            "запас над второй опцией": round(options[best] - sorted(options.values())[-2], 1)}

print(decide(Position(spent=6_400, remaining_cost=3_800, remaining_value=5_200,
                      p_success=0.55, best_alternative=1_500, salvage=400)))
# {'оценки': {'продолжать': -940.0, 'урезать до ядра': 1789.0, 'остановить': 1900.0},
#  'решение': 'остановить', 'запас над второй опцией': 111.0}

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

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

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

1. Назвать причину фактами, а не людьми: «допущение об охвате опровергнуто, 22% вместо 60%» — это результат работы; проект, дёшево доказавший, что затея не сходится, свою задачу выполнил.
2. Объявить самому и сразу: слух распространяется быстрее письма и всегда в худшей версии.
3. Сохранить актив: код в ветке с описанием, данные исследования в общей базе, выученное — в чек-листы (раздел 8).
4. Решить судьбу людей до объявления: первый вопрос в голове каждого — про себя, и пока ответа нет, остальное не слышно.
5. Отметить остановку как решение: организация, где на гейте хоть раз публично поблагодарили за своевременный отказ, получает честные статусы бесплатно.

Отдельный исход — не остановить, а превратить в продукт: работа не имеет конца, система живёт и требует развития, а проектное финансирование её убивает, расформировывая команду ровно тогда, когда она разобралась в домене (Fowler, «Products Over Projects»). Тогда правильный ход — постоянная команда и потоковое финансирование; см. трек Product Management и разбор жизненного цикла в его завершающей статье.

7. Финиш: что значит «закончено»

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

Передача в эксплуатацию — самый недооценённый этап: команда празднует релиз, а через две недели ночью звонит алерт, и дежурить некому. Практика, которая это закрывает, пришла из Google SRE и называется production readiness review (SRE Book).

Минимальный набор для передачи: владелец сервиса поимённо; SLO и алерты, привязанные к пользовательскому эффекту, а не к загрузке CPU; runbook с реальными сценариями отказа; проверенный откат; дашборд; известная стоимость эксплуатации; список принятого технического долга с датами. Подробности — в треке SRE и статье про on-call, инженерная часть поставки — в DevOps. Правило одной строкой: у любого результата проекта есть владелец после закрытия проекта. Нет владельца — вы построили не систему, а сироту, и её содержание оплатит кто-то другой, не подозревая об этом.

8. Закрытие: разбор и подтверждение выгод

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

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

Через три-шесть месяцев после запуска кто-то должен взять бизнес-кейс, измерить те же метрики и честно ответить, сбылось ли. Эту встречу не проводит почти никто — и именно поэтому бизнес-кейсы остаются жанром художественной литературы: обещание, которое никогда не сверяют с фактом, не имеет причин быть точным. Регулярная сверка даёт три вещи: калибровку (организация, которая два года сверяет прогнозы с фактом, прогнозирует заметно лучше без единого тренинга — просто потому, что авторы знают о будущей сверке), эталонные классы (накопленные пары «план — факт» — та самая база для взгляда снаружи из раздела 2) и решения о продолжении (половина запусков даёт эффект ниже обещанного, но выше нуля; «доводить или свернуть» — тот же расчёт из раздела 6). Формально это benefits realization, описанное в PMBOK и PRINCE2 (там же — принцип постоянного экономического обоснования: бизнес-кейс пересматривается на каждой стадии, а не один раз на старте), и в ISO 21502:2020. Не хватает не знания, а привычки: дата проверки выгод ставится в календарь в день закрытия проекта, а имя ответственного пишется в уставе.

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

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

Внутренняя платформа, 6 инженеров, горизонт 9 месяцев. Устав на страницу в репозитории, бюджет разбит на три транша. На первом гейте интервью показали готовность 22% вместо ожидаемых 60% — проект урезали до одного сценария для десяти крупнейших клиентов, бюджет сократили втрое. Через полгода сценарием пользуются восемь клиентов из десяти, ручные часы поддержки упали на 40%. Полная версия не построена и не нужна.

Миграция биллинга, фиксированная цена, внешний подрядчик. Объём известен, форма контракта адекватна; основная работа менеджера — контроль изменений: за проект прошло 34 запроса, принято 9, отозвано авторами 14 после ответа на вопрос «что выпадает». Гейты не по календарю, а по снятию риска: после проверки миграции на копии продовых данных и после первого параллельного прогона двух систем. Разбор дал коэффициент «миграции данных — множитель 2,0», который через год спас следующий проект от обещания невыполнимого срока.

Инициатива, которую вовремя остановили. Три месяца, 40% бюджета; на гейте 2 данные пилота показали конверсию втрое ниже порога, записанного в устав на старте. Спонсор объявил закрытие на общей встрече, назвав причину как результат: «за три месяца и 40% бюджета мы узнали то, за что иначе заплатили бы годом». Побочный эффект оказался важнее решения: в следующие полгода две другие команды сами пришли с предложением остановить свои затеи.

Программа, где всё сделали наоборот. Бюджет на 18 месяцев одним решением, гейты ежеквартальные и отчётные, критериев остановки нет. На четвёртом квартале выяснилось, что ключевое допущение о готовности смежной системы неверно — его никто не проверял, потому что владелец допущения не был назначен. Формально проект завершён в срок; система в проде, ею пользуется 4% аудитории, владельца эксплуатации нет, проверка выгод не проводилась. Ни одно правило процесса нарушено не было — все нарушенные правила находятся в этой статье.

Мини-итог

• Края проекта важнее середины. В середине управляют процентами, на краях — разами: решение не начинать или остановить на трети даёт множитель, недостижимый оптимизацией процесса.
• Бизнес-кейс — фальсифицируемая гипотеза о деньгах. Полезен не итоговым числом, а анализом чувствительности: он показывает, какое допущение проверять первым и каким самым дешёвым экспериментом. Числа берут снаружи, из архива «план — факт», а не только снизу вверх.
• Устав — одна страница: одно имя спонсора, измеримые критерии успеха, явное «вне объёма», допущения с владельцами, пороги полномочий и критерии остановки, написанные до старта.
• Транши и гейты покупают опцион не платить остаток. Гейт с одним возможным исходом — отчёт; здоровых исходов пять: продолжать, урезать, приостановить, закрыть, перевести в продукт.
• У изменения всегда есть цена. Запрос принимается вместе с ответом «что выпадает»; пороги полномочий важнее комитета; форма контракта определяет, кто несёт риск объёма и как вообще идёт разговор.
• Решение продолжать смотрит вперёд. Потраченного в формуле нет: сравнивают остаточную ценность с остаточными затратами и с лучшей альтернативой для той же команды.
• «Закончено» — четыре разных факта: поставлено, принято, эксплуатируется, ценность подтверждена; самая частая пропущенная строка даёт систему без владельца. Выводы живут в шаблонах, а не в отчётах, а дата проверки выгод — в календаре с дня закрытия.

Источники

• PMBOK Guide, 7-е издание — принципы вместо процессов; разбор на портале — PMBOK.
• PRINCE2 — постоянное экономическое обоснование и роль спонсора; разбор — PRINCE2.
• ISO 21502:2020 — руководство по управлению проектами, нейтральное к методологии.
• Cooper R. G., «Perspective: The Stage-Gate Idea-to-Launch Process», JPIM 2008; stage-gate.com.
• Denne M., Cleland-Huang J., «Software by Numbers», 2003 — инкрементальное финансирование.
• Matts C., Maassen O., «Real Options Underlie Agile Practices», InfoQ 2007.
• Kahneman D., Lovallo D., «Delusions of Success», HBR 2003 — взгляд снаружи.
• Flyvbjerg B., «From Nobel Prize to Project Management», PMJ 2006 — эталонное прогнозирование; «How Big Things Get Done», 2023.
• Arkes H., Blumer C., «The Psychology of Sunk Cost», OBHDP 1985; Staw B., «Knee-Deep in the Big Muddy», 1976 и AMR 1981.
• Reinertsen D. G., «The Principles of Product Development Flow», 2009 — экономика очередей и стоимости задержки.
• Fowler M., «Products Over Projects» — почему проектное финансирование вредит долгоживущим системам.
• Google SRE Book: «Evolving SRE Engagement Model» и «Postmortem Culture».
• Arnold J., Black Swan Farming: Cost of Delay — практические материалы по стоимости задержки.

Что дальше

Внешняя петля замыкает всё остальное: процесс из статей 01–12 определяет, насколько быстро вы узнаёте правду, а гейты, критерии остановки и проверка выгод определяют, что вы с этой правдой делаете. Работают они только вместе — короткая петля обратной связи бесполезна, если решение всё равно нельзя изменить, а право остановиться бесполезно, если правда приходит на восемнадцатом месяце.

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

Читайте: Расписание, зависимости и ресурсы: сетевой график, сжатие срока, критическая цепь