На початку цієї книжки я розповів вам історію проекту «Вартовий» у ФБР. Якщо пам’ятаєте, зовнішній підрядник витратив сотні мільйонів доларів на розробку програмного забезпечення, що не працювало. Одним з основних джерел перевищення бюджету там (та й майже в будь-якому контракті – чи йдеться про створення комп’ютерних програм, чи про літаки, чи будинки) є вартість внесення змін. Збільшення цієї вартості є, по суті, бізнес-моделлю урядових підрядників. Вони знижують ціну проекту, знаючи, що отримають свою вигоду за рахунок замовлень на внесення змін. Коли контракт підписується на багаторічний проект, усі вимоги до якого викладено в гарних на вигляд графіках, дуже спокусливо казати: «Ну, начебто все враховано». Але потім виникає потреба щось змінити, а підрядник каже: «Я роблю тільки те, під чим підписався, і не більше. Якщо ви хочете внести якісь зміни, платіть за це». Така система виставляння додаткових рахунків ставала джерелом настільки значних витрат, що компанії та агенції мусили створювати навіть спеціальні комісії для контролю за змінами. З точки зору витрат це має сенс. Обмежте кількість змін, і ви обмежите пов’язані з ними видатки.

Проте контролери не розуміють, що цим вони встановлюють систему, яка не дає людям отримати дійсно бажані речі. Вони намагаються обмежити витрати, але разом з тим обмежують навчання, інновацію та творчість. Якщо ви починаєте якийсь проект і невдовзі розумієте, що справжня цінність (20 відсотків) полягає не в характеристиках, які ви розписали, а в інших речах, що відкрилися в процесі роботи, то традиційний підхід до управління проектом не дозволить вам діяти далі. Обмежуючи зміни, він просто налаштовує на зупинку швидшого виведення в люди цінності.

До того ж, спроба «здійснювати жорсткий контроль» навіть не працює! Попри всі намагання контрольних комісій обмежити зміни, потреба в змінах часто буває настільки великою, що вони перемагають. Без змін проекти не мали б жодної цінності. Тому контрольні комісії неохоче дають на них згоду, і вартість проекту збільшується. А потім з’являється інша зміна, яку неодмінно треба внести. Отакої, ще одна. Доволі скоро проект вибивається з бюджету на мільйони доларів, запізнюючись на рік, два, а то й усі п’ять.

Ось чому я запропонував ідею так званих безкоштовних змін. У стандартному контракті з фіксованою вартістю просто зазначається, що зміни є безкоштовними. Складається перелік усіх характеристик, яких ви очікуєте. Наприклад, якщо ви виробляєте танк, вам потрібно, щоб він розвивав швидкість до 120 кілометрів на годину, робив десять пострілів на хвилину, вміщував чотирьох членів екіпажу, мав кондиціонер і т. д. – усе, що ви вважаєте за необхідне для цього танка. Розробник дивиться на цей опис і каже, що зробити такий двигун – це буде, гм, 100 балів, зарядний механізм хай буде 50, екіпаж – 5 і так далі за переліком. Наприкінці кожна характеристика матиме свій відповідник у кількості балів. Тоді клієнт, який у цьому сценарії зобов’язаний контрактом тісно співпрацювати з власником продукту, кожного спринту може повністю змінювати свої пріоритети. Будь-який пункт чи характеристика беклогу можуть бути пересунуті деінде. А як щодо нових характеристик? Жодних проблем: просто викидаєте рівноцінні характеристики з переліку завдань. О, тепер ви хочете лазерну систему наведення? Добре, це буде 50 балів роботи – для компенсації цього доповнення викиньмо на 50 балів низькопріоритетних характеристик із нижньої частини беклогу.

Деякі компанії вивели цю ідею на новий рівень, надаючи клієнтам лише високопріоритетні опції. Кілька років тому я почув про одну фірму, де використовують систему Scrum, яка отримала 10-мільйонний контракт на розробку програмного забезпечення для великої будівельної компанії. Обидві сторони погодилися на строк у двадцять місяців. Однак компанія-розробник вставила в контракт пункт, що якщо будівельна фірма захоче розірвати його в будь-який час, то може це зробити, сплативши лише 20 відсотків вартості решти контракту. Фактично, якщо програмне забезпечення працювало так, як хотіли будівельники, вони могли зупинити Scrum-команду, щоб та більше нічого не робила.

