М.Болтон: Оценка проекта и Черные Лебеди. Часть 1.

Вольный перевод статьи Майкла Болтона Project Estimation and Black Swans (Part 1)

В последние месяцы в сети активно обсуждалось оценивание:

• Ward Cunningham написал в твиттере: "Оценивание - выдуманная проблема, на решение которой профан тратит десятки дней"
• Pradeep Soundararajan опубликовал в блоге развернутую статью, посвященную оценке затрат на тестирование.
• Некто, назвавшийся Nathaniel'ем, изложил интересную точку зрения на успешные оценки на сайте Terralien.
• Jens Schauder опубликовал 8 причин, почему оценки слишком низки.
• Andre Dhondt недавно подключился к спору со статьей “Оценки ведут к убыткам, резервы приносят пользу”. (Вообще-то я не согласен. Резервы не приносят пользу, а вносят некоторый вклад в создание благоприятных условий, позволяющих создать нечто полезное. Достаточное количество резервов позволяет снизить угрозы.)

Все это сподвигло меня опубликовать результаты некоторых численных экспериментов, начатых в ноябре 2009-го и основанных на мысленном эксперименте, придуманном Джеймсом Бахом (James Bach). Эта работа совпадает по времени с Лебединой Песней, колонкой для Better Software, в которой я обсуждал книгу Талеба (Nassim Nicholas Taleb) "Черный Лебедь".

Черный Лебедь - невероятное и неожиданное событие, меняющее наше представление о реальности и обладающее тремя качествами. 

Во-первых, оно застает нас врасплох, обычно от того, что не описывается нашими моделями. Талеб пишет, "Модели и конструкции, эти мысленные карты реальности, не всегда неверны; они неверны только в некоторых случаях. Проблема в том, что а) вы не знаете заранее (а только по наступлении факта), в чем карта неверна и б) последствия ошибки могут быть суровыми. Эти модели похожи на экспериментальную медицину, которая иногда помогает, но очень часто влечет серьезные побочные эффекты."

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

В-третьих, после Черного Лебедя люди склонны говорить, что они предполагали его приход. Такие заявления звучат после события и обусловлены парой взаимосвязанных когнитивных ошибок (ошибок познания). Первую Талеб называет эпистемиологической самонадеянностью, преувеличенным представлением о том, что мы знаем. Вторая - это искажение нарратива, наша склонность рассказывать и воспринимать истории в соответствии с нашими представлениями о нашем знании, без проверки связей между причиной и результатом. Легко считать, что мы знаем важные факторы истории, когда нам известно, чем кончилось дело. Первая Мировая Война была Черным Лебедем; 11е сентября 2001го года было Черным Лебедем; землетрясения на Гаити, вулкан в Исландии, разрушение нефтяной платформы в Мексиканском заливе были Черными Лебедями. Взлет цены на акции Google после выхода этой компании на биржу тоже был Черным Лебедем. (Возможно, вы встречали людей, заявляющих, что они знали заранее о будущем резком росте акций. Если бы это было правдой, они бы купили акции и стали богаты. Если они не богаты, это проявление искажения нарратива)

Думаю, одна из причин, по которой проекты не укладываются в оценки, заключается в том, что мы от природы не учитываем влияние Черных Лебедей. Джеймс предложил мне мысленный эксперимент, иллюстрирующий некоторые интересные проблемы оценивания.

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

Кроме того, предположим, что ваша оценка была очень осторожной, и половина задач (т.е. 50) были завершены за тридцать минут вместо часа. Назовем такие задачи Ошеломляющим Успехом. 35% задач выполнены за отведенное время; назовем их Нормальными Задачами.

В 15% случаев вам не везет.

• Восемь задач занимают два часа вместо одного. Давайте назовем их Небольшой Сдвиг.
• Четыре задачи (одна из 25ти) заканчиваются через 4 часа вместо одного, как вы предполагали. Проявился баг в какой-то чужой библиотеке, которую вы используете; вам нужен доступ на какой-то сервер, а IT департамент слишком занят и отвечает только после обеда. Такую задачу мы назовем Потраченное Утро.
• Две задачи (одна из пятидесяти) занимают целый день вместо часа. Кто-то должен остаться дома с больным ребенком. Их мы назовем Потерянный День.
• Одна задача из ста - только одна - занимает два дня вместо часа. Другая команда задерживает разработку библиотеки на пару дней; поломка жесткого диска обрушила систему, а резервная копия оказалась испорченной; одной из программисток удалили зуб мудрости (все эти вещи случались в проектах, где я работал). Эти события не обладают разрушительной силой Черных Лебедей; они больше похожи на детей Черного Лебедя, поэтому давайте звать их Гадкими Утятами.

Число задач	Тип задачи	Длительность	Всего (часов)
50	Ошеломляющий успех	0.5	25
35	Нормальная задача	1	35
8	Небольшой сдвиг	2	16
4	Потраченное утро	4	16
2	Потерянный день	8	16
1	Гадкий Утенок	16	16
100			124

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

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

