Как стать автором
Обновить

Оценка времени выполнения задач: желаемое и реальное

Время на прочтение3 мин
Количество просмотров5.4K

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

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

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

  3. Недооценка факторов риска: исполнители могут не учитывать возможные трудности и препятствия, которые могут возникнуть в процессе работы и затормозить выполнение задачи. Внешние факторы, такие как изменения в требованиях заказчика или задержки в поставках, могут значительно повлиять на время выполнения задачи.

  4. Недостаточный опыт: неопытные исполнители могут занижать оценки времени из-за нехватки опыта и знаний по данному виду работы.

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

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

От слов - к делу. В любой команде есть некое представление о том, сколько времени потребуется на выполнение той или иной задачи. Есть сторипоинты у задач для указания сложности, а вместе с тем и примерного количества времени на выполнение. Но анализировать данные по задачам в своей команде не так интересно, т.к. всё равно есть некое представление о том, кто, как быстро и какие задачи делает. В рамках своего небольшого исследования буду использовать некий датасет, состоящий из данных по выполенным задачам в техподдержке в одной из IT компаний. На команду делаются тикеты, они их выполняют, но сроки выполнения всегда плавающие. Это добавляет интереса :)

Какие данные из датасета буду использовать: дата создания задачи, приоритет, дата решения, статус.

Датасет после обработки
Датасет после обработки

Посмотрим на соотношение приоритета и даты создания задач

Диаграмма рессеяния за 2022 г.
Диаграмма рессеяния за 2022 г.

А сколько в среднем тратится времени на выполнение тикета в зависимости от приоритета?

Диаграмма за месяц
Диаграмма за месяц

Ещё можно посмотреть распределение задач по дате создания за месяц. Как раз будет наглядно видно, что в выходные почти никто не работает (ожидаемо)

Распределение задач в месяц
Распределение задач в месяц

А когда создаётся больше всего тикетов? Это тоже можем посмотреть - в среду

Распределение задач по дням недели
Распределение задач по дням недели

А днём когда чаще всего создают тикеты? Неожиданно - в обед. Накидали тикетов и пошли со спокойной совестью на обед :)

Вернёмся к тому, с чего начали - оценка времени на выполнение задач. Если ориентироваться на гибкие методологии и различные (популярные) исследования в этой области, то обычно приводится диаграмма нормального распределения. К примеру, в книге Майка Кона «Agile: оценка и планирование проектов» приводятся распределения для «одно-», «двух-» и «трёхпунктовой» задач.

Распределение времени, необходимого для реализации «однопунктовой» задачи
Распределение времени, необходимого для реализации «однопунктовой» задачи
Распределение времени, необходимого для реализации «одно-», «двух-» и «трёхпунктовой» задач
Распределение времени, необходимого для реализации «одно-», «двух-» и «трёхпунктовой» задач

Предположим, что в нашем случае команда работает по гибкой методологии разработки Agile. Одна условная задача в среднем выполняется за 3 дня, т.е. 72 часа. Возьмём сутки в качестве стандартного отклонения, т.е. 24 часа. Как в предыдущем примере, для наглядности и простоты сравнения результатов, сгенерируем 66960 случайных чисел, что будет равно 66960 задач.

Задачи за год - синтетические
Задачи за год - синтетические

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

На гистограмме видно, что данные распределены нормально (по закону Гаусса).

А как на самом деле? Анализ датасета показывает, что среднее значение 58ч., а стандартное отклонение 129ч.

Задачи за год - "реальные"
Задачи за год - "реальные"

Посмотрим плотность распределения задач по "реальным" данным

Распределение задач по количеству часов за год
Распределение задач по количеству часов за год

Ого! Это что? А где нормальное расрпеделение? Оказывается, что в действительности распределение логарифмическое, а не нормальное (Гаусс). Получившийся "хвостик" из задач можно отнести к различным причинам: сегодня не хотелось что-то делать, блокер, низкая производительность и т.д.

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

Теги:
Хабы:
Всего голосов 4: ↑3 и ↓1+4
Комментарии7

Публикации

Истории

Ближайшие события

7 – 8 ноября
Конференция byteoilgas_conf 2024
МоскваОнлайн
7 – 8 ноября
Конференция «Матемаркетинг»
МоскваОнлайн
15 – 16 ноября
IT-конференция Merge Skolkovo
Москва
22 – 24 ноября
Хакатон «AgroCode Hack Genetics'24»
Онлайн
28 ноября
Конференция «TechRec: ITHR CAMPUS»
МоскваОнлайн
25 – 26 апреля
IT-конференция Merge Tatarstan 2025
Казань