Как оценивать сроки разработки и почему оценка задачи — ещё не дата завершения

Один из самых частых вопросов к продуктовой команде звучит просто:

Когда будет готово?

Кажется, что для ответа достаточно оценки разработчика.

Если задача занимает пять рабочих дней, значит, она будет готова через пять дней.

На практике почти никогда.

Разработчик может начать только через неделю. До него должен закончить работу аналитик. После него нужен frontend. Затем QA. Один из специалистов уходит в отпуск. Параллельно появляется более приоритетная задача.

В итоге оценка в пять дней легко превращается в календарный срок в три недели.

Проблема не в том, что команда «плохо оценила».

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

Чтобы прогнозировать сроки разработки реалистично, Product Owner должен связывать оценку не только с объёмом работы, но и с очередью ресурсов, зависимостями и текущим состоянием плана.

Что именно мы оцениваем

Под словом «срок» часто смешивают несколько разных понятий.

Например:

• трудоёмкость;
• длительность этапа;
• время ожидания;
• календарное время;
• дедлайн;
• прогноз завершения.

Из-за этого одна и та же фраза воспринимается по-разному.

Разработчик говорит:

«Это примерно пять дней».

Он может иметь в виду:

если я начну эту работу и буду заниматься ей последовательно, потребуется около пяти рабочих дней.

Бизнес слышит:

результат будет через пять календарных дней.

Между этими утверждениями может быть большая разница.

Поэтому первым шагом полезно разделить хотя бы три понятия.

Оценка

Сколько рабочего времени требует задача или этап.

Дата старта

Когда нужный специалист реально сможет начать работу.

Дата завершения

Когда работа закончится с учётом старта, длительности, календаря и зависимостей.

Это простое разделение уже устраняет значительную часть недопонимания.

Почему трудоёмкость не равна календарному сроку

Представим этап backend-разработки с оценкой пять рабочих дней.

Вариант 1:

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

Тогда пять дней действительно близки к календарному прогнозу.

Вариант 2:

• разработчик ещё четыре дня занят;
• аналитика завершится через три дня;
• после backend нужны frontend и QA;
• между работами попадают выходные.

Трудоёмкость backend по-прежнему пять дней.

Но итоговая дата продукта будет совсем другой.

Поэтому формула выглядит не так:

оценка = срок

а скорее:

доступность ресурса + длительность работы + зависимости + календарь = прогноз завершения

Срок проекта нельзя получить простым сложением оценок

Допустим, продуктовая инициатива состоит из четырёх этапов:

• аналитика — 3 дня;
• backend — 7 дней;
• frontend — 5 дней;
• QA — 3 дня.

Простое сложение даёт 18 рабочих дней.

Но это ещё не означает, что проект займёт 18 дней.

Некоторые этапы могут выполняться параллельно.

Другие, наоборот, будут ждать доступного специалиста.

Например, дизайн может идти одновременно с аналитикой, а frontend начнётся только после готового API.

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

Оценка должна быть достаточно хорошей, а не идеальной

Команды часто тратят слишком много времени на попытку получить точную оценку заранее.

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

Поэтому цель оценки — не предсказать будущее до часа.

Цель — получить достаточно хороший масштаб, чтобы построить рабочий план.

Например:

• 1 день;
• 3 дня;
• 5 дней;
• 10 дней.

Для верхнеуровневого планирования этого часто достаточно.

Дальше прогноз можно уточнять.

Гораздо опаснее вообще не иметь оценок и при этом обещать календарные даты.

Какие факторы влияют на точность оценки

Есть несколько основных источников неопределённости.

Неясные требования

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

Техническая неизвестность

Интеграции, новая технология, нестандартная архитектура и плохо изученный код повышают риск.

Внешние зависимости

Документация партнёра, внешний API, подрядчик, согласование.

Качество декомпозиции

Крупная задача оценивается хуже, чем несколько понятных этапов.

Опыт команды

Если команда уже делала похожую работу, диапазон неопределённости меньше.

Изменения во время реализации

Даже хорошая оценка устаревает, если scope изменился.

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

Когда использовать диапазон, а не одну цифру

