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

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

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

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

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

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

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

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

 

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

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

Теория

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

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

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

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

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

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

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

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

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

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

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

Практика

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

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

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

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

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

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

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

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

Заключение

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

"О стеклянном потолке" или приложение Теории ограничений к профессиональному развитию.

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

Может быть, дело в тебе

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

Источник картинки

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

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

Это, конечно, упрощённая модель. У человека не может быть одного ограничения, которое во всех ситуациях мешает ему работать. В зависимости от ситуации человек может упираться в разные ограничения, но общая тенденция сохраняется. По мере развития технических навыков он чаще начинает упираться во что-то другое.

Но если работа программиста - писать программы, то что же такое его может ограничивать кроме, собственно, умения программировать? Судя по своему личному опыту, я могу привести такие примеры:

• Личная несобранность и неумение организовать свою работу.
• Неумение доносить свои мысли до коллег и воспринимать их идеи.
• Неумение конструктивно решать конфликты точек зрения между коллегами.
• Неконструктивное восприятие критики.
• Неумение планировать и исполнять долгосрочные проекты в условиях отвлечения текущими проблемами.
• Излишне оптимистичное мышление.
• Отсутствие системности в решении проблем.
• Невнимательность к деталям.
• Непонимание бизнеса, в котором я работаю.
• Неспособность взглянуть на проблему глазами заказчика или пользователя.

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

А может быть, и не в тебе

Но это лишь одна из причин, которые могут приводить к феномену "стеклянного потолка". Теория ограничения подсказывает и другоую причину: внешнее ограничение. В романе "Дело не в везенье" из цикла "Цель" Голдратт описывает вымышленную компанию, поставляющую паровое оборудование. Они упёрлись в саму форму отношений с клиентами и нашли решение в переходе от вендорской модели к сервисной. Если предприятие разобралось со своими внутренними проблемами, то дальнейший рост может быть ограничен внешним фактором: ёмкостью рынка, поставщиками, формой отношений с клиентом.

Как этот принцип переносится в персональную область? Он даёт объяснение ещё одной причине "стеклянного потолка". Можно стать идеальным сотрудником, развить все свои навыки до совершенства лишь для того, чтобы упереться в ограниченность своей роли в конкретной компании. Существует много красивых рассказов о ключевых технических специалистах разрабатывающих ключевые для бизнеса технологии и получающих баснословные зарплаты. Суровая реальность состоит в том, что таких позиций - единицы, большинство разработчиков занимаются более обыденными вещами и не способны существенно повлиять на успех бизнеса. А раз так, то и ценность их для бизнеса ограничена сверху самими условиями их работы.

Теория ограничений дает также и модель для объяснения этого ограничения. Если у бизнеса есть свои внутренние ограничения, узкие места, то на его успешность влияют именно те люди, которые с этими ограничениями связаны напрямую. Эти люди и являются ключевыми для успеха бизнеса, их "стеклянный потолок" проявится только тогда, когда ограничение переедет в другое место, а это не частое явление. Как это ни прискорбно, но остальные могут сколько угодно пыжиться и стараться, от них зависит не так много.

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

Заключение

Итак какие основные выводы достигнуты?

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

Побочным выводом является то, что человека можно рассматривать как мини-бизнес и применять к нему те же подходы, что и к "настоящему" бизнесу.