Почему сроки разработки срываются и как это учитывать
Практика2 минРедакция Innovialabs
Коротко
Оценка — это прогноз в условиях неопределённости, а не обещание, поэтому просите диапазон вместо одной даты, уточняйте допущения, закладывайте буфер и пересматривайте прогноз по мере выполнения работы.
Почему оценки ошибаются
Сроки срываются не обязательно потому, что команда плохо работает. Разработка — это создание того, чего ещё не было, и в начале проекта неизвестного больше всего. Оценка в этот момент — прогноз, а не обещание. Чем лучше вы понимаете источники ошибки, тем спокойнее планируете бизнес вокруг запуска.
Основные причины
- Неполные требования. «Личный кабинет» в голове заказчика и разработчика может означать очень разный объём работы.
- Забытые задачи. Оценивают видимые функции, но забывают про тестирование, развёртывание, исправление ошибок, админку, письма и уведомления.
- Интеграции. Внешние сервисы ведут себя не так, как описано, а доступы к ним выдают с задержкой.
- Изменения по ходу. Каждая «маленькая правка» добавляет работу, и вместе они заметно сдвигают срок.
- Оптимизм. Люди склонны оценивать задачу так, будто всё пойдёт по плану.
- Ожидание решений. Неделя без ответа заказчика — это неделя к сроку.
- Давление на цифру. Если от команды ждут конкретной даты, она называет желаемую, а не реалистичную.
Диапазон вместо одной цифры
Одна дата создаёт ложную точность. Диапазон честнее показывает неопределённость.
| Формат оценки | Что он сообщает |
|---|---|
| «Сделаем к 1 марта» | Ничего о рисках и допущениях |
| «От 8 до 12 недель» | Есть неопределённость, и известны её границы |
| «8–12 недель, если API банка доступен в первую неделю» | Диапазон плюс ключевое допущение |
Чем раньше проект, тем шире диапазон. По мере работы он должен сужаться. Если через месяц он такой же широкий, стоит разобраться почему.
Как закладывать буфер
- Добавляйте запас на весь проект, а не на каждую задачу отдельно: в отдельных задачах буфер обычно «съедается» незаметно.
- Больше запаса — для частей с высокой неопределённостью: интеграции, новые технологии, нечёткие требования.
- Не привязывайте жёсткие бизнес-события (рекламу, публичный анонс) к оптимистичной границе диапазона.
Как читать оценку подрядчика
Задайте несколько вопросов:
- Какие допущения лежат в основе оценки?
- Включены ли тестирование, развёртывание и исправление ошибок?
- Что считается готовой задачей?
- Какие части самые рискованные?
- Как и когда оценка будет уточняться?
Насторожиться стоит, если оценка подозрительно точная при размытых требованиях или если на вопросы о допущениях нет ответа.
Что делать заказчику
- Делите проект на этапы с демо: так вы видите реальный прогресс, а не проценты в отчёте.
- Определите, что можно сократить без потери смысла, если срок важнее объёма.
- Быстро отвечайте на вопросы команды и согласовывайте материалы.
- Фиксируйте изменения требований и их влияние на срок.