Я создал небольшую программу на Ruby, генерирующую результаты таких сценариев. Скрипт выполняет N проектов (состоящих из M задач каждый), позволяет мне указать произвольное число вероятностей и длительностей для задач, сохраняет результаты в таблицу Excel и создает графики для этих результатов. (Естественно, пока я занимался этим проектом, я нашел и починил тонну багов в моем коде. Но помимо этого я нашел баги в Excel'е, включая обрушения, вследствие состояния гонки (race condition), проблемы с производительностью API и просто недостаточную документацию. Разве тестирование - это не интересно?) Для описанного выше сценария я выполнил 5000 проектов, каждый из которых состоял из 100 случайных задач. Я получил следующие результаты, основанные на  указанных выше числах:

Средний проект	123.83 часа
Минимальная длительность	74.5 часа
Максимальная длительность	217 часов
Проекты завершенные вовремя или раньше	460 (9.2%)
Опоздавшие проекты	4540 (90.8%)
Опоздавшие на 50% и больше	469 (9.8%)
Опоздавшие на 100% и больше	2 (0.9%)

  

  

Несколько интересных вещей, которые я заметил:

• Средний проект занимает 123.83 часов, почти на 25% больше, чем мы оценивали
• 460 проектов (или меньше 10%) завершились вовремя или раньше срока!
• 4540 проектов (или более 90%) завершились с опозданием!
• Вам может повезти. В моем запуске три проекта завершились за 80 часов и меньше. Ни один из проектов не избежал какого-либо Потраченного Утра, Потерянного Дня или Гадкого Утенка. Ни один из пяти тысяч.
• Кроме того, вам может не повезти. 469 проектов заняли, по меньшей мере, в полтора раза больше времени, чем планировалось. Два проекта заняли более чем вдвое больше времени. Наконец, один очень несчастливый проект содержал четыре Потраченных Утра, один Потерянный День и восемь Гадких Утят. Этот проект занял 217 часов.

Это может показаться парадоксальным результатом. Половина задач занимает только половину времени, отведенного для их выполнения. 85% задач завершается вовремя или раньше. Только 15% задерживаются. Имеется всего один шанс из сотни встретить Гадкого Утенка. Как вышло, что так мало проектов завершилось вовремя?

Ответ в асимметрии, еще одном элементе модели Черного Лебедя, созданной Талебом. Делая оценки, легко ошибиться, работая, скажем, с множителем 2. Так, деление длительности задачи на два имеет совершенно иное влияние, чем умножение длительности на два. Маленькая Победа сохраняет только половину Нормальной Задачи, в то время как Небольшой Сдвиг стоит две Нормальные Задачи.

Предположим, что вы очень хорошо делаете оценки, и что вы не так часто ошибаетесь. 20% задач завершаются на 10% раньше (назовем их Маленькими Победами). 65% задач выполняются точно вовремя (Нормальные Задачи). То есть, 85% ваших оценок точны или слишком осторожны. Как и раньше, вы имеете восемь Небольших Сдвигов, четыре Потраченных Утра, два Потерянных Дня и Гадкого Утенка.

Имея 20% задач, завершающихся раньше срока и 15% - позже, как бы вы оценили длительность среднего проекта?

  

Число задач	Тип задачи	Длительность	Всего (часов)
20	Небольшая победа	0.9	18
65	Нормальная задача	1	65
8	Небольшой сдвиг	2	16
4	Потраченное утро	4	16
2	Потерянный день	8	16
1	Гадкий Утенок	16	16
100			147

Хотя ваши оценки даже более точны, чем в первом примере, средний проект завершается на 47% позже. То есть вы полагаете, что он займет две с половиной недели, а на самом деле, судя по всему, потребуется более трех с половиной недель. Напомню, это в среднем, и вновь основано на вероятности. Как и ранее, не каждый проект столкнется с невезением, а некоторые проекты будут более невезучими, чем остальные. Я вновь выполнил 5000 проектов, состоящих из ста задач каждый.

Средний проект	147.24 часа
Минимальная длительность	105.2 часа
Максимальная длительность	232 часа
Проекты завершенные вовремя или раньше	0 (0.0%)
Опоздавшие проекты	5000 (100.0%)
Опоздавшие на 50% и больше	2022 (40.4%)
Опоздавшие на 100% и больше	30 (0.6%)

  

Ни один из 5000 проектов не завершился вовремя. Лучший из проектов опоздал на 5%. Он содержал 18 Маленьких Побед, 77 Нормальных Задач, 4 Небольших Сдвига и Потраченное Утро. Этот проект счастливо избежал Потерянных Дней и Гадких Утят. И, будучи близким к запланированному времени, он был чрезвычайно редким. На самом деле, только 16 проектов из 5000 задержались менее чем на 10%.

Это чисто математические модели. Они игнорируют все, что свойственно самосознающим (self-aware) системам, способы взаимодействия и влияния между системами и их участниками. Единственный использованный здесь вид активности по управлению проектами - моделирование и оценка задач в виде одночасовых кусков. Все, что происходило после этого, сводится к случайности и удаче. Мне кажется, метод Монте-Карло показывает, что при отсутствии управления малое, на наш взгляд, количество сюрпризов и неполадок может иметь большое влияние.

Заметьте, что в обоих примерах, по меньшей мере, 85% задач завершались вовремя или даже раньше. Не больше чем 15% задач опаздывали. Это асимметрия влияния запаздывающих задач, приводящая к задержке подавляющего большинства проектов. Задача, занимающая одну шестнадцатую запланированного времени сохраняет менее одной Нормальной Задачи, а стоимость Гадкого Утенка превышает пятнадцать Нормальных Задач. Комбинация математики и неожиданности безжалостна к вам. Чтобы обойти проблему, вам придется управлять чем-то. Какие стратегии возможны? Об этом поговорим завтра.