Поясняет Леша Гмитрон, наставник на курсе «Фронтенд-разработчик»:
Оценка сроков выполнения задач — частая боль разработчиков. Довольно часто срок задачи невозможно оценить точно: порой не всё в этой задаче зависит от одного тебя. Обычно задача требует множества уточнений у людей из разных команд или зависит от другой задачи, которой занят другой разработчик. А ещё там меняются вводные, ломается инфраструктура, из-за чего задерживается тестирование или деплой новой задачи, и есть множество других факторов.
Поэтому, перед тем как обещать сроки менеджеру, более опытные разработчики сначала берут паузу: обсуждают нюансы с коллегами, которые могут быть больше погружены в контекст и могут знать какие-либо подводные камни; смотрят код, чтобы хотя бы понять, возможно ли реализовать задачу или для этого придётся всё переписать. После чего уже можно и назвать срок, заложив ещё дополнительно некоторое время на случай неожиданностей, чтобы не подводить тех, кто на эти сроки рассчитывает.
Когда менеджер просит назвать точный срок здесь и сейчас, то так и хочется сделать срок побольше, чтобы без предварительных прикидок не поставить невыполнимый дедлайн, в который невозможно уложиться.
В меме разработчику не дают время подумать и тщательно оценить задачу, поэтому он называет срок сразу в три года, что для разработки одной фичи обычно очень много, — но он это делает на всякий пожарный.
