Предсказуемость в обмен на гибкость
Каскадная модель делит проект на последовательные фазы: обследование, проектирование, реализация, испытания, ввод в эксплуатацию. Каждая заканчивается результатом, который принимает заказчик. Не принял — следующая не начинается. В этой строгости и состоит сделка: заказчик покупает предсказуемый срок и бюджет, команда — гарантию, что содержание не поплывёт.
Выбирают каскад обычно по внешним обязательствам. Договор с фиксированной ценой, техническое задание как приложение, конкурсные процедуры, требования регулятора, этапная оплата — во всех этих случаях содержание проекта уже зафиксировано документом, и делать вид, что оно будет уточняться по ходу, бессмысленно.
Известная слабость модели тоже связана с этой строгостью: ошибка в требованиях обнаруживается на приёмке, когда исправление стоит дороже всего. Смягчают её тем, что сокращают расстояние между решением и проверкой: промежуточные демонстрации, прототипы, разбивка на более короткие этапы с самостоятельной ценностью. Отказываться от каскада для этого не требуется.
- Содержание, срок и бюджет зафиксированы договором.
- Есть внешняя приёмка по этапам и требования к документации.
- Предметная область устойчива, требования не будут переизобретаться по ходу.
- Стоимость изменения на поздней стадии заведомо высокая — стройка, оборудование, регулируемая среда.
- Требования известны в общих чертах и будут уточняться в процессе.
- Заказчик не может описать результат заранее и узнаёт его, когда видит.
- Рынок или требования меняются быстрее, чем идёт фаза.
- Результат можно поставлять частями и получать пользу от каждой.
Документы и контрольные точки
В каскаде документ — не бюрократия, а способ зафиксировать договорённость, к которой можно вернуться. Спор о содержании, не подкреплённый документом, в этой модели неразрешим.
Содержание работ
Что входит в проект и, не менее важно, что не входит. Раздел об исключениях экономит больше всего времени на приёмке.
Иерархическая структура работ
Разбиение результата на управляемые пакеты работ. Основа для оценки, календарного плана и распределения ответственности.
Базовый план
Утверждённые сроки, бюджет и содержание, относительно которых меряется отклонение. Меняется только через процедуру изменений.
| СОБЫТИЕ | ЧАСТОТА И ДЛИТЕЛЬНОСТЬ | УЧАСТНИКИ | ЧЕМ ЗАКАНЧИВАЕТСЯ |
|---|---|---|---|
| Приёмка фазы | 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Запросы на изменение удобно вести отдельным списком со статусами: подан, оценён, принят, отклонён.
Частые вопросы
Нет, это подход с другими условиями применимости. Там, где содержание зафиксировано договором, стоимость поздних изменений высока, а приёмка идёт по этапам, каскад работает лучше гибких методов. Устаревшим он выглядит только когда его применяют там, где требования заведомо будут уточняться.