Scrum 221123 091803

SCRUM
THE ART OF DOING

TWICE THE WORK IN
HALF THE TIME
Jeff Sutherland
CROWN
BUSINESS
NEW YORK
SCRUM
НАВЧИСЬ РОБИТИ
ВДВІЧІ БІЛЬШЕ
ЗА МЕНШИЙ ЧАС
Джефф Сазерленд
УДК 005.330
С12
Жодну з частин цього видання

не можна копіювати або відтворювати в будь-якій формі
без письмового дозволу видавництва
Публікується з дозволу автора та його літературних агентів ROSS YOON

AGENCY (USA) за сприяння Alexander Korzhenevski Agency
Перекладено за виданням:
Sutherland J. Scrum : The Art of Doing Twice the Work in Half the Time /
Jeff Sutherland. — New York : Random House, 2014. — 256 p.
Переклад з англійської Ярослава Лебеденка
Дизайнер обкладинки Влад Прокопів
© Jeff Sutherland and Scrum, Inc.,

2014
© Hemiro Ltd, видання українсь-
кою мовою, 2016, 2018, 2019,
2020, 2022
© Книжковий Клуб «Клуб Сімей-
ного Дозвілля», переклад і ху-
ISBN 978-617-12-9517-9 (PDF) дожнє оформлення, 2016
ВІДГУКИ ПРО КНИЖКУ
Ця надзвичайна книжка демонструє новий спосіб
спростити ваше життя та роботу, підвищити концен-
трацію та виконувати за менший час більше, ніж ви
взагалі будь-коли собі уявляли.
Брайан Трейсі,
автор бестселера «Зроби це зараз»
Дивовижно… Це повністю переверне уявлення лю-

дей про те, наскільки продуктивними вони можуть
бути насправді… Джефф Сазерленд розкриває нетехніч-
ному світові елегантно просту систему, якою після винай-
дення ним Scrum уже давно користуються програмісти та
веб-дизайнери. Ця книжка показує, як невелика, сконцен-
трована та віддана ідеї команда здатна забезпечити значно
вищу якість роботи швидшими темпами за рахунок само
аналізу, циклічності та адаптації.
Майкл Менґі,
старший віце-президент з інтерактивних технологій
Social@Ogilvy
Джефф Сазерленд розписав суть Scrum для широких мас.

Ця книжка підносить Scrum від простого інструмента ви-
правлення проблем до способу життя.
Гіротака Такеучі, професор управлінських практик

Гарвардської школи бізнесу
Джефф Сазерленд є великим майстром творення

високопродуктивних команд. Підзаголовок цієї книжки
6 Відгуки про книжку
не розкриває всієї дії Scrum. Якщо ви не потроїте результати

за третину витраченого часу, то явно робите щось не так!
Скотт Максвелл, засновник та старший виконавчий

директор OpenView Venture Partners
Джефф Сазерленд скористався очевидними, але рідко за-

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

бізнесу та співавтор книжки «Від знання до справи»
Таємницею Сазерленда щодо подолання професійних та

особистих перешкод є підхід до завдань із продуманою
увагою та гнучким складом розуму. Ця книжка змінить
спосіб, у який ви робите все. Навіть більше: вона
допоможе вам почуватися добре в процесі роботи.
Просто прочитайте її і починайте робити більше.
Арнольд В. Стронг, генеральний директор

BrightNeighbor.com та полковник запасу армії США
Ця оманливо проста система є найпотужнішим з усіх

способів покращити ефективність будь-якої команди.
Лео Бабаута, творець блогу ZenHabits.net

ЗМІСТ
Передмова................................................................................. 8
Розділ 1. Спосіб, у який працює світ, — недосконалий....... 11
Розділ 2. Витоки Scrum.......................................................... 37
Розділ 3. Команди....................................................................57
Розділ 4. Час.............................................................................91
Розділ 5. Марнування — це злочин.....................................107
Розділ 6. Плануйте реальність, а не фантазію...................137
Розділ 7. Щастя......................................................................175
Розділ 8. Пріоритети............................................................ 203
Розділ 9. Змінюйте світ........................................................ 237
Подяки...................................................................................268
Додаток. Впровадження Scrum — із чого почати............. 270
Примітки................................................................................275
ПЕРЕДМОВА
Чому Scrum?
За участю Кена Швабера я створив Scrum іще двадцять років

тому як швидший, надійніший та ефективніший метод роз-
роблення програм для технічних галузей. До того часу — та
навіть іще у 2005-му — більша частина проектів розробки
програмного забезпечення базувалася на каскадній моделі,
за якою проект виконувався поетапно та просувався крок за
кроком аж до остаточної передачі клієнтам або користува-
чам. Процес був повільним, непередбачуваним і часто так
і не приводив до створення продукту, який люди хотіли чи
готові були купувати. Великою проблемою цієї моделі були
затримки випуску продуктів — на місяці і навіть на роки.
Заздалегідь розроблені покрокові плани, детально викладе-
ні в діаграмах Ґантта, переконували керівництво, що процес
розробки повністю контрольований, але можна було майже
безпомилково сказати, що ми швидко випадемо з графіка та
катастрофічно перевищимо бюджет.
Щоб подолати ці проблеми, у 1993 році я винайшов новий

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

повім про витоки Scrum із виробничої системи компанії
Toyota та принципу ООВД (Оглядати — Орієнтуватись —
Вирішувати — Діяти), прийнятого в бойовій авіації. Я по-
кажу вам, як ми використовуємо для виконання проектів
невеликі команди і чому це є таким ефективним способом
роботи. Я поясню, як ми розставляємо пріоритети в проек-
тах, організовуємо однотижневі або одномісячні спринти
для підтримки робочого ритму та відповідальності всіх чле-
нів команди, проводимо короткі щоденні обговорення зро-
бленого та викликів, що неминуче виникають. Крім того,
ви побачите, як Scrum поєднує концепції безперервного
покращення та представлення мінімально функціональних
продуктів для отримання негайного відгуку від спожива-
чів — замість очікування, доки проект буде повністю завер-
шено. Як ви дізнаєтесь нижче, ми маємо досвід застосуван-
ня Scrum абсолютно для всього: від виробництва доступних
автомобілів, витрата пального в яких становить один літр
на сорок кілометрів, до вдосконалення баз даних ФБР до
рівня ХХІ століття.
Дочитайте цю книжку до кінця. Думаю, ви зрозумієте, як

описаний у ній підхід може допомогти трансформувати весь
лад роботи, творення нових продуктів, планування та само-
го мислення вашої компанії. Я твердо вірю, що за допомогою
Scrum можна радикально змінити діяльність підприємства
практично в будь-якій галузі. Так само, як цей підхід уже
здійснив революцію у сфері інновацій та швидкості, дозво-
ливши вийти на ринок багатьом чудовим молодим компа-
ніям, а також уможлививши неймовірний асортимент нових
продуктів із Силіконової долини та світу високих технологій.
Джефф Сазерленд
РОЗДІЛ 1. СПОСІБ, У ЯКИЙ ПРАЦЮЄ
СВІТ, — НЕДОСКОНАЛИЙ
12 Спосіб, у який працює світ, — недосконалий
Джефф Джонсон абсолютно не чекав від того дня нічого

доброго. 3 березня 2010 року Федеральне бюро розслідувань
США вирішило згорнути свій найбільший та найамбітніший
проект модернізації програмного забезпечення. Передбача-
лося, що він дозволить не допустити надалі подій на кшталт
терактів 11 вересня, але його спіткав один із найграндіозні-
ших провалів усіх часів. ФБР намагалось удосконалити свою
комп’ютерну систему вже більш ніж десять років, і ця спро-
ба, схоже, вчергове зазнавала краху. Знову. І цього разу вона
була дітищем Джонсона.
Джефф прийшов у Бюро лише за сім місяців до того, піддав-

шись на пропозицію нового керівника інформаційної служби
Чеда Фулгема, з яким він раніше працював у банку Lehman
Brothers. Джонсон став заступником начальника управління
інформаційних технологій та отримав кабінет на верхньому
поверсі будівлі Едгара Гувера — штаб-квартири ФБР у центрі
Вашингтона. То був чудовий, просторий кабінет. З нього на-
віть відкривався вид на монумент Вашингтона. Джефф тоді
й подумати не міг, що більшу частину двох наступних років
проведе в бетонному підвалі, у тісній кімнатці без вікон, на-
магаючись виправити те, що всі вважали невиправним.
Джефф та його бос вирішили визнати свою поразку і згор-

нути розробку програми, яка вже забрала близько десяти
років і коштувала сотні мільйонів доларів. На той момент
було більше сенсу зробити проект внутрішньою справою
інформаційного відділу й займатися ним далі самотужки.
«Це було непросте рішення, — каже він. — Проте роботу слід
було зробити, і то зробити добре».
Проект являв собою довгоочікувану комп’ютерну систему,

що мала ввести ФБР у сучасну еру. Річ у тім, що у 2010 році —
в еру Фейсбуку, Твітеру, Amazon та Google — ФБР усе ще
складало більшу частину своїх звітів на папері. Прийнята на
той час у Бюро система називалась «Автоматизована під-
Спосіб, у який працює світ, — недосконалий 13
тримка слідчих справ» і працювала на величезних ЕОМ, що

були останнім словом техніки ще в далекі вісімдесяті. Бага-
то спеціальних агентів до них навіть не підходили. Надто
вже громіздкою й повільною була ця система в епоху теро-
ристичних атак та злочинців, які не сидять на одному місці.
Коли якийсь агент ФБР хотів щось зробити — по суті, будь-

що: заплатити інформаторові, вистежити терориста, скласти
звіт на грабіжника банків, — то процедура не надто відріз-
нялася від тієї, що діяла тридцятьма роками раніше. Джон-
сон описує її так: «Ви складали документ у текстовому ре-
дакторі та роздруковували три примірники. Один треба було
надіслати на затвердження. Другий зберігався на місці на
випадок, якщо перший загубиться. А з третім необхідно було
взяти червону ручку — я не жартую, червону ручку — та об-
вести на ньому ключові слова для занесення до бази даних.
Ви складали покажчик власного звіту».
Якщо запит затверджували, перший примірник повертався

згори з присвоєним йому номером. Ви здивовані? Так, доку-
ментообіг ФБР вівся за допомогою простого номера, простав-
леного на аркуші. Цей метод був настільки застарілим та ураз-
ливим, що саме на нього поклали частину провини за те, що
Бюро не змогло додати два і два й виявити членів «Аль-Каїди»,
які в’їхали до країни за кілька тижнів чи місяців до 11 вересня.
Один відділ був зайнятим своїм підозрюваним. У другому на-
магались розібратися, чому стільки підозрілих іноземців рап-
том забажали повчитися на пілотів. У третьому стежили ще
за кимось, але нікому про це не казали. Проблема полягала
в тому, що ніхто в Бюро не зумів вчасно звести все це докупи.
Після терактів 11 вересня було створено спеціальну комісію

Сенату, яка намагалася виявити основну причину, чому це
сталося. Так от, на думку цієї комісії, аналітики просто не змог-
ли отримати доступ до інформації, яку повинні були проана-
лізувати. У звіті сказано: «Жалюгідний стан інформаційної
системи ФБР призвів до того, що такий доступ великою мірою

залежав від особистих стосунків аналітика з членами опера-
тивних підрозділів та груп, які мали цю інформацію».
До трагічних подій 11 вересня в ФБР навіть не думали про

проведення комплексної оцінки терористичної загрози Спо-
лученим Штатам. Для цього було багато причин — від зосе-
редження окремих співробітників на кар’єрному зростанні
до поганого обміну інформацією. Але, мабуть, ключовою
причиною такого значного провалу напередодні масових
терористичних атак звіт назвав технічну недосконалість
Бюро. «Інформаційні системи ФБР жахливо застаріли, —
йдеться у висновку комісії. — ФБР не вистачило здатності
знати про все, що воно знало: не було ефективного механіз-
му відстеження та обміну основними даними».
Коли сенатори почали ставити Бюро незручні запитання,

там зазвичай відповідали: «Не хвилюйтесь, ми вже розроб
ляємо план модернізації». Цей план здобув назву «Віртуаль-
ні слідчі справи» і мав усе змінити. Не бажаючи втратити
зиск навіть із кризи, чиновники заявили, що їм потрібні ще
70 мільйонів доларів на додачу до 100 мільйонів, уже перед-
бачених бюджетом для реалізації плану. Якщо почитати
тогочасну пресу, ви побачите, що слова революційний та
перетворення лилися просто рікою.
Але три роки потому програму згорнули. Вона просто не пра-

цювала. Ані на йоту. ФБР витратило цілих 170 мільйонів
доларів платників податків, щоб купити комп’ютерну систе-
му, якою так і не скористалося — жодним рядком коду, до-
датком чи кліком мишки. Увесь проект виявився однією
суцільною катастрофою. І то була не просто якась рядова
технічна помилка IBM чи Microsoft. На кону буквально сто-
яли людські життя. Як сказав тоді газеті Washington Post
сенатор від штату Вермонт Патрік Ліхі, головний демократ
у юридичному комітеті Сенату:
У нас була інформація, що могла зупинити 11 вересня. Вона

лежала там і була незадіяна… Я не побачив, щоб вони ви-
правили проблеми… Поки ми опануємо технології двадцять
першого століття, може вже настати двадцять друге1.
Показово, що багато людей, які працювали у ФБР на час про-

валу «Віртуальних слідчих справ», більше там не працюють.
У 2005 році ФБР анонсувало запуск нової програми «Варто-

вий». Цього разу вона вже мала запрацювати. Цього разу
вони вживуть необхідних запобіжних заходів, залучать від-
повідні бюджетні процедури, правильні засоби контролю.
Вони засвоїли свій урок. Ціна питання? Усього якийсь там
451 мільйон доларів. І до 2009-го все повністю запрацює.
Що тут могло піти не так? У березні 2010 року відповідь ляг-

ла Джеффові Джонсону на стіл. Компанія Lockheed Martin,
підрядник, найнятий для розробки системи «Вартовий»,
уже витратила 405 мільйонів доларів. При цьому вони роз-
робили лише половину проекту, і то спізнившись у своїй
роботі на цілий рік. Незалежний аналіз показав, що для
закінчення проекту їм потрібно ще 6—8 років, а платникам
податків доведеться викинути на це щонайменше 350 міль-
йонів доларів додатково.
І Джонсон мав щось із цим робити.
Що ж тоді пішло не так і як ситуацію вдалося виправити?

Відповіді на ці питання якраз і спонукали мене написати цю
книжку. Проблема полягала не в дурнях. Не можна сказати,
що в Бюро не вистачало компетентного персоналу чи необ-
хідних технологій. Усе гаразд було й з робочою етикою та
здоровою конкуренцією.
Головною проблемою був спосіб роботи. Саме так, спосіб

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

так учили.
Коли чуєш, що сталося, спершу все здається цілком логіч-

ним. Перед тим як братися за контракт, співробітники
Lockheed вивчили вимоги замовника та почали планувати
створення системи, яка буде на все це здатна. Було задіяно
багато розумних людей, які довгі місяці працювали над ви-
значенням того, що треба зробити. Потім вони витратили
ще місяці на планування того, як це зробити. Вони підготу-
вали чудові графіки, позначивши там усе, чого слід досягти,
та час, який займе виконання кожного завдання. Після цьо-
го, ретельно дібравши кольори, вони зобразили всі частини
проекту, які переходили одна в одну у вигляді каскаду.
КАСКАДНА МОДЕЛЬ
Початок Визначення
проекту Проектування
Бізнес-вимоги Розробка
Технічний проект Випробування
Кодування
й тестування
Схвалення
клієнтом та запуск
Такі графіки називаються діаграмами Ґантта, на честь аме-

риканського інженера Генрі Ґантта, який їх розробив. З по-
явою в 1980-х персональних комп’ютерів, які спростили
творення цих складних графіків і дозволили робити їх дійс-
но комплексними, вони перетворилися на справжні витвори
мистецтва. Тепер кожен крок у проекті детально презенту-
ється. Кожна віха. Кожна дата випуску. Ці графіки насправ-
ді вражають. Єдина проблема з ними — в тому, що вони
абсолютно завжди неправильні.
Генрі Ґантт винайшов свої знамениті діаграми приблизно

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

но виконати для реалізації масштабного проекту, презентуєть-
ся на загальний огляд. Я бував у багатьох компаніях, де єдиним
завданням кількох співробітників є щоденне оновлення діа-
грам Ґантта. Проблема в тому, що як тільки цей план зустріча-
ється з реальністю, то тріщить по всіх швах. Але замість того,
щоб викинути на смітник і сам план, і його ідею, менеджери
наймають під нього людей, роблячи вигляд, що все чудово
працює. По суті, вони платять фахівцям, щоб ті їм брехали.
Ця невдала схема нагадує звіти, які отримувало радянське

Політбюро 1980-х перед самим розпадом СРСР. Повний мі-
раж. Як і тоді, сьогодні звіти стали важливішими за дійсність,
яку вони мають описувати, і якщо виникає якась невідпо-
відність, винною вважається саме дійсність, а не діаграми.
Колись давно, коли я був кадетом Військової академії Вест-

Пойнт, я спав у колишній кімнаті Дуайта Ейзенхауера. Уночі
мене іноді будило світло вуличних ліхтарів, яке відбивалось
від золотої таблички над каміном. Там було написано: «Тут
спав Дуайт Д. Ейзенхауер». Так от, я пригадую, цей президент
якось зазначив, що планувати бій важливо, але варто лише
прогриміти першим пострілам, як ваш план іде за вітром.
Принаймні йому вистачало здорового глузду не використо-
вувати діаграм Ґантта.
Отже, Lockheed представив ФБР усі ці гарненькі графіки,

і Бюро їх прийняло. Начебто цього разу завдання було роз-
плановане настільки добре, що завадити успіху не могло
ніщо. «Дивіться, тут вам і різнокольорові позначки, і розміт-
ка часу, і гістограми».
Проте коли Джефф та його бос, голова інформаційної служ-

би Чед Фулгем, поглянули на план навесні 2010 року, то
зрозуміли, що дива не сталось: усі ці діаграми були нескін-
ченно далекими від дійсності. Розглянувши реальний стан
справ, ці двоє усвідомили, що розв’язати проблему просто
неможливо. Нові дефекти програмного забезпечення вияв-
лялися швидше, ніж вдавалося виправити старі.
Чед доповів генеральному інспекторові Міністерства юстиції,

що вони зможуть завершити проект «Вартовий», узявши його
розробку на себе та зменшивши кількість розробників. За
рахунок цього вони виконають найскладнішу половину про-
екту більш ніж уп’ятеро швидше, витративши менш ніж де-
сяту частину бюджетних грошей. Скептицизм у зазвичай су-
хих звітах інспектора для Конгресу можна було просто-таки
відчути на дотик. У жовтні 2010 року, виклавши свої пере-
стороги в дев’яти пунктах, цербери генерального інспектора
підбили підсумок: «Загалом, ми маємо великі сумніви сто-
совно здатності цього нового підходу завершити проект
“Вартовий” у межах бюджету, вчасно та не з гіршою, ніж
зараз, функціональністю…»2
НОВИЙ СПОСІБ МИСЛЕННЯ

Цей новий підхід називається Scrum. Я створив його двадцять
років тому. На сьогодні це єдиний перевірений спосіб, здатний
дати раду такого роду проектам. Існують два способи управлін-
ня проектами: старий «каскадний», який марнує сотні мільйо-
нів доларів і часто не дає на виході геть нічого, і новий, який із
меншою кількістю людей та за менший час може дати більший

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

гально потребуючи нового способу мислення щодо роботи.
Перелопативши тонни досліджень та експериментів, переди-
вившись гори отриманих раніше даних, я зрозумів, що новий
спосіб організації людської діяльності потрібен нам усім. У цьо-
му не було чогось надзвичайного, адже в минулому цю пробле-
му порушували не раз і не двічі. Пошукам ефективних способів
організації праці були присвячені ще дослідження часів Другої
світової війни. Але з тих чи інших причин люди так і не змогли
зібрати окремі ідеї докупи. Я намагався зробити це протягом
більш ніж двадцяти років, після чого мені вдалося створити
систему, дуже поширену сьогодні в першій сфері, для якої я її
застосував, — розробці програмного забезпечення. Від таких
гігантів, як Google, Amazon та Salesforce.com, до дрібних старт
апів, про які ви поки що не чули, ця система радикально змі-
нила підхід людей до виконання поставлених у роботі завдань.
Причина ефективності цієї системи проста. Я взяв до уваги

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

розділах, ця система підвищення ефективності команд отри-
мала назву Scrum. Цей спортивний термін, що означає гурту-
вання навколо м’яча в регбі, чудово відображує спосіб спів
праці членів команди для пересування полем. Він потребує
злагодженості дій, єдності мети та чіткого розуміння необхід-

ності її спільного досягнення. Це ідеальна метафора для того,
чого я хочу від командної роботи.
Зазвичай у ході роботі над будь-яким проектом менеджмент

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

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

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

саме стільки часу й зусиль і чому ми так погано вміємо визна-
чати їх заздалегідь. На будівництво Шартрського собору піш-
ло п’ятдесят сім років. Так от, я можу заприсягтись, що на
початку будівництва каменярі подивились на єпископа й ска-
зали: «Двадцять років максимум. Можливо, впораємось і за

п’ятнадцять».
Scrum вітає непевність і творчість. Ця система закладає під-

валини процесу пізнання, що дозволяє командам оцінювати
не лише те, що вони створили, але й (не менш важливо) як
вони це створили. Спираючись на справжню роботу команд,
Scrum дає їм інструменти для самоорганізації та швидкого
покращення швидкості та якості їхньої роботи.
У своїй основі Scrum базується на простій ідеї: хоч коли по-

чався проект, чому б регулярно не перевіряти, що він іде
в правильному напрямку та дійсно відповідає прагненням
людей? Непогано також ставити собі питання, чи існують
якісь способи покращити вашу роботу, виконувати її якісніше
та швидше, а також що може вам у цьому заважати.
Це називається циклом перевірки та адаптації. Як тільки ви-

падає вільна хвилинка, треба зупинятись, переглядати вже
зроблене, перевіряти його відповідність визначеним раніше
вимогам та шукати шляхів покращення своїх дій. Це проста
ідея, але її впровадження потребує уваги, самоаналізу, щиро-
сті та дисципліни. Я пишу цю книгу, щоб показати вам, як це
робиться. І не лише в компаніях з розробки програмного за-
безпечення. Я бачив, як Scrum успішно застосовували для
випуску автомобілів, управління пральнею, навчання студен-
тів, виготовлення космічних кораблів, планування весілля —
навіть як його застосовувала моя дружина, щоб проконтро-
лювати виконання мною всіх домашніх справ на вихідні.
Кінцевим результатом застосування Scrum — метою його роз-

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

всій планеті. А вже консультантом та тренером я працював
іще в кількох сотнях різних фірм.
Результати, буває, настільки вражають, що, на думку провід-

них дослідницьких та аналітичних фірм (таких як Gartner,
Forrester Research та Standish Group), старий стиль роботи
вже можна сміливо відкинути й забути. Компанії, які все ще
чіпляються за давно відомі, але неефективні ідеї управління
та контролю, мріючи про чітку передбачуваність, просто
приречені на провал, якщо їхні конкуренти використовують
Scrum. Надто вже велика між ними різниця. Наприклад,
у фірмі OpenView Venture Partners із Бостона, де я працюю
консультантом, кажуть, що Scrum пропонує надто велику
конкурентну перевагу, щоб нею не скористатись. Люди, які
там працюють, зовсім не білі й пухнасті. Це холодні ділки,
але вони просто кажуть: «Результати беззаперечні. Компанії
мають лише два варіанти: змінюйтесь або помріть».
РОЗВ’ЯЗАННЯ ПРОБЛЕМИ ФБР

Першою проблемою, з якою зіткнулась у ФБР команда про-
екту «Вартовий», були контракти. Адже кожна найменша
зміна програми закінчувалася контрактними переговорами
з Lockheed Martin. Тому Джефф Джонсон та Чед Фулгем ви-
тратили місяці, розплутуючи всі контракти, беручи розробку
на себе та скорочуючи штат із кількох сотень працівників до
п’ятдесяти. Основна команда вийшла в них ще меншою.
Увесь перший тиждень вони займалися тим, що робить багато

людей у таких обставинах: роздруковували всі документи з ви-
могами. Якщо ви ніколи не бачили, на що це схоже у великих
проектах, то це можуть бути сотні й сотні сторінок. Я сам бачив
стоси ледь не в метр заввишки. Проект за проектом люди ви-
різають та вставляють у текст одні й ті самі стандартні фра-
зи, а потім ті купи паперу ніхто не читає. Це просто фізично

неможливо. Але стара система змушує людей діяти саме так.
«Там було 1100 вимог. Стос вийшов завтовшки з десять

сантиметрів», — каже Джонсон. Особисто в мене сама дум-
ка про ці документи викликає співчуття до людей, які, ма-
буть, витратили кілька тижнів свого життя, готуючи те, що
не мало жодної мети. ФБР та Lockheed Martin не одні такі —
я бачив повторення цього ледь не в кожній компанії, де
працював. Ця товста пачка непотребу якраз і є однією з при-
чин, чому впровадження Scrum може стати для людей та-
кою потужною зміною. Ніхто не повинен витрачати своє
життя на безцільну роботу. Це погано не лише для бізне-
су — це вбиває душу.
Отже, отримавши свою пачку паперів, Джонсон та Фулгем

розставили пріоритети для кожної вимоги. Це було просто
життєво необхідно і складніше, ніж здається. Часто люди про-
сто кажуть, що важливе все. Але насправді слід ставити пи-
тання, яке й поставили члени команди «Вартового»: що
принесе проекту найбільшу цінність? Цим і слід займатися
насамперед. У розробці програмного забезпечення є правило,
підкріплене десятиліттями досліджень: 80 відсотків цінності
будь-якої програми закладені у 20 відсотках її функціональ-
них особливостей. Подумайте про це: коли востаннє ви кори-
стувалися функцією візуального редактора у Microsoft Word?
Ви, мабуть, узагалі не знаєте, що це таке, не кажучи вже про
те, для чого він потрібний. А він там є, і хтось витратив чима-
ло часу на його впровадження, але я гарантую вам, що це
не набагато підвищило цінність Word.
Необхідність розставляти пріоритети за цінністю змушує лю-

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

разд, ми займаємось цим величезним проектом, який є жит-
тєво необхідним і на який ми вже викинули сотні мільйонів
доларів. Коли ж він завершиться?» Подумавши над цим,
вони пообіцяли здати роботу восени 2011 року. Але звіт ге-
нерального інспектора, поданий восени 2010-го, був про-
сто-таки зразком недовіри:
У ФБР стверджують, що для завершення розробки «Вартово-

го» задіють так звану «гнучку методологію», для якої потрібно
менше співробітників ФБР, Lockheed Martin та компаній, що
постачають готові компоненти цього проекту. Загалом ФБР
планує зменшити кількість контрактних фахівців, залучених
до роботи над «Вартовим», із приблизно 220 до 40. Там кажуть,
що водночас і кількість задіяних у проекті співробітників ФБР
зменшиться з 30 до 12… Бюро запевнило нас, що планує за-
вершити «Вартового» приблизно за 20 мільйонів доларів, які
ще залишились у бюджеті проекту, та не пізніш ніж через
12 місяців після запровадження цього нового підходу3.
Використання вислову «гнучка методологія» чітко показує,

як мало інспектор знав про Scrum. Цей термін походить іще
із зустрічі 2001 року, на якій я та шістнадцятеро інших май-
стрів програмного забезпечення склали те, що стало відомим
як «Маніфест гнучкої розробки». Цей маніфест проголосив
такі цінності: люди важливіші за процеси; продукти, що дійс-
но працюють, важливіші за документування їхніх номіналь-
них цілей; співпраця з клієнтами важливіша за переговори
з ними; реакція на зміни важливіша за дотримання плану.
Scrum — це система, яку я створив для впровадження цих
цінностей на практиці. Це не просто якась методологія.
Звичайно, 12-місячну обіцянку Джонсона було дано з пев-

ною натяжкою. Адже насправді вони не знали, коли закін-
чать, — просто не могли знати. По суті, ніхто в ФБР навіть
не здогадувався, як швидко здатні працювати їхні команди.
Саме про це я постійно кажу керівникам різного роду під-

приємств: «Я знатиму дату завершення проекту, коли поба-
чу ступінь прогресу членів команди. Як швидко вони просу-
ватимуться вперед. Наскільки вони прискоряться».
Було також дуже важливо, звичайно, щоб члени команди

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

вих концепцій, яку ввів в обіг Оно, є ідея «потоку». Суть у тому,
що виробництво має бути швидким та безперервним протя-
гом усього процесу, а одним із головних завдань менеджмен-
ту, за його словами, є виявлення та усунення перешкод для
цього потоку. Усе, що стоїть на його шляху, є марнуванням.
У своїй класичній книзі «Виробнича система Toyota» Оно дає
цьому явищу моральну, а також ділову оцінку:
Не буде перебільшенням сказати, що в період незначного

зростання таке марнування є злочином проти суспільства,
а не просто комерційними втратами. Усунення марнування
має стати першорядним завданням будь-якого підприємства4.
Оно багато говорить про різні види марнувань та перешкод,

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

саме йому.
Команді «Вартового» знадобилося близько трьох місяців,

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

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

початку кожного циклу відбувається зустріч із планування
спринту. Члени команди вирішують, скільки роботи вони
можуть виконати протягом наступних двох тижнів. З пере-
ліку завдань із розставленими пріоритетами вони обирають
робочі моменти, які потрібно виконати, часто виписуючи їх
просто на стікери та ліплячи на стіну. Після цього члени
команди вирішують, скільки цих робочих моментів вони
зможуть виконати протягом даного проміжку часу.
Наприкінці спринту всі члени команди збираються разом та

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

просуватися, — їхньої швидкості.
Після демонстрації досягнень (саме тут у гру вступає ідея

Таїчі Оно) вони обговорюють не що зробили, а як вони це
зробили. Вони шукають відповіді на запитання: «Як можна
покращити нашу спільну роботу в наступному спринті? Що
стояло в нас на шляху протягом попереднього? Які перешко-
ди знижують нашу швидкість?» Більш детальне пояснення
роботи Scrum можна знайти в додатку.
І саме тому Джеффові Джонсону знадобилося кілька місяців,

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

ло, які перешкоди їх затримували. Передусім він прагнув
прискорити ці команди, щоб вони почали діяти швидше — за
рахунок не понаднормової роботи (далі я поясню, що це шлях
у нікуди, який лише гальмує справу), а роботи кращої та ро-
зумнішої. За словами Джеффа Джонсона, його команди під-
вищили свою продуктивність утричі. Порівняно із самим
початком роботи, вони стали просуватися вперед у три рази
швидше. Чому? Безумовно, вони навчилися краще працюва-
ти разом, але найважливіше, що вони визначили речі, які їх
затримували, та протягом кожного циклу й кожного спринту
намагались їх позбутися.
Урешті-решт, для впровадження проекту «Вартовий» зна-

добилося півтора року кодування для створення системи
бази даних і ще два місяці для розгортання її по всьому ФБР.

«На нас дуже сильно тиснув час, — сказав Джонсон під час
інтерв’ю. — Але ви маєте зрозуміти: ця система охоплює все.
Оплату інформаторів. Зберігання доказів. Слідчі справи.
Календарі. Навіть інформацію про нашу з вами бесіду також
занесено у “Вартового”».
Яка ж частина Scrum, на його думку, є найефективнішою?

«Демонстрація результатів. Прагнення до отримання про-
дукту, який можна продемонструвати на кожному етапі».
Раз на два тижні члени команди «Вартового» демонструють,
чого вони досягли. Причому демонстрація та обговорення
здійснюються не лише для них самих. Вони беруть свої до-
сягнення та показують їх людям, які фактично користува-
тимуться цією системою. Усі підрозділи, що брали участь
у проекті, присилали своїх представників, яких збиралося
доволі багато. Там були люди з діловодства, розвідки, спец
агенти, апарат генерального інспектора та представники
інших державних установ. Доволі часто приходили директор
та заступник директора ФБР, а також чинний генеральний
інспектор власною персоною. Натовп збирався ще той.
І саме тому вони й упорались, каже Джонсон. «Scrum стосу-

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

(як би це м’якше сказати?) були доволі скептично налаштова-
ні щодо заявленого командою прогресу. Вони просто не могли
повірити, що «Вартовий» дійсно прогресує, причому з дедалі
більшою швидкістю. «Я запевняв Конгрес, що за 5 відсотків
бюджету та двадцять місяців ми збираємось досягти того, що
Lockheed не зміг зробити, маючи 90 відсотків бюджету та де-
сять років, — каже Джонсон. — Але мені не надто вірили. Ми
мали подавати звіти помічникові генерального прокурора. Ми

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

ФБР. «Хлопці з підвалу знову збираються всіх надурити», —
думали вони. Це буде лише ще одна тимчасова система, що
швидко провалиться, і нам доведеться повернутись до па-
перових гір.
Джефф розповів своїй команді про рядки, які він запам’ятав,

коли навчався у Військово-морській академії в Аннаполісі.
То був уривок із промови Теодора Рузвельта «Громадянство
в республіці», з якою він виступив у Сорбонні 1910 року. Його
часто цитують:
Значення має не критик, не людина, яка вказує, де сильний

спіткнувся чи де справжній діяч міг би зробити краще. На
повагу заслуговує той, хто сам на арені, чиє обличчя вкрите
пилом, потом та кров’ю, хто відважно бореться, помиляється,
програє знову і знову, бо не буває зусиль без помилок та по-
разок, але все одно прагне діяти, хто знає великий ентузіазм,
велику відданість, хто розтрачує себе в гідній справі і в кра-
щому випадку зазнає наприкінці тріумфу високого досягнен-
ня, а в гіршому хибить, однак після великих дерзань. Тому
його місце ніколи не буде поруч із тими холодними та бояз-
кими душами, що не знають ані перемог, ані поразок5.
Команда таки мала кілька затримок, доки точно не визна-

чила, як швидко вони можуть діяти й наскільки складні
завдання перед ними стоять. Нарешті, у липні 2012 року
«Вартовий» було запущено. Причому запускати його дове-
лось одразу на повну, для всіх підрозділів. Про поетапне
впровадження не було й мови.
«Це відбулося протягом лиш одного дня, — згадує Джефф

Джонсон. — Адже в кримінальній або антитерористичній
справі якісь події в Лос-Анджелесі можуть бути пов’язані
з якимись подіями в Чикаґо. Ми просто не могли дозволити
собі жодної втрати інформації. У будь-який момент часу
в нас мали бути чіткі та повні дані про стан справ».
Причому дані мали бути достатньо чіткими та повними для

передачі справи в суд. Адже інформація проекту «Вартовий»
використовувалася для карного переслідування людей, і її
повнота мала бути поза всякими сумнівами.
У перший день Джефф був увесь на нервах. Він прийшов у свій

кабінет та запустив «Вартового». Той завантажився. Це було
добре. А потім він спробував затвердити документ електрон
ним підписом — рутинна повсякденна процедура, яку десятки
тисяч співробітників ФБР мусять робити весь час. І тут на
екрані з’явилося повідомлення про помилку. Система не пра-
цювала. Джонсон згадує, що почав панікувати, а в його голо-
ві затанцювали картини катастрофи. Але уважніше приди-
вившись до коду помилки, він зрозумів, що все не так погано.
Він просто не вставив свою ідентифікаційну картку в машину
для підтвердження особи. Він вставив картку, клацнув миш-
кою, і «Вартовий» запрацював належним чином.
Ефект цієї програми для ФБР був надзвичайним. Здатність

спілкуватись та обмінюватись інформацією фундаментально
змінила можливості Бюро. У січні 2013 року регіональне від-
ділення ФБР повідомили про злам банківського рахунку од-
ного малого підприємства. Перш ніж американські банки
змогли це зупинити, близько мільйона доларів було переве-
дено до іншої країни. Скориставшись «Вартовим», місцеве
відділення скооперувалося з аташе з юридичних питань по-
сольства країни призначення, який повідомив тамтешні пра-
воохоронні органи, а вже ті зупинили трансфер, не давши
йому потрапити в банківську систему. Усе це сталося за ліче-
ні години, чого просто не могло бути в епоху трьох друкованих

примірників та червоних ручок. У цьому й полягала різниця:
спіймати зловмисника чи дати йому втекти зі здобиччю.
Команда «Вартового» все ще працює в підвалі ФБР, прибрав-

ши лише перегородки між столами, щоб бачити одне одного.
На стіні висить плакат із текстом «Маніфесту гнучкої розроб-
ки» — принципів, які я допомагав писати та впровадженню
яких в усьому світі присвятив життя. Доволі дивно для при-
міщення без вікон, але неподалік входу під люмінесцентною
лампою росте цілком здорова лаванда. У цьому є певний сим-
волізм, адже «Лаванда» була кодовою назвою прототипу «Вар-
тового». Члени команди досі продовжують удосконалювати
створену ними систему, додаючи все нові й нові функції.
Серед прихильників Scrum ходить старий жарт про курку та

свиню, які йдуть разом дорогою та розмовляють.
— Слухай, свинко, я тут подумала, чи не відкрити нам із

тобою ресторан, — каже курка.
— А як ми його назвемо? — питає свиня.
— Може, «Яєчня з беконом»?
— Ні, дякую, — каже свиня. — Я тоді буду зайнята повністю,

а ти лише долучишся!
Суть полягає в тому, що в Scrum «свині» — це ті, хто вико-

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

також набуває складності з нечуваною раніше швидкістю.
Візьмімо, наприклад, машини. Колись я сам займався своєю
автівкою, роблячи дрібні ремонти своїми руками. Тридцять
років тому я навіть міг полагодити радіатор. Тепер же, відкри-
ваючи капот, я неначе заглядаю всередину якогось комп’юте-
ра. По суті, саме це я й роблю, бо новий Ford містить у собі
більше рядків програмного коду, ніж Фейсбук і Твітер разом
узяті. Створення таких складних речей потребує масштабних
людських зусиль. А кожного разу, коли люди беруться за
складні творчі справи — чи запуск ракети в космос, чи вдо-
сконалення вимикача, чи арешт злочинця, — традиційні
методи управління просто розвалюються.
І ми це розуміємо — як окремі люди, так і суспільство в ці-

лому. Ми бачимо відгомін нашого справжнього життя у фан-
тазіях на офісну тему, на кшталт зображених у коміксах
«Дільберт» чи фільмі «Офісний простір». Ми всі приходимо
додому з роботи та розповідаємо нашим близьким чи друзям
про божевілля сучасної корпоративної «організації». Ми всі
чуємо, що правильне заповнення форм важливіше за вико-
нання роботи або що нам потрібно проводити зустрічі для
підготовки підготовчої зустрічі. Це просто якась дурня. Але
ми все одно продовжуємо це робити. Навіть перед загрозою
абсолютного та повного провалу.
Яскравим прикладом є запуск веб-сайту Healthcare.gov, при-

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

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

підрядників, не йолопи — вони розуміли, що можна зробити
й краще. Проте всі казали: «То не мій клопіт». Вони викону-
вали свій шматок роботи — і квит. Вони ніколи не дивились
на той сайт із точки зору користувачів, а лише з власної.
А все тому, що не були згуртовані — об’єднані спільною метою.
Scrum же якраз і зводить членів команди разом для досягнен-
ня великих результатів, вимагаючи від усіх не лише бачити
кінцеву мету, але й покроково до неї наближатись. У проекті
Healthcare.gov не було відповідальної особи, яка б наполягала,
щоб усе тестувалось одразу після створення, і, на жаль, у появі
збоїв не було нічого надзвичайного. Хто ж зумів виправити
ситуацію із сайтом? Люди, які використовували Scrum.
Скільки разів вам доводилося чути про якийсь масштабний

проект вартістю в мільйони й мільйони доларів, який скасо-
вують не лише через перевищення бюджету, але й через те,
що він просто не працює? Скільки мільярдів доларів витра-
чається щороку, не приносячи геть нічого? Скільки часу ва-
шого життя марнується на роботу, яка не принесе віддачі, що
наперед розумієте і ви, і ваш начальник? Із таким самим успі-
хом ви могли б копати ями, а потім закидати землею їх знову.
Так не має бути. Дійсно не має. Навіть якщо всі завжди ка-
зали вам, що світ улаштований саме так, це зовсім не озна-
чає, що вони праві. Існує й інший спосіб досягнення резуль-
тату — зовсім інший спосіб роботи.
І, якщо не користуватися ним, вас переведуть на зовнішнє

управління. Або ваша компанія помре. У гіперконкурентному
світі праці ХХІ століття немає місця для марнування та

безглуздя.
Ще важливіший момент: робота максимально продуктив-

ним способом (таким як Scrum) не обов’язково має обме-
жуватися сферою бізнесу. Що як люди користуватимуться
цим методом для розв’язування масштабних проблем, від
яких потерпає все людство: наприклад, залежності від на-
фти, браку освіти, нестачі чистої води в бідних частинах
земної кулі чи розгулу злочинності? Що як насправді вже
давно існує кращий спосіб життя та роботи, а також інак-
шого розв’язання проблем? Спосіб, яким дійсно можна
змінити світ? А він є. Існують люди, які використовують
Scrum для розв’язування всіх цих проблем, які я згадав,
і вони роблять велику справу.
Із цієї книжки ви дізнаєтеся про деякі основні способи по-

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

історію, як я сам до цього дійшов.
Що треба запам’ятати
Планувати корисно. Сліпо дотримуватися плану

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

ни. Закладайте у свій метод роботи можливість змін, від-
криттів та нових ідей.
Перевіряйте та адаптуйте. Після кожного маленького

кроку робіть паузу, переглядайте виконане та дивіться,
чи все ще відповідає воно вашій меті та чи можете ви
щось покращити у своїй роботі.
Змінюйтесь або помріть. Прив’язка до старого способу

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

ти. Корпоративна культура часто приділяє більше уваги
різним формам, процедурам та зустрічам, аніж створенню
відчутної цінності, яку з короткими інтервалами можуть
випробувати користувачі. Робота, що не приносить справж-
ньої цінності, безглузда. Виробництво ж продукту корот-
кими циклами дозволяє отримати ранній відгук користу-
вачів та негайно позбутися явного марнування зусиль.
РОЗДІЛ 2. ВИТОКИ SCRUM
38 Витоки Scrum
Для американських військових пілотів у В’єтнамі період про-

ходження служби означав виконання ста польотних завдань
над ворожою територією. При цьому п’ятдесят відсотків пі-
лотів були збиті. Декого вдавалося врятувати, але більшість
збитих уже ніколи не поверталися. У 1967 році, будучи ще
молодим, недосвідченим винищувачем, я прибув із військо-
во-повітряної бази Маунтін-Хоум в Айдахо на базу королів-
ських ВПС Удон у північному Таїланді для виконання най-
небезпечнішої роботи в авіації США — розвідки.
Це було задовго до нинішньої ери дронів та достовірних

супутникових даних. Мій літак RF-4C Phantom був споря-
джений усіма видами зброї, обладнаний камерами та до-
датковим паливним баком. Моєю роботою були польоти
над ворожою територією, щоб штурман міг зняти фото до
та після нашого бомбардування. Більшість завдань вико-
нувалися вночі, і я летів крізь тропічну пітьму приблизно
в сотні метрів над землею, ледь не причісуючи верхівки
дерев. У момент перетину кордону з Північним В’єтнамом
дисплей у моєму шоломі час від часу спалахував, наче ав-
томат для гри в пінбол, після чого з гучним писком та сви-
стом активувалася система попередження про ракетну ата-
ку. Небо світилося від трасерів зеніток, і я розумів, що через
кілька хвилин мій літак засіче ракетний радар, хіба тільки
150 метрів — це достатньо низько, щоб від нього сховатись.
У такі хвилини рівень адреналіну в моїй крові мав би за

шкалювати, але я не втрачав голови. Навпаки, небезпека мене
майже заспокоювала. Цим я завдячую тренуванням з конт
ролю ризиків, які отримав від ВПС. Ті тренування навчили
мене робити чотири речі: Оглядати, Орієнтуватись, Вирі-
шувати й Діяти. Зокрема, я мав спостерігати за об’єктом
розвідки, визначати найкращий шлях у гарячу зону й назад,
орієнтуватись у разі неочікуваних подій, а потім рішуче ді-
яти на основі інстинктів та засвоєних навичок. Зволікання
може вбити пілота, як і безрозсудна хоробрість. Як тільки
Витоки Scrum 39
мій штурман робив потрібні фото, я тягнув важіль на себе та

виривався з-під обстрілу, хоча через перевантаження майже
нічого не бачив. Від тих перевантажень штурман теж часто
відключався, а в деяких випадках і втрачав контроль над
своїм кишечником. Але він не скаржився. Бо я завжди до-
ставляв нас назад живими.
Тоді я був просто молодим пілотом реактивного літака,

який сподівався пережити свою сотню завдань. Я не знав,
що досвід польотів та тренувань, які я пройшов щодо вмін-
ня думати та діяти в смертельно небезпечних ситуаціях,
сформує спосіб моєї роботи до кінця життя. Я прибув до
В’єтнаму в 1967 році з двома ескадрильями винищувачів
F-4 та двома розвідниками RF-4C, загалом сотнею літаків.
Ми прибули на зміну двом ескадрильям RF-101s. З п’ятде-
сяти RF-101s протягом одного року були збиті всі, крім
чотирьох. А ті, що залишились, мали в корпусі стільки про-
боїн, що просто не могли літати. Навіть не знаю, як пілоти
взагалі посадили їх після останнього завдання. RF-4C був
більш витривалим літаком-винищувачем, але половину
наших літаків однаково збили протягом року. Ми покра-
щили показники виживання, але 50 відсотків тих, хто при-
був разом зі мною, все одно не повернулися на базу. Лише
кількох щасливчиків вдалося врятувати з джунглів, перш
ніж їх схопили в’єтнамці.
Повернувшись із війни у В’єтнамі, я здобув ступінь магістра

статистики в Стенфорді, проводячи весь свій вільний час
у лабораторії штучного інтелекту. Після цього я став викла-
дачем математики в Академії військово-повітряних сил та
вступив до аспірантури з біометрики в Медичній школі
Університету Колорадо. Там я спитав свого куратора док-
тора Джона Бейлара, одного з найвидатніших дослідників
у сфері медицини та статистики, як написати дисертацію,
що буде корисною людям, а не валятиметься на запилюже-
ній полиці бібліотеки. Він передав мені три сотні статей
з медичних журналів про рак. Усі вони містили діаграми

онкологічної статистики, які широко варіювали для лю-
дей і тварин та залежно від типу пухлини. Бейлар сказав,
що якщо я зумію пояснити, чому вони всі різні, то зможу
претендувати на докторський ступінь. Саме це я й зробив,
ставши доктором.
Але перед тим я роками намагався визначити, що відбуваєть-

ся в клітині, від чого вона стає раковою. Я багато дізнався про
теорію систем і те, як лише система має певні стабільні стани.
У міру свого розвитку клітина переходить з одного стабільно-
го стану в інший. Саме визначенню правил переходу складної
адаптивної системи з одного стану в інший та перетворення
наступного стану на позитивний замість негативного я й при-
святив майже десять наступних років свого життя.
Із часом я зрозумів, що організації, команди та люди також

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

ти на наукові дослідження, у тому числі й мій грант від На-
ціональних центрів дослідження раку, коли я був провідним

дослідником збирання та аналізу даних відділення клініч-
них та епідеміологічних досліджень Центру раку при Уні-
верситеті Колорадо. Поки я думав, що робити далі, до мене
звернулися з компанії під назвою MidContinent Computer
Services, де почули, що я є провідним фахівцем у сфері їхніх
найновіших розробок. MidContinent займалась обслугову-
ванням 150 банків у всій Північній Америці. Свій найнові-
ший продукт вони назвали мережею «автоматичних касових
апаратів» (банкоматів). Це було в далекому 1983 році, коли
отримання готівки зазвичай означало вистоювання довгої
черги в банку або під’їзд до спеціального банківського вікна
на вашому автомобілі. Ви мали заповнити чек на готівку,
вказавши потрібну суму, та передати його касирові.
Нова мережа мала залишити цю незручність у минулому,

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

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

як там усе працює. Можете уявити, як вище керівництво
ставилося до моїх хлопців. Там було багато крику, дріб’яз-

кових розпоряджень, пасивно-агресивної поведінки та ви-
мог працювати краще й понаднормово. Але хоч як керів-
ництво тиснуло, проекти все одно хронічно запізнювались,
не вкладалися в бюджет і не приносили очікуваного ре-
зультату.
Я прийшов до думки, що найкращим варіантом для нас

є все це змінити. Проблем було надто багато, щоб усувати
їх окремо, тому я вирішив створити компанію всередині
компанії. Я попросив нашого генерального директора Рона
Гарріса дозволити мені сформувати окрему організацію
з усіх залучених до проекту створення мережі банкоматів.
У нас буде власна команда продажів, власна група марке-
тингу та власні фінансисти. Рон був блискучим і творчим
керівником, який мені довіряв. Мабуть, за керівництва ко-
гось іншого це б ніколи не вдалося реалізувати. Почувши
про мою ідею, він сказав мені: «Сазерленде, якщо ви хоче-
те взяти на себе цей головний біль, то візьміть».
Я так і зробив. Я пішов до розробників та менеджерів і сказав

їм: «Перше, що нам треба, це припинити робити речі, які
нас убивають». Це як у тому старому жарті про людину, яка
б’ється головою об цегляну стіну лише для того, щоб відчути,
як це добре, коли перестане. «Ми маємо визначити кращий
спосіб роботи, — сказав я їм, — і почати слід негайно».
І ми створили цілу невеличку компанію у формі єдиної

команди, поділеної на групи. При цьому премії базувалися
не на індивідуальній продуктивності, а на продуктивності
всієї компанії. Ми задіяли концепції та інструменти, які
десять років потому знайшли своє місце в Scrum (напри-
клад: власник продукту, беклог проекту та тижневі сприн-
ти), детальніше описані нижче та викладені в додатку. Че-
рез шість місяців ми стали найприбутковішим підрозділом
у компанії. Прибутки на 30 відсотків перевищили видатки.
Наші системи Nonstop Tandem стали першими онлайнови-

ми автоматами для транзакцій, яким банки довіряли до-
статньо, щоб їх використовувати. Ми розгорнули їх по всій
Північній Америці. У наші дні, у яку б частину країни ви
не поїхали, банкомат знайдеться скрізь. І всі ці машини
точно знатимуть, скільки грошей на вашому рахунку. Моя
команда добряче над цим попрацювала. Ага, нема за що.
ВЧИМОСЯ ДУМАТИ, ЯК РОБОТ

Після моєї першої кар’єри в армії, а другої — в освіті, при-
йшовши в бізнес, я почувався свого роду аутсайдером. Про-
те точка зору сторонньої людини якраз і стала одним із най-
цінніших моїх активів. З першого ж дня для мене стало
загадкою, чому люди наполягають на роботі способом, який
наперед є неефективним та марнотратним, дегуманізованим
і просто гнітючим. Гадаю, вони вважали, що так діють усі,
а тому він, мабуть, найкращий.
Мені дійсно подобалося працювати в MidContinent, але

я прагнув випробувати свої вміння та навички на нових
викликах. Закінчилося це тим, що протягом наступних двох
десятиліть я працював на великі й малі компанії на посаді
віце-президента з проектування або технічного директора.
У кожній з них я намагався досягти більш ефективної спіль-
ної роботи команд. Улаштувавшись в одну із цих компаній,
я опинився в Кембриджі, штат Массачусетс, усього за кіль-
ка кварталів від Массачусетського технологічного інститу-
ту (МТІ). Кілька тамтешніх докторів та професорів якраз
заснували нову компанію зі створення роботів, і їм стало
тісно в їхній лабораторії. Розглянувши різні варіанти, вони
орендували офісне приміщення в моєї компанії.
Через кілька тижнів після їхнього переїзду сталася геть неочі-

кувана річ: у мій кабінет забіг шестиногий робот завбільшки
з кота, який почав ганятися за мною навколо столу. Роз-

робники відразу забрали його та нервово вибачилися за
їхню машину, але кожні кілька днів це повторювалося зно-
ву. Один із роботів постійно тікав з лабораторії та починав
гасати будівлею. Я весь час чув клацання механічних ніг
у коридорах.
У мене тоді була одна традиція. Наприкінці дня в п’ятницю

я завжди виставляв у своєму кабінеті вино та пиво, щоб усі
члени команди могли розслабитись і неформально поспіл-
куватися після важкого тижня. На ці посиденьки я запрошу-
вав також моїх сусідів робототехніків, і однієї п’ятниці до
мене завітав Родні Брукс. Цей викладач штучного інтелекту
МТІ був одним із засновників компанії. Я спитав його, як
працюють ці бродячі роботи.
«Ми десятками років намагалися створити дійсно розумну

машину, — сказав він мені. — Витратили мільярди доларів
і багато-багато років праці, збудувавши найбільші комп’юте-
ри, які тільки могли, з найбільшими базами даних, але отри-
мали лише комп’ютер, здатний обіграти людину в шахи».
Він пояснив, що до його роботів застосовується зовсім інак-

ший підхід. Замість спроб побудувати щось із одним-єдиним
центральним мозком, вони збудували робота, у якого кожна
із шести ніг мала власний мозок. Процесор у спині мав лише
кілька простих правил: уперед, назад, не наступати на інші
ноги. Чип нейронної мережі в голові робота контролював
дотримання цих правил і діяв як рефері для всіх частин. Він
повідомляв ногам про те, що бачив крізь свою камеру, коли
натикався на перешкоду, — та й усе.
За словами Брукса, цікавим було те, що кожного разу, коли

робота вмикали, він учився ходити заново. У нього не було
бази даних про розташування інших предметів у кімнаті.
Натомість його базою даних був сам світ. Кожного разу
після вмикання він визначав розташування інших предме-

тів, немов уперше. Натикався на речі й сприймав їх як ре-
альне оточення, що означало його здатність адаптуватися
до будь-якого середовища.
«Давайте я вам покажу», — сказав Брукс, затягнувши мене

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

розробити набір простих інструкцій для груп людей працю-
вати разом, точно як оці ноги? Вони б самоорганізувались
та самооптимізувались, як і цей робот?
— Не знаю, — відповів він. — Чому б вам не спробувати це

й не повідомити мені, що із цього вийшло?
НЕ ЖЕНІТЬСЯ ЗА КАСКАДНОЮ МОДЕЛЛЮ

Я дедалі краще розумів: якщо зможу створити систему, яка,
подібно до цього робота, координуватиме незалежні центри
рішень із постійним відгуком про стан справ, буде досягнуто
значно вищих рівнів продуктивності. Розподіляючи потік

інформації між «ногами» групи, можна буде досягти ефек-
тивності, якої раніше не досягав ще ніхто.
Моя розмова з Родні Бруксом відбулася понад два десяти-

ліття тому. Протягом багатьох років він був завідувачем
кафедри робототехніки та штучного інтелекту МТІ, а той
схожий на павука робот, якого я бачив, на прізвисько Чин-
гізхан, тепер зберігається в музеї Смітсонівського інсти-
туту. Сьогодні ви, мабуть, чули про одну з компаній Брук-
са iRobot, що виробляє пилосос Roomba та використовує
для прибирання ваших кімнат той самий адаптивний ін-
телект, який Чингізхан використовував, щоб ганятися за
мною по кабінету. Його остання новинка в Rethink Robotics,
робот Бакстер, може успішно співпрацювати з людьми
в спільному робочому просторі.
Праця Брукса мене надихнула. І в 1993 році я приніс ці ідеї

із собою в компанію Easel, куди мене запросили на посаду
віце-президента з об’єктних технологій. Керівництво Easel
хотіло, щоб моя команда за шість місяців розробила абсо-
лютно нову серію продуктів для деяких із їхніх найбіль-
ших клієнтів, таких як Ford Motor, які використовували
їхнє програмне забезпечення в проектуванні та створенні
власних додатків. Я сів порадитись зі своїми розробника-
ми й сказав їм, що, на мою думку, вони не зможуть цього
зробити за допомогою старого способу розробки програм-
ного забезпечення.
Тією старою методикою була каскадна модель, яку я вже

описував у попередньому розділі: усе, що стосується про-
екту, ретельно зображувалося на масштабних діаграмах
Ґантта, кожне завдання точно оцінювалось у годинах і ви-
ділялося симпатичними кольорами, що стікали сторінкою,
немов каскад. Ці діаграми здавалися дуже гарними й точ-
ними, але були цілковитою нісенітницею.
Я знав, що в Easel каскадна модель викине нас за межі

дедлайнів на місяці, якщо не роки. Ми мали розробити
зовсім інакший спосіб управління проектами. Я пішов до
генерального директора і сказав, що діаграми Ґантта не для
нас. Він був шокований і вимагав пояснити чому.
— Скільки діаграм Ґантта ви бачили за свою кар’єру? —

спитав я.
— Сотні, — сказав він.
— А скільки з них справдилися?
— Жодної, — відповів він після паузи.
Саме тоді я й пояснив йому, що збираюся презентувати на-

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

документів, книжок та статей з організації команд і розроб-
ки продукту. А потім один розробник якось приніс статтю
з Harvard Business Review від 1986 року, написану двома
японськими викладачами економіки Гіротакою Такеучі та
Ікуджиро Нонакою. Вона називалася «Розробка нового про-
дукту. Нові правила гри». Такеучі та Нонака вивчали коман-
ди кількох найбільш продуктивних та інноваційних компа-
ній світу: Honda, Fuji-Xerox, 3M, Hewlett-Packard та інших.
Вони стверджували, що старий спосіб розробки продукту,
заданий фазовою системою планування програм NASA, —
каскадна модель — дефектний у своїй основі. Натомість най-
кращі компанії використовують ступеневий процес розроб-
ки, який є швидшим та гнучкішим. Ці команди мають
різнопрофільних фахівців, автономію та взаємопідтримку.
При цьому вони ставлять перед собою мету вийти за межі

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

била галасу, але то було за сім років до того, як ми прочи-
тали її в Easel. Усі нею захоплювались, але ніхто нічого із
цим не робив. Пересічний американський менеджер був
не здатний осмислити її ідеї, навіть попри те, що Toyota
швидко збільшувала свою частку ринку, використовуючи
цей підхід. В Easel нам не було чого втрачати. Ми виріши-
ли спробувати, хоча стаття й описувала більше виробничу
сферу, а не розробку програмного забезпечення. Я вважав,
що їхні ідеї приведуть до чогось фундаментального, проце-
дури, що описувала б найкращий спосіб співпраці людей
у будь-якій сфері діяльності. Адже вони чудово вкладалися
в усі інші експерименти, які я проводив іще з моєї першої
роботи у приватному секторі в MidContinent.
Це стало офіційним народженням Scrum. Ми здали гото-

вий продукт вчасно, ще до закінчення шести місяців, не пе-
ревищивши бюджет і з меншою кількістю помилок, ніж
у будь-якому попередньому замовленні.
Можливості цієї нової форми управління проектами так

мене надихнули, що вся моя майбутня робота зосередилась
на вдосконаленні Scrum для компаній. У 1995 році разом із
Кеном Швабером я презентував на дослідницькій конфе-
ренції Асоціації обчислювальної техніки працю під назвою

«Спосіб розробки SCRUM», яка систематизувала ці прак-
тики. Після того ми відмовилися від слів великими літера-
ми та дещо допрацювали цю ідею, але основні принципи
залишаються незмінними; а компанії, які прийняли цей
спосіб, зазвичай отримують негайні переваги2.
ПЕРЕВІРЯЙТЕ ТА АДАПТУЙТЕ
У системі Scrum команди, які добре працюють, здатні до-
сягти того, що ми називаємо гіперпродуктивністю. Важко
повірити, але серед груп, які добре впроваджують Scrum,
ми регулярно бачимо десь так від 300 до 400 відсотків
покращення продуктивності. Найкращі команди можуть
досягти підвищення продуктивності аж до 800 відсотків,
а потім повторювати цей успіх знову й знову. Крім того,
в результаті використання цієї системи подвоюється якість
їхньої роботи.
То як створити в Scrum-команді автономію, прагнення пе-

ревершити самих себе, взаємозаохочення — а потім досягти
гіперпродуктивності за рахунок поєднання всього цього?
Мова про це піде в решті розділів цієї книжки, але базові
принципи я збираюся подати вам тут. У скороченій формі їх
можна також побачити в додатку.
Оскільки Scrum бере початок із технік, використовуваних

у японському виробництві, не завадить трохи дізнатися,
звідки їх узяли японці. За іронією долі, вони багато чого
навчилися в одного американця — Вільяма Едвардса Де-
мінга. Під час американської окупації Японії після Дру-
гої світової війни Демінг працював на генерала Дуґласа
Мак-Артура. Підхід Мак-Артура до відновлення економіки
полягав у тому, щоб звільнити більшу частину вищого
керівництва японських компаній, підвищити керівників
середньої ланки та залучити до ділових операцій експертів

зі Сполучених Штатів, таких як Демінг. Вплив Демінга на
японське виробництво був надзвичайним. Він навчив сот-
ні інженерів того, що називається «статистичним контро-
лем процесів». Основною ідеєю було точне вимірювання
зробленого та його якості, а також прагнення до безперерв-
ного покращення. Не просто разового покращення, а по-
стійного. Слід завжди шукати, що можна покращити, і ні-
коли не зупинятися на досягнутому. Для цього потрібно
постійно проводити експерименти, які вказуватимуть на
можливість досягти кращих результатів. Якщо спробувати
цей метод, чи не буде він кращим за старий? Як щодо ін-
шого? Що як змінити один цей момент?
Відомий виступ Демінга перед керівниками японських під-

приємств у 1950 році. Серед слухачів були й такі люди, як
Акіо Моріта, засновник компанії Sony. Демінг тоді сказав їм:
…хоч які чудові у вас технічні фахівці, саме ви, лідери, по-
винні прагнути успіхів у покращенні якості та однорідності
продукції, а ваші техніки мають бути здатні на ці покращен-
ня. Отже, перший крок — за керівництвом. Перш за все,
техніки вашої компанії та робітники ваших заводів повинні
знати, що ви маєте завзяття для вдосконалення якості та
однорідності продукції, а також почуття відповідальності
за якість продукції.
Якщо лише говорити про це, нічого не вийде. Важливо діяти3.
Найбільше Демінг відомий якраз своїм методом дій — ци-

клом ПРПД (Планувати, Робити, Перевіряти, Діяти).
Цей цикл можна застосувати до виробництва практично
всього: автомобіля, відеогри чи навіть паперового літачка.
Коли я навчаю когось застосовувати Scrum, то використо-

вую саме їх — паперові літачки. Я поділяю людей на коман-
ди й ставлю перед ними завдання зробити якомога більше

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

цикли виробництва паперових літачків. Одну хвилину кож-
ного циклу команди мають Планувати, як вони збираються
робити літачки, три хвилин — Робити (виготовляти й тес-
тувати якомога більше літачків, дійсно здатних літати).
І нарешті, дві хвилини вони мають Перевіряти. На цьому
етапі команда дивиться, як можна покращити процес ви-
готовлення їхніх паперових літачків. Що пішло правильно?
Що — неправильно? Чи не слід змінити дизайн? Як можна
покращити процес виготовлення? А потім вони Діятимуть.
У системі Демінга «діяти» означає змінювати ваш спосіб
роботи на основі реальних результатів і реального впли-
ву зовнішніх умов. Та сама стратегія використовувалась
і в рóботах Брукса.
Пройдіть цей цикл тричі, і, хоч що ви виробляєте — папе-

рові літачки чи справжні космічні кораблі, — ви станете
кращими, значно кращими (прискорившись у два-три рази
і щонайменше подвоївши якість). Саме завдяки цьому ци-
клу Демінга — радикальній ідеї на той час, коли її презен-
тували японцям, — компанія Toyota і стала автовиробни-
ком номер один у світі. Саме так працює будь-який різновид
«ощадливого» виробництва (американський термін для
використання концепцій виробничої системи Toyota) або
розробка продукту в Scrum.
ЗМІНЮЙТЕСЬ АБО ПОМРІТЬ

Причина того, чому новий спосіб управління проектами
був таким важливим і чому стільки різних компаній його
прийняли, почасти полягала в надзвичайно поганому ста-
ні розробки програмного забезпечення. Проекти майже
завжди не вкладалися в строки та бюджет, а часто й взага-
лі не працювали. І це було не через тупість чи жадібність
людей — скоріше річ була в способі їхнього мислення про
роботу. Вони наполягали на застосуванні каскадної моделі,
казали, що все можна планувати заздалегідь, навіть що
умови не змінюються в ході багаторічного проекту. А це
вже просто божевілля перед лицем таких змін.
Я переконався в цьому на власному досвіді в компанії

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

визначити, що вони роблять неправильно. Дуже скоро
я зрозумів, що неправильним був увесь спосіб їхньої робо-
ти. Це може бути неприємно чути, коли вам здається, що
ви все робите як слід. Тому одного дня, коли я став перед
повною залою, де було 150 інженерів BellSouth, і сказав, що
якщо вони не перейдуть на іншу, більш інтерактивну мо-
дель, то не втримаються на поверхні, мене не схотіли слу-

хати. Вони всі були дійсно розумними людьми, але вважа-
ли мої ідеї черговою управлінською маячнею.
Я ніяк не міг переконати їх, тому просто знизав плечима

й пішов, залишивши їм останнє попередження: «Змінюй-
тесь або помріть»… Компанії BellSouth більше не існує.
ШУ-ХА-РІ
Коріння Scrum проростає з японського мислення та прак-
тик. Коли я нещодавно їздив до Японії, щоб зустрітися
з професором Ікуджиро Нонакою, він пояснив мені, що
в його країні Scrum аж ніяк не вважається новомодною
управлінською дурницею. До нього ставляться як до спосо-
бу дій, способу існування, способу життя. Навчаючи людей
застосовувати цю систему, я часто розповідаю про мій влас-
ний досвід вивчення японського бойового мистецтва айкі-
до протягом кількох років.
Подібно до айкідо чи, можливо, танго, Scrum є чимось, що

дійсно можна вивчити лише на практиці. Завдяки постійній
практиці та вдосконаленню ваше тіло, розум і дух з’єднують-
ся в одне ціле. У бойових мистецтвах ви вивчаєте концепцію
під назвою Шу-Ха-Рі, яка вказує на різні рівні майстерності.
У стані Шу ви знаєте всі правила та форми. Ви повторюєте
їх, наче танцювальні па, тому ваше тіло всотує їх. При цьому
ви не відхиляєтесь ані на крок.
У стані Ха, опанувавши форми, ви можете робити щось

нове. Наприклад, додавати нові повороти до ваших танцю-
вальних па.
У стані Рі ви вже здатні відкинути форми, які дійсно опану-

вали на практиці, й вільно творити, адже знання суті айкідо
чи танго так глибоко вкорінилось у вас, що її відображує

кожен ваш крок.
Scrum дуже подібний до цього. Він потребує практики та

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

досягти цього стану в їхньому житті. Робота зовсім не повин-
на вас засмоктувати. Вона може плинути потоком, бути ви-
явленням радості, шляхом до вищої мети. Ми можемо бути
кращими. Можемо бути великими майстрами своєї справи!
Нам просто потрібна практика.
Решту розділів цієї книжки я присвячую розгляду конкрет-

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

тесь, Вирішуйте, Дійте. Знайте, де ви є, оцінюйте свої
варіанти, приймайте рішення та дійте!
Шукайте відповіді ззовні. Складні адаптивні системи

дотримуються кількох простих правил, які вони засвою-
ють із довкілля.
Видатні команди мають свої особливості. Це різно-

профільні фахівці, автономія та взаємопідтримка.
Не гадайте. Плануйте, Робіть, Перевіряйте, Дійте.

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

тільки опануєте їх, вносьте щось нове. Наприкінці, досяг-
нувши стану високої майстерності, відкидайте форми
і просто будьте — глибоко засвоївши все вивчене та
приймаючи рішення майже підсвідомо.
РОЗДІЛ 3. КОМАНДИ
58 Команди
Саме команди виконують проекти у світі праці. Існують

команди, які виробляють автомобілі, відповідають на теле-
фонні дзвінки, проводять хірургічні операції, програмують
комп’ютери, готують новини та проникають у двері захо-
плених терористами приміщень. Безумовно, існують також
окремі ремісники чи художники, які виконують роботу са-
мотужки, але саме команди обертають Землю. І саме на них
базується Scrum.
Усі це розуміють, але в бізнесі ми надто часто зосереджує-

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

що це інтуїтивно здається їм правильним. Ви хочете мати
найкращих людей, а люди різні, тому зосередьтесь на най-
кращих виконавцях, і ви матимете кращі результати, прав-
да? На жаль, усе не так просто.
Візьмімо, наприклад, процедуру отримання студентами

оцінок під час занять. У Єльському університеті особливо
складним вважається курс комп’ютерного програмування
професора Стенлі Айзенштата CS 323. Коли студенти поча-
ли скаржитись на те, скільки часу займає кожне завдання,
професор не зробив своє завдання простішим, а почав від-
стежувати, скільки часу потрібно кожному студентові на
його виконання. Потім Джоел Спольскі, який пройшов курс
Айзенштата в далекі 1980-ті, а тепер має власний бізнес
із програмного забезпечення, порівняв отримані дані з ре-
альними оцінками, які люди отримували. Він хотів з’ясу-
вати, чи існує якась кореляція між часом, витраченим на
проект, і отриманою студентом оцінкою. Цікаво, що не іс-
Команди 59
нує. Одні люди працюють швидко й отримують «відмінно»,

а інші працюють довго, а отримують те саме. Єдиною різ-
ницею є кількість витраченого на завдання часу. Як же
застосувати це в бізнесі?
Ну, якщо ви менеджер, то вам, схоже, краще найняти не

просто робітників, які отримують оцінки «відмінно», а тих,
хто отримує їх за найкоротший час. У Єльському дослі-
дженні найшвидші студенти перевершували своїх повіль-
них товаришів у співвідношенні 10 : 1. Вони були в десять
разів швидшими, а оцінки отримували такі самі високі.
У десять разів — це вражає, так? Тому схоже, що компанії
мають наймати найшвидших людей і позбуватися повіль-
них. Це здається найкращим підходом до підвищення
продуктивності, але інші чинники можуть бути ще важ-
ливішими.
Якщо ви поглянете на команди, а не на окремих осіб, то

побачите дещо цікаве. Існують дослідження, де перегляну-
то близько 3800 різних проектів, від виконання роботи
в бухгалтерських фірмах до розробки програмного забез-
печення для бойових кораблів і технічних проектів в ІВМ.
Аналітики дивилися на дані продуктивності не окремих
осіб, а лише команд. І, якщо вивчити, як працювали коман-
ди, ви побачите щось дивне. Якщо найкраща команда мог-
ла виконати завдання за тиждень, скільки, на вашу думку,
це займало в найгіршої команди? Ви, можливо, гадаєте, що
вийшло співвідношення, яке спостерігалось у Єлі, — 10 : 1
(тобто повільній команді потрібно було понад два місяці,
щоб досягти того, що швидка команда робила за тиждень).
Однак правильна відповідь та, що між командною й інди-
відуальною продуктивністю існує значно більша різниця.
Насправді повільній команді треба було не десять тижнів
на роботу, яку швидка команда могла виконати за тиждень,
а дві тисячі тижнів. Отакою великою є різниця між най-
кращою і найгіршою командами. То на чому слід зосередити
60 Команди
вашу увагу? На індивідуальному рівні, де ви можете досяг-

ти покращення в десять разів, якщо якимось дивом зроби-
те всіх своїх працівників геніями? Чи на командному рівні,
де можна збільшити продуктивність до нечуваних розмірів,
навіть якщо просто зробити свої найгірші команди посе-
редніми? Звичайно, якщо націлюватись на посередність,
то її ви й отримаєте. Але що, як ви зможете зробити всі свої
команди найкращими?
У певний час у певному місці з певними невеликими гру-

пами людей усе стає можливим. Навіть якщо ви ніколи
не мали таких команд, ви бачили їх у дії. Ви чули про них
захоплені розповіді. Про їхні можливості складають ле-
генди. Особисто я виріс поблизу Бостона і живу там за-
раз, а тому мені спадають на думку такі видатні команди,
як Celtics 1980-х у баскетболі чи New England Patriots
часів Тома Брейді в американському футболі. Коли ці
команди виходили на поле, здавалося, вони грають не
в ту гру, що всі інші. Пересування, кидки та удари, які
колись здавалися неможливими, раптом стали звичай-
ною частиною плану гри. Це було так, наче на цих грав-
ців спустилося просвітлення і деякий час вони просто
не могли помилятися. Ларрі Берд рухався майданчиком
і пасував м’яч навіть не дивлячись, здавалося б, у порож-
нечу. Але, коли м’яч уже виходив за межі поля, Кевін
Мак-Гейл просто виникав саме там, де він і мав бути.
А потім кидав м’яч на край знову, наче не дивлячись, —
і Роберт Періш тут-таки опинявся в ідеальній позиції для
кидка. Таке абсолютне поєднання мети й довіри якраз
і робить команду видатною.
Нам усім випадало бачити такі команди. Декому з нас

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

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

описане те, що пізніше стало Scrum, професори Такеучі та
Нонака дали характеристики команд, які вони бачили
в найкращих компаніях світу.
1. Надзвичайні. Вони мають відчуття надзвичайної мети.

Ця вища мета дозволяє їм переходити зі звичайних у над-
звичайні. Цілком реально саме рішення бути не пере-
січними, а видатними змінює їхній погляд на самих себе
та свої можливості.
2. Автономні. Ці команди самоорганізовані й самокерова-

ні. Вони мають право приймати власні рішення про свою
роботу та втілювати їх у життя.
3. Багатофункціональні. Ці команди мають усі вміння

й навички, необхідні для виконання проекту: плануван-
ня, проектування, виробництва, продажів, дистрибуції.
Причому ці навички підживлюють та підсилюють одна
одну. Один із членів команди, яка розробила револю-
ційну нову камеру для Canon, описав це так: «Коли всі
члени команди перебувають в одній великій кімнаті,
чиясь інформація стає вашою навіть без зусиль. Потім
ви починаєте мислити категоріями того, що стоїть на
першому або на другому місці для групи загалом, а не
лише для вашої ділянки»1.
То як створити команду, націлену на вищу мету, самоорга-

нізовану та постійно підживлювану вміннями й навичками
кожного її члена? Я витратив чимало часу, щоб це зрозуміти.
62 Команди
Зрештою, не можна просто кричати на людей, щоб вони

були більш самоорганізовані та надзвичайні. Мотивація має
йти зсередини. Її нав’язування просто вб’є те, що ви намага-
єтесь зробити. Можливо, існує якийсь простий набір правил,
що заохочують до створення дива?
ДОВГА СІРА ЛІНІЯ

Я повертаюся думками до того часу, коли був частиною од-
нієї з таких дивовижних команд. Це було на початку 1960-х,
коли я навчався у Військовій академії Сполучених Штатів,
більш відомій як Вест-Пойнт. В останній рік там я був при-
значений інструктором моєї кадетської роти L2, яку ще на-
зивали «Вільною парою»*.
У 1963 р. у Вест-Пойнті було двадцять чотири роти з номе-

рами від A1 до M1 та від A2 до M2. Тричі на тиждень ці роти
виходили на плац і карбували крок у повній парадній фор-
мі, з гвинтівками на плечі та шаблями на боці, білими ре-
менями та погонами. Ці парадні шикування були в Акаде-
мії справжніми змаганнями протягом майже двох століть.
На той час наша рота вже більш як сто років пасла задніх
у загальному заліку.
Інструктор не має прямої влади. Він не входить до коман-

дування ротою. Ніхто йому не підпорядковується. Ніхто
не зобов’язаний робити те, що він каже. Але після кожно-
го параду всі інструктори збираються разом і оцінюють
кожну роту за різноманітними критеріями. Як інструктор,
я вирішив, що можу зробити ситуацію більш зрозумілою
для кадетів. Я підготував кольорові схеми того, що йшло
правильно, і того, що йшло неправильно, а потім розвісив
* Пара винищувачів, завданням яких є спостереження за ходом бою та

знищення окремих літаків супротивника. (Прим. перекл.)
Команди 63
їх у казармі, де всі хлопці з моєї роти могли бачити їх кож-

ного дня.
Спочатку зауваження були простими. «Чарлі встромив ша-

блю в багнюку». «Джим не розвернувся синхронно з усіма».
«Салют Дейва вийшов недостатньо чітким». Не було жодних
покарань чи звинувачень. Були просто факти, викладені
всіма іншими інструкторами під час оцінювання. Однак це
були причини, чому L2 посідала останні місця в рейтингу.
Через кілька тижнів кадети відточили свою техніку шику-

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

Дуґлас Мак-Артур. Він мав найвищі оцінки з усіх кадетів, які
звідти випустились, і був провідним полководцем в обох сві-
тових війнах. Як генерала армії та кавалера медалі Пошани,
у кадетському корпусі його особливо поважали.
За рік до того як я став інструктором своєї роти, у травні

1962-го, він виступив у нас зі своєю останньою промовою.
Щоб повністю зрозуміти її вплив на кадетів, ви маєте на-
лежним чином уявити собі цю сцену. У величезній кам’яній
залі з масивними колонами та гігантськими люстрами, що
звисають зі стелі, зібрались три тисячі чоловіків у сірій
кадетській формі. Біля однієї стіни над усією залою здій-
мався поміст заввишки в десять метрів. Генерал Мак-Ар-
тур, тоді вже доволі немічний, зійшов на поміст і виступив
64 Команди
із промовою, яку сьогодні називають «Довга сіра лінія»

(за кольором форми кадетів).
Ви — цемент, який з’єднує всю будівлю нашої національ-

ної системи оборони. З ваших лав виходять видатні пол-
ководці, які беруть у свої руки долю Нації, коли зазвучать
набати війни.
Довга сіра лінія ніколи нас не підводила. І, якщо вам дове-

деться піти в бій, мільйони солдатських душ в оливковому,
хакі, синьому та сірому піднімуться з-під своїх білих хрестів,
карбуючи ці магічні слова: Обов’язок, Честь, Батьківщина2.
Я пам’ятаю, як при цьому всім здалося, що за спиною Мак-Ар-

тура, який залишав кадетам свій останній заповіт, дійсно
вишикувався цей легіон солдатських душ. І три тисячі муж-
ніх чоловіків, загартованих для війни, яким не так легко
заплакати, не могли стримати сліз.
Уві сні я знову чую гуркіт гармат, автоматні черги, дивне та

скорботне гудіння поля бою. Але наприкінці своїх днів я по-
думки повертаюся до Вест-Пойнту. Адже там завжди луна-
ють ці слова: Обов’язок, Честь, Батьківщина.
Сьогодні моя остання вечірня повірка разом із вами. Але

я хочу, щоб ви знали: коли я піду назавжди, мої останні сві-
домі думки будуть про кадетський корпус, знову і знову3.
Досі кожен кадет в Академії перед випуском зобов’язаний

вивчити цю промову напам’ять, рядок за рядком, слово за
словом. Вона стала духовною настановою кадетського кор-
пусу та офіцерського корпусу США загалом: Обов’язок,
Честь, Батьківщина.
Майже через рік після тієї промови генерал Мак-Артур по-

мер. Потрібно було обрати одну з рот для урочистого маршу
Команди 65
на його похороні. І що ви думаєте? Під траурний барабанний

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

зі своєю ротою під час церемонії випуску з Вест-Пойнту.
Марширували всі двадцять чотири роти, і через її місце в ал-
фавіті L2 йшла передостанньою. Після церемонії мій май-
бутній тесть спитав мене:
— Оця рота, друга з кінця. Вони відрізнялися від усіх реш-

ти. Інші маршували, а вони, здавалось, не торкалися землі.
Хто це був?
— Це була моя рота. — сказав я йому. — Ці люди ховали ге-

нерала Мак-Артура.
Моя рота досягла надзвичайності.
SCRUM ПІД ЧАС РЕВОЛЮЦІЙ

Часто, коли люди говорять про видатні команди, то згадують
лише надзвичайне відчуття мети. Але, хоча це й дуже важ-
ливий елемент, це тільки одна ніжка триногого табурета. Не
менш важливою, але, мабуть, менш помітною є свобода ви-
конувати вашу роботу способом, який ви вважаєте найкра-
щим, — мати автономію. Усі видатні команди залишають
своїм членам вирішувати, як саме досягти цілей, поставле-
них керівництвом організації.
Площа Тахрір сьогодні вже стала синонімом єгипетської

революції та невпинної боротьби в цій країні, але до січня
2011 року це була просто ще одна брудна, забита транспор-
том кільцева розв’язка в центрі Каїра. На північ від неї
66 Команди
розташована рожево-червона будівля Єгипетського музею,

на південь — високі стіни Американського університету
в Каїрі та знаменита урядова будівля Моґамма. На заході
ви знайдете штаб-квартиру Національної демократичної
партії єгипетського диктатора Хосні Мубарака, а також
штаб-квартиру Ліги арабських держав. Хоч як дивно, на
східному кінці площі був американський фастфуд KFC, що
невдовзі став тилом для протестувальників, які кидали
каміння та тіснили поліцію.
Наприкінці січня 2011 року невелика група людей вирі-

шила влаштувати всередині цього транспортного кільця
демонстрацію протесту проти жорстокого вбивства єги-
петською поліцією молодого чоловіка на ім’я Халед Саїд.
Але те, що мало б стати черговим невеликим протестом
проти репресивних дій режиму, перетворилося на іскру,
яка розпалила уяву єгиптян і врешті-решт вивела на пло-
щу мільйони людей.
А в наступному місяці сталося неймовірне. Лише через те,

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

ваги. Серед тих, хто приїхав до Каїра її висвітлювати, була
й бригада Національного громадського радіо (NPR), одно-
го з провідних медіа Сполучених Штатів. Але спочатку про-
дюсери та репортери були настільки заскочені зненацька,
що не встигали за подіями, губили матеріали, плутали ре-
портажі та ледь-ледь задовольняли вимоги свого керівни-
цтва у Вашингтоні.
Команди 67
Виправити ситуацію був посланий Джей Джей Сазерленд,

мій син. Як досвідчений військовий кореспондент та про-
дюсер, він був направлений до Каїра, щоб узяти на себе
безперервну підготовку репортажів. Адже події там набули
надто великого масштабу, щоб не виходити в ефір кожного
дня, у кожному випуску новин та кожної години. Джей
Джей опинився в країні, де не працювали аеропорти, іно-
земці відчайдушно намагалися виїхати, а мобільний зв’я-
зок та Інтернет були відключені. Він був там старшим про-
дюсером, але (дуже подібно до інструктора у Вест-Пойнті)
продюсер NPR є радше не типовим менеджером чи керів-
ником, а посередником та організатором — тим, хто допо-
магає чи сприяє. Завданням Джей Джея було допомагати
команді виконувати найкращу роботу, яку вони тільки мог-
ли. Не розповідати їм, що робити, а забезпечувати їх усім
потрібним. Керівництво наказувало готувати репортажі та
виходити в ефір кілька разів на день, а вже як це зробити,
визначала сама команда на місці, вирішуючи, що саме ви-
світлювати і в якому форматі радіопередачі.
На диво, через деякий час команда почала успішно працю-

вати, причому саме через складнощі зв’язку з вашинг
тонським керівництвом. Адже радійникам довелося діяти
переважно на власний ризик. Постійні прямі вказівки
отримувати було просто неможливо, а події розвивалися
дуже швидко, тому для виконання роботи команді довело-
ся самоорганізовуватись. Однією з ключових концепцій
у системі Scrum є якраз те, що члени команди самі вирішу-
ють, як вони збираються працювати. Керівництво відпові-
дає лише за виставлення стратегічних цілей, а вже як їх
досягти, має вирішувати команда. Той, хто не був тоді в Ка-
їрі, просто не міг слідкувати за тим, що відбувається. Май-
же щодня команда NPR готувала низку репортажів на на-
ступний день, але події змінювались так блискавично, що
всі ці повідомлення майже миттєво застарівали. На площі
Тахрір відбувалася масштабна сутичка, лунала якась гучна
68 Команди
заява, хтось подавав у відставку, і вся робота команди йшла

псу під хвіст. Раптом виявлялося, що їм майже нема чого
вчасно видати в ефір.
Успіху ж їм вдалося досягти за допомогою Scrum. Вказівки

керівництва вимагали від них виходити з репортажами кож-
ні дванадцять годин: у вранішньому випуску та у вечірньому
підсумковому. Щоразу Джей Джей звертався до команди
й ставив їм три дуже прості запитання: «Що ви робили із
часу нашої останньої розмови? Що ви збираєтеся робити до
нашої наступної розмови? І що стоїть у вас на шляху?» Цей
звичайний ритуал Scrum змушував кореспондентів говори-
ти й ділитися один з одним своїми думками. Але головною
роботою Джей Джея, як де-факто Scrum-майстра, було сте-
жити, щоб перешкоди, на які скаржилися члени команди на
одній зустрічі, усувалися до наступної. Перешкодою могло
бути що завгодно — від проблем з єгипетською бюрократією
до відсутності безпечного готельного номера, від пошуку
водіїв та перекладачів до визволення кореспондентів із ка-
тівень жахливої єгипетської таємної поліції «Мухабарат».
Як же це все покращилось? Можу вас запевнити, що хаос,

пов’язаний із загальною непевністю, особистими сварками
та нездатністю миттєво видавати новини, швидко перетво-
рився на добре змащений механізм, яким начальству навіть
не доводилось керувати. Натомість члени команди керува-
ли самі собою. Протягом наступних кількох тижнів брига-
да NPR у Каїрі підготувала більше репортажів, ніж хтось
узагалі вважав за можливе. Причому якість усіх цих новин
була вищою, ніж пропонували конкуренти, за що журна-
лісти врешті-решт отримали навіть кілька нагород. То був
справжній успіх, якого не вдалося б досягти, якби команду
не захопило відчуття мети (розповісти про одну з найви-
датніших подій у їхній кар’єрі) і якби вона не мала авто-
номії (здатності самим вирішувати, як висвітлювати різні
аспекти великої події).
Команди 69
Сьогодні Scrum використовується в усіх сферах роботи На-

ціонального громадського радіо — від веб-дизайну до жур-
налістського збирання даних та створення нових передач.
Використовують його також команди Chicago Tribune, New
York Times, Washington Post і ProPublica. Адже, коли дед-
лайни підпирають, швидкість потрібна всім.
ОДНА КОМАНДА ДЛЯ ВСІЄЇ РОБОТИ

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

ма», за допомогою якої розробляли програму космічних
шатлів та інші проекти NASA в 1960-ті — 1980-ті роки. Сьо-
годні ця модель дуже змінилась, але ось як вона працювала
колись. Першою йшла фаза дослідження, коли люди вирі-
шували, на що вони збираються замахнутись — можливо,
збудувати ракету, що полетить на Місяць. Група стратегів
збиралась у кімнаті й починала про це фантазувати. А далі
йшла «брама», коли менеджер або група менеджерів під-
писували проект як вартий розробки. Другою фазою було
визначення масштабу робіт, коли спеціалісти з вимог та
стандартів вирішували, що має бути зроблено. Потім ішла
друга «брама» та ще ряд зустрічей, після яких усі підгото-
вані документи вели до наступної фази — створення під-
приємницького завдання та плану проекту. Далі всі ці пла-
ни проходили ще ряд обговорень та узгоджень, після чого
наставала ще одна фаза — розробки, де починалося справжнє
70 Команди
створення продукту. Пройшовши ще кілька обговорень та

процес підготовки документів, продукт передавався абсо-
лютно іншій групі для наступної фази — тестування. Ці
люди ніколи не бачили продукту раніше, але тестували
його, підписували, що з ним усе гаразд, а потім проштов-
хували його до наступної «брами» або ряду нескінченних
обговорень, із наступною купою документів, яких ніхто
не читав. І лише після цього продукт потрапляв до шостої
групи людей, які дійсно вводили його в експлуатацію. Вис-
нажливо навіть просто писати про це. А для NASA така
робота була звичною.
Якось на початку 1980-х керівники компанії Fuji-Xerox

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

Вільяма Роджерса, яка розслідувала причини катастрофи
космічного корабля «Челленджер» у 1986 році. Як написав
у своєму відомому «Додатку F» до звіту комісії фізик Річард
Фейнман: «Цілком може виявитись, що з будь-якою метою,
чи то для внутрішнього споживання, чи то для зовнішньо-
го, керівництво NASA перебільшує надійність своєї продук-
ції до фантастичних показників»4.
Факт залишається фактом: якщо поглянути на найкращі

команди (схожі на ті, що існували в Toyota чи 3M, коли
Такеучі й Нонака писали свою працю, або на ті, що існують
у Google, Salesforce.com чи Amazon сьогодні), ви не поба-
чите там такого розподілу ролей. Члени всіх команд разом
виконують усю роботу, від початку до кінця.
Команди 71
Розгляньмо інший приклад. У компанії Salesforce.com за

гнучку інфраструктуру релізів відповідає Нікола Дурамбе.
Вона керує роботою приблизно двохсот Scrum-команд у ком-
панії, яка постійно потрапляє в рейтинги ста найкращих
роботодавців за версією журналу Fortune та найбільш інно-
ваційних компаній світу за списком Forbes. Вона каже, що
вважає Scrum «таємним соусом» своєї роботи. «Коли ми
були стартапом, то робили якийсь великий реліз три чи чо-
тири рази на рік. Але в 2005—2006 роках, коли ми зросли та
розширились, управляючи проектами типовим каскадним
способом, цей показник упав до одного разу на рік. Так за-
лишати було не можна. Тому ми запровадили Scrum. Після
того релізи в нас пішли тричі на рік. Не так уже багато вели-
ких підприємств здатні похвалитися тим самим».
У будь-якій команді вона шукає різноманіття — вмінь та

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

лягає в тому, що вона питає, скажімо, інженера мережі:
«У якій ви команді?» Якщо спеціаліст відповідає, згадуючи
продукт, над яким вони працюють (наприклад, автоматиза-
ції чи інтеграції), а не свою спеціальність (розробку мереж),
вона схвально киває. Якщо ж він ідентифікує себе більше зі
спеціальністю, ніж із продуктом, який наразі готують, Ду-
рамбе знає, що їй треба працювати далі.
SCRUM ПІД ЧАС ВІЙНИ

Одним із найбільш вражаючих прикладів багатофункціо-
нальних команд є військова служба. Адже саме за цим
принципом працюють американські сили спеціального
72 Команди
призначення. Типова армійська «команда А» (загін «Аль-

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

ня показали, що вони надзвичайно добре вміють убивати
людей. Вони могли виявити ціль та знищити її в одну ніч.
Між 2003 і 2007 роками вони виконали тисячі завдань,
спрямованих на придушення іракського спротиву, особли-
во терористичної діяльності «Аль-Каїди». У своїх завданнях
вони майже завжди досягали тактичного та оперативного
успіху. Їхні багатофункціональні, чудово підготовані ко-
манди стали однією з найбільш смертоносних сил, які
колись бачив світ. Однак, попри всі свої вміння, навички
й таланти, вони мали майже нульовий стратегічний вплив.
Протягом цих перших чотирьох років війни атаки на аме-
риканські сили та іракських цивільних лише посилювали-
ся мало не щодня. У деякі найчорніші дні війни на амери-
канських військових здійснювалося більш ніж сто нападів,
і навіть смертоносність сил спеціального призначення не
могла цьому зарадити. Наприкінці 2006 та на початку
Команди 73
2007 року майже всі компетентні коментатори вважали

Ірак справою безнадійною. Кожна нова загибель американ-
ця почала розглядатись як марна жертва.
А потім у 2007-му генерал Девід Петреус очолив стратегію,

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

пристрій чи безпілотник. Генерал Стенлі Мак-Крістал, на
той час начальник управління спеціальних операцій, на
звав цю стратегію «спільним веденням війни». Вона перед-
бачала виявлення та знешкодження мережі «Аль-Каїди»
за участю багатофункціональних команд з усіх підрозділів,
підпорядкованих уряду США. У статті від 6 вересня 2008 року
газета Washington Post описала її так:
ЦРУ забезпечує аналітиків розвідки та шпигунську техніку

з різними датчиками й камерами, здатними відстежувати
цілі, транспортні засоби чи військову техніку впродовж
14 годин. ФБР надає експертів-криміналістів, які ретельно
вивчають отримані дані — від інформації з мобільних теле-
фонів до вмісту кишень та гаманців екстремістів. Співробіт-
ники міністерства фінансів відслідковують грошові потоки
серед екстремістів та від урядів, які їх підтримують. Штатні
74 Команди
працівники Агенції національної безпеки перехоплюють

переговори та комп’ютерні файли, а фахівці Національної
агенції геопросторової розвідки використовують високо-
технологічне обладнання для точного визначення місця,
де підозрювані екстремісти користуються телефонами чи
комп’ютерами5.
Разом вони створили багатофункціональну команду, що

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

передавала всі матеріали силам спеціального призначен-
ня, які й діяли далі. Після цього спецпризначенці, у свою
чергу, передавали всю зібрану ними розвідінформацію
іншій команді для аналізу. Ті, хто мав справу з такою мо-
деллю, відчув на собі те саме, що й компанія Fuji-Xerox
тоді, коли японці намагалися запровадити в себе систему
поетапного планування NASA, і це стало однією з голов-
них причин розроблення Scrum. Скрізь, де між командами
відбуваються такі передачі справ, існує небезпека катастро-
фи. У статті в журналі міністерства оборони США Joint
Force Quarterly під назвою «На службі розвідки, спосте-
реження та рекогносцирування: найкращі практики спец-
назу» про це говориться так:
Міжвідомчі групи дозволили позбутись організаційних

«швів» між різними силами коаліції в Іраку, приставивши
до пріоритетних цілей «незмигне око»… Адже передача
обов’язків між підрозділами та організаціями являла собою
«мигання», під час якого сповільнювалась динаміка і ціль
могла втекти6.
Команди 75
Налагодити обмін інформацією та ресурсами, як у цьому

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

бюрократична підтримка міжвідомчих команд почала зни-
жуватись. До 2008 року управління й агенції, особливо
одна розвідувальна агенція, яка залишилась неназваною,
почали відкликати своїх людей і згортати спільну діяль-
ність, вважаючи, що обмін інформацією та співпраця над-
то далеко зайшли7.
Найпотужнішу зброю в арсеналі Америки, яку Боб Вудворд

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

ті в найкращих командах, попри всю ефективність, несуть
у собі загрозу структурам, заснованим на таємничості та
звичці все заплутувати. Менеджери часто не бажають, щоб
інші менеджери, їхні власні команди або якісь інші люди
всередині керівництва точно знали, чим вони займаються,
чого досягли і як швидко. Вони вважають, що зберігання
цього в таємниці надзвичайно важливе для їхньої влади.
Замість того щоб діяти за спільними інтересами, вони діють
за власними мотивами, які часто зводяться до жадібності та
амбіцій. Саме такий спосіб мислення і призвів до масштаб-
них управлінських провалів, що спричинили нещодавню
світову економічну кризу. Дії багатьох компаній були засно-
вані виключно на короткострокових перевагах для окремих
осіб. Про загальну користь або обмеження шкоди для гло-
бальної економіки ніхто не думав.
РОЗМІР МАЄ ЗНАЧЕННЯ, АЛЕ НЕ ТАК,

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

са», уперше виведений Фредом Бруксом ще в 1975 році у його
новаторській книжці «Міфічна людина-місяць». Якщо стис-
ло, закон Брукса каже: «Додавання людських ресурсів до
простроченого проекту програмного забезпечення затримує
Команди 77
його ще більше»8. Слушність цього підтверджено багатьма

дослідженнями. Зокрема, вивченню того, скільки часу за-
ймає робота і чому, присвятив своє життя Лоренс Патнем —
легендарна фігура в розробці програмного забезпечення.
Його праці незмінно демонструють, що проекти, в яких бра-
ли участь двадцять чи більше людей, потребували більших
зусиль, ніж ті, де виконавців було п’ятеро чи менше. Причо-
му не трохи, а набагато. Великій команді зазвичай потрібно
в п’ять разів більше годин, ніж малій. Патнем спостерігав це
знову й знову, а в середині 1990-х років вирішив спробувати
провести широкомасштабне дослідження, щоб визначити
ідеальну чисельність команди. Для цього він переглянув
491 проект середнього розміру сотень різних компаній. Усе
це були проекти, що вимагали створення нових продуктів
чи властивостей, а не перепризначення старих версій. Він
розподілив ці проекти за розміром команди й одразу дещо
помітив. Як тільки чисельність команд перевищувала вісім
людей, виконання роботи починало займати в них значно
більше часу. Групи, що нараховували від трьох до семи осіб,
потребували для виконання однакового обсягу роботи —
приблизно 25 відсотків зусиль груп, де було від дев’яти до
двадцятьох виконавців. Цей результат повторювався в сот-
нях проектів. Те, що дуже великі групи роблять менше, зда-
ється, є залізним правилом людської природи.
Але чому? Щоб відповісти на це запитання, слід розглянути

обмеженість людського мозку. Ви, можливо, чули про кла-
сичне дослідження Джорджа Міллера, яке в 1956 році пока-
зало: максимальна кількість речей, що можуть зберігатися
в короткотривалій пам’яті пересічної особи, становить сім.
Ось тільки проблема з висновками Міллера в тому, що пізні-
ше дослідження довело їхню помилковість.
У 2001 році Нельсон Ковен з Університету Міссурі вирішив

перевірити правильність магічного правила семи та про-
вів усебічне вивчення всіх нових досліджень на цю тему.
78 Команди
Виявилося, що кількість елементів, які людина може збе-

рігати у своїй короткотривалій пам’яті, не сім. Це чотири9.
Люди часто думають, що можуть запам’ятати більше, ви-
користовуючи якісь спеціальні пристрої чи просто силь-
ніше концентруючись. Але дослідження абсолютно чітко
показують: ми здатні запам’ятати лише чотири «шматоч-
ки» даних. Класичним прикладом є дати комусь такий ряд
із дванадцяти літер: дпанбумвфєцб. Як правило, люди
можуть запам’ятати близько чотирьох із цих літер — якщо
тільки не помітять, що їх можна поділити на добре відомі
абревіатури: ДПА (Державна податкова адміністрація),
НБУ (Національний банк України), МВФ (Міжнародний
валютний фонд), ЄЦБ (Європейський центральний банк).
Якщо вам вдасться пов’язати речі у вашій короткотрива-
лій пам’яті з асоціаціями довготривалої пам’яті, ви зможе-
те утримати в голові більше. Але задіяна частина розуму —
свідома частина — може утримати за раз лише приблизно
чотири різні елементи.
Таким чином, існує глибоко вкорінене обмеження щодо

того, скільки речей наш мозок може утримувати одночасно.
Це відсилає нас знову до Брукса. Намагаючись визначити,
чому додавання людей затримує виконання проекту, він
відкрив дві причини. Першою є час, необхідний людям,
щоб набрати потрібну робочу швидкість. Як ви, мабуть,
розумієте, введення нового виконавця в курс справи затри-
мує всіх інших. Друга причина пов’язана не лише з тим, як
ми думаємо, але й, доволі буквально, з тим, про що наші
мізки здатні думати. Зі збільшенням кількості людей знач-
но збільшується кількість комунікаційних каналів, і наш
розум просто не може із цим упоратись.
Якщо ви хочете розрахувати вплив розміру групи, візьміть

кількість людей у команді, помножте її на цю саму кількість
мінус один і поділіть на два. Кількість комунікаційних кана-
лів = n (n–1)/2. Таким чином, наприклад, якщо у вас є п’я-
Команди 79
теро людей, ви маєте десять каналів. Шість людей — п’ят-

надцять каналів. Сім — двадцять один. Вісім — двадцять
вісім. Дев’ять — тридцять шість. Десять — сорок п’ять. Наші
мізки просто не можуть дати раду зі стількома людьми за
раз. Ми не знаємо, що вони всі роблять. І, намагаючись це
визначити, ми сповільнюємось.
Як і в загоні спеціального призначення, у Scrum усі члени

команди також мають знати, що роблять усі інші. Уся ви-
конувана робота, нові виклики, досягнутий прогрес мають
бути прозорими для решти виконавців. І, якщо команда
стає надто великою, здатність кожного чітко спілкуватися
з усіма іншими в будь-який час погіршується. Адже з’явля-
ється забагато перехресних зв’язків. Дуже часто команда
соціально та функціонально розбивається на підкоманди,
які починають працювати над досягненням невідповідних
одна одній і навіть протилежних цілей. Багатофункціональ-
ність утрачається. Зустрічі, що раніше тривали хвилини, за
таких умов розтягуються на години.
Не робіть цієї помилки. Команди мають залишатись не-

великими.
SCRUM-МАЙСТЕР
Працюючи зі своєю першою Scrum-командою, я регулярно
показував їм відео про те, як готується до гри команда з рег-
бі All Blacks. Ця легендарна збірна маленької Нової Зелан-
дії є дійсно видатною командою. Перед кожною грою вони
виконують ритуал народу маорі під назвою хака — танець,
що надихає воїнів на битву. Спостерігаючи за ним, ви про-
сто-таки бачите, як енергія виходить із кожного гравця та
зливається в одне велике ціле. На ваших очах синхронні
притупування, плескання та ритуальні рухи уявного пере-
різання горлянки ворога перетворюють звичайних чоловіків
80 Команди
на щось більше, щось величніше. Вони викликають бойо-

вий дух, що не приймає ні поразки, ні страху.
Це відео довелось переглянути кілька разів, але врешті-решт

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

коротких стендапів (зустрічей стоячи), оглядів та ретроспек-
тив, після чого я усвідомив, що нам потрібен хтось, чиїм
завданням буде слідкувати за ефективністю самого цього
процесу. Не менеджер — скоріше лідер-слуга, щось середнє
між капітаном команди і тренером. Оскільки ми дивилися
відео з All Blacks щодня, я спитав команду, як нам слід на
звати цю людину. І вони зійшлися на «Scrum-майстер». Він
чи вона забезпечуватиме всі зустрічі, стежитиме за прозорі-
стю і, найважливіше, допомагатиме команді виявляти, що
стоїть у неї на шляху. Ключовою частиною цього було усві-
домлення, що часто перешкоди полягають не просто в про-
блемах із технікою або придуркуватості якогось бухгалтера
Джима — проблемою може бути процес як такий. Завданням
Scrum-майстра було вести команду до безперервного покра-
щення, регулярно шукаючи відповідь на питання: «Як нам
виконувати свою роботу ще краще?»
В ідеалі наприкінці кожного циклу і кожного спринту ко-

манда має уважно поглянути на саму себе — на свою вза-
Команди 81
ємодію, практику та процеси — і дати відповіді на два пи-

тання: «Що ми можемо змінити у своєму підході до роботи?»
і «В чому наша найбільша проблема?» Якщо відповідати
на ці питання щиро, команда зможе діяти з не баченою
раніше швидкістю.
ШУКАЙТЕ ПРОБЛЕМУ НЕ В ГРАВЦЯХ,

А В ГРІ
Часто буває так, що низький моральний дух, погана зла-
годженість та продуктивність команди спричинені фун-
даментальним нерозумінням того, як люди працюють.
Скільки разів ви з колегою пліткували про когось третьо-
го, хто «не тягне», «завжди нас затримує» чи «приймає
дурні рішення»? Чи, може, ви бачили, як, зустрівшись із
проблемою, ваша група замість пошуку рішення починає
звинувачувати одне одного?
Готовий заприсягтися, що всім і кожному з вас доводилося

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

ція. Процеси припущення, навчання та відкриття» Джона
Г. Голланда та ін. Одна з робіт, процитована в цій книжці,
82 Команди
опублікована ще на початку 1970-х років, тому новою її

не назвеш. Це стара ідея, яка повторюється знову й знову.
І пов’язана вона з тим, щó змушує людей діяти в той чи
інший спосіб. У будь-якому разі, результати дослідження
доволі цікаві. Автори зібрали групу студентів коледжу
(хлопців) і поставили їм два прості питання: «Чому ви
обрали саме цей предмет спеціалізації?» і «Чому ви зу-
стрічаєтеся саме із цією дівчиною?» А потім дослідники
попрохали студентів відповісти на ті самі питання щодо
їхнього найкращого друга. І тут виявилися важливі від-
мінності. Коли студенти говорили про себе, то говорили
більше не про себе особисто, а про тему питання. На
приклад, про свій головний предмет вони казали: «Хі-
мія — то високооплачувана галузь», а про дівчину: «Вона
дуже приємна людина». Натомість, говорячи про своїх
друзів, вони казали про здібності та потреби цих хлоп-
ців — щось на кшталт: «Йому завжди легко давалася ма-
тематика» або «Він доволі слабохарактерний, і йому по-
трібна владна жінка»10.
Цей спосіб сприйняття світу здається кумедним, коли ви

бачите його в інших. Адже помилковість їхніх суджень оче-
видна. Але перш ніж сміятися, мусите визнати, що й ви
постійно робите ті самі помилки. Усі роблять. Ми всі сприй-
маємо самих себе як тих, хто просто реагує на ситуацію, тоді
як в інших бачимо мотиви, продиктовані їхнім характером.
Тут є один цікавий аспект, який полягає в тому, що, коли
нас просять розповісти про риси характеру нас самих та
наших друзів, ми завжди змальовуємо себе значно менш
виразно. Ми стверджуємо, що маємо значно менше харак-
терних особливостей, ніж наші друзі.
Автори «Індукції» проводять цікаву паралель між нашим

помилковим мисленням про соціальну мотивацію і тим, як
люди, котрі не є науковцями і мають суто інтуїтивне розу-
міння фізики, бачать фізичний світ.
Команди 83
Такі люди можуть пояснити падіння каменя тим, що сам

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

на системи був експеримент Мілґрема з вивчення покори
перед авторитетом, проведений на початку 1960-х років
у Єльському університеті. Експеримент цей був простим
і, на наш сучасний погляд, дещо жорстоким. Його резуль-
тати дуже вразили, і сьогодні його вивчають усі, хто прохо-
дить психологію на першому курсі. Викладач Єлю доктор
Стенлі Мілґрем намагався знайти відповідь на доволі акту-
альне питання свого часу.
Річ у тім, що за три місяці до початку перших експеримен-

тів перед судом постав Адольф Ейхманн, якого називали
архітектором Голокосту. Але діяв він не сам-один. Дуже
багатьох цікавило, чому до цього масового винищення єв-
реїв добровільно долучилося стільки мільйонів людей. Чи
були в німців якісь фундаментальні проблеми з мораллю?
Можливо, в їхнє культурне середовище було закладено
якесь внутрішнє зло? Чи вони дійсно просто виконували
накази? Дуже легко дивитись на злочини проти людства та
звинувачувати людей за їхні дії. Саме так і треба робити,
правда? А от Мілґрем хотів знайти відповідь на інше пи-
тання: чи так уже звичайні американці відрізняються від
німців? Чи реагували б вони інакше в тій самій ситуації?
84 Команди
І некомфортна відповідь полягає в тому, що ні, американ-

ці не поводилися б інакше. По суті, враховуючи, скільки
країн та народів пізніше повторили цей експеримент, ні-
хто б не поводився. У відповідній ситуації ми всі могли б
стати нацистами.
Експеримент проводився так. Хтось одягнений у білий ла-

бораторний халат (що надавало йому наукового авторите-
ту) наказував об’єктові експерименту, пересічній людині,
застосовувати дедалі більший електричний струм до тре-
тьої особи — актора, який перебував в іншій кімнаті. Об’єкт
міг чути цього актора, але не бачити. У міру того як струм
ставав сильнішим, актор починав зойкати, кричати і про-
сити його пожаліти. Далі актор (який у деяких версіях екс-
перименту казав об’єктові, що в нього хворе серце) починав
тарабанити в стіну, благаючи, щоб експеримент припини-
ли. Під кінець він затихав.
Деякі об’єкти зупинялись на 135 вольтах, коли актор починав

зойкати, і питали про мету експерименту. Після того як їх
запевняли, що ніякої відповідальності вони не нестимуть,
майже всі продовжували. Деякі, чуючи крики агонії із сусід-
ньої кімнати, починали нервово сміятись. Коли ж об’єкт
хотів зупинитись, «учений» просто казав: «Продовжуйте,
будь ласка». А якщо об’єкт відмовлявся це зробити, учений
додавав: «Експеримент вимагає, щоб ви продовжували».
Якщо й це не допомагало, учений посилював тиск: «Абсо-
лютно необхідно, щоб ви продовжували». Більшість об’єктів
відчували великий стрес і рясно пітніли. У них спостеріга-
лись підвищення пульсу й температури, адже спрацьовував
інстинкт «бий або тікай». І тоді, якщо вони все ще відмов-
лялися тиснути на кнопку, вчений робив останню спробу:
«У вас немає іншого вибору. Ви повинні продовжувати».
Майже всі й продовжували, завдаючи останнього удару стру-

мом тому, хто так страшно кричав, а потім затихав. Підсум-
Команди 85
ки своїх спостережень Мілґрем підбив у статті 1974 року

«Небезпеки покори»:
Дійовими силами жахливого руйнівного процесу можуть

стати звичайні люди, які просто роблять свою роботу, не ма-
ючи зі свого боку якоїсь особливої ворожості. Більше того,
навіть коли руйнівні наслідки їхньої роботи стають абсолют-
но зрозумілими, а їх просять виконувати дії, несумісні з ос-
новними стандартами моралі, відносно небагато людей зна-
ходять у собі сили, потрібні для опору авторитетові11.
Коли експеримент Мілґрема обговорюють в університет-

ських аудиторіях, студентам зазвичай наголошують, що про-
вина лежить не на людях як таких, а на системі, у межах
якої ці звичайні люди діяли. Але це суворий урок, бо, якщо
сприйняти його за правду, що це скаже про нас самих?
Це скаже, що ми всі є породженням системи, в яку вбудо-

вані. І Scrum якраз приймає цю реальність і замість пошу-
ку винних намагається вивчити систему, яка породила про-
блему, й виправити її.
Інший експеримент, що висвітлює подібне явище, був про-

ведений в одній духовній семінарії на початку 1970-х років.
Ви, можливо, думаєте, що семінаристи мають бути най-
більш співчутливими людьми на планеті, так? Об’єктів цьо-
го експерименту просили прочитати проповідь на іншому
кінці кампусу. Одним казали поспішити, бо на них уже
чекають і вони запізнюються. Інших не підганяли. По до-
розі на території закладу кожному із семінаристів трапля-
лася людина, яка благала про допомогу. Скільки з тих, кому
сказали поспішити, зупинилися допомогти? Десять від
сотків. І це із семінаристів!
А проте люди прагнуть звинувачувати окремих осіб, а не

систему. Від цього вони просто краще почуваються. Фун
86 Команди
даментальна помилка атрибуції апелює до нашого почуття

справедливості. Якщо ми можемо звинувачувати когось ін-
шого, то відділяємо себе від можливості зробити те саме —
що ми так само готові тиснути на кнопку, як і будь-хто ін-
ший. Справа лише за відповідними обставинами.
Як ця помилка звинувачення людей, а не системи вияв-

ляється в бізнесі? Я маю два чудові приклади, першим
з яких є автомобільний завод New United Motor Manufac-
turing, Inc. (NUMMI) у місті Фремонт, штат Каліфорнія.
Це було спільне підприємство компаній General Motors
і Toyota. У 1982 році General Motors закрила завод. Керів-
ництво вважало його найгіршим місцем роботи в Амери-
ці. Люди пиячили прямо на роботі, прогулювали та по-
стійно, хоч і не сильно, псували автомобілі, які виробляли
(наприклад, залишали всередині дверцят пляшку з-під
кока-коли, яка гриміла і дратувала покупців). У 1984 р.
Toyota відкрила завод заново. При цьому японцям казали,
що робітники там були жахливі, але менеджери чудові,
і їх варто взяти назад на роботу. Натомість у цій компанії
відмовилися брати назад менеджерів, а взяли більшість
попередніх робітників — деяких навіть послали до Японії
вивчати виробничу систему Toyota. І що з цього вийшло?
Майже відразу завод почав виробляти машини з тією са-
мою точністю й мінімумом дефектів, як і в Японії. Люди
залишилися ті самі, змінилась система. Що ж до компанії
General Motors, то їй ніколи не вдалося досягти таких
рівнів якості на жодному з інших американських заводів.
Вона розірвала угоду про спільну діяльність і того ж року
збанкрутувала.
Другий приклад, який спадає мені на думку, дещо відріз-

няється. Він нагадує мені, наскільки ж людям властиво
шукати винного в проблемі, а не її розв’язання. Він про
те, як діють венчурні капіталісти, з якими я працюю, коли
вирішують інвестувати в ту чи іншу компанію. Уперше
Команди 87
приєднавшись до OpenView Venture Partners, я був здиво-

ваний, що, на відміну від багатьох венчурних фірм, їм
насправді байдуже, як компанія витрачала свої гроші до
їхньої інвестиції. Минуле їх не турбує. OpenView вирішує,
чи варто вкладати в компанію гроші, виходячи з її поточ-
ного стану, — усе інше не важить. Вони лише хочуть знати,
як збираються витрачати їхні гроші. Як компанія витра-
чала гроші інших, їх не обходить. Значення для них має
лише майбутнє — лише рішення.
ДОСЯГНЕННЯ НАДЗВИЧАЙНОСТІ
Коли члени команди починають гуртуватися навколо спіль-
ної мети й синхронізувати свої дії, це схоже на магію. Ви
відчуваєте це, коли заходите в приміщення, де вони пра-
цюють. Ви бачите це, коли гравці виходять на поле. Вони
починають діяти надзвичайно злагоджено, перевершую-
чи самих себе.
Нещодавно я гостював в одного свого друга в Копенгагені.

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

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

Scrum. У цьому немає нічого неможливого. На це здатні
не лише якісь унікуми, спортсмени чи спецпризначенці.
Уся суть у створенні правильної структури з правильними
стимулами та наданні людям свободи, поваги й повнова-
жень діяти самостійно. Надзвичайність не можна спустити
згори — вона має прийти знизу. Але вона дійсно живе все-
редині кожного з нас.
Беріться за правильний важіль. Змінюйте роботу ко-

манди. Вона має набагато більше значення — на декіль-
ка порядків, — ніж робота окремих осіб.
Прагніть надзвичайності. Видатні команди ставлять

перед собою мету, що виходить за межі прагнень окремої
людини: честь поховати генерала Мак-Артура або вигра-
ти чемпіонат НБА.
Дозволяйте автономну роботу. Надавайте командам

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

повинна мати всі потрібні вміння та навички для вико-
Команди 89
нання проекту, чи то розробка програмного забезпечен-

ня Salesforce.com, чи захоплення терористів в Іраку.
Не беріть багато людей. Малі команди працюють швид-

ше за великі. Залізне правило — це сім членів команди
плюс-мінус двоє. Менше людей — менше помилок.
Не звинувачуйте. Не шукайте поганих людей, шукайте

погані системи — ті, що стимулюють неправильну пове-
дінку та винагороджують погану роботу.
РОЗДІЛ 4. ЧАС
92 Час
Час є основним обмежувачем людської діяльності і впливає

абсолютно на все — від нашої працездатності до тривалості
виконання проектів та рівня успішності. Невмолимий одно-
спрямований хід часу великою мірою формує наше бачення
світу і самих себе. Британський поет XVII століття Ендрю
Марвелл сказав про це так: «Якби ж то світу стало нам і часу».
Тоді можна було б досягти всього. На жаль, над кожним нашим
зусиллям, безумовно, тяжіє відчуття смертності. Ми знаємо, що
часу в нас небагато. То чи не є найбільшим злочином його мар-
нувати? Треба діяти! Ось що пише Марвелл із цього приводу:
Отож, хоча нам сонце не припнути,

Ми поганяти можемо його1.
Але як це зробити? Легко кричати з трибуни: «Carpe diem!»

(«Лови день!»), надихаючи натовп, але як це здійснити на
практиці? Великий обсяг роботи наказує людям просиджу-
вати за нею, зіщулившись, цілими днями. «Не думайте про
зовнішній світ, — утовкмачують нам наші боси. — Забудьте
про своїх дітей, серфінг чи навіть обід. Просто працюйте,
більше й більше, і буде вам винагорода. Ви отримаєте це
підвищення. Оформите цей продаж. Завершите цей проект».
Хоча я не маю нічого проти підвищень, продажів чи проек-

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

якусь нову «процедуру». Я просто хотів зібрати докупи всі
дослідження, що проводилися десятиліттями, і відтворити
умови найкращої роботи людей. Я прагнув об’єднати най-
кращі практики та поцупити всі кращі ідеї, які лишень знай-
ду. Незадовго до першого справжнього запуску Scrum в Easel
Час 93
у 1993 році я працював у компанії всього за кілька кварталів

від медіа-лабораторії МТІ, поцупивши звідти ідею, яка стала
основою Scrum, — ідею спринту.
СПРИНТ
На початку 1990-х років ця медіа-лабораторія пропонувала
велике різноманіття нових продуктів. То був час зародження
всесвітньої павутини, і вони розробляли геть усе — від роботів
до електронних чорнил, що відкривають читачам електрон
них книг нові можливості кодування звуку. То був дивовижно
стрімкий час, і я часто брав до себе на роботу студентів із цієї
лабораторії, бо вони були переповнені ідеями й мали надзви-
чайну здатність створювати чудові речі, і то швидко.
Своєю швидкістю вони завдячували політиці медіа-лаборато-

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

відний вимогам продукт і, найважливіше, отримувати негай-
ний відгук на нього.
Подумайте про багато проектів, над якими працюєте ви. Пе-

реконаний, що ви рідко отримуєте на них відгуки до самого
завершення — а на це можуть піти місяці та навіть роки. Ви
можете місяцями рухатись у зовсім неправильному напрямку
і не підозрювати про це. Це забирає величезні шматки вашо-
го життя, які не закінчуються нічим. У бізнесі ж це може оз-
начати різницю між успіхом і провалом. Я постійно бачу, як
це відбувається: компанія витрачає роки на проект, що зда-
вався чудовою ідеєю, коли працівники його тільки почали,
94 Час
але на той час, як вони закінчили, ринок абсолютно змінився.

Чим скоріше ви презентуєте продукт клієнтам, тим швидше
вони зможуть вказати вам на можливі невідповідності.
Отже, я запустив перший Scrum в Easel і сказав генерально-

му директорові, що не збираюсь показувати йому великі
й детальні діаграми Ґантта, які ми обидва вважаємо хибними.
— Чудово, — відповів він. — Що ж тоді ви збираєтесь мені

показувати?
— Щомісяця я демонструватиму частину програмного за-

безпечення, яке працює. Не щось незрозуміле, що запрацює
лише в самому кінці. Не якийсь там фрагмент архітектури.
Частину програмного забезпечення, яке клієнт дійсно зможе
використовувати. Повністю готову та впроваджену функцію.
— Гаразд, — сказав він. — Робіть це.
Отак моя команда почала практикувати спринти. Ми назва-

ли їх так, бо ця назва асоціюється з інтенсивною роботою.
Ми збирались повністю виконувати поставлене завдання за
короткий період, а потім зупинятися й дивитися, чого досягли.
Хочу розповісти вам про «Команду WIKISPEED» — групу, за-

сновану людиною із чудовим прізвищем Джо Джастіс (це прі
звище означає «справедливість»). Вони виготовляють машини.
Автівки, які витрачають літр пального на 40 км, майже не за-
бруднюють повітря, мають п’ять зірочок за рейтингом безпеки,
розганяються до 225 км/год і коштують дешевше за Camry.
При цьому WIKISPEED постійно покращує свої транспортні
засоби. Якщо ви хочете купити один із них, сплатіть двадцять
п’ять штук через сайт wikispeed.com, і вам приженуть автівку
протягом трьох місяців. І для цього вони використовують
Scrum. Подібно до багатьох найкращих команд у наш час, вони
працюють за принципом однотижневих спринтів. Щочетверга
Час 95
вони сідають усі разом і проглядають так званий беклог сприн-

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

етла в один зі звичайних четвергів, можна побачити те, що
зветься «організований хаос» — його і являє собою автомай-
стерня. Скрізь валяються інструменти, болгарки, електронне
начиння, кріплення та гайкові ключі. ЧПУ-роутер у кутку
третього боксу поряд із напівзібраною рамою автомобіля.
Верстати для свердління та гнуття металу сидять поруч, наче
цуценята, які прагнуть, щоб з ними погрались. У день, коли
ми там були, над рамою висіло фото людини, яка купувала ту
автівку, — Тіма Маєра. Він любить лазити по горах, чипси та
сидр. Він не любить не знати, що відбувається, або не мати
варіантів. У вихідні шукайте його за містом, а ввечері кожно-
го понеділка — на танцях у таверні «Трактор».
Спереду, в першому боксі, стоїть перша машина, зібрана «Ко-

мандою WIKISPEED», — автівка, що брала участь у змаганнях
із призовим фондом у десять мільйонів доларів для машин
з найменшою витратою пального на 100 миль. Вона тоді ввій-
шла в першу десятку, залишивши позаду понад сто конкурентів
з великих автомобільних компаній та університетів. У резуль-
таті її запросили на Детройтський автосалон-2011 і виставили
в першому ряду між «Шевроле» і «Фордом». Сьогодні ця ав-
тівка слугує команді стендом для випробування нових ідей.
Біля неї встановлено майже чотириметрову лекційну дошку,

що тягнеться на всю ширину майстерні. На ній ви знайдете
десятки й десятки стікерів — одного з основних атрибутів
96 Час
Scrum. На кожному із цих яскравих кольорових клейких

папірців записано якесь завдання, що має бути виконане:
«просвердлити трубу для модульної рейки керма», «підго-
тувати модель інтер’єру», «встановити внутрішню обшивку
крила для захисту від бризок із шин» тощо.
Дошка ділиться на кілька колонок: «Беклог», «Виконується»,

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

доки не буде повністю готовим для використання клієн-
том. Іншими словами, майбутній господар може прокон-
тролювати процес виготовлення машини між спринтами,
побачивши, що було зроблено з минулого разу. І якщо під
час тест-драйву він скаже: «Агов, сигнали повороту пра-
цюють із затримкою», — цю проблему буде розв’язано
в наступному спринті.
Спринти ще часто називають «часовими проміжками». Вони

мають визначену тривалість. Не можна робити однотижневий
спринт, а потім тритижневий. Слід бути послідовним. Потріб-
но встановлювати такий ритм роботи, де люди знатимуть,
скільки вони зможуть виконати в заданий період часу. Дово-
лі часто цей обсяг стає сюрпризом для них самих.
При цьому одним із надзвичайно важливих елементів сприн-

ту є те, що, як тільки команда береться за виконання роботи,
завдання блокуються. Ніхто за межами команди не може вже
нічого додати до переліку. На причинах цього я детальніше
Час 97
зупинюсь нижче, але зараз вам досить запам’ятати, що втру-

чання та відволікання значно зменшують швидкість роботи
команди.
Як я вже згадував, у першому Scrum ми використовували

чотиритижневі спринти. Десь під кінець першого спринту ми
відчули, що просуваємось недостатньо швидко і можемо ро-
бити більше. Тоді ми якраз дивилися відео, як All Blacks ви-
конують хаку, а потім проривають оборону супротивника.
«Чому ми не такі? — питали ми себе. — Чому не маємо такого
бойового духу?» Ми вирішили поставити собі за мету стати
не просто доброю командою, а найкращою. Як це можна було
зробити? І знову відповідь полягала в простій речі, яку ми
поцупили в когось іншого, — щоденних зустрічах.
ЩОДЕННІ СТЕНДАПИ
На виїзді з одного міста, яке я не можу назвати, в компанії,
яку я не повинен згадувати, кожного дня збирається група
людей, обговорюючи, як відправити інших людей у космос.
Оскільки космічні кораблі, по суті, є міжконтинентальними
балістичними ракетами з людським зарядом, інформація
про це приватне підприємство космічних подорожей пов’я-
зана з дотриманням певного рівня безпеки й таємності. Крім
того, це бізнес, а не просто примха ексцентричного мільяр-
дера. Поки я пишу ці рядки, чергова приватна ракета якраз
стикується з Міжнародною космічною станцією, причому
вже вдруге. Навіть уряд США не має таких можливостей на
даний момент.
Але в цій конкретній будівлі цього конкретного дня ці кон-

кретні люди б’ються над питанням, якого розміру має бути
блок бортової радіоелектроніки ракети. Це обладнання по-
відомляє ракеті, куди вона летить і як туди дістатись. Вва-
жайте його мозком космічного корабля.
98 Час
Маємо дві команди по сім людей: одна займається апаратним,

а друга — програмним забезпеченням. Кожного дня одна
і друга команди збираються перед великою лекційною до-
шкою заввишки від підлоги до стелі та завдовжки в усю стіну.
Точно як у «Команди WIKISPEED», цю дошку розкреслено
на кілька колонок: «Беклог», «Виконується», «Виконано».
У колонках перелічуються лише ті завдання, які команді по-
трібно виконати в конкретному спринті. Завдання варіюють-
ся від роботи з одним із кількох постачальників спеціальних
мікросхем до визначення взаємодії акселерометра з рештою
корабля. Scrum-майстер — особа, яка відповідає за процес, —
ставить кожному членові команди три запитання:
1. Що ви робили вчора, щоб допомогти команді завершити

спринт?
2. Що ви робитимете сьогодні, щоб допомогти команді за-
вершити спринт?
3. Які перешкоди стоять на шляху команди?
І все. На цьому зустріч закінчується. Якщо вона займає

більш ніж п’ятнадцять хвилин, то ви робите щось не так.
І вона допомагає всім членам команди чітко розуміти пе-
ребіг спринту та стадії розв’язання його завдань. Чи будуть
усі завдання виконані вчасно? Чи є можливості допомогти
іншим членам команди в подоланні перешкод? Завдання
не розподіляються згори — команда автономна. Її члени
роблять усе самі. Немає детального звітування перед керів-
ництвом. Будь-хто з керівництва або іншої команди може
зайти подивитись на дошку команди авіоніки й чітко зро-
зуміти, на якій стадії все перебуває.
Отже, коли перша Scrum-команда прагнула визначити, як

їм стати схожими на All Blacks, вони звернулися до літера-
тури, щоб пошукати причини успіху найкращих команд.
У розробці програмного забезпечення добре те, що через
надзвичайно погану ситуацію на самому початку та марну-
Час 99
вання мільярдів доларів щороку люди витрачали чимало

часу на вивчення причин, а тому дані були про все.
Одним із тих, хто витратив роки на вивчення ситуації з про-

грамним забезпеченням, був Джим Копліен із легендарного
дослідницького центру Bell Labs компанії AT&T. Копліен
багато років вивчав сотні проектів програмного забезпечен-
ня, намагаючись визначити, чому так мало з них виконують-
ся добре, а більшість закінчується катастрофою. На початку
1990-х його запросили для вивчення проекту корпорації
Borland Software з розробки нового редактора електронних
таблиць під назвою Quattro Pro для Windows. Для проекту
вже було прописано мільйон рядків програмного коду. На
це пішов тридцять один місяць роботи восьми людей. Це
означає, що кожен член команди писав тисячу рядків коду
на тиждень. То було швидше за всі інші команди серед його
записів, і Джим хотів знати, як їм це вдавалося.
Він склав мапу всіх комунікаційних потоків усередині коман-

ди — хто з ким розмовляв, де інформація текла, а де ні. Така
мапа є чудовим інструментом, за допомогою якого можна ви-
явити місця звуження потоків інформації або людей, які при-
ховують її від інших. Чим більше комунікаційне насичення
(чим більше всі знають про все), тим швидше працює команда.
По суті, такий аналіз дозволяє виміряти, наскільки добре всі
знають те, що їм потрібне для виконання роботи. Так от, кор-
порація Borland мала в цьому плані найвищий рейтинг: 90 від-
сотків. Більшість же компаній ледь дотягували до 20 відсотків.
Як же нам було досягти такого інформаційного насичення

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

порвати свої візитівки. Якщо хтось хоче писати свою посаду
в резюме, то може робити це лише для зовнішнього викори-
стання. Тут, де вони працюють зараз, є лише члени команди.
Іншим інгредієнтом «таємного соусу» команди Borland було

те, що всі в команді кожного дня збиралися на зустріч для
обговорення ходу роботи. Ключем було зібрати всіх разом
в одній кімнаті, бо це давало команді можливість самоорга-
нізуватися навколо викликів. Якщо хтось стикався з якоюсь
проблемою (наприклад, не було зв’язку між акселерометром
і альтиметром), усі бачили, що ця перешкода може загальму-
вати весь спринт, і енергійно бралися за неї, гарантуючи її
оперативне розв’язання.
У Borland щоденні зустрічі тривали не менш ніж годину. На

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

ми запровадили для них певні правила. Зустріч проводилась
в один і той самий час кожного дня, і присутність на ній була
обов’язковою для всіх. Якщо раптом присутня була не вся
команда, обговорення просто не відбувалось. Зустріч мала
бути в той самий час — байдуже який, але один і той самий —
кожного дня. Суть полягала в тому, щоб задати команді регу-
лярний ритм.
Другим правилом було те, що зустріч не могла тривати дов-

ше за п’ятнадцять хвилин. Ми прагнули зробити її динаміч-
ною, відкритою та націленою на результат. Якщо якась про-
блема вимагала дальшого обговорення, ми відзначали це
й зустрічалися додатково після щоденної зустрічі. Ідея по-
лягала в обміні найбільш актуальною та корисною інформа-
цією за найкоротший час.
Час 101
За третім правилом, усі мали брати в обговоренні активну

участь. Для сприяння цьому я наполіг, щоб зустрічі відбува-
лися стоячи. Тому всі активно говорили і слухали. Крім того,
це дозволяло не затягувати час.
Із цієї причини таку зустріч іноді називають щоденним стенд

апом або щоденним Scrum. Насправді не має значення, як
її називати. Вона має відбуватися в один і той самий час
щодня, з відповідями на однакові три запитання, стоячи й не
довше за п’ятнадцять хвилин.
Проблема в тому, що люди часто схильні перетворювати що-

денний стендап просто на індивідуальне звітування. «Я зро-
бив це… зроблю те…» — а тепер наступний… Оптимальний
підхід нагадує радше коротку нараду гравців в американський
футбол перед початком матчу. Ресивер каже: «У мене пробле-
ма з лінійним захисником», — на що нападник-блокер відпо-
відає: «Я подбаю про це. Лінію буде відкрито». Або квотербек
говорить: «Наша атака немов натикається на стіну. Здивуймо
їх пасом на лівий край». Ідея в тому, щоб команда швидко
узгодила свій шлях до перемоги — провела спринт. Пасив-
ність не просто є ознакою лінощів, а шкодить решті дій ко-
манди. Одразу після виявлення її слід негайно позбуватись.
Потрібно, щоб команди були агресивними — виходили зі що-

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

є таким: «Ви хочете вічно пасти задніх? Така у вас мотивація
в житті? Вибір за вами — ніхто вас ні до чого не змушує».
Команда сама має захотіти стати видатною.
102 Час
Працюючи в Easel з першою Scrum-командою, ми запрова-

дили щоденний стендап під час третього спринту. Ми відве-
ли для того спринту чотири тижні роботи — приблизно та-
кий самий обсяг, що й у попередній місяць. Закінчили ж усе
за тиждень. Покращення склало 400 відсотків. У ту першу
п’ятницю всі члени команди дружно подивились одне на
одного й промовили: «Оце так». Саме тоді я й зрозумів, що
рухаюсь у правильному напрямку.
ЧАС І ЩЕ РАЗ ЧАС

І таке покращення Scrum дав уже на третьому спринті. Саме
в цьому й полягає мета його створення. У деяких випадках
мені доводилось бачити, як високодисципліновані команди
підвищували свою продуктивність у вісім разів. Ось що ро-
бить Scrum таким революційним. Він дозволяє виконати
більше завдань швидше й дешевше — подвоїти результат за
половину часу. Причому слід пам’ятати, що час важливий
не лише в бізнесі. З нього складається все ваше життя, тому
марнування його, по суті, є повільною формою самогубства.
Scrum змінює сам спосіб вашого мислення про час. Варто

хоча б почати проводити спринти й стендапи, і ви переста-
нете дивитись на час як на прямий шлях у майбутнє, зрозу-
мівши, що він є циклічним у своїй основі. Кожен спринт — це
можливість зробити щось зовсім нове, а кожен день дає шанс
на покращення. Scrum заохочує глобальне бачення світу. Той,
хто його практикує, починає цінувати кожну мить життя.
Мене завжди лякала думка про те, скільки може тривати пе-
репланування будинку. Ми з дружиною часто нагадували
одне одному, що це буде вдвічі довше й коштуватиме вдвічі
дорожче, ніж ми думаємо. І це в кращому разі. Переконаний,
ви чули приблизно такі самі страшні історії, що і я: ремонт
кухні, на який відводилися два тижні, затягнувся на всі шість,
Час 103
через що родина мусила їсти деінде понад місяць. Електрич-

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

друг та колега по гнучкому мисленню Елко Рустенбурґ роз-
повів мені за обідом, що вирішив переробити свій будинок —
повністю, згори донизу. Він відремонтує всі кімнати, проведе
нову проводку, встановить нове обладнання та все перефар-
бує. Вкластися ж він збирався в якихось шість тижнів.
Ми всі посміялись і почали лякати Елко нашими страшними

ремонтними байками.
— Шість тижнів на весь будинок? — сказав я зі сміхом. —

Жодних шансів. У мене пішло шість тижнів на ремонт кухні,
хоча мені обіцяли два. Ти житимеш у готелі до кінця року.
— Аж ніяк, — відповів він. — Усе буде зроблено вчасно та

в межах бюджету. Я збираюся зробити це за допомогою Scrum.
А оце вже мене зацікавило — ідея використання Scrum у зовсім

іншій сфері, ніж програмне забезпечення. Приблизно шість
місяців потому я знову зустрівся з Елко та спитав його, як усе
пройшло. «Чудово, — сказав він. — Шість тижнів день у день.
А от у сусіда… Зараз розповім тобі ще одну страшну історію».
Ось як це було. Елко вирішив змусити ремонтників працювати

подібно до Scrum-команди. Він розробив тижневі проекти, які
вони мали переводити в розділ «Виконано», а в їхньому трей-
лері, припаркованому на його передньому подвір’ї, було вста-
новлено дошку, повну стікерів із переліком завдань. Кожного
ранку він збирав теслярів, електриків, сантехників і загалом
усіх, хто був потрібний для виконання спринту на цьому тижні,
та обговорював із ними, що зроблено за минулий день, що вони
збираються робити в цей день і що стоїть на їхньому шляху.
104 Час
Елко каже, що це змусило їх думати й говорити про проект

інакше, ніж вони звикли. Сантехніки та теслярі обговорюва-
ли, як вони можуть допомогти один одному працювати швид-
ше. Нестача матеріалів виявлялася ще до того, як їхня відсут-
ність зупинила б усю роботу. Але, за його словами, головним
результатом таких стендапів було усунення залежностей.
У будь-якому будівельному проекті багато часу витрачається
на очікування, доки буде виконано одну частину роботи, щоб
могла початися наступна. І часто ці етапи передбачають різні
набори вмінь та навичок — наприклад, проведення електри-
ки та встановлення гіпсокартонних панелей. Але щоденні
зустрічі стоячи збирали всіх в одному приміщенні, де вони
швидко визначали, як можна працювати разом, однією ко-
мандою. Люди більше не були просто майстрами з окремими
вміннями й навичками, а стали однією командою, яка праг-
нула перевести будинок у розділ «Виконано».
І це спрацювало. Через шість тижнів проект було завершено.

Елко з родиною щасливо повернулися додому. Життя було
чудовим. Коли він розповів мені про це, я був дуже здивований,
але привітав його з тим, що йому трапились класні ремонтни-
ки. А він сказав, щоб я трохи зачекав, бо це ще не кінець історії.
Далі по вулиці один його сусід захотів зробити майже такий

самий ремонт у своєму будинку. Вони обидва жили в старій
частині Нідерландів, і їхні будинки були збудовані в один
час за однаковим проектом. Сусід побачив, яку чудову робо-
ту ремонтники зробили в будинку Елко, і думав, що йому
вдасться повторити цю магію.
Були найняті ті самі робітники, але цього разу їм знадоби-

лися три місяці. Ті самі люди. Той самий тип будинку. Та
сама робота. Удвічі більше часу і, звичайно, удвічі більше
грошей. Єдина відмінність полягала в тому, що сусід не ви-
користовував Scrum. Проблеми, які Scrum витягає на по-
верхню, у цьому випадку не виявлялись, аж доки не ставало
Час 105
запізно. Люди не координували своїх дій, як попереднього

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

ється, поки ви чекаєте завершення роботи кимось іншим або
потрібної вам інформації? А скільки йде на те, що ви намагаєтесь
зробити забагато речей одночасно? Можливо, вам подобається
сидіти на роботі до ночі — мені ж більше подобається серфінг.
Час має свої межі. Зважайте на це. Розбивайте свою

роботу на завдання, які можна виконати протягом регу-
лярних, чітких, коротких періодів — в ідеалі від одного до
чотирьох тижнів. І, якщо ви вже підхопили Scrum-лихо-
манку, називайте їх спринтами.
Демонструйте або помріть. Наприкінці кожного сприн-

ту майте щось виконане — щось придатне для викори-
стання (польоту, поїздки, чого завгодно).
Викиньте свої візитівки. Посади є показниками кон-

кретного статусу. Нехай за вас говорять ваші справи, а не
додаток до імені.
Усі разом знають усе. Комунікаційне насичення приско-

рює роботу.
Одна зустріч на день. Коли йдеться про перевірку досяг-

нень команди, раз на день цілком досить. Збирайтесь разом
на п’ятнадцять хвилин у щоденному стендапі, дивіться, що
можна зробити для збільшення швидкості, та робіть це.
РОЗДІЛ 5. МАРНУВАННЯ — ЦЕ ЗЛОЧИН
108 Марнування — це злочин
В основі Scrum лежить ритм, який має надзвичайно важ-

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

винагороджують або несуть нам щастя. Наприклад, існують
негативні ритми наркоманів та алкоголіків або людей у стані
депресії. Ви можете пройтися коридорами ледь не будь-
якого офісного центру і побачити чимало таких негатив-
них виявів. Майже напевне вони трапляються там, де люди
зневірились у своїх силах і почуваються загнаними в глу-
хий кут, перебувають у тихому відчаї, потрапивши в паст-
ку байдужої системи, або зляться, що їх вважають гвинти-
ками величезної машини.
Це — частина багатовікового людського досвіду. Читаючи

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

на тому, що ми є істотами, які залежать від своїх звичок,
скрізь шукають ритм, дещо передбачувані, але й мають
у собі щось магічне і здатні на видатні вчинки. Створюючи
Scrum, я думав: «Що як я зможу взяти схеми людської по-
ведінки та зробити їх позитивними, а не негативними? Що
як я зможу розробити ефективний самопідкріплюваний
цикл, що посилюватиме найкращі наші риси та послаблю-
ватиме найгірші?» Гадаю, задаючи Scrum щоденний та
Марнування — це злочин 109
щотижневий ритм, я прагнув запропонувати людям шанс

полюбити особу, яку вони бачать у дзеркалі.
Але, як і скрізь, на цьому шляху також трапляються пастки.

Те, що здається цілком надійною схемою, може закінчити-
ся черговою дурницею — марнуванням часу, грошей та зу-
силь. Розгляду цієї проблеми я й збираюся присвятити цей
розділ: марнування, яке уражає нашу роботу, немов ракова
пухлина, підриваючи нашу продуктивність, організацію,
життя та все наше суспільство.
Якось, проводячи співбесіду з одним із кандидатів на вакан-

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

історією, вивчав американський колоніальний період, і ро-
бота давала йому можливість спілкуватися з провідними
фахівцями в цій галузі.
«Я пропрацював там рік, — сказав він. — Рік, витрачений

на підготовку десятків різних матеріалів. Наприкінці ж того
року ми вперше переглянули свої досягнення. І чи не по-
ловину зробленої мною роботи було викинуто на смітник.
Не тому, що вона була поганою, а тому, що вона, бачте,
виявилась неринковою або не відповідала новим напрямам
діяльності фірми. Шість місяців мого життя були цілком
і повністю змарновані».
У цей момент у його голосі прозвучали гнів та обурення. Але

потім на зміну їм прийшла рішучість: «Я сподіваюся, що
Scrum такого не дозволить, у моєї роботи буде мета, а зро-

блене дійсно матиме значення».
Ви, можливо, думаєте, що це крайній випадок, коли марну-

вання склало аж п’ятдесят відсотків роботи. Але насправді
це ще не так і погано. Коли я приходжу в якусь компанію, то
зазвичай виявляю, що там марнується близько 85 відсотків
усіх зусиль. Лише шоста частина будь-якої виконаної робо-
ти дійсно має якусь цінність. Глибоко всередині нас самих,
зважаючи на ритм наших днів, ми знаємо, що це правда. Ось
чому ми всі сміємось, трохи нервово, над жартами про вну-
трішнє безумство та марність життя в сучасній корпорації.
Але я хочу, щоб ви знали: це не має бути кумедним. Це має

бути ганебним. Ми повинні оплакувати життя та потенціал,
які марнуємо. Я вже коротко представив вам керівника
Toyota Таїчі Оно в першому розділі цієї книжки, коли він
сказав: «Марнування є злочином проти суспільства, а не
просто комерційними втратами». Його думки про марну-
вання глибоко вплинули на мої, і я збираюся присвятити
деякий час розповіді про них.
Оно говорив про три різні типи марнування. Він використо-

вував японські слова: мурі — марнування через непроду-
маність; мура — марнування через непостійність; муда —
марнування через непотрібність результатів. Ці ідеї чітко
співвідносяться з циклом Демінга, про який я писав рані-
ше: Плануйте, Робіть, Перевіряйте, Дійте. Плануйте
означає уникайте мурі. Робіть означає уникайте мура.
Перевіряйте означає уникайте муда. Дійте означає волю,
мотивацію та рішучість зробити все це. Я збираюсь розгля-
нути ці кроки один за одним, вказуючи на те, чого слід
уникати — від марнування ресурсів до марнування через
неправильну роботу з першого разу, марнування через над-
то важку роботу та емоційного марнування через необґрун-
товані очікування1.
ОДНА СПРАВА ЗА РАЗ

Мені часто доводиться чути вихваляння людей про їхню здат-
ність до багатозадачності. Упевнений, що й вам теж. Якщо ви
не кричите про це самі, то знаєте когось, хто це робить, — хлоп-
ця, який береться по три проекти за раз, розмовляє по мобіль-
ному за кермом, підвищує свою компетентність, голосно скар-
жачись на все, чим йому доводиться займатися щодня. «Ділові
ковбаси» такого штибу поступово стають частиною нашої ро-
бочої культури. У вимогах до вакансій сьогодні можна побачи-
ти таке: «здатність підтримувати п’ять проектів одночасно».
Здатність «жонглювати» завданнями здається такою приваб

ливою — особливо в еру, коли інформаційні потоки йдуть
тисячами різних труб, а серед дедлайнів превалює поняття
«на вчора». Ми прагнемо стати таким хлопцем — супержон-
глером. Ми запевняємо самих себе, що це можемо. Але, на
жаль, не можемо. І чим більше ми думаємо, що здатні, тим
гірше в нас це насправді виходить.
Особливо яскравим прикладом є така щоденна практика

багатозадачності, як розмови по мобільному за кермом. До-
слідження показують це дуже чітко. Люди, які розмовляють
по телефону під час їзди — навіть по гучному зв’язку, — ча-
стіше потрапляють в аварії, ніж ті, хто цього не робить. Про-
блема є особливо гострою, якщо врахувати, що, за даними
Національного управління безпекою руху, на трасах у будь-
який конкретно взятий момент по телефону за кермом роз-
мовляють 8 відсотків людей.
Ось що заповідає нам багатозадачність.
А ось цитата з моєї улюбленої статті з цього приводу:
…навіть коли учасники дорожнього руху дивляться на до-

рогу, розмовляючи по мобільному, вони часто не «бачать»
об’єктів навколо себе через відвернення уваги від зовніш-

нього оточення та спрямування її на внутрішній когнітивний
контекст, пов’язаний із телефонною розмовою2.
Так і є, люди дійсно дивляться на об’єкт — авто, до якого

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

разд, інші люди на це не здатні. Але я не такий, я — високо-
посадовий керівник» або: «Я — розумний. Я здатний на це,
а вони ні». Проте дані досліджень висвітлюють цю тему
цілком однозначно: якщо ви думаєте, що добре щось умієте,
то насправді — гірше за всіх інших. В Університеті Юти було
проведено чимало цікавих експериментів у цій сфері, у яких
людей питали, чи вважають вони себе майстрами багатоза-
дачної діяльності, на кшталт користування мобільним за
кермом, а потім перевіряли, чи мають вони рацію. Дослід-
ники дійшли таких висновків:
Сприйняття здатності до багатозадачності виявилось над-

то перебільшеним. По суті, більшість учасників оцінювали
свою здатність до багатозадачності вище за середній рі-
вень. Ці оцінки мало відповідали дійсності. Таким чином,
виходить, що люди, які охочіше беруться за багато завдань
і користуються мобільним телефоном за кермом, мають
найбільш роздуте уявлення про свої здібності3.
У січні 2013 року керівник одного з таких досліджень Де-

від Санбонмацу розповів для блогу Shots Національного
громадського радіо США: «Люди беруться за багато за-
вдань водночас не тому, що добре це вміють. Вони роблять
це через підвищену неуважність. Їм важко придушити
в собі імпульс узятися ще за одну справу». Іншими слова-
ми, прихильники багатозадачності здебільшого просто
не вміють зосереджуватись. Вони нічого не можуть із

собою вдіяти.
Мабуть, не варто казати «вони». Я мав би казати «ми».

Ми всі це робимо. Цього важко не робити. Головне — пам’я-
тати, що це дурість. Попрошу вас виконати одну невеличку
вправу. На моїх курсах я постійно задаю її людям. Вона
доволі простенька, але демонструє глибокий вплив зосере-
дження та потоку.
Це завдання чітко показує, наскільки болісною багатоза-

дачність є для мозку і наскільки вона вас затримує, навіть
якщо ви думаєте, що прискорює. Ця вправа демонструє
марність багатозадачності.
Ось що я попрошу вас зробити. Треба буде записати в стовп-

чик цифри від 1 до 10, римські цифри від 1 до 10 (І, II, III,
IV тощо) та латинські літери від A до J. Зафіксуйте свій час.
Треба виконати це завдання якомога швидше. Наведу при-
клад, як це зробити: пишете арабську цифру, потім рим-
ську, а потім літеру, щоб у вас вийшло таке:
1 I A
2 II B
3 III C
Зробімо це разом рядок за рядком. Зафіксуйте свій час.

У мене пішло на це тридцять дев’ять секунд. Тепер, замість
того щоб записувати рядками, зробіть це стовпчиками. Пер-
шими напишіть усі арабські цифри, потім римські, а потім
літери. Я зроблю це також. Вийшло дев’ятнадцять секунд.
Просто виконуючи завдання по одному за раз, а не пере-
микаючись із одного контексту на інший, я вдвічі зменшив
час, який це в мене забрало.
Я прямо чую, як ви кажете: «Гаразд, Сазерленде, все це до-

бре й годиться для розмов по мобільному та складання дур-
них переліків, але я керую компанією. Я мушу робити купу
речей за раз — наказувати своїм командам братися за п’ять
проектів водночас. Я мушу залишатися конкурентоспро-
можним. Я просто не можу дозволити собі цього не робити».
Ось де в пригоді знову стає величезна кількість досліджень

щодо розробки програмного забезпечення. Пам’ятаєте,
люди проводили ці дослідження через те, що постійно
марнували сотні мільйонів доларів на рік, а їхні продукти
ставали лише гіршими. І тому, будучи інженерами, вони
почали уважно вивчати дані та все вимірювати. Наводжу
вам чудову таблицю з класичної праці про розробку комп’ю-
терних програм «Управління якістю програмного забезпе-
чення» Джеральда Вайнберґа4:
Кількість Відсоток часу Втрати

одночасних для кожного через перемикання
проектів проекту контексту
1 100 % 0 %
2 40 % 20 %
3 20 % 40 %
4 10 % 60 %
5 5 % 75 %
Колонка «Втрати через перемикання контексту» відобра-

жує марнування в його чистому вигляді. Саме так: якщо
ви маєте п’ять проектів, то аж 75 відсотків вашої роботи
йде в нікуди — три чверті вашого дня спускається в унітаз.
Тому ви й не можете записувати рядки та колонки з одна-
ковою швидкістю. Це є наслідком фізичних обмежень ва-
шого мозку.
Один науковець на ім’я Гарольд Пашлер продемонстрував

це явище на початку 1990-х років. Він назвав його «взає-
мовпливом подвійного завдання». Пашлер провів кілька
простих експериментів. Одна група учасників виконувала
дійсно просте завдання, скажімо, натискати кнопку, коли
засвічується лампочка. А потім перед іншою групою ставили
це завдання плюс іще одне просте, наприклад, натискати
різні кнопки залежно від кольору лампочки. Одразу після
додавання ще одного завдання, хоч яким простим воно було,
потрібний для виконання час подвоювався. Пашлер вивів із
цього теорію про існування певного роду вузького місця
обробки інформації: люди насправді можуть думати лише
про одну річ за раз. Він припустив, що для завершення од-
ного процесу, звернення до пам’яті, виклику звідти іншого,
а потім виконання цієї роботи потрібні певні зусилля. І кож-
ного разу, коли ви переключаєтесь із одного завдання на
інше, це потребує більше часу5.
Як результат, цього не відбувається. Ви повністю концентру-

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

гаєтесь виконати якесь завдання? Візьмімо для прикладу
типову команду. Цього року вони вирішили виконати три

проекти. Назвемо їх A, B та C. Причому вони розпланували
свій рік зі словами, що попрацюють трохи над одним проек-
том, потім над другим, а там і над третім, так що їхній кален-
дар почав виглядати, як показано на с. 117.
Через намагання робити все одночасно — класична стра-

тегія — завершення цих трьох проектів забере в них час
до кінця липня. Але за рахунок підходу до завдань за сис-
темою Scrum та переведення кожного проекту до розділу
«Виконано» по одному за раз вони мінімізують витрати
перемикання контексту. Тобто зможуть завершити все ще
до початку травня.
Вони не змінюють розміру проекту або того, що передбачає

його втілення, а просто за рахунок виконання виключно
одного завдання перед тим, як рухатись далі, робота займає
трохи більш ніж половину всього часу. Половину!
А що ж таке ота друга половина? Насправді то марнування

в чистому вигляді. Протягом неї не виробляється жоден про-
дукт, не економиться жоден долар, не впроваджується жод-
на інновація. Це просто марнування людського життя. Це
робота без мети.
Отже, ось чого коштує багатозадачність. Ми всі живемо у сві-

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

даєте звіт, готуєте презентацію, розробляєте частину про-
грамного забезпечення чи пишете книжку, — то тримаєте
ВИЗНАЧЕННЯ ПРІОРИТЕТІВ СЕРЕД ПРОЕКТІВ
Продукт A A1 A2 A3 = А
Продукт В В1 В2 В3 = В
Продукт С C1 C2 C3 = С
Традиційна стратегія: «Важливе все! Робіть усе одразу!» А В С
A1 B1 C1 A2 B2 C2 A3 B3 C3
січень лютий березень квітень травень червень липень
Гнучка стратегія: «Пріоритети й зосередження»
A1 A2 A3 В1 В2 В3 С1 С2 С3
січень лютий березень квітень травень червень липень
А В С
в голові неймовірно складний об’єкт. Ви повинні зважати на

десятки чинників, пам’ятати, що вже зроблено, куди треба
рухатись далі і які для цього можуть бути перешкоди. Роби-
ти це зовсім не просто. А якщо ви змушені будете перерва-
тись або швидко перемкнутись на інший проект, хай навіть
на хвилину? Можете здогадатись: уся ретельно вибудувана
ментальна архітектура розвалиться. Повернення ж до того
самого стану зосередженості може зайняти години. Саме
таку ціну ми платимо. Тож мінімізуйте таке марнування,
не намагайтеся виконувати завдання всі одночасно, що ви-
магає особливого типу концентрації. Виділяйте для них
спеціальні періоди, коли можна буде вимкнути ваш телефон

і повісити на двері табличку «Не турбувати».
Насправді кілька досліджень показали, що багатозадачність

не лише марнує ваш час, але й робить вас дурними. Дослі-
дження, проведене в Університеті Лондона ще в 2005 р.7,
(звісно, дуже маленьке й неперевірене, та все ж…), оціни-
ло, наскільки дурними може зробити вас багатозадач-
ність. Психіатр Ґленн Вілсон узяв чотирьох чоловіків та
чотирьох жінок і перевірив їхній коефіцієнт розумового
розвитку в умовах спокою та в умовах відволікання (теле-
фонних дзвінків, надходження електронних листів). Під
час тестів він вимірював електропровідність шкіри об’єктів,
пульс та кров’яний тиск. Цікаво, що в умовах відволікання
середні розумові показники об’єктів падали більш ніж на
десять пунктів. А ще цікавіше, що це падіння більше вияв-
лялось у чоловіків, ніж у жінок (мабуть, із певних причин
жінки більш пристосовані до відволікання).
ЗРОБЛЕНЕ НАПОЛОВИНУ —
НЕ ЗРОБЛЕНЕ ВЗАГАЛІ
Як я вже згадував, Scrum черпає багато своїх ідей з япон-
ської виробничої моделі, розписаної в класичній книж-
ці «Виробнича система Toyota» Таїчі Оно. У Сполучених
Штатах цю модель інтерпретовано як «ощадливе вироб-
ництво». По суті, ідея полягає в тому, щоб якомога більше
позбутися марнування в роботі заводських цехів. Звісно,
більшість із нас сьогодні не шукає шляхів покращити ви-
робничий потік автозаводу, але деякі ідеї можна застосува-
ти взагалі до будь-якого виду роботи.
Одна з проблем, яку я хочу тут розглянути, називається

«незавершена робота» або просто «запаси». Суть проблеми
в тому, що це марнування — мати купу навалених скрізь
комплектуючих, які не використовуються для створення

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

мімо щось дуже просте, що є ледь не в кожного одружено-
го дорослого чоловіка на планеті: перелік хатніх справ,
складений дружиною. Будь-якого конкретно взятого тижня
мій перелік зазвичай нараховує від десяти до двадцяти
справ, про які я маю подбати. Вони варіюють від перефар-
бування ванної кімнати до поповнення запасів собачої їжі,
від сплати рахунків до згрібання опалого листя. Усе це ча-
стина повсякденного життя, типова для повноправних чле-
нів суспільства. Існує багато різних підходів до виконання
цього переліку. Але найбільшою помилкою, яку ви тільки
можете зробити, є намагання взятися за п’ять речей одно-
часно. Це багатозадачність, і ви навряд чи впораєтесь із
ними всіма, що залишить вас із незавершеною роботою.
Уявіть (чи згадайте, якщо вам уже колись так не пощасти-

ло), що у вас є п’ять завдань, виконаних частково. Ви по-
фарбували одну стіну ванної кімнати, собача їжа лишилась
у багажнику, рахунки заповнені, але не сплачені, а листя
зібране в купи, але не зсипане в мішки для сміття. Ви ви-
тратили зусилля, та не зробили нічого цінного. Цінність
настає, коли ганчір’я та бляшанки з-під фарби прибрано
з ванної, собака нагодований, комунальники отримали
свої гроші, а двір чистий. Зробити половину чогось — це,

по суті, не зробити нічого.
Як я вже казав, у Scrum існує робочий ритм. У кожному ци-

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

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

У грудні 2012 року компанія General Motors почала звіль-
няти працівників одного зі своїх автозаводів в Америці.
Чому? Компанія виробила забагато машин. На кінець ли-
стопада вони мали 245 853 повнорозмірні пікапи на стоян-
ках по всій країні. Це відповідало 139 дням перевиробни-
цтва. Приблизна вартість цих непроданих автівок складала
близько 7,5 мільярдів доларів. Мільярдів, не мільйонів! Усі
ці гроші — у цьому випадку у формі пікапів, але все одно
гроші — займали місце на стоянках, а не в банку. Тому ком-
панія мусила почати закривати заводи та звільняти людей
з роботи перед самісіньким Різдвом.
До скількох днів запасів має прагнути автокомпанія? Стан-

дартом для цієї галузі є приблизно шістдесят днів — менш
ніж половина від того, що мала General Motors. Подумайте
про це. Коли ви купуєте в крамниці собачу їжу, ви ж не бе-
рете її на півроку наперед. Вона займає місце в гаражі
і може коштувати стільки, що не вистачить на сплату кому-
налки цього місяця.
Тут ви можете подумати: «Стоп, вони ж виробили маши-

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

нами однієї проблеми: витрати зусиль без жодного пози-
тивного результату. Не робіть так.
РОБІТЬ УСЕ ПРАВИЛЬНО З ПЕРШОГО РАЗУ

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

лась на ринку автомобілів класу люкс. У Японії такі компанії,
як Toyota, Honda та Nissan, у середньому витрачали на ви-
готовлення розкішного авто 16,8 години. До заводського
цеху надходили потрібні деталі, і приблизно через 17 годин
з’являвся «Лексус». Причому на сотню автомобілів вони
мали лише 34 дефекти. Непогано.
У Європі ж підходили до справи інакше. Такі компанії, як

Mercedes-Benz, Audi та BMW, витрачали на одне авто 57 го-
дин і мали 78,7 дефекту на кожну сотню готових машин.
Чому європейцям було потрібно так багато часу? І чому

було так багато дефектів? Ніхто ж не скаже, що BMW ві-
дома виготовленням мотлоху. Ось чому: на заводі Toyota,
коли на конвеєрі з’являється якась проблема, кожен ро-
бітник має можливість зупинити всю лінію. Коли це ста-
ється, всі робітники збираються там, де виявлено брак, —
не покричати на того, хто зупинив роботу, а виправити
проблему, якою б вона не була. Вони не хочуть, щоб хоч
одна машина вийшла із заводу з дефектами, які доведеть-
ся виправляти потім. Вони виправляють проблему раз
і назавжди. Якщо цього не робити, той самий дефект може
з’явитися в сотнях автомобілів.
У європейських виробників розкішних машин був інший

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

ня проблем, ніж японському було потрібно для виготовлен-
ня майже ідеального авто відразу8.
Ви прочитали правильно. Німці витрачали більше часу на

доведення до ладу автівки, яку щойно виготовили, ніж япон-
ці на виготовлення нової. Це і є причиною, чому Toyota
стала автовиробником номер один на планеті. Там робили
все правильно з першого разу.
Звичайно, ми не завжди робимо все ідеально відразу. Ми

люди, і нам властиво помилятись. Але те, як ви даєте раду із
цими помилками, може мати величезний вплив на швид-
кість виконання роботи та рівень її якості. У Toyota, як я вже
казав, кожен робітник заводу може зупинити конвеєр. Ідея
в тому, що під час проходження різних етапів виробництва
процес дедалі ускладнюється, а тому виправляти проблеми
доцільніше відразу після їх виявлення, а не в самому кінці.
Кілька років тому я побував у Каліфорнії, де виступав пе-

ред розробниками з компанії Palm. Вони виготовляли те,
що пізніше було названо персональними цифровими асис-
тентами, які ми тепер знаємо як смартфони. Усі свої дії ці
люди відстежували автоматично. Одним із багатьох мо-
ментів, які вони вимірювали, була тривалість виправлен-
ня помилок у програмі. Іншими словами, скільки часу
займало у програміста виправлення проблеми, яку він
створив у системі. Кожного разу цей час ретельно відслід-
ковувався комп’ютером.
Уявіть, що одного дня під час спроби інтегрувати до реш-

ти системи код, написаний, скажімо, Меттом, було вияв-
лено помилку. Як і більшість програмістів, Метт не хотів
повертатись назад і виправляти цей код одразу. Натомість
він вирішив узятися за нього пізніше. Спочатку він напи-
ше новий код.
У більшості компаній тестування такого роду відбувається

навіть не в той самий день. Можуть минути тижні чи міся-
ці, перш ніж увесь код пройде перевірку, і проблеми буде
виявлено лише тоді. Але в Palm проводилося щоденне ав-
томатизоване тестування всіх кодів, тому помилку вони
виявляли одразу.
Вони придивились до таких «меттів» по всій компанії — со-

тень розробників — і вирішили проаналізувати, скільки за-
ймає виправлення помилки, якщо зробити це одразу, в по-
рівнянні зі спробою виправити її кількома тижнями пізніше.
Як ви розумієте, програмне забезпечення може бути доволі
складним та заплутаним. Ураховуючи це, якою, на вашу
думку, була різниця?
У двадцять чотири рази довше в другому випадку. Якщо

взятися за помилку в день її появи, на виправлення піде
якась година. Якщо ж через три тижні — це буде вже двад-
цять чотири години. І тут неважливо навіть, велика помил-
ка чи мала, складна чи проста — через три тижні на неї
завжди потрібно в двадцять чотири рази більше часу. Як
ви можете собі уявити, дуже скоро від кожного розробни-
ка програмного забезпечення в компанії почали вимагати
тестування та виправлення їхніх кодів у той самий день.
Людський розум має обмеження. Ми можемо пам’ятати

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

нутись у свідомість, якої більше не існує. На це потрібен
час. Багато часу. У двадцять чотири рази більше, ніж тре-
ба для виправлення проблеми відразу після її виявлення.
Переконаний, вам доводилося самим стикатися з таким

у роботі. Напевне, вам ще в дитинстві казали: «Роби все
правильно з першого разу». Єдине, що додалося сьогодні:
якщо ви робите помилку — а ми всі їх робимо, — виправ-
ляйте її, щойно помітите. Інакше пізніше вони вам дорого
коштуватимуть.
ПОНАДНОРМОВА ПРАЦЯ
ЗБІЛЬШУЄ ОБСЯГ РОБОТИ
Коли Скотт Максвелл, засновник фірми OpenView Venture
Partners, працював консультантом у McKinsey & Company
на початку 1990-х, він отримав настанову, яка здалася йому
доволі дивною. Джон Катценбах, тоді директор компанії,
а нині автор кількох книжок та голова Центру Катценбаха
при Booz Allen Hamilton, дав Скотту одну пораду, яку той
ніколи не забуде. Джон розповів, що в далекі сімдесяті,
коли він починав свою діяльність, усі в McKinsey працюва-
ли сім днів на тиждень. Такою була корпоративна культура,
і саме це очікувалось від усіх співробітників. Якщо ви не пра-
цювали стільки годин, вважалося, що ви не тягнете, не при-
носите достатньої користі команді.
З релігійних причин Джон Катценбах не ходив на роботу по

суботах. І він дещо помітив. Працюючи менше годин, він
насправді виконував більше за тих, хто працював кожного
дня — а такими в той час були майже всі його колеги. Тоді
він вирішив спробувати працювати лише п’ять днів на тиж-
день і виявив, що почав робити ще більше. Якщо працювати
забагато, зрозумів він, устигаєш менше. Він розповів Скотту,
що завжди хотів скоротити свій робочий тиждень до чоти-

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

глум. Працювати менше годин? Це ж девіз ледацюг, чи
не так? Але ідея залишилася зі Скоттом на довгі роки, коли
він просувався кар’єрними щаблями. Ставши ж засновни-
ком та генеральним директором OpenView Venture Partners,
він почав інвестувати гроші в технологічні компанії, деко-
трі з яких практикували Scrum. Він почув, що я, винахідник
Scrum, живу з ним в одному місті, й одного ранку запросив
мене на сніданок. За кавою з круасанами Скотт розповів
мені історію однієї з компаній, у які він інвестував, де ко-
манда розробників запровадила Scrum і змогла покращити
свою продуктивність спочатку на 25, а потім і на 35 від
сотків. Він був дійсно вражений. Моя ж щира реакція була
такою: «Двадцять п’ять? Тридцять п’ять? Та вони явно роб
лять щось не так!!!»
Скотт вирішив принести Scrum в OpenView та запрова

дити його по всій своїй компанії. Відділи інвестицій та
досліджень, вище керівництво, адміністративний персо-
нал — усі були включені в ту чи іншу Scrum-команду.
І врешті-решт сталося те, що є однією з найбільших пере-
ваг Scrum, — компанія виявила, як люди працюють не на
словах, а на ділі.
У той час OpenView була схожа на багато інших венчурних

компаній. У її корпоративну культуру було міцно вбудо-
ване очікування, що люди мають сидіти на роботі до піз-
ньої ночі, а також на вихідних. Це були енергійні, амбітні
люди, але вони швидко вигоряли, впадали в депресію та
деморалізувались. Обстановка була такою напруженою,
що деякі співробітники не могли більше її витримувати та
звільнялись.
ПОДВІЙНА КОРИСТЬ ВІД СКОРОЧЕННЯ

РОБОЧОГО НАВАНТАЖЕННЯ
200
180
Крива Максвелла
160
Scrum
140
Завершена робота
120
100
Каскадна
80 модель
60
40
20
0
0 10 20 30 40 50 60 70 80
Робочий тиждень
Але, як тільки команди цієї фірми почали практикувати

Scrum, Скотт помітив різку зміну продуктивності. Основний
акцент перестав робитись на понаднормову працю. Одного
дня він затягнув мене до себе в кабінет і намалював на до-
шці подану вище криву.
Вісь y — це продуктивність, а вісь x — години роботи. Пік

продуктивності насправді припадає на трохи менш ніж
сорокагодинний робочий тиждень. Озброєний цими дани-

ми, Скотт почав відправляти людей додому раніше.
«Їм знадобився певний час, щоб зрозуміти, що я не жар-

тую, — каже Скотт. — Але врешті-решт вони прийшли до
мого способу мислення».
Він почав розповідати людям, що пізня робота не є ознакою

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

боті. Коли люди йдуть у відпустку, передбачається, що вони
відпочиватимуть, а не перевірятимуть електронну пошту чи
будуть постійно на зв’язку з офісом. Понад те, якщо ви самі
не можете просто відключатись, не турбуючись весь час про
справи на роботі, керівник команд із вас не дуже добрий.
«Багато компаній такого не практикують [обмеження ро-

бочих годин], — каже Скотт. — Але ж тут існує пряма коре-
ляція. Ви виконуєте більше завдань. Ви стаєте щасливіши-
ми. Підвищується якість роботи». Не треба бути генієм,
щоб це зрозуміти. Працюючи менше, можна робити більше
з вищою якістю.
За словами Скотта, для різних людей крива буде різною,

навіть для однієї й тієї самої особи в різний час життя.
«Я помітив, як з віком та в різних ролях пік продуктивнос-
ті для мене змістився на меншу кількість годин, ніж це було
двадцять років тому», — каже він. На його думку, значення
тут має багато чинників, зокрема фізична форма, дієта,
особисті проблеми та інше. Але він також вважає, що сьо-
годні його продуктивність сягає піку швидше, бо він виріс
як спеціаліст та доволі глибоко вивчив характер роботи. «Я
тепер можу братися за дедалі складніші можливості».
Чому так відбувається: якщо працювати менше, виконуєш

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

доволі тривожні докази, що ми маємо дуже обмежену здат-
ність приймати рішення. Чим більше ми виснажуємось і чим
менше відпочиваємо, тим гірше нам це вдається.
У квітні 2011 року група ізраїльських дослідників опубліку-

вала в журналі Національної академії наук США цікаву стат-
тю. У цій праці під назвою «Зовнішні фактори прийняття
юридичних рішень» розглянуто понад тисячу постанов вось-
ми ізраїльських суддів, які засідали у двох різних комісіях
з умовно-дострокового звільнення. Постанови стосувались
злочинців-ізраїльтян єврейського та арабського походжен-
ня, чоловіків та жінок. Злочини варіювали від розтрати,
словесної образи та погроз до зґвалтування і вбивства. Пе-
реважна більшість розглянутих суддями справ були подані
на дострокове звільнення9.
Здається, тут усе доволі просто, чи не так? Поважні судді

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

ним щодо вашого звільнення чи незвільнення? Можливо,
щире каяття? Ваше виправлення та поведінка у в’язниці?
Тяжкість вашого злочину? Насправді нічого із цього. Вияв-

ляється, по-справжньому має значення лише те, коли суддя,
умовно кажучи, з’їв свій сендвіч.
Дослідження враховувало час, коли судді приймали рішен-

ня про помилування, а також проміжок, що відділяв їх від
можливості перекусити. Якщо вони лише взялися до роботи,
повернулися з перерви на каву чи обіду, позитивні рішення
приймалися більш ніж у 60 відсотках випадків. Натомість
перед самою перервою цей показник падав майже до нуля.
По суті, відразу після короткої перерви судді заходили до

зали з більш позитивним настроєм і приймали більш поблаж-
ливі рішення. Вони виявляли більше уяви та здатності поба-
чити, що світ і люди можуть змінитися, стати іншими. Але
в міру спалення своїх запасів енергії вони починали прийма-
ти дедалі більше рішень, що залишали злочинця у в’язниці.
Переконаний: якби ви спитали цих суддів, чи впевнені вони,

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

що той чи інший вибір передбачає витрати енергії. Це
дивний різновид виснаження: ви не почуваєтесь утомле-
ними фізично, але ваша здатність приймати правильні
рішення знижується. Насправді тут змінюється ваш само-
контроль — здатність залишатись дисциплінованими, роз-
судливими та передбачливими.
Зовсім нещодавно це продемонстрував інший цікавий екс-

перимент. Група дослідників прагнула з’ясувати, як при-
ймання рішень впливає на самоконтроль. Тому вони зібрали
типових об’єктів психологічних досліджень — студентів уні-
верситету — та провели із частиною з них сеанс прийняття

низки рішень. Зокрема, цим студентам представили різні
товари та попросили вибрати ті, які їм більше сподобаються.
Їх попросили уважно подумати перед цим, бо наприкінці
експерименту вони отримають подарунок, який залежатиме
від їхніх преференцій. Іншій частині студентів жодних рі-
шень приймати не доводилось10.
Тестовій групі поставили низку запитань. Які ароматичні

свічки їм подобаються — ванільні чи мигдалеві? Якій мар-
ці шампуню вони віддають перевагу? Які із запропонова-
них цукерок вони хотіли б з’їсти? А потім був класичний
тест на самоконтроль: якомога довше протримати руку
в крижаній воді.
Які б ресурси не спалювались у процесі прийняття рішень,

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

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

роботу та припинити вимірювати її годинами. Самі по собі
години — це витрати. Вимірюйте замість них досягнутий
результат. Яка різниця, хто скільки над чим працював?

Значення має лише те, як швидко робота виконується та
наскільки вона добра.
БУДЬТЕ РОЗСУДЛИВІ
За Таїчі Оно, існують три типи марнування, які ведуть до
того, що люди працюють важче та більше часу, ніж необхід-
но. Я щойно пояснив, чому понаднормова праця — це на-
прочуд погана ідея, але розуміння складників марнування,
яке Оно назвав мурі, тобто «непродуманість», «нерозсудли-
вість», є, мабуть, найпотужнішим із доступних нам інстру-
ментів досягнення змін.
Першим складником є «абсурдність». Ви маєте ставити

перед своєю командою амбітні цілі — підштовхувати її до
досягнення чогось більшого. Але ви не маєте вести її до
абсурдних, нереальних цілей.
Другим складником є «необґрунтовані очікування». Скільки

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

«перевантаження». Це поведінка, яку художник Скотт Адамс
регулярно висміює у своїх коміксах про Ділберта. Сюди на-

лежать обтяжлива політика компанії, що заважає роботі;
непотрібна бюрократія, коли люди змушені заповнювати
форми заради форм; пустопорожні зустрічі, що висмоктують
час і не приносять жодної користі.
Хоч Оно не згадав четвертого складника, на думку спадає

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

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

настільки вкорінились у нашому мисленні, що як альтерна-
тива нам потрібна найлегша процедура з найбільшим впли-
вом на роботу. Scrum якраз і зосереджує нас на намаганні
позбутися безцільного марнування, яке здається невід’єм-
ною частиною роботи. Я намагався створити його так, щоб
сама по собі процедура турбувала людей якнайменше, не за-
важаючи їм зосереджуватись на головному.
Найголовнішим для вас є досягти у своїй роботі так зва-

ного «потоку», який би не вимагав жодних зусиль. У бо-
йових мистецтвах чи медитативній практиці, коли ви до-
сягаєте відчуття єдності з рухом, він перестає бути зусиллям,
перетворюючись на енергію, що тече крізь вас вільним
потоком. Дивлячись на відомих танцюристів чи співаків,
ви просто-таки відчуваєте, як вони підкорюються силі,
більшій за них самих, дозволяючи їхньому мистецтву тек-
ти крізь них. Саме досягнення такого стану в нашій робо-
ті ми й повинні всі прагнути.
Але, як скаже вам будь-який майстер кунг-фу, монах, тан-

цюрист чи оперний співак, в основі потоку лежить дисци-
пліна. Там не має бути жодного зайвого руху — нічого
стороннього, лише зосереджене застосування людських
можливостей. Усе, що відволікає вас від цього, є марну-
ванням. Якщо ви почнете дивитись на роботу з точки зору
дисципліни та потоку, то зможете досягти просто неймо-
вірного результату.
Багатозадачність робить вас дурними. Виконання

більш ніж одного завдання за раз гальмує та погіршує
обидва. Не робіть цього. Якщо ви думаєте, що вас це
не стосується, то помиляєтесь — ще й як стосується.
Виконане наполовину — невиконане зовсім. Напо-

ловину зібраний автомобіль просто зв’язує ресурси, які
можна було б використати, щоб зробити щось цінне або
зекономити. Усе незавершене коштує грошей та енергії,
не приносячи геть нічого.
Робіть усе як слід з першого разу. Зробивши помилку,

виправляйте її відразу. Зупиняйте все інше та беріться
за неї. Виправлення її пізніше може забрати у вас у двад-

цять чотири рази більше часу, ніж якщо виправити її без
затримки.
Понаднормова робота лише збільшує роботу. Якщо

працювати довше, ви не зробите більше. Ви зробите
менше. Надмірна праця викликає втому, призводячи до
помилок, які змушують виправляти те, що ви тільки-но
закінчили. Замість того щоб працювати до пізньої ночі
чи на вихідних, працюйте лише в робочий час у постій-
ному темпі. І обов’язково беріть відпустку.
Не будьте нерозсудливими. Амбітні цілі мотивують.

Нереалістичні викликають депресію.
Без героїзму. Якщо для виконання роботи вам потрібен

герой, то у вас проблема. Героїчні зусилля мають розці-
нюватись як провал планування.
Досить дурних правил. Будь-які правила, що здаються

сміховинними, скоріше за все, такими і є. Дурні форми,
дурні зустрічі, дурні узгодження, дурні стандарти є саме
такими — дурними. Якщо ваш офіс здається схожим на
комікс про Ділберта, виправте це.
Жодних гівнюків. Не будьте ними самі і не дозволяйте

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

решкодний спосіб виконування завдань. Scrum якраз і по-
кликаний допомогти вам досягти найбільшого потоку.
РОЗДІЛ 6. ПЛАНУЙТЕ РЕАЛЬНІСТЬ,
А НЕ ФАНТАЗІЮ
138 Плануйте реальність, а не фантазію
«Слухай, Джеффе, у нас проблема!»
Саме так починаються багато з моїх телефонних розмов.

Люди самі заганяють себе у глухий кут, а потім хапаються
за телефон і дзвонять мені. Цього разу то був Марк Ленді,
головний розробник архітектури програмного забезпе-
чення фірми Medco, яка надсилає ліки поштою. На час
того дзвінка Medco входила до рейтингу ста найуспішні-
ших фірм за версією журналу Fortune, отримуючи близько
38 мільярдів доларів річного доходу та будучи найбільшою
в країні фармацевтичною компанією, на яку працювали
десятки тисяч людей. При всьому цьому їхнє керівництво
стрімко вело їх до прірви.
Дзвінок цей пролунав у грудні 2006 року. У липні прези-

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

зв’язок пацієнта з фармацевтом, щоб останній знав не лише
про конкретні ліки, але й про всі препарати, прописані цій
людині. Це було особливо важливим для пацієнтів із хро-
нічними проблемами, на кшталт діабету чи хвороб серця,
які мають 80 відсотків людей, що постійно сидять на меди-
каментах. Причому більшість цих людей — особливо літ-
ніх — приймають по шість чи більше препаратів одночасно.
Плануйте реальність, а не фантазію 139
Їхні ж лікарі — спеціалісти з різних сфер охорони здоров’я —

не завжди це розуміють.
«Лікарі не [завжди] діляться інформацією один з одним.

Ми, аптека, дізнаємося більше за них, причому в реально-
му часі, [навіть] раніше за страхувальників здоров’я», —
казав Ленді.
Отже, ідея президента Medco була такою: створити спеціа-

лізовані аптеки в п’яти різних місцях по всій країні. Там
будуть аптеки для людей із хворобами серця, діабетиків,
астматиків і т. д. І спеціально підготувати для цих аптек
фармацевтів, які були б у курсі взаємодії тих чи інших ліків,
побічних ефектів тощо. Оскільки ці фармацевти матимуть
глибокі знання про стан пацієнтів, вони зможуть повідом-
ляти лікарів про можливі протипоказання. Уявімо, напри-
клад, що хтось страждає на діабет. Скоріш за все, ця люди-
на має зайву вагу та проблеми з печінкою. Як результат,
ліки в неї засвоюються не так, як у інших. Тому, якщо новий
лікар прописує препарати для нормалізації тиску, фарма-
цевт Medco може зателефонувати йому й порекомендувати
переглянути печінкові проби пацієнта, у разі потреби ско-
ригувавши дозування.
Метою цього було привести до Medco нових клієнтів, яких

здебільшого обслуговували різні страхові компанії. За до-
помогою цих нових аптек, чи лікувально-оздоровчих цен-
трів, як їх вирішили назвати, клієнти могли б економити
гроші, зменшивши не стільки витрати на свої ліки, скіль-
ки загальні медичні витрати. Адже ті суттєво зростають,
коли люди лікуються неправильно або приймають пре
парати, що погано взаємодіють один з одним або про-
сто не підходять цій конкретній особі. Понад те, Medco
гарантувала економію коштів. Якщо клієнт не зеконо-
мить прогнозовану суму, компанія зобов’язувалась повер-
нути йому різницю.
На Волл-стрит, м’яко кажучи, сподобалась ця новина. Дово-

лі класна ідея, чи не так? Економити гроші й надавати краще
медичне обслуговування. Більше клієнтів, більше продажів.
Ситуація з гарантованим виграшем. Була лиш одна пробле-
ма. Хоча Клеппер і перевірив зі своїми менеджерами, що
ідея технічно можлива, він не уточнив, скільки часу займе
впровадження цього плану. Люди, які дійсно мали цим за-
йматись, зробили це лише після того, як їхній президент
пообіцяв Волл-стрит, що нова система запрацює 7 липня
2007 року. Хай там що, за будь-яких умов.
Дотриматись цього дедлайну було для Medco особливо важ-

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

Medco шанс удосконалити їхню систему й залишатися на
крок попереду конкурентів. Проте приблизно через пів-
року в компанії зрозуміли, що вони не встигнуть підготу-
вати все вчасно. Їхні розрахунки показували, що в най
кращому разі систему буде запущено щонайменше на рік
пізніше. Можливо, навіть більше. Саме тоді вони й звер-
нулися до мене.
Чому ж їм знадобилось аж шість місяців, щоб зрозуміти

своє запізнення? Спробуймо відповісти на це питання ра-
зом. Не те щоб вони були недостатньо розумними, не мали
під рукою відповідних команд або технологій. Не те щоб

вони недостатньо напружено працювали чи не прагнули
обійти конкурентів. Адже без усього цього просто немож-
ливо стати найбільшою компанією у своїй галузі.
Розробники проекту просто припустилися дуже типової по-

милки. Вони вирішили, що можуть спланувати все наперед.
Вони витратили місяці зусиль на детальні плани, що здава-
лися бездоганними — викладені в гарних графіках і чітких
кроках та майже завжди нескінченно далекі від реальності.
Як я вже казав раніше, планування дуже часто так приваб

лює та захоплює, що стає для людей важливішим за сам
план. А план — важливішим за реальність. Проте завжди
слід пам’ятати: гладенько буває лише на папері.
Коли команда вперше сідає за створення плану проекту,

приміщення часто немов електризується — наповнюється
відчуттям можливостей, відкриття нових світів та випро-
бування нових ідей. Це дійсно є одним з найкращих від-
чуттів у житті.
А потім настає момент, коли натхнення перетворюється на

розрахунки, і частина енергії розсіюється. Люди починають
розмірковувати: «Як нам дійсно потрапити з точки А в точ-
ку B? І, коли ми це визначимо, скільки часу піде на дорогу?»
На жаль, такий етап розрахунку часто стає простим марну-

ванням часу. Залучені до нього люди можуть бути дуже ро-
зумними, але все одно не розуміти, що закладають у графі-
ки свого планування лише бажане, а не дійсне.
Коли Марк Ленді пояснив мені ситуацію, що склалася

в Medco, я відповів: «У вас таки проблема». А після коро-
тенької паузи продовжив: «Але я впевнений, що ми зможе-
мо її розв’язати».
Довелося мені перед самим Різдвом летіти до Нью-Джерсі,

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

Брентові Бертону, Scrum-тренеру, з яким працював разом
над іншими проектами. «Бренте, — мовив я, — мені потрі-
бен ти та всі, кого ти зможеш зібрати до початку січня.
Є робота, що неначе саме на нас чекала».
Пізніше Брент розповідав, що, прийшовши в Medco, по-

бачив «компанію в глухому куті». Там було стільки інте-
ресів та різних розумників, що не робилося геть нічого.
Першого дня ми зустрілися десь із сімома різними група-
ми працівників, кожна з яких володіла своєю частиною
проекту і жодна не була щиро зацікавлена спробувати
щось нове. Але, як він каже сьогодні: «Ми могли дозволи-
ти собі розкіш називати речі своїми іменами. Адже кон-
сультанти спокійно можуть брати собі в союзники біль та
страх. Натрапляючи на спротив, ми просто казали їм: “Агов,
ви можете діяти, як і раніше, залишити все без змін, зда-
ти роботу із запізненням, якщо це вас влаштовує”. І тоді
у відповідь чули: “Не влаштовує”».
Перш за все ми зібрали всіх у конференц-залі: усіх ключових

гравців, усіх, хто насправді мав виконувати роботу. І Брент
наказав їм роздрукувати всі наявні документи, що описува-
ли вимоги до проекту. Причому електронна версія не при-
ймалась, потрібні були папери.
Ми сиділи у великій залі розміром приблизно п’ятнадцять

на п’ятнадцять метрів, без вікон, як, здається, усі такі при-
міщення, хоч і не знаю чому. Посередині стояв стіл, де ми

звалили всі принесені людьми документи. Стос вийшов
вищим за півметра.
— Хто з вас насправді все це прочитав? — спитав я.
А у відповідь — тиша.
— Але послухайте, — звернувся я до одного з менедже-

рів, — ви ж це підписували. Ось ваш підпис. Невже ви
цього не читали?
Знову незручна тиша.
Я не хотів його підколювати, але факт залишається фак-

том: проект за проектом люди вирізають та вставляють
шматки тексту, використовують різні шаблони докумен-
тів, але ніхто насправді не читає всі ці тисячі сторінок. Це
просто фізично неможливо. Ось у чому проблема. Вони
запровадили систему, що змушує їх схвалювати фантазію.
Тому ми з Брентом дістали ножиці, скотч, клей-олівці та

стікери. Схоже на те, що ми дійсно навчилися всього, що
треба знати, ще в дитячому садку.
«Ось що ми зараз зробимо, — сказав Брент. — Ми візьмемо цю

купу паперу та повирізаємо все, що дійсно потрібно зробити
для виконання цього проекту. А потім розклеїмо це на стіні».
Саме цим люди й займалися наступні кілька годин. У кінці

ми отримали три стіни, вкриті сотнями й сотнями папірців.
При цьому на столі лишилася більш ніж половина стосу,
з якого ми почали.
Дублікати, шаблони, канцеляризми. Абсолютне марнуван-

ня часу та зусиль.
Після цього я сказав членам команди: «Тепер нам потрібно

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

способах оцінювати роботу, бо насправді люди дуже погано
це вміють. Але того разу я навчив їх швидкого та брудного
методу, найкращого з цілої купи поганих способів, яким
вони й скористалися.
Їм знадобився деякий час, але вони впорались. Тепер на

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

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

чогось досягли. Тепер вони бачили, що треба робити.
— Гаразд, — спитав Брент. — Що нам потрібно зробити

спочатку?
Десь із п’ятеро співробітників висловили свої думки.
— А потім?
Висловились іще п’ятеро, запропонувавши цього разу інші

ідеї.
— А потім?
Ми хотіли, щоб вони зробили те, що подобається далеко

не всім: розставили пріоритети. Дуже часто люди просто
кажуть, що важливе все. Але Брент прагнув почути відпо-
відь на питання: «Що принесе проекту найбільшу цінність?»
Це ми спочатку й зробимо.
У кінці ми мали на стінах шість рядів стікерів, кожен з яких

був іншого кольору та представляв іншу команду. Переліки
завдань простяглись уздовж трьох сторін приміщення. Те-
пер я знав, що ми можемо хоча б почати.
ПЛАНУВАННЯ ВЕСІЛЛЯ
Викладена таким чином проблема може здаватися простою,
але дозвольте мені проілюструвати етапи процесу плануван-
ня на прикладі меншого масштабу: весілля. Офіційне весіл-
ля — це проект, із багатьма речами, які слід виконати до
конкретної дати, і всі одружені знають (а неодружені скоро
дізнаються), що тут усе завжди йде поза планом та віднімає
в чотири рази більше зусиль, ніж передбачалось.
Звичайно, може статись також і по-іншому: те, на що ви

виділяли години, пролетить за п’ятнадцять хвилин. І тут
знову постає вічне питання: «Чому ми так погано вміємо
оцінювати тривалість подій?»
А ми ж таки поганенько це вміємо. Повернемось до весілля

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

коливатися від 400 до 25 відсотків реально витраченого на
неї часу. Верхня та нижня межі оцінок різняться в шістнад-
цять разів. Причому в міру просування та виконання про-
екту оцінки дедалі більше вкладаються в межі реальності,
доки не залишиться сама тільки реальність без жодних
приблизних оцінок.
Згадаймо ситуацію з компанією Medco. Вони витратили мі-

сяці на планування своїх зусиль: як виглядатиме готовий
продукт, скільки часу на нього піде. Але навіть після всіх цих
місяців дослідження показує, що кожного разу вони, схоже,
помилялися в цілих чотири рази. Ось чому, на мою думку,
каскадна модель є дійсно безглуздим способом планування.
Я прямо чую, як ви кажете: «Гаразд, Сазерленде, ми погано

вміємо оцінювати, але я ж маю щось робити, правильно?
У мене повинен бути хоч якийсь план». Так, повинен. Але
ключем тут є вдосконалення плану протягом проекту, а не
затвердження його заздалегідь. Просто закладайте у свій
план достатньо деталей для наступного підвищення цінно-
сті, тоді як решту проекту оцінюйте більшими шматками.
У Scrum наприкінці кожного спринту ви отримуєте щось
цінне, що можна побачити, помацати й показати клієнтам.
Ви можете спитати їх: «Чи цього ви хочете? Чи розв’язує
це хоча б частину вашої проблеми? Чи рухаємось ми у пра-
КОНУС НЕВИЗНАЧЕНОСТІ
4х
2х
1,5х
1,25х
1,0х
0,8х
0,67х
0,5х
0,25х
0
Час
Варіативність в оцінці масштабу проекту
(зусиль, вартості, характеристик)
вильному напрямку?» І якщо відповідь негативна, змінити

свій план.
То як це зробити?
Повернімося до весілля. Перш за все треба скласти перелік

усіх речей, з яких складається успішна подія такого роду. Він
може мати приблизно такий вигляд:
• наречена та наречений
• квіти
• запрошення
• церква
• зала для прийому гостей

• частування
• священик
• сукня
• обручки
• музика (ді-джей чи оркестр)
Тепер слід зробити ось що: взяти всі ці складники й роз-

сортувати їх за пріоритетами. Для різних людей результат
буде різним. Кожна наречена та кожен наречений див-
ляться на світ по-іншому. Але якось я спитав свого друга
Алекса, як він розставив пріоритети у своєму переліку,
і ось що вийшло в нього:
• наречена та наречений
• священик
• обручки
• зала для прийому гостей
• запрошення
• частування
• музика
• сукня
• квіти
• церква
Сенс цієї вправи — визначити дійсно важливі речі та взя-

тися за них передусім. Для Алекса частування та музика
важливіші за церкву чи квіти. Це важливо, бо якщо ви
не встигатимете чи не вкладатиметесь у кошторис, то бу-
дете знати, із чого почати скорочення — з кінця вашого
переліку. Я детальніше зупинюся на цьому в розділі 8,
а наразі, мабуть, досить.
У Medco такий перелік зайняв три стіни великої конфе-

ренц-зали, нараховуючи сотні пунктів, підготованих шість-
ма різними командами. Але концепція була повністю та-
кою самою. Організуйте перелік за цінністю, якою б вона

не була. У випадку Medco це може бути цінність бізнесу,
а у випадку весілля — щастя нареченої.
РОЗМІР МАЄ ЗНАЧЕННЯ, АЛЕ ЛИШЕ ВІДНОСНО

Отже, ви маєте перед собою перелік речей, які потрібно
виконати, і пріоритети розставлено. Тепер слід визначити,
скільки зусиль, часу та грошей коштуватиме проект. Як
я вже наголошував, ми, люди, абсолютно не вміємо це ро-
бити. Але добре вміємо давати відносні оцінки — порівню-
вати між собою різні розміри. Наприклад, виявляти різни-
цю між малими, середніми та великими футболками.
Моїм улюбленим прикладом відносного оцінювання є «со-

бакометр». Кілька років тому мій друг, один із провідних
майстрів гнучкого мислення Майк Кон, як і я, намагався
розв’язати проблему виконання проектів вчасно та в межах
бюджету, а також їх оцінювання. Будучи любителем собак,
хоча дружина не дозволила йому завести пса, він почав
питати свою команду, завбільшки з якого собаку є кожен
шматок проекту. Він навіть запропонував використовувати
для порівняння деякі породи:
• лабрадор-ретривер
• тер’єр
• данський дог
• пудель
• такса
• німецька вівчарка
• ірландський сетер
• бульдог
Після цього його питання почали звучати так: «Гаразд, ця

проблема — це в нас такса чи данський дог? Якщо та була
таксою, то ця має бути розміром з лабрадора, чи не так?»

А потім команди проглядали всі моменти, які мали роз-
робити, й оцінювали їх за розмірами собак. Трохи згодом
Майк сказав: «А давайте надамо кожній породі цифрове
значення. Так простіше. Такса в нас буде одиниця, дог —
тринадцять. Тоді лабрадор стане п’ятіркою, а бульдог —
трійкою»1.
Те саме можна зробити з весільним переліком, який ми

з вами щойно склали. Знайти відповідне приміщення? Ну,
доведеться попрацювати, пошукати інформацію, походити
та подивитись. Це потребує зусиль. Назвімо це проблемою
завбільшки з лабрадора, п’ятіркою. Наречена й наречений?
Жодних проблем: нам просто треба обом з’явитися вчасно.
Це буде «такса» — одиниця, нічого такого. От із запрошен-
нями вийде складніше. Треба буде скласти наш власний
перелік гостей, урахувати переліки наших матерів, вибрати
папір та конверти, роздрукувати запрошення, надписати
адреси. Це вже великий проект — «дог», тринадцять. Може,
навіть два «доги». А якщо щось настільки велике, його,
мабуть, слід розбити на менші шматки. Як щодо того, щоб
зробити відбір гостей одним проектом, а роздрук іншим?
Те й друге потягне на «бульдога», чи не так? Назвімо їх
трійками. Надписування адрес буде «лабрадором», п’ятір-
кою. І далі в тому ж дусі.
От вам і відносне оцінювання — порівняння завдань між

собою. Тут ми, на жаль, не використовуємо всіх собак, але
ви, можливо, помітили послідовність чисел, яку я вибуду-
вав: 1, 3, 5, 8, 13. Кожне число в цьому ряді дорівнює сумі
двох попередніх. Це називається «послідовність Фібонач-
чі», і для її використання є певні причини. Адже вона про-
стежується скрізь і всюди.
Саме в такій послідовності проявляється все живе: черепаш-

ка черевоногого молюска, крона дерева, опуклості ананаса
ПОСЛІДОВНІСТЬ ФІБОНАЧЧІ: УСЕ НАВКОЛО НАС
• Послідовність Фібоначчі — це схема, де наступне число

є сумою двох попередніх:
0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55…
• Вона простежується в усіх природних системах, тому зна-

йома людям тисячі років.
чи луска соснової шишки. Її видно в суцвіттях цвітної ка-

пусти та звивинах людського мозку. Вона однакова в завит-
ках листя папороті та формі галактики. Це одне з тих явищ,
які здаються дивною примхою природи.
Цей феномен має свою назву — «золотий перетин». Ми

бачимо його в пам’ятках архітектури та витворах мисте-
цтва. Від Парфенону в Афінах до Великої мечеті Кайруана
в Тунісі. Він використовується для визначення розміру
й форми сторінок у книжці, а також пропорцій гральних
карт. Люди запрограмовані вважати такі пропорції при
вабливими. Що ж до ділових практик, то достатньо розумі-
ти: наш вид глибоко відчуває пропорції послідовності Фібо-
наччі. Просто-таки спинним мозком.
Числа в послідовності Фібоначчі достатньо віддалені одне

від одного, тому ми легко можемо бачити різницю. Людям
нескладно рухатись нею з одного боку чи іншого. Якщо
одна особа оцінить щось на п’ять, а друга на вісім, ми інту-
їтивно відчуємо різницю. А як щодо різниці між п’ятіркою
і шісткою? Вона вже доволі незначна, і наші мізки не завж-
ди можуть її відчути.
У медицині добре відомо, що для сприйняття пацієнтами

покращення їхнього стану воно має перевищувати 65 від-
сотків. Наш розум не працює з незначним приростом. Ми
краще сприймаємо переходи з одного стану до іншого —
і не гладенькі, а різкі стрибки.
Використання послідовності Фібоначчі для розрахунку роз-

міру завдання дозволяє робити оцінки, що не обов’язково
мають бути на всі сто відсотків точними. Ніщо не буде точ-
но п’ятіркою, вісімкою чи тринадцяткою, але за допомогою
цих чисел можна збирати думки про розмір завдань, де всі
користуватимуться приблизно однаковим мірилом, і дося-
гати таким чином згоди.
Таке групове оцінювання виходить значно точнішим за

індивідуальне.
ДЕЛЬФІЙСЬКИЙ ОРАКУЛ
Отже, тепер ми знаємо, що добре вміємо порівнювати речі
між собою. Ми також знаємо найкращий підхід до розв’я-
зання завдань. Але як ним скористатись? Перелік пріори-
тетних речей — це все добре, але як же нам визначити, що
в нас п’ятірка, а що вісімка, що «лабрадор», а що «вівчарка»?
І навіть якщо одна людина має доволі добру ідею, як нам
переконатися, що її оцінки збігаються з думками всіх інших?
Що як вона не врахувала якихось ключових факторів?
Звісно, ця проблема не нова. Люди билися над нею десят-

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

каскад». Автори статті «Теорія фантазій, моди, звичаїв
та культурних змін як інформаційних каскадів» Сушил
Біхчандані, Девід Гіршляйфер та Іво Велч сказали про це
так: «Інформаційний каскад виникає, коли для людини

оптимально, поспостерігавши за діями попередників, пов-
торити їх, незважаючи на її власну інформацію»2.
Автори наводять чудовий приклад — подачу статті до яко-

гось журналу. Скажімо, редактор першого журналу її відхи-
ляє. Тоді автор подає ту саму статтю до другого журналу.
Редактор цього журналу, навчений відмовою першого, най
імовірніше, також відмовить. І, якщо буде третій журнал,
його редактор, знаючи про дві попередні відмови, відмовить
іще ймовірніше. Люди схильні вважати, що інші приймають
правильні рішення, навіть якщо ті суперечать їхнім власним.
Це погано. Приймаючи рішення про те, коли буде готовий
багатомільярдний проект — або чи встигнете ви підготувати
все до дня весілля, — дуже важливо спиратися на власні
судження. Оцінки інших можна використовувати лише для
покращення власних, а ніяк не їх заміни.
Інша добре відома проблема називається «ефектом орео-

лу». Це коли одна характеристика чогось впливає на те, як
люди сприймають інші, не пов’язані з нею. Перше емпірич-
не дослідження цього провів у 1920 році Едвард Лі Торн-
дайк. У його класичній праці «Постійна помилка в психо-
логічних оцінках» Торндайк описує, як просив армійських
офіцерів оцінити їхніх солдатів за різноманітними якостя-
ми — фізичними, інтелектуальними, лідерськими, особи-
стісними тощо. Потім він дивився на те, як один набір яко-
стей впливає на оцінку інших. Дослідник виявив, що вони
корелюють аж занадто тісно. Якщо чиїсь фізичні дані оці-
нено високо, те саме стосується його лідерських якостей,
інтелекту й характеру.
З роками ці результати було підтверджено дальшими до-

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

просто фізична краса, і може проявитися будь-де. Дослід-
ники зазначають, наприклад, що неурядові організації ча-
сто вважаються силами добра, навіть якщо це не так; авто-
мобільні компанії створюють один класний автомобіль для
поширення чудового враження на всю лінійку, а iPod надає
сприйняття крутизни всім продуктам Apple.
Як і з ефектом стадності, люди, зосереджені на ореолі, не

зважають на реальні дані. Скоріше вони тяжіють до чогось,
що має на собі блиск позитиву. Знову ж таки, це не відсут-
ність волі, а природа людей.
Боротися з нею лоб у лоб немає сенсу — це все одно, що

боротися із силою тяжіння.
Але розбиратися в цьому можна і треба. У 1950-х роках

працівників корпорації Rand попросили відповісти на ряд
доволі незручних питань, які були популярні в часи «хо-
лодної війни». Нагадуючи своєю термінологією про Дель-
фійського оракула (жрицю, яка могла передбачати майбут-
нє), Норман Делкі та Олаф Гелмер опублікували в 1963 році
статтю під назвою «Експериментальне застосування дель-
фійського методу в роботі експертів», з корисним посилан-
ням «Записка RM-727/1, скорочена». У цій статті вони за-
явили про свій намір ставити питання так, щоб думки
однієї особи не впливали на інших. Для цього вони зібрали
групу експертів: чотирьох економістів, фахівця з фізичної
уразливості, системного аналітика та інженера-електрика.
Цим людям запропонували таке:
застосувати експертну думку до вибору оптимальної, з точ-

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

бомб потрібно СРСР, щоб не дати нам виготовляти наші влас-
ні бомби. Це були часи, коли ядерний конфлікт розглядали
не лише як можливий, але і як потенційно переможний.
При цьому Делкі та Гелмер не хотіли, щоб їхні експерти

впливали один на одного. Але що як один з них є завідува-
чем кафедри великого університету, а інший — звичайним
викладачем маленького коледжу? Як завадити одній люди-
ні хибно вплинути на думки колег?
Дослідники вигадали ряд анонімних опитувань. Жоден з екс-

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

для 50-відсоткової гарантії руйнування військової промисло-
вості США, оцінювалась у діапазоні від 50 штук мінімум до
5000 максимум. Коли Делкі та Гелмер проаналізували відпо-
віді, їм здалося, що в думках експертів є деякі спільні моменти —
уразливість деяких мішеней, відновлюваність різноманітних
галузей промисловості, вихідні запаси тощо. Тоді вони запита-
ли експертів, чи є ці викладки правильними і яку іншу інфор-
мацію вони використовували в підготовці своїх відповідей.
Після цього їх просто засипали даними від міцності заводів

до різниці між фізичною та економічною уразливістю та
циклів виробництва окремих компонентів.
Дослідники зібрали ці дані й роздали їх усім експертам,

запитавши, скільки потрібно бомб тепер? Цього разу діа-
пазон склав від 89 до 800 штук. Вони зробили це знову.
І знову. Розбіжність результатів продовжувала звужува-

тись. Урешті-решт, вона скоротилась остаточно, склавши
від 167 до 360 необхідних ядерних зарядів.
Здатність відсіяти неймовірно широкий діапазон оцінок

(із 10 000 до приблизно 200 відсотків) є надзвичайно по-
тужним інструментом для політики. Вона дозволяє досягти
загальної згоди експертів, не турбуючись про можливі від-
хилення в той чи інший бік. Цей інструмент є настільки
ефективним, що й досі використовується корпорацією Rand.
Одним із нещодавніх прикладів було застосування дель-
фійського методу в 2011 році для оцінки шансів Сполучених
Штатів на успіх в афганському конфлікті. Прогнози, якщо
вам цікаво, були не райдужні.
ПЛАНУВАЛЬНИЙ ПОКЕР
Отже, перевагою дельфійського методу є те, що він збирає
широке розмаїття думок, намагається максимально виключити
необ’єктивність і за допомогою поінформованих, але ано-
німних тверджень звужує думки до загальноприйнятної
оцінки. У нашому випадку погано те, що він задовгий. По-
чавши працювати з командами в Medco, я не міг дозволити
собі гаяти час на анонімні опитування. Я прагнув оцінки
всіх цих сотень завдань протягом годин, а не днів і вже
точно не тижнів.
На щастя, існує й інший спосіб збирання оцінок, доволі

швидкий та точний. Він називається «планувальний покер».
Ідея тут проста. Усім «гравцям» дають по колоді карт, на

яких зображені оці цікаві числа з послідовності Фібоначчі:
1, 3, 5, 8, 13 і т. д. Кожне завдання, що потребує оцінки, по
черзі викладається на стіл. Тоді всі витягають карту, яка, на
їхню думку, відображує правильну кількість зусиль, і кладуть
3 4 5 8 13
2
1
13
13
її на стіл цифрою донизу. Після цього всі одночасно відкри-

вають свої карти. Якщо різниця значень не перевищує двох
карт (скажімо, п’ятірка, дві вісімки та тринадцятка), то ко-
манда просто виводить середнє арифметичне (у цьому ви-
падку 6,6), переходячи до наступного завдання. Пам’ятайте:
ми говоримо про оцінки, а не залізні графіки. Причому оцін-
ки невеликих частин проекту.
Якщо ж різниця перевищує три карти, ті, хто поклав карту

з найбільшим та найменшим числами, пояснюють, чому
вони так вважають. А потім усі проходять ще один раунд
планувального покеру. Бо інакше середні оцінки зроблять
дані надто неточними, на кшталт запропонованих статисти-
ками корпорації Rand спочатку.
Наведу приклад. Скажімо, ви фарбуєте стіни всередині бу-

динку, і вам потрібно оцінити, скільки часу піде на віталь-
ню, кухню та дві спальні. Причому вам допомагає команда,
з якою ви вже фарбували кімнати раніше. Отже, спочатку
беремо дві спальні: всі оцінюють їх як трійку. Жодних сер-
йозних заперечень — ви всі робили це раніше і не бачите зі

спальнями якихось проблем. Потім команда оцінює віталь-
ню. Це доволі велика кімната, але цілком проста. Оцінки
малярів розходяться від п’ятірки до тринадцятки, вреш-
ті-решт даючи в середньому шістку. І знову жодних обго-
ворень не потрібно. Далі йде кухня, і тут на столі з’являють-
ся трійка, вісімка, тринадцятка та п’ятірка. Той, хто поклав
трійку, заявляє, що це приміщення доволі мале і площа стін
там навіть менша, ніж у спальнях. Власник тринадцятки
заперечує, що дуже багато часу піде на захист від фарби
всіх шафок та шухляд, а фарбувати невеличкі ділянки до-
ведеться пензлем, а не валиком. Команда швидко викла-
дає карти знову. Тепер трійка стає вісімкою, а все інше
залишається без змін. Оцінки стають досить близькими,
їх додають, виводять середнє арифметичне й переходять
до наступного завдання.
Цей дивовижно простий метод дає можливість уникнути

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

у Пенсильванії з компанією онлайнових продажів GSI Com-
merce. Пізніше їх купила eBay. Компанія займається диза-
йном онлайнових магазинів для таких фірм, як Levi’s, Toys
«R» Us, Major League Baseball і Zales Diamonds. Аж ніяк
не маленькі проекти. І GSI доволі добре дає їм раду.
Але тоді ця компанія мала ідею, яка здавалася цілком непо-

ганою. Вона полягала в тому, що замість оцінювання завдан-
ня кожною окремою командою його доручатимуть найкра-
щим оцінювачам компанії — найрозумнішим, які дійсно
розбираються в проектах і технологіях та знають, що потрібно
виконати. Так і зробили з кількома проектами. За попе-

редніми оцінками, один мав зайняти стільки-то часу, ін-
ший — стільки-то і т. д. Планувалося представити оцінки
вісімдесяти багатомільйонних проектів клієнтам та ко-
мандам, які дійсно виконуватимуть роботу. Здається ціл-
ком розумним, чи не так?
Проте цей спосіб виявився настільки неправильним, що

вони зупинили експеримент на півдорозі, після виконання
лише сорока проектів. Мені це нагадує клінічні дослідження
лікарських препаратів, зупинені через те, що ліки не лікують
пацієнтів, а вбивають їх. Оцінки були настільки далекими
від реальності, що не давали ніякої користі. Нічого не зда-
валося вчасно. Серед клієнтів зростало невдоволення. Ко-
манди були деморалізовані. Це була повна катастрофа.
Менеджерам довелося швидко повернутися до оцінюван-
ня саме тими командами, які виконуватимуть роботу. І що
ви думаєте? Оцінки знову почали збігатися з реальністю.
Із цього я виніс, що лише ті люди, які виконують роботу,

знають, скільки часу та зусиль вона потребує. Команда
експертів може чудово розбиратися в одних речах, але не
розумітися на інших. Можна мати одного фахівця з кон
кретної сфери діяльності, але при цьому інші сфери зали-
шатимуться в тіні. Як я вже казав раніше, всі команди
індивідуальні та унікальні. Кожна з них має власний темп
та ритм. Це не тісто для печива — однаковими формочка-
ми його не наріжеш.
НЕ ПРОСТО ЗАВДАННЯ, А СЮЖЕТИ

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

ритки, — результати можуть виявитись неочікуваними.
Скільки разів на роботі вам давали завдання, сенсу виконання

якого ви не розуміли? Хтось просить вас визначити, наскільки
змінилися продажі за останній місяць у регіоні A в крамницях
площею понад 55 квадратних метрів. Ви робите це, але не зна-
єте, навіщо воно потрібне. А тому можете подати неправильні
дані, помилково інтерпретувати питання або просто образи-
тись через купу зайвої роботи. Або, якщо ви менеджер, вас
може здивувати, що ваші люди не одразу розуміють, що ви
збираєтесь позакривати дрібні крамниці та відкрити великі.
Проблема полягає в тому, що ви не отримуєте або не даєте

достатньо інформації для дійсно правильного виконання ро-
боти. Люди мислять зв’язними розповідями, історіями, сюже-
тами. Саме так ми розуміємо навколишній світ. Ми близько
сприймаємо характери, бажання та мотиви. Коли ж намагає-
мось відділити від головної сюжетної лінії окремі частини та
працювати з ними поза контекстом, починаються складнощі.
Тому перш за все, розмірковуючи над якимсь завданням,

треба думати про основну дійову особу (хто у вас головний
герой — наприклад: клієнт, наречена, читач, акціонер).
Хто ця людина, для якої виконується завдання? Чий по-
гляд на світ ми маємо враховувати, створюючи цю річ,
приймаючи це рішення чи виконуючи цей шматок роботи?
Далі треба думати про те, що ми хочемо виконати передусім.

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

цю річ? Як вона служитиме та радуватиме цього конкретного
клієнта? І в певному розумінні це ключовий момент. Моти-
вація надає всьому навколо кольору.
Мій улюблений приклад походить з інтернетівського мему

кількарічної давнини. Він являє собою зображення Жана-
Люка Пікара, капітана американського зорельота Enterprise
із фільму «Зоряний шлях», з підписом: «Як капітан зоре-
льота, я б хотів, щоб бортовий журнал автоматично вико-
ристовував сьогоднішню зоряну дату…» Якщо подумати, це
має сенс. Вас не дивує, чому в далекому майбутньому капітан
зорельота мусить вручну вводити дату, роблячи запис у жур-
налі? «Капітанський журнал. Зоряна дата 4671.7. Планета
Марс така гарна з орбіти…» Ми сьогодні не мусимо цього
робити, коли пишемо блог. То чому мусить він?
Ключове питання без відповіді тут — навіщо. Навіщо йому

така функція? Якій меті вона слугуватиме? Чи лише для
дотримування часової послідовності записів? Чи для чогось
серйознішого? Чи повинні ці журнали не містити виправ-
лень задля зручності слідчих зоряного флоту? Дві дуже
різні причини: одна бажана, друга необхідна. Команді по-
трібно визначити, чого він дійсно хоче. При цьому вони
можуть придумати зовсім інший спосіб дати йому це, до-
давши важливішу інформацію, про яку капітан навіть не
думав, але яка буде дійсно корисною.
Часто потреби різних дійових осіб різні. Уявіть собі, напри-

клад, користувацьку історію (побажання), середина та кі-
нець якої звучать так: «…мені потрібен автомобіль, щоб
їздити на роботу». Тепер, якщо почати це речення «Як меш-
канцеві передмістя…» або «Як фермерові з Південної Дако-
ти, де погані дороги…», ви маєте зовсім різні інтерпретації
ідеального засобу пересування.
Отже, перед тим як розставляти пріоритети завдань для

вашого бізнесу, треба визначити дійову особу, користувача,
клієнта — людину, яка використовуватиме те, що ви збира-
єтесь створити. Треба знати, що вона любить, не любить, її
мрії, розчарування та радості. А потім зрозуміти її мотива-
цію. Як вона аргументує своє бажання? Для чого їй авто?

Що саме вона робитиме з капітанським журналом?
Це також вплине на вашу оцінку завдань. Потрібна проста

функція календаря? Це легко. От незмінний часовий штамп
для потреб правоохоронців — це вже буде складніше.
СТВОРЮЙТЕ КОРОТКІ СЮЖЕТИ

Проте, пишучи ваші сюжети, треба слідкувати, щоб вони були
достатньо короткими для їх реальної оцінки. Уявіть побажан-
ня стосовно сайту Amazon.com: «Як клієнт, я хочу мати най-
більшу у світі онлайнову книгарню, де б можна було купити
будь-яку книгу в будь-який час». Сьогодні такий опис, без
умовно, відповідає Амазону, але він надто великий для робо-
ти з ним. Його потрібно розбити на частини. Менші частини.
Зокрема, для онлайнової книгарні можна написати такі

побажання:
«Як клієнт, я хочу мати змогу проглядати книжки за жанром,

щоб легше знаходити мій улюблений різновид».
«Як клієнт, я хочу додавати книжку в кошик, щоб її можна

було купити».
«Як менеджер книгарні, я хочу мати змогу відстежувати по-

купки клієнтів, щоб пропонувати їм конкретні книжки на
основі куплених раніше».
На такі побажання й має орієнтуватися команда. Обговорення

цілком може обертатися навколо їх виконання. Вони достатньо
конкретні, щоб бути реалістичними, але не нав’язують, як їх
слід виконувати. Пам’ятайте: команда вирішує, як буде викону-
ватись робота, але що буде виконуватись, вирішується діловою
цінністю. Повне зібрання побажань щодо ідеї (у цьому випад-

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

цілком, який містить у собі ряд коротших сюжетів, що скла-
даються в єдину ідею.
Тім Столл є одним із тих хлопців, чия кар’єра, як то кажуть,

охоплює «широкий спектр подій», з основним спрямуван-
ням на прискорення роботи команд. Він служив медиком
у спецназі, пройшов Ірак та Афганістан; у ЦРУ та поліції
мав справу із жорстокими злочинцями; а зараз працює
Scrum-тренером. За його словами, він завжди був Scrum-
тренером, навіть коли керував спецопераціями.
«У спецназі, — каже він, — ми не називаємо їх побажання-

ми чи сюжетами. Ми називаємо їх курсами дій. Але, по суті,
це одне й те саме».
Ось одна з кількох історій, які Тім може розповісти публічно,

про операцію спецназу — медичну місію до Лаосу. «Ми мали
два епіки. Першим був курс медичної підготовки — навчан-
ня місцевих збройних сил тактичної медицини. Другий сто-
сувався розмінування боєприпасів, що не розірвалися».
Як медик, Тім відповідав за перший епік. Він каже, що перш

за все сів та визначив, щó потрібно зробити і як скомпонува-
ти окремі складники загального завдання. За його словами,
він почав з ідей, що дуже легко вкладаються в систему Scrum.
«Як медик сил спеціального призначення, я повинен навчи-

ти моїх учнів основ анатомії, щоб вони краще розуміли бу-
дову людського організму».
Починаючи розписувати свої побажання, Тім розумів, що поча-

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

їм про довгі кістки, потім про короткі, тоді про зап’ястки,
гомілки, сухожилки та зв’я́зки». Лише після закладення основ
можна буде перейти до складання цих кісток, вправляння
суглобів, очищення дихальних шляхів та зупинки кровотечі.
Закінчивши, він побачив, що потрібно для підтримки його

навчальних цілей. Потрібен був скелет та роздавальні мате-
ріали англійською й лаоською мовами. А потім він розбив
усе на цикли, тобто спринти. «Два дні польоту до Лаосу.
Тиждень на підготовку. Два шеститижневі цикли навчання.
Ми мали підвищити рівень медичних знань наших учнів
з базового до середнього. І ми зробили це».
БУДЬТЕ ГОТОВІ, І ВСЕ БУДЕ ВИКОНАНО

Розписуючи побажання, тобто складаючи перелік робіт, які
треба виконати, важливо ставити перед собою два питання:
«Чи готове завдання? І як ви знатимете, коли воно буде ви-
конано?»
Візьмімо за приклад історію Тіма:
Як медик сил спеціального призначення, я повинен навчити

моїх учнів основ анатомії, щоб вони краще розуміли будову
людського організму.
Є одна схема, яку я завжди використовую для визначення

готовності елементів беклогу. Створив її Білл Вейк, глибокий
мислитель у сфері розробки програмного забезпечення.
Білл стверджує, що для готовності будь-яке завдання має
відповідати таким критеріям:
Незалежність. Завдання має бути реальним і виконуваним

саме по собі. Воно має не залежати від іншого завдання.
Обговорюваність. Поки воно дійсно не виконане, його має

бути можливо переписати. Має бути вбудований дозвіл змін.
Цінність. Завдання має бути дійсно цінним для клієнта, ко-

ристувача чи зацікавленої особи.
Оцінюваність. У вас повинна бути можливість оцінити його

розмір.
Стислість. Завдання має бути достатньо коротким, щоб його

можна було легко оцінити та спланувати. Якщо воно завели-
ке, перепишіть його чи розбийте на менші.
Контрольованість. Завдання повинне мати тест, який буде

показником його готовності. Він складається перед розпи-
суванням завдання.
Отже, завдання Тіма є незалежним: він може виконати його

без необхідності враховувати, скажімо, пальне гвинтокри-
ла, потрібне для доправлення учнів до місця навчання.
Його завдання обговорюване: навчання анатомії — це те,
що він вважає за потрібне, але якщо він прибуде туди й ви-
явить, що учні вже мають ці знання чи частину цих знань,
то може змінити свій підхід. Воно цінне: учні отримають
практичні та прикладні знання про людський організм.
Завдання стисле: він навчатиме основ анатомії, а не хірур-
гічних операцій. І воно контрольоване: він знає інформа-
цію, яку хоче донести, і може перевірити, чи дійсно його
учні засвоїли цю інформацію.
Для кожного завдання, за яке ми беремося, має бути «визна-

чення підготованості» (тобто: чи відповідає воно вищенаве-
деним критеріям?), а також «визначення готовності» (тобто:
яких умов має бути дотримано, які тести пройдено, щоб
назвати його виконаним?). На прикладі реальних проектів
ми бачимо, що, якщо завдання дійсно готове, команда по-
двоїть швидкість його виконання. А якщо воно дійсно вико-

нане наприкінці спринту, команда може подвоїти швидкість
знову. Це є одним із трюків, потрібних для виконання вдві-
чі більшої роботи за половину часу.
ПЛАНУВАННЯ СПРИНТУ
У Scrum цей вид планування проводиться абсолютно для
кожного спринту під час спеціальної зустрічі. Усі збирають-
ся разом, розглядають перелік завдань, які потрібно вико-
нати, і кажуть: «Гаразд, чого ми можемо досягти в цьому
спринті? Чи готові ці завдання? Чи можливо виконати їх до
кінця цього циклу? Чи зможемо ми потім продемонструва-
ти їх клієнтові, показавши реальну цінність?» Ключем до
відповіді на ці питання є лише те, наскільки швидко коман-
да просувається вперед.
ЗНАЙТЕ ВАШУ ШВИДКІСТЬ

Ми можемо нарешті почати відповідати на питання про те,
коли буде виконано проект, бо тепер знаємо, як вимірювати
справжню роботу команди. Ми маємо всі ці побажання
(користувацькі сюжети) — речі, які потрібно зробити. І ми
оцінили їх — це тягне на вісім, те на три і т. д. Після цього
починаємо наш перший спринт. Скажімо, тривалістю в тиж-
день. Наприкінці цього тижня ми підраховуємо всі завдання,
які виконали, підсумовуємо бали їхніх оцінок, і ці цифри
повідомляють нам, наскільки швидко команда просувається
вперед, її швидкість. Знаючи ж швидкість, можна подиви-
тися, скільки побажань ще залишилось і на скільки балів
вони. І тоді ви знатимете, коли все буде виконано.
Крім того, знаючи свою швидкість, ви можете визначити най-

важливішу річ у Scrum: що заважає вам просуватися швидше?
Що не дає вам прискоритись? У попередньому розділі я говорив

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

Після оцінки всієї роботи я зібрав вище керівництво, відпові-
дальне за проект. Там були кілька віце-президентів, які очо-
лювали цілі служби компанії, навіть старший віце-президент.
Ми сиділи в конференц-залі, і цей старший віце-президент

хотів почути відповідь лише на одне питання.
— Чи впораєтесь ви до обіцяної президентом дати? — спитав

він, ляснувши долонею по столу.
— Не знаю, — чесно відповів я. — Але ми впораємось раніше

за змінену дату, яку запропонували ваші люди, або ви змо-
жете забрати свої гроші назад.
— Цього недостатньо! Чи дотримаєтесь ви вихідних строків?
— Сьогодні я не можу вам цього сказати. Потрібно, щоб

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

Я працював у Toyota.
— Це вже здається непоганим проектом. — відповів я також

зі сміхом.
Стало ясно, що він знайомий з ідеями марнування Таїчі

Оно і розуміє, як вони працюють: ключ до прискорення
команд — позбутися марнування.
Отже, після трьох спринтів вимірювання швидкості команди

прискорились із 20 до 60 балів за спринт, і я вже знав, коли
вони завершать проект. Ураховуючи їхню швидкість та про-
грес на початок березня, потрібно було ще дев’ятнадцять
двотижневих спринтів, а отже, строк виконання — 1 грудня.
Керівництво компанії не зраділо. Це їх аж ніяк не влашто-

вувало. Даєш 1 липня або ніколи. Усе було націлене ви-
ключно на це.
Тоді я вручив їм перелік дванадцяти перешкод для цього.

Перешкоди були різними: від ненадання людям права самим
приймати рішення до обтяжливих технічних вимог, від неявки
працівників на зустрічі до простих речей, на кшталт незабез-
печення роботи членів команди в одному приміщенні. Там
були проблеми з робочим процесом, персональними якостя-
ми та процедурою — речі, шкідливі для будь-якої корпорації.
Ці види перешкод можуть здаватися нездоланними. Як ча-

сто ви дивились навколо на своїй власній роботі та думали:
«Ми робимо це неправильно, ми завжди робили це непра-
вильно, і всі знають, що це тупо». Але з якихось причин люди
вважають зміну корпоративної культури неможливою. Ко-
лись я й сам із цим погоджувався, особливо коли йшлося про
великі компанії із застиглою культурою та політикою.
Medco довела, що я помилявся, і більше я вже ніколи не по-

вернуся до старого способу мислення. Той старший віце-
президент, який раніше працював у Toyota, у понеділок
розіслав наш перелік усім працівникам. Біля кожної пере-
шкоди стояло ім’я менеджера, відповідального за її усу-
нення. І до четверга всі перешкоди зникли. Можливо, для
мотивації до змін людям іноді потрібен пістолет біля голо-

ви, але це показало, що можна зробити, якщо на те є воля
(або якщо за старшого у вас хлопець із Toyota). Немає ні-
чого незмінного. По суті, змінити можна все.
До кінця наступного спринту швидкість команд зросла на

50 відсотків. Новою датою завершення проекту було на
звано 1 вересня. Але це все одно було на три місяці пізніше
за термін, навіть попри те, що вони прискорились із 20 до
90 балів за спринт, більш ніж на 400 відсотків!
Цього все одно було недостатньо.
Ми з Брентом знову зібрали всіх разом — від інженерів

і маркетологів до бізнес-аналітиків, контролерів та мене-
джерів. І вони були налякані. Вони боялися втратити свою
роботу та кар’єру, якщо не зможуть це витягти. Тому я по-
ставив їм три питання:
1. Чи можемо ми щось змінити для більшого прискорення?
— Ну, — сказав головний інженер, — десь у середині остан-

нього спринту хлопці з інформаційної безпеки відключили
вихід в Інтернет, тому наші команди в Індії та Бразилії
не змогли нічого зробити.
— То це ж треба виправити, так? — я аж вухам своїм не по-

вірив. Головний інженер подивився на голову служби ін-
формаційних технологій, який сидів за столом трохи далі.
На їхню думку, це мало скоротити час виконання проекту
на місяць. Залишалося ще два.
2. Чи можемо ми виключити якісь пункти з беклогу? До-

ручити частину іншим командам?
Нічого путнього ніхто не запропонував.

3. Можна не робити якісь речі? Зменшити якимось чином

обсяг проекту?
— Неможливо, — відповіли вони. І без того всі вимоги були

скорочені до мінімуму.
— Гаразд, — сказав я, — але давайте просто присвятимо дру-

гу половину дня їх перегляду. Кожне завдання має поборо-
тися за своє життя.
Це зайняло кілька годин, але ми зекономили ще місяць.
Ось тоді я й сказав: «Гаразд, ми все ще запізнюємось на мі-

сяць. Якщо не зможемо вигадати щось іще, доведеться сказа-
ти керівництву, що ми не впорались».
«Ні, — закричали всі, — нас усіх звільнять. Давайте подивимось

на ці три питання знову». Я запропонував зустрітися з керівниц-
твом компанії. Адже це була не лише наша проблема. Це була
і їхня проблема також, і вони цілком могли нам допомогти.
Зустріч вийшла короткою. Керівництво поглянуло на ситу-

ацію і сказало: «Ну, ми маємо здати все 1 липня. Можливо,
для початку просто скоротити проект до одного заводу?
Одного центру? Або кількох? Це спрацює?» Над чимось
довелося подумати, а щось переінакшити, але врешті-решт
вони вирішили, що можуть зменшити потрібні характери-
стики та вкластися до липня 2007 року — дати, яку їхній
президент пообіцяв Волл-стрит.
У кінці тієї зустрічі старший віце-президент просто сказав:

«Можна говорити про перемогу. Якщо виникнуть якісь про-
блеми, телефонуйте».
Того літа ціни на акції Medco приємно дивували. З початком

розбудови інфраструктури вони поповзли вгору, а коли ми
закінчили, вони продовжили зростати. Наскільки? На бага-

то мільярдів доларів, із 25 до понад 50 доларів за акцію про-
тягом одного року. На Волл-стрит вирішили, що компанія
продовжуватиме зростати, приваблюватиме нових клієнтів
і зберігатиме лідерство у своїй галузі. Якби ж я знав, то по-
просив би собі відсоток від зростання ринкової вартості ком-
панії, а не простий гонорар.
Через кілька років Medco застосувала Scrum для створення

того, що вони назвали Medco 2.0. Вони реструктуризували
всі частини компанії, згори донизу. Нові заводи, нові рóботи,
нові виробничі процеси, більше автоматизації. Марк Ленді,
який тоді вже був головним технічним директором компанії,
каже, що без досвіду лікувально-оздоровчих центрів вони б
не змогли це зробити. «Нам просто не дозволили б зробити
це в промислових масштабах. Але ми отримали підтримку
всієї організації: відділу розробки, операцій, фінансів, клі-
нічних випробувань. Ми змогли створити нову культуру».
А це, він каже, є найважливішою частиною Scrum: зміна куль-
тури праці людей, яка може деяких лякати. Правда, за його
словами, компанії довелось позбутися співробітників, які
не змогли переключитись на новий лад. Не через їхню не-
компетентність, а через приховування інформації та знань
для власної користі, забезпечення власної незамінності, а не
допомоги команді та компанії. Проте саме зміна такої куль-
тури дозволяє досягти справжньої досконалості.
Гладенько буває лише на папері. Не закохуйтесь у свій

план. Він майже напевно неправильний.
Плануйте лише те, що вам потрібно зробити. Не

намагайтесь проектувати все на роки вперед. Просто пла-
нуйте достатньо для підтримки зайнятості вашої команди.
Що це за собака? Не оцінюйте проект в абсолютних ве-

личинах типу годин — доведено, що люди цього не вмі-
ють. Оцінюйте відносний розмір завдань: собаками, фут-
болками (S, M, L, XL, XXL) чи, ще краще, за допомогою
послідовності Фібоначчі.
Питайте оракула. Використовуйте сліпу техніку, на кшталт

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

швидкої оцінки роботи, яку потрібно виконати, спеціаль-
ний планувальний покер.
Робота — це сюжет. Спочатку думайте про те, кому це

принесе цінність, потім про те, що це таке, а потім — на-
віщо це їм потрібне. Люди мислять сюжетами та поба-
жаннями, тому давайте їм їх. Як X, я хочу Y, щоб Z.
Знайте вашу швидкість. Кожна команда має точно зна-

ти, скільки роботи вона може виконати в кожному сприн-
ті. Крім того, її члени мають знати, наскільки вони мо-
жуть покращити цю швидкість, працюючи розумніше та
усуваючи бар’єри, які їх затримують.
Швидкість × Час = Виконання проекту. Визначивши

швидкість свого просування, ви знатимете, як скоро до-
сягнете мети.
Ставте сміливі цілі. За допомогою Scrum не так уже

й важко подвоїти виробництво чи вдвічі скоротити час
завершення проекту. Якщо робити все правильно, ваші
прибутки та вартість акцій також подвояться.
РОЗДІЛ 7. ЩАСТЯ
176 Щастя
Люди хочуть бути щасливими. Не в сенсі сонного самовдо-

волення, як вівці, а в значно більш активний спосіб. Томас
Джефферсон, серед багато чого іншого, вихваляв той вид
щастя, який приносить гонитва за чимось. Саме вона, схоже,
й робить нас щасливими. Правильне застосування Scrum зро-
бить щасливими робітників, клієнтів, менеджерів та акціоне-
рів (зазвичай у такому порядку).
Звісно, справжнє щастя дається нелегко. Якось я зустрів аль-

пініста, який продав мені світлину верхівки Гімалаїв на захо-
ді сонця. Він зробив її невдовзі після того, як сам-один досяг
піку гори Еверест уже під вечір. Повернутись до базового
табору до темряви здавалося неможливим. Якби він цього
не зробив, то, напевне, замерз би до смерті. Та світлина до-
зволяла пройнятись його відчуттями, коли він писав у про-
щальній записці, що щасливий досягти піку, навіть попри той
факт, що прочитати її можуть над його мертвим тілом.
Якщо заговорити з альпіністами про якусь експедицію, вони

не будуть довго розповідати про свої враження від вершини.
Натомість вам розкажуть про люті морози, болючі мозолі, по-
гану їжу, жахливі умови та незручне спорядження. А ще ви по-
чуєте, що після тріумфу від досягнення вершини зазвичай на-
стає спустошення (якщо тільки смертельна небезпека не заступає
його). Вони зробили це. Їхня боротьба принесла успіх. Але якщо
ви спитаєте їх, коли вони були найщасливішими, то почуєте, що
це було в моменти випробувань — максимального напруження
м’язів, розуму та духу. Саме тоді вони були найщасливішими
й відчували справжню втіху. І саме це вони хочуть пережити
знову. Здавалося б, жодна людина при здоровому глузді не схо-
че добровільно проходити такі жахіття двічі. Але альпіністи,
схоже, не здатні зупинитися, кидаючи виклик піку за піком,
шукаючи задоволення в гонитві за наступною вершиною.
Цікаво, що в більшості культур такий специфічний тип ща-

стя не винагороджується і не заохочується. Професор Тал
Щастя 177
Бен-Шахар викладав найпопулярніший курс у Гарвардсько-

му університеті «Позитивна психологія». У своїй книжці
«Бути щасливішим» він пише: «Нас винагороджують не за
насолоду від самої подорожі, а за успішне її завершення.
Суспільство винагороджує результати, а не процеси, досяг-
нення, а не шлях до них».
Проте наше повсякденне життя складається переважно зі

шляху. Ми не досягаємо вершин, не здійснюємо подвигів
і не виграємо кубків кожен день. Більшість наших днів на-
повнені прагненням до наших цілей, якими б вони не були.
У компанії метою може бути випуск наступного чудового
продукту, покращення завдяки йому людського життя чи
розв’язання якоїсь проблеми, що турбує світ. Але якщо ми
отримуватимемо винагороду лише за результати, а не про-
цеси, нічого доброго для нас із цього не вийде.
Коли на початку 1980-х я тільки пішов з військової академії

у світ бізнесу, мене поставили керувати десятком програміс-
тів, що виглядали доволі нещасними. Їхні проекти завжди
запізнювались і вибивалися з бюджету — і це коли взагалі
щось працювало. Із часом їхній настрій став таким негатив-
ним, що атмосфера в робочому приміщенні діяла на всіх
гнітюче. При цьому виробничий процес, який вони вико-
ристовували, був настільки поганим, що досягти успіху було
просто неможливо. Відтоді я якраз і займаюсь розв’язанням
такого роду проблем, витративши на це тридцять років.
Важливість щастя по-справжньому вразила мене, коли я ство-

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

І першим кроком до успіху є відчуття радості від роботи.
Усе це може здаватися трохи дивним, немов я пропоную вам

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

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

на, що зробило щасливішими мене та моїх рідних. Але як
бізнесмен та вчений я люблю більш конкретні дані.
ЩАСТЯ — ЦЕ УСПІХ
Результати досліджень говорять про це напрочуд чітко. Ща-
сливі люди просто діють краще — вдома, на роботі, у житті.
Вони заробляють більше грошей, отримують кращу роботу,
закінчують коледж і просто живуть довше. Дивовижно, але
факт: майже в усіх сферах вони досягають більшого.
Щасливі співробітники більше продають, приносять біль-

ше прибутків і менше витрат, рідше змінюють місце ро-
Щастя 179
боти, здоровіші й довше працюють. Або, як ідеться у стат-

ті 2005 року, де проведено мета-аналіз 225 досліджень із
понад 275 000 учасників:
Щастя веде до успіху ледь не в кожній сфері нашого життя,

зокрема в шлюбі, здоров’ї, товариських стосунках, громадській
діяльності, творчості, а особливо в роботі, кар’єрі та бізнесі1.
Мета-аналітики показали, що люди, які почуваються щасли-

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

людей немає нічого дивного — вони ж щасливі через свій успіх,
чи не так? Виявляється, не так. У тому самому мета-аналізі чи-
таємо: «Дослідження за дослідженням показують, що щастя
передує важливим результатам та показникам процвітання».
Ось як насправді. Люди не тому щасливі, що успішні, а тому

успішні, що щасливі. Щастя — прогностичний показник. При-
чому продуктивність покращується, якщо люди стають хоча б
трохи щасливішими. Не потрібно різко змінювати чиєсь жит-
тя, щоб зробити їх щасливішими, принаймні тимчасово. Навіть
маленький шматочок щастя веде до помітно кращих результа-
тів. Не треба, щоб люди впадали в стан глибокого щастя, наче
в день весілля. Достатньо, щоб вони просто стали трохи щасли-
вішими, ніж були до того. Звичайно, чим щасливішими вони
стануть, тим більший ефект це матиме. Але я хочу, щоб ви
винесли із цього простий месидж: навіть невеликі жести
можуть мати великий вплив. А Scrum якраз і зосереджується
на тому, щоб систематично закладати ці дрібнички в підмурок
успіху. Лише по одній за раз, і ви дійсно зможете змінити світ.
Я збираюся дати вам набір інструментів для вимірювання

щастя вас самих і вашої команди, компанії та родини, а також
180 Щастя
будь-якої організації, з якою вам трапиться мати справу. Це

Scrum. Забудьте вправи на побудову довіри, а натомість просто
будуйте її кожного дня. І я хочу, щоб ви це вимірювали. Недо-
статньо думати, що люди щасливі. Треба, щоб ви стали в цьому
експертом: обчислюйте щастя та порівнюйте його з продуктив-
ністю. Якщо щось не сходиться, це вказує на проблему. Чудово
ходити з вашою командою на пиво. Але це не принесе компанії
багато користі, якщо не втілиться в дійсно кращу продуктив-
ність. Є багато людей, з якими я проводжу час задля розваги,
але щодо моєї команди я хочу, щоб цей соціальний аспект вів
безпосередньо до продуктивності. І так воно й виходить.
РОЗРАХУНОК ЩАСТЯ
Як же зробити щасливими самих себе, наших працівників
та колег по команді? Як перетворити це щастя на більшу
продуктивність і прибутки?
Щоб відповісти на ці питання, потрібно повернутися до

Toyota та хрестового походу Таїчі Оно проти марнування.
Мета позбутися цієї проблеми привела його до ідеї «безпе-
рервного покращення». Недостатньо досягти певного рівня
продуктивності та залишатися там — ідея полягає в постій-
ній перевірці ваших робочих процесів на предмет їх вічного
покращення. Досконалість, звичайно, не має меж, але кожен
здобуток у цьому напрямку має значення.
Як і роботу та час слід розбивати на керовані частини, по-

кращення треба нарізати на окремі кроки. У японській мові
для цього є спеціальне слово кайдзен — «безперервне покра-
щення». Що невеличке можна зробити просто зараз, щоб
покращити вашу роботу?
У Scrum це розглядається наприкінці кожного спринту під час

того, що я називаю «ретроспективою». Спочатку члени коман-
Щастя 181
ди показують, чого вони досягли протягом останнього сприн-

ту (що в них «Виконано» та може потенційно бути представ-
лене клієнтам для відгуку). А потім вони сідають і думають,
що пройшло добре, що могло пройти краще та що можна
покращити в наступному спринті. Яке покращення робочого
процесу вони як команда здатні запровадити просто зараз?
Щоб бути ефективною, ця зустріч потребує певної емоційної

зрілості та атмосфери довіри. Головне — пам’ятати, що ви не
шукаєте когось винного, а розглядаєте можливі недоліки про-
цесу. Чому це сталося саме так? Чому ми це пропустили? Що
може зробити нас швидшими? Дуже важливо, щоб люди брали
на себе відповідальність за свою роботу і її результати як ко-
манда та шукали рішення як команда. Водночас люди повин-
ні мати мужність порушувати питання, які дійсно їх турбують,
орієнтуючись на пошук рішення, а не звинувачення. А решта
команди повинна мати зрілість слухати відгуки, сприймати
їх та шукати розв’язання, а не займати оборонну позицію.
У циклі Демінга (плануйте, робіть, перевіряйте, дійте) ре-

троспективна зустріч — це частина перевіряйте. Головне —
дістатися кроку дійте (кайдзен), який дійсно змінить робочий
процес та зробить його кращим наступного разу. Недостатньо
лише ділитися відчуттями, потрібно мати змогу діяти.
Найкращий виявлений мною спосіб досягти всього цього базу-

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

команди відповідає лише на декілька запитань:
1. Як ви почуваєтесь щодо своєї ролі в компанії за шкалою

від 1 до 5?
182 Щастя
2. Як ви почуваєтесь щодо компанії в цілому за тією самою

шкалою?
3. Чому ви так вважаєте?
4. Яка одна річ могла б зробити вас щасливішими в наступ-
ному спринті?
І все. Це можна зробити лише за кілька хвилин. Кожен член

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

кращення та робить його найважливішою річчю, яку слід зро-
бити в наступному спринті, — зі вступними випробуваннями.
Як ви доведете, що покращення досягнуто? Потрібно визначити,
що таке успіх, чітко та доступно, щоб у наступній ретроспективі
спринту було дійсно легко побачити, чи досягли ви кайдзену.
Кілька років тому я вирішив розширити свою компанію Scrum,

Inc. до консультаційної агенції з повним набором Scrum-по-
слуг. Ми відстежили нашу швидкість і виявили, що кожного
однотижневого спринту виконуємо завдань приблизно на со-
рок балів. Після запровадження показника щастя одразу ви
явилось, що наші сюжети не досить добрі. Вони не були достат-
ньо підготованими, не мали визначення готовності та були
надто розпливчастими. Я попрацював над цим, і ми почали
писати кращі сюжети. Але протягом наступного спринту вони
все ще були недостатньо добрими. Це відображали наші оцін-
ки щастя. У третьому спринті виникла нова проблема. Ми взя-
лися за неї. Так і пішло. Усього за кілька тижнів наша швид-
кість збільшилася із сорока балів за спринт до ста двадцяти.
Ми потроїли продуктивність, просто питаючи, що може зро-
бити людей щасливішими. Як результат, наші клієнти також
стали щасливішими, а наші прибутки різко підскочили. Усе,
Щастя 183
що треба було для цього зробити, — почати питати в команди:

«Що може зробити вас щасливішими?», а потім давати їм це.
Ми зобразили ці дані на графіку, наклавши їх на час, і побачи-

ли кілька надзвичайно цікавих моментів. Як генеральний ди-
ректор, я зосереджений на тому, що може статись у майбутньо-
му з нашими прибутками, зростанням та продуктивністю. І от
що я виявив: на відміну від фінансових показників, показник
щастя є прогностичним. Фінансові дані показують, що було
в минулому, але, коли ви питаєте людей про їхнє щастя, вони
дійсно проектують майбутнє. А коли вони думають про своє
щастя в компанії, то починають проектувати свої думки про
діяльність компанії. Як результат, ви отримуєте сигнал про
проблему до її виникнення. І, якщо приділяти достатньо уваги
тому, що каже вам ваша команда, можна вживати заходів та
виправляти ситуацію до того, як вона перетвориться на пробле-
му. На графіку нижче, наприклад, падіння рівня щастя передує
падінню швидкості чи продуктивності на кілька тижнів. Якщо
дивитися лише на продуктивність, ви не побачите негараздів,
5 30
4 25
20
3
15
2
10
1
5
0
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
Швидкість Щастя
184 Щастя
доки вони не зваляться вам на голову, неначе гірський обвал.

Але, побачивши по всій команді падіння щастя, навіть за умо-
ви зростання продуктивності, знайте, що у вас проблема, якою
слід зайнятися, причому якнайскоріше.
РОБІТЬ УСЕ ВИДИМИМ

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

автономії, майстерності та мети, є прозорість. Ідея полягає
в тому, що має не бути жодних таємних інтриг, прихованих
мотивів, нічого за лаштунками. Надто часто в компанії буває
насправді неясно, хто над чим працює чи як щоденна діяль-
ність кожного працівника наближає спільні цілі.
Запускаючи Scrum, я багато думав про закони, які один мій

добрий друг намагався включити в законодавство штату
Колорадо, — так звані закони «сонячного світла». Вони ви-
магали, щоб усі публічні зустрічі бути відкритими, усі запи-
си — доступними для громадськості, а також щоб нічого
не відбувалося за зачиненими дверима — нічого не прихо-
вувалось. Ось чому в Scrum будь-хто може прийти на будь-
яку зустріч. Будь-яка зацікавлена особа може спостерігати
за щоденним стендапом чи відвідати огляд спринту.
Я прагнув зробити все відкритим. А це може лякати деяких

людей. Розповім про PatientKeeper — компанію, яка розроб
Щастя 185
ляє портативну апаратуру для лікарень та лікарів. Коли

вони найняли мене, я одразу ж застосував до їхнього ви-
робничого процесу систему Scrum. Я сказав розробникам,
що тепер всі мають знати все, що відбувається в компанії.
Вони ж настільки звикли до різних обмежень, що злякали-
ся нового рівня прозорості як чергового підступного плану
керівництва.
«Довіртесь мені, — переконував я. — Це не використовува-

тиметься вам на шкоду. Чи з метою покарання. Це піде
лише всім на користь».
Як я вже казав, командна продуктивність цікавить мене

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

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

наймаєте, щоб разом виконувати спільну роботу, то найма-
єте неправильних людей і створюєте систему, в якій із само-
го початку закладено провал.
Найкращою візуальною репрезентацією цієї ідеї, тим, що ви

побачите в кожній кімнаті Scrum-команди по всій планеті,
є Scrum-дошка.
ПРОЕКТ/ КОМАНДА:ЧУДОВА SCRUM-КОМАНДА

Беклог Виконати Виконується На огляді Виконано!
Сюжет 1
Сюжет 2
Сюжет 3
Сюжет 4
Сьогодні існує програмне забезпечення, здатне виміряти

що завгодно, надати вам будь-які показники та аналізи, але
Scrum-дошка являє собою просто купу стікерів на лекцій-
ній дошці. Вона має три рівні статусу завдань: «Виконати»,
«Виконується» та «Виконано». Коли хтось підписується на
якесь завдання, всі знають, хто над ним працює. І всі зна-
Щастя 187
ють, коли його виконано. А завдяки тому, що дошка має

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

а що поки ні, вони можуть регулювати свою роботу. Вони
знають, що мають робити, і розуміють, що в колеги про-
блема, якщо завдання не переходить у колонку «Викона-
но» надто довго. Як тільки з’являється прозорість, коман-
да може самоорганізуватися для подолання проблем, що
стають очевидними.
У компанії PatientKeeper прозорість, яка спочатку так на-

лякала працівників, цілком себе виправдала. Оскільки вся
робота була прозорою, ми мали змогу координувати завдан-
ня між багатьма командами. Усі завжди точно знали, над
чим працюють інші. Вони могли підтримати одне одного,
якщо хтось натикався на перешкоду. Один розробник міг
скористатися розв’язанням проблеми, яке запропонував
інший, навіть якщо вони були з різних команд! Продуктив-
ність у компанії зросла більш ніж учетверо. Ми випускали
сорок п’ять нових версій серійного програмного продукту
підприємства на рік. І не якогось там Angry Birds, а про-
грам, установлених у великих лікарнях, від яких залежать
людські життя. Завдяки прозорості всіх процесів ми змогли
вивести свій продукт на ринок швидше за всіх у світі. Ось
на що здатне «сонячне світло».
Коли ж я пішов із PatientKeeper, нове керівництво вирішило,

що Scrum більше не найкращий спосіб управління проекта-
ми. Результат? Випуск продукції скоротився із сорока п’яти
разів на рік до двох, прибутки впали з п’ятдесяти мільйонів
доларів до двадцяти п’яти, а плинність кадрів, яка була мен-
шою за десять відсотків, підскочила до понад тридцяти.
188 Щастя
Повернувшись до традиційної корпоративної поведінки,

видатна компанія знову стала посередньою.
ДОСТАВЛЯЮЧИ ЩАСТЯ
Однією з компаній, що розглядають щастя як основу своєї
корпоративної культури, є Zappos. Цей просто дико успіш-
ний веб-сайт переконав людей робити те, що багато хто вва-
жає неможливим: купувати взуття через Інтернет. Генераль-
ний директор компанії Тоні Шей написав про це книжку
«Доставляючи щастя». Тоні пише про унікальну культуру
Zappos, засновану на тому, щоб приносити позитивні емоції
клієнтам. Виявляється, зробити клієнтів щасливими можуть
щасливі люди на іншому кінці телефонного дроту.
У розмовах із керівництвом Zappos часто можна почути

слово зв’язок. Проведене ними дослідження показує, що
чим більше люди пов’язані з іншими в процесі роботи, тим
вони щасливіші — а також, зрозуміло, більш продуктивні
й інноваційні. Тому керівництво вирішило спеціально ство-
рити ці зв’язки — не лише в межах однієї команди чи від-
ділу, а й по всій компанії. І не лише між людьми одного
рівня, але й між різними рівнями — від віце-президентів
до простих бухгалтерів.
Вони роблять це за допомогою засобів водночас простих

і складних. Наприклад, фізично заохочують випадкові зу-
стрічі. У будівлі компанії багато виходів, але всі вони зачи-
нені, крім одного, що змушує людей входити і виходити
крізь одні й ті самі двері. Ідея полягає в тому, що, коли люди
буквально натикаються одне на одного день у день, вони
скоріше налагоджують та розвивають зв’язки між собою.
Інший приклад стосується способу занурення людей у куль-

туру Zappos. Кожен працівник, від вантажника до дирек-
Щастя 189
тора, має пройти те, що Кріста Фолі, старший менеджер

відділу кадрів, називає «курс молодого бійця». Протягом
чотирьох тижнів кожен працівник проходить тренінг щодо
роботи компанії, а також її корпоративної культури. По
суті, це є другим відсівом у межах прийняття на роботу до
Zappos. Навіть після отримання пропозиції роботи ви ма-
єте довести, що здатні ввібрати в себе цю культуру.
Результати, за словами Фолі, дивовижні. «Ці зв’язки [спів-

робітників], налагоджені за час проходження курсу, за
лишаються з ними протягом усієї їхньої кар’єри». Тренінг
спеціально доволі напружений: люди мають з’являтись
о 7 : 00 ранку, тяжко працювати, дотримуватись дедлайнів
та складати тести. Але це працює. Ті, хто його проходить,
підтримують стосунки не просто місяцями, а роками, орга-
нізовуючи зустрічі старих друзів та спільні пікніки, щоб не
втрачати зв’язку одне з одним.
«Це перетворюється на велику родину, — каже керівник

Zappos Рейчел Браун. — Ви запрошуєте колег додому. Про-
водите з ними дозвілля».
Є ще один спосіб, яким Zappos підтримує щастя своїх людей.

Компанія дає співробітникам можливість для навчання та
професійного зростання. Там майже завжди віддають пере-
вагу найму, так би мовити, зсередини. Скажімо, відкрива-
ється вакансія у відділі кадрів, яку бачить хтось із бухгалте-
рії, кому завжди подобалась такого роду робота. Цю людину,
яка цікавиться кадровими питаннями, запросять на практи-
ку, яка там називається «учнівство». Це дасть працівникові
можливість побачити, чи дійсно йому подобається така ро-
бота, а менеджеру — чи добре той вписується в команду.
Компанія також пропонує безкоштовні заняття, які прово-
дять інші співробітники: з основ фінансів, кодування для
початківців тощо. У Zappos турбуються про те, щоб люди
зростали над собою та в межах компанії.
190 Щастя
Як я вже згадував у розділі 3, описуючи команди, люди хочуть

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

кар’єри, така корпоративна культура може стати просто-таки
ковтком свіжого повітря. «Усю мою кар’єру до Zappos я пере-
важно була зосереджена на доборі персоналу», — каже Фолі.
За її словами, це була одноманітна робота, на якій вона просто
професійно вигоряла. Перехід до Zappos надав їй нових сил.
Сьогодні про культуру цієї компанії вона каже так: «Завдяки
їй я почала отримувати задоволення від своєї роботи».
Саме цього й прагне Zappos. Саме цього має прагнути будь-

яка компанія. Саме цього хочу і я. Люди мають із радістю йти
на роботу. Це змінює їхній світогляд. Від роботи на компа-
нію — до роботи з моєю компанією. Деяким людям важко
прийняти такий світогляд. Тому Zappos і зосереджується на
внутрішніх підвищеннях. Там виявили, що людям, які при-
ходять у компанію ззовні, особливо на вищі керівні посади,
доволі нелегко пристосуватися до їхніх порядків. «Ми поєд-
нуємо в собі підприємницьке й інноваційне», — каже Фолі.
Але це лише половина справи. Другою половиною є співпра-
ця. Компанія прагне, щоб її співробітники працювали разом,
підтримуючи дружні стосунки по всій організації. Іноді це
відходить від стандартів корпоративної культури. Один на-
чальник відділу сказав мені: «Я ніде не заявляю свою посаду.
Ми вважаємо, що як група здатні працювати значно краще».
Дуже часто в компаніях можна побачити менеджерів, які

хочуть керувати своїм напрямом без прозорості та співпра-
ці. Вони створюють динаміку типу «ми проти них». Прово-
дяться лінії розмежування, і на ваших очах різні підрозділи
Щастя 191
починають плести один проти одного інтриги просто-таки

в середньовічному макіавеллівському дусі. Тільки уявіть,
наскільки продуктивнішою могла б стати ваша компанія,
якби всі в ній працювали разом заради спільної мети. По-
думайте про місце, яке всі вважають моєю компанією, де
кожного дня є шанс стати кращим, щось удосконалити,
навчитися нового. Натомість більшість корпорацій чомусь
створюють середовище, де люди більше зайняті внутріш-
німи іграми, ніж отриманням користі.
У Zappos, якщо ви не вписуєтесь у команду та культуру, то

не підходите для компанії. Їхня річна плинність кадрів
складає 12 відсотків, причому найбільше вона спостеріга-
ється в довідковій службі. Це тому, що вони звільняють лю-
дей, які не горять пристрастю задовольняти потреби клієн-
тів. Zappos розглядає цю службу як обличчя компанії, де слід
дотримуватись високих стандартів роботи. Керівництво го-
тове виявити гнучкість у багатьох моментах, але не в цьому.
Мені доводилося бачити таку саму динаміку в багатьох ко-

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

приходять нові співробітники, тим більш однотипне їхнє
мислення, а отже, тим складніше їм відмовитись від звич-
них способів роботи. Scrum дає людям систему, яка доз-
воляє це зробити. Він забезпечує структуру всієї організації,
192 Щастя
спрямовану на досягнення спільної мети. Його стовпами

є прозорість, командна робота та співпраця. Багато компа-
ній сьогодні вітають цю філософію, а ті, хто цього не ро-
бить, неминуче програють.
Сайт Zappos пройшов шлях від 1,6 мільйона доларів продажів

у 2000 році до понад мільярда у 2008-му. Це відповідає рівню
зростання в 124 відсотки щороку протягом восьми років по-
спіль. Не знаю, як ви, але я вважаю це доволі переконливим
аргументом за забезпечення щастя людей. І Scrum є якраз
тим інструментом, яким ви можете для цього скористатися.
ЛОПАЙТЕ ЩАСЛИВУ БУЛЬБАШКУ

При всьому цьому щастя (принаймні те, про яке говорю я) —
не самовдоволеність. Радше воно має зовсім протилежний
сенс: позитивне та пристрасне захоплення. Як каже Кріста
Фолі з Zappos, щастя надзвичайно далеке від пасивності.
«Я з радістю йду на роботу. Замість [заохочення вас стати]
самовдоволеними, наша позитивна та надихальна культу-
ра підштовхує вас працювати наполегливіше». Вони просто
відсіюють тих, хто вважає, що працювати в щасливій ком-
панії означає не працювати. Їм потрібні люди, яких радість
від роботи вестиме вперед.
І вони в цьому не самотні. Журнал Harvard Business Review

присвятив щастю весь свій номер за січень—лютий 2012 року.
Там виявили, що:
…єдиний шлях до щастя працівника, яке також іде на ко-

ристь зацікавлених осіб, пролягає крізь відчуття задоволен-
ня від добре виконаної важливої роботи. Ми маємо прагну-
ти не лише зробити співробітників «щасливими», але й так,
щоб це щастя походило від досягнення видатних результатів.
Коротше кажучи, ми маємо заслужити пристрасну прихиль-
Щастя 193
ність наших співробітників до місії та успіху компанії, допо-

магаючи їм заслужити пристрасну прихильність клієнтів2.
І ця пристрасна прихильність дає відчутні переваги. Щасливі

співробітники не прогулюють, працюють інтенсивніше і не
лише не йдуть із компанії, а й приваблюють інших, таких, як
вони, які поділяють той самий настрій. У статті для Harvard
Business Review Ґретхен Шпрайтцер та Крістін Порат вирі-
шили не називати цих людей «щасливими» через асоціацію
із самовдоволеністю. Натомість вони назвали їх «квітучими».
Вони виявили, що ці люди працюють на 16 відсотків краще
за своїх колег, на 125 відсотків менше вигоряють, на 32 відсо-
тки більш віддані компанії та на 46 відсотків більш задоволе-
ні своєю роботою. Вони беруть менше лікарняних, менше
ходять до лікарів і частіше отримують підвищення3.
Спільним для цих «квітучих» є якраз те, про що я пишу

протягом усього цього розділу: кожен із них сповнений
життя та пристрасті, і кожен прагне вдосконалити свою
майстерність, чи то член екіпажу літака, чи то помічник
офіціанта в ресторані. Що можуть зробити компанії для
створення атмосфери, в якій люди квітуватимуть? Мене-
джери можуть заохочувати автономію, дозволяючи людям
приймати власні рішення про свою роботу. А ще вони мо-
жуть слідкувати, щоб співробітники були в курсі всіх справ,
бо, як вони кажуть: «Працювати в інформаційному вакуумі
нудно та нецікаво». Менеджери також повинні мати нульо-
ву толерантність до нечемності та ніколи не дозволяти пра-
цівникам отруювати корпоративну культуру образами чи
неповагою. Нарешті, вони мають давати швидкі й безпосе-
редні відгуки про роботу та поведінку підлеглих.
Scrum дає людям усі ці речі. Він налаштований на їхню ре-

алізацію, особливо за допомогою безпосередніх відгуків, які
приходять щодня під час стендапів і висвітлюються ретро-
спективами спринту та показником щастя.
194 Щастя
Проте є одна небезпека, про яку я хотів би сказати. Вона

цілком реальна, навіть трапляється досить часто, щоб я ви-
тратив чимало часу на її вивчення. Мова йде про утворення
так званої «щасливої бульбашки». Зазвичай це відбувається
після досягнення командою якогось великого успіху чи різ-
кого підвищення її продуктивності за рахунок використання
Scrum. Члени команди діяли самоорганізовано і тепер від-
чувають гордість за свій прогрес. І в цей час може виникну-
ти самовдоволеність. Вони кажуть собі: «Ось, ми досягли
такого покращення, що більше не маємо до чого прагнути».
Вони, так би мовити, виходять на плато продуктивності і до-
волі скоро після цього припиняють показувати чудові ре-
зультати. При цьому вони достатньо майстерні, щоб деякий
час жити в цій уявній щасливій бульбашці, що відділяє їх від
неприємної правди. Вони не усвідомлюють, що безперервне
покращення означає саме безперервність: ніколи не зупи-
нятися. Коли я був пілотом-винищувачем, ми часто казали,
що після трьох тисяч годин нальоту треба звільнятися, бо
людина стає самовдоволеною, а це може вбити. Хоча са-
мовдоволена команда в бізнесі, можливо, ризикує мен-
ше, її поточна продуктивність явно перебуває в небезпеці.
Самовдоволеність часто виявляється в подібних коментарях:

«Ми заслуговуємо на відпочинок; ми його заробили». І тут
або окремі члени команди цінують свій командний дух та
щастя настільки високо, що не хочуть ними ризикувати, або
вони бояться змінюватись самі, вважаючи, що не потрібно
змінювати те, що працює і так.
Оскільки саме тут принципи Scrum можуть дати збій, такі

«щасливі бульбашки» є однією з найбільших моїх пересто-
рог. Я бачив це не раз і не двічі: команда може використо-
вувати все, чого вчить Scrum (розставлення пріоритетів,
однозадачність, багатофункціональність, огляди роботи),
але її покращення припиняється. Дуже часто вони стають
значно кращими, ніж були до вивчення Scrum, мають успі-
Щастя 195
хи, які це доводять, але спочивають на лаврах. Вони кажуть:

«Нам не треба якогось іще покращення».
Це нагадує мені олімпійську збірну США з баскетболу

2004 року. У тій команді були чудові гравці — згадати лише
Леброна Джеймса, Тіма Данкана та Аллена Айверсона. При-
чому команда Сполучених Штатів мала історію не просто
перемог, а домінування в спорті, особливо після того, як
брати участь в Олімпіаді дозволили професійним гравцям.
Ці американські баскетболісти знали, що вони найкращі.
Ось тільки найкращими вони не були. Вони програли біль-
ше матчів, ніж будь-яка олімпійська збірна США з баскет-
болу за всю історію. Вони програли Литві. Їхня гордість та
самовдоволеність довели їх до падіння. Виявилось, що вони
жили у щасливій бульбашці.
Отже, як лопнути таку бульбашку, перш ніж ваші гравці

зганьблять свою країну в прямому телеефірі на очах у мільяр-
дів людей? Першим кроком є усвідомити проблему, чому
я й хочу, щоб команди вимірювали свою швидкість кожного
спринту. Я хочу знати їхній рівень змін. Якщо там немає по-
зитивного зростання, я розумію, що ми котимось донизу.
І у виправленні цього покладаюсь на Scrum-майстра. Він має
бути здатним побачити проблему та винести її на розгляд
команди. Дуже важливо, щоб хтось ставив складні запитання.
По суті, вам потрібен шекспірівський «мудрий дурень».
Що за порода в тебе та твоїх дочок: їм хочеться, щоб мене

відшмагали за те, що я говорю правду, а ти хочеш, щоб мене
відшмагали за те, що я брешу. А то ще, бува, шмагають мене
за те, що я держу язик за зубами4…
Король Лір, акт 1, сцена 4*
* Шекспір В. Твори в 6 т. / Пер. М. Рильського. — Т. 5. — К. : Дніпро, 1986.

(Прим. перекл.)
196 Щастя
Це людина, яка ставить незручні запитання чи підіймає

незручні істини. З такими працівниками не завжди легко
мати справу, бо їх можуть вважати джерелами проблем або
не частиною команди, але їх просто необхідно культивувати
та використовувати.
Мабуть, найкращим прикладом є всім нам знайомий кла-

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

ворити про голизну короля, адже це означало б їхню невід-
повідність займаним посадам. Тому королівська процесія
рухалась далі й далі вулицею, аж доки якась дитина не за-
кричала: «Але ж він голий!» Спочатку батько дитини цить-
нув на неї, але потім, почавши із шепоту й закінчивши в пов-
Щастя 197
ний голос, усі мешканці міста стали кричати: «Та він же

зовсім голий!» Хоча король і боявся, що народ каже правду,
він вирішив витримати всю процесію. А придворні йшли за
ним і вдавали, що несуть шлейф, якого не було й близько.
«Мудрий дурень», як та дитина, — це особа, здатна поба-

чити, що загальноприйнята істина є просто загальною ілю-
зією, а насправді король без штанів. Тому, якщо у вас є такі
«дурні», плекайте їх.
Існують також інші способи лопнути щасливу бульбаш-

ку — наприклад, вливання свіжої крові та втручання ке-
рівництва компанії. Проте за своєю суттю це те саме — під-
ведення команди до лиця реальності, якої вони, можливо,
не хочуть бачити. На щастя, у Scrum усе прозоре: скільки
команда виробляє, якість її роботи, наскільки щасливий
клієнт. Однією з переваг Scrum є те, що він робить незруч-
не видимим, причому швидко. Натомість традиційні ко-
манди та організації можуть безтурботно зробити крок
у прірву, а потім дивуватися, що могло піти не так. Вони
надто довго не отримують ефективного відгуку від ринку
та один від одного.
ЩАСЛИВІ СЬОГОДНІ, ЩАСЛИВІ ЗАВТРА

Психологи, включно з професором Бен-Шахаром із Гар-
варду, стверджують, що одним зі способів аналізу ставлен-
ня людей до навколишнього світу є запитати, чи прино-
сить їм їхня робота щастя сьогодні та чи приноситиме
завтра. Я виявив, що це корисна точка зору на внутрішній
клімат компанії.
За словами Бен-Шахара, люди зазвичай поділяються на

чотири типи. Перший тип — «гедоністи», які роблять те,
що приносить їм щастя просто зараз. Завтра? «Про завтра
198 Щастя
подбаю завтра. Я хочу насолоджуватися сьогодні». Я бачу

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

чинають турбуватися. Тому вони наймають купу менедже-
рів, щоб пасти це стадо хакерів. І раптом хакери помічають,
що безтурботний світ, який їм так подобався, накрився
мідним тазом. З’явились різноманітні правила, тести та
звіти. Це вже не весело сьогодні і, схоже, не буде весело
ніколи. Тепер їх можна назвати «нігілістами».
Далі йдуть ті, яких зазвичай кидають на керівництво склад-

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

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

всі працюють разом, команда допомагає гедоністові диви-
Щастя 199
тись у завтрашній день, переконує нігіліста в існуванні май-

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

Він дозволяє команді допомагати її членам ставати кра-
щими. Він систематично, обережно та поступово усуває
причини нещастя. Він дає людям наснагу змінюватись
і стимул для цього.
Пам’ятаєте фундаментальну помилку атрибуції? Коли вас

оточують гівнюки, шукайте не поганих людей, а погані сис-
теми, що винагороджують їх за таку поведінку. А потім
використовуйте показник щастя, щоб їх виправити.
У старших класах чи коледжі багато хто з нас вивчав «ієрар-

хію потреб» американського психолога Абрагама Маслоу.
У ній у формі піраміди викладено потреби, про які люди
дбають передусім, а потім ті, чия нагальність збільшується
в міру задоволення нижчих. В основі піраміди лежать фі-
зіологічні потреби: повітря, вода, їжа, одяг та прихисток.
Якщо ми не маємо цього, то навіть почати не можемо дума-
ти про все інше. Наступним шаром є безпека — не просто
фізична та фінансова, але й гарантія доброго здоров’я. Дуже
важливо мати певний доступ до медичного забезпечення.
Цікаво, що багато людей на цьому й зупиняються, навіть
попри те, що наступний шар містить безумовно потрібні
речі, які суспільство часто ігнорує: любов та належність —
зв’язок, про який так багато говорять у Zappos. Вище розта-
шована потреба в самооцінці та повазі від інших. А на самі-
сінькій вершині піраміди — потреба в повному розкритті
потенціалу людини.
Маслоу найбільше цікавив оцей верхній шар, на якому також

зосереджений і Scrum: допомога людям досягти особистісного
зростання та самореалізації. Піднімаючись по цій піраміді,
200 Щастя
люди стають не просто щасливішими та більш реалізованими,

але й ефективнішими та більш інноваційними. Вони отри-
мують змогу досягти надзвичайності.
Я зараз майже бачу, як ви киваєте головами, бо ми всі від-

чуваємо цю піраміду спинним мозком, навіть якщо хтось
із нас ніколи глибоко не розбирався в її значенні. Штука
в тому, щоб піднятися до цих захмарних висот і зуміти
точно простежити це. Якщо ви керуєте підприємством, то,
мабуть, вимірюєте свої досягнення прибутками та зростан-
ням. Якщо намагаєтесь допомогти хворим, то, мабуть, ви-
мірюєте їх кількістю тих, що залишилися жити. Якщо на-
магаєтесь змінити світ, то, мабуть, вимірюєте їх величиною
впроваджених змін. Якщо ж просто прагнете виконати пе-
релік справ вашої дружини, досягнення, мабуть, вимірю-
ються кількістю вихідних, вільних для риболовлі.
Недостатньо просто бути щасливими. Щастя має приноси-

ти результати. Усі складники Scrum об’єднуються якраз
навколо допомоги людині в цьому. У чому головна хи-
трість? У розставленні пріоритетів. Детальніше про це ми
поговоримо в наступному розділі.
Це шлях, а не пункт призначення. Справжнє щастя —

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

ймати розумніші рішення. Крім того, коли люди щасливі,
то більш творчі, рідше звільняються з роботи та частіше
досягають просто неймовірних результатів.
Щастя 201
Обчислюйте щастя. Недостатньо просто почуватися до-

бре. Потрібно вимірювати це відчуття та порівнювати
його з реальною продуктивністю. Інші показники див-
ляться в минуле. Щастя ж демонструє майбутнє.
Ставайте кращим кожного дня — і вимірюйте це.

Наприкінці кожного спринту члени команди мають оби-
рати одне маленьке покращення, або кайдзен, яке зро-
бить їх щасливішими. І це має бути найважливішою
річчю, якої вони досягнуть у наступному спринті.
Таємність — отрута. Не має бути нічого таємного. Усі

мають знати все, включно з інформацією про зарплати
та фінансові справи компанії. Прихованість потрібна
лише людям, які керуються власними, а не командними
інтересами.
Робіть усе видимим. Заведіть дошку, що показуватиме

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

чуть контролювати власну долю, ставати кращими у сво-
їй роботі та служити меті, вищій за них самих.
Лопайте щасливі бульбашки. Не ставайте настільки

щасливими, щоб почати вірити у власне марення. Не
забувайте порівнювати щастя з продуктивністю і в разі
виявлення невідповідності будьте готові діяти. Само
вдоволеність — ворог успіху.
РОЗДІЛ 8. ПРІОРИТЕТИ
204 Пріоритети
Зі Скоттом Максвеллом я вперше зустрівся в «Закусочній

Джонні» у Ньютоні, штат Массачусетс, кілька років тому.
Я вже розповідав про нього раніше. Він — засновник ком-
панії OpenView Venture Partners і та сама людина, яка ви-
рахувала, що понаднормова робота породжує більше кло-
потів, ніж досягнень. Я пропрацював з OpenView та їхніми
клієнтами майже вісім років, і всі вони демонстрували
надзвичайне зростання продуктивності. Але Scrum при-
значений не лише для прискорення роботи команд. Він
має величезний вплив, який у випадку з венчурними ка-
піталістами набуває простої форми — прибутку. Якщо ком-
панія не приносить грошей, це не успішне комерційне під-
приємство, а якесь хобі.
Навіть не скажу, скільки я бачив компаній із чудовими іде-

ями та дійсно класним продуктом, яким усі захоплювались.
Здавалося, що він неодмінно займе ринкову нішу, що про-
сто приречений на успіх. Адже він такий класний. Але
попри мегадози уяви, натхнення та важкої праці, люди,
які його виробляли, так і не змогли визначити, як саме
заробляти на ньому гроші.
У чому різниця між компаніями Pets.com і Zappos? Вони

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

центруватися лише на тому, що ви здатні створити, це може
Пріоритети 205
ВЛАСНИК ПРОДУКТУ ПОВИНЕН ЗБАЛАНСУВАТИ
ЩО ВИ МОЖЕТЕ ЩО ВИ МОЖЕТЕ
ЗРОБИТИ ПРОДАТИ
БАЧЕННЯ
ПРОДУКТУ
ДО ЧОГО ВИ
МАЄТЕ
ПРИСТРАСТЬ!
закінчитись виготовленням насправді нікому не потрібних

речей, навіть якщо ви маєте до них пристрасть. Якщо роби-
ти ставку лише на те, що ви можете продати, можна наобі-
цяти речі, які не вийде створити. Якщо ж створювати лише
те, що ви можете продати, але до чого не маєте пристрасті,
це закінчиться важкою роботою заради посередності. Але
в центрі, перехресті, лежить бачення, що проростає з реаль-
ності, — бачення з реальною можливістю стати чимось ви-
датним. У цьому розділі я збираюсь показати вам, як до цьо-
го прийти. Попередні розділи зосереджувались на тому, як
робити все швидше та краще. Цей розділ розповість, як зму-
сити «швидше та краще» працювати на вас — як досягти
надзвичайності.
Скотт Максвелл каже, що справжня сила Scrum полягає

в його готовому, пріоритетному й вимірюваному беклозі —
переліку завдань, які треба виконати. Ось чому Скотт запро-
вадив Scrum у венчурній групі та вважає його вирішальною
конкурентною перевагою.
БЕКЛОГ: ЩО Й КОЛИ РОБИТИ

Перше, що потрібно зробити, застосовуючи Scrum, — склас-
ти беклог. Він може бути завдовжки в сотні пунктів або
містити лише кілька речей, з якими слід розібратися перед
усім. Безумовним є лише одне: ви маєте чітко уявляти, що
хочете отримати наприкінці роботи. Це може бути якийсь
продукт, весілля, послуга, нова вакцина, пофарбовані стіни
будинку тощо. Це може бути будь-що, але одразу після
створення в голові картинки бажаного результату слід про-
думати, чого потребуватиме його досягнення.
Нещодавно я працював із компанією, яка виробляє авто-

матизовані системи для будинків: опалення, охолодження,
електрики, сантехніки, усього потроху. Одним із їхніх нових
продуктів є система побутової автоматики. Вони створюють
систему, здатну контролювати всі аспекти вашого побуту:
від відчинення вхідних дверей та вмикання світла в кімна-
тах до контролю витрат на опалення — і все з вашого мо-
більного пристрою. Отже, спочатку вони сідають і складають
перелік усього, що для цього потрібне: перемикачів, кон
тролерів, інтерфейсів, датчиків, протоколів зв’язку тощо.
По суті, не конкретних правил та шматків роботи, а всіх
сюжетів та побажань замовника.
Тому вони записують такі речі: «Як домовласник я хочу мати

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

тів, адже йшлося про велику, складну систему автоматики.
Беклог базується на ідеї, що в нього має входити все, що
тільки можна включити в продукт. Звичайно, всього вбуду-

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

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

валося багато разів. Я вже говорив про нього раніше: 80 від-
сотків цінності закладені в 20 відсотках характеристик. За-
думайтесь над цим на хвилину. В усьому, що ви купуєте,
основна цінність — те, чого люди хочуть найбільше, — скла-
дає лише п’яту частину створеного. У випадку цієї компанії
співробітники дивилися на свій величезний перелік речей,
які можна включити в їхню систему побутової автоматики,
і розуміли (знали), що насправді клієнти хочуть лише 20 від-
сотків із цього. Scrum дозволяє визначити, як створити ці
20 відсотків передусім. У традиційній розробці продуктів ко-
манди не знають, у чому полягають ці 20 відсотків, доки не за-
вершать увесь проект. Це означає, що цілих 80 відсотків їхніх
зусиль марнуються. А ви знаєте, як я ставлюсь до марнування.
А якби ви могли завершувати проекти в п’ять разів швидше

за ваших конкурентів, з уп’ятеро більшою цінністю? Це
шлях до перемоги.
Тому працівники цієї компанії з автоматизації засіли за свій

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

визначити як бачення, так і цінність. У Scrum ми називаємо
таку особу власником продукту.
ВЛАСНИК ПРОДУКТУ
У Scrum є лише три ролі. Ви є або членом команди та вико-
нуєте роботу, або Scrum-майстром та допомагаєте команді
визначити кращі методи роботи, або власником продукту.
Усі ці ролі детально описано в додатку цієї книжки. Власник
продукту вирішує, якою має бути робота. Він чи вона розпо-
ряджається беклогом — переліком завдань і, найважливіше,
пріоритетністю їх виконання.
Створюючи першу Scrum-команду в 1993 році, я не мав влас-

ника продукту. Я був членом керівної команди та мав купу
інших обов’язків, окрім визначення, що саме повинна робити

команда в кожному спринті. Я займався керівництвом та мар-
кетингом, вирішував питання з клієнтами та накреслював
загальну стратегію. Але в тому першому спринті я виявив, що
цілком можу керувати беклогом. Потрібно було просто слід-
кувати за тим, щоб мати досить сюжетів, побажань та харак-
теристик для роботи команди протягом наступного спринту.
Проблема полягала в тому, що після другого спринту ми
запровадили щоденні стендапи — обговорення стоячи. Уже
в наступному спринті швидкість роботи підвищилась на
400 відсотків, і команда за тиждень закінчила те, що мало б
зайняти в нас місяць. У них закінчилися завдання з беклогу,
над якими треба було працювати! Я ж собі думав, що маю
місяць для планування нових завдань. Доволі велика пробле-
ма, погодьтеся, але її треба було якось розв’язувати. Тому
я й подумав про цю роль власника продукту та про якості,
потрібні для належного її виконання.
Розробляючи її, я надихався роллю головного інженера ком-

панії Toyota. Людина на цій посаді відповідає за всю вироб-
ничу лінію окремої моделі, наприклад, Corolla чи Camry.
Для цього вона має задіяти таланти груп працівників, які
спеціалізуються на створенні корпуса, коліс, електропровод-
ки тощо. Головний інженер має об’єднати групи окремих
фахівців, щоб створити єдину багатофункціональну коман-
ду, здатну зібрати авто. За межами Toyota цих легендар-
них головних інженерів (або шуса, як їх називають у Япо-
нії) вважають всесильними лідерами так званого «шляху
Toyota». У певному розумінні це правда. Але влади при цьо-
му вони не мають. Ніхто їм не підзвітний — радше вони самі
підзвітні своїм групам. Люди можуть вказувати головним
інженерам на їхні помилки, тому вони мають стежити за
правильністю своїх рішень. Вони не дають нікому оцінок
продуктивності, підвищень чи заохочень. Вони лише при-
ймають рішення щодо бачення авто і способів його виготов-
лення — шляхом переконання, а не примусу.
Саме цю ідею я й хотів утілити в системі Scrum. Джон Шук

з Інституту ощадливого підприємництва якось почав свій
опис ролі головного інженера цитатою з інструкції для ко-
мандного складу морської піхоти США:
Відповідальність людини за лідерство не залежить від вла-

ди… глибоко вкорінене припущення, що влада має дорів-
нювати відповідальності, є коренем великого організацій-
ного негаразду. Я вважаю, що непорозуміння навколо цього
питання загрозливе й проблемне, воно проникло в нашу
свідомість так глибоко, що ми цього навіть не усвідомлюємо1.
Згадуючи свій досвід, набутий у Вест-Пойнті та В’єтнамі,

я цілком погоджуюсь, що лідерство не має нічого спільно-
го із владою. Радше воно — серед іншого — стосується знань
та готовності служити людям. Головний інженер Toyota не
може просто наказувати виконати щось конкретним спо-
собом. Він має переконувати, лестити й демонструвати, що
його спосіб є правильним, найкращим. Зазвичай, щоб грати
цю роль, потрібні десятиліття досвіду. Я хотів запровадити
її у Scrum, але я також добре знав, що дуже небагато людей
мають такий рівень досвіду та навичок. Тому я розбив цю
роль на дві, віддавши питання як робити Scrum-майстрові,
а що робити — власникові продукту.
Навіть у перші дні Scrum я знав, що мені потрібний хтось

для тісного зв’язку з клієнтом. Після кожного спринту влас-
ник продукту має передавати команді відгуки споживачів.
Він повинен проводити половину свого часу за розмовами
з людьми, які купують продукт (дізнаючись їхні думки про
найсвіжіший реліз та його цінність для них), а другу поло-
вину — з командою, розробляючи беклог (показуючи їм, що
клієнт цінує, а вони ні).
Запам’ятайте: «клієнтом» може бути масовий споживач,

великий банк, ваш чоловік або хтось, хто потребує ротавіру-
сної вакцини та залежить від вас, щоб її дістати. Клієнтом

є той, хто отримає цінність від того, що ви робите.
Але менеджера я не хотів. Я хотів когось, кому команда б

вірила, довіряючи йому розставляти пріоритети завдань
беклогу. Тому я пішов і запросив до себе на роботу найро-
зумнішого хлопця у сфері товарного маркетингу — не роз-
робки, зверніть увагу, а маркетингу. І саме так Дон Роднер
став першим власником продукту. Він знав продукт, який
ми виробляли, не з технічної точки зору — хоча й розумів
у цьому достатньо, щоб спілкуватися з інженерами — а рад-
ше з точки зору клієнтів. Що потрібне людям, які дійсно
користуватимуться цим продуктом? Добираючи власника
продукту, беріть когось, хто може поставити себе на місце
людини, яка отримує цінність від вашої роботи. Як каже
один мій друг: «Моя дружина — ідеальний власник продук-
ту, бо точно знає, чого хоче. Я просто це впроваджую».
Власник продукту не лише потребує ширшого спектра вмінь

та навичок, ніж Scrum-майстер, але й має дотримуватись
іншого набору стандартів. Scrum-майстер та команда відпо-
відають за те, як швидко вони просуваються і наскільки
швидшими можуть стати. А власник продукту слідкує за
перетворенням продуктивності команди на цінність.
З роками я звів головні характеристики власника продукту

до чотирьох.
По-перше, власник продукту має розбиратися у своїй сфері

діяльності. Маю на увазі дві речі. Він повинен досить добре
розуміти, чим займається команда, щоб знати, що може бути
виконане і, не менш важливо, що не може. Але він також має
розуміти це що достатньо добре, щоб знати, як перетворити
його на справжню цінність, яка має сенс. Це може бути
комп’ютерна система, що допомагає ФБР ловити терористів,
чи методика навчання, яка покращує успішність учнів середніх
шкіл. Власник продукту повинен знати ринок достатньо до-

бре, щоб розуміти, щó саме може змінити ситуацію на краще.
По-друге, власник продукту повинен мати повноваження

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

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

цінність. У контексті бізнесу значення мають передусім при-
бутки. Я вимірюю роботу власника продукту тим, скільки
прибутку він приносить на один бал зусиль. Якщо команда
щотижня виконує роботи на сорок балів, я хочу знати, скіль-
ки прибутку дав кожен із них. Але мірилом цінності може бути
і те, скільки успіхів має команда. Я знаю одну поліцейську
команду, яка вимірювала цінність кількістю проведених за

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

ності забагато? Саме тому у великих проектах усіма потре-
бами зазвичай займається ціла команда власників продукту.
Детальніше я розповім про це пізніше. А спочатку хочу по-
казати наочний приклад обов’язків цієї людини. Уявіть себе
в кабіні реактивного винищувача F-86 Sabre, де за штурва-
лом сидить «божевільний майор» Джон Бойд, готовий до
повітряного бою над Корейським півостровом.
ОГЛЯДАЙТЕ, ОРІЄНТУЙТЕСЬ,
ВИРІШУЙТЕ, ДІЙТЕ
Під час Корейської війни повітряні бої точились переважно
між американськими літаками F-86 Sabre і МіГ-15 радян-
ського виробництва. МіГ був швидшим, маневренішим, ніс
більше озброєння та й узагалі переважав за всіма параме-
трами. Теоретично МіГи мали б очистити небо від амери-
канських пілотів. Натомість їх самих збивали в десять разів
більше. Намагання визначити, як це стало можливим,
сформувало тактику ведення майбутніх війн. Крім того,
воно мало величезний вплив на розвиток системи Scrum.
Джон Бойд був просто-таки найвидатнішим пілотом-вини-

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

після закінчення війни, викладаючи в льотній школі ВПС
США на базі Нелліс, що на півдні штату Невада. В армії, де
цінується часта зміна персоналу, він безпрецедентно про-
служив інструктором цілих шість років.
Льотчиків-винищувачів не назвеш особливо скромними

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

їми, скажімо так, енергійними висловлюваннями. Вони май-
же завжди викрикувались просто в обличчя опонентові, ким
би той не був, причому Бойд тицяв його в груди двома паль-
цями із затиснутою в них запаленою сигарою. Легенда роз-
повідає, що іноді він (випадково, звісно ж) навіть підпалював
противникові краватку. У таких випадках він не виявляв
жодного каяття, використовуючи для перемоги в суперечці
будь-яку зброю зі свого арсеналу.
Бойд умів бачити все поле бою. Ось як він сам про це розповідав:
Я бачу себе неначе у величезній кулі — всередині цієї кулі —

і можу фіксувати все, що відбувається навколо неї, [хоча]
весь час маневрую… Я можу бачити все з двох точок водно-

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

неба та подій сформувала його військові теорії, а пізніше
змінила весь спосіб ведення війн США.
Пішовши з льотної школи, Бойд вирішив вивчати інженер-

ну справу і в процесі цього створив модель льотно-технічних
характеристик повітряного судна, що описувала повітряний
бій з точки зору енергетичного співвідношення. Його теорія
повітряного бою «Енергія—Маневреність» (EM) ураховує
кінетичну та потенціальну енергію літака в будь-якій ситу-
ації (висоту, повітряну швидкість та напрямок), а також те,
наскільки швидко можна змінити будь-яку із цих величин.
Згодом ця теорія викристалізувалась у спосіб моделювання
більшості бойових літаків, безпосередньо привівши до розроб-
ки F-15 та F-16, найкращих винищувачів останніх сорока років.
На жаль, згідно з теорією Бойда, МіГ-15 мав би змести F-86

Sabre із неба. Щось тут було не так. Як розповідає у своєму
біографічному творі Роберт Корам, намагаючись у цьому
розібратися, Бойд часто цілими днями просиджував у тран-
сі. Він був переконаний, що його теорія правильна, але ж
чому тоді співвідношення збитих було 10 : 1 на користь аме-
риканських льотчиків? Краща підготовка? Це могло пояс-
нити ситуацію лише частково. Тактика? Можливо, але цей
фактор знову не міг привести до такого протилежного ре-
зультату. А потім його осяяло. Американські пілоти краще
бачили та швидше діяли. Причому завдяки не якимось сво-
їм внутрішнім якостям, а простим особливостям конструкції
літаків. Sabre мав краплиноподібний ліхтар кабіни, тоді як
у МіГа той складався з багатьох скляних панелей та переми-
чок, що перекривали пілотові огляд. Крім того, F-86 мав
повністю гідравлічні органи керування польотом, тоді як на

МіГу гідравліка відігравала лише допоміжну роль. Було ві-
домо, що пілотам МіГ-15 доводиться спеціально качати м’язи
верхньої частини тіла для кращого маневрування літаком.
Тому американські льотчики помічали МіГи першими, а після

цього, найголовніше, могли реагувати швидше за китайських
та північнокорейських пілотів. Результат битви вирішували
не технічні можливості машини, а швидкість перетворення
спостереження на дію. МіГ виконував якийсь маневр, Sabre
відповідав, а поки пілот МіГа намагався відповісти на це,
американський пілот устигав виконати вже новий маневр. Він
реагував на кожну нову дію МіГа настільки швидше, що більш
технологічно досконалий літак ставав легкою здобиччю.
Те саме спостерігалось і у В’єтнамі, коли я був там. На той

час бої велися між іншими літаками, МіГ-21 і F-4, але краща
видимість американців знову перемагала кращу маневре-
ність радянського літака. Як сказав би Бойд, його найвідо-
міша інновація помістила льотчиків «усередину циклу при-
йняття рішень ворога».
Ця ідея стала основою ведення війн. І саме для цього я при-

значав Scrum — дозволити власникові продукту приймати
рішення швидко, на основі відгуку клієнтів у реальному часі.
Отримуючи постійну реакцію від користувачів: людини, яка
клацає кнопку «Купити» на Amazon, парафіян вашої церкви,
дітей у класі чи дівчини в примірювальній — ви маєте змогу
постійно коригувати свою стратегію та швидше досягати успіху.
Ця ідея має дещо дивну назву «петля ООВД» (Оглядати —

Орієнтуватись — Вирішувати — Діяти). І хоча декому
вона може здаватись кумедною, на війні та в бізнесі вона
працює дуже навіть серйозно. Проникнення всередину чи-
йогось циклу прийняття рішень викликає в них втрату орі-
єнтації та сумніви. Їхні реакції стають або надмірними, або
недостатніми. На інструктажі для інших офіцерів Бойд казав

про це так: «Виживає той, хто здатний опанувати найшвидший
рівень змін»3. Трохи нижче ви знайдете діаграму петлі ООВД.
«Оглядати» — тут усе доволі очевидно: треба чітко бачити

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

момент, але й про наслідки, які ви здатні побачити, — меню
альтернатив, які ви для себе створюєте. За словами Бойда,
чинниками цього створення є генетична спадковість, культур-
ні традиції, попередній досвід і, звичайно, розвиток ситуації.
Таким чином, орієнтація відображує не лише те, як ви бачите
світ і ваше місце в ньому, але і який світ ви здатні побачити.
Оглянувши все та зОрієнтувавшись, ви Вирішуєте, а відтак

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

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

ся, не мають жодної цінності, поки не завершені, може бути
доволі складно. Наприклад, як проводити поетапні випуски
218
ЦИКЛ OOВД
Оглядати Орієнтуватися Вирішувати Діяти
Приховане Приховане
управління управління
Зовнішня та контроль Культурні та контроль
традиції
інформація
Випередження Генетична Аналіз / Випередження Випередження

Розвиток спадковість Синтез Взаємодія
ситуації Огляд Вирішення Дія із середо-
(гіпотеза) (тест) вищем
Нова Попе-
Вплив інфор- редній
середовища мація досвід
Відгук
Відгук
Пріоритети
автомобіля? Або відеогри вартістю в сто мільйонів доларів?

Головне тут — зосередитись на частинах, що дійсно мають
цінність — достатню для отримання справжнього відгуку
щодо них, реакції в реальному часі.
Візьмімо, наприклад, машини. Toyota розробила модель

Prius від концепції до завершення проекту за п’ятнадцять
місяців, швидше за будь-який інший їхній проект. Хоча чле-
ни команди, що розробила та зібрала Prius, не стали прода-
вати свою автівку, перш ніж та була завершена, вони почали
швидко виготовляти її прототипи, щоб головний інженер
міг «побуцати ногами шини» та подивитись, чи просува-
ється команда в правильному напрямку. Виготовлення
прототипів (повністю функціональних авто) до офіційного
випуску, а потім покращення їх знову й знову, доки ви
не отримаєте продукт, який хочете продавати споживачам,
може стати рушієм дивовижно швидких змін. Головне тут —
не мати чітко затвердженого дизайну із самого початку,
а радше виготовляти функціональний прототип і потім ди-
витися, що можна в ньому покращити. А після покращення
виготовляти наступний прототип та покращувати його. Ідея
полягає в тому, що чим швидше ви отримаєте справжній
відгук, тим швидше зможете зробити кращу автівку.
«Команда WIKISPEED», про яку я вже писав у розділі 4, вироб

ляє повні прототипи їхнього авто кожного тижня. І продає їх.
Ці прототипи не потрапляють на масовий ринок — WIKISPEED
поки не готова до цього, — але є любителі, готові викласти
за них 25 тисяч доларів. Думаючи про створення чогось,
не вважайте, що не зможете отримати щось цінне аж до са-
мого кінця. Натомість намагайтесь думати про мінімально
життєздатний продукт. Який абсолютний мінімум я можу
зробити, надавши при цьому клієнтові щось цінне?
Ще одним добрим прикладом є відеоігри. У наші дні дедалі

більше розробників надають любителям новинок можливість
оплатити так званий допрем’єрний «альфа»-доступ до своєї

продукції. У такий спосіб розробники отримують відгук від
їхніх найвідданіших фанатів, перш ніж гра запрацює офіцій-
но. Це дозволяє їм бачити, як люди реагують насправді, а не
здогадуватись, як ті реагуватимуть потім.
Залежно від сфери, у якій ви працюєте, чи організації, якою

керуєте, прийняти ідею поетапних випусків може бути
складно. У цьому випадку, якщо ви не можете запропону-
вати щось зовнішньому клієнтові, виходом буде визначити
внутрішнього клієнта — наприклад власника продукту, —
який зіграє роль цільової аудиторії. Показуйте вашому вну-
трішньому клієнтові все, що може принести корисний відгук:
напрямки розширення земельної ділянки, план оновлення
заводу, перероблену гальмівну систему, кампанію з набору
на військову службу добровольців тощо. Ідея полягає в тому,
щоб створити для себе можливість перевірки та адаптації.
Компанія чи організація, не здатна реагувати на зміну умов,
конкурентів чи смаків, сильно ризикує.
Бойд каже про це так:
Потрібно проникати всередину темпу чи ритму іншого хлоп-

ця, де ми його й повалимо… Треба мати в голові образ чи
картину, які ми називаємо орієнтацією. Потім ми маємо при-
ймати рішення щодо подальших дій, після чого реалізовува-
ти це рішення… Далі ми дивимось на цю дію [що вийшла
в результаті], плюс наше спостереження та занурюємось
у нові дані, нову орієнтацію, нове рішення, нову дію і так до
нескінченності… Орієнтація — це не просто стан, у якому
ви перебуваєте, це процес. Ви орієнтуєтесь завжди…
Чудовий тісний маленький світ, де немає змін… [Створіння, що

живуть у такому світі] — динозаври, вони вимруть. Найголов-
ніше тут — не стати динозавром. Якщо ви стоятимете на місці,
то помрете… Усе просто: виходу немає… Отакі пироги, хлопці4.
Отакі пироги, хлопці. Як я вже казав у розділі 1, вибір перед

вами доволі простий: змінюйтесь або помріть. Якщо не ввій-
дете всередину циклу прийняття рішень ваших конкурентів,
вони ввійдуть усередину вашого. Як казав Бойд: «Що я хочу
зробити, так це загнати свого супротивника назад, усереди-
ну його… Тоді я зможу довести його до втрати орієнтації,
розгубленості, а там і до паралічу дій». Не знаю, як ви,
а я краще робитиму так сам, ніж щоб так робили зі мною.
ПЕРШЕ РОБИТЬСЯ ПЕРШИМ

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

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

беклог і змінюючи пріоритети кожного спринту, прагнучи
порядку дій, що забезпечить цінність якнайшвидше. Ви,
мабуть, ніколи не досягнете абсолютно ідеального порядку,
але треба йти до нього крок за кроком, спринт за спринтом.
Головне — пам’ятати, що він постійно змінюється. Порядок,

який є правильним одного тижня, вже не буде таким наступно-
го. Ваше середовище зміниться. Ви засвоїте якісь нові речі.

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

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

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

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

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

стуватися продуктом, то ніколи не вмикали цього режиму,
але постійно хотіли постити фото в соціальних мережах.
Це дозволяє вам упроваджувати передусім характеристики,

які люди цінують, і випускати ваш продукт, коли виконано
лише приблизно 20 відсотків роботи. Ви знаєте, що продукт
не ідеальний, але він дуже близький до ідеалу. Кожна годи-
на, витрачена на непотрібне «вилизування» проекту, є втра-
ченою можливістю для цінності.
КРИВА ЦІННОСТІ — РАДИКАЛЬНО ШВИДШЕ

ВИВЕДЕННЯ ПРОДУКТУ В ЛЮДИ
100
90
80
Відсоток цінності
70 Найпізніше виведення продукту!

60 80 % цінності
20 % характеристик
50
40
30
МЖВ може бути тут
20
10
0
10 20 30 40 50 60 70 80 90 100
Відсоток характеристик
У цьому процесі чудовим є те, що він повторюваний (ітератив-

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

ривши лише половину характеристик вихідного продукту чи
проекту, ви зможете принести вдвічі більше цінності за вдві-

чі менший час. Ось у чому справжня сила Scrum. Саме так він
може фундаментально змінити спосіб не лише вашої роботи,
але й усього життя. Не зосереджуйтесь на виконанні всього
переліку завдань — всього й одразу — зосереджуйтесь на тому,
що має цінність, чого люди дійсно хочуть або потребують.
ПОЕТАПНА ЦІННІСТЬ — РАДИКАЛЬНО КРАЩЕ

ВИВЕДЕННЯ ПРОДУКТУ В ЛЮДИ
200
180
160
140 Виведення продукту
120
Цінність, %
100
80
Виведення продукту
60
40
20
10 20 30 40 50 60 70 80 90 100
Час, вартість, характеристики (%)
Це нагадує мені розповіді солдатів та офіцерів, які побували

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

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

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

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

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

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

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

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

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

у виробництво стрімголов, вони створили три різні повністю
функціональні лінзи й провели порівняльні випробування.
Оскільки насправді розробники лише намагалися розв’язати
питання з лінзою та мали зробити це передусім, бо виробництво
займало чимало часу, вони тестували кожну лінзу за допомогою
камери для ноутбука. Виявилося, що найкраще заданим кри-
теріям відповідало скло. При цьому, що дуже важливо, вони
мали змогу прийняти своє рішення, побачивши, як щось дійсно
працює. Їхній вибір базувався не на теоретичних уявленнях.
Вони мали щось, що можна було подивитись і помацати. Розв’я-
завши це питання, вони змогли перейти до дизайну корпуса
камери, у якому буде встановлена лінза, та процесорів, що об-
роблятимуть отримане зображення. Розставивши пріоритети
щодо лінзи, компанія потенційно зекономила собі мільйони
доларів. Відомо, що Apple робить так з усією своєю продукцією,
часто створюючи десяток повністю функціональних прототипів,
а потім обираючи з них найкращий. Це дає змогу швидкої пре-
зентації різних ідей публіці без надмірних інвестицій.
Фінансовий ризик є тим, що спричиняє крах більшості ком-

паній. Вони створюють щось класне, але не можуть продати
це за достатню суму, щоб дійсно отримати прибуток. Класич-

ним прикладом цього є онлайнова журналістика та поступо-
ва загибель друкованих видань. З початком Інтернет-буму
в дев’яності роки минулого століття газети з радістю розмі-
щували свій контент у мережі. Деякі головні редактори ви-
явили, що навіть онлайн прибутки від реклами залишати-
муться, тому зробили цей контент безкоштовним для читачів.
Проблема, звичайно, полягала в тому, що рекламісти були
готові платити за онлайнову рекламу значно менше грошей,
ніж за друковану. При цьому вартість виготовлення контен-
ту залишалася незмінною. Інші намагалися встановлювати
платний доступ до свого контенту, але в мережі було стільки
сайтів безкоштовних новин, що їм часто доводилося просто
змиритися з цим. Але ж тримати штат репортерів, які дійсно
виїжджатимуть на місце подій та описуватимуть побачене,
коштує дорого. Результат можна бачити у поступовому за-
критті відділів новин у всьому світі.
Ідея надання якогось контенту чи сервісу безкоштовно, а за-

робляння грошей на рекламі й досі превалює серед техніч-
них стартапів. Підприємці дивляться на приклад Facebook
чи Google і кажуть: «Я теж так можу». Проблема в тому, що
такими успішними компаніями стають далеко не всі. На
початку розквіту Інтернету, коли онлайновий простір упер-
ше дозволив компаніям охопити конкретні сегменти цільо-
вої аудиторії, «гіперфокусування» вважалося цінним. Але
в міру виникнення дедалі більшої кількості платформ для
цього така можливість дещо втратила актуальність.
Іншим шляхом до фінансового краху компаній є переплата

за приваблення клієнтів. Одним із прикладів цього є ком-
панії, що пропонують щоденні купони, на кшталт Groupon
та Living Social. Спочатку вони приваблювали клієнтів
швидко та легко. Але в міру розширення зони їхньої досяж-
ності та збільшення клієнтури приваблювати нових рекла-
модавців та людей, охочих придбати купон, ставало дедалі
дорожче. Результати можна бачити в оцінках вартості ак-

тивів цих компаній.
Scrum дозволяє бізнесу швидко відповісти на ключове пи-

тання: чи заробимо ми на цьому гроші? Оперативно презен-
туючи клієнтам поетапні релізи, ви знатимете, що цінують
ваші клієнти й за що вони готові платити. А якщо перші
здогадки виявляться хибними, ви зможете внести необхідні
зміни. Максимум, чим ви ризикуєте, так це часом та енергі-
єю, вкладеними в кілька спринтів. Це аж ніяк не багатоміль-
йонні витрати на створення величезної складної інфраструк-
тури лише щоб виявити, що людям подобається ваш продукт,
але не настільки, щоб платити за його виробництво.
ОСЬ ЩО ВАМ РОБИТИ ЗАВТРА

Гаразд, що ви робитимете завтра для впровадження Scrum у сво-
їй роботі? Перший крок — це скласти перелік завдань та дібрати
команду. Подумайте про своє бачення продукту і почніть запи-
сувати речі, які вам потрібно зробити для його реалізації. Не
потрібно писати все одразу — достатньо переліку завдань (бек
логу) на тиждень. І поки члени команди проводитимуть свої
щоденні зустрічі стоячи та виконуватимуть перший спринт,
ви зможете підготувати достатній беклог для зайнятості ко-
манди протягом наступних двох спринтів. Ніколи не випу-
скайте його з уваги, бо, як тільки ваша команда прискориться,
вони почнуть робити більше, ніж ви вважали за можливе.
Потім, як власник продукту, складіть так звану дорожню

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

ниться. Можливо, навіть радикально.
Сенсом такого роду планування є створити прозорість усереди

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

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

як це зробити, ви знайдете в додатку. Scrum покликаний дати
вам можливість прискорити роботу команди за кілька днів.
Складіть ваш беклог, сплануйте свій перший спринт — і впе-
ред. Не треба присвячувати багато часу плануванню, рефлек-
сії, медитаціям, програмним заявам чи п’ятирічним проекці-
ям. Залиште це все конкурентам, яких ви обійдете. До речі,
чому б по дорозі не змінити світ на краще? У наступному
розділі я покажу вам, як це можна зробити.
Складайте перелік завдань. Перевіряйте його двічі.

Запишіть усе, що можливо виконати для проекту. Потім
розставте пріоритети. Перемістіть нагору цього беклогу
пункти з найвищою цінністю та найнижчим ризиком, по-
тім наступні за цими показниками, і так до кінця переліку.
Потрібен власник продукту. Ця людина перетворює

бачення проекту на беклог. Вона має розуміти особливос-
ті вашої галузі, ринку та клієнта.
Лідер — не бос. Власник продукту задає, що потрібно

виконати та чому. Як команда досягатиме цього та хто
саме — справа команди.
Вимоги до власника продукту. Мати глибокі знання сфе-

ри діяльності та повноваження для прийняття остаточного
рішення. Бути завжди доступним для відповіді на питання
команди та нести відповідальність за отримання цінності.
Оглядайте, орієнтуйтесь, вирішуйте, дійте (ООВД).

Треба бачити всю стратегічну картину, але діяти тактично
та швидко.
Сійте страх, непевність та сумнів у супротивника.

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

зміни. Створюйте нові речі лише доти, поки вони при-
носять цінність. Будьте готові відкинути їх заради речей,
що вимагають таких самих зусиль. Те, що ви вважаєте за
потрібне спочатку, ніколи не буде тим, що вам дійсно
потрібне.
РОЗДІЛ 9. ЗМІНЮЙТЕ СВІТ
238 Змінюйте світ
Scrum має свій початок у світі розробки програмного забез-

печення, але сьогодні він поширився в багатьох інших га-
лузях та компаніях, де виконуються проекти. Різноманітні
підприємства використовують його скрізь: від будівництва
космічних ракет до управління платіжними відомостями та
розширення відділу кадрів, причому в усіх сферах — від фі-
нансів до інвестицій, від розваг до журналістики. Я часто сам
дивуюся, що система, розроблена мною в 1993 році для до-
помоги в розробці комп’ютерних програм, довела свою уні-
версальну придатність. Scrum прискорює людські зусилля,
причому неважливо, які саме.
По суті, я почав бачити його проникнення в найдивніших

місцях, де він застосовується для розв’язання найскладні-
ших проблем людства. Задумайтесь тільки над деякими
з них. Наприклад, багато людей живуть у бідності, що
не лише принижує, але й породжує низку соціальних хво-
роб — від злочинності та корупції до війн та руйнувань.
Є також наша система освіти, яка потім підводить студен-
тів усього світу. Замість умінь та навичок ХХІ століття ми
нав’язуємо нашій молоді способи навчання, створені ще
років двісті тому. Спадає на думку ще один нефункціональ-
ний елемент.
Це форма державного управління, яка багато в чому за-

йшла у глухий кут, спираючись на застарілі ідеї, що більше
не відповідають реаліям нашого життя.
Легко відмахуватись від останніх новин про загибель лю-

дей в Африці, насильство в наших школах чи нескінченне
позерство людей при владі. Іноді здається, що їх надто
багато, і ми нічого не можемо з цим удіяти. Але Scrum
якраз і призначений для розв’язування таких складних
проблем. У кожному із цих випадків люди сьогодні зверта-
ються до Scrum по допомогу і, як і у світі бізнесу, демон-
струють неабиякий успіх.
Змінюйте світ 239
ОСВІТА
У чомусь передмістя всього світу дуже подібні між собою.
Розташовані в кількох кілометрах від ділових центрів, вони
є тими місцями, куди люди переїжджають, щоб купити де-
шевше житло, створити родину та відправити дітей до шко-
ли без багатьох проблем великого міста.
У цьому Альфен-ан-ден-Рейн є доволі типовим невеликим

містом. Воно розташоване на заході Нідерландів, між Лей-
деном і Утрехтом, десь у сорока п’яти хвилинах їзди від Ам-
стердама. Якщо під’їхати до містечка трасою в будній день,
то весь транспорт рухатиметься у зворотному напрямку —
везтиме людей на роботу деінде. Околиці ж рясно вкриті
молочними фермами та вітряками, старими й новими.
У самому місті транспорт майже повністю складається

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

столи рівними рядами навпроти вчителя перед дошкою, тиж-
день теорії, а потім практичні заняття разом із партнером,
вибір якого часто був завданням стратегічним і доволі стре-
совим. Можливо, ви любили хімію, можливо, вона вимотува-
ла вас до сліз. А може, серіал «Пуститися берега» дав вам нове
розуміння фінансового потенціалу опанування лабораторної
техніки та важливості добору правильного партнера. Яким би
не був ваш досвід, як тільки вчитель починав говорити про
ковалентні зв’язки чи якісь інші незрозумілі речі, вас із одно-
класниками майже із чутним клацанням перемикало. Ви по-
чинали дружно дивитись у вікно, щось малювати в зошиті або
думати про симпатичного хлопця чи дівчину в другому ряді.
Визнаймо, що в класах, де проходять уроки хімії, думки учнів
часто ширяють дуже далеко від предмета.
Але на уроках Вейнандса все зовсім не так. «Бачите, — каже

він, коли учні вриваються в клас та поспішають до своїх
столів, чомусь не сідаючи, — я нічого не роблю». На годин-
нику 8 : 30 ранку звичайної середи вересня, але клас Вей-
нандса не схожий на навчальний кабінет. Жодних тобі столів
рядами перед учителем. Вони розставлені так, щоб групи із
чотирьох учнів могли бачити одне одного.
Замість того щоб розсістися на місця, учні дістали великий

аркуш ватману, вкритий стікерами, прикріпили його на сті-
ну та зібралися навколо. Ватман поділений на кілька вели-
ких колонок. Крайня ліворуч називається «Alle items». Далі
йдуть «Te doen», «In uitvoering» і, нарешті, «Klaar». Як ви
можете здогадатись, вони означають «Всі завдання», «Ви-
конати», «Виконується» та «Виконано».
Нижче від колонок є ще чотири заголовки: «Визначення

готовності», «Графік» — їхній варіант діаграми згоряння
завдань, що показує прогрес у напрямку до мети, а також
«Ретроспектива» та «Швидкість» для вимірювання балів,
досягнутих за кожний урок. Їхні спринти зазвичай тривають

чотири-п’ять тижнів і закінчуються тестом.
Стоячи перед своїми Scrum-дошками («флопс», як вони

називають їх нідерландською), учні планують, що вони зби-
раються вивчити на конкретному уроці. Вони переносять
стікери з обраними завданнями з беклогу «Всі завдання» до
колонки «Виконати» й беруться до роботи. І знову, як лю-
бить говорити Вейнандс, він не робить нічого. Учні самі
відкривають свої підручники та починають учитися. Мабуть,
найважливіше, що вони навчають один одного. Вейнандс
лише походжає по класу, дивлячись на Scrum-дошку та діа-
граму згоряння. Час від часу він указує учням на помилку,
швидко пояснює складний момент чи навмання бере якесь
завдання з колонки «Виконано» та швидко опитує всіх учнів
про нього, стежачи, щоб усі розуміли цю тему. Якщо тема
зрозуміла не до кінця, він повертає її назад до колонки «Ви-
конати». Умовою готовності є те, що матеріал має бути зро-
зумілим усьому класу.
Правда, у цих учнів є один унікальний розділ Scrum-до-

шки: «Визначення веселощів». Вони мають не лише ви-
конувати роботу, але й отримувати від цього задоволення.
Трьома критеріями цього є довіра, гумор та унікальне ні-
дерландське слово Gezelligheіd. Точного перекладу воно
не має. Якщо приблизно, то воно означає затишок, това-
риськість, розвагу, задоволення, зустріч із друзями після
довгої відсутності, проведення часу з коханими чи просто
належність до чогось. Якщо чесно, це вразило мене як
ідеальний спосіб описати відчуття підтримки, радості, на-
дії, веселощів, комфорту та захвату від членства в дійсно
чудовій команді.
«Вам не потрібно виступати в ролі поліцейського, — каже

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

вже вивчили, до якої дати треба досягти проміжних ета-
пів і чи потрібно попрацювати вдома, щоб вивчити все
вчасно. «Вони самоорганізовані. Вони розробляють розум-
ніші та швидші способи навчання. Одна команда почала
зразу з тесту і працювала у зворотному напрямку. Гурт оди-
надцятирічних учнів. “Не добре”, — сказав я їм, і вони одра-
зу похнюпились. — Вейнандс сяє своєю заразливою усміш
кою. — “Відмінно!” — продовжив я».
Учні знайомляться зі Scrum, чи eduScrum, як називає свій

підхід Вейнандс, у перший же день занять. Перш за все вони
розбиваються на команди — причому багатофункціональні.
Учні оцінюють самих себе в різноманітних категоріях — від
хоробрості до любові до математики, від урахування почут-
тів інших до націленості на мету. Потім їм кажуть сформу-
вати багатофункціональні команди, що матимуть усі вміння
та навички, потрібні для засвоєння матеріалу. За словами
Вейнандса, це вчить їх чогось не менш важливого, ніж хі-
мія, — співпрацювати з людьми, які мають інші таланти, ніж
вони, та високо їх цінувати.
Тіму Янсену сімнадцять. Це його останній рік у школі. Він

використовує Scrum уже три роки й збирається вступати до
університету, де планує вивчати хімію. Тім схожий на типо-
вого заучку. «Я можу вчитися швидше за інших, — каже
він. — Але працюючи разом із кимось, ви стаєте кращим.
Пояснюючи матеріал іншим, я краще засвоюю його сам».
Він повертається до Ґудіт Шварц, яка сидить через стіл від
нього. «Вона знає, що може спитати в мене щось із предме-
та. А я можу спитати її щодо організації. Їй вдається зводити
все докупи краще за мене».
Ґудіт зовсім не схожа на нього: струнка, приваблива бі-

лявка. «Так ти більше дізнаєшся про своїх однокласників,
розумієш, кому що краще вдається».
«Scrum допомагає відлюдькам налагоджувати зв’язок із реш-

тою класу, — долучається до розмови її також гарненька та
стильна подружка Манека Бовенс. — Іноді ти обираєш ко-
манду, а іноді обирають тебе. Ти дізнаєшся, що вони кращі
за тебе в деяких якостях».
Таке навчання, за словами Вейнандса, є частиною ідеї зро-

бити несвідомі вміння та навички свідомими. У житті важ-
ливі далеко не лише ті вміння, що можна перевірити на іс-
питі. Якщо допомогти учням визначати й цінувати різні
чесноти самих себе та інших, у них розвиваються навички
ХХІ століття. Засвоїти їх потрібно кожному.
Після розбиття на команди учнів вчать оцінювати вико-

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

тиву, питаючи себе: «Що пройшло добре?», «Що могло про-
йти краще?», «Як команда може покращити свою роботу?»
Такий акцент на командах, каже Вейнандс, іноді дивує бать-

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

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

ся на результатах. У голландській системі шкільної освіти
оцінки успішності йдуть від 1 до 10, причому найнижчою
задовільною вважається 5,5. На заняттях Віллі найнижчою
оцінкою є 7. І учні відповідають цьому стандарту. За остан-
ній рік, каже Вейнандс, результати тестів покращились
більш ніж на 10 відсотків.
Віллі дізнався про Scrum від свого зятя — працівника вели-

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

однією з багатьох прийнятих систем — він створений для
панування. У голландських школах, наприклад, eduScrum
не залежить від однієї особи, навіть такого видатного вчи-
теля, як Вейнандс.
Можливо, він і почався з Віллі, який переконав кількох своїх

колег, учителів хімії в Ашрамі, його спробувати, але тепер він
росте далі. За підтримки ділової спільноти сьогодні в Нідер-
ландах діє спеціальна фундація eduScrum, де готують учителів
та розповідають школам про переваги цієї системи. Співробіт-
ники цього фонду підготували вже сімдесятьох чотирьох учи-
телів — з усіх предметів для дванадцяти шкіл. Причому нада-
лі вони планують зростання, готуючи по шістдесят учителів
для п’ятнадцяти шкіл щороку. Через п’ять років це означа-

тиме ще 300 вчителів і 75 шкіл. Непоганий початок.
Я зустрівся з кількома вчителями з усієї країни, і вони

говорили мені, що це нова система Монтессорі. Вони вва-
жають її рухом уперед.
І це відбувається не лише в Нідерландах. В Аризоні є при-

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

з деякими тамтешніми учнями. Коли я запропонував їм
ставити питання, руку підняв один хлопчик.
«Аж не віриться, що ви розробили це для комп’ютерного

програмного забезпечення, — сказав він. — Це здається іде-
альною розробкою для середньої школи».
Я дивився на цього хлопця й відчував, як у мене зволожи-

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

кількох комп’ютерних компаній, я не розумів, що створюю
також щось, що зможе допомогти виправляти людські жит-
тя. Але вийшло саме так. І, мабуть, найяскравіше це вияви-
лося в угандійських селах.
БІДНІСТЬ
Уганда є однією з найбідніших країн світу. Понад третина
місцевого населення живе на менш ніж 1,25 долара на день.
Переважна більшість угандійців мешкає в сільських райо-
нах, де бідність є суцільною, а люди борються за виживан-
ня, обробляючи невеликі земельні ділянки, які дістали
у спадок. Багато із цих місць дуже віддалені — до найближ-
чого містечка з ринком треба кілька днів іти пішки. Роди-
нам складно відправляти дітей до школи, бо їхні руки по-
трібні для роботи по господарству. Особливо рано кидають
навчання дівчата. Середня тривалість життя людей складає
п’ятдесят три роки. Дитяча смертність на 5 відсотків пере-
вищує народжуваність, а шість тисяч жінок щороку поми-
рають від ускладнень вагітності. Життя землероба в Уганді
аж ніяк не назвеш простим.
Але, на щастя, існує фонд Grameen, заснований однойменним

банком лауреата Нобелівської премії Мухаммада Юнуса, який
почав свою діяльність з мікрофінансування найбідніших
мешканців Бангладеш. Робота цього фонду спрямована на
допомогу біднякам усього світу вийти з бідності, причому за
рахунок не подачок, а розвитку їхніх недооцінених сильних
сторін. В Уганді було вирішено спробувати зробити це, на-
давши бідним людям можливість ділитися своїми знаннями
та засвоювати нові.
Для цього фонд найняв на роботу приблизно 1200 меш-

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

давши їм смартфони та доносячи таким чином інформацію
до населення.
Стів Белл, співробітник «Інституту ощадливого підприєм-

ництва» і сертифікований Scrum-майстер, нещодавно від-
відав два віддалених села та описав, як це працює. Прово-
диться зустріч землеробів — стоячи прямо в полі. Хтось із
них показує рослину, що страждає від якоїсь хвороби. Ін-
формаційний працівник швидко проглядає зображення
в смартфоні, доки не знаходить фото рослини з такими
симптомами й не визначає хворобу. Тут же на місці доби-
рається науковий спосіб лікування, який не вимагає доро-
гих пестицидів чи хімікатів і яким селянин може негайно
скористатись.
Белл каже, що швидка передача практичної інформації вже

сама по собі є достатньо потужним інструментом, але цей
мобільний додаток ще й пов’язує селян між собою по всій
Уганді. Завдяки цьому зв’язку вони можуть ділитись інфор-
мацією про ціни на найближчому ринку, до якого часто
буває кілька днів ходу. Раніше вони покладалися на милість
перекупників, які, користуючись їхнім незнанням ринку,
називали ціни просто «зі стелі». Тепер же селяни завжди
знають, скільки перекупники беруть собі.
Белл розповів мені історію однієї жінки, яка сказала, що самі

лише сільськогосподарські дані подвоїли її врожаї. А ринко-
ві дані ще й подвоїли її ціни. Раніше вона отримувала по
300 шилінгів за бушель, але коли дізналася, що це коштує
1000 шилінгів, змогла домовитись на 600. Подвійний уро-
жай, подвійний прибуток, та сама робота. Саме для цього
призначений Scrum, і саме це він приніс їй.
Ерік Камара очолює технологічну групу відділення фон-

ду Grameen у Кіншасі. Його група використовує Scrum
для розробки цих мобільних додатків. За його словами,

кожного разу, отримуючи замовлення на нові опції, ко-
манда оцінює їх за шкалою від 1 до 7, відповідаючи на
три питання:
1. Наскільки важлива ця робота для місії допомоги бідним?

2. Як ця характеристика посприяє роботі інформаційних
працівників?
3. Чи підтримують цю характеристику партнери? (Фонд від-
дає перевагу роботі з партнерами, такими як фонд Білла
та Мелінди Ґейтсів, а не самотужки.)
Це дозволяє Камарі розставляти пріоритети в роботі, вико-

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

ти швидко поширюється на решту відділень фонду в Кін-
шасі, змінюючи ставлення працівників до їхньої звичної
роботи з дев’ятої до п’ятої. Раніше там проводилися що-
тижневі зустрічі, на які ніхто не хотів іти, — багатогодин-
ні переливання з пустого в порожнє, де підіймались окре-
мі проблеми та скарги, але майже нічого не робилось. Такі
зустрічі тривали вічність і нікого не влаштовували. Дуже
часто єдиним результатом були звинувачення, а не пошук
рішень. Тепер же, каже Камара, кожна команда має свою
Scrum-дошку. Перед зустріччю всі проблеми та перешко-
ди стають добре помітними. У наші дні директор відді
лення може просто пройтись кабінетами та на власні очі
обачити, що гальмує чи блокує роботу, просто погля-

п
нувши на Scrum-дошку.
Якщо поговорити з людьми зі світу неурядових організацій,

то вони всі скаржаться, що люди там об’єднані спільною
метою та віддані справі, але з дисципліною в них не дуже.
Натомість Scrum дозволяє використовувати пристрасть лю-
дей до роботи, пояснюючи необхідність і правильність роз-
ставлення пріоритетів.
Зі Scrum легко працювати в бізнесі. Використовуючи його,

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

буде виміряти. Scrum дає людям можливість легко вимірю-
вати прогрес. У фонді Grameen є те, що його співробітни-
ки називають «прогресом виходу з індексу бідності». Ним
вимірюється ефективність кожної з програм. Вони можуть
провести опитування та чітко побачити вплив, який мають
громадські інформаційні працівники з мобільними пристро-
ями в сільській місцевості. Вони можуть експериментувати
з різними способами роботи. Вони можуть допомагати лю-
дям знаходити нові шляхи виходу з бідності.
Мене захоплює, що Scrum повертається до свого коріння.

Запускаючи його вперше, я надихався діяльністю банку
Grameen та інших мікрофінансових інституцій, а також
їхньою допомогою командам бідних людей щодо виходу
з бідності. Вони збирали команди бідняків і задавали
кожному із членів скласти бізнес-план, розписавши, що б
той зробив, отримавши мікрокредит у 25 доларів. Один

чоловік міг захотіти купити візок для продажу фруктів на
площі містечка. Інша жінка — швацьку машинку, щоб
шити на продаж одяг. Нові позики команда отримувала
лише після повернення попередніх. Кожного тижня вони
зустрічались, щоб подивитись, як можуть допомогти одне
одному. Результати вражали. Спершу жінка зі швацькою
машинкою починала заробляти достатньо грошей, щоб
прогодувати своїх дітей. Кілька тижнів потому вона вже
могла дозволити собі купити їм взуття. Потім вона отри-
мувала можливість відправити їх до школи. Ще через
кілька циклів вона взагалі відкривала малий бізнес і мог-
ла почати будівництво власного будинку. Дивлячись на
такі успіхи, я сказав програмістам, з якими тоді працю-
вав: «Ці бідні люди не мають взуття, але це не заважає їм
знайти вихід із бідності. Ви маєте взуття, але не програм-
не забезпечення. Вони знайшли спосіб співпраці, щоб
вибратися зі злиднів. Чи готові ви зробити те саме?» Так
і народився Scrum.
Неприбуткові організації — це лише одна сфера, де ми мо-

жемо запровадити інновації для досягнення соціального
добробуту. А як щодо самоорганізації? Органів влади?
ДЕРЖАВНЕ УПРАВЛІННЯ
Державне управління є не лише формою організації соці-
альної сфери — доріг, поліції, судів та транспорту. Воно
також формалізує, хто ми є як народ. Воно зводить воєди-
но наші уявлення про самих себе. У Сполучених Штатах
фундаментальні прагнення американського народу зібра-
ні в документі, підписаному купкою бунтівників, яких би
точно перевішали по одному, якби вони не трималися
разом, — Декларації незалежності. Складена аристокра-
тами, ідеалістами, рабовласниками та землевласниками,
ця Декларація, на диво, містить радикальне уявлення про

те, яким саме народом хотіли бути американці тієї рево-
люційної доби.
Ми вважаємо самоочевидними істинами, що всі люди ство-

рені рівними і наділені своїм Творцем певними невід’ємни-
ми правами, до яких належать життя, свобода та прагнення
до щастя. На те, щоб забезпечувати ці права, між людьми
встановлюються уряди, влада яких походить зі згоди тих,
ким вони правлять.
У наші дні важко оцінити, яким відступом від загально-

прийнятих тоді норм були ці слова. Хоча ідеї епохи Просвіт-
ництва вже почали поширюватись, повністю демократичних
країн у ті часи ще не існувало. Правління здійснювалося
згори, божественним правом королів та силою зброї. Біль-
шою частиною світу правили великі імперії — не лише Ве-
лика Британія, але й Франція, Австрія, Росія та Туреччина.
Ідея про те, що люди наділені правами від народження, а не
отримують їх милістю когось при владі, здавалась, м’яко
кажучи, революційною.
З таких ідеалів і виникла форма правління, що називалась

республікою. Подібно до того, як учився ходити робот Родні
Брукса, Сполучені Штати також спочатку невпевнено стояли
на ногах, спотикалися й падали та час від часу сходили на
манівці. Але ці ідеали надихнули революції по всьому світу,
і сьогодні більшістю великих держав править, бодай фор-
мально, народ через своїх представників.
Проблемою, звичайно, є понад двохсотлітній бюрократич-

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

приватизуючи прибутки та соціалізуючи витрати.
У більшості світових столиць сьогодні виріс такий собі при-

дворний клас, що постійно перебуває біля влади. Тендери,
грошові потоки та теплі крісла розподіляються за принци-
пом «кого ти знаєш», а не «що ти із собою несеш». Особли-
во яскраво це виявляється в колообігу політиків, генералів
та владних бюрократів із влади до бізнесу і назад. Кількість
багатозіркових генералів, що очолюють фірми-підрядники
оборонної промисловості, депутатів, які стають лобістами,
чи колишніх урядців, що йдуть у фінансово-промислові гру-
пи, просто зашкалює.
Але, як я підкреслював у розділі 3, безглуздо шукати поганих

людей — треба шукати погані системи. Давайте ставити пи-
тання, що має шанс дійсно змінити стан справ: «Якими мо-
тивами керується погана поведінка?» Я дуже сумніваюсь, що
хтось із вашингтонських непотоплюваних вважає себе пога-
ною людиною — скоріше навпаки, вони сповнені добрих на-
мірів. Це система підставила їх, та й нас теж. Але як нам
змінити цю систему? Як заохотити прозорість, пріоритетність
і відповідальність? Ви знаєте відповідь: за допомогою Scrum.
Почнімо за кілька тисяч кілометрів на захід від міста Ва-

шингтона — зі столиці штату Вашингтон, міста Олімпії.
Останні дві президентські адміністрації (спочатку респу-
бліканці, а тепер демократи) впроваджували там так зва-
ний ощадливий уряд. Під час виборчої кампанії восени
2012 року чинний губернатор Джей Інслі сказав в інтерв’ю:
«Держава переважно зайнята прийняттям рішень. Ми ж
хочемо знайти спосіб залишити на столі менше паперу»1.
План губернатора містить п’ять пунктів, які можна знайти

в будь-якій передвиборчій програмі: 1) система освіти «сві-
тового класу» від початкової школи до коледжу; 2) «еконо-
міка благоденства»; 3) зробити штат національним ліде-

ром із відновлюваних джерел енергії та чистого довкілля;
4) здорові та безпечні громади; 5) раціональне, ефективне
й відповідальне управління.
Це не якісь там революційні цілі. Це лише те, чого люди

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

повідає не лише за те, які нові технології закуповуються,
але і як це робиться. Штат управління налічує двадцять
співробітників, які мають запобігати серйозним програм-
ним збоям вартістю в десятки мільйонів доларів. При цьо-
му вони займаються оновленням програмного забезпечення
для органів влади, що відповідають за найрізноманітніші
сфери, від видачі водійських прав та розподілу виплат з без-
робіття до регулювання рибних ресурсів та дикої природи.
У 2012 році вони проконтролювали вісімдесят звернень
на загальну суму понад 400 мільйонів доларів. А ще вони
видають правила та розпорядження для різноманітних аген-
цій щодо впровадження політики штату.
Для цього вони використовують Scrum. Вони навіть при

брали перегородки у своїх кабінетах та сформували Scrum-
команди.
За словами заступника голови управління Майкла Де Андже-

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

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

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

існує величезний страх не отримати ідеального продукту.
У серпні 2013 року він повідомив: «Минулого тижня ми змі-
нили порядок звернення до нас клієнтів. Але залишилось
багато місць, де все ще вказано старий спосіб — на нашому
сайті, в різних матеріалах тощо. Тому ми маємо всі ці мате-
ріали змінити [передусім]. Ми вирішили не чекати, а просто
зробити це. Ми оновимо всю документацію в наступному
спринті. Інакше клієнти залишатимуться без кращого спо-
собу зв’язку місяцями… ми крастимемо їхню цінність».
Управління інформаційної політики також намагається про-

вести Scrum крізь усі бюрократичні перешкоди штату. Саме
тому вони й змінили на Scrum власну систему — щоби ста-
ти прикладом, мати змогу говорити про нього зі знанням
справи. Переваги тут просто надто великі, щоб ними не
користуватись.
Але існують і деякі перепони на цьому шляху. За слова-

ми Де Анджело, вони виявили одну річ: у деяких випад-
ках у законі штату буквально прописано каскадну мо-

дель. Змінити це може бути дуже непросто, бо штат
Вашингтон виділяє фінансування дворічними циклами.
«Доводиться просити великі суми. Тут не вийде казати,
що ми додаватимемо цінність, доки ви не скажете нам
зупинитись, — каже ДеАнджело. — Уряд хоче бачити, що
це коштуватиме стільки-то грошей і принесе таку-то цін-
ність у таких-то часових межах. Це потрібне йому для роз-
мови з громадянами. Хоча ми й знаємо, що це значно
менш ефективно».
Почасти проблема полягає в тому, що в Сполучених Штатах

як на рівні держави, так і штату законодавчі органи влади
розбиті на комітети. Одна група законодавців займається
освітою, друга — злочинністю, третя — бюджетом, а четвер-
та — соціальними службами.
«Вони розрізнені й ніколи не дивляться на загальну кар-

тину», — каже Рік Андерсон. Він працює консультантом
державних агенцій, округів та міст у штатах Вашингтон,
Орегон, Каліфорнія та Гаваї. Він працював із законодав-
цями й каже, що зміни назріли, навіть якщо на це піде
деякий час.
На його думку, почати слід зі встановлення цілей, базова-

них на продуктивності. «Гаразд, агенціє X, ось ваші цілі,
а ось ваші очікувані результати. Лише маючи їх, можна
починати писати закони, засновані на результатах», —
каже він.
У модернізованому світі Scrum замість затвердження кон-

кретного плану будівництва мосту через річку законодавчий
орган зможе сказати дорожньому управлінню: «Ми хочемо,
щоб цей перехід міг пропускати X людей за час Y, що кош-
туватиме Z. Як ви це зробите — вирішувати вам». Це б одра-
зу дало поштовх відкриттям та інноваціям.
Натомість сьогодні нормою є будівельні проекти, що ви-

биваються з бюджету на сотні мільйонів доларів. У чому
сенс? У міру праці на об’єкті бригада будівельників стика-
ється з новими проблемами та новими способами їх розв’я-
зання. Замість того щоб обмежувати такого роду інновації
через комісії з контролю за внесенням змін та масу звітів,
ми б мали їх заохочувати.
Але як щодо ідеалів, з яких я почав цей розділ, — де сус-

пільство саме формує себе через документ? Скажімо, кон-
ституцію? Ну, одна країна вирішила, що використання
Scrum дозволяє розробити конституцію, яка дійсно відо-
бражуватиме волю народу.
У 2008 році по світу вдарила фінансова криза, якої цілком

можна було уникнути. Великі банки випустили ситуацію
з-під контролю, накопичуючи дедалі більше безнадійних
боргів, які неможливо було повернути. Однією з країн, що
постраждали найбільше, стала Ісландія. За підтримки дер-
жави місцеві приватизовані банки взяли на себе просто
величезні ризики на фінансових ринках. Як кажуть на
Волл-стрит, якщо ви не знаєте, хто в кімнаті дурень, то це
ви. У цьому випадку дурнем була Ісландія. Сума грошей,
яку вони заборгували, була приголомшливою як для такої
маленької країни.
Урешті-решт, банківські оцінки у дванадцять разів переви-

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

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

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

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

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

скоро зрозуміють, що їм більше нема де ховатися. Scrum
змінює світ навколо них, і, попри весь їхній спротив, зміни
неминучі. Система Scrum настільки швидка, прозора та
уважна до побажань людей, що рано чи пізно переможе
політиканів, які стоять на її шляху.
Змінюйтесь або помріть.
ЯК МИ ВСІ КОЛИСЬ ПРАЦЮВАТИМЕМО

Раніше в цій книжці я вже розповідав про принцип бойових
мистецтв Шу-Ха-Рі. У стані Шу люди чітко дотримуються
правил, щоб засвоїти ідеї, які за ними стоять. У стані Ха
люди починають створювати власний стиль у межах цих
правил, адаптуючи їх до своїх потреб. У стані Рі люди існу-

ють поза межами правил — вони втілюють ідеал. Спостері-
гаючи за справжнім майстром у стані Рі, неначе бачиш
рухомий шедевр. Його чи її дії здаються неможливими, але
це тому, що майстер став філософією у плоті. Ідея знайшла
свою реалізацію.
Усе це є передмовою до того факту, що в Scrum існують

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

ників вільними та оптимізувати інновації, є Valve. Її при-
клад показує, як ми всі можемо неминуче організувати
самих себе чи для розробки кращого програмного забезпе-
чення, чи визволення людей з бідності, чи для планування
весілля, чи ремонту будинку.
Створена в 1990-х як фірма з випуску відеоігор, що розро-

била такі революційні хіти продажів, як Half-Life та Portal,
компанія Valve працює на повному самофінансуванні й сама
володіє всією своєю інтелектуальною власністю. Майже всі
її понад триста співробітників працюють в одній офісній
будівлі в місті Бельв’ю, штат Вашингтон. Компанія має по-
над п’ятдесят мільйонів клієнтів та заробляє сотні мільйо-
нів доларів на рік. Причому головного начальника як та-
кого в них немає.
Витоком Valve є насамперед Microsoft. У наші дні Microsoft

уже зовсім інакший, але в далекі 1990-ті він був просто-таки
зразком ієрархічної корпорації. Усі визначали себе за тим,

як далеко внизу корпоративної піраміди вони від засновни-
ка та генерального директора Білла Ґейтса — тоді найбагат-
шої людини у світі, та й досі однієї з найбагатших.
Серед засновників Valve був і Ґреґ Кумер. Він працював на

Ґейба Ньювелла, який у Microsoft очолював групу розробки.
Ґреґ описує, як ця підвищена увага до фігури боса виявля-
лась навіть в інструментах, які люди використовували у сво-
їй роботі: «У Microsoft був плагін Outlook під назвою “Орга-
нізаційна схема”. І щоразу, отримуючи електронну пошту,
вони починали клацати цей плагін, щоби подивитись, яке
місце в компанії займає відправник. У скількох клацаннях
той від Білла, скільки в нього прямих підлеглих, ворог він
чи друг — усе це можна було зрозуміти просто з його місця
в “Організаційній схемі”».
Ґреґ каже, що, якщо подивитися з віддалі, можна було по-

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

людей, які підпорядковувались безпосередньо йому. «Це
дуже впадало в очі, коли ви відкривали додаток “Організа-
ційна схема”, — каже Ґреґ. — Вона явно туди не вписувалась.
І це спричиняло політичні проблеми, бо вона, бачте, не мала
правильної кількості менеджерів чи правильної структури».
Реакція компанії була майже такою, як у лейкоцитів, що
масово атакують інфекцію. Сьогодні, звичайно, Microsoft
уже має три тисячі людей, які працюють у Scrum-командах,
і поступово рухається в бік розширення до двадцяти тисяч.
Але в ті часи цю «інфекцію» всіляко намагалися ліквідувати.
Тому Ґейб, Ґреґ та кілька інших співробітників звільнились

і заснували власну компанію Valve. Кілька років тому Ґреґ
намагався скласти пам’ятку для працівників, пояснюючи

принципи роботи Valve. У цьому документі не було перелі-
ку ставок зарплати чи інформації про покриття медичним
страхуванням виготовлення окулярів. Радше це була спро-
ба передати дух компанії.
«Я визначив, що для засвоєння підходу Valve до роботи

співробітникам потрібно від дев’яти до шістнадцяти місяців.
Вони не одразу звикають до відчуття свободи», — каже Ґреґ.
Той документ був призначений прискорити занурення лю-
дей в атмосферу компанії, але Ґреґ та інші засновники би-
лися над кожним словом, бо не хотіли, щоб це пояснення
здавалося спущеним згори. У результаті перший розділ на-
зивався «Ласкаво просимо на Рівнину».
Це наш короткий спосіб сказати, що ми не маємо жодного

начальства і ніхто нікому не «звітує». У нас, щоправда, є за-
сновник/президент, але навіть він вам не начальник. Цією
компанією керуєте ви — ведете її до можливостей та від
ризиків. Ви маєте право давати зелене світло проектам. Ви
маєте право постачати продукти.
Пласка структура усуває всі організаційні бар’єри між вашою

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

ності», — то ви не помилились2.
Ось як у Valve зазвичай починається проект. Хтось зі спів-

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

ють це цікавою ідеєю, то приєднуються до команди, чи
«кабал», як вона називається у Valve. Усі столи, яких у ком-
панії сотні, мають колеса. Починаючи працювати разом над
якимось проектом, люди буквально голосують своїми стола-
ми, зсуваючи їх у нову конфігурацію.
Ґреґ описує, як це відбувалося з продуктом під назвою «Ве-

лика картина». Одним з найбільших продуктів Valve є їхня
ігрова платформа Steam, яка постачає користувачам відео
ігри та програмне забезпечення. На цій платформі мож-
на знайти ігри не лише Valve, але й інших розробників.
Саме таким чином сьогодні переважно й поширюються
комп’ютерні ігри. Але, як згадує Ґреґ, був момент, коли він
та кілька його колег злякалися, що вже досягли свого клі-
єнтського максимуму — понад п’ятдесят мільйонів.
«[Ми] почали думати про те, як зростає наша компанія і як

розвивається Steam, і нам здалося, що це межа кількості
клієнтів, якої ми можемо досягти. Ми ж хотіли дістатися до
клієнтів також в інших місцях, у їхніх вітальнях, мобільних
пристроях тощо».
Тоді він почав говорити з людьми — дизайнерами, іншими

колегами. Він переконав їх, що буде добре запропонувати
щось, що працюватиме на телевізорах, телефонах та план-
шетах, і вони створили ідею «Великої картини» — способу
постачати відеоігри на ці платформи. Але люди, яких пере-
конав Ґреґ, не мали всіх умінь та навичок, потрібних, щоб
дійсно це зробити. Вони знали, як має виглядати те, що їм
потрібне, але не мали змоги це реалізувати.
«Ми почали продумувати деталі, а потім зробили фільм про

те, як круто це буде, і скористались ним, щоб набрати людей
під проект. Самі створити потрібний код ми не могли, [тому]
нам потрібно було залучити людей, які можуть».
Так вони й зробили. Приблизно через рік проект був пред-

ставлений клієнтам. Хто вирішував, коли його представля-
ти? Люди, які над ним працювали. Хто вирішував, що він
достатньо добрий? Люди, які над ним працювали.
«Коли якась компанія оптимізується навколо нововведен-

ня, вона зазвичай змінюється докорінним чином, усуваю-
чи внутрішні структури та ієрархії, будь-яку внутрішню
структуру», — каже Ґреґ. Valve працює так весь час. Вони
не чекають, поки змінитися їх змусить та чи інша криза,
а змінюються постійно. Це повсякденний спосіб роботи
їхньої компанії. Ще одна цитата з пам’ятки для співробітни-
ків компанії Valve.
Valve не відкидає організаційну структуру повністю — хоч

і ненадовго, вона постійно виявляється в багатьох формах.
Але коли ієрархія або чіткий розподіл праці не створюють-
ся членами групи чи коли ці структури залишаються на
довгий період, виникають проблеми. Ми вважаємо, що ці
структури неминуче починають слугувати власним потре-
бам, а не потребам клієнтів компанії. Ієрархія починає по-
силювати власну структуру, наймаючи людей, які відпо
відають її формі, додаючи людей для заповнення ролей
підлеглих та підтримки. Її члени також мотивовані займа-
тися пошуками своєї вигоди, віддаючи перевагу владній
структурі, а не зосередженню на простому забезпеченні
цінності для клієнтів3.
Може здатися, що компанія Valve вразлива для халявни-

ків — людей, які прагнуть скористатись їхньою вільною
системою, — але там постійно зберігається контроль з боку
колег. Звичайно, люди самі вирішують, над чим працю-
вати, але якщо їм не вдається переконати більше нікого,
що це добра ідея, можливо, вона дійсно не добра. За сло-
вами Ґреґа, хоча співробітники компанії позбавлені сум-
нівного задоволення вислуховувати чиїсь накази, їхні
олеги завжди готові висловити свою думку щодо пропо-

к
нованого проекту.
Це не ідеальна система. Жодна людська організація не іде-

альна. Але зазвичай у Valve персональні перестороги вперше
підіймають колеги по команді в розмовах між собою. Вони
можуть приводити когось для консультації. Це може закін-
чуватись відгуком, жорстким коригуванням чи навіть відхи-
ленням проекту. Але вирішує команда.
Виняток стався у 2013 році, коли компанія Valve зіткнулась

із проблемою, з якою їхня система не могла впоратись. Упер-
ше за весь час своєї роботи вони найняли велику групу пра-
цівників одночасно. Річ у тім, що вони прийняли рішення
розділитись на підрозділи апаратного забезпечення та мо-
більних додатків, але просто не мали для цього потрібних
умінь та навичок. Тому вони найняли для розв’язання цієї
проблеми багато нових людей.
Але прийом на роботу одночасно такої кількості нових спів-

робітників, незвичних до порядків Valve, спричинив про-
блеми. Деякі працівники не бажали підлаштовуватись під
традиції компанії. Вони говорили іншим людям, що роби-
ти. І, найгірше, не дотримувались високих стандартів про-
дуктивності Valve. За звичайних умов інші члени команди
не терпіли б такої поведінки, але через те, що всі в групі
були новенькими, їхні колеги не мали достатньо впевнено-
сті у способі дій компанії.
«Тому група старих працівників (кістяк) Valve, яким це на-

бридло, стала на захист принципів компанії. Навіть якщо
для цього їм довелося діяти за межами цих принципів», —
каже Ґреґ. Компанія найняла одразу кілька десятків людей.
Розмовляючи з Ґреґом, можна було сказати, що він вважав
це помилкою. Він описує це як майже біологічну реакцію,
яка дивним чином нагадує дії Microsoft проти засновників
Valve. Відбулася атака на чужорідні організми для захисту

цілісності системи.
«Ми багато обговорювали значення для заявлених нами

цілей того, що нам довелося діяти за їхніми межами, —
розмірковує Ґреґ. — І як ми можемо уникати цього в май-
бутньому. І не покладатися на групу людей, які працю
ють у компанії довгий час. — Він зупиняється на хвильку,
а потім упевнено каже: — Не мине й року, як ми це зна
тимемо».
У тому, що вони зробили, відчувається віра. Вони послідов-

но прагнули максимізувати свободу, можливості й творчість
людей. Попри періодичні труднощі, цей спосіб дій виявився
надто ефективним, щоб не повторювати його знову і знову.
«Це капіталістична інновація, не менш потужна, ніж бага-

то промислових інновацій, що змінили природу роботи, —
каже Ґреґ. — Вона настільки корисна та успішна, що, без
умовно, стане рушійною силою змін у світі».
Чи використовують вони Scrum? За словами Ґреґа, про-

йшовши коридором, ви побачите чимало лекційних дощок
на колесах, щільно вкритих стікерами. Але вони не змушу-
ють людей використовувати цю систему, а дають самим
вирішувати, яка процедура їм підходить. Як і з більшості
питань, Ґреґ та інші засновники компанії утримуються від
того, щоб казати комусь, що робити. Проте багато працівни-
ків Valve вирішили, що по змозі обиратимуть Scrum. І цього
для мене досить.
Сьогодні ви не побачите багато компаній, схожих на Valve.

Але кожного дня їх виникає дедалі більше. І не лише у сфе-
рі програмного забезпечення. Наприклад, жодних началь-
ників немає також у компанії Morning Star — світовому
лідері з переробки томатів. Щодо ролей та обов’язків усі
працівники домовляються між собою — чи то продажі, чи

вантажні перевезення, чи складні інженерно-технічні роз-
робки. У будь-якій компанії спочатку треба дати співробіт-
никам відчути себе вільними, а потім підвести їх до прийнят-
тя відповідальності, яка із цим приходить.
Або, як співав гурт Funkadelic іще в 1970 році: «Звільніть свій

розум… і ваша дупа потягнеться слідом».
ЩО МИ НЕ МОЖЕМО ЗРОБИТИ?
Цинізм, мабуть, є раціональною реакцією на відчай, але це
один з найбільш руйнівних станів людини. Перші роки цьо-
го століття були багаті на елементи, які породжують цинізм:
безглузді війни, загорнуті в патріотизм; нігілістичний теро-
ризм, що маскується під віру; жадібність, прикрита плащем
ідеологічної правоти; амбітні навколовладні діячі, що діють
за своїми егоїстичними інтересами.
Циніки з розумінням зітхнуть і скажуть: «Так уже влашто-

ваний світ. Люди в суті своїй зіпсовані та егоїстичні, і не
визнавати цього просто наївно». Так вони виправдовують
примус та раціоналістично пояснюють обмеження.
За останні два десятиліття я глибоко вивчив літературу про

те, що приносить надзвичайність. Ви здивуєтесь, але від-
повідь полягає в тому, що в глибині душі люди прагнуть
стати надзвичайними. Вони хочуть робити щось важливе —
змінювати світ, хай навіть трохи, на краще. Головне — по
збутися перешкод на їхньому шляху, усунути те, що заважає
їм стати тим, ким вони можуть стати.
Саме це й робить Scrum. Він задає цілі та систематично, крок

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

світ чи пасуванням перед наявним. Радше це практичний,
дієвий спосіб запровадження змін. Мені відомо про Scrum-
проекти, спрямовані на постачання вакцин для дітей, і про
інші, покликані будувати дешеве житло, позбутися дрібної
корупції, ловити жорстоких злочинців, викорінити голод
та відправити людей до інших планет.
І все це — не якісь там фантазії, а цілком дієві плани. Звіс-

но, щоб не сталося помилки, вони потребують перевірки,
адаптації та корекції на кожному кроці, але вони просува-
ються. У всьому світі відбуваються швидкі зміни, набли-
жаючи нас до кращого життя.
Саме це, сподіваюся, ви й винесете із цієї книжки: знання,

що це можливо — ситуацію можна змінювати, а не обов’яз-
ково сприймати як належне.
Мріють усі, але не однаково. Ті, хто бачить сни вночі в запи-
люжених куточках свого розуму, вдень прокидаються і ви-
являють, що це було марнотою; але ті, хто мріє вдень, — не-
безпечні люди, бо можуть програвати свої мрії з відкритими
очима, втілюючи їх.
T. E. Лоуренс, Сім стовпів мудрості4
Не слухайте циніків, які говорять вам, що не можна зробити.

Дивуйте їх тим, що можна.
Scrum прискорює всі людські зусилля. Яким би

не був проект чи проблема, Scrum можна застосувати
в будь-якій сфері для покращення продуктивності та
результатів.
Scrum для шкіл. У Нідерландах дедалі більше вчителів

використовують Scrum для навчання дітей. При цьому
вони спостерігають майже негайне покращення резуль-
татів тестів більш ніж на 10 відсотків. І вони залучають
учнів усіх рівнів підготовки — від професійного до уні-
верситетського.
Scrum для бідності. В Уганді фонд Grameen використо-

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

джерів, структур. Надайте людям свободу робити те, що
вони вважають за найкраще, а також можливість бути
відповідальними за це. Результати вас приємно здивують.
ПОДЯКИ
Будь-який проект не є результатом роботи однієї людини.
Це продукт команди, і ця книжка не виняток.
Перш за все, я б хотів подякувати моєму синові, Джей

Джей Сазерленду. Саме він запропонував мені написали
разом книжку про дійсно дивовижну подорож, у яку Scrum
повів мене кілька років тому. Він хотів перепочити від
десяти років біганини з однієї війни та катастрофи на іншу
для Національного громадського радіо та вважав, що роз-
повісти історію того, як Scrum виник, працює та змінює
світ, буде не лише важливо, але й дуже цікаво. Хоча книга,
яку ви тримаєте в руках, є моєю історією, це водночас про-
дукт багатьох годин спільної праці, і на папір її переніс
саме мій син.
Говард Юн, найрозумніший з літературних агентів, просив

нас думати глибше та масштабніше. Його інтуїція, порада,
мудрість і життєвий досвід не лише дозволили цій книзі
відбутися, але й вивели її на зовсім інший рівень.
Не так часто випадає можливість попрацювати зі справжнім

майстром своєї справи, і мені надзвичайно пощастило з Рі-
ком Горґаном із Crown Publishing Group. Завдяки його
майстерності та ретельності будь-який текст одразу стає
кращим. Він зробив його таким простим. Знімаю капелю-
ха та щиро дякую.
Головний власник продукту Алекс Браун, Джо Джастіс та

решта команди Scrum, Inc. ділилися зі мною важливими
ідеями, своєю невичерпною енергією та величезним до-
свідом.
Подяки 269
Я також хотів би подякувати:
Професорам Гіротаці Такеучі та Ікуджиро Нонаці, чия

робота запалила ідею Scrum і які пізніше стали моїми
добрими друзями.
Моєму товаришеві у створенні Scrum Кену Шваберу, чия

сердита впертість допомогла сформувати цю систему та зро-
бити її силою, якою вона є сьогодні.
Найбільша подяка моїй дружині Арлін. Вона була зі мною

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

власників продукту та команд на планеті, які просто-таки
живуть Scrum кожного дня. Ви робите його живою й пози-
тивною силою, якою він є сьогодні у світі, і я ніколи не пере-
стану дивуватися успіхам, досягнутим вами завдяки цьому.
ДОДАТОК.
ВПРОВАДЖЕННЯ SCRUM — ІЗ ЧОГО ПОЧАТИ
Тепер, коли ви прочитали цю книжку, я розповім, як почати
за допомогою Scrum будь-який проект, у двох словах. Наве-
дений опис процесу доволі загальний, але для початку вам
має бути цілком досить. Цю книжку було написано, щоб
пояснити, чому з’явився Scrum. А додаток у скороченій фор-
мі розповість вам, як він працює.
1. Доберіть власника продукту. Це людина, яка володі-

тиме баченням того, що ви збираєтесь зробити чи ство-
рити, чого досягти. Вона враховуватиме можливі ризики
та винагороди, що можна виконати і до чого є пристрасть.
(Більше див. у розділі 8 «Пріоритети».)
2. Доберіть команду. Це люди, які насправді виконувати-

муть роботу. Команді потрібно мати всі вміння та навич
ки, необхідні для того, щоб узяти бачення власника про-
дукту й перетворити його на реальність. Команди мають
бути невеликими: золоте правило — від 3 до 9 людей.
(Більше див. у розділі 3 «Команди».)
3. Доберіть Scrum-майстра. Ця людина навчатиме решту

команди принципів Scrum та допомагатиме їм позбува-
тися всього, що їх затримує. (Більше див. у розділі 5 «Мар-
нування — це злочин».)
4. Складіть беклог продукту та розставте пріоритети. Це

перелік усього, що потрібно створити чи виконати для
перетворення бачення на реальність. Беклог існує та роз-
вивається протягом усього життєвого циклу продукту —
це його дорожня мапа. У будь-який момент часу беклог
продукту є єдиним кінцевим орієнтиром «всього, що ко-
лись може зробити команда, у порядку пріоритетності».
Існує лише один беклог продукту. Це означає, що власник
Впровадження Scrum — із чого почати 271
продукту повинен приймати рішення щодо розставлення

пріоритетів по всьому спектру. Власник продукту має кон-
сультуватися з усіма зацікавленими особами та коман-
дою, щоб чітко відображувати, що люди хочуть і що мож-
на створити. (Більше див. у розділі 8 «Пріоритети».)
5. Удоскональте та оцініть беклог продукту. Важливо,

щоб люди, які насправді виконуватимуть завдання із
цього переліку, оцінювали, скільки зусиль їм на це зна-
добиться. Команда має дивитись на кожен пункт пере-
ліку завдань і бачити, чи дійсно його можна виконати.
Чи достатньо для цього інформації? Чи не надто великий
обсяг робіт для оцінки? Чи є визначення готовності —
загальноприйняті стандарти, яких слід дотриматися, щоб
перевести завдання в колонку «Виконано»? Чи створює
це видиму цінність? Кожний пункт має бути готовим для
показу, демонстрації, в ідеалі — потенційно готовим до
передачі клієнтові. Не оцінюйте завдання в годинах, бо
люди абсолютно не вміють цього робити. Оцінюйте за
порівняльним розміром: малі, середні чи великі. Або,
навіть краще, використовуйте послідовність Фібоначчі
та оцінюйте кожний пункт у балах: 1, 2, 3, 5, 8, 13, 21 тощо.
(Більше див. у розділі 6 «Плануйте реальність, а не фан-
тазію».)
6. Проведіть планування спринту. Це перша зі Scrum-зу-

стрічей. Команда, Scrum-майстер та власник продукту
збираються разом і складають план спринту. Спринти
завжди мають фіксовану тривалість, меншу за місяць.
Більшість людей сьогодні використовує одно- чи двотиж-
неві спринти. Члени команди дивляться на верхню части-
ну беклогу та прогнозують, скільки завдань із неї вони
можуть виконати в цьому спринті. Якщо команда вже
пройшла кілька спринтів, вони мають ураховувати кіль-
кість балів, які отримали за попередній спринт. Ця кіль-
кість відома як швидкість команди. Scrum-майстер та
272 Впровадження Scrum — із чого почати
команда повинні намагатися кожного спринту збільшу-

вати цю кількість. Це ще одна можливість для команди
та власника продукту переконатись, що всі чітко розумі-
ють значення цих пунктів плану для реалізації спільного
бачення. Також під час цієї зустрічі всі мають узгодити
мету спринту — чого вони хочуть ним досягти.
Одним зі стовпів Scrum є те, що, як тільки команда

візьме на себе зобов’язання виконати можливе, на їхню
думку, протягом цього спринту, беклог блокується. Ні
змінити, ні додати вже нічого не можна. Команді слід
дозволити автономно працювати протягом усього сприн-
ту аж до повного виконання запланованого. (Більше
див. у розділі 4 «Час» та розділі 6 «Плануйте реаль-
ність, а не фантазію».)
7. Зробіть робочий процес видимим. Найпоширенішим

способом досягти цього в Scrum є створити Scrum-до-
шку з трьома колонками: «Виконати», «Виконується»,
«Виконано». Завдання, які потрібно виконати, показу-
ються стікерами. Команда переміщує їх по Scrum-дошці
одне за одним у міру завершення завдань.
Іншим способом зробити все видимим є створити діагра-

му згоряння завдань. На одній її осі буде кількість
балів, набраних командою за спринт, а на другій — кіль-
кість днів. Кожного дня Scrum-майстер підраховує кіль-
кість балів виконаних завдань і відзначає її на діаграмі
згоряння. В ідеалі там має спостерігатись різке зниження
кривої, що вестиме до нуля балів в останній день спринту.
(Більше див. у розділі 7 «Щастя».)
8. Щоденний стендап. Це серце всього Scrum. Кожного

дня, в один і той самий час, не більш ніж на п’ятнадцять
хвилин, команда та Scrum-майстер збираються разом
і відповідають на три питання:
• Що ви робили вчора, щоб допомогти команді завер-

шити спринт?
• Що ви робитимете сьогодні, щоб допомогти команді
завершити спринт?
• Чи є якісь перешкоди, що заважають вам чи команді
досягти мети спринту?
І це все. На цьому зустріч закінчується. Якщо вона за-

ймає більш ніж п’ятнадцять хвилин, то ви робите щось
не так. Насправді вона допомагає всім членам команди
чітко розуміти перебіг спринту та стадії розв’язання
його завдань. Чи всі завдання буде виконано вчасно?
Чи є можливості допомогти іншим членам команди
в подоланні перешкод? Завдання не розподіляються
згори — команда є автономною й робить усе сама. Не-
має жодного детального звітування перед начальством.
За усунення перешкод для прогресу команди чи яки-
хось перепон відповідає Scrum-майстер. (Більше див.
у розділі 4 «Час» та розділі 6 «Плануйте реальність, а не
фантазію».)
9. Огляд, або демонстрація спринту. Це зустріч, під

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

визначенню готовності. Те, що цілком та повністю го-
тове і може бути здане без жодної додаткової роботи.
Це може бути не повністю завершений продукт, але
точно повністю готова його характеристика. (Більше
див. у розділі 4 «Час».)
10. Ретроспектива спринту. Спочатку члени команди

показують, чого вони досягли протягом останнього сприн-
ту (що в них «Виконано» і може потенційно бути пред-
ставлене клієнтам для відгуку). А потім вони сідають
і думають, що пройшло добре, що могло пройти краще
і що можна покращити в наступному спринті. Яке по-
кращення робочого процесу вони як команда здатні за-
провадити просто зараз?
Щоб бути ефективною, ця зустріч потребує певної емо-

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

узгодити одне покращення процесу, яке вони впрова-
дять у наступному спринті. Це покращення процесу, яке
іноді називають кайдзен, слід внести в беклог наступно-
го спринту разом із критеріями прийнятності. Так ко-
манда зможе легко бачити, чи дійсно вони впровадили
покращення і який вплив це мало на швидкість. (Більше
див. у розділі 7 «Щастя».)
11. Одразу починайте наступний спринт, ураховуючи досвід

команди щодо перешкод та покращень процесу.
ПРИМІТКИ
РОЗДІЛ 1
1. Eggen, Dan, and Griff Witte. “The FBI’s Upgrade That Wasn’t;
$170 Million Bought an Unusable Computer System.” Washing
ton Post, 18 серпня 2006 р.: A1.
2. Status of the Federal Bureau of Investigation’s Implementation

of the Sentinel Project. US Department of Justice, Office of
the Inspector General. Report 11-01, жовтень 2010 р.
3. Там само.
4. Ohno, Taiichi. Toyota Production System: Beyond Large-

scale Production (Cambridge, MA: Productivity, 1988).
5. Roosevelt, Theodore. “Citizenship in a Republic.” Промова у Сор-

бонському університеті, Париж, Франція, 23 квітня 1910 р.
РОЗДІЛ 2
1. Takeuchi, Hirotaka, and Ikujiro Nonaka. “The New New Product

Development Game.” Harvard Business Review (січень—
лютий 1986 р.): 285-305.
2. Schwaber, Ken. “Scrum Development Process,” у збірці

OOPSLA Business Object Design and Implementation Work-
shop, J. Sutherland, D. Patel, C. Casanave, J. Miller, and
G. Hollowell, eds. (London: Springer, 1997).
3. Deming, W. Edwards. “To Management.” Промова в Конфе-

ренц-центрі на горі Хаконе, Японія, 1950 р.
276 Примітки
РОЗДІЛ 3
1. Takeuchi, Hirotaka, and Ikujiro Nonaka. “The New New

Product Development Game.” Harvard Business Review
(січень—лютий 1986 р.): 285—305.
2. MacArthur, Douglas. “The Long Gray Line.” Промова в Ака-

демії Вест-Пойнт, штат Нью-Йорк, 1962 р.
3. Там само.
4. Feynman, Richard. Report of the Presidential Commission on

the Space Shuttle Challenger Accident, Appendix F — Personal
Observations on Reliability of Shuttle. Звіт (1986).
5. Warrick, Joby, and Robin Wright. “U.S. Teams Weaken In-

surgency in Iraq.” Washington Post, 6 вересня 2006 р.
6. Flynn, Michael, Rich Jergens, and Thomas Cantrell. “Employing

ISR: SOF Best Practices.” Joint Force Quarterly 50 (3-й квар-
тал 2008 р.): 60.
7. Lamb, Christopher, and Evan Munsing. “Secret Weapon: High-

value Target Teams as an Organizational Innovation.” Institute
for National Strategic Studies: Strategic Perspectives, no. 4 2011.
8. Brooks, Frederick P. The Mythical Man-Month: Essays on

Software Engineering (Reading, MA: Addison-Wesley, 1975).
9. Cowan, Nelson. “The Magical Number 4 in Short-Term Me

mory: A Reconsideration of Mental Storage Capacity.”
Behavioral and Brain Sciences 24 (2001): 87—185.
10. Nisbett, Richard, Craig Caputo, Patricia Legant, and Leanne Mare-
cek. “Behavior as Seen by the Actor and as Seen by the Observer.”
Journal of Personality and Social Psychology 27.2 (1973): 154—64.
Примітки 277
11. Milgram, Stanley. “The Perils of Obedience.” Harper’s Maga-

zine, 1974.
РОЗДІЛ 4
1. Marvell, Andrew. “To His Coy Mistress,” (1681).
РОЗДІЛ 5
1. Ohno, Taiichi. Toyota Production System: Beyond Large-

scale Production (Cambridge, MA: Productivity, 1988).
2. Strayer, David, Frank Drews, and Dennis Crouch. “A Com-

parison of the Cell Phone Driver and Drunk Driver.” Human
Factors 48.2 (літо 2006): 381—91.
3. Sanbonmatsu, D. M. D. L. Strayer, N. Medeiros-Ward, and

J. M. Watson. “Who Multi-Tasks and Why? Multi-Tasking
Ability, Perceived Multi-Tasking Ability, Impulsivity, and Sen-
sation Seeking.” PLoS ONE (2013) 8(1): e54402. doi:10.1371/
journal.pone.0054402.
4. Weinberg, Gerald M. Quality Software Management (New York:

Dorset House, 1991).
5. Pashler, Harold. “Dual-task Interference in Simple Tasks: Data and

Theory.” Psychological Bulletin 116.2 (1994): 220—44.
6. Charron, Sylvain, and Etienne Koechlin. “Divided Represen-

tation of Concurrent Goals in the Human Frontal Lobes.”
Science 328.5976 (2010): 360—63.
7. Wilson, Glenn. The Infomania Study. Issue brief, http://www.

drglennwilson.com/ Infomania_experiment_for_HP.doc.
8. Womack, James P. Daniel T. Jones, and Daniel Roos. The

Machine That Changed the World: The Story of Lean Produc-
tion (New York: Harper Perennial, 1991).
9. Avnaim-Pesso, Liora, Shai Danziger, and Jonathan Levav.

“Extraneous Factors in Judicial Decisions.” Proceedings of
the National Academy of Sciences of the United States of
America. 108.17 (2011).
10. Vohs, K. R. Baumeister, J. Twenge, B. Schmeichel, D. Tice, and

J. Crocker. Decision Fatigue Exhausts Self-Regulatory Resources —
But So Does Accommodating to Unchosen Alternatives (2005).
РОЗДІЛ 6
1. Cohn, Mike. Agile Estimation and Planning (Upper Saddle

River, NJ: Prentice Hall 2005).
2. Bikhchandani, Sushil, David Hirshleifer, and Ivo Welch. “A Theory

of Fads, Fashion, Custom and Cultural Change as Informational
Cascades.” Journal of Political Economy 100.5 (1992): 992—1026.
3. Thorndike, Edward Lee. “A Constant Error in Psychological

Ratings.” Journal of Applied Psychology 4.1 (1920): 25—29.
4. Dalkey, Norman, and Olaf Helmer. “An Experimental Appli-

cation of the Delphi Method to the Use of Experts.” Manage-
ment Science 9.3 (квітень 1963 р.): 458—67.
РОЗДІЛ 7
1. Lyubomirsky, Sonja, Laura King, and Ed Diener. “The Benefit

of Frequent Positive Affect: Does Happiness Lead to Success?”
Psychological Bulletin 131.6 (2005): 803—55.
2. Spreitzer, Gretchen, and Christine Porath. “Creating Sustain-

able Performance.” Harvard Business Review (січень—лютий
2012 р.): 3—9.
3. Там само.
4. The Fool, King Lear, act 1, scene 4.
РОЗДІЛ 8
1. Shook, John. “The Remarkable Chief Engineer.” Lean Enter-

prise Institute, 3 лютого 2009.
2. Ford, Daniel. A Vision So Noble: John Boyd, the OODA Loop

and America’s War on Terror (CreateSpace Independent, 2010).
3. Boyd, John. New Conception. 1976.
4. Там само.
РОЗДІЛ 9
1. Shannon, Brad. “McKenna, Inslee Outline Plans to Bring Efﬁcien-

cy to Government.” The Olympian, 6 жовтня 2012 р.
2. Valve Handbook for New Employees (Bellevue, WA: Valve

Press, 2012).
3. Там само.
4. Lawrence, T. E. Seven Pillars of Wisdom: A Triumph (London:

Cape, 1973).
Популярне видання
САЗЕРЛЕНД Джефф
Scrum. Навчись робити вдвічі більше за менший час
Головний редактор С. І. Мозгова

Відповідальний за випуск А. І. Кривко
Редактор Р. А. Трифонов
Художній редактор Ю. О. Сорудейкіна
Технічний редактор В. Г. Євлахов
Коректор А. І. Кривко
Підписано до друку 17.11.2021.

Формат 60х90/16. Друк офсетний.
Гарнітура «Georgia». Ум. друк. арк. 17,5.
Наклад 3500 пр. Зам. № .
Книжковий Клуб «Клуб Сімейного Дозвілля»

Св. № ДК65 від 26.05.2000
61001, м. Харків, вул. Б. Хмельницького, буд. 24
E-mail: cop@bookclub.ua
Віддруковано у АТ «Харківська книжкова фабрика “Глобус”»

61011, м. Харків, вул. Різдвяна, 11.
Свідоцтво ДК № 7032 від 27.12.2019 р.
www.globus-book.com

Scrum 221123 091803

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Scrum 221123 091803

Uploaded by

Copyright:

Available Formats

SCRUM

THE ART OF DOING

Жодну з частин цього видання

Публікується з дозволу автора та його літературних агентів ROSS YOON

Переклад з англійської Ярослава Лебеденка

Дизайнер обкладинки Влад Прокопів

© Jeff Sutherland and Scrum, Inc.,

Дивовижно… Це повністю переверне уявлення лю-

Джефф Сазерленд розписав суть Scrum для широких мас.

Гіротака Такеучі, професор управлінських практик

Джефф Сазерленд є великим майстром творення

не розкриває всієї дії Scrum. Якщо ви не потроїте результати

Скотт Максвелл, засновник та старший виконавчий

Джефф Сазерленд скористався очевидними, але рідко за-

Джеффрі Пфеффер, професор Стенфордської школи

Таємницею Сазерленда щодо подолання професійних та

Арнольд В. Стронг, генеральний директор

Ця оманливо проста система є найпотужнішим з усіх

Лео Бабаута, творець блогу ZenHabits.net

Розділ 1. Спосіб, у який працює світ, — недосконалий....... 11

Розділ 2. Витоки Scrum.......................................................... 37

Розділ 5. Марнування — це злочин.....................................107

Розділ 6. Плануйте реальність, а не фантазію...................137

Розділ 8. Пріоритети............................................................ 203

Розділ 9. Змінюйте світ........................................................ 237

Додаток. Впровадження Scrum — із чого почати............. 270

За участю Кена Швабера я створив Scrum іще двадцять років

Щоб подолати ці проблеми, у 1993 році я винайшов новий

компаніям за межами світу високих технологій. У ній я роз-

Дочитайте цю книжку до кінця. Думаю, ви зрозумієте, як

Джефф Джонсон абсолютно не чекав від того дня нічого

Джефф прийшов у Бюро лише за сім місяців до того, піддав-

Джефф та його бос вирішили визнати свою поразку і згор-

Проект являв собою довгоочікувану комп’ютерну систему,

тримка слідчих справ» і працювала на величезних ЕОМ, що

Коли якийсь агент ФБР хотів щось зробити — по суті, будь-

Якщо запит затверджували, перший примірник повертався

Після терактів 11 вересня було створено спеціальну комісію

системи ФБР призвів до того, що такий доступ великою мірою

До трагічних подій 11 вересня в ФБР навіть не думали про

Коли сенатори почали ставити Бюро незручні запитання,

Але три роки потому програму згорнули. Вона просто не пра-

У нас була інформація, що могла зупинити 11 вересня. Вона

Показово, що багато людей, які працювали у ФБР на час про-

У 2005 році ФБР анонсувало запуск нової програми «Варто-

Що тут могло піти не так? У березні 2010 року відповідь ляг-

І Джонсон мав щось із цим робити.

Що ж тоді пішло не так і як ситуацію вдалося виправити?

Головною проблемою був спосіб роботи. Саме так, спосіб

чином ми вважаємо за потрібне виконувати роботу, бо нас

Коли чуєш, що сталося, спершу все здається цілком логіч-

Технічний проект Випробування

Такі графіки називаються діаграмами Ґантта, на честь аме-

Генрі Ґантт винайшов свої знамениті діаграми приблизно

А просто це здається дуже заманливим: уся робота, яку потріб-

Ця невдала схема нагадує звіти, які отримувало радянське

Колись давно, коли я був кадетом Військової академії Вест-­

Отже, Lockheed представив ФБР усі ці гарненькі графіки,

Проте коли Джефф та його бос, голова інформаційної служ-

Чед доповів генеральному інспекторові Міністерства юстиції,

НОВИЙ СПОСІБ МИСЛЕННЯ

меншою кількістю людей та за менший час може дати більший

Двадцять років тому я перебував у справжньому розпачі, на-

Колись давно, коли я був кадетом Військової академії Вест-