Управление сроками проекта: как наш проджект перестал их срывать

Почему сроки срываются даже у опытных команд

Почти всегда причина не в лени и не в слабых разработчиках. Проект ломается на планировании и на изменениях, которые никто не учёл. Эти механизмы давно описаны и имеют имена.

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

• оценка делается по лучшему сценарию, без учёта согласований и правок;
• объём растёт по ходу, а срок остаётся прежним;
• задачи зависят друг от друга, и задержка одной сдвигает цепочку;
• заказчик отвечает на вопросы неделями, и это время никто не считает;
• проблемы всплывают на приёмке, когда до финала остаются дни.

Как оценивать задачи точнее

Помогает трёхточечная оценка из метода PERT. Для задачи называют оптимистичный, наиболее вероятный и пессимистичный срок, а итог считают по формуле (О + 4 × В + П) / 6. Цифра получается выше, чем при оценке «как обычно», зато ближе к реальности.

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

Инструменты контроля сроков

Под каждый тип проекта подходит свой набор. В заказной разработке я чаще всего вижу связку из плана-графика и короткого цикла отчётности перед заказчиком.

План-график работ и критический путь

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

Удобно вести такой график в MS Project, GanttPRO или прямо в таблице. Инструмент вторичен. Важно, чтобы график обновляли каждую неделю, а не рисовали один раз для договора.

Один буфер вместо запаса в каждой задаче

Элияху Голдратт в книге «Критическая цепь» (1997) предложил убирать запас из отдельных задач и собирать его в общий буфер в конце проекта. Разработчик оценивает задачу честно, без перестраховки. Задержки на отдельных задачах съедают общий буфер, и по скорости его расхода видно, успевает ли проект.

Еженедельная встреча с заказчиком: что на ней обсуждать

Встреча раз в неделю нужна не для красивого отчёта. Короткая сверка снимает сюрпризы в конце проекта. Хватает 30 минут и постоянной структуры.

• что сделано за неделю и что можно посмотреть руками;
• что в работе на следующей неделе;
• риски и вопросы, по которым нужен ответ заказчика, с датой ответа;
• изменения объёма и как они влияют на срок и бюджет.

Приёмка проекта без превращения в тестирование

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

Чтобы приёмка прошла спокойно, критерии готовности фиксируют заранее, ещё на этапе плана. Внутреннее тестирование заканчивается до показа. На демонстрацию приходят с чек-листом сценариев, по которому заказчик проходит сам.

Типичные ошибки в управлении сроками

Каждая из ошибок ниже по отдельности стоит пары дней. Вместе они дают те самые недели опоздания, после которых заказчик перестаёт верить любым датам. Разбор после каждого этапа, без поиска виноватых, помогает не наступать на них повторно.

• называть срок до декомпозиции, «на глаз»;
• принимать новые задачи без пересмотра даты;
• прятать задержку до последнего вместо того, чтобы сказать о ней сразу;
• считать время разработчиков, но не время на ответы и согласования;
• не обновлять план после старта;
• разбирать сорванный этап только в поисках виноватых, а не причин.