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

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

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

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

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

Риск

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