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

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

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

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

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

РИСК

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

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

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