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

от автора

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Задачи за год — «реальные»

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

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

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

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

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


ссылка на оригинал статьи https://habr.com/ru/articles/821957/


Комментарии

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *