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

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

Когда заключается контракт на многолетний про­ект и все требования отображаются в тех самых симпатичных диаграммах и таблицах, так и хочется сказать: «Ну вот, это должно все покрыть». Потом подрядчик говорит: «Я согласен выполнить это, и только это. Если вы захотите что-то изменить, это будет стоить отдельно». Такого рода выставление счетов задним чис­лом стало причиной столь масштабных расходов, что компаниям и агентствам пришлось создать органы контроля за внесением из­менений. С точки зрения расходов это вполне осмысленно.[372]

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

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

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

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

Некоторые компании вывели на новый уровень эту идею соз­дания для клиента только высокоприоритетных функций. Пару лет назад я услышал о компании-разработчике, применявшей Scrum, которая получила контракт по разработке программ­ного обеспечения для крупной строительной компании на десять миллионов долларов. Стороны договорились о временных рам­ках в двадцать месяцев. Однако компания добавила в контракт примечание, гласившее: «Если строительная фирма захочет при­остановить контракт в любой момент — а по договору она имела на это право, — в таком случае ей нужно будет выплатить лишь 20 процентов от остающейся стоимости контракта. То есть если программное обеспечение работало так, как нужно заказчику, он мог в любой момент остановить работу скрам-команды. Раз­работчики начали спринты длиной в один месяц. После первого месяца клиент перенаправил часть усилий разработчика, чтобы получить большую ценность. Во второй месяц ситуация повто­рилась. После третьего месяца клиент приостановил контракт, внедрил программное обеспечение и начал с ним работать. Они получили ту ценность, которая была им нужна.[375]

Давайте посчитаем, чтобы увидеть, кто остался в выигрыше. На самом деле и заказчик, и исполнитель. За первые три ме­сяца контракта клиент заплатил команде полтора миллиона долларов. Приостановив контракт раньше времени, он обязан был выплатить 20 процентов от остававшихся 8, 5 миллиона — это 1, 7 миллиона. Заказчик заплатил 3, 2 миллиона долларов за программное обеспечение, которое, по его ожиданиям, должно было обойтись в десять миллионов долларов, а исполнитель по­лучил свои деньги на семь месяцев раньше.[376]

И они были не единственными, кто остался в выигрыше: компания взялась за проект с ожидаемой маржей прибыли в 15 процентов. Поэтому за первые три месяца на разработку они потратили 1, 3 миллиона долларов. Но в результате по­лучили 3, 2 миллиона долларов. Их маржа прибыли выросла с 15 до 60 процентов. То есть увеличение дохода на 400 процен­тов. К тому же теперь, когда разработчики освободились, они могут браться за новые проекты. Это не просто хороший бизнес. Это стратегия раннего выхода на пенсию.

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

Риск

Управление рисками лежит в основе любого успешного предпри­ятия. Методология Scrum позволяет вам снизить риск неудачи. Три наиболее распространенных типа рисков: рыночный, техни­ческий и финансовый. Проще говоря, хотят ли люди то, что мы делаем? Можем ли мы на самом деле создать это? Можем ли мы продать то, что создали? [377]

Я много писал о рыночном риске. Scrum помогает его миними­зировать за счет того, что делает упор на пошаговую сдачу про­дукта. Это позволяет вам быстрее предоставить клиенту продукт. А благодаря ранней и частой обратной связи вы можете вносить небольшие изменения на месте, вместо того чтобы кардинально менять продукт после того, как вы уже инвестировали в его соз­дание миллионы долларов и поняли, что делаете совсем не то, что хочет заказчик. Встречаются ситуации, когда клиент, по его собственным словам, хотел в начале рабочего процесса один на­бор функций, но потом изменил свое решение. Люди довольно часто не знают сами, что им действительно нужно, пока не ис­пробуют продукт в деле. Огромное количество советов из обла­сти бизнеса связано с ситуациями быстро приближающегося про­вала. Я предпочитаю думать о том, как быстрее создать продукт.

Технический риск создает порой интересные ситуации. На­сколько в принципе возможно создать то, что хочет получить клиент? Вопрос непростой, особенно если вы создаете продукт, требующий физических затрат, заводского оборудования, спе­циальных инструментов и предварительного финансирования.

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

