Управление Agile Waterfall в госкорпорациях — это гибрид: сверху у вас Waterfall для бюджета, сроков, контрактов и отчётности, а внутри — Agile (Scrum/Kanban) для разработки кусками, чтобы не обнаружить «мы не то делали» на этапе приёмки через год.

Главная боль госсреды не в том, что «Agile не работает», а в том, что закон, закупки и архитектурные комитеты живут по календарю и печатям. А продуктовая команда — по обратной связи и инкрементам (поставкам). В итоге все делают вид, что у них один процесс, хотя на самом деле — два, склеенных скотчем из регламентов.

И да: Agile Waterfall — не ругательство. Это реальность большинства крупных организаций в РФ, где деньги выделяются по ФЗ-44/ФЗ-223, требования фиксируются в ТЗ, а релизы всё равно надо выпускать часто, потому что пользователи (и проверяющие) ждать не любят. На https://itokno.ru как раз любят такие «приземлённые» расклады: без мантр, с разбором, где вы теряете время и деньги.

Почему Agile “не взлетает” в госкорпорации — и почему взлетает гибрид

Тезис: Waterfall нужен не потому, что вы “динозавр”, а потому что вы в системе обязательств

Обоснование. В госкорпорациях и около них почти всегда есть: годовое бюджетирование, контрольные точки, закупочные процедуры, формализованная приёмка, внешний аудит. Это всё — про фиксированные артефакты (ТЗ, план-график, смета), то есть природная среда Waterfall.

Практический вывод. Не пытайтесь «внедрить Agile вместо всего». Пытайтесь сделать так, чтобы внешний контур выглядел предсказуемо (Waterfall), а внутренний контур был адаптивным (Agile).

Подводный камень. Самая частая ошибка — продавать руководству «Agile без сроков и фиксации». В госсреде это звучит как «хочу денег без ответственности» и умирает на первом комитете.

Тезис: Agile нужен, потому что “идеальное ТЗ” в реальности не существует

Обоснование. Даже если ТЗ подписано кровью, у вас меняются интеграции (СМЭВ/ЕСИА, ведомственные витрины), регламенты, приоритеты, люди, санкционные ограничения по стеку. В итоге растёт стоимость изменения: чем позже нашли ошибку, тем дороже переделка.

Практический вывод. Делайте поставку по инкрементам: каждые 2–4 недели показывайте работающий кусок функционала стейкхолдерам (внутренним заказчикам, ИБ, эксплуатации, иногда даже пользователям через пилот).

Подводный камень. «Мы делаем спринты, но не релизимся» — классика. Если инкремент нельзя поставить в тестовый контур и потрогать, это не Agile, это просто планёрки по понедельникам.

Как реально выглядит Agile Waterfall: схема двух контуров

Контур 1 (внешний): Waterfall для начальства, закупок и контроля

• Фиксируем рамки: бюджет, сроки этапов, критерии приёмки.
• Делаем этапность: Аналитика → Проектирование → Разработка → Внедрение, но внутри этапов — итерации.
• Документы не исчезают: они становятся контейнером неопределённости, а не “каменными скрижалями”.

Лайфхак Agile: закладывайте в ТЗ «коридоры» — например, диапазоны по нефункциональным требованиям, перечень интеграций “по мере готовности”, и самое важное: процедуру управления изменениями (Change Request), чтобы не устраивать войну за каждую правку.

Контур 2 (внутренний): Agile для команды, чтобы не утонуть

• Backlog (бэклог) = список работ, отсортированный по ценности и рискам.
• Sprint/Iteration = короткий цикл 1–3 недели, где есть цель и измеримый результат.
• Definition of Done = что значит «готово» (код, тесты, документация, согласования ИБ — да, тоже).

Подводный камень. Если ИБ/архитектура/эксплуатация подключаются только в конце — вы сами строите “водопадную бомбу замедленного действия”. В гибриде эти роли должны входить в ритм поставки.

Кейсы Agile Waterfall: один удачный и один “так делать не надо”

Кейс №1 (удачный): “витрина данных для руководства” с итерациями и формальной приёмкой

Ситуация. Делали внутреннюю витрину отчётности (дашборды) на российском стеке (условно: ClickHouse/PostgreSQL + Superset/аналоги + интеграции с корпоративным DWH). Срок сверху — 6 месяцев, бюджет фикс, приёмка по этапам.

