[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"general-list":3,"footer-feature-tags":4,"slate-glossary-term-project-life-cycle":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":298},{"id":68,"slug":69,"translations":70,"category":84,"tags":91,"letter":125,"og_image":17,"cover":17,"author_name":17,"author_position":17,"author_avatar":17,"faqs":126,"related":158,"views_count":41,"helpful_yes_count":129,"helpful_no_count":129,"created_at":295,"updated_at":296,"published_at":297},407,"project-life-cycle",{"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},"Жизненный цикл проекта","Структурированная последовательность фаз от инициации до закрытия, задающая правила перехода между этапами и точки принятия решений.","Жизненный цикл проекта — управленческий каркас, задающий правила перехода между фазами.\nGate-критерии определяют, когда команда готова двигаться дальше, а не просто «время пришло».\nPMBOK выделяет 5 групп процессов управления проектом.\nНа практике циклы бывают предиктивными, итеративными, адаптивными и гибридными — выбор определяется уровнем неопределённости требований, а не модой на Agile.\nОтсутствие gate-критериев — главная причина перерасходов даже при формально соблюдённых фазах.","\u003Ch2>Определение и суть жизненного цикла проекта\u003C\u002Fh2>\u003Cp>Жизненный цикл проекта — структурированная последовательность фаз, через которые проект проходит от появления идеи до формального закрытия и передачи результата в эксплуатацию. Ключевая ценность жизненного цикла — не в делении работы на куски, а в том, что он задаёт \u003Cstrong>правила перехода между фазами\u003C\u002Fstrong>. Эти правила называют gate-критериями или phase gates: набор условий, которые должны быть выполнены, прежде чем команда двигается дальше.\u003C\u002Fp>\u003Cp>Пока устав проекта не подписан и стейкхолдеры не идентифицированы — нет смысла открывать планирование. Пока план не утверждён — нет смысла запускать исполнение. Без gate-критериев жизненный цикл превращается в формальность: фазы есть, но команда переходит между ними по инерции, а не по факту готовности.\u003C\u002Fp>\u003Cp>По данным McKinsey (2017, «Delivering large-scale IT projects on time, on budget, and on value»), крупные IT-проекты стоимостью от $15 млн и выше в среднем выходят за рамки бюджета на 45%, а инфраструктурные проекты — ещё значительнее. Исследование Бента Фливберга (Oxford, 2014) на выборке мегапроектов показало, что 9 из 10 крупных инфраструктурных проектов превышают первоначальный бюджет (речь именно о мегапроектах — экстраполировать эту статистику на проекты любого масштаба некорректно). Причина в большинстве случаев одна: решения о переходе между фазами принимались без проверки реальной готовности.\u003C\u002Fp>\u003Ch2>Классическая модель: 5 фаз по \u003Ca href=\"\u002Fglossary\u002Fpmbok\u002F\" data-term-slug=\"pmbok\">PMBOK\u003C\u002Fa> и их содержание\u003C\u002Fh2>\u003Cp>PMBOK описывает жизненный цикл через пять групп процессов. Это не жёсткие временны́е отрезки, а логические блоки работы, которые могут перекрываться.\u003C\u002Fp>\u003Cfigure class=\"shtab-visual\">\u003Cimg src=\"https:\u002F\u002Fshtab.app\u002Fblog\u002Fcontent\u002Fimages\u002F2026\u002F09\u002Fcover-89.jpg\" alt=\"Пять групп процессов PMBOK: логика переходов и gate-вопросы\" loading=\"lazy\" decoding=\"async\">\u003Cfigcaption>Пять групп процессов PMBOK: логика переходов и gate-вопросы\u003C\u002Ffigcaption>\u003C\u002Ffigure>\u003Cul>\u003Cli>\u003Cstrong>Инициация.\u003C\u002Fstrong> Формируется устав проекта, определяются цели и ограничения, идентифицируются стейкхолдеры. Gate-вопрос: «Есть ли достаточное обоснование, чтобы вкладывать ресурсы?» Артефакты: \u003Ca href=\"\u002Fglossary\u002Fproject-charter\u002F\" data-term-slug=\"project-charter\">Project Charter\u003C\u002Fa>, реестр стейкхолдеров.\u003C\u002Fli>\u003Cli>\u003Cstrong>Планирование.\u003C\u002Fstrong> Разрабатывается план управления проектом: \u003Ca href=\"\u002Fglossary\u002Fscope\u002F\" data-term-slug=\"scope\">scope\u003C\u002Fa>, расписание, бюджет, риски, коммуникации. Gate-вопрос: «Понятно ли, что, кто, когда и за сколько сделает?» Артефакты: WBS, расписание, бюджет, \u003Ca href=\"\u002Fglossary\u002Frisk-register\u002F\" data-term-slug=\"risk-register\">реестр рисков\u003C\u002Fa>.\u003C\u002Fli>\u003Cli>\u003Cstrong>Исполнение.\u003C\u002Fstrong> Команда выполняет работы согласно плану, параллельно идут управление качеством, коммуникациями и закупками. Gate-вопрос на выходе: «Deliverables соответствуют критериям приёмки?»\u003C\u002Fli>\u003Cli>\u003Cstrong>Мониторинг и контроль.\u003C\u002Fstrong> Сквозной процесс: сравнение фактического прогресса с планом, управление изменениями, контроль рисков. Не отдельная фаза во времени, а постоянная деятельность на протяжении всего проекта.\u003C\u002Fli>\u003Cli>\u003Cstrong>Закрытие.\u003C\u002Fstrong> Формальная приёмка результатов, закрытие контрактов, архивирование документации, проведение \u003Ca href=\"\u002Fglossary\u002Flessons-learned\u002F\" data-term-slug=\"lessons-learned\">lessons learned\u003C\u002Fa>. Gate-вопрос: «Все обязательства выполнены, знания зафиксированы?» Эту фазу чаще всего игнорируют — и теряют накопленный опыт.\u003C\u002Fli>\u003C\u002Ful>\u003Ch2>Предиктивный, итеративный, адаптивный и гибридный циклы\u003C\u002Fh2>\u003Cp>Жизненный цикл — не синоним водопада. PMBOK 7 и современная практика выделяют четыре типа, и выбор зависит от уровня неопределённости проекта.\u003C\u002Fp>\u003Cfigure class=\"shtab-visual\">\u003Cimg src=\"https:\u002F\u002Fshtab.app\u002Fblog\u002Fcontent\u002Fimages\u002F2026\u002F09\u002Fcover-90.jpg\" alt=\"Четыре типа жизненного цикла: когда и что выбирать\" loading=\"lazy\" decoding=\"async\">\u003Cfigcaption>Четыре типа жизненного цикла: когда и что выбирать\u003C\u002Ffigcaption>\u003C\u002Ffigure>\u003Cul>\u003Cli>\u003Cstrong>Предиктивный (Waterfall).\u003C\u002Fstrong> Scope, сроки и бюджет определяются в начале и остаются стабильными. Подходит, когда требования ясны и изменения дорогостоящи: строительство, производство, регуляторные проекты. Риск: любое изменение требований ломает план.\u003C\u002Fli>\u003Cli>\u003Cstrong>Итеративный.\u003C\u002Fstrong> Scope уточняется итерациями, каждая из которых добавляет детализацию. Используется, когда понятна общая цель, но детали выясняются в процессе. Пример: прототипирование продукта или архитектурное проектирование.\u003C\u002Fli>\u003Cli>\u003Cstrong>Адаптивный (\u003Ca href=\"\u002Fglossary\u002Fagile\u002F\" data-term-slug=\"agile\">Agile\u003C\u002Fa>).\u003C\u002Fstrong> Scope гибкий, команда работает короткими спринтами, приоритеты пересматриваются регулярно. Подходит при высокой неопределённости и быстро меняющихся требованиях: разработка ПО, продуктовые проекты.\u003C\u002Fli>\u003Cli>\u003Cstrong>Гибридный.\u003C\u002Fstrong> Комбинация предиктивного и адаптивного подходов. Например: фазы инициации и закрытия — предиктивные, исполнение — итеративное. Всё чаще используется в крупных инфраструктурных и цифровых проектах.\u003C\u002Fli>\u003C\u002Ful>\u003Cp>Практическое правило: чем выше неопределённость требований и чем дороже ошибка — тем больше оснований для адаптивного или гибридного цикла. Чем стабильнее scope и регуляторная среда — тем оправданнее предиктивный.\u003C\u002Fp>\u003Ch2>Жизненный цикл проекта vs. жизненный цикл продукта\u003C\u002Fh2>\u003Cp>\u003Cstrong>Проект конечен:\u003C\u002Fstrong> он создаёт уникальный результат и завершается. Жизненный цикл проекта охватывает период от инициации до закрытия и передачи результата.\u003C\u002Fp>\u003Cp>\u003Cstrong>Продукт живёт дальше:\u003C\u002Fstrong> после того как проект закрыт, продукт входит в стадию эксплуатации, развития, зрелости и в конечном счёте — вывода из обращения. Жизненный цикл продукта может включать несколько проектов: запуск, редизайн, масштабирование.\u003C\u002Fp>\u003Cp>Типичная ошибка: команда закрывает проект по всем формальным признакам, но никто не подхватывает эксплуатацию результата. Продукт или система запущены, но нет владельца, нет бюджета на поддержку, нет процесса сбора обратной связи. Выгода от проекта не извлекается, потому что переход между циклами не был спланирован.\u003C\u002Fp>\u003Cp>Чтобы этого избежать, в фазе инициации нужно явно ответить на вопрос: кто и как будет управлять результатом после закрытия проекта?\u003C\u002Fp>\u003Ch2>Типичные ошибки и как их избежать\u003C\u002Fh2>\u003Cp>Формальное наличие фаз не защищает от провала. Наиболее распространённые управленческие ошибки:\u003C\u002Fp>\u003Cul>\u003Cli>\u003Cstrong>Пропуск инициации.\u003C\u002Fstrong> Команда сразу переходит к планированию, не зафиксировав цели, ограничения и стейкхолдеров. В итоге план строится на непроверенных допущениях.\u003C\u002Fli>\u003Cli>\u003Cstrong>Отсутствие gate-критериев.\u003C\u002Fstrong> Фазы есть, но переход между ними происходит по календарю, а не по факту готовности артефактов. Проблемы из предыдущей фазы переносятся в следующую и накапливаются.\u003C\u002Fli>\u003Cli>\u003Cstrong>Мониторинг как разовое мероприятие.\u003C\u002Fstrong> Контроль воспринимается как отдельная фаза, а не сквозной процесс. Отклонения обнаруживаются слишком поздно, когда корректировка уже дорогостоящая.\u003C\u002Fli>\u003Cli>\u003Cstrong>Игнорирование фазы закрытия.\u003C\u002Fstrong> Команда переходит на новый проект, не проведя lessons learned и не закрыв контракты. Накопленный опыт теряется, ошибки повторяются.\u003C\u002Fli>\u003Cli>\u003Cstrong>Разрыв между проектом и продуктом.\u003C\u002Fstrong> Проект закрыт, но ответственный за эксплуатацию результата не назначен. Инвестиции не окупаются.\u003C\u002Fli>\u003C\u002Ful>","\u003Cul>\u003Cli>Проект имеет чёткую дату начала и конца, уникальный результат и выделенный бюджет.\u003C\u002Fli>\u003Cli>Команда работает над задачей впервые или в условиях высокой неопределённости — нужна структура для принятия решений на переходах.\u003C\u002Fli>\u003Cli>Несколько стейкхолдеров с разными интересами: жизненный цикл фиксирует точки согласования и снижает конфликты.\u003C\u002Fli>\u003Cli>Проект длится дольше одного месяца и включает более одной команды или подрядчика.\u003C\u002Fli>\u003Cli>Необходим аудит или отчётность: жизненный цикл создаёт документальный след по каждой фазе.\u003C\u002Fli>\u003C\u002Ful>","\u003Cul>\u003Cli>Операционные процессы без конечной даты и уникального результата — повторяющиеся задачи лучше описываются процессными моделями, а не проектным циклом.\u003C\u002Fli>\u003Cli>Задачи длительностью в несколько часов или дней: накладные расходы на gate-процедуры превысят пользу от структуры.\u003C\u002Fli>\u003Cli>Исследовательские активности без заданного результата — там нет смысла в gate-критериях, потому что неизвестно, что именно проверять на переходе.\u003C\u002Fli>\u003Cli>Команда из одного человека с полным контролем над scope и сроками: формальный жизненный цикл добавит бюрократию без управленческой ценности.\u003C\u002Fli>\u003C\u002Ful>","\u003Cp>\u003Cstrong>Кейс 1. Denver International Airport: классический провал gate-контроля\u003C\u002Fstrong>\u003C\u002Fp>\u003Cp>Строительство аэропорта Денвера (1989–1995) — один из наиболее задокументированных примеров нарушения жизненного цикла проекта. Автоматизированная система обработки багажа, ключевой подпроект, была запущена в исполнение до завершения фазы проектирования: требования менялись уже в ходе монтажа. Отсутствие gate-критериев на переходе от планирования к исполнению привело к 16-месячной задержке открытия аэропорта и перерасходу бюджета на $560 млн (итоговая стоимость — $4,8 млрд вместо запланированных $1,7 млрд). Кейс подробно разобран в исследовании Calleam Consulting и многократно цитируется в литературе по управлению проектами как пример того, что формальное наличие фаз без реальных gate-проверок не защищает от провала.\u003C\u002Fp>\u003Cp>\u003Cstrong>Кейс 2. Российское жилищное строительство: сокращение инвестиционно-строительного цикла\u003C\u002Fstrong>\u003C\u002Fp>\u003Cp>По данным отраслевых медиа, средний срок строительства многоквартирного дома в России сократился с 2181 дня в 2019 году до 1228 дней по итогам 2025 года. Ускорение связывают с типизацией проектных решений, цифровизацией согласований и оптимизацией фаз жизненного цикла — в первую очередь за счёт сокращения времени на прохождение административных gate-процедур между стадиями проектирования и строительства.\u003C\u002Fp>","\u003Cp>\u003Cstrong>Совет от Shtab:\u003C\u002Fstrong> Создайте в Shtab проект с иерархией задач, где верхний уровень — фазы жизненного цикла (Инициация → Планирование → Исполнение → Закрытие), а внутри каждой фазы — конкретные deliverables и gate-чеклисты. Назначьте статусы задач как gate-критерии: пока все задачи фазы «Инициация» (устав проекта, реестр стейкхолдеров) не переведены в «Done», не переводите задачи следующей фазы в работу — это дисциплинирует команду и имитирует gate-контроль даже без автоматической блокировки.\u003C\u002Fp>","жизненный цикл проекта, цикл проекта, фазы проекта, этапы проекта, project life cycle","Project Life Cycle","Жизненный цикл проекта: фазы, gate-критерии и типы","Что такое жизненный цикл проекта: 5 фаз по PMBOK, gate-критерии переходов, выбор между предиктивным и адаптивным циклом, отличие от жизненного цикла продукта.",{"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,105,113,120],{"id":61,"slug":93,"kind":93,"hex":94,"order":61,"translations":95},"methodology","#5e79ec",{"ru":96},{"title":97},"Методология",{"id":6,"slug":99,"kind":100,"hex":101,"order":6,"translations":102},"concept","other","#4b5370",{"ru":103},{"title":104},"Концепция",{"id":106,"slug":107,"kind":108,"hex":94,"order":109,"translations":110},11,"planning","phase",12,{"ru":111},{"title":112},"Планирование",{"id":109,"slug":114,"kind":115,"hex":86,"order":116,"translations":117},"pmbok","framework",20,{"ru":118},{"title":119},"PMBOK",{"id":28,"slug":108,"kind":108,"hex":121,"order":57,"translations":122},"#888ca0",{"ru":123},{"title":124},"Этап","Ж",[127,134,140,146,152],{"id":128,"order":129,"translations":130},2033,0,{"ru":131},{"question":132,"answer":133},"Сколько фаз в жизненном цикле проекта?","\u003Cp>PMBOK выделяет пять групп процессов: инициация, планирование, исполнение, мониторинг и контроль, закрытие. В российской практике и ряде других методологий используют четырёхфазную модель, объединяя мониторинг с исполнением. Количество фаз — не догма: организация может адаптировать модель под свои процессы, главное — сохранить gate-критерии на переходах.\u003C\u002Fp>",{"id":135,"order":61,"translations":136},2034,{"ru":137},{"question":138,"answer":139},"Чем жизненный цикл проекта отличается от жизненного цикла продукта?","\u003Cp>Проект конечен: он создаёт уникальный результат и завершается. Жизненный цикл проекта охватывает период от инициации до закрытия. Продукт живёт дальше — через стадии эксплуатации, развития, зрелости и вывода из обращения. Один продукт может порождать несколько последовательных проектов: запуск, редизайн, масштабирование.\u003C\u002Fp>",{"id":141,"order":21,"translations":142},2035,{"ru":143},{"question":144,"answer":145},"Какой жизненный цикл выбрать: предиктивный или адаптивный?","\u003Cp>Выбор определяется уровнем неопределённости требований. Если scope стабилен, изменения дорогостоящи и есть регуляторные ограничения — предиктивный цикл. Если требования меняются, клиент не может сформулировать их заранее, а стоимость ошибки невысока — адаптивный. В большинстве реальных проектов оптимален гибридный подход: предиктивные фазы инициации и закрытия, итеративное исполнение.\u003C\u002Fp>",{"id":147,"order":51,"translations":148},2036,{"ru":149},{"question":150,"answer":151},"Входит ли мониторинг и контроль в отдельную фазу или это сквозной процесс?","\u003Cp>По PMBOK — сквозной процесс: мониторинг и контроль идут параллельно всем остальным фазам с момента запуска проекта до его закрытия. Выделять мониторинг в отдельный временной отрезок — методологическая ошибка, которая приводит к тому, что отклонения обнаруживаются слишком поздно для эффективной корректировки.\u003C\u002Fp>",{"id":153,"order":39,"translations":154},2037,{"ru":155},{"question":156,"answer":157},"Как жизненный цикл проекта связан с методологиями Scrum, Kanban и Waterfall?","\u003Cp>Waterfall — реализация предиктивного жизненного цикла: фазы идут строго последовательно, переход возможен только после завершения предыдущей. Scrum реализует адаптивный цикл: внутри каждого спринта есть мини-версия полного цикла (планирование → исполнение → ревью → ретроспектива). Kanban не привязан к фазам жизненного цикла — это инструмент управления потоком задач, который может применяться внутри любой фазы.\u003C\u002Fp>",{"parent":159,"related":166,"child":240},[160],{"id":161,"slug":114,"translations":162},49,{"ru":163},{"title":164,"short_definition":165},"PMBOK (свод знаний по управлению проектами)","Свод знаний по управлению проектами от PMI — базовый стандарт классического проектного управления.",[167,174,181,188,195,202,208,214,220,226,233],{"id":168,"slug":169,"translations":170},60,"scope",{"ru":171},{"title":172,"short_definition":173},"Scope (объём проекта)","Совокупность работ, которые нужно выполнить для получения продукта проекта с заданными характеристиками.",{"id":175,"slug":176,"translations":177},63,"milestone",{"ru":178},{"title":179,"short_definition":180},"Milestone (Контрольная точка)","Значимое событие в проекте — обычно завершение этапа или достижение ключевого результата.",{"id":182,"slug":183,"translations":184},55,"critical-path",{"ru":185},{"title":186,"short_definition":187},"Критический путь","Самая длинная цепочка зависимых задач в проекте, определяющая минимально возможную длительность проекта.",{"id":189,"slug":190,"translations":191},52,"wbs",{"ru":192},{"title":193,"short_definition":194},"WBS (иерархическая структура работ)","Иерархическая декомпозиция работ проекта на управляемые пакеты сверху вниз.",{"id":196,"slug":197,"translations":198},69,"triple-constraint",{"ru":199},{"title":200,"short_definition":201},"Triple Constraint (Тройственное ограничение)","Базовая модель управления проектом: объём работ, сроки и бюджет связаны так, что улучшить все три сразу невозможно.",{"id":61,"slug":203,"translations":204},"agile",{"ru":205},{"title":206,"short_definition":207},"Agile","Семейство гибких подходов к разработке продуктов и управлению проектами, основанное на коротких итерациях и быстрой адаптации к изменениям.",{"id":21,"slug":209,"translations":210},"scrum",{"ru":211},{"title":212,"short_definition":213},"Scrum","Гибкий фреймворк разработки продуктов короткими итерациями — спринтами — с фиксированными ролями, артефактами и встречами.",{"id":51,"slug":215,"translations":216},"kanban",{"ru":217},{"title":218,"short_definition":219},"Kanban (Agile)","Метод управления потоком задач с визуализацией на доске и ограничением количества одновременно выполняемых задач (WIP).",{"id":221,"slug":222,"translations":223},54,"gantt",{"ru":224},{"title":58,"short_definition":225},"Графическое представление календарного плана проекта с задачами в виде горизонтальных полос на временной оси.",{"id":227,"slug":228,"translations":229},64,"deliverable",{"ru":230},{"title":231,"short_definition":232},"Deliverable (поставляемый результат)","Конкретный материальный или цифровой результат, который должен быть произведён в рамках проекта.",{"id":234,"slug":235,"translations":236},101,"roadmap",{"ru":237},{"title":238,"short_definition":239},"Roadmap (Дорожная карта)","Стратегический документ, показывающий направление развития продукта или проекта на 3–12 и более месяцев вперёд.",[241,248,255,262,269,276,283,290],{"id":242,"slug":243,"translations":244},62,"project-charter",{"ru":245},{"title":246,"short_definition":247},"Project Charter (Устав проекта)","Документ, формально запускающий проект: цели, объём работ, бюджет, сроки, ключевые роли и заинтересованные стороны.",{"id":249,"slug":250,"translations":251},78,"quality-gate",{"ru":252},{"title":253,"short_definition":254},"Quality Gate (контрольная точка проекта)","Контрольная точка между фазами проекта, на которой проверяется соответствие критериям перед переходом дальше.",{"id":256,"slug":257,"translations":258},67,"lessons-learned",{"ru":259},{"title":260,"short_definition":261},"Lessons Learned (извлечённые уроки)","Документирование уроков, извлечённых из проекта — что сработало, что нет, что улучшить в следующих.",{"id":263,"slug":264,"translations":265},66,"kickoff",{"ru":266},{"title":267,"short_definition":268},"Kickoff Meeting (стартовая встреча проекта)","Стартовая встреча проекта: знакомство команды, презентация целей, согласование принципов работы.",{"id":270,"slug":271,"translations":272},408,"project-initiation",{"ru":273},{"title":274,"short_definition":275},"Инициация проекта","Первая фаза жизненного цикла проекта: идея превращается в формально одобренный замысел с зафиксированными целями, границами, ролями и ресурсами.",{"id":277,"slug":278,"translations":279},413,"waterfall-vs-agile",{"ru":280},{"title":281,"short_definition":282},"Чем Waterfall отличается от Agile","Waterfall строит проект как цепочку фиксированных фаз; Agile — как серию коротких итераций с поставкой ценности в каждой.",{"id":284,"slug":285,"translations":286},415,"waterfall-model",{"ru":287},{"title":288,"short_definition":289},"Каскадная модель (Waterfall)","Каскадная модель — линейный подход к разработке, где каждая фаза (требования, дизайн, реализация, тестирование, внедрение, поддержка) стартует только после формального закрытия предыдущей.",{"id":291,"slug":292,"translations":293},416,"waterfall",{"ru":294},{"title":288,"short_definition":289},"2026-09-01T15:56:07.896754+03:00","2026-09-01T15:56:07.896773+03:00","2026-09-01T15:56:08.106334+03:00",[299,321,348],{"id":300,"slug":301,"translations":302,"category":307,"tags":310,"letter":319,"cover":17,"updated_at":320,"published_at":17},65,"baseline",{"ru":303},{"title":304,"short_definition":305,"translation_en":306},"Baseline (базовый план)","Утверждённая версия плана проекта по содержанию, срокам и бюджету — точка отсчёта для контроля отклонений и изменений.","Baseline",{"id":51,"slug":85,"hex":86,"icon":17,"order":51,"translations":308},{"ru":309},{"title":89,"description":90},[311,316],{"id":39,"slug":312,"kind":100,"hex":121,"order":39,"translations":313},"artifact",{"ru":314},{"title":315},"Артефакт",{"id":6,"slug":99,"kind":100,"hex":101,"order":6,"translations":317},{"ru":318},{"title":104},"B","2026-04-25T22:42:17.413625+03:00",{"id":322,"slug":323,"translations":324,"category":329,"tags":332,"letter":346,"cover":17,"updated_at":347,"published_at":17},61,"change-request",{"ru":325},{"title":326,"short_definition":327,"translation_en":328},"Change Request (Запрос на изменение)","Формальный документ, которым запрашивают изменение объёма работ, сроков, бюджета или других параметров проекта.","Change Request (CR)",{"id":51,"slug":85,"hex":86,"icon":17,"order":51,"translations":330},{"ru":331},{"title":89,"description":90},[333,336,339],{"id":39,"slug":312,"kind":100,"hex":121,"order":39,"translations":334},{"ru":335},{"title":315},{"id":6,"slug":99,"kind":100,"hex":101,"order":6,"translations":337},{"ru":338},{"title":104},{"id":340,"slug":341,"kind":108,"hex":101,"order":342,"translations":343},14,"process",22,{"ru":344},{"title":345},"Процесс","C","2026-04-25T22:42:17.323214+03:00",{"id":349,"slug":350,"translations":351,"category":356,"tags":359,"letter":346,"cover":17,"updated_at":370,"published_at":17},72,"contingency-plan",{"ru":352},{"title":353,"short_definition":354,"translation_en":355},"Contingency Plan (план реагирования на риск)","План действий на случай, если риск всё-таки наступит: что именно делает команда, чтобы снизить ущерб.","Contingency Plan",{"id":51,"slug":85,"hex":86,"icon":17,"order":51,"translations":357},{"ru":358},{"title":89,"description":90},[360,363],{"id":6,"slug":99,"kind":100,"hex":101,"order":6,"translations":361},{"ru":362},{"title":104},{"id":364,"slug":365,"kind":100,"hex":366,"order":45,"translations":367},16,"risk","#ff6a6a",{"ru":368},{"title":369},"Риски","2026-04-25T22:42:17.574403+03:00"]