Проблема в оценке требуемого времени на решение задач состоит в том, что часто оценки времени оказываются недостоверными и недооцененными. Это может привести к несоблюдению сроков выполнения задач, задержкам в проекте и дополнительным расходам. Причины этой проблемы могут быть разными:
Недостаточное понимание задачи: часто исполнители не полностью понимают объем работы и сложность задачи, из-за чего недооценивают необходимое время на ее выполнение. Некоторые задачи могут быть менее понятными или сложными, чем кажутся на первый взгляд, что затрудняет оценку времени на их выполнение.
Оптимистичный подход: исполнители часто имеют склонность к оптимистичной оценке времени, надеясь на быструю и легкую реализацию задачи. Некоторые задачи могут потребовать больше времени и ресурсов, чем изначально предполагалось из-за неожиданных проблем или сложностей.
Недооценка факторов риска: исполнители могут не учитывать возможные трудности и препятствия, которые могут возникнуть в процессе работы и затормозить выполнение задачи. Внешние факторы, такие как изменения в требованиях заказчика или задержки в поставках, могут значительно повлиять на время выполнения задачи.
Недостаточный опыт: неопытные исполнители могут занижать оценки времени из-за нехватки опыта и знаний по данному виду работы.
Недооценка времени на тестирование. Тестирование и отладка программного обеспечения могут занимать значительное количество времени, и их учет при оценке сроков выполнения задачи может быть недостаточным.
Оценка требуемого времени на выполнение задачи в области разработки программного обеспечения зависит от многих факторов, таких как сложность задачи, опыт разработчика, доступность необходимых ресурсов и технологий, а также особенностей проекта.
От слов - к делу. В любой команде есть некое представление о том, сколько времени потребуется на выполнение той или иной задачи. Есть сторипоинты у задач для указания сложности, а вместе с тем и примерного количества времени на выполнение. Но анализировать данные по задачам в своей команде не так интересно, т.к. всё равно есть некое представление о том, кто, как быстро и какие задачи делает. В рамках своего небольшого исследования буду использовать некий датасет, состоящий из данных по выполенным задачам в техподдержке в одной из IT компаний. На команду делаются тикеты, они их выполняют, но сроки выполнения всегда плавающие. Это добавляет интереса :)
Какие данные из датасета буду использовать: дата создания задачи, приоритет, дата решения, статус.
Посмотрим на соотношение приоритета и даты создания задач
А сколько в среднем тратится времени на выполнение тикета в зависимости от приоритета?
Ещё можно посмотреть распределение задач по дате создания за месяц. Как раз будет наглядно видно, что в выходные почти никто не работает (ожидаемо)
А когда создаётся больше всего тикетов? Это тоже можем посмотреть - в среду
А днём когда чаще всего создают тикеты? Неожиданно - в обед. Накидали тикетов и пошли со спокойной совестью на обед :)
Вернёмся к тому, с чего начали - оценка времени на выполнение задач. Если ориентироваться на гибкие методологии и различные (популярные) исследования в этой области, то обычно приводится диаграмма нормального распределения. К примеру, в книге Майка Кона «Agile: оценка и планирование проектов» приводятся распределения для «одно-», «двух-» и «трёхпунктовой» задач.
Предположим, что в нашем случае команда работает по гибкой методологии разработки Agile. Одна условная задача в среднем выполняется за 3 дня, т.е. 72 часа. Возьмём сутки в качестве стандартного отклонения, т.е. 24 часа. Как в предыдущем примере, для наглядности и простоты сравнения результатов, сгенерируем 66960 случайных чисел, что будет равно 66960 задач.
Посмотрим плотность распределения задач по сгенерированным данным
На гистограмме видно, что данные распределены нормально (по закону Гаусса).
А как на самом деле? Анализ датасета показывает, что среднее значение 58ч., а стандартное отклонение 129ч.
Посмотрим плотность распределения задач по "реальным" данным
Ого! Это что? А где нормальное расрпеделение? Оказывается, что в действительности распределение логарифмическое, а не нормальное (Гаусс). Получившийся "хвостик" из задач можно отнести к различным причинам: сегодня не хотелось что-то делать, блокер, низкая производительность и т.д.
В качестве вывода
С одной стороны можно увидеть, что не всё так просто, как кажется. Реальность и оценка трудозатрат (времени) на выполнение не всегда совпадают. Но с другой стороны хотелось бы отметить то, что в представленном небольшом исследовании были проанализированы данные в одной компании и с одним (усреднённым) подходом к выполнению задач.
Комментарии (6)
ManGegenMann
14.06.2024 22:45+1Невероятно но факт. В области где каждая задача уникальная, а для точной оценки в ±3ч необходимо провести исследование на 10ч невозможно нормально сказать когда будет готова задача.
Когда-то люди поймут что оценка задач бесполезное занятие и мы вернёмся обратно к разработке, а не планингам и грумингам.
Octabun
14.06.2024 22:45+1Когда-то люди поймут что оценка задач бесполезное занятие
А разве люди этого не понимают? Проблема в том, что человечество упорствует в огромном количестве абсолютно идиотских практик и в каждом случае у этого есть фундаментальная причина не имеющая никакого отношения ни к непониманию ни к глупости. Конкретно с оценкой времени имеем
цель деятельности как уведичение капитала. Капиталу всё равно куда вкладываться, чтобы решить куда ему нужны оценка выгод и оценка затрат. Первую определяет талант бизнесмена, в здоровом обществе состоящий в способности понимать истинные, см. Джобс, потребности окружающих, а вторую - опыт бизнесмена, в случае быстро изменяющейся среды типа ИТ мало полезный, и любые ухищрения типа оценок задач.
использование работы по найму. Связанные с ней интересанты, начиная со слоя менеджеров, нуждаются в оценках как для того, чтобы говорить с капиталом, так и для укрепления власти и отсева имперсонаторов.
Таким образом, оценка задач - неизбежное зло. Попытка от этого избавиться без устранения обеих фундаментальных причин - сделает только хуже.
За много-много лет видел всего два решения.
в СССР полным аналогом оценки была необходимость составления квартального плана. Решение - включение в план только уже выполненных работ.
в стартапе в США талантливый менеджер не давал заданий, не спрашивал сроков, а объяснял направление развития. Иногда, правда, говорил типа - вот эти две фичи нужны к следующему понедельнику, отдел продаж их уже продал.
В обоих случаях вопрос о вложении капитала был решён до того, а проблема менеджмента и имперсонаторов была решена внеэкономическими методами.
Вывод; если нет возможности организовать производство совсем иначе, не так как все, обратно см. Джобс, то терпите и не дёргайтесь.
donRumatta
14.06.2024 22:45Добрый день!
Решение - включение в план только уже выполненных работ.
А можно тут поподробнее? Заполнять план задним числом? Или просто отставать/опережать на квартал по документам?
Это же рецепт идеального agile - спокойно делать задачи по приоритетам, а на планировании заполнять следующий спринт итогом предыдущего)
maclaudstein
14.06.2024 22:45У меня было в управлении 2 команды - веб и мобилки, с частью общих сервисов, где как раз оценки фронтов были близки к правде, а оценки на сервисы сильно расходились с действительностью именно в мобильной команде.
Что сделали: мобилки согласовали некий шаблон оценки задач и рисков при ее решении, и мы договорлись, что задачи со средней степенью неопределенности и сложнее мы идем и оцениваем дольше, выделяя время в спринте только на оценку (с неким исследованием). Если задача в принципе неоцениваема, мы выделяли отдельной задачей поиск решения, согласовывали на это выделение времени, и после поиска задача сводилась из высокой неопределенности к средней или набору простых, и оценки бились. Оценки нужны для 2х вещей: чтобы спринт был наполнен, а не перегружен (то есть чтобы разработчик честно сказал, я не сделаю - и не сделал), а так же чтобы бизнесовому заказчику делать ограничения с 2х сторон на периоде (сделаем не раньше такого-то и не позже такого-то).
Итог довольно простой: в командах вопрос на ретро "почему ты не сделал, хотя мы же планировали" перестал подниматься в принципе, отношения стали гораздо лучше, а для бизнеса стало понятнее, что если они хотят что-то впихнуть, то придется чем-то жертвовать. Я продакт, то есть я представлял тот самый бизнес, но так как я же и проджект (ну не было отдельного, епрст), я же и понимал необходимость ограничений, прекрасно понимал своих парняг и девчин в команде, и как следствие, у нас доверие, чилл, отсутствие авралов по вине перепланирования, не было кранчей - мне спокойно, людям спокойно.
а если приходить сверху и как заказчик "а к среде сделаете? а почему?", не разбираться в процессах, не иметь понимания технологий и ограничений, не видеть ситуацию изнутри - то да, проблема оценок стоит остро, тогда "эти они виноватые, а я все сделал" и прочие радости эффективного менеджмента вылезают. Вы одно целое с командой, один продукт делаете, один хлеб едите, так и двигайтесь к общим интересам
Мы когда приходили с проблемой оценок в команду, мы тоже с вторым коллегой-продактом приходили не с ноги "вы все косяки", а с проблемой "у нас есть запрос озвучивать границы, мы уже и перезакладываемся, и че тока не делаем, но все равно случается попадос, и влетаем - ребяты, как можно сделать лучше".
и ретры не ради ретр, а ретры от лица любого члена команды с подобными вопросами имеют место быть, с совместным же решением, благодарностями, участием. Вот тогда щасье
bloomdido
14.06.2024 22:45Поэтому и существует скрам и подобные методологии - не для организации работы (разработчикам скрам не нужен), а чтобы дать "заказчикам сверху" ту степень предсказуемости, которая реально существует. Чтобы PM или техлид говорили с бизнесом на языке реалий и не обманывали друг друга вымышленными сроками. Команда для себя отщипнула от бэклога вот столько на ближайший спринт, еще в бэклоге есть столько-то задач, которые в принципе удалось оценить, по темпам работы, которые наблюдались раньше, похоже, что это еще на пару спринтов. И еще в бэклоге есть миллион задач, которые мы даже не видим смысла пока оценивать - но вы на стороне бизнеса можете каким-то из них поставить высокий приоритет, и тогда мы будем что-то отщипывать от них для следующего спринта.
HEXFFFFFFFF
В it с определением времени выполнения работы есть трудности. Я 35 лет в it но не всегда могу оценить обьем работ. Но оценка может быть неверной в обе стороны. Может оказаться что трудная на первый взгляд задача реалезуется за пару часов. А может быть что простая, казалась бы задача, может потребовать не одну неделю работы.
Очень частая ситуация - для решения задачи существует библиотека, возможно не одна. В таком случае интеграция библиотеки не сложная задача. Но в процессе интеграции может выяснится что не одна из библиотек не работает стабильно, имеет баги или недочеты. При этом еще не известно что займет меньше времени - правка чужой библиотеки или написание своей.
Так же есть существенная разница между it и другими отраслями. На стройке плохой каменщик кладет 100 кирпичей в час а хороший 150. В it производительность труда хорошего и плохого программиста может отличатся в сто раз.
То что один програмист делает за месяц, двое за два, трое за три, а десять за год))))