Почему сумма дней по задачам не равна сроку проекта: считаем зависимости до обещания даты

В смете восемь задач по несколько дней. Заказчик складывает длительности и получает месяц. Подрядчик говорит, что закончит за две недели, потому что часть работ пойдёт параллельно. Затем оказывается, что интеграцию нельзя проверить без доступа, а дизайн ждёт согласования. Спор о сроке начался раньше, чем стороны описали зависимости.
Разделите трудоёмкость и длительность
Двадцать часов работы не обязательно занимают двадцать часов подряд в календаре. Исполнитель может быть доступен не всю смену, задача — ждать входных данных, а результат — требовать проверки. Для графа нужны оценки длительности этапов в одной выбранной единице. Трудоёмкость для бюджета хранится рядом, но не подменяет эти интервалы.
Два независимых этапа иногда выполняются одновременно. Но один сотрудник не превращается в двух только потому, что в плане появились параллельные линии. Модель зависимостей задаёт нижнюю организационную границу; доступность людей и среды уточняют расписание отдельно.
У каждой стрелки должно быть объяснение
Зависимость означает, что следующая работа не начинается до завершения предыдущей в принятой модели. Например, тестирование обмена требует работающего API, тестовых доступов и согласованного состава полей. Это не всегда означает, что весь интерфейс обязан ждать весь дизайн: иногда этапы можно разумно разделить.
Не соединяйте всё подряд только ради привычной последовательности. Лишняя зависимость искусственно растягивает срок. Но и удалять реальное условие ради красивой даты нельзя. Попросите исполнителя кратко объяснить каждую существенную стрелку и указать, что подтверждает её выполнение.
| Работа | Длительность | После чего | Раннее завершение |
|---|---|---|---|
| A: правила и структура | 2 условных дня | Начало | 2 |
| B: интерфейс | 4 | A | 6 |
| C: подготовка обмена | 3 | A | 5 |
| D: совместная проверка | 2 | B и C | 8 |
Сумма длительностей равна 11, но при допустимой параллельности нижняя оценка по зависимостям — 8. Ветка A–B–D определяет завершение. У C в этой модели есть один день резерва, пока она успевает к началу D. Это не свободный день для любых изменений в проекте: резерв относится к конкретным условиям расчёта.
Что означает критическая задача
В простом расчёте без дополнительных ограничений критическая работа не имеет временного резерва относительно полученного окончания. Её задержка сдвигает завершение, если остальные условия остаются прежними. Критических ветвей может быть несколько. Подсветить только одну красивую цепочку и забыть о другой — значит скрыть риск.
Некритическая работа не становится ненужной. Если она потратит запас, критический набор изменится. Поэтому граф пересчитывают после существенного изменения оценок или зависимостей. Старое слово «есть запас» не должно бессрочно оправдывать задержку.
Согласование — тоже работа с владельцем
Входные материалы, доступы, выбор вариантов и приёмка должны иметь ответственного и понятное условие завершения. Если срок согласования неизвестен, его нельзя честно заменить нулём. Можно договориться о плановом окне и правилах пересмотра даты при отклонении.
При этом не надо добавлять бесконечные скрытые буферы в каждую задачу. Лучше отдельно показать неопределённость и резерв проекта. Тогда заказчик понимает, где оценка основана на известных данных, а где ещё требуется решение. Конкретная дата становится следствием согласованного плана, а не результатом обратного подгона оценок.
Где заканчиваются возможности калькулятора
Инструмент принимает ID работы, целую длительность и список предшественников. Он строит граф без циклов, считает ранние и поздние сроки и показывает нулевой резерв. Единица — условный рабочий день, начало проекта обозначено нулём. Праздники, реальные даты и загрузка сотрудников не рассчитываются.
В модель входят только связи «завершение — начало» без задержек. Другие типы, например частичное перекрытие или зависимость от поставки с фиксированной датой, требуют расширения. Цикл означает ошибку описания: работа не может одновременно ждать собственное завершение через цепочку других задач.
Как использовать результат в заказе разработки
- Согласовать состав результата и понятные этапы, а не только названия экранов.
- Записать оценки и существенные входные зависимости.
- Проверить возможность заявленной параллельной работы по людям и доступам.
- Добавить реальные окна согласования и календарь.
- Зафиксировать основания изменения плана и повторно проверить его перед стартом.
Калькулятор не обещает срок студии и не заменяет оценку конкретного проекта. Он помогает увидеть, какое допущение скрывается за числом дней. Если после обсуждения выясняется недоступный внешний API или один перегруженный исполнитель, это полезный результат: проблему обнаружили до подписанного обещания, а не в день предполагаемой сдачи.
План зависимостей и резерв условных рабочих дней
Только завершение–начало, без календаря, задержек и ограничений ресурсов. Это модель плана, не коммерческое обещание даты. Расчёт выполняется на вашем устройстве, введённые данные никуда не отправляются.
Материалы для проверки
Если нужна реализация
Состав работ зависит от текущего проекта и подтверждённой причины. Можно обсудить диагностику или разработку подходящего решения.
