Если на задачу дать неделю, скорее всего, её и будут делать неделю. Если дать месяц, вполне возможно, что она растянется на месяц.
И дело не обязательно в том, что люди начинают работать медленнее. Просто когда времени много, появляется соблазн сделать «ещё чуть лучше»: что-то дополнительно обсудить, отрефакторить, предусмотреть ещё один сценарий или заодно поправить соседнюю проблему.
В разработке это особенно заметно:
- появляется лишний рефакторинг;
- добавляются новые абстракции;
- возникают дополнительные сценарии и требования;
- в задачу постепенно попадает то, чего изначально вообще не планировали.
В итоге задача начинает расти вместе с доступным временем.
Это касается не только отдельных задач, но и целых проектов. Если на проект изначально заложено много времени, команда может начать тратить этот запас на дополнительные эксперименты: например, внедрить DDD, хотя проект пока этого не требует, а практического опыта с этим подходом у команды нет. Появляется ощущение: «время есть, заодно разберёмся».
Само по себе изучение нового подхода не проблема. Проблема возникает, когда обучение, эксперименты и усложнение архитектуры начинают попадать в критический путь проекта без явной необходимости.
Важно помнить и об обратной стороне: слишком короткий дедлайн тоже не делает работу эффективнее. Он может привести к ошибкам, техническому долгу и отказу от важных решений ради скорости.
Поэтому смысл закона Паркинсона не в том, чтобы постоянно ужимать сроки. Скорее в том, чтобы заранее договориться, что именно считается готовым результатом, и не превращать свободное время в повод бесконечно расширять задачу.
Срок это не только ограничение. Он ещё и влияет на то, сколько работы мы в итоге сами себе создаём.