Прогноз сроков: как говорить о неопределённости честно

Команда прикинула задачу и ответила: «Думаем, к концу месяца». Через пару дней эта дата уже стоит в презентации для руководства — без слова «думаем» и без списка неизвестных. Знакомо?

Так предварительная оценка незаметно превращается в обещание. На старте команда могла ещё не знать, что доступ к системе выдаётся две недели, а «простая интеграция» вовсе не такая простая. Хороший прогноз нужен, чтобы эти неизвестные не потерялись по дороге от команды к заказчику.

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

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

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

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

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

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

«Планируем релиз 6 июля. Разработку и проверку рассчитываем закончить к 29 июня, после чего у нас есть неделя буфера на риски интеграции и небольшие задержки. Для этого доступ к внешней системе нужен к началу работ. Если он задержится или появятся новые требования, сразу сообщим, как это влияет на дату релиза».

Такой ответ не гарантирует результат, зато объясняет, на чём основан прогноз и когда появится следующая информация. Дата, названная уверенным голосом, сама по себе этих деталей не добавит.

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

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

Смысл прогноза не в том, чтобы однажды угадать дату и больше к ней не возвращаться. Он помогает принимать решения, пока у команды и заказчика ещё есть выбор.