Как качать умение оценки задач?

 Публичный пост

Привет.

После очередного сорванного плана по срокам выполнения таска возник вопрос - а как качать умение предсказывать время выполнения задач?

Понятно что самое простое - накидывай время сверху. Однако тут возникает обратная проблема - оцениваешь задачу на сутки, делаешь за час. Ну и да, тяжко объяснить почему у этой задачи такая большая оценка : ) Аргумент "на всякий случай" обычно не прокатывает.
Пока вижу следующие способы решения проблемы:

  • Считать на сколько времени ты оцениваешь задачу и за сколько ты её делаешь. И просто учитывать ошибку оценки в будущих оценках. Проблему вижу в том что оценка может прыгать как вверх, так и вниз
  • Перед каждой задачей делать ресерч. Предпологается что хорошая design-doc перед задачей может уменьшить ошибку оценки. Проблема: на это требуется дополнительное время и планирование планирования
  • Разбивать каждую задачу на много подзадач пока размер не будет минимальный. Проблема: см пункт 2

Может быть у вас есть какие-то классные способы улучшить оценку задач? Возможно, единственный вариант правильно оценить задачу - если ты делал такую же уже раньше? Тогда что делать людям, которые делают уникальные вещи?
В любом случае, буду рад советам от более опытных ребят.

Связанные посты
4 комментария 👇

Не нужна эта точность никому.

Точная оценка стоит дорого так как потребует детализации и подготовки. Не лучше ли это время потратить собственно на реализацию?

Точная оценка как правило никому не нужна, крутые PMы строят критический путь , плохие умножают сроки на 3.14. Но по факту это ни на что не влияет.

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

Как по мне, то гораздо полезнее изучить метрики из Канбан (Throughput, Lead Time, Cycle time) и научиться их собирать, считать, анализировать и строить прогнозы на основе исторических данных.

  Развернуть 1 комментарий

У меня задачи бывают двух типов: "Да тут хуйня делов, ща сделаю" и "Ну тут хз, дай мне день/неделю/месяц". Первый тип подразумевает, что задача будет сделана в течение дня. С задачами второго типа сложнее.

Время я беру чисто от пизды по своему опыту, докидываю сколько-то допуска на форс-мажоры, и просто делаю то, что успеваю сделать за оговорённое время. Практически всегда успеваю сделать минимальную версию решения, по которой уже можно получить обратную связь и дальше уже дробить на более конкретные задачи вида "Да тут хуйня делов, ща сделаю". Если не успеваю сделать всё, что хотел -- срезаю углы, чтобы успеть. Метод прогрессивного джипега короче. Как правило никому не нужно прям вот идеально работающее решение, и такой подход в большинстве случаев удовлетворяет вообще всех.

Один раз было так, что оценил задачу в неделю, а сделал за день. Тогда я просто сказал "Смотри, вот я тут сделал, может ещё что-то докинем?". Лучше уж так, чем не успеть

Надо понимать, что такой подход плохо будет работать, когда у программистов KPI по карточкам в жире и зарплата по времени на таску. Но в таком случае можно просто давать больше эстимейт, если просят дать меньше -- давай чуть-чуть меньше)

  Развернуть 1 комментарий
🕵️ Юзер скрыл свои комментарии от публичного просмотра...
Nikita Kulikov Mobile/Android Engineer автор 9 марта 2021

Прикреплю еще топик на похожую тему: https://vas3k.club/post/2647/
Но там более высокоуровнево, не со стороны инженера

  Развернуть 1 комментарий

😱 Комментарий удален его автором...

  Развернуть 1 комментарий

😎

Автор поста открыл его для большого интернета, но комментирование и движухи доступны только участникам Клуба

Что вообще здесь происходит?


Войти  или  Вступить в Клуб