Как дать максимально хреновую оценку задаче

[Ab0cha]

Главное не поддаваться, если оценка действительно адекватная)

[vintikzzz]

А на аватарке у автора есть руки?

[shok96]

руки-скриптухи)))

[yellow79]

Работая в одной компании, где очень любили, когда задачи выполняются в срок, но очень не любили твои отказы, когда ты занят решением задачи, а тебе приносят другую, я выработал для себя золотое правило, оцени сроки и умножь их на 3. Всегда успевал, даже с учётом наваливающихся дополнительных задач, всегда молодец, всегда в срок или раньше. С тех пор прошло почти 5 лет, а способ оценки сроков у меня так и не изменился

[pilot114]

Можете подробнее расказать о той части, которая идет до умножения на 3?
Тоже хочу всегда в срок успевать

[yellow79]

Тут всё зависит от конкретики. Руководствуясь опытом и зная кодовую базу проекта обычно безошибочно понимаю сколько надо на решение той или иной задачи. Но если оценить сходу не получается, то беру время на оценку. Бью задачу на максимально минимальные подзадачи, которые могу точно оценить руководствуясь опытом, в сторону откладываю то, что оценить не получается даже после деления. После пытаюсь накидать по-быстрому прототип тех подзадач которые оценить не удаётся, чтобы появилось хоть какое-то понимание объёмов. Ну а дальше складываю, умножаю, озвучиваю

[steal-a-var]

Прикол. Я всегда на 2 умножаю, и вроде работает)

[Zifix]

ru.wikipedia.org/wiki/Законы_Паркинсона#Первый_закон_Паркинсона

[Pan_brigadir]

Как ваш способ работает на больших задачах?
К примеру Вы оценили задачу в месяц и говорите что будете делать её 3 месяца?
Насколько ваш подход работает на длительных задачах?

[Ab0cha]

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

[fireSparrow]

А как манагер может оценить чисто технические вещи?

[XVlady5]

Меня часто спрашивают:
Почему это нормально, что на прохождение ревью может уйти в 2 раза больше времени чем на написание кода? Может быть ли это нормально для старичков проекта? Почему? Или сколько времени закладывать на исправление выявленных багов? Почему так много? что будет если половину этого времени переложить на аналитиков, то будет ли здесь экономия?
Что вы отвечаете на такие вопросы?

[Ab0cha]

Почему это нормально, что на прохождение ревью может уйти в 2 раза больше времени чем на написание кода?
— Это нормально, так как на проекте может быть несколько разработчиков и каждый из них может оставить свое замечание к вашему пул реквесту, которое придется либо оспаривать, либо исправлять.
Может быть ли это нормально для старичков проекта?
— Со старичками проекта такое случается реже, так как они уже больше знают о специфике проекта и правилах код ревью, которые установлены на этом проекте
Или сколько времени закладывать на исправление выявленных багов?
Сложно дать точный ответ на этот вопрос, опять же все зависит от специфики проекта, сложности вашей задачи и так далее. Очень много факторов имеют влияние.
Что будет если половину этого времени переложить на аналитиков, то будет ли здесь экономия?
— Не до конца понял вопрос, половину какого именно времени ?)