Розробники програмного забезпечення почали спринти, які тривали в них по місяцю. Після першого місяця клієнт переспрямував деякі зусилля розробників на отримання більшої цінності. Другий місяць – те саме. Після третього місяця клієнт розірвав контракт, забрав програмне забезпечення та запустив його в роботу. Він отримав цінність, якої потребував.

Давайте тепер трохи порахуємо, щоб побачити, як від цього виграли всі. У перші три місяці контракту будівельники заплатили Scrum-команді 1,5 мільйона доларів. Дострокове розірвання контракту вимагало від них сплатити 20 відсотків від решти суми у 8,5 мільйона, що склало 1,7 мільйона доларів. Тобто вони заплатили 3,2 мільйона доларів за частину програмного забезпечення, яке вважали вартим 10 мільйонів, і отримали його на сімнадцять місяців раніше.

При цьому вони були аж ніяк не єдиними, хто залишився у виграші. Scrum-компанія підписала контракт, від якого очікувала отримати 15 відсотків чистого прибутку. Тому в ці перші три місяці вони витратили на розробку 1,3 мільйона доларів. Але отримали вони 3,2 мільйона. Їхній чистий прибуток зріс із 15 до 60 відсотків, а це – 400-відсоткове збільшення доходів. І тепер, звільнившись від проекту, вони могли взятися за інші. Це не просто вигідна угода. Це стратегія дострокового заробляння собі на пенсію.

Вони змогли зробити це завдяки особливостям роботи Scrum. Керуючи собою як багатофункціональним підрозділом, команда зуміла швидко прискоритись, принісши більшу цінність за менший час. Наприкінці кожного спринту спостерігалося чергове покращення базового продукту. Він працював. Його можна було застосувати відразу. У кожному спринті власник продукту мав можливість змінити пріоритети беклогу на підставі відгуку клієнта. А коли для клієнта було створено достатню цінність, усі припинили роботу. Таким чином, Scrum синхронізує інтереси всіх учасників процесу: команди, Scrum-майстра, власника продукту, клієнта і компанії. Усі працюють над досягненням спільної мети та зі спільним баченням: створити справжню цінність якнайшвидше. Я щиро вірю в ситуації виграшу для всіх, і можливість заробити більше грошей створенням кращих продуктів за нижчою ціною здається мені дуже навіть непоганою угодою.

В основі будь-якого успішного проекту лежить управління ризиками. Scrum дозволяє вам суттєво зменшити ризик провалу. Трьома найпоширенішими різновидами тут є ринковий, технічній та фінансовий ризики. Щоб було зрозуміліше, треба відповісти на три питання. Чи хочуть люди те, що ми робимо? Чи дійсно ми можемо це зробити? Чи дійсно ми можемо продати зроблене?

Про ринковий ризик я писав уже не раз. Scrum допомагає вам мінімізувати його, просуваючи ідею поетапної здачі проекту. Він дозволяє вам скоріше представляти продукт клієнтам. Отримуючи ж ранні й часті відгуки, ви можете вносити невеликі зміни відразу, а не опинятися потім перед необхідністю великих змін після того, як вкладете в проект мільйони доларів і зрозумієте, що зробили зовсім не те, чого насправді хоче клієнт. Дуже часто саме про цю річ клієнт казав на початку процесу, але в реальності люди не знають, чого насправді хочуть, доки не зможуть щось випробувати. Багато ділових порад обертаються навколо швидкого провалу, який допоможе виявити слабкі місця. Мені ж більше подобається ідея швидкого представлення проекту клієнтам.

Технічній ризик цікавий. Питання, чи дійсно можливо зробити те, чого хоче клієнт, доволі непросте. Особливо якщо мова йде про щось матеріальне, що потребує заводів, інструментів та інвестицій.

Пам’ятаєте компанію, що виробляла систему побутової автоматики? Так от, вони підійшли до цього, озброївшись так званою «комплексною конкурентною розробкою». Простою мовою це означає створення кількох різних прототипів, щоб виявити, який з них працює найкраще, перш ніж запускати серійне виробництво. Наприклад, вони знали, що їм потрібна така відеокамера, щоб клієнти бачили, хто стукає до них у двері, і могли впустити бажаних гостей. Найдорожчою частиною цієї камери, яка до того ж вимагала найбільше часу на підготовку, була лінза. Зробити її з пластику? Скла? Кришталю? Який матеріал витримає будь-які погодні умови? Який буде легко дряпатись? Який дасть найчіткішу картинку? Скільки кожен із них коштуватиме у виробництві?