Как оценить сроки проекта и не сорвать дедлайн

Начнём

— Сколько времени займёт?

— Думаю, дня три.

Знакомо?

Через три дня готово процентов 70. Потом выясняется, что API работает немного не так, как было в документации. Заказчик вспоминает про мобильную версию. Авторизация внезапно требует ещё пару состояний. А перед самым релизом находится Safari.

Три дня превращаются в неделю.

И проблема здесь не обязательно в том, что разработчик плохо работает. Чаще он плохо оценивает неизвестность.

Разберёмся, как реалистично оценивать сроки проекта, что закладывать в оценку и почему собственная статистика полезнее любых формул.

Почему мы постоянно ошибаемся в сроках

Когда нас спрашивают:

Сколько займёт эта задача?

Мозг обычно оценивает идеальный сценарий.

Сверстать страницу — 6 часов.

Подключить API — 4 часа.

Добавить форму — 2 часа.

Получается примерно 12 часов. Полтора рабочих дня.

Красота.

Только в эти 12 часов обычно не попадают:

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

В итоге мы оцениваем чистое выполнение задачи, а клиент получает срок готового результата. Это разные цифры.

Не оценивайте проект целиком

Представьте задачу "Сделать личный кабинет пользователя".

Сколько времени нужно? Неделя? Две? Месяц?

На такой вопрос практически невозможно нормально ответить.

Потому что «личный кабинет» — это не задача.

Разбиваем:

Теперь это уже можно обсуждать.

Хорошее правило:

Если задачу сложно оценить — скорее всего, она недостаточно декомпозирована.

Чем меньше кусок работы, тем меньше вероятность ошибиться в его оценке.

Диапазон лучше одной цифры

Если вы говорите:

Сделаю за 12 часов.

12 превращается в обещание.

Даже если это была приблизительная оценка.

Гораздо честнее:

Оценка — 12–16 часов.

Почему?

Потому что разработка — не конвейер.

В одной задаче API подключится за час.

В другой окажется, что документация устарела, тестовый сервер лежит, а поле userId иногда приходит как user_id.

Диапазон показывает, что существует неопределённость.

И чем её больше, тем шире должен быть диапазон.

Добавляйте запас. Но не «накину сверху 30% на всякий случай»

Популярный совет:

Посчитал срок — умножь на два.

Иногда работает.

Но это не оценка. Это страховка.

Лучше понимать, где именно находится риск.

Допустим:

Вёрстка — 8 часов.

Интеграция — 6 часов.

Тестирование — 3 часа.

На вёрстке всё понятно. Макеты готовы, компоненты знакомые.

А вот интеграция зависит от нового API, с которым вы раньше не работали.

Логичнее добавить запас именно туда, а не раздувать весь проект.

«Я работаю 8 часов» не значит «у меня есть 8 часов на проект»

Ещё одна классическая ловушка.

Рабочий день — 8 часов.

Значит задача на 24 часа займёт три дня?

Нет.

Кроме основной задачи будут:

• сообщения;
• созвоны;
• код-ревью;
• другие проекты;
• организационные вопросы;
• мелкие срочные задачи.

Особенно это заметно на фрилансе, когда одновременно несколько клиентов.

Из восьми часов рабочего дня на конкретный проект может реально оставаться пять.

Тогда задача на 24 часа — это уже почти пять рабочих дней.

Поэтому важно различать:

трудозатраты — сколько часов непосредственно требуется на работу;

Не забывайте про правки

Есть опасная фраза:

Ну там потом только правочки.

Иногда «правочки» занимают столько же времени, сколько первая версия.

Особенно если результат впервые видит заказчик.

Поэтому лучше заранее предусмотреть время на:

• проверку;
• исправление найденных ошибок;
• обратную связь;
• финальную полировку.

Если после завершения разработки вы сразу ставите дедлайн — любое изменение превращается в опоздание.

Самый точный способ оценки — ваши прошлые проекты

Можно изучить Planning Poker, PERT, Story Points и десяток других методик.

Они полезны.

Но есть источник данных значительно ближе к реальности:

вы сами.

Допустим, вы думаете, что обычный лендинг занимает у вас 20 часов.

Открываете историю проектов:

• первый — 31 час;
• второй — 27;
• третий — 34;
• четвёртый — 29.

Похоже, ваша реальная оценка — вовсе не 20.

Или другой пример.

Вы постоянно оцениваете интеграцию API в 8 часов, а фактически тратите 12–15.

Через несколько проектов это уже не случайность.

Это данные.

И именно здесь учёт времени перестаёт быть историей про «запустить таймер».

Он становится инструментом оценки будущих проектов.

Итог: Простая схема оценки проекта

Перед тем как назвать срок:

1. Разбейте проект на небольшие задачи.

Не «сделать интернет-магазин», а конкретные части системы.

2. Оцените трудозатраты каждой задачи.

Лучше диапазоном.

3. Найдите неизвестные.

Новые технологии, API, зависимости, legacy.

4. Добавьте время на тестирование и правки.

Они тоже являются работой.

5. Посчитайте реальную доступность.

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

6. Учтите внешние зависимости.

Дизайн, backend, заказчик, тестирование, согласования.

7. Сравните оценку с похожими прошлыми проектами.

Если раньше такая работа занимала 30 часов, странно обещать её за 15 только потому, что сейчас хочется получить заказ.