Как проект может отстать на год?
… по дню «за раз»
…Фред Брукс

Идея написать пост появилась в связи с тем, что в последнее время приходится сталкиваться со следующий кейсом: Руководители проектов стараются поддерживать процессы, соблюдать предписания методологий, собирать метрики, поддерживать высокую мотивацию на проекте. Но приходит время очередной проверки результатов работы (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

Источник