Ознакомительная версия. Доступно 14 страниц из 69
Мне это напоминает истории, которые рассказывают вернувшиеся из Ирака или Афганистана. Американские военные входят в поселок, оглядывают окрестности и говорят: «Эти люди разводят кур. Давайте построим им завод по переработке куриного мяса». Они тратят миллионы долларов на завод, оснащенный по последнему слову техники, не задумываясь, что в поселке отсутствует бесперебойная подача электричества, что местные жители в большинстве своем неграмотны и будет непросто обучить их работать с оборудованием. Находится человек, который догадывается спросить у жителей поселка: «А что на самом деле вам помогло бы выжить?» Ему отвечают: «Знаете, вот пешеходный мост через реку не помешал бы, а то тратим по полдня на дорогу до ближайшей переправы, когда идем на базар». Этот пешеходный мост стоит пару сотен долларов. Выглядит он куда менее внушительно, нежели большой завод. И звучит не слишком впечатляюще, когда вы рассказываете о нем своему начальству в Вашингтоне. Но для тех деревенских жителей это действительно гораздо ценнее, чем модная постройка с ржавеющим оборудованием внутри.
Еще один момент, который стоит обсудить, – это раньше срока завершенный проект. Скажем, вы делаете будильник нового поколения для Alarm Clock. У вас список из многих десятков характеристик: часы, кнопка сброса, таймер, громкий сигнал, радио, док-станция для iPhone, GPS – да мало ли что еще. Но будучи здравомыслящим владельцем продукта, вы расставляете приоритеты в соответствии с тем, что люди на самом деле хотят: будильник, который легко устанавливается, достаточно громкий, с радио и хорошим ярким дисплеем, который будет видно независимо от того, светло в комнате или темно. Когда ваша команда его создала, вы понимаете, что это самый элегантный будильник из когда-либо существовавших. Настоящий Apple iPod среди будильников. Он красив и свою основную функцию выполняет весьма качественно. Вместо того чтобы поручать команде работать над дополнительными функциями, вы выпускаете этот будильник и начинаете работу над новым проектом. Команда может произвести больше ценности, работая над чем-нибудь другим.
Деньги ни за что и изменения бесплатно
В начале книги я рассказывал историю проекта «Страж» в ФБР. Если вы помните, привлеченный подрядчик потратил сотни миллионов долларов, чтобы создать программное обеспечение, которое не работало.
И в случае с ФБР, и в большинстве ситуаций с другими подрядчиками – будь то в области разработки программного обеспечения, самолетостроении или строительстве – одной из главных причин перерасхода денежных средств, выделенных из бюджета, являются штрафы за внесение изменений. Увеличение сумм таких штрафов – это бизнес-модель, которой пользуется большинство подрядчиков в государственных контрактах. Они дают низкую цену за проект, понимая, что выиграют за счет штрафов за изменения. Когда заключается контракт на многолетний проект и все требования отображаются в тех самых симпатичных диаграммах и таблицах, так и хочется сказать: «Ну вот, это должно все покрыть». Потом подрядчик говорит: «Я согласен выполнить это, и только это. Если вы захотите что-то изменить, это будет стоить отдельно». Такого рода выставление счетов задним числом стало причиной столь масштабных расходов, что компаниям и агентствам пришлось создать органы контроля за внесением изменений. С точки зрения расходов это вполне осмысленно.
Ограничьте масштабы изменений, и вы ограничите связанные с ними расходы. Счетоводы никак не могут постичь, что они создают систему, мешающую людям получить желаемый продукт. Подрядчики, пытаясь уменьшить расходы, на самом деле ограничивают процесс получения опыта, инновации и творчество. Если вы запускаете проект и понимаете через какое-то время, что истинная ценность, 20 процентов, находится не в тех характеристиках, которые вы зафиксировали на бумаге, – традиционный подход управления проектом предполагает, что вас нужно остановить. Он устроен таким образом, чтобы не допустить более быстрого создания ценности.
К тому же попытка осуществлять жесткий контроль совершенно не дает результатов! Даже при наличии органа контроля за внесением изменений, пытающегося эти изменения ограничить, потребность в них настолько велика, что изменения одерживают верх. Не будь изменений, проект не имел бы ценности. И тогда контролирующий орган стиснув зубы дает добро – и проект увеличивается в цене.
А потом возникает следующее изменение, которое необходимо внести. Затем еще одно. И очень скоро проект уже на пару миллионов долларов превышает бюджет, опаздывая на год, на два, на пять.
Вот почему я выступил с идеей бесплатных изменений. В стандартном контракте с фиксированной стоимостью мы просто прописываем бесплатные изменения. Составьте список всех функций, которые вы хотите получить. Например, вы создаете новый танк и хотите, чтобы он двигался со скоростью 120 километров в час, давал десять залпов в минуту, в нем должно быть четыре посадочных места, кондиционер и многое другое. Разработчик смотрит на это описание и говорит, что сделать такой двигатель – это сто баллов, заряжающий механизм – пятьдесят баллов, посадочные места – пять баллов и так далее по всему списку. В конце каждой функции будет присвоено некоторое количество баллов. И потом после каждого спринта клиент, который при таком сценарии по контракту обязан тесно сотрудничать с владельцем продукта, может полностью менять свои приоритеты. Любой объект, любая функция в бэклоге могут быть передвинуты куда угодно. А новые функции? Никаких проблем: просто выбрасываем из списка другую функцию, оцененную в аналогичное количество баллов. Теперь хотите систему с лазерным наведением? Это будет пятьдесят баллов работы – чтобы компенсировать данную прибавку, давайте откажемся от маловажных функций из нижней части бэклога общей суммой на пятьдесят баллов.
Некоторые компании вывели на новый уровень эту идею создания для клиента только высокоприоритетных функций. Пару лет назад я услышал о компании-разработчике, применявшей Scrum, которая получила контракт по разработке программного обеспечения для крупной строительной компании на десять миллионов долларов. Стороны договорились о временных рамках в двадцать месяцев. Однако компания добавила в контракт примечание, гласившее: «Если строительная фирма захочет приостановить контракт в любой момент – а по договору она имела на это право, – в таком случае ей нужно будет выплатить лишь 20 процентов от стоимости остающейся стоимости контракта. То есть если программное обеспечение работало так, как нужно заказчику, он мог в любой момент остановить работу скрам-команды. Разработчики начали спринты длиной в один месяц. После первого месяца клиент перенаправил часть усилий разработчика, чтобы получить большую ценность. Во второй месяц ситуация повторилась. После третьего месяца клиент приостановил контракт, внедрил программное обеспечение и начал с ним работать. Они получили ту ценность, которая была им нужна.
Давайте посчитаем, чтобы увидеть, кто остался в выигрыше. На самом деле и заказчик, и исполнитель. За первые три месяца контракта клиент заплатил команде полтора миллиона долларов. Приостановив контракт раньше времени, он обязан был выплатить 20 процентов от остававшихся 8,5 миллиона – это 1,7 миллиона. Заказчик заплатил 3,2 миллиона долларов за программное обеспечение, которое, по его ожиданиям, должно было обойтись в десять миллионов долларов, а исполнитель получил свои деньги на семь месяцев раньше.
Ознакомительная версия. Доступно 14 страниц из 69
