Задать вопрос
@JustMoose
Программист. Радиолюбитель. Прокрастинатор ;)

Как оценивать сроки по задачам?

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

Речь про обычные разработческие задачи (на плюсах, в сильно незнакомом коде). Например, "а давайте нарисуем новый клёвый диалог к нашему редактору/браузеру/космолёту" (возможно предварительно поисследовав, а как такие диалоги вообще делают в данном конкретном редакторе/браузере/....).
  • Вопрос задан
  • 129 просмотров
Подписаться 1 Простой 1 комментарий
Пригласить эксперта
Ответы на вопрос 4
DadSkil
@DadSkil
PM и продакт
Было бы неплохо, если дополните свой вопрос контекстом:
1. Работаете над задачами в соло над собственным проектом или в найме
2. Есть ли коллеги или знакомые с релевантным опытом
В целом CBET_TbMbI дал ответ. Если хотите больше конкретики, желательно добавить фактуры.

Если без контекста:
1. Разбивайте задачу до более мелких, которые вы сможете оценить.
2. Опирайтесь на похожие задачи, которые уже делали.
3. Учитывайте в оценке не только время на написание кода, но и продумывание решения, взаимодействие с коллегами (либо на форумах / чатах), перерывы, проверку написанного кода и на возможные итерации правок после тестирования.
4. Консультируйтесь у коллег, кто уже имеет экспертизу по аналогичной задаче.
5. Возможен кейс, когда дать оценку без ресерча - пальцем в потолок как ни пытайся декомпозировать. Сперва оцените время на ресерч и если он кратно меньше потенциальной оценки на реализацию, по его результатам уже саму задачу.

Если будет желание углубиться в разные методы оценки, как вариант попробуйте оценку по трем точкам.
Ответ написан
Комментировать
@CBET_TbMbI
Вариант 1: опросить 10 опытных разработчиков и взять среднее (или не среднее, а, например, то время в которое с 95% вероятностью уложитесь).

Вариант 2: найти задачу-аналог и прировнять к ней. Возможно, умножив на некий коэффициент, если это уместно. Например, если вы делали ПО для производства бетона месяц, то можно ожидать, что для другого бетонного завода сделаете тоже примерно за месяц. Но если в другом заводе технологических операций в 2 раза больше, то, вероятно понадобится 1,5-2 месяца.

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

Вариант 4. Опыт рулит. Опытный управленец после первого знакомства с проектом и заказчиком может сказать "да мы тут только ТЗ месяц согласовывать будем, потом месяц делать, потом месяц переделывать под его хотелки, которые он забудет указать".
Ответ написан
Комментировать
xez
@xez
TL Junior Roo
Мое видение такое: оценить можно только атомарные задачи - условно, такие, которые могут быть выполнены за 4 часа. Т.е. если вы можете сказать - "это я за 4 часа напишу", можно считать такую задачу на 1Sp.
Если вдруг задача выходит за 4 часа, то она переходит в разряд неопределенности. Нельзя ее предварительно оценить не в 2sp ни даже больше, только по факту выполнения.
Что делать, если задача явно не 4 часа разработки, а, предположим на 4000 часов? Ее нужно декомпозировать на такие вот атомарные кирпичики в 1Sp. Потом эти кирпичики сложить, умножить на 1.5, добавить 2 недели и получится ориентировочный срок выполнения.

Почитать советую "Мифический человеко-месяц".
Декомпозиции научитесь с опытом.
Ответ написан
Комментировать
@Vitsliputsli
чтобы мне такого почитать про оценку времени вообще и про декомпозицию задач в частности?

Я бы посоветовал ничего не читать и не тратить впустую время. Оценка времени разработки никогда не бывает точной и с этим нужно смириться. Декомпозиция вещь хорошая, но тут теория вряд ли поможет, только опыт разработки.
Любая попытка более точной оценки - это устранение неопределенностей, для этого, например, разбивают на более мелкие задачи в которых точно уже известно что делать и кажется что все контролируешь. Но, оценка никуда не делась и она всегда строится на "похожих" задачах, которые уже делались. Только вот если мы говорим про нормальную разработку, то там это не работает, совсем... Если действительно похожая задача реализована, значит основной функционал уже есть и нужны только минимальные правки, а значит вторая задача будет стоить несравнимо меньше. Другой момент, действительно со стороны может показаться что есть похожие задачи и на них всегда тратится похожее кол-во времени, но в какойто момент времени окажется что следующая "похожая" обойдется в 10 раз дороже. Поэтому если где-то похожие задачи всегда стабильно стоят одинаково, то скорее там не разработка, а набор текста.
Если про правки "в сильно незнакомом коде", то даже не пытайтесь, здесь неопределенность зашкаливает. Такой код требует предварительно изучения, и не важно какая задача, она может решаться как добавлением 2 строчек, так и переписыванием всего и вся.
"возможно предварительно поисследовав", как только вы употребили слово исследование, никакие оценки здесь уже не применимы. Исследования не оценивают, на них выделяют время, когда время закончилось решают нужно ли еще время или бессмысленно копать в эту сторону.
Это все, конечно, несколько утрировано, но, на мой взгляд все что требуется со стороны разработчика (а я так понял вопрос именно с этой стороны) это просто давать оценку задачам, а затем обращать внимание на аспекты которые потребовали много времени, но которые упустили при планировании.
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Похожие вопросы