Как проект может отстать на год?
… по дню «за раз»
…Фред Брукс
Идея написать пост появилась в связи с тем, что в последнее время приходится сталкиваться со следующий кейсом: Руководители проектов стараются поддерживать процессы, соблюдать предписания методологий, собирать метрики, поддерживать высокую мотивацию на проекте. Но приходит время очередной проверки результатов работы (milestones, deliverables) и оказывается, что степень завершенности проекта отстает от плановой, что неминуемо приведет к срыву сроков. И руководитель проекта, стараясь устранить угрозу как можно раньше, озвучивает ее команде, а далее просто пытается ускорить процесс напутствующим словом и частным мониторингом, что без определения причин редко работает.
В качестве возможного варианта выявления причин проблемы (в приведенном кейсе – это перерасход времени), хотелось бы вспомнить один из достаточно простых инструментов мониторинга проекта — диаграмму Парето. Диаграмма позволяет определить первоочередные задачи, которые необходимо решить для устранения возникшей проблемы. Стоит отметить, что со всех инструментов контроля качества у нас прижилась диаграмма Парето по нескольким причинам:
1. Простота использования;
2. Быстрота расчета и отсутствие необходимости использовать какое-либо дополнительное программное обеспечение. Достаточно багтрекинговой системы и Excel-я;
3. Возможность обработки данных «задним числом». Означает, что если о каком-то факторе не было известно, то его всегда можно ввести в момент проведения анализа;
4. Наглядность полученных данных.
Ниже приведено подробное описание построения графика Парето для определения причин отставание от плана разработки.
Итак, на первом этапе нужно определиться с данными и их классификацией. Предположим, что на проекте перерасход времени был как на выполнение задач, так и исправление багов. Тогда для анализа достаточно выгрузить из багтрекинготовой системы следующую информацию: список сделанных фитч и закрытых багов. Отдельно выделить задачи, по которым был перерасход времени и определить его причины. В качестве примера предположим, что совместно с командой были выделены следующие факторы:
— Неверно сделанная оценка задачи;
— Перерасход времени, в связи с появлением багов при закрытии задачи.
Далее необходимо отдельно выделить факторы возникновения багов. В качестве примера также приведем следующие возможные причины:
— Возникновение бага из-за недостатка времени на тестирование задачи;
— Возникновение бага из-за невозможности тестирования фитчи (не было возможности смоделировать ситуацию);
— Баг появился вследствие ошибки в реализации фитчи (или непредусмотренный кейс программистом).
На втором этапе следует подсчитать количество фактов нарушения. Для нашего примера отразим результаты на рисунке 1:
Рисунок 1. Количество фактов
На третьем этапе следует подсчитать перерасход времени по каждому приведенному факту (рисунок 2).
Рисунок 2. Расчет перерасхода времени
Для полной картины в нашем примере мы выводим эти оба фактора как значимые. Количество фактов показывает частоту возникновения, затраты времени – степень влияния. Поэтому объединяем оба значения и определяем перерасход по времени с учетом количества факторов (рисунок 3).
Рисунок 3. Перерасход по времени с учетом количества факторов
Далее следует определить воздействие факторов. Для этого считаем процентное соотношение перерасхода времени с учетом количества факторов (4) по отношению к общему количеству этих факторов (итого по колонке 4). Сортируем колонку по убыванию (рисунок 4).
Рисунок 4. Воздействие факторов.
Следующим этапом необходимо определить суммарное воздействие факторов. Для первого фактора с максимальным значением будет его же значение, для каждого последующего – предыдущий плюс он сам (рисунок 5).
Рисунок 5. Суммарное воздействие факторов.
На последнем этапе — построение графика. Строится координатная ось. Вертикальная ось – проценты, горизонтальная – интервал, соответствующий числу причин проблемы. В приведенном примере результат построен в excel (рисунок 6).
Рисунок 6. График Парето
График наглядно показывает степень воздействие каждой причины и по закону 80/20 (суммарное воздействие) можно выделить главные факторы, которые повлияли на результат. В приведенном примере он вызван 3 причинами:
1. Возникновение бага из-за недостатка времени на тестирование фитчи;
2. Отставание в связи с появлением багов при закрытии фитчи;
3. Возникновение бага из-за невозможности тестирования фитчи (не было возможности смоделировать ситуацию).
Итог: как показала практика обычный усный опрос предположений команды причин отставаний далеко не всегда совпадает с полученным результатами по итогу построения графика Парето, так как значимость факторов достаточно сложно определить «на глаз». Кроме того, правило 80/20 позволяет сфокусироваться менеджеру на устранении результатообразующих факторов.
PS. Надеюсь, что пост был полезным, а описание не излишне подробным :-)
Автор: DeBovuar
