Stage-Gate Process — формальный процесс разработки нового продукта, разбитый на последовательные стадии работы (Stage), между которыми стоят «ворота» (Gate) — контрольные точки, на которых явно принимается одно из четырёх решений: Go (продолжить), Hold (приостановить), Recycle (доработать) или Kill (закрыть проект). В отличие от инновационной воронки, которая показывает агрегатную динамику МНОГИХ идей сразу, Stage-Gate отслеживает ОДИН конкретный проект и даёт формальный, воспроизводимый механизм принятия решения на каждом контрольном рубеже.
Происхождение и исследовательская база
Прямой концептуальный предшественник Stage-Gate — процесс поэтапной проверки (phase review process), который NASA внедрило в 1960-х годах для управления космическими программами: пять стадий работы, каждая завершается обязательной формальной проверкой (review), прежде чем проект допускается к следующей стадии. Это, по сути, первое поколение процесса управления с контрольными воротами, задолго до появления самого термина «stage-gate».
Опираясь на логику NASA и на собственное многолетнее эмпирическое исследование более 3000 проектов разработки новых продуктов в тысячах компаний, канадский исследователь Роберт Купер (Robert G. Cooper) формализовал и опубликовал систему в книге «Winning at New Products» (1986) — на момент выхода первого издания сам термин «stage-gate» ещё не использовался, но структура процесса (последовательные стадии + формальные ворота с явным решением) была уже полностью описана. Позже система была официально зарегистрирована как товарный знак Stage-Gate® (компания Stage-Gate International). По оценкам, на сегодняшний день процесс в том или ином виде применяют около 80% североамериканских компаний, занимающихся разработкой новых продуктов.
Купер построил систему не как умозрительную теорию, а как эмпирическое обобщение практик команд, которые реально побеждали в разработке новых продуктов, — сорок с лишним лет его исследовательской карьеры посвящены систематическому изучению того, что именно отличает успешные проекты разработки продукта от провальных.
Ключевые идеи и принципы
Принцип: на каждых воротах принимается явное решение из четырёх вариантов, а не молчаливое продолжение
Классический провал управления проектами — когда проект просто продолжает получать финансирование по инерции, без явного пересмотра его перспектив. Stage-Gate требует на каждых воротах формально выбрать одно из четырёх решений: Go (критерии выполнены, продолжаем), Hold (приостановить, не закрывая), Recycle (вернуть на доработку — критерии частично не выполнены, но проект перспективен), Kill (закрыть проект окончательно). Такая формализация не даёт слабому проекту продолжать существовать просто потому, что его никто явно не остановил.
Принцип: у каждых ворот — заранее известные, конкретные критерии перехода
Критерии ворот определяются заранее, до начала стадии, а не придумываются постфактум под конкретный проект — это защищает решение от субъективности и политического давления («мы уже столько вложили, нельзя останавливаться»). Типичные критерии первых ворот — стратегическое соответствие, техническая осуществимость, рыночный потенциал; критерии поздних ворот — готовность прототипа, успешная валидация у клиентов, готовность производства к масштабированию.
Принцип: чем позже стадия, тем дороже её пройти — и тем важнее не пропустить слабый проект на предыдущих воротах
Стоимость разработки растёт от стадии к стадии: скоупинг идеи стоит на порядки дешевле полноценной разработки, а разработка — дешевле запуска на рынок. Именно поэтому ранние ворота (отбор идеи, бизнес-обоснование) должны отсекать заведомо слабые проекты как можно раньше — пропустить слабый проект на ранних воротах означает потратить непропорционально много ресурсов на его последующую (заведомо провальную) проработку.
Ограничения, слепые зоны и критика
Главная практическая критика — избыточная бюрократизация. Компании, механически внедряющие Stage-Gate, иногда превращают процесс в череду длинных формальных совещаний с объёмной документацией на каждых воротах, что резко замедляет разработку — особенно губительно для быстроразвивающихся рынков, где скорость важнее полноты формального процесса. Сам Купер в поздних работах прямо признавал эту проблему и предлагал облегчённые («agile-gate»/гибридные) версии процесса для менее рискованных или более быстрых проектов.
Второе ограничение — линейная, последовательная природа классического процесса плохо сочетается с итеративной разработкой в духе Agile/Lean Startup, где продукт намеренно выпускается в минимальной версии и дорабатывается по обратной связи, а не проходит полный цикл проработки до единственного «правильного» запуска. Современные гибридные версии Stage-Gate явно интегрируют agile-спринты внутри отдельных стадий, но это уже отход от исходной модели 1986 года.
Третье — формальное прохождение критериев (все чекбоксы отмечены) не гарантирует реального качества решения на воротах: комитет может формально одобрить переход, даже если критерии выполнены лишь номинально, особенно при сильном организационном давлении продолжать уже начатый проект.
Типовые ошибки
Ошибка 1: превращают ворота в формальность, пропуская все проекты как Go.
Комитет одобряет переход почти всегда, независимо от реального выполнения критериев — процесс существует на бумаге, но фактически не отсеивает слабые проекты, теряя весь смысл системы.
Как избежать: явно фиксировать решение Kill/Hold/Recycle как штатный, не «провальный» исход процесса — и реально его использовать, когда критерии не выполнены.
Ошибка 2: делают критерии ворот расплывчатыми или субъективными.
Критерий формулируется абстрактно («хороший потенциал») без конкретного, проверяемого содержания — решение на воротах тогда принимается интуитивно, а не по факту выполнения объективного критерия.
Как избежать: формулировать критерии максимально конкретно и проверяемо ещё до начала стадии, не постфактум под уже проделанную работу.
Ошибка 3: применяют полный тяжёлый процесс ко всем проектам без разбора.
Небольшое, малорискованное улучшение продукта проходит через ту же пятиступенчатую процедуру с полным набором совещаний и документации, что и крупный, стратегически значимый запуск — процесс становится избыточно медленным для лёгких проектов.
Как избежать: адаптировать глубину процесса под масштаб и риск конкретного проекта — облегчённая версия для малых инициатив, полная для крупных.
Ошибка 4: продолжают финансировать проект по инерции после решения Hold.
Проект формально «приостановлен», но по факту команда продолжает над ним работать без явного пересмотра — Hold превращается в способ избежать неудобного решения Kill, а не в реальную паузу для переоценки.
Как избежать: назначать явную дату пересмотра решения Hold и реально останавливать работу на этот период.
Главное, что нужно знать
Stage-Gate Process (концептуальный предок — phase review process NASA, 1960-е; формализация — Роберт Купер, «Winning at New Products», 1986, на основе исследования 3000+ проектов) — последовательные стадии разработки продукта, разделённые формальными воротами с явным решением Go/Hold/Recycle/Kill по заранее известным критериям. В отличие от инновационной воронки (агрегатная динамика многих идей), Stage-Gate отслеживает один конкретный проект. Главный практический риск — превращение ворот в формальность (все проекты автоматически проходят Go) или, наоборот, в избыточную бюрократию, замедляющую разработку.
План внедрения
Неделя 1-2: определить стадии и критерии ворот для типового проекта
Зафиксировать конкретные, проверяемые критерии для каждых из пяти ворот заранее — до начала работы по конкретному проекту, чтобы критерии не подгонялись задним числом под уже сделанную работу.
Неделя 3-4: провести первый проект через ворота 1-2 с реальными решениями
На каждых воротах явно фиксировать одно из четырёх решений (Go/Hold/Recycle/Kill) — не позволять проекту молчаливо продолжаться без формального рассмотрения.
Месяц 2-3: пройти оставшиеся стадии до запуска или закрытия
Продолжать формально проверять критерии на каждых воротах, включая готовность к масштабированию на последних воротах перед запуском на рынок.
Далее: адаптировать глубину процесса под масштаб проектов
Ввести облегчённую версию процесса для малых, малорискованных инициатив — не применять полный тяжёлый процесс ко всем проектам без разбора.
Как реализовать этот план с помощью фрейма «Stage-Gate Process» в OrgDevTools
Фрейм отслеживает один конкретный проект разработки продукта через пять последовательных ворот с чекбоксами критериев и явным решением на каждых воротах.
Неделя 1-2 — поле «Проект разработки»: название конкретного продукта/проекта, который отслеживается (Stage-Gate — не про портфель идей, а про один конкретный проект). Каждые из пяти ворот содержат заранее заданный набор из трёх критериев (соответствуют стандартным критериям модели Купера — стратегическое соответствие, техническая осуществимость, рыночный потенциал на первых воротах, и так далее к готовности запуска на последних).
Неделя 3-4 — чекбоксы критериев отмечаются по мере их реального выполнения; счётчик «выполнено N из 3» на каждых воротах сразу показывает, готов ли проект к формальному решению.
Месяц 2-3 — на каждых воротах выбирается явное решение из выпадающего списка (Go/Hold/Recycle/Kill); цвет карточки ворот меняется в соответствии с решением, что визуально сразу показывает статус проекта.
Далее — вкладка «Итоги» показывает текущий статус: если проект закрыт (Kill) на одних из ворот — вердикт явно называет это ворота и прекращает отсчёт; если пройдены все пять ворот — проект готов к запуску.