Если работа сильно неопределённая, одна цифра создаёт ложную точность.

Вместо:

8 дней

может быть полезнее:

6–10 дней.

Или:

оптимистично — 6, вероятно — 8, пессимистично — 12.

Но для календарного планирования всё равно нужно какое-то рабочее значение.

Важно, чтобы команда понимала:

это прогноз, а не гарантия.

По мере выполнения задачи диапазон можно сужать.

Зависимости могут быть важнее самой оценки

Представим, что frontend-этап занимает два дня.

Очень маленькая работа.

Но он зависит от backend, который будет готов только через три недели.

С точки зрения трудоёмкости frontend почти бесплатен.

С точки зрения календаря он завершится далеко не через два дня.

Поэтому при оценке сроков проекта важно видеть:

• что должно произойти раньше;
• какие этапы идут последовательно;
• что можно делать параллельно;
• где есть внешний блокер.

Без этого даже качественные оценки не складываются в реалистичный прогноз.

Очередь ресурсов — главный скрытый фактор

Пусть есть три проекта.

Каждому нужен один и тот же backend-разработчик.

Оценки:

• проект A — 5 дней;
• проект B — 4 дня;
• проект C — 7 дней.

Если смотреть на проекты отдельно, каждый кажется коротким.

Но общий ресурс один.

Значит, календарь будет выглядеть как очередь.

Если порядок A → B → C, то C начнётся только после первых девяти дней работы backend.

Поэтому дата завершения C зависит не только от собственной оценки, но и от всей работы, которая стоит перед ним.

Именно здесь срок отдельной задачи начинает зависеть от портфеля в целом.

Приоритет напрямую влияет на сроки

Если порядок проектов меняется, меняется и календарь.

Было:

1. A
2. B
3. C

Стало:

1. C
2. A
3. B

Трудоёмкость ни одной задачи не изменилась.

Но даты завершения изменились у всех трёх.

Это важный вывод:

срок — функция не только оценки, но и приоритета.

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

Текущая работа тоже входит в расчёт

Новый проект никогда не стартует в пустой системе.

Команда уже чем-то занята.

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

Это особенно важно при квартальном планировании.

Команда входит в новый квартал не с нулевой загрузкой, а с хвостом предыдущего.

Игнорирование этой работы почти гарантирует слишком оптимистичный прогноз.

Как учитывать отсутствия

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

Например:

• работа занимает 5 дней;
• сотрудник может начать в понедельник;
• в среду уходит в отпуск на неделю.

Формально оценка не изменилась.

Но дата завершения изменилась существенно.

Для одного этапа это просто.

Для нескольких зависимых проектов эффект может распространяться дальше по цепочке.

Поэтому рабочий календарь и отсутствия должны быть частью модели планирования.

Дедлайн и прогноз — не одно и то же

Ещё одна типичная путаница.

Дедлайн

Дата, к которой результат нужен бизнесу.

Прогноз

Дата, когда текущий план ожидает результат.

Эти даты могут совпадать.

Но могут и расходиться.

Например:

Дедлайн — 30 ноября. Текущий прогноз — 12 декабря.

Это не ошибка интерфейса.

Это важный управленческий сигнал.

Теперь Product Owner должен решить:

• уменьшать объём;
• повышать приоритет;
• добавлять ресурс;
• менять зависимость;
• пересматривать обязательство.

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

Как оценивать сроки разработки на практике

Полезный процесс выглядит так.

Шаг 1. Разбейте инициативу на этапы

Не пытайтесь оценить большой проект одной цифрой.

Например:

• аналитика;
• дизайн;
• backend;
• frontend;
• QA;
• запуск.

Шаг 2. Получите оценки длительности

Пусть исполнители оценят свои этапы в понятной единице.

Для календарного плана удобно использовать рабочие дни.

Шаг 3. Зафиксируйте зависимости

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

Шаг 4. Назначьте ресурсы

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

Шаг 5. Учтите текущую загрузку

Посмотрите, когда специалист реально освободится.

Шаг 6. Учтите приоритет

Если за ресурс конкурируют несколько инициатив, порядок должен быть определён.

