Предсказуемость в обмен на гибкость
Каскадная модель делит проект на последовательные фазы: обследование, проектирование, реализация, испытания, ввод в эксплуатацию. Каждая заканчивается результатом, который принимает заказчик, и только после приёмки начинается следующая. Эта строгость и есть предмет сделки: заказчик получает предсказуемость по сроку и бюджету, а команда — зафиксированное содержание.
Выбирают каскад обычно не по идеологическим причинам, а по внешним обязательствам. Договор с фиксированной ценой, техническое задание как приложение, конкурсные процедуры, требования регулятора, этапная оплата — во всех этих случаях содержание проекта уже зафиксировано документом, и делать вид, что оно будет уточняться по ходу, бессмысленно.
Известная слабость модели тоже связана с этой строгостью: ошибка в требованиях обнаруживается на приёмке, когда исправление стоит дороже всего. Отсюда основной способ смягчения — не отказ от каскада, а сокращение расстояния между решением и проверкой: промежуточные демонстрации, прототипы, разбивка на более короткие этапы с самостоятельной ценностью.
- Содержание, срок и бюджет зафиксированы договором.
- Есть внешняя приёмка по этапам и требования к документации.
- Предметная область устойчива, требования не будут переизобретаться по ходу.
- Стоимость изменения на поздней стадии заведомо высокая — стройка, оборудование, регулируемая среда.
- Требования известны в общих чертах и будут уточняться в процессе.
- Заказчик не может описать результат заранее и узнаёт его, когда видит.
- Рынок или требования меняются быстрее, чем идёт фаза.
- Результат можно поставлять частями и получать пользу от каждой.
Документы и контрольные точки
В каскаде документ — не бюрократия, а способ зафиксировать договорённость, к которой можно вернуться. Спор о содержании, не подкреплённый документом, в этой модели неразрешим.
Содержание работ
Что входит в проект и, не менее важно, что не входит. Раздел об исключениях экономит больше всего времени на приёмке.
Иерархическая структура работ
Разбиение результата на управляемые пакеты работ. Основа для оценки, календарного плана и распределения ответственности.
Базовый план
Утверждённые сроки, бюджет и содержание, относительно которых меряется отклонение. Меняется только через процедуру изменений.
| СОБЫТИЕ | ДЛИТЕЛЬНОСТЬ | УЧАСТНИКИ | РЕЗУЛЬТАТ |
|---|---|---|---|
| Приёмка фазы | 1–3 дня | команда и заказчик | подписанный результат этапа или список замечаний |
| Еженедельный статус | 30–60 мин | руководитель проекта и команда | отклонения по срокам и решения по ним |
| Совет по изменениям | по мере поступления | заказчик и руководитель проекта | решение об изменении содержания, срока или бюджета |
| Разбор по завершении | 2–3 ч | все участники | извлечённые уроки для следующих проектов |
Как запустить проект по каскаду
Основная работа делается до начала реализации. Ошибка, допущенная в содержании и плане, дальше только дорожает — в отличие от гибких подходов, где её можно исправить в следующем цикле.
- 1Зафиксируйте содержание и исключенияЧто входит в проект и что не входит. Раздел об исключениях важнее списка работ: именно вокруг него возникают споры на приёмке.до старта
- 2Разбейте результат на пакеты работДекомпозиция до уровня, на котором пакет можно оценить и назначить ответственного. Ориентир: от нескольких дней до пары недель.2–5 дней
- 3Постройте календарный план с зависимостямиНе список дат, а сеть: что от чего зависит. Только после этого видно, какие работы определяют общий срок.2–3 дня
- 4Определите вехи и критерии приёмкиВеха — контрольная точка с проверяемым результатом, а не «середина этапа». К каждой — критерии, по которым результат принимается.1 день
- 5Заложите резервы явноРезерв времени и бюджета лучше держать отдельной строкой, чем размазывать по оценкам работ: так видно, сколько его осталось.0,5 дня
- 6Опишите процедуру измененийКто подаёт запрос, кто оценивает влияние на срок и бюджет, кто принимает решение. Без этого изменения приходят устно и не учитываются в плане.0,5 дня
Что контролировать по ходу
Типичные ошибки при работе по каскаду
Содержание описано без исключений
План — это список дат без зависимостей
Резерв размазан по оценкам работ
Изменения принимаются устно
Заказчик появляется только на приёмке
Веха без критериев приёмки
Разбор по темам
Как вести каскадный проект в Shtab
Календарный план, зависимости и вехи собираются на диаграмме Ганта, а документы проекта живут рядом с работой, а не в отдельном хранилище.
- 01Диаграмма Ганта показывает фазы, зависимости между работами и вехи — сдвиг одной работы сразу виден на общем сроке.
- 02Пакеты работ — задачи с подзадачами: декомпозиция сохраняется в структуре, а не в отдельном документе.
- 03Оценка трудозатрат и трекер времени дают план-факт по каждому пакету без ручного сведения.
- 04Устав, содержание и критерии приёмки — страницами в том же проекте: их видно всем участникам.
- 05Портфель проектов даёт картину по нескольким проектам сразу — для руководителя проектного офиса.
- 06Запросы на изменение удобно вести отдельным списком со статусами: подан, оценён, принят, отклонён.
Частые вопросы
Нет, это подход с другими условиями применимости. Там, где содержание зафиксировано договором, стоимость поздних изменений высока, а приёмка идёт по этапам, каскад работает лучше гибких методов. Устаревшим он выглядит только когда его применяют там, где требования заведомо будут уточняться.