[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"general-list":3,"footer-feature-tags":4,"slate-glossary-term-waterfall":66},true,[5,14,20,29,34,40,46,52,56,62],{"id":6,"name":7,"hex":8,"translations":9,"count_pages":13},8,"Компания","#f40925",{"ru":10,"en":11},{"name":7},{"name":12},"Company",9,{"id":15,"name":16,"hex":17,"translations":18,"count_pages":6},26,"Главная страница",null,{"ru":19},{"name":16},{"id":21,"name":22,"hex":23,"translations":24,"count_pages":28},2,"Проекты","#3027ff",{"ru":25,"en":26},{"name":22},{"name":27},"Project",15,{"id":30,"name":31,"hex":17,"translations":32,"count_pages":21},33,"ИИ",{"ru":33},{"name":31},{"id":35,"name":36,"hex":17,"translations":37,"count_pages":39},34,"Комментарии",{"ru":38},{"name":36},4,{"id":41,"name":42,"hex":17,"translations":43,"count_pages":45},25,"Задачи",{"ru":44},{"name":42},24,{"id":47,"name":48,"hex":17,"translations":49,"count_pages":51},27,"Рабочие пространства",{"ru":50},{"name":48},3,{"id":45,"name":53,"hex":17,"translations":54,"count_pages":6},"Kanban-доска",{"ru":55},{"name":53},{"id":57,"name":58,"hex":17,"translations":59,"count_pages":61},23,"Диаграмма Ганта",{"ru":60},{"name":58},1,{"id":28,"name":63,"hex":17,"translations":64,"count_pages":61},"Календарь",{"ru":65},{"name":63},{"detail":67,"more":223},{"id":68,"slug":69,"translations":70,"category":84,"tags":91,"letter":128,"og_image":17,"cover":17,"author_name":17,"author_position":17,"author_avatar":17,"faqs":129,"related":161,"views_count":51,"helpful_yes_count":132,"helpful_no_count":132,"created_at":220,"updated_at":221,"published_at":222},416,"waterfall",{"ru":71},{"title":72,"short_definition":73,"tldr":74,"full_explanation":75,"when_to_apply":76,"when_not_to_apply":77,"examples":78,"tips":79,"synonyms":80,"translation_en":81,"seo_title":82,"seo_description":83},"Каскадная модель (Waterfall)","Каскадная модель — линейный подход к разработке, где каждая фаза (требования, дизайн, реализация, тестирование, внедрение, поддержка) стартует только после формального закрытия предыдущей.","Waterfall — строго последовательный жизненный цикл: следующая фаза открывается только после закрытия предыдущей.\n«Канонический» waterfall из шести этапов — упрощение статьи Ройса 1970 года, где сам автор предупреждал об опасности чистой линейности и предлагал повторные проходы.\nПлюс — предсказуемый бюджет и срок; цена — позднее обнаружение проблем и дорогие правки задним числом.\nВ академическом разборе одного крупномасштабного waterfall-проекта (Petersen, Wohlin, Baca, 2009) зафиксировано 26% отброшенных требований и 31% дефектов, дошедших до системного тестирования.\nВыбор между каскадом и Agile — вопрос не идеологии, а стоимости изменения требования на поздней фазе.","\u003Ch2>Что такое каскадная модель и откуда она взялась\u003C\u002Fh2>\u003Cp>Каскадная модель (waterfall) — линейный \u003Ca href=\"\u002Fglossary\u002Fproject-life-cycle\u002F\" data-term-slug=\"project-life-cycle\">жизненный цикл проекта\u003C\u002Fa>, в котором фазы выполняются строго последовательно: следующая начинается только после формального закрытия предыдущей. Никакого параллельного выполнения этапов и, в теории, никакого возврата назад.\u003C\u002Fp>\u003Cp>Есть устойчивый миф, что «классический waterfall» придумал Уинстон Ройс в статье 1970 года «Managing the Development of Large Software Systems». На самом деле в этой статье Ройс описывает чисто последовательную схему как рискованную и сам предлагает её модифицировать — вводить повторные проходы между соседними этапами и вовлекать заказчика на промежуточных стадиях, а не только в конце. То есть «канонический» жёсткий waterfall из шести непересекающихся блоков — упрощённая интерпретация, сложившаяся в индустрии и учебниках задним числом, а не то, что предлагал сам автор термина.\u003C\u002Fp>\u003Ch2>Шесть фаз каскада: что происходит на каждой и чем она закрывается\u003C\u002Fh2>\u003Cp>В большинстве современных описаний waterfall сведён к шести фазам:\u003C\u002Fp>\u003Cul>\u003Cli>\u003Cstrong>Требования\u003C\u002Fstrong> — сбор и фиксация того, что должна делать система; выход — техническое задание или спецификация требований.\u003C\u002Fli>\u003Cli>\u003Cstrong>Проектирование\u003C\u002Fstrong> — архитектура, интерфейсы, структура данных; выход — проектная документация.\u003C\u002Fli>\u003Cli>\u003Cstrong>Реализация\u003C\u002Fstrong> — написание кода или производство продукта по проекту; выход — готовый компонент или система.\u003C\u002Fli>\u003Cli>\u003Cstrong>Тестирование\u003C\u002Fstrong> — проверка соответствия требованиям; выход — протокол испытаний, список дефектов.\u003C\u002Fli>\u003Cli>\u003Cstrong>Внедрение\u003C\u002Fstrong> — передача в эксплуатацию; выход — акт внедрения, приёмка заказчиком.\u003C\u002Fli>\u003Cli>\u003Cstrong>Сопровождение\u003C\u002Fstrong> — устранение ошибок и доработки после запуска.\u003C\u002Fli>\u003C\u002Ful>\u003Cp>Ключевая особенность не в названии этапов, а в том, что переход возможен только после точки приёмки — формального подтверждения, что артефакт фазы завершён и принят. Именно это делает waterfall удобным для контрактной работы: каждая фаза — это веха, к которой привязаны платежи и отчётность.\u003C\u002Fp>\u003Ch2>Что каскад даёт и чем за это платит\u003C\u002Fh2>\u003Cp>Плюсы каскадной модели понятны и объясняют, почему она до сих пор жива:\u003C\u002Fp>\u003Cul>\u003Cli>бюджет, сроки и объём работ фиксируются до старта проекта;\u003C\u002Fli>\u003Cli>отчётность прозрачна — заказчик видит прогресс по завершённым фазам, а не по абстрактному «процент готовности»;\u003C\u002Fli>\u003Cli>низкая \u003Ca href=\"\u002Fglossary\u002Fdependency\u002F\" data-term-slug=\"dependency\">зависимость\u003C\u002Fa> от состава команды — документация на входе каждой фазы позволяет заменить исполнителя без глубокого погружения в контекст.\u003C\u002Fli>\u003C\u002Ful>\u003Cp>Цена этой предсказуемости — позднее обнаружение проблем. Petersen, Wohlin и Baca в статье «The Waterfall Model in Large-Scale Development» (2009) разобрали один крупномасштабный индустриальный waterfall-проект и показали главное: заметная доля требований отбрасывается уже по ходу работы, а почти треть дефектов доезжает до системного тестирования — самой дорогой стадии обнаружения. Конкретные метрики этого проекта приведены ниже, в разделе с примерами. Эти цифры — метрики одного проекта, а не отраслевая статистика. Их ценность не в обобщении «каскад плохой», а в том, что они дают ориентир для сравнения: если в вашем проекте доля отброшенных требований и поздних дефектов сопоставима или выше — это сигнал, что чистая каскадная схема здесь работает на грани применимости.\u003C\u002Fp>\u003Ch2>Каскад против \u003Ca href=\"\u002Fglossary\u002Fagile\u002F\" data-term-slug=\"agile\">Agile\u003C\u002Fa>: не идеология, а тип неопределённости\u003C\u002Fh2>\u003Cp>Спор «waterfall или Agile» обычно ведётся как спор философий, но практический критерий гораздо проще: известны ли требования заранее и сколько стоит их изменение на поздней фазе.\u003C\u002Fp>\u003Cfigure class=\"shtab-visual\">\u003Cimg src=\"https:\u002F\u002Fshtab.app\u002Fblog\u002Fcontent\u002Fimages\u002F2026\u002F09\u002Fcover-119.jpg\" alt=\"Когда какой подход соответствует типу неопределённости\" loading=\"lazy\" decoding=\"async\">\u003Cfigcaption>Когда какой подход соответствует типу неопределённости\u003C\u002Ffigcaption>\u003C\u002Ffigure>\u003Cp>Если требования стабильны и цена ошибки высока (строительство, медицинское оборудование, регулируемые поставки), низкая частота запросов на изменение, как в исследовании выше, означает, что каскад работает предсказуемо. Если же требования меняются каждые одну-две недели, а рынок или продукт не устоялись, каскад не защищает от риска, а откладывает его обнаружение на самый дорогой момент — тестирование или внедрение, превращая процесс в бюрократию поверх постоянных переделок.\u003C\u002Fp>\u003Ch2>Гибриды: где каскад живёт в 2026 году\u003C\u002Fh2>\u003Cp>На практике чистый waterfall в разработке ПО сегодня редкость. Гораздо чаще встречается гибридная схема: каскадная рамка сверху — контракты, фазовые гейты, вехи, приёмка заказчиком — и итеративная разработка внутри фазы реализации, где команда работает короткими циклами, не нарушая формальной структуры контракта.\u003C\u002Fp>\u003Cp>Территория, где каскад остаётся основным подходом без гибридизации, — это проекты с высокой ценой ошибки и слабой обратимостью решений: строительство, госзаказ, авиационная и медицинская отрасль, крупные аппаратные разработки. Там цена «отката» физически или юридически слишком высока, чтобы позволить себе итеративность в чистом виде.\u003C\u002Fp>","\u003Cul>\u003Cli>Требования известны заранее и вряд ли изменятся до конца проекта\u003C\u002Fli>\u003Cli>Проект контрактный, с фиксированным бюджетом и жёсткими вехами приёмки\u003C\u002Fli>\u003Cli>Ошибка на поздней фазе стоит критически дорого — строительство, медицина, авиация, госзаказ\u003C\u002Fli>\u003Cli>Нужна прозрачная отчётность перед заказчиком или регулятором по завершённым этапам\u003C\u002Fli>\u003Cli>Состав команды может меняться, а документация на входе каждой фазы должна компенсировать потерю контекста\u003C\u002Fli>\u003C\u002Ful>","\u003Cul>\u003Cli>Требования заведомо будут уточняться по ходу работы — продукт ищет рынок, гипотезы не проверены\u003C\u002Fli>\u003Cli>Цена изменения требования на поздней фазе низкая, а частота изменений высокая (продуктовая разработка, стартапы)\u003C\u002Fli>\u003Cli>Заказчик или пользователи не могут сформулировать требования полностью до старта\u003C\u002Fli>\u003Cli>Команда работает в среде, где обратная связь важнее формальной приёмки на каждом шаге\u003C\u002Fli>\u003Cli>Проект короткий, и накладные расходы на фазовую документацию не окупаются\u003C\u002Fli>\u003C\u002Ful>","\u003Cp>\u003Cstrong>Академический кейс: крупномасштабный waterfall-проект (Petersen, Wohlin, Baca, 2009).\u003C\u002Fstrong> Исследователи разобрали один реальный индустриальный проект, реализованный по классической каскадной схеме, и получили измеримые метрики: 0,076 запроса на изменение на одно реализованное требование, 26% требований, которые в итоге отбросили и не стали реализовывать, и 31% дефектов, дошедших до стадии системного тестирования — то есть почти треть ошибок нашли уже после того, как код прошёл через все ранние фазы. Вывод авторов: строгий каскад в таком масштабе плохо справляется с изменчивостью требований, и часть проблем, которые могли бы вскрыться раньше, доезжают до самой дорогой стадии обнаружения.\u003C\u002Fp>\u003Cp>\u003Cstrong>Аналогия: госконтракт по 44-ФЗ.\u003C\u002Fstrong> В госзакупках техническое задание фиксируется на этапе тендера, оплата привязана к актам приёмки этапов, а изменение требований после подписания контракта требует формальной процедуры допсоглашения. Каскадная модель структурно совпадает с логикой контрактного госзаказа: фазовые гейты waterfall и вехи приёмки по 44-ФЗ — это одна и та же управленческая механика, просто в разных терминах.\u003C\u002Fp>","\u003Cp>\u003Cstrong>Совет от Shtab:\u003C\u002Fstrong> сделайте фазовые гейты видимыми на доске задач. Заведите колонки по фазам каскада — требования, проектирование, реализация, тестирование, внедрение — и к каждой границе между колонками привяжите отдельную задачу-веху с чек-листом приёмки: фаза считается закрытой только когда все задачи предыдущей колонки завершены и пункты чек-листа отмечены. Запросы на изменение требований заведите как отдельные задачи с тегом «change request» и раз в месяц сравнивайте их количество с числом закрытых задач фазы: если запросов на изменение стало больше, чем закрытых задач, — чистый каскад в этом проекте уже не работает, и пора переходить на гибридную схему.\u003C\u002Fp>","водопадная модель, водопад, waterfall, каскадная модель разработки, линейная модель разработки, каскадный жизненный цикл","Waterfall model","Каскадная модель (Waterfall): что это и когда применять","Каскадная модель простыми словами: фазы, миф о Ройсе, цифры из исследования крупного проекта и тест выбора между waterfall и Agile.",{"id":51,"slug":85,"hex":86,"icon":17,"order":51,"translations":87},"pm-classic","#3a4058",{"ru":88},{"title":89,"description":90},"Классическое проектное управление","Традиционные методологии и инструменты PM: PMBOK, PRINCE2, PMI, WBS, RACI, диаграмма Ганта, критический путь, EVM, управление рисками и заинтересованными сторонами.",[92,98,106,114,119],{"id":61,"slug":93,"kind":93,"hex":94,"order":61,"translations":95},"methodology","#5e79ec",{"ru":96},{"title":97},"Методология",{"id":99,"slug":100,"kind":101,"hex":94,"order":102,"translations":103},11,"planning","phase",12,{"ru":104},{"title":105},"Планирование",{"id":107,"slug":108,"kind":101,"hex":109,"order":110,"translations":111},14,"process","#4b5370",22,{"ru":112},{"title":113},"Процесс",{"id":28,"slug":101,"kind":101,"hex":115,"order":57,"translations":116},"#888ca0",{"ru":117},{"title":118},"Этап",{"id":120,"slug":121,"kind":122,"hex":123,"order":124,"translations":125},17,"model","framework","#352eb3",30,{"ru":126},{"title":127},"Модель","К",[130,137,143,149,155],{"id":131,"order":132,"translations":133},2073,0,{"ru":134},{"question":135,"answer":136},"Чем каскадная модель отличается от Agile и Scrum?","\u003Cp>Каскад фиксирует требования, бюджет и сроки до старта и проходит фазы строго последовательно — от требований до сопровождения. Agile и Scrum строят продукт короткими итерациями, допуская изменение требований на каждом спринте. Разница не в «правильности», а в типе неопределённости: каскад подходит, когда требования стабильны, Agile — когда они меняются по ходу работы.\u003C\u002Fp>",{"id":138,"order":61,"translations":139},2074,{"ru":140},{"question":141,"answer":142},"Какие этапы входят в каскадную модель и обязательно ли их шесть?","\u003Cp>Чаще всего описывают шесть фаз: требования, проектирование, реализация, тестирование, внедрение и сопровождение. Но это условное деление — в разных индустриях и версиях модели фаз может быть четыре или восемь, важен не их точный список, а принцип: каждая фаза закрывается формальной приёмкой перед переходом к следующей.\u003C\u002Fp>",{"id":144,"order":21,"translations":145},2075,{"ru":146},{"question":147,"answer":148},"Можно ли в waterfall вернуться на предыдущий этап, если требования изменились?","\u003Cp>В теории чистый каскад такого не предусматривает — это одна из главных претензий к модели. На практике возврат возможен, но оформляется как формальное изменение (change request), которое требует пересмотра сроков, бюджета и иногда согласования с заказчиком, поэтому обходится дороже, чем правка на ранней фазе.\u003C\u002Fp>",{"id":150,"order":51,"translations":151},2076,{"ru":152},{"question":153,"answer":154},"Устарела ли каскадная модель и где её всё ещё применяют?","\u003Cp>В чистой разработке ПО каскад действительно уступил гибким и гибридным подходам. Но в строительстве, госзаказе, авиации, медицинском оборудовании и других регулируемых или слабо обратимых отраслях каскадная логика фазовых гейтов и вех приёмки остаётся основой планирования — там цена ошибки и стоимость отката слишком высоки для чистой итеративности.\u003C\u002Fp>",{"id":156,"order":39,"translations":157},2077,{"ru":158},{"question":159,"answer":160},"Правда ли, что каскадную модель придумал Уинстон Ройс?","\u003Cp>Отчасти. Ройс в статье 1970 года описал последовательную схему фаз, но сам назвал её рискованной и предложил модификации — повторные проходы между соседними этапами и вовлечение заказчика на промежуточных стадиях. Жёсткий «канонический» waterfall без возврата назад — это упрощённая интерпретация индустрии и учебников, а не то, что предлагал сам автор.\u003C\u002Fp>",{"parent":162,"antonym":170,"child":177,"related":185},[163],{"id":164,"slug":165,"translations":166},407,"project-life-cycle",{"ru":167},{"title":168,"short_definition":169},"Жизненный цикл проекта","Структурированная последовательность фаз от инициации до закрытия, задающая правила перехода между этапами и точки принятия решений.",[171],{"id":61,"slug":172,"translations":173},"agile",{"ru":174},{"title":175,"short_definition":176},"Agile","Семейство гибких подходов к разработке продуктов и управлению проектами, основанное на коротких итерациях и быстрой адаптации к изменениям.",[178],{"id":179,"slug":180,"translations":181},78,"quality-gate",{"ru":182},{"title":183,"short_definition":184},"Quality Gate (контрольная точка проекта)","Контрольная точка между фазами проекта, на которой проверяется соответствие критериям перед переходом дальше.",[186,193,199,206,213],{"id":187,"slug":188,"translations":189},51,"prince2",{"ru":190},{"title":191,"short_definition":192},"PRINCE2 (методология управления проектами)","Структурированная методология управления проектами, созданная британским правительством: распространена в Великобритании и госсекторе.",{"id":194,"slug":195,"translations":196},54,"gantt",{"ru":197},{"title":58,"short_definition":198},"Графическое представление календарного плана проекта с задачами в виде горизонтальных полос на временной оси.",{"id":200,"slug":201,"translations":202},69,"triple-constraint",{"ru":203},{"title":204,"short_definition":205},"Triple Constraint (Тройственное ограничение)","Базовая модель управления проектом: объём работ, сроки и бюджет связаны так, что улучшить все три сразу невозможно.",{"id":207,"slug":208,"translations":209},61,"change-request",{"ru":210},{"title":211,"short_definition":212},"Change Request (Запрос на изменение)","Формальный документ, которым запрашивают изменение объёма работ, сроков, бюджета или других параметров проекта.",{"id":214,"slug":215,"translations":216},63,"milestone",{"ru":217},{"title":218,"short_definition":219},"Milestone (Контрольная точка)","Значимое событие в проекте — обычно завершение этапа или достижение ключевого результата.","2026-09-10T12:37:39.366031+03:00","2026-09-10T12:37:39.366048+03:00","2026-09-10T12:37:39.576578+03:00",[224,249,268],{"id":225,"slug":226,"translations":227,"category":232,"tags":235,"letter":247,"cover":17,"updated_at":248,"published_at":17},65,"baseline",{"ru":228},{"title":229,"short_definition":230,"translation_en":231},"Baseline (базовый план)","Утверждённая версия плана проекта по содержанию, срокам и бюджету — точка отсчёта для контроля отклонений и изменений.","Baseline",{"id":51,"slug":85,"hex":86,"icon":17,"order":51,"translations":233},{"ru":234},{"title":89,"description":90},[236,242],{"id":39,"slug":237,"kind":238,"hex":115,"order":39,"translations":239},"artifact","other",{"ru":240},{"title":241},"Артефакт",{"id":6,"slug":243,"kind":238,"hex":109,"order":6,"translations":244},"concept",{"ru":245},{"title":246},"Концепция","B","2026-04-25T22:42:17.413625+03:00",{"id":207,"slug":208,"translations":250,"category":253,"tags":256,"letter":266,"cover":17,"updated_at":267,"published_at":17},{"ru":251},{"title":211,"short_definition":212,"translation_en":252},"Change Request (CR)",{"id":51,"slug":85,"hex":86,"icon":17,"order":51,"translations":254},{"ru":255},{"title":89,"description":90},[257,260,263],{"id":39,"slug":237,"kind":238,"hex":115,"order":39,"translations":258},{"ru":259},{"title":241},{"id":6,"slug":243,"kind":238,"hex":109,"order":6,"translations":261},{"ru":262},{"title":246},{"id":107,"slug":108,"kind":101,"hex":109,"order":110,"translations":264},{"ru":265},{"title":113},"C","2026-04-25T22:42:17.323214+03:00",{"id":269,"slug":270,"translations":271,"category":276,"tags":279,"letter":266,"cover":17,"updated_at":290,"published_at":17},72,"contingency-plan",{"ru":272},{"title":273,"short_definition":274,"translation_en":275},"Contingency Plan (план реагирования на риск)","План действий на случай, если риск всё-таки наступит: что именно делает команда, чтобы снизить ущерб.","Contingency Plan",{"id":51,"slug":85,"hex":86,"icon":17,"order":51,"translations":277},{"ru":278},{"title":89,"description":90},[280,283],{"id":6,"slug":243,"kind":238,"hex":109,"order":6,"translations":281},{"ru":282},{"title":246},{"id":284,"slug":285,"kind":238,"hex":286,"order":45,"translations":287},16,"risk","#ff6a6a",{"ru":288},{"title":289},"Риски","2026-04-25T22:42:17.574403+03:00"]