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

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

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

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

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

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

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

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

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

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

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

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