Вместо того чтобы принимать решение заранее и в полную силу заниматься производством, они сделали три разные полно­стью функциональные линзы и сравнили их.[378] Так как они только пытались разобраться с линзами, что было для них первоочеред­ной задачей из-за долгого периода освоения новой продукции, они тестировали каждую линзу при помощи настроек камеры от но­утбука.[379] Оказалось, стекло по всем критериям подходит идеально. Самое важное, что оценка была дана после того, как все увидели реальную работу над камерой. Выбор не основывался на теоре­тических построениях. У команды были разработаны реальные варианты, использованы реальные подходы, выбраны реальные материалы — результат все могли посмотреть и даже потрогать. Найдя ответ на этот вопрос, они смогли перейти к созданию кор­пуса, в котором будет установлена линза, и процессоров, которые будут обрабатывать изображение. Выбрав в качестве приоритет­ного решение вопроса с линзой, компания сэкономила миллионы. Как известно, Apple поступает так со всеми своими продуктами, зачастую создавая не меньше десятка полностью рабочих прототипов, прежде чем сделать окончательный выбор в пользу луч­шего. Это позволяет оперативно апробировать различные идеи без привлечения крупных инвестиций.

Для компаний именно финансовый риск чаще всего стано­вится причиной неудач. Компания создала довольно привле­кательный продукт, но не в состоянии продать его по цене, ко­торая принесет прибыль. Классический пример — онлайновые версии газет и журналов. Когда в 1990-е годы только начинался интернет-бум, газеты стремились разместить свой контент в Сети. Некоторые главные редакторы понимали, что в принципе независимо от версии их продукции — онлайновой или бумаж­ной — люди все равно будут платить за размещение рекламы. Поэтому доступ к контенту они сделали бесплатным. Проблема обнаружилась быстро. Рекламодатели оказались не готовы пла­тить такие же деньги за онлайновую версию, как за печатную. Но стоимость создания контента оставалась такой же. Посте­пенно кто-то пытался сделать контент платным, но они потер­пели фиаско — в Сети было слишком много бесплатных сайтов с новостями. Отправлять репортеров на места, чтобы видеть со­бытия своими глазами, — удовольствие довольно дорогое. Ре­зультат налицо — по всей стране закрываются новостные отделы.[380]

Среди технических стартапов и по сей день превалирует идея предоставлять контент или сервис бесплатно, а деньги за­рабатывать за счет рекламы.[381] Молодые предприниматели, глядя на Facebook или Google, думают, что и они так смогут. Проблема лишь в том, что компаний, подобных Facebook и Google, не очень много. На заре интернета, когда в онлайн-пространстве компа­нии впервые смогли обратиться к конкретным целевым группам, такая «гиперфокусировка» высоко ценилась. Но по мере того как появлялось все больше платформ, на которых это можно было осуществлять, темпы расширения возможностей не ускорялись.

Еще один путь, приводящий компании к финансовому краху, — переплата за привлечение клиентов. Яркий пример представляют купонные компании, такие как Groupon и Living Social. Поначалу они быстро и легко привлекали новых клиен­тов. Но по мере того как их зона охвата расширялась и росло ко­личество клиентов, привлекать новых рекламодателей и людей, желавших купить купон, становилось все труднее. Результат вы можете видеть в оценках этих компаний.

Методология Scrum полезна бизнесу тем, что быстро отвечает на вопрос: сможем ли мы заработать деньги, если сделаем то или иное? Если быстро предлагать клиенту пошаговые релизы, вы узнаете, что ценят ваши клиенты и за что они готовы платить. Но если ваши первые предположения оказались ошибочными, вы можете быстро внести изменения. Максимум, чем вы риску­ете, — временем и собственными силами. Согласитесь, это мало напоминает многомиллионные расходы на огромные и сложные инфраструктуры, сотворив которые вы тут же обнаруживаете: людям нравится ваш продукт, но не до такой степени, чтобы пла­тить за него ту цену, в которую обошлось его создание.