Как вести проект по каскадной модели: фазы, приёмка, изменения

Содержание: раздел об исключениях важнее списка работ

Список работ обычно пишут внимательно. Раздел «что не входит в проект» — почти никогда, и именно вокруг него разворачивается большинство споров на приёмке. Заказчик подразумевал перенос исторических данных, команда — нет; в документе об этом ничего не сказано, и правы формально обе стороны.

Пишите исключения так же тщательно, как включения, и особенно там, где решение неочевидно: миграция данных, обучение пользователей, поддержка после сдачи, интеграции со смежными системами, работы на стороне заказчика. Один абзац на каждом из этих пунктов снимает недели переговоров.

Второй источник споров — критерии приёмки. «Система работает корректно» приёмке не подлежит: корректность каждый понимает по-своему. Критерий должен допускать однозначную проверку: перечень сценариев, предельные значения, состав документации.

Когда содержание задаёт стандарт

В госзаказе и в крупных внедрениях состав работ и документов задаёт не только договор, но и стандарт: ГОСТ 34.601 описывает стадии создания автоматизированной системы, ГОСТ 34.602 — структуру технического задания, ГОСТ 34.603 — виды испытаний. Если в договоре есть ссылка на них, состав документации становится частью предмета договора, и «система работает, но технический проект не оформлен» означает неисполнение.

Практическое следствие: трудоёмкость документирования оценивайте отдельной строкой. Считать её накладными расходами дорого — на проектах по стандарту она сопоставима с трудоёмкостью самой разработки и чаще всего оказывается неучтённой в фиксированной цене.

Второе следствие — стадийность. Перепрыгнуть стадию нельзя: приёмка следующей опирается на утверждённые документы предыдущей. Планируйте сроки согласования этих документов на стороне заказчика как отдельные работы — они длятся неделями и в план обычно не попадают.

Фазы: длина важнее названий

Состав фаз зависит от предметной области, а вот их длина — управленческое решение, и оно важнее. Чем длиннее фаза, тем позже обнаруживается ошибка в требованиях и тем дороже её исправление.

Практическое правило: фаза не должна быть длиннее того срока, за который заказчик готов ждать первого проверяемого результата. Если проект на год делится на две фазы по полгода, первая обратная связь придёт через шесть месяцев работы, и к этому моменту исправление затронет всё сделанное.

Полезный ориентир при нарезке фаз даёт V-модель: у каждого проектного документа есть своя проверка. Техническое задание проверяют приёмочными испытаниями, технический проект — комплексными, рабочую документацию — автономными. Если для фазы не удаётся назвать проверку, которая её закрывает, фаза описана плохо.

У разбивки на короткие этапы с самостоятельной ценностью есть имя — инкрементальный каскад: проект идёт очередями, и каждая очередь проходит все фазы и сдаётся заказчику отдельно. Это самый действенный способ смягчить главную слабость модели, не отказываясь от неё. Формально всё остаётся каскадом: фазы внутри очереди последовательны, приёмка этапная, договор фиксирует содержание.

Базовый план: относительно чего меряем отклонение

Базовый план — утверждённые содержание, сроки и бюджет, зафиксированные на момент старта. Нужен он ровно для одного: чтобы было относительно чего считать отклонение. План, который правят по ходу без процедуры, отклонений не показывает: факт всегда совпадает с «планом».

Отклонение само по себе не проблема — проблема в том, что оно обнаруживается поздно. Поэтому смотрите на запас по критическому пути: сколько дней резерва осталось на работах, которые определяют срок всего проекта. Общий процент выполнения об этом молчит.

Отдельно договоритесь, как считается выполнение пакета работ, — иначе процент будет самооценкой исполнителя. Рабочие правила простые: пакет не начат — ноль, начат — половина, принят — сто процентов; либо только ноль или сто, если пакет короче отчётного периода. Точность здесь не нужна, нужна одинаковость. Вместо «выполнено на 70%» спрашивайте «сколько осталось» — оценка остатка врёт заметно реже.

Резерв держите отдельной строкой. Пока он стоит отдельно, видно и то, сколько его израсходовано; размазанный по оценкам работ, он тратится незаметно, и о его отсутствии узнают в момент, когда он уже нужен.

Изменения: процедура вместо устной договорённости

Изменения в каскадном проекте не запрещены — запрещено принимать их молча. Процедура минимальна: запрос пишут, влияние на срок, бюджет и содержание оценивают, решение принимает уполномоченный, базовый план обновляют. Пропустишь шаг — процедуры нет.

Пропуск любого шага даёт один и тот же результат: работа добавляется, план остаётся прежним, и к концу проекта команда объясняет срыв срока «дополнительными пожеланиями», которых нигде не зафиксировано. Формально в такой ситуации права не команда.

Полезная практика — считать не только каждое изменение по отдельности, но и их накопленный объём. Десять мелких правок по два дня — это месяц, которого нет в плане; по одной они выглядят безобидно и почти всегда принимаются.

Отдельно от изменений ведите невыполненные обязательства заказчика: доступы, данные, помещения, выделенные специалисты, согласования. Каждое из них — работа в плане со сроком и ответственным на стороне заказчика. Как только срок сорван, отправляйте письменное уведомление с указанием, какие работы остановлены и на сколько сдвигается срок: устная договорённость «мы подождём» через полгода превращается в вашу просрочку.

Приёмка: как не превратить её в переговоры

Приёмка проходит по критериям, записанным до начала фазы. Если критериев нет, приёмка превращается в переговоры, где сила аргумента заменяет проверку, а результат зависит от настроения и загруженности принимающего.

Готовьте материалы приёмки заранее: перечень критериев с отметкой о выполнении, результаты проверок, состав переданных документов. С таким пакетом встреча занимает час, без него разбирательство растягивается на дни.

Замечания фиксируйте списком, помечая, какие относятся к критериям приёмки, а какие оказались новыми пожеланиями. Вторые — запросы на изменение: они идут по процедуре, и устранять их «заодно» не нужно.

Испытания и опытная эксплуатация

Во внедрении приёмка редко сводится к одной встрече: между «готово у нас» и «принято» стоят испытания. Обычная последовательность — автономные проверки подсистем, комплексные испытания на стенде, предварительные испытания у заказчика, опытная эксплуатация и приёмочные испытания. Каждый шаг закрывается своим протоколом, и доказательством на приёмке служат именно протоколы; переписка в этой роли не работает.

Программу и методику испытаний пишут заранее, вместе с критериями приёмки, и согласовывают до начала испытаний. Программа, написанная после того, как система готова, всегда описывает то, что получилось, — и заказчик это видит.

Опытная эксплуатация — отдельный этап со своими правилами. Заранее договоритесь о её длительности, о том, кто и как регистрирует замечания, и о делении замечаний на блокирующие, существенные и несущественные: без классификации любая мелочь становится основанием не подписывать акт. Отдельно зафиксируйте, что новые пожелания, возникшие в опытной эксплуатации, идут через процедуру изменений.

Что фиксируется на каждом этапе

Чек-лист перед стартом фазы

Срыв фазы закладывается до её начала. Пройдите список перед каждой фазой: вторая и третья ломаются ровно так же, как первая.

Как это выглядит в Shtab

На приёмке не придётся собирать материалы из почты: устав, критерии и акты лежат в проекте.

Частые вопросы