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

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

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

Оставляйте проблемные задачи незавершенными; допускайте потерю функциональности

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

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

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

Я работал программным менеджером (Program Manager) в компании, которая очень успешно применяла комбинацию стратегий "Дуть в Свисток" и "Выбрасывать задачи по ходу работы". Зачастую такой подход достаточно хорошо работает для коммерческого ПО. Вам нужно периодически выпускать обновления, чтобы биржевые аналитики и акционеры оставались довольны. Досадно выпустить нечто менее амбициозное, чем вы надеялись. Тем не менее, зачастую это гораздо лучше, чем поздний выпуск продукта и потеря прибыли в текущем квартале. Если вам удастся сосредоточить внимание торговцев, аналитиков и слухов на том, что действительно было сделано, то никому за пределами компании не нужно знать, что вы собирались сделать на самом деле. Кроме того, имеется польза и для планирования будущей работы: незавершенные задачи текущего проекта становятся элементами списка задач для следующего.

Оставляйте проблемные задачи незавершенными; допускайте потерю функциональности и багов

Мы можем ограничить время выполнения задач, снизить стандарт качества и прекращать работу над задачей, как только затраченное время превышает Небольшой Сдвиг. Обычно это ведет к наличию багов или других проблем в задачах, которые при ином подходе могли бы стать Потраченными Утрами, Потерянными Днями или Гадкими Утятами. Кроме того, придется выбросить некоторое количество задач (поскольку даже Небольшой Сдвиг стоит нам одну Нормальную Задачу).

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

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

Расцепляйте задачи

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

В реальной жизни все происходит иначе. Зачастую у нас есть возможность реорганизовать задачи, поменять их приоритеты, так что когда встречается Гадкий Утенок, мы порой можем игнорировать его и заняться другими задачами. Это работает, когда наши процессы очень гибки и когда задачи не зависят друг от друга.

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

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

Замечайте проблемы и управляйте ими

Что мы можем сделать, чтобы предупредить и обнаружить проблемы, чтобы управлять ими?

Мы можем применять практики Agile, такие как работа в парах (то есть построение процесса, гарантирующего, что каждый член команды регулярно работает в паре с каждым из остальных членов команды), которые могли бы помочь с проблемой критического пути. Если каждый член команды хотя бы минимально знаком со всем проектом, то выше вероятность, что любой из них сможет работать над новой задачей, пока его текущая задача заблокирована. И наоборот, если один человек заблокирован, другие могут передать ему свои задачи или помочь с решением блокирующей проблемы.

Если у нас возникают подозрения, что текущая задача не будет завершена вовремя, мы можем внести коррективы. Это наводит на мысль о сокращении цикла обратной связи с помощью постоянных проверок и тестирования, проверки задач в процессе выполнения и наискорейшего решения проблем - чтобы не позволять задачам отодвигаться и создавать потенциально гибельные задержки. По такому критерию короткие ежедневные standup-митинги лучше длинных еженедельных статусных митингов; но работа в парах, в одном помещении и постоянное общение - еще лучше. Откладывая проверки и тестирование до появления сборок (builds) интеграционного или системного уровня, мы получаем сравнительно медленную обратную связь для низкоуровневых проблем; проверка самих низкоуровневых элементов позволяет получать информацию относительно быстро и легко.

Мы можем управлять как проектами, так и задачами, уделяя особое внимание сбору и анализу информации. Исследуйте природу сдвигов; возможно, Потраченные Утра, Потерянные Дни или Гадкие Утята возникают по какому-то общему шаблону. Может какая-то часть проекта постоянно порождает проблемы? Может последовательность выполнения проекта делает его более подверженным сдвигам? Может какие-то эксперименты или странные действия, призванные уточнить оценку, отняли все время, отведенное на задачу? Может, задержки постоянно связаны с каким-то человеком или группой людей, и проблему можно решить обучением, работой в парах или переключением на другие задачи?

Заметьте, что получение обратной связи занимает какое-то время. Митинги могут занимать время, достаточное для выполнения задачи; постоянное общение - замедлять работу. В результате нам придется изменить некоторые наши задачи (или некоторую их часть) с «работы» на «проверку работы» или «обсуждение работы»; и возможно, что некоторые Ошеломительные Успехи превратятся в Нормальные Задачи. Это недостаток. Выгода в том, что мы, возможно,  предотвратим некоторые Небольшие Сдвиги, Потраченные Утра, Потерянные Дни и Гадких Утят и превратим их в Нормальные Задачи или Ошеломительные Успехи.

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

