Scrum. Революционный метод управления проектами

Мне это напоминает истории, которые рассказывают вернувшиеся из Ирака или Афганистана. Американские военные входят в поселок, оглядывают окрестности и говорят: «Эти люди разводят кур. Давайте построим им завод по переработке куриного мяса». Они тратят миллионы долларов на завод, оснащенный по последнему слову техники, не задумываясь, что в поселке отсутствует бесперебойная подача электричества, что местные жители в большинстве своем неграмотны и будет непросто обучить их работать с оборудованием. Находится человек, который догадывается спросить у жителей поселка: «А что на самом деле вам помогло бы выжить?» Ему отвечают: «Знаете, вот пешеходный мост через реку не помешал бы, а то тратим по полдня на дорогу до ближайшей переправы, когда идем на базар». Этот пешеходный мост стоит пару сотен долларов. Выглядит он куда менее внушительно, нежели большой завод. И звучит не слишком впечатляюще, когда вы рассказываете о нем своему начальству в Вашингтоне. Но для тех деревенских жителей это действительно гораздо ценнее, чем модная постройка с ржавеющим оборудованием внутри.

Еще один момент, который стоит обсудить, – это раньше срока завершенный проект. Скажем, вы делаете будильник нового поколения для Alarm Clock. У вас список из многих десятков характеристик: часы, кнопка сброса, таймер, громкий сигнал, радио, док-станция для iPhone, GPS – да мало ли что еще. Но будучи здравомыслящим владельцем продукта, вы расставляете приоритеты в соответствии с тем, что люди на самом деле хотят: будильник, который легко устанавливается, достаточно громкий, с радио и хорошим ярким дисплеем, который будет видно независимо от того, светло в комнате или темно. Когда ваша команда его создала, вы понимаете, что это самый элегантный будильник из когда-либо существовавших. Настоящий Apple iPod среди будильников. Он красив и свою основную функцию выполняет весьма качественно. Вместо того чтобы поручать команде работать над дополнительными функциями, вы выпускаете этот будильник и начинаете работу над новым проектом. Команда может произвести больше ценности, работая над чем-нибудь другим.

Деньги ни за что и изменения бесплатно

В начале книги я рассказывал историю проекта «Страж» в ФБР. Если вы помните, привлеченный подрядчик потратил сотни миллионов долларов, чтобы создать программное обеспечение, которое не работало.

И в случае с ФБР, и в большинстве ситуаций с другими подрядчиками – будь то в области разработки программного обеспечения, самолетостроении или строительстве – одной из главных причин перерасхода денежных средств, выделенных из бюджета, являются штрафы за внесение изменений. Увеличение сумм таких штрафов – это бизнес-модель, которой пользуется большинство подрядчиков в государственных контрактах. Они дают низкую цену за проект, понимая, что выиграют за счет штрафов за изменения. Когда заключается контракт на многолетний проект и все требования отображаются в тех самых симпатичных диаграммах и таблицах, так и хочется сказать: «Ну вот, это должно все покрыть». Потом подрядчик говорит: «Я согласен выполнить это, и только это. Если вы захотите что-то изменить, это будет стоить отдельно». Такого рода выставление счетов задним числом стало причиной столь масштабных расходов, что компаниям и агентствам пришлось создать органы контроля за внесением изменений. С точки зрения расходов это вполне осмысленно.

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

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

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