Джефф Сазерленд - Scrum. Революционный метод управления проектами

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

ДЕНЬГИ НИ ЗА ЧТО И ИЗМЕНЕНИЯ БЕСПЛАТНО

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

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

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

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

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

Вот почему я выступил с идеей бесплатных изменений. В стандартном контракте с фиксированной стоимостью мы просто прописываем бесплатные изменения. Составьте список всех функций, которые вы хотите получить. Например, вы создаете новый танк и хотите, чтобы он двигался со скоростью 120 километров в час, давал десять залпов в минуту, в нем должно быть четыре посадочных места, кондиционер и многое другое. Разработчик смотрит на это описание и говорит, что сделать такой двигатель — это сто баллов, заряжающий механизм — пятьдесят баллов, посадочные места — пять баллов и так далее по всему списку. В конце каждой функции будет присвоено некоторое количество баллов. И потом после каждого спринта клиент, который при таком сценарии по контракту обязан тесно сотрудничать с владельцем продукта, может полностью менять свои приоритеты. Любой объект, любая функция в бэклоге могут быть передвинуты куда угодно. А новые функции? Никаких проблем: просто выбрасываем из списка другую функцию, оцененную в аналогичное количество баллов. Теперь хотите систему с лазерным наведением? Это будет пятьдесят баллов работы — чтобы компенсировать данную прибавку, давайте откажемся от маловажных функций из нижней части бэклога общей суммой на пятьдесят баллов.