Читати книгу - "Scrum"

навколо й кажуть: «Ці люди розводять курей. Збудуймо їм завод із переробки курятини». Отже, вони витрачають мільйони доларів на будівництво ультрасучасного заводу. Вони не зважають, що в тому районі майже відсутня регулярна подача електрики чи що місцеві мешканці переважно неписьменні, тож навчитися працювати зі спеціальним обладнанням їм зовсім нелегко. Через деякий час хтось із американців нарешті звертає на це увагу, іде до селян і питає: «Що б вам дійсно допомогло?» І чує у відповідь: «Ви знаєте, було б просто чудово спорудити пішохідний міст через річку, бо по дорозі на ринок нам доводиться витрачати половину дня, щоб дістатися до найближчої переправи». Що тут скажеш? Пішохідний міст коштує кількасот доларів. Він справляє значно менше враження, ніж великий завод. У розмові з вашими босами у Вашингтоні якийсь там міст звучить зовсім не круто. Але для цих селян він однозначно цінніший за чудернацьку будівлю з дивними машинами, що тепер стоять та іржавіють без діла.

Також варто робити те, що ви можете завершити в короткі строки. Скажімо, ви виготовляєте суперовий будильник наступного покоління. Ви маєте перелік із десятків характеристик: годинник, кнопка «повторити згодом», таймер, гучний сигнал, радіо, станція для айфона, навігатор тощо. Але як кмітливий власник продукту ви робите пріоритетним те, чого люди дійсно хочуть: будильник, який легко виставляти, з достатньою гучністю, радіо та яскравим екраном, який добре видно навіть при світлі. І коли ваша команда із цим закінчує, ви розумієте, що насправді вони створили найкращий будильник усіх часів. Це просто айпод серед будильників. Він гарний і робить одну річ дійсно дуже добре. Замість того щоб змушувати вашу команду вбудовувати в нього додаткові опції, ви випускаєте цей будильник на ринок і починаєте працювати над наступним проектом. Команда може принести більше цінності, зайнявшись чимось іншим.

Гроші ні за що та безкоштовні зміни

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

Проте контролери не розуміють, що цим вони встановлюють систему, яка не дає людям отримати дійсно бажані речі. Вони намагаються обмежити витрати, але разом з тим обмежують навчання, інновацію та творчість. Якщо ви починаєте якийсь проект і невдовзі розумієте, що справжня цінність (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 мільйона доларів. Але отримали вони