Итак, если нам нужно управлять проектом, быстро реагировать на потенциально неконтролируемые задачи, сглаживать отклонения, используя те или иные из предложенных выше идей, то как мы можем это смоделировать, используя метод Монте-Карло? Если мы часто делаем проверки, то мы делаем меньше в рамках каждой задачи, поэтому давайте превратим Ошеломляющие Успехи (задачи, решенные за 50% запланированного времени) в Скромные Успехи (задачи, решенные за 75% отведенного времени). Мы неизбежно переоценим одни задачи и недооценим другие, так что давайте полагать, что в среднем 50 задач из ста завершаются на 25% раньше, 49 - на 25% позже. Каждого порой настигает неудача, поэтому мы оставим шанс появления одного Гадкого Утенка в проекте.

Число задач	Тип задачи	Длительность	Всего (часов)
50	Скромный успех	0.75	37.5
49	Крохотный сдвиг	1.25	61.25
1	Гадкий Утенок	16	16

И опять я выполнил 5000 смоделированных проектов.

Средний проект	114.67 часа
Минимальная длительность	92.0 часа
Максимальная длительность	204.25 часа
Проекты завершенные вовремя или раньше	1058 (21.2%)
Опоздавшие проекты	3942 (78.8%)
Опоздавшие на 50% и больше	96 (1.9%)
Опоздавшие на 100% и больше	1 (0.02%)

Вспомните, что в первом примере половина задач завершалась на 50% раньше. Сейчас половина задач завершается только на 25% раньше, но картина в целом выглядит лучше. Мы удвоили число проектов, завершившихся вовремя, а средняя длительность проекта снизилась со 124% до 114%. Отлов проблем до того, как он превратятся в Потраченные Утра или Потерянные Дни дает заметную разницу в результатах.

Замечайте проблемы и управляйте ими, плюс короткие итерации

Чем больше задач в проекте, тем больше шансов столкнуться с Гадким Утенком. Что если мы получим возможность выбирать и откажемся от крупных проектов? В сущности это идея методологии Agile, фокусирующейся на серии коротких итераций вместо единого монолитного проекта. Разбиение большого проекта на спринты позволяет получить эквивалент частых проверок состояния задач на уровне проекта.

Когда я смоделировал проект Agile с помощью метода Монте-Карло, я был поражен результатом.

Для распределения задача/длительность я использовал тот же подход, что и раньше

Число задач	Тип задачи	Длительность	Всего (часов)
50	Скромный успех	0.75	37.5
49	Небольшой сдвиг	1.25	61.25
1	Гадкий Утенок	16	16

Я уменьшил размер проекта до 20 задач. Далее, чтобы скомпенсировать уменьшение проекта, я выполнил 25000 смоделированных проектов.

Средний проект	22.94 часа
Минимальная длительность	16 часов
Максимальная длительность	66.75 часа
Проекты завершенные вовремя или раньше	12433 (49.7%)
Опоздавшие проекты	12567 (50.3%)
Опоздавшие на 50% и больше	4552 (18.2%)
Опоздавшие на 100% и больше	400 (1.6%)

Тут есть несколько интересных моментов. Мы, наконец, сумели завершить вовремя почти половину проектов! Кроме того, более 80% проектов (20443 из 25000 в моем запуске) находятся в пределах 15% от предсказанного времени - а поскольку полный проект занимает только 30 часов, отклонение этих проектов составляет только 3 часа. Это позволяет быстро корректировать курс; в модели сточасовых проектов средний проект задерживался на три дня.

Есть и еще один потрясающий результат: общее количество времени, затраченного на эти 25000 проектов (всего 500 000 задач), равно 573 410 часов. В исходной модели общее время равнялось 619 156,5 часов, что на 8% больше. В более реалистичном втором примере общее время равнялось 736 199,2 часа, что на 28% больше. Короткие итерации дают случайности меньше возможностей повлиять на каждый отдельный проект в нашей модели.

Итак, что все это означает? Чем это полезно? Давайте рассмотрим некоторые идеи в следующий раз.