Что сделали. Разбили проект на 3 больших этапа (Waterfall), а внутри — 2-недельные итерации (Agile). В конце каждой итерации показывали работающий отчёт на тестовых данных. Для руководства — ежемесячный статус по этапам. Для команды — нормальный backlog и приоритизация.

Результат. На 2-м месяце выяснили, что 30% метрик «красивые, но не нужны». Выкинули их без боли, потому что не успели “закопать” в монолит. Это и есть экономия: меньше разработки, меньше согласований, меньше поддержки.

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

Кейс №2 (провальный): “Scrum по документам”

Ситуация. Команда отчиталась, что у них Scrum: спринты, стендапы, Jira… а релиз раз в квартал, потому что “так принято”. ТЗ заморожено, изменения только через долгую переписку.

Что пошло не так. Agile оставили как церемонии, а поставку ценности — как Waterfall. В итоге любые сюрпризы всплывали в конце квартала, когда уже поздно, а команда выгорала, потому что много «движухи» и мало результата.

Вывод. Если у вас нет частой обратной связи через работающий функционал — это не гибрид, это имитация управления.

Лайфхаки Agile Waterfall, которые реально спасают сроки и нервы

1) Декомпозиция “по рискам”, а не “по модулям”

Тезис. Самые рискованные куски делайте первыми: интеграции, производительность, безопасность.

Практика. Сначала поднимите сквозной «тонкий» сценарий (вертикальный срез): авторизация (ЕСИА/внутренняя), один бизнес-процесс, одна интеграция, один отчёт. Это даст реальную картину сложности.

Подводный камень. Начать с “красивого интерфейса” без сложной начинки — быстрый способ получить презентацию вместо системы.

2) “Контракт на результат”, а не “контракт на список фич”

Тезис. В закупках часто хотят зафиксировать всё. Но можно фиксировать критерии результата: SLA, время ответа, сценарии, объёмы данных, требования ИБ.

Практический вывод. Там, где закон и процедура позволяют, формулируйте приёмку через измеримые метрики и пользовательские сценарии. Фичи пусть плавают внутри коридора приоритетов.

Подводный камень. Если критерии приёмки размыты (“удобный интерфейс”), вы купите бесконечные переделки.

3) Общая “линия поставки”: разработка + тестирование + ИБ + эксплуатация

Тезис. В госкорпорациях узкое горлышко — не разработка, а согласования и ввод в контур.

Практика. Введите Definition of Done, где учтены: автотесты, статанализ, требования ИБ, документация для эксплуатации. Да, сначала будет медленнее. Потом — резко быстрее.

Подводный камень. Отделить “код готов” от “можно внедрять” — любимая ловушка начинающих РМ/PO.

Сколько это стоит по рынку (и почему новичкам важно понимать контекст)

Если вы нацелены на роли типа Project Manager / Business Analyst / Product Owner в таких компаниях, вам платят не за «знание Scrum-слов», а за умение пройти между Сциллой регламентов и Харибдой разработки.

Коммерческий фактор. На рынке РФ обучение Agile/PM/BA обычно стоит от 30–150 тыс. ₽ за программу, а “профпереподготовка” может уходить и выше. Скрытая цена — время (2–6 месяцев) и необходимость практики: без кейсов вам будет сложно на собеседованиях, потому что спрашивают не «что такое спринт», а «как вы принимали изменения в ТЗ и кто подписывал».

Экспертный вердикт и инструмент: как понять, что вам подходит Agile Waterfall

Гибрид Agile Waterfall — нормальная модель для госкорпораций, если вы честно разделяете “витрину предсказуемости” для внешних обязательств и “двигатель адаптивности” для команды. Ваша задача — не устроить религиозную войну методологий, а снизить стоимость ошибки и не сорвать приёмку.

1. Где у нас фикс (не обсуждается): бюджет, дата, регуляторика, контуры, ИБ-требования?
2. Где у нас флекс (можно двигать): приоритеты фич, детализация требований, порядок реализации?
3. Как часто заказчик видит работающий результат: раз в 2 недели или раз в квартал “на приёмке”?
4. Кто принимает изменения: есть ли Change Control (процесс управления изменениями) или всё решается в переписке?
5. Что для нас “готово”: код или поставка в тест/пром с документацией и согласованием ИБ?

Частые вопросы