Визуализация прогноза как инструмент общения с заказчиком

Как известно, разработка софта была бы намного более приятным делом, если бы в ней не были замешаны пользователи и - герои статьи - заказчики. Все проблемы от них:

Например, заказчик приходит и спрашивает: "Успеете сделать вот ЭТО к дедлайну?". Надо ему что-то ответить, да ещё чтобы это было правдой. Ответ, конечно же: "Нет", и это правда. Но этот ответ заказчика не устраивает, и он начинает приставать со всякими неудобными вопросами:

- А сколько времени надо?

- А если к дедлайну, то сколько успеете?

- А точно успеете?

- А если вот ещё эту работу впихнуть, то успеете? Нет? А сколько тогда не успеете?

По сути в ходе общения с заказчиком идёт поиск приемлемого решения в классическом проектном треугольнике:

 

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

Природа человека такова, что он получает львиную долю информации через зрение. Следовательно, чтобы сделать что-то понятным, надо сделать это наглядным. Чтобы легче было искать конкретное решение в треугольнике, необходимо как-то визуализировать спектр этих решений. Как это сделать?

Теория

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

Здесь на вертикальной оси отложено содержание бэклога, а на горизонтальной - время. Верхний левый угол - это нулевое содержание с плановой сдачей сейчас. Движение вниз увеличивает содержание, движение вправо - количество оставшегося до релиза времени. Каждая точка на этой плоскости - конкретное решение <Содержание, Время>. Очевидно, что не все варианты являются реалистичными для нашей команды. Чтобы понять, что и за какое время мы успеваем сделать, применяется метод эмпирического прогнозирования, описанный выше. Этот метод позволяет рассечь эту плоскость на три области:

1. "Зеленую зону" - решения из этой зоны попадают в зону возможностей команды даже при пессимистическом варианте развития событий.
2. "Красную зону" - решения из этой зоны заведомо превосходят возможности команды даже в оптимистическом сценарии.
3. "Конус неопределенности" - решения, находящиеся в конусе, возможны при оптимистическом варианте развития событий и невозможны при пессимистическом.

Хотя концепция неопределённости будущего и вероятностного характера планирования не нова, на практике ответ "не знаю" является некоторым табу, а фразы "скорее всего сделаем" или "наверное не успеем" часто округляются до "да" или "нет". Я считаю, что неопределённость будущего должна быть явно выражена в прогнозах, потому на диаграмме присутствует конус неопределённости. Как именно получить оптимистически и пессимистический варианты прогноза - тема отдельной статьи. Пока просто примем, что менеджер применяет какой-то метод.

Применять эту диаграмму можно для получения ответа на два принципиальных вопроса:

1. Что мы успеваем к выбранному сроку в оптимистическом и пессимистическом сценариях?

2. К какому сроку мы можем завершить выбранный объем работ в оптимистическом и пессимистическом сценариях?

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

Например, это помогает решить проблему "наброса на бэклог" новой работы:

Приходит заказчик и говорит:
- А вот красную ручку сбоку ещё прилепить успеете?
- Конечно успеем! - отвечает разработчик, подразумевая, что ручку-то они успеют, но за счёт чего-то.
- Вот и ладненько, - радуется босс, уверенный, что добавил новую работу без ущерба для ранее согласованной.

Если этот разговор вести у диаграммы, то сразу станет очевидно, какая работа "уедет" в красную или жёлтую зону, если выполнить новое требование босса.

Практика

Как на практике я применяю этот подход? Хотя принципы построения диаграммы исключительно просты, строить и перестраивать её вручную нельзя: это убивает важное преимущество - интерактивность процесса поиска решения. Полноценной программы, которая бы это автоматизировала, я пока не сделал, но добился некоторых результатов в Excel. Первый прототип был сделан исключительно на формулах, но он был неудобен в использвании. Второй прототип использует несколько простых макросов (всего 126 строк).

Для получения картинки необходимо заполнить параметры "Average velocity" и "Velocity variation" (слева сверху), а так же заполнить таблицу бэклога работами с оценкой их трудоёмкости. После этого кнопка "Пересчитать" вызывает макрос, которой заполняет цветную диаграмму справа. Цифры в диаграмме - побочный артефакт работы макроса и ничего особенного не означают.

Здесь представлена картинка расчёта диаграммы из реального проекта, поэтому я скрыл наименования работ. Работы с оценкой "0" уже завершены и я держу их в этой таблице только для полноты картины запланированных работ. Как видно, к плановой дате завершения, которая наступит через десять недель, будет сделано не всё.  Из двадцати восьми работ только шестнадцать попадают в зелёную зону, четыре - в жёлтую; ещё восемь работ в красной зоне.

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

Ограничения инструмента

Описанный здесь инструмент имеет важное преимущество - он очень прост для понимания, а потому его легко объяснить заказчику. У этой простоты есть и обратная сторона - ограничения, о которых необходимо помнить:

• Он не является заменой управлению проекта. К сожалению, эта область до сих пор превосходит возможности макросов в Excel. Основная задача менеджера не строить диаграммы, а решать проблемы.
• Прогноз строится по урощённой линейной схеме и теряет точность по мере удаления горизонта планирования. На реальных метриках при горизонте планирования в 10-15 недель область неопределённости становится слишком большой, чтобы диаграмма помогала принимать решения.
• Однажды построенный прогноз ничего не гарантирует.
• Прогноз не учитывает зависимости между работами.

Вообщем, это удобный инструмент для визуализации прогноза проекта, но не более того.

Заключение

В этой статье я описал свои наработки по визуализации результатов прогнозирования разработки, ведущейся по модным нынче "легковесным" процессам. И метод и конкретная реализация ещё далеки от совершенства и будут улучшаться по мере необходимости, но уже сейчас приносят реальную пользу в работе.