Проект, продукт и жизненный цикл: фазы, гейты и почему ЖЦ проекта не равен ЖЦ продукта

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

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

1. Проект строго: четыре определения, которые стоит знать точно

Проект — временное предприятие, направленное на создание уникального продукта, услуги или результата (формулировка PMBOK, практически совпадающая с ISO 21502:2020). Каждое слово нагружено:

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

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

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

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

1.1. Что «временность» ломает в продуктовых командах

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

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

Практический вывод не «отменить проекты», а разделить два класса работы:

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

2. Три жизненных цикла, которые постоянно путают

Это главный раздел главы. Ниже — три цикла на одной оси времени.

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

ЖЦ проекта: инициация → планирование → исполнение → закрытие (мониторинг и контроль идут поперёк всех фаз). Измеряется месяцами, владеет им спонсор вместе с менеджером проекта, заканчивается достижением цели или признанием её недостижимой.

ЖЦ разработки ПО (SDLC): требования → проектирование → реализация → тестирование → релиз → эксплуатация. Измеряется неделями (в предиктивных проектах — месяцами), владеет им команда, заканчивается работающей версией — и начинается снова. Подробно этапы разобраны в главе «Что такое SDLC»; здесь SDLC нужен нам как один из трёх уровней, а не сам по себе.

Из таблицы следуют три вещи, которые в разговорах обычно теряются.

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

2.1. Популярная схема из четырёх этапов и что с ней не так

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

3. Фазы и гейты

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

Гейт (phase gate, stage gate, tollgate) — точка между фазами, где владелец денег отвечает на вопрос, продолжаем ли мы и на каких условиях. Гейт, у которого одним из законных исходов является закрытие проекта, называют kill point. Стадийно-гейтовый подход в его современном виде описал Роберт Купер для новых продуктов (Stage-Gate, обзор в JPIM 2008).

3.1. Чем гейт отличается от демо

Их путают, потому что оба выглядят как «показать сделанное начальству». Разница — в контуре и в полномочиях.

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

Механика траншей, критериев остановки и здоровых исходов гейта разобрана детально в запуске и закрытии проекта — здесь мы намеренно не дублируем, а фиксируем только место гейта в структуре жизненного цикла.

4. Пять типов жизненного цикла и как из них выбирать

PMBOK различает пять типов ЖЦ по тому, что фиксируется рано, а что уточняется по ходу.

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

Выбор типа ЖЦ выводится из двух вопросов: насколько мы знаем, что нужно (неопределённость требований) и сколько стоит ошибка (цена неверного решения, включая цену его исправления после поставки).

Осторожно с популярными матрицами выбора. Схему «согласие о требованиях против определённости технологии» приписывают Ральфу Стейси, хотя сам он возражал против такого использования и позже отказался от матрицы; Cynefin Дэйва Сноудена (HBR, 2007) аккуратнее, но и он классифицирует ситуации, а не выбирает модель процесса. Работающий критерий проще: сколько стоит узнать, что мы ошиблись, и через какое время. Дорого и поздно — усиливайте верификацию заранее; дёшево и быстро — сокращайте итерацию.

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

• модель процесса описывает, из каких стадий состоит работа и что происходит на каждой (водопад, спираль);
• методология — набор правил, техник и практик, делающих работу эффективнее (RUP, XP, PRINCE2);
• фреймворк — намеренно неполный каркас, который надо дополнить своими практиками (Scrum);
• подход — принципиальная позиция по поводу изменений (предиктивный, адаптивный).

Классификация типов ЖЦ по проектам разных видов — от энтерпрайза до аутсорса — есть в главе про типы проектов.

5. Сквозной пример: интернет-магазин по трём контурам

Возьмём классический учебный пример — интернет-магазин книг — и пройдём его по всем трём контурам сразу.

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

Контур проекта. Внутри продукта живёт несколько проектов, каждый со своим уставом, бюджетом и концом:

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

Контур процесса. Внутри проекта 1 SDLC прокручивается не один раз: сначала каталог и карточка товара (требования → дизайн → код → тест → релиз на стенд), затем корзина и оплата, затем личный кабинет. Подрядчик работает двухнедельными итерациями, приёмка — по каждому куску. Даже при фиксированной цене и утверждённом ТЗ внутри исполнения живёт нормальный инкрементный процесс.

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

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

6. Что заканчивается, а что нет

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

Минимальный состав передачи — семь пунктов, каждый с именем:

1. Владелец сервиса — конкретный человек или команда, а не отдел: принимает решения и отвечает за доступность.
2. Дежурство и эскалация — кто получает алерт ночью, кому эскалирует, за какое время реагирует.
3. Наблюдаемость — метрики пользовательского эффекта, а не загрузки процессора; дашборд, который реально открывают.
4. Runbook — сценарии типовых отказов, проверенные хотя бы одним учебным прогоном.
5. Проверенный откат — не «мы можем откатиться», а «мы откатывались на прошлой неделе на стенде».
6. Бюджет эксплуатации — стоимость инфраструктуры, лицензий и человеко-часов поддержки на год, включённая в план.
7. Принятый техдолг — список известных срезанных углов с датами, а не устная договорённость «потом починим».

Два пропуска дают самые дорогие патологии. Без владельца система становится сиротой: формально она есть, фактически ею никто не занимается, пока не сломается настолько, что людей придётся собирать экстренно. Без бюджета эксплуатации возникает невидимая стоимость владения: организация думает, что проект стоил 9 млн руб., а он стоил 9 млн руб. плюс 2 млн руб. в год, и эти два миллиона тихо съедают мощность команды, которая делает что-то другое.

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

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

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

Продуктовая компания, внутренняя платформа. Продукт живёт четыре года, за это время внутри него закрыто одиннадцать проектов: миграция на другую СУБД, интеграция с системой единого входа, вывод устаревшего API, соответствие требованию регулятора. Команда постоянная, финансирование потоковое; проектная форма включается только там, где есть внешний срок или внешние деньги. Гейты ставятся не по календарю, а перед крупными тратами: перед закупкой лицензий, перед наймом подрядчика, перед переходом всей аудитории на новый интерфейс.

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

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

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

Мини-итог

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

Источники

• PMBOK Guide, PMI — определения проекта, программы, портфеля и типов жизненного цикла.
• ISO 21502:2020 — руководство по управлению проектами; ISO 21500:2021 — контекст и словарь.
• ISO/IEC/IEEE 12207:2017 — процессы жизненного цикла программных средств.
• Fowler M., «Products Over Projects», 2019 — почему проектное финансирование вредит долгоживущим системам.
• Cooper R. G., «Perspective: The Stage-Gate Idea-to-Launch Process», JPIM 2008; stage-gate.com.
• Snowden D., Boone M., «A Leader’s Framework for Decision Making», HBR 2007 — Cynefin.
• О матрице Стейси и её ограничениях — почему её не стоит использовать как механический выбор подхода.
• Google SRE Book, «Evolving SRE Engagement Model» — production readiness review как форма передачи в эксплуатацию.

Что дальше

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

Следующая глава восстанавливает оригиналы: что на самом деле написал Ройс в 1970 году, почему водопад стал нормативом Минобороны США, чем V-модель отличается от водопада и почему она живёт в медтехнике и автомобильной электронике, и в чём принципиальная разница между «достроить кусок» и «переделать целое лучше».

Читайте: Модели процесса разработки: code-and-fix, водопад, V-модель, инкремент, итерации, спираль