Шаг 7. Добавьте календарь и отсутствия

Рабочие и нерабочие дни должны влиять на расчёт.

Шаг 8. Получите прогноз

Теперь можно рассчитать:

• дату старта;
• дату завершения;
• ожидание ресурса;
• критические зависимости.

Это и есть реальный срок в текущих условиях.

Что делать, если оценка изменилась

Изменение оценки — нормальная ситуация.

Например, backend был оценён в пять дней.

После двух дней работы выяснилось, что понадобится ещё шесть.

Вместо попытки сохранить старую дату любой ценой полезнее обновить прогноз.

Дальше нужно посмотреть:

• какие последующие этапы сдвигаются;
• затрагиваются ли другие проекты;
• изменяется ли квартальный план;
• нужно ли пересмотреть приоритет.

Главное — не скрывать изменение исходных данных.

Что делать, если появился срочный проект

Предположим, новый проект получает высший приоритет.

Его оценка — семь дней backend.

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

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

1. добавить новую работу;
2. назначить приоритет;
3. пересчитать очередь ресурсов;
4. получить новые даты;
5. оценить последствия;
6. принять решение.

Не стоит делать наоборот:

пообещать срочный проект «через неделю», а затем выяснять, что будет со всем остальным.

История прогноза важнее первоначальной точности

Даже очень хороший план меняется.

Поэтому полезно хранить версии.

Например:

1 октября

Прогноз завершения — 20 ноября.

12 октября

Backend-оценка увеличена на 4 дня. Новый прогноз — 26 ноября.

21 октября

Добавлена срочная инициатива выше по приоритету. Новый прогноз — 5 декабря.

Такая история помогает отвечать на вопрос:

почему дата изменилась?

Это намного полезнее, чем просто видеть текущий срок.

Как понять, что прогнозу можно доверять

Никакой план не гарантирует будущее.

Но прогноз становится значительно полезнее, если:

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

То есть доверие к сроку появляется не из-за красивой даты, а из-за понятной модели, которая к ней привела.

Какие ошибки чаще всего портят сроки

«Разработчик сказал пять дней — значит обещаем пятницу»

Оценка работы превращается в обязательство без проверки календаря.

Планирование каждого проекта отдельно

Конфликт за общих специалистов становится невидимым.

Игнорирование текущей загрузки

Будущие задачи планируются с сегодняшнего дня, хотя ресурс ещё занят.

Слишком крупные оценки

Проект «на два месяца» трудно использовать для управления.

Ложная точность

Дата через полгода до дня создаёт больше уверенности, чем реально существует.

Отсутствие перепланирования

Условия изменились, а срок остался старым.

Замена прогноза дедлайном

Система показывает желаемое вместо вероятного.

Как разговаривать о сроках с бизнесом

Полезно разделять три формулировки.

«Команда оценивает работу в 10 дней»

Это трудоёмкость.

«По текущему плану мы сможем начать 15 ноября»

Это доступность ресурса.

«Текущий прогноз завершения — 29 ноября»

Это календарный результат.

Так разговор становится гораздо точнее.

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

что нужно изменить в плане, чтобы приблизить прогноз к дедлайну?

Это уже намного продуктивнее разговора:

разработчики опять ошиблись со сроком.

Где здесь KORDO

KORDO использует оценки как один из входов в планирование, но не подменяет ими календарные даты.

Этап получает оценку длительности, исполнителя и зависимости.

Дальше его место в календаре зависит от:

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

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

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

Это особенно важно для нескольких проектов, использующих одну команду.

Главное

Оценка срока разработки начинается с правильного вопроса.

Не:

«Сколько дней занимает эта задача?»

А:

«Сколько работы она требует, когда нужный ресурс сможет её начать и что должно произойти до этого?»

Трудоёмкость — только одна часть прогноза.

Реальный срок складывается из:

оценки → зависимостей → доступности ресурсов → приоритетов → календаря → текущей очереди работ.

Поэтому задача на пять дней может закончиться через пять дней.

А может — через три недели.

Оба варианта могут быть следствием одной и той же качественной оценки.

Разница в том, есть ли вокруг неё реалистичный план.