[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"general-list":3,"footer-feature-tags":4,"slate-glossary-term-waterfall-example":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":241},{"id":68,"slug":69,"translations":70,"category":84,"tags":91,"letter":119,"og_image":17,"cover":17,"author_name":17,"author_position":17,"author_avatar":17,"faqs":120,"related":152,"views_count":47,"helpful_yes_count":123,"helpful_no_count":123,"created_at":238,"updated_at":239,"published_at":240},406,"waterfall-example",{"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 пример","Примеры применения каскадной модели в строительстве, производстве и регулируемой IT-разработке с разбором фаз, рисков и сравнением с Agile.","Waterfall — строго последовательная модель: требования → проектирование → разработка → тестирование → внедрение → поддержка.\nКаждая фаза начинается только после полного завершения предыдущей; возврат назад формально не предусмотрен.\nМодель оправдана там, где требования фиксированы, регуляторная нагрузка высока и цена ошибки на старте критична.\nВ динамичных средах Agile и гибридные схемы показывают более высокую вероятность успеха — особенно когда требования меняются в процессе.\nГибридный подход (Waterfall для фаз с фиксированным scope + Agile для итеративных блоков) в ряде исследований показывает лучшие результаты по срокам и затратам по сравнению с чистыми подходами.","\u003Ch2>Что такое Waterfall-модель и из каких фаз она состоит\u003C\u002Fh2>\u003Cp>Waterfall (каскадная, или водопадная, модель) — предсказательный подход к управлению проектами, разработанный в 1970-х годах. Проект делится на строго последовательные фазы, каждая из которых полностью завершается до старта следующей. Классическая цепочка выглядит так:\u003C\u002Fp>\u003Cfigure class=\"shtab-visual\">\u003Cimg src=\"https:\u002F\u002Fshtab.app\u002Fblog\u002Fcontent\u002Fimages\u002F2026\u002F09\u002Fcover-88.jpg\" alt=\"Последовательность фаз каскадной модели — каждая открывается только после закрытия предыдущей\" loading=\"lazy\" decoding=\"async\">\u003Cfigcaption>Последовательность фаз каскадной модели — каждая открывается только после закрытия предыдущей\u003C\u002Ffigcaption>\u003C\u002Ffigure>\u003Col>\u003Cli>\u003Cstrong>Требования\u003C\u002Fstrong> — сбор, согласование и фиксация всего объёма требований; итогом служит утверждённое техническое задание или SRS (Software Requirements Specification).\u003C\u002Fli>\u003Cli>\u003Cstrong>Проектирование\u003C\u002Fstrong> — архитектурные решения, схемы, прототипы; на выходе — проектная документация, которая становится контрактом между аналитиками и разработчиками.\u003C\u002Fli>\u003Cli>\u003Cstrong>Разработка \u002F Реализация\u003C\u002Fstrong> — создание продукта строго по утверждённому проекту; изменения требований на этом этапе формально запрещены или проходят через \u003Ca href=\"\u002Fglossary\u002Fchange-request\u002F\" data-term-slug=\"change-request\">change request\u003C\u002Fa>.\u003C\u002Fli>\u003Cli>\u003Cstrong>Тестирование\u003C\u002Fstrong> — проверка соответствия результата требованиям; дефекты фиксируются и устраняются, но новые требования не принимаются.\u003C\u002Fli>\u003Cli>\u003Cstrong>Внедрение\u003C\u002Fstrong> — передача продукта заказчику, развёртывание в боевой среде.\u003C\u002Fli>\u003Cli>\u003Cstrong>Поддержка\u003C\u002Fstrong> — эксплуатация и сопровождение; любые существенные изменения инициируют новый проект или формальный change request.\u003C\u002Fli>\u003C\u002Fol>\u003Cp>Ключевая особенность модели — критическая роль upfront-аналитики. Ошибка в требованиях, обнаруженная на фазе тестирования, обходится в разы дороже, чем та же ошибка, найденная на фазе требований. Именно поэтому Waterfall требует зрелых аналитических компетенций и плотного участия заказчика на самом первом этапе.\u003C\u002Fp>\u003Ch2>Примеры Waterfall-проектов по отраслям\u003C\u002Fh2>\u003Ch3>Строительство: многоэтажный жилой дом\u003C\u002Fh3>\u003Cp>\u003Cstrong>Контекст.\u003C\u002Fstrong> Застройщик возводит 18-этажный жилой комплекс. Требования зафиксированы в проектной документации, согласованной с госэкспертизой. Изменить планировку после заливки монолитного каркаса физически невозможно без сноса конструкций.\u003C\u002Fp>\u003Cp>\u003Cstrong>Как работает Waterfall.\u003C\u002Fstrong> Фазы жёстко упорядочены: геодезия и изыскания → проектирование → согласование → земляные работы и фундамент → возведение каркаса → инженерные сети → отделка → сдача в эксплуатацию. Каждый этап закрывается актом, который служит gate-критерием для перехода к следующему. Параллельный старт зависимых этапов невозможен: нельзя монтировать инженерные сети до завершения каркаса.\u003C\u002Fp>\u003Cp>\u003Cstrong>Результат.\u003C\u002Fstrong> Предсказуемость бюджета и сроков высокая при условии качественной проектной документации. Стоимость изменений после старта строительства резко возрастает на каждой последующей фазе — именно поэтому строительная отрасль исторически является классическим примером применения каскадной модели.\u003C\u002Fp>\u003Ch3>Производство: запуск новой продукции на линию\u003C\u002Fh3>\u003Cp>\u003Cstrong>Контекст.\u003C\u002Fstrong> Производитель бытовой техники выводит новую модель холодильника. Продукт должен соответствовать техническим регламентам ЕАЭС, пройти сертификацию и встать на конвейер в фиксированную дату.\u003C\u002Fp>\u003Cp>\u003Cstrong>Как работает Waterfall.\u003C\u002Fstrong> Цепочка: маркетинговое ТЗ → инженерное проектирование → прототипирование и испытания → подготовка производства (оснастка, закупка компонентов) → пилотная партия → сертификация → серийный выпуск. Каждый этап зависит от предыдущего: сертификацию нельзя начать до завершения испытаний, а подготовку производства — до утверждения конструкторской документации.\u003C\u002Fp>\u003Cp>\u003Cstrong>Результат.\u003C\u002Fstrong> Жёсткая последовательность обеспечивает трассируемость: каждое техническое решение задокументировано и может быть проверено регулятором. Scope creep исключён конструктивно — изменение компонента после запуска оснастки требует повторной сертификации и дополнительных затрат.\u003C\u002Fp>\u003Ch3>Регулируемая IT-разработка: банковская core-система\u003C\u002Fh3>\u003Cp>\u003Cstrong>Контекст.\u003C\u002Fstrong> Банк внедряет новую АБС (автоматизированную банковскую систему). Требования определены регулятором, внутренними политиками и договором с вендором. Система должна пройти аудит безопасности и получить разрешение на эксплуатацию.\u003C\u002Fp>\u003Cp>\u003Cstrong>Как работает Waterfall.\u003C\u002Fstrong> Фазы: сбор и согласование требований (BRD, SRS) → системное проектирование → разработка и кастомизация → интеграционное тестирование → UAT → аудит безопасности → промышленная эксплуатация. Каждая фаза закрывается пакетом документов, который проверяется внутренним PMO и внешним аудитором. Изменения требований после подписания SRS проходят через change request board с оценкой влияния на сроки и бюджет.\u003C\u002Fp>\u003Cp>\u003Cstrong>Результат.\u003C\u002Fstrong> Регулятор получает полную трассируемость требований до конкретных функций системы. Проект предсказуем по срокам и бюджету, однако любое изменение требований на поздних фазах существенно увеличивает стоимость — именно поэтому качество SRS становится ключевым фактором успеха.\u003C\u002Fp>\u003Ch2>Waterfall vs Agile vs гибрид: когда каскад оправдан\u003C\u002Fh2>\u003Cp>Сравнительные академические исследования фиксируют заметную разницу в вероятности успеха между подходами. В динамичных средах с меняющимися требованиями Agile-проекты демонстрируют более высокую вероятность успеха, чем чистый Waterfall, а доля провальных проектов у каскадной модели заметно выше. Исследования BI-проектов также указывают на то, что Agile-команды чаще фиксируют положительный ROI по сравнению с командами, работающими по Waterfall.\u003C\u002Fp>\u003Cp>Тем не менее эти данные относятся к динамичным средам с меняющимися требованиями. В средах с фиксированными требованиями и высокой регуляторной нагрузкой картина иная:\u003C\u002Fp>\u003Cul>\u003Cli>\u003Cstrong>Waterfall\u003C\u002Fstrong> даёт предсказуемость сроков и бюджета, полную трассируемость и соответствие регуляторным требованиям к документации.\u003C\u002Fli>\u003Cli>\u003Cstrong>Agile\u003C\u002Fstrong> выигрывает при частых изменениях требований, коротких циклах обратной связи и высокой неопределённости продукта.\u003C\u002Fli>\u003Cli>\u003Cstrong>Гибридный подход\u003C\u002Fstrong> — Waterfall для фаз с фиксированным scope (проектирование, сертификация) и Agile для итеративных блоков (разработка фич, UX) — по данным ряда исследований, позволяет улучшить ключевые показатели проекта по сравнению с чистыми подходами, особенно когда часть требований стабильна, а часть подвержена изменениям.\u003C\u002Fli>\u003C\u002Ful>\u003Cp>Вывод: выбор модели определяется не модой, а характеристиками конкретного проекта — стабильностью требований, регуляторной нагрузкой, размером команды и допустимым уровнем неопределённости.\u003C\u002Fp>\u003Ch2>Типичные ошибки при использовании Waterfall и как их избежать\u003C\u002Fh2>\u003Cp>Большинство провалов Waterfall-проектов связаны не с самой моделью, а с её неправильным применением. Три главных риска:\u003C\u002Fp>\u003Ch3>Неполные требования на старте\u003C\u002Fh3>\u003Cp>Если SRS или ТЗ содержат пробелы, они материализуются в дефекты на фазе тестирования или в scope creep на фазе разработки. \u003Cstrong>Контрмера:\u003C\u002Fstrong> quality gate на выходе из фазы требований — документ считается закрытым только после подписи всех стейкхолдеров и прохождения формальной инспекции (walkthrough или review).\u003C\u002Fp>\u003Ch3>Отсутствие обратной связи до финальной фазы\u003C\u002Fh3>\u003Cp>Заказчик видит результат только на UAT и обнаруживает, что продукт не соответствует его ожиданиям, хотя формально соответствует требованиям. \u003Cstrong>Контрмера:\u003C\u002Fstrong> промежуточные демо заказчику в конце каждой фазы — не для изменения требований, а для подтверждения, что понимание не разошлось.\u003C\u002Fp>\u003Ch3>Scope creep без механизма change request\u003C\u002Fh3>\u003Cp>Команда начинает «по-тихому» добавлять функции или менять решения без фиксации изменений. \u003Cstrong>Контрмера:\u003C\u002Fstrong> change request board — любое отклонение от утверждённой документации оформляется как CR с оценкой влияния на сроки, бюджет и риски, и утверждается спонсором проекта.\u003C\u002Fp>\u003Ch2>Как оформить Waterfall-проект: артефакты и инструменты\u003C\u002Fh2>\u003Cp>Минимальный набор артефактов Waterfall-проекта привязан к конкретным фазам и служит gate-критерием перехода:\u003C\u002Fp>\u003Ctable>\u003Cthead>\u003Ctr>\u003Cth>Артефакт\u003C\u002Fth>\u003Cth>Фаза\u003C\u002Fth>\u003Cth>Назначение\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\u003Ctr>\u003Ctd>Устав проекта (\u003Ca href=\"\u002Fglossary\u002Fproject-charter\u002F\" data-term-slug=\"project-charter\">Project Charter\u003C\u002Fa>)\u003C\u002Ftd>\u003Ctd>Инициация\u003C\u002Ftd>\u003Ctd>Фиксирует цели, бюджет, спонсора и \u003Ca href=\"\u002Fglossary\u002Fscope\u002F\" data-term-slug=\"scope\">границы проекта\u003C\u002Fa>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd>SRS \u002F ТЗ\u003C\u002Ftd>\u003Ctd>Требования\u003C\u002Ftd>\u003Ctd>Gate-документ: подписан → фаза закрыта\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd>WBS (\u003Ca href=\"\u002Fglossary\u002Fwbs\u002F\" data-term-slug=\"wbs\">Work Breakdown Structure\u003C\u002Fa>)\u003C\u002Ftd>\u003Ctd>Проектирование\u003C\u002Ftd>\u003Ctd>Декомпозиция работ до уровня задач\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd>\u003Ca href=\"\u002Fglossary\u002Fgantt\u002F\" data-term-slug=\"gantt\">Диаграмма Ганта\u003C\u002Fa> с критическим путём\u003C\u002Ftd>\u003Ctd>Проектирование\u003C\u002Ftd>\u003Ctd>Визуализирует зависимости и резервы времени\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd>Реестр рисков\u003C\u002Ftd>\u003Ctd>Проектирование → Разработка\u003C\u002Ftd>\u003Ctd>Актуализируется на каждой фазе\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd>Журнал изменений (Change Log)\u003C\u002Ftd>\u003Ctd>Разработка → Тестирование\u003C\u002Ftd>\u003Ctd>Фиксирует все CR с решениями и статусами\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd>Протокол UAT\u003C\u002Ftd>\u003Ctd>Тестирование\u003C\u002Ftd>\u003Ctd>Gate-документ перед внедрением\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003Cp>Диаграмма Ганта — центральный инструмент Waterfall: она показывает логику проекта, \u003Ca href=\"\u002Fglossary\u002Fcritical-path\u002F\" data-term-slug=\"critical-path\">критический путь\u003C\u002Fa>, зависимости между задачами и вехи как контрольные точки перехода между фазами. Без неё управление каскадным проектом превращается в ручное отслеживание статусов в таблицах.\u003C\u002Fp>","\u003Cul>\u003Cli>Требования полностью определены и зафиксированы до старта — заказчик не планирует их менять в процессе.\u003C\u002Fli>\u003Cli>Высокая регуляторная нагрузка: проект требует формальной документации, аудита и трассируемости (строительство, медицина, банкинг, госзаказ).\u003C\u002Fli>\u003Cli>Жёсткие физические или технологические зависимости между этапами — нельзя начать следующий, не завершив предыдущий (монолитное строительство, производственная оснастка).\u003C\u002Fli>\u003Cli>Фиксированный бюджет и срок, согласованные с внешним заказчиком или регулятором, — предсказуемость важнее гибкости.\u003C\u002Fli>\u003Cli>Команда и заказчик имеют достаточный опыт для качественной upfront-аналитики и готовы инвестировать время в проработку требований на старте.\u003C\u002Fli>\u003C\u002Ful>","\u003Cul>\u003Cli>Требования размыты или заказчик сам не знает, что хочет — высок риск получить продукт, формально соответствующий ТЗ, но не решающий реальную задачу.\u003C\u002Fli>\u003Cli>Продукт новый, рынок не проверен — нужна итеративная обратная связь от пользователей, которую Waterfall не предусматривает.\u003C\u002Fli>\u003Cli>Команда небольшая (до 5–7 человек) и кросс-функциональная, а проект короче 3 месяцев — накладные расходы на документацию и gate-процедуры съедят значительную долю ресурсов.\u003C\u002Fli>\u003Cli>Технологический стек или архитектурные решения не определены — проектирование без стабильного фундамента приведёт к переделкам на поздних фазах.\u003C\u002Fli>\u003Cli>Частые изменения внешней среды (законодательство, рынок, конкуренты) делают требования устаревшими быстрее, чем завершается фаза разработки.\u003C\u002Fli>\u003C\u002Ful>","\u003Cp>\u003Cstrong>Кейс 1: Строительство многоэтажного жилого комплекса\u003C\u002Fstrong>\u003Cbr>Застройщик возводит жилой комплекс по утверждённой проектной документации. Фазы жёстко упорядочены: изыскания → проектирование → согласование → фундамент → каркас → инженерные сети → отделка → сдача. Каждый этап закрывается актом приёмки — это gate-критерий для перехода к следующему. Параллельный старт зависимых этапов физически невозможен. Результат: при качественной проектной документации бюджет и сроки предсказуемы; изменения после старта строительства дороги кратно — что делает вложения в upfront-аналитику экономически обязательными.\u003C\u002Fp>\u003Cp>\u003Cstrong>Кейс 2: Запуск новой модели бытовой техники на производственную линию\u003C\u002Fstrong>\u003Cbr>Производитель выводит новую модель холодильника, которая должна пройти сертификацию по техническим регламентам ЕАЭС и встать на конвейер к фиксированной дате. Цепочка фаз: маркетинговое ТЗ → инженерное проектирование → прототипирование и испытания → подготовка оснастки → пилотная партия → сертификация → серийный выпуск. Изменение компонента после запуска оснастки требует повторной сертификации. Результат: жёсткая последовательность обеспечивает полную трассируемость для регулятора и исключает scope creep конструктивно.\u003C\u002Fp>\u003Cp>\u003Cstrong>Кейс 3: Внедрение банковской АБС\u003C\u002Fstrong>\u003Cbr>Банк внедряет автоматизированную банковскую систему. Требования определены регулятором и зафиксированы в BRD и SRS, подписанных всеми стейкхолдерами. Фазы: требования → системное проектирование → разработка и кастомизация → интеграционное тестирование → UAT → аудит безопасности → промышленная эксплуатация. Каждое изменение после подписания SRS проходит через change request board. Результат: регулятор получает полную трассируемость требований до конкретных функций системы; проект предсказуем по срокам и бюджету при условии качественного SRS на старте.\u003C\u002Fp>","\u003Cp>\u003Cstrong>Совет от Shtab.\u003C\u002Fstrong> Создайте проект в Shtab с доской в режиме списка, где каждая колонка — фаза Waterfall: Требования, Проектирование, Разработка, Тестирование, Внедрение. Добавьте вехи (milestones) как контрольные точки перехода между фазами — в Shtab веха создаётся как задача с нулевой длительностью и отображается на диаграмме Ганта ромбом, визуально отделяя одну фазу от другой. На диаграмме Ганта настройте зависимости типа «Финиш → Старт» (finish-to-start) между задачами смежных фаз: выделите задачу-предшественник, в поле «Зависимости» укажите задачу-последователь и выберите тип связи FS. После этого Shtab автоматически сдвинет зависимые задачи при изменении сроков предшественника — это поможет команде видеть критический путь и не допускать параллельного старта зависимых этапов вручную.\u003C\u002Fp>","каскадная модель пример, waterfall модель пример, каскадный метод пример, водопадная модель пример","Waterfall example","Waterfall пример: кейсы по отраслям и сравнение с Agile","Реальные примеры Waterfall-проектов в строительстве, производстве и IT-разработке. Фазы модели, типичные ошибки, сравнение с 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],{"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},"Этап","W",[121,128,134,140,146],{"id":122,"order":123,"translations":124},2028,0,{"ru":125},{"question":126,"answer":127},"Какие реальные примеры проектов по Waterfall существуют?","\u003Cp>Классические примеры — строительство зданий и инфраструктуры, запуск новой продукции на производственную линию, внедрение банковских и ERP-систем с жёсткими регуляторными требованиями. Во всех этих случаях требования фиксированы до старта, этапы физически или технологически зависят друг от друга, а стоимость изменений на поздних фазах критически высока. Именно эти условия делают Waterfall оправданным выбором.\u003C\u002Fp>",{"id":129,"order":61,"translations":130},2029,{"ru":131},{"question":132,"answer":133},"Чем Waterfall отличается от Agile на практике?","\u003Cp>В Waterfall все требования фиксируются до старта, фазы выполняются последовательно, заказчик видит результат только на финальном этапе. В Agile работа ведётся короткими итерациями (спринтами), требования могут меняться между итерациями, а заказчик получает рабочий инкремент продукта каждые 1–4 недели. Сравнительные исследования показывают, что Agile даёт более высокую вероятность успеха в динамичных средах с меняющимися требованиями, тогда как Waterfall выигрывает по предсказуемости в проектах с фиксированным scope и высокой регуляторной нагрузкой.\u003C\u002Fp>",{"id":135,"order":21,"translations":136},2030,{"ru":137},{"question":138,"answer":139},"В каких отраслях Waterfall-модель до сих пор эффективна?","\u003Cp>Waterfall остаётся эффективным в строительстве и инфраструктуре, промышленном производстве, аэрокосмической и оборонной отрасли, а также в регулируемой IT-разработке (банки, медицина, госсектор). Общий знаменатель — высокая стоимость изменений после старта, жёсткие требования к документации и трассируемости, а также регуляторные ограничения, которые делают итеративный подход юридически или технически невозможным.\u003C\u002Fp>",{"id":141,"order":51,"translations":142},2031,{"ru":143},{"question":144,"answer":145},"Можно ли совмещать Waterfall и Agile в одном проекте?","\u003Cp>Да, это называется гибридным подходом. Типичная схема: фазы с фиксированным scope и регуляторными требованиями (проектирование, сертификация, аудит) ведутся по Waterfall, а итеративные блоки (разработка функций, UX, интеграции) — по Agile. Ряд исследований указывает на то, что проекты с гибридной схемой чаще показывают улучшение ключевых показателей по сравнению с чистыми подходами, особенно когда часть требований стабильна, а часть подвержена изменениям.\u003C\u002Fp>",{"id":147,"order":39,"translations":148},2032,{"ru":149},{"question":150,"answer":151},"Какие основные этапы Waterfall-модели и что происходит на каждом?","\u003Cp>Классическая цепочка: \u003Cstrong>Требования\u003C\u002Fstrong> — сбор и фиксация всего объёма требований в SRS или ТЗ; \u003Cstrong>Проектирование\u003C\u002Fstrong> — архитектурные решения и проектная документация; \u003Cstrong>Разработка\u003C\u002Fstrong> — создание продукта строго по утверждённому проекту; \u003Cstrong>Тестирование\u003C\u002Fstrong> — проверка соответствия требованиям, устранение дефектов; \u003Cstrong>Внедрение\u003C\u002Fstrong> — передача продукта заказчику; \u003Cstrong>Поддержка\u003C\u002Fstrong> — эксплуатация и сопровождение. Переход между фазами возможен только после закрытия gate-документа предыдущей фазы.\u003C\u002Fp>",{"antonym":153,"related":160,"parent":230},[154],{"id":61,"slug":155,"translations":156},"agile",{"ru":157},{"title":158,"short_definition":159},"Agile","Семейство гибких подходов к разработке продуктов и управлению проектами, основанное на коротких итерациях и быстрой адаптации к изменениям.",[161,167,174,181,188,195,202,209,216,223],{"id":162,"slug":163,"translations":164},54,"gantt",{"ru":165},{"title":58,"short_definition":166},"Графическое представление календарного плана проекта с задачами в виде горизонтальных полос на временной оси.",{"id":168,"slug":169,"translations":170},55,"critical-path",{"ru":171},{"title":172,"short_definition":173},"Критический путь","Самая длинная цепочка зависимых задач в проекте, определяющая минимально возможную длительность проекта.",{"id":175,"slug":176,"translations":177},52,"wbs",{"ru":178},{"title":179,"short_definition":180},"WBS (иерархическая структура работ)","Иерархическая декомпозиция работ проекта на управляемые пакеты сверху вниз.",{"id":182,"slug":183,"translations":184},60,"scope",{"ru":185},{"title":186,"short_definition":187},"Scope (объём проекта)","Совокупность работ, которые нужно выполнить для получения продукта проекта с заданными характеристиками.",{"id":189,"slug":190,"translations":191},61,"change-request",{"ru":192},{"title":193,"short_definition":194},"Change Request (Запрос на изменение)","Формальный документ, которым запрашивают изменение объёма работ, сроков, бюджета или других параметров проекта.",{"id":196,"slug":197,"translations":198},78,"quality-gate",{"ru":199},{"title":200,"short_definition":201},"Quality Gate (контрольная точка проекта)","Контрольная точка между фазами проекта, на которой проверяется соответствие критериям перед переходом дальше.",{"id":203,"slug":204,"translations":205},398,"scrumban",{"ru":206},{"title":207,"short_definition":208},"Scrumban (гибрид Scrum и Kanban)","Способ работы, где от Scrum остаются роли и регулярные встречи, а от Kanban приходят непрерывный поток, доска с реальными этапами и ограничение работы в процессе.",{"id":210,"slug":211,"translations":212},62,"project-charter",{"ru":213},{"title":214,"short_definition":215},"Project Charter (Устав проекта)","Документ, формально запускающий проект: цели, объём работ, бюджет, сроки, ключевые роли и заинтересованные стороны.",{"id":217,"slug":218,"translations":219},70,"risk-register",{"ru":220},{"title":221,"short_definition":222},"Risk Register (реестр рисков)","Документ со списком рисков проекта: описание, вероятность, влияние, ответственный и стратегия реагирования.",{"id":224,"slug":225,"translations":226},63,"milestone",{"ru":227},{"title":228,"short_definition":229},"Milestone (Контрольная точка)","Значимое событие в проекте — обычно завершение этапа или достижение ключевого результата.",[231],{"id":232,"slug":233,"translations":234},49,"pmbok",{"ru":235},{"title":236,"short_definition":237},"PMBOK (свод знаний по управлению проектами)","Свод знаний по управлению проектами от PMI — базовый стандарт классического проектного управления.","2026-09-01T09:59:01.935450+03:00","2026-09-01T09:59:01.935468+03:00","2026-09-01T09:59:02.099286+03:00",[242,267,286],{"id":243,"slug":244,"translations":245,"category":250,"tags":253,"letter":265,"cover":17,"updated_at":266,"published_at":17},65,"baseline",{"ru":246},{"title":247,"short_definition":248,"translation_en":249},"Baseline (базовый план)","Утверждённая версия плана проекта по содержанию, срокам и бюджету — точка отсчёта для контроля отклонений и изменений.","Baseline",{"id":51,"slug":85,"hex":86,"icon":17,"order":51,"translations":251},{"ru":252},{"title":89,"description":90},[254,260],{"id":39,"slug":255,"kind":256,"hex":115,"order":39,"translations":257},"artifact","other",{"ru":258},{"title":259},"Артефакт",{"id":6,"slug":261,"kind":256,"hex":109,"order":6,"translations":262},"concept",{"ru":263},{"title":264},"Концепция","B","2026-04-25T22:42:17.413625+03:00",{"id":189,"slug":190,"translations":268,"category":271,"tags":274,"letter":284,"cover":17,"updated_at":285,"published_at":17},{"ru":269},{"title":193,"short_definition":194,"translation_en":270},"Change Request (CR)",{"id":51,"slug":85,"hex":86,"icon":17,"order":51,"translations":272},{"ru":273},{"title":89,"description":90},[275,278,281],{"id":39,"slug":255,"kind":256,"hex":115,"order":39,"translations":276},{"ru":277},{"title":259},{"id":6,"slug":261,"kind":256,"hex":109,"order":6,"translations":279},{"ru":280},{"title":264},{"id":107,"slug":108,"kind":101,"hex":109,"order":110,"translations":282},{"ru":283},{"title":113},"C","2026-04-25T22:42:17.323214+03:00",{"id":287,"slug":288,"translations":289,"category":294,"tags":297,"letter":284,"cover":17,"updated_at":308,"published_at":17},72,"contingency-plan",{"ru":290},{"title":291,"short_definition":292,"translation_en":293},"Contingency Plan (план реагирования на риск)","План действий на случай, если риск всё-таки наступит: что именно делает команда, чтобы снизить ущерб.","Contingency Plan",{"id":51,"slug":85,"hex":86,"icon":17,"order":51,"translations":295},{"ru":296},{"title":89,"description":90},[298,301],{"id":6,"slug":261,"kind":256,"hex":109,"order":6,"translations":299},{"ru":300},{"title":264},{"id":302,"slug":303,"kind":256,"hex":304,"order":45,"translations":305},16,"risk","#ff6a6a",{"ru":306},{"title":307},"Риски","2026-04-25T22:42:17.574403+03:00"]