Scrum. Навчись робити вдвічі більше за менший час - Джефф Сазерленд 34 стр.


Випуск

Отже, пріоритети розставлено. Ви знаєте, у чому полягають 80 відсотків цінності. Коли ж ви випустите ваш продукт? І тут Scrum допоможе досягти результату набагато швидше. Коли і що б ви не робили, вам потрібно передати це в руки безпосередніх користувачів якомога швидше. Зробити це потрібно навіть до того, як будуть готові 20 відсотків характеристик. Достатньо буде й чогось, що нестиме в собі хоча б крихітну частинку цінності. Я називаю це мінімально життєздатним виробом (МЖВ). Це має бути річ, яку ви покажете публіці на перший раз. Наскільки ефективною вона має бути? Ну, цей продукт має дійсно працювати, хоча для людини, яка його розробляла, він може здаватися неоковирним. Вам потрібно демонструвати свій продукт публіці як тільки це буде можливо! Це дасть вам відгук, необхідний для посилення вашого циклу прийняття рішень та розставлення пріоритетів. Назвемо це версією 0.5. Уявіть фотоапарат, що вже може робити знімки, але поки не здатний фокусуватись. Набір меблів для їдальні всього з двох стільців. Відправлення вакцини до пяти із сотні сіл, яким ви намагаєтесь допомогти. Щось недороблене майже до сміху.

Але це дає вам відгук. Виявляється, що корпус фотоапарата насправді незручний, бо кнопка затвора не там, де треба. Дерево, з якого зроблені стільці, погано пасує до матеріалу обіднього столу. Через абсолютно зайву соціальну нетактовність ви примудрились образити старійшин сіл. Завдяки цьому ви дізнаєтеся про помилки, поки ще не надто пізно, а шкода мінімальна.

Потім, коли ви будете робити офіційний реліз чи розгортати велику програму, вже виправите виявлені недоліки і знатимете, що люди дійсно цінують. У прикладі з фотоапаратом може виявитися, що спочатку користувачі казали про рівну цінність режиму панорамної зйомки та можливості ділитися світлинами у Фейсбуку. Коли ж вони дійсно почали користуватися продуктом, то ніколи не вмикали цього режиму, але постійно хотіли постити фото в соціальних мережах.

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


Крива цінності  радикально швидше виведення продукту в люди



У цьому процесі чудовим є те, що він повторюваний (ітеративний): просто «змити й повторити». Як тільки люди матимуть ваш продукт, послугу чи зміну в їхньому житті, вони скажуть вам, якою є наступна найцінніша для них річ. Тоді ви знову підготуйте 20 відсотків цього та презентуйте їм. Знову і знову.

За умови такого поетапного процесу випуску продукту, створивши лише половину характеристик вихідного продукту чи проекту, ви зможете принести вдвічі більше цінності за вдвічі менший час. Ось у чому справжня сила 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 мільйона доларів. Але отримали вони 3,2 мільйона. Їхній чистий прибуток зріс із 15 до 60 відсотків, а це 400-відсоткове збільшення доходів. І тепер, звільнившись від проекту, вони могли взятися за інші. Це не просто вигідна угода. Це стратегія дострокового заробляння собі на пенсію.

Назад Дальше