«Scrum»

Scrum (fb2) - Scrum [Навчись робити вдвічі більше за менший час] (пер. Ярослав Лебеденко) 1661K скачать: (fb2) - (epub) - (mobi) - Джефф Сазерленд

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

© Jeff Sutherland and Scrum, Inc., 2014

© Hemiro Ltd, видання українською мовою, 2016

© Книжковий Клуб «Клуб Сімейного Дозвілля», переклад і художнє оформлення, 2016

Відгуки про книжку

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

Брайан Трейсі, автор бестселера «Зроби це зараз»

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

Майкл Менґі, старший віце-президент з інтерактивних технологій Social@Ogilvy

Джефф Сазерленд розписав суть Scrum для широких мас. Ця книжка підносить Scrum від простого інструмента виправлення проблем до способу життя.

Гіротака Такеучі, професор управлінських практик Гарвардської школи бізнесу

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

Скотт Максвелл, засновник та старший виконавчий директор OpenView Venture Partners

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

Джеффрі Пфеффер, професор Стенфордської школи бізнесу та співавтор книжки «Від знання до справи»

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

Арнольд В. Стронг, генеральний директор BrightNeighbor.com та полковник запасу армії США

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

Лео Бабаута, творець блогу ZenHabits.net

Scrum Навчись робити вдвічі більше за менший час

Передмова

Чому Scrum?

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

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

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

Джефф Сазерленд

Розділ 1. Спосіб, у який працює світ, – недосконалий

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

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

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

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

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

Якщо запит затверджували, перший примірник повертався згори з присвоєним йому номером. Ви здивовані? Так, документообіг ФБР вівся за допомогою простого номера, проставленого на аркуші. Цей метод був настільки застарілим та уразливим, що саме на нього поклали частину провини за те, що Бюро не змогло додати два і два й виявити членів «Аль-Каїди», які в’їхали до країни за кілька тижнів чи місяців до 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

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

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

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

Тоді я був просто молодим пілотом реактивного літака, який сподівався пережити свою сотню завдань. Я не знав, що досвід польотів та тренувань, які я пройшов щодо вміння думати та діяти в смертельно небезпечних ситуаціях, сформує спосіб моєї роботи до кінця життя. Я прибув до В’єтнаму в 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: «…м’яч пасується всередині команди, яка рухається полем як єдине ціле»[6].

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

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

Можливості цієї нової форми управління проектами так мене надихнули, що вся моя майбутня робота зосередилась на вдосконаленні Scrum для компаній. У 1995 році разом із Кеном Швабером я презентував на дослідницькій конференції Асоціації обчислювальної техніки працю під назвою «Спосіб розробки SCRUM», яка систематизувала ці практики. Після того ми відмовилися від слів великими літерами та дещо допрацювали цю ідею, але основні принципи залишаються незмінними; а компанії, які прийняли цей спосіб, зазвичай отримують негайні переваги[7].

Перевіряйте та адаптуйте

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

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

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

Відомий виступ Демінга перед керівниками японських підприємств у 1950 році. Серед слухачів були й такі люди, як Акіо Моріта, засновник компанії Sony. Демінг тоді сказав їм:

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

Якщо лише говорити про це, нічого не вийде. Важливо діяти[8].

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

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

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

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

Змінюйтесь або помріть

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

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

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

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

Шу-Ха-Рі

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

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

У стані Ха, опанувавши форми, ви можете робити щось нове. Наприклад, додавати нові повороти до ваших танцювальних па.

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

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

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

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

Що треба запам’ятати

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

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

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

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

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

Розділ 3. Команди

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

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

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

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

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

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

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

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

Виявляється, відповідь є ствердною.

У своїй оригінальній праці «Розробка нового продукту», де описане те, що пізніше стало Scrum, професори Такеучі та Нонака дали характеристики команд, які вони бачили в найкращих компаніях світу.

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

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

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

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

Довга сіра лінія

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

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

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

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

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

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

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

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

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

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

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

Сьогодні моя остання вечірня повірка разом із вами. Але я хочу, щоб ви знали: коли я піду назавжди, мої останні свідомі думки будуть про кадетський корпус, знову і знову[12].

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

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

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

– Оця рота, друга з кінця. Вони відрізнялися від усіх решти. Інші маршували, а вони, здавалось, не торкалися землі. Хто це був?

– Це була моя рота. – сказав я йому. – Ці люди ховали генерала Мак-Артура.

Моя рота досягла надзвичайності.

Scrum під час революцій

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

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

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

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

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

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

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

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

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

Сьогодні Scrum використовується в усіх сферах роботи Національного громадського радіо – від веб-дизайну до журналістського збирання даних та створення нових передач. Використовують його також команди Chicago Tribune, New York Times, Washington Post і ProPublica. Адже, коли дедлайни підпирають, швидкість потрібна всім.

Одна команда для всієї роботи

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

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

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

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

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

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

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

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

Scrum під час війни

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

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

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

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

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

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

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

Міжвідомчі групи дозволили позбутись організаційних «швів» між різними силами коаліції в Іраку, приставивши до пріоритетних цілей «незмигне око»… Адже передача обов’язків між підрозділами та організаціями являла собою «мигання», під час якого сповільнювалась динаміка і ціль могла втекти[15].

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

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

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

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

Розмір має значення, але не так, як ви гадаєте

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

У розробці програмного забезпечення є термін «закон Брукса», уперше виведений Фредом Бруксом ще в 1975 році у його новаторській книжці «Міфічна людина-місяць». Якщо стисло, закон Брукса каже: «Додавання людських ресурсів до простроченого проекту програмного забезпечення затримує його ще більше»[17]. Слушність цього підтверджено багатьма дослідженнями. Зокрема, вивченню того, скільки часу займає робота і чому, присвятив своє життя Лоренс Патнем – легендарна фігура в розробці програмного забезпечення. Його праці незмінно демонструють, що проекти, в яких брали участь двадцять чи більше людей, потребували більших зусиль, ніж ті, де виконавців було п’ятеро чи менше. Причому не трохи, а набагато. Великій команді зазвичай потрібно в п’ять разів більше годин, ніж малій. Патнем спостерігав це знову й знову, а в середині 1990-х років вирішив спробувати провести широкомасштабне дослідження, щоб визначити ідеальну чисельність команди. Для цього він переглянув 491 проект середнього розміру сотень різних компаній. Усе це були проекти, що вимагали створення нових продуктів чи властивостей, а не перепризначення старих версій. Він розподілив ці проекти за розміром команди й одразу дещо помітив. Як тільки чисельність команд перевищувала вісім людей, виконання роботи починало займати в них значно більше часу. Групи, що нараховували від трьох до семи осіб, потребували для виконання однакового обсягу роботи – приблизно 25 відсотків зусиль груп, де було від дев’яти до двадцятьох виконавців. Цей результат повторювався в сотнях проектів. Те, що дуже великі групи роблять менше, здається, є залізним правилом людської природи.

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

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

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

Якщо ви хочете розрахувати вплив розміру групи, візьміть кількість людей у команді, помножте її на цю саму кількість мінус один і поділіть на два. Кількість комунікаційних каналів = n (n–1)/2. Таким чином, наприклад, якщо у вас є п’ятеро людей, ви маєте десять каналів. Шість людей – п’ятнадцять каналів. Сім – двадцять один. Вісім – двадцять вісім. Дев’ять – тридцять шість. Десять – сорок п’ять. Наші мізки просто не можуть дати раду зі стількома людьми за раз. Ми не знаємо, що вони всі роблять. І, намагаючись це визначити, ми сповільнюємось.

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

Не робіть цієї помилки. Команди мають залишатись невеликими.

Scrum-майстер

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

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

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

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

Шукайте проблему не в гравцях, а в грі

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

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

Захопливі матеріали на цю тему наведено в збірці «Індукція. Процеси припущення, навчання та відкриття» Джона Г. Голланда та ін. Одна з робіт, процитована в цій книжці, опублікована ще на початку 1970-х років, тому новою її не назвеш. Це стара ідея, яка повторюється знову й знову. І пов’язана вона з тим, що змушує людей діяти в той чи інший спосіб. У будь-якому разі, результати дослідження доволі цікаві. Автори зібрали групу студентів коледжу (хлопців) і поставили їм два прості питання: «Чому ви обрали саме цей предмет спеціалізації?» і «Чому ви зустрічаєтеся саме із цією дівчиною?» А потім дослідники попрохали студентів відповісти на ті самі питання щодо їхнього найкращого друга. І тут виявилися важливі відмінності. Коли студенти говорили про себе, то говорили більше не про себе особисто, а про тему питання. Наприклад, про свій головний предмет вони казали: «Хімія – то високооплачувана галузь», а про дівчину: «Вона дуже приємна людина». Натомість, говорячи про своїх друзів, вони казали про здібності та потреби цих хлопців – щось на кшталт: «Йому завжди легко давалася математика» або «Він доволі слабохарактерний, і йому потрібна владна жінка»[19].

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

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

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

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

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

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

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

Майже всі й продовжували, завдаючи останнього удару струмом тому, хто так страшно кричав, а потім затихав. Підсумки своїх спостережень Мілґрем підбив у статті 1974 року «Небезпеки покори»:

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

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

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

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

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

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

Другий приклад, який спадає мені на думку, дещо відрізняється. Він нагадує мені, наскільки ж людям властиво шукати винного в проблемі, а не її розв’язання. Він про те, як діють венчурні капіталісти, з якими я працюю, коли вирішують інвестувати в ту чи іншу компанію. Уперше приєднавшись до OpenView Venture Partners, я був здивований, що, на відміну від багатьох венчурних фірм, їм насправді байдуже, як компанія витрачала свої гроші до їхньої інвестиції. Минуле їх не турбує. OpenView вирішує, чи варто вкладати в компанію гроші, виходячи з її поточного стану, – усе інше не важить. Вони лише хочуть знати, як збираються витрачати їхні гроші. Як компанія витрачала гроші інших, їх не обходить. Значення для них має лише майбутнє – лише рішення.

Досягнення надзвичайності

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

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

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

Що треба запам’ятати

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

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

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

Орієнтуйтесь на багатофункціональність. Команда повинна мати всі потрібні вміння та навички для виконання проекту, чи то розробка програмного забезпечення Salesforce.com, чи захоплення терористів в Іраку.

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

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

Розділ 4. Час

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

Отож, хоча нам сонце не припнути, Ми поганяти можемо його[21].

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

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

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

Спринт

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

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

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

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

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

– Чудово, – відповів він. – Що ж тоді ви збираєтесь мені показувати?

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

– Гаразд, – сказав він. – Робіть це.

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

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

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

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

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

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

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

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

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

Як я вже згадував, у першому Scrum ми використовували чотиритижневі спринти. Десь під кінець першого спринту ми відчули, що просуваємось недостатньо швидко і можемо робити більше. Тоді ми якраз дивилися відео, як All Blacks виконують хаку, а потім проривають оборону супротивника. «Чому ми не такі? – питали ми себе. – Чому не маємо такого бойового духу?» Ми вирішили поставити собі за мету стати не просто доброю командою, а найкращою. Як це можна було зробити? І знову відповідь полягала в простій речі, яку ми поцупили в когось іншого, – щоденних зустрічах.

Щоденні стендапи

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

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

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

1. Що ви робили вчора, щоб допомогти команді завершити спринт?

2. Що ви робитимете сьогодні, щоб допомогти команді завершити спринт?

3. Які перешкоди стоять на шляху команди?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Моє стандартне звернення до команд, великих чи малих, є таким: «Ви хочете вічно пасти задніх? Така у вас мотивація в житті? Вибір за вами – ніхто вас ні до чого не змушує». Команда сама має захотіти стати видатною.

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

Час і ще раз час

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

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

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

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

Ми всі посміялись і почали лякати Елко нашими страшними ремонтними байками.

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

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

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

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

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

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

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

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

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

Що треба запам’ятати

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

Демонструйте або помріть. Наприкінці кожного спринту майте щось виконане – щось придатне для використання (польоту, поїздки, чого завгодно).

Викиньте свої візитівки. Посади є показниками конкретного статусу. Нехай за вас говорять ваші справи, а не додаток до імені.

Усі разом знають усе. Комунікаційне насичення прискорює роботу.

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

Розділ 5. Марнування – це злочин

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

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

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

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

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

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

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

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

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

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

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

Оно говорив про три різні типи марнування. Він використовував японські слова: мурі – марнування через непродуманість; мура – марнування через непостійність; муда – марнування через непотрібність результатів. Ці ідеї чітко співвідносяться з циклом Демінга, про який я писав раніше: Плануйте, Робіть, Перевіряйте, Дійте. Плануйте означає уникайте мурі. Робіть означає уникайте мура. Перевіряйте означає уникайте муда. Дійте означає волю, мотивацію та рішучість зробити все це. Я збираюсь розглянути ці кроки один за одним, вказуючи на те, чого слід уникати – від марнування ресурсів до марнування через неправильну роботу з першого разу, марнування через надто важку роботу та емоційного марнування через необґрунтовані очікування[22].

Одна справа за раз

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

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

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

Ось що заповідає нам багатозадачність.

А ось цитата з моєї улюбленої статті з цього приводу:

…навіть коли учасники дорожнього руху дивляться на дорогу, розмовляючи по мобільному, вони часто не «бачать» об’єктів навколо себе через відвернення уваги від зовнішнього оточення та спрямування її на внутрішній когнітивний контекст, пов’язаний із телефонною розмовою[23].

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

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

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

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

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

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

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

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

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

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

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

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

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

Отже, повернімося до роботи. Що це означає, коли ви намагаєтесь виконати якесь завдання? Візьмімо для прикладу типову команду. Цього року вони вирішили виконати три проекти. Назвемо їх A, B та C. Причому вони розпланували свій рік зі словами, що попрацюють трохи над одним проектом, потім над другим, а там і над третім, так що їхній календар почав виглядати, як показано на с. 117.

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

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

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

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

Визначення пріоритетів серед проектів

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

Насправді кілька досліджень показали, що багатозадачність не лише марнує ваш час, але й робить вас дурними. Дослідження, проведене в Університеті Лондона ще в 2005 р.[28], (звісно, дуже маленьке й неперевірене, та все ж…), оцінило, наскільки дурними може зробити вас багатозадачність. Психіатр Ґленн Вілсон узяв чотирьох чоловіків та чотирьох жінок і перевірив їхній коефіцієнт розумового розвитку в умовах спокою та в умовах відволікання (телефонних дзвінків, надходження електронних листів). Під час тестів він вимірював електропровідність шкіри об’єктів, пульс та кров’яний тиск. Цікаво, що в умовах відволікання середні розумові показники об’єктів падали більш ніж на десять пунктів. А ще цікавіше, що це падіння більше виявлялось у чоловіків, ніж у жінок (мабуть, із певних причин жінки більш пристосовані до відволікання).

Зроблене наполовину – не зроблене взагалі

Як я вже згадував, 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, а двигун гудів у правильній тональності. Вони перевіряли точність допасування всіх частин і вважали себе не промисловцями, а ремісниками, майстрами виготовлення гарних речей. Загалом це чудово, коли ви виготовляєте кілька машин, але коли їх мільйони, це веде лише до зайвих витрат. Як зауважив у своїй книжці Вумек:

…німецький завод докладав більше зусиль для виправлення проблем, ніж японському було потрібно для виготовлення майже ідеального авто відразу[29].

Ви прочитали правильно. Німці витрачали більше часу на доведення до ладу автівки, яку щойно виготовили, ніж японці на виготовлення нової. Це і є причиною, чому 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 була схожа на багато інших венчурних компаній. У її корпоративну культуру було міцно вбудоване очікування, що люди мають сидіти на роботі до пізньої ночі, а також на вихідних. Це були енергійні, амбітні люди, але вони швидко вигоряли, впадали в депресію та деморалізувались. Обстановка була такою напруженою, що деякі співробітники не могли більше її витримувати та звільнялись.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Зовсім нещодавно це продемонстрував інший цікавий експеримент. Група дослідників прагнула з’ясувати, як приймання рішень впливає на самоконтроль. Тому вони зібрали типових об’єктів психологічних досліджень – студентів університету – та провели із частиною з них сеанс прийняття низки рішень. Зокрема, цим студентам представили різні товари та попросили вибрати ті, які їм більше сподобаються. Їх попросили уважно подумати перед цим, бо наприкінці експерименту вони отримають подарунок, який залежатиме від їхніх преференцій. Іншій частині студентів жодних рішень приймати не доводилось[31].

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

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

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

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

Будьте розсудливі

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

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

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

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

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

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

Потік

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

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

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

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

Що треба запам’ятати

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

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

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

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

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

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

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

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

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

Розділ 6. Плануйте реальність, а не фантазію

«Слухай, Джеффе, у нас проблема!»

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

– Хто з вас насправді все це прочитав? – спитав я.

А у відповідь – тиша.

– Але послухайте, – звернувся я до одного з менеджерів, – ви ж це підписували. Ось ваш підпис. Невже ви цього не читали?

Знову незручна тиша.

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

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

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

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

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

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

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

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

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

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

– Гаразд, – спитав Брент. – Що нам потрібно зробити спочатку?

Десь із п’ятеро співробітників висловили свої думки.

– А потім?

Висловились іще п’ятеро, запропонувавши цього разу інші ідеї.

– А потім?

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

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

Планування весілля

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

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

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

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

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

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

То як це зробити?

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

• наречена та наречений

• квіти

• запрошення

• церква

• зала для прийому гостей

• частування

• священик

• сукня

• обручки

• музика (ді-джей чи оркестр)

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

• наречена та наречений

• священик

• обручки

• зала для прийому гостей

• запрошення

• частування

• музика

• сукня

• квіти

• церква

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

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

Розмір має значення, але лише відносно

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

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

• лабрадор-ретривер

• тер’єр

• данський дог

• пудель

• такса

• німецька вівчарка

• ірландський сетер

• бульдог

Після цього його питання почали звучати так: «Гаразд, ця проблема – це в нас такса чи данський дог? Якщо та була таксою, то ця має бути розміром з лабрадора, чи не так?» А потім команди проглядали всі моменти, які мали розробити, й оцінювали їх за розмірами собак. Трохи згодом Майк сказав: «А давайте надамо кожній породі цифрове значення. Так простіше. Такса в нас буде одиниця, дог – тринадцять. Тоді лабрадор стане п’ятіркою, а бульдог – трійкою»[32].

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

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

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

Послідовність Фібоначчі: усе навколо нас

• Послідовність Фібоначчі – це схема, де наступне число є сумою двох попередніх:

0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55…

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

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

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

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

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

Таке групове оцінювання виходить значно точнішим за індивідуальне.

Дельфійський оракул

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

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

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

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

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

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

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

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

Боротися з нею лоб у лоб немає сенсу – це все одно, що боротися із силою тяжіння.

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

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

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

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

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

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

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

Дослідники зібрали ці дані й роздали їх усім експертам, запитавши, скільки потрібно бомб тепер? Цього разу діапазон склав від 89 до 800 штук. Вони зробили це знову. І знову. Розбіжність результатів продовжувала звужуватись. Урешті-решт, вона скоротилась остаточно, склавши від 167 до 360 необхідних ядерних зарядів.

Здатність відсіяти неймовірно широкий діапазон оцінок (із 10 000 до приблизно 200 відсотків) є надзвичайно потужним інструментом для політики. Вона дозволяє досягти загальної згоди експертів, не турбуючись про можливі відхилення в той чи інший бік. Цей інструмент є настільки ефективним, що й досі використовується корпорацією Rand. Одним із нещодавніх прикладів було застосування дельфійського методу в 2011 році для оцінки шансів Сполучених Штатів на успіх в афганському конфлікті. Прогнози, якщо вам цікаво, були не райдужні.

Планувальний покер

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

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

Ідея тут проста. Усім «гравцям» дають по колоді карт, на яких зображені оці цікаві числа з послідовності Фібоначчі: 1, 3, 5, 8, 13 і т. д. Кожне завдання, що потребує оцінки, по черзі викладається на стіл. Тоді всі витягають карту, яка, на їхню думку, відображує правильну кількість зусиль, і кладуть її на стіл цифрою донизу. Після цього всі одночасно відкривають свої карти. Якщо різниця значень не перевищує двох карт (скажімо, п’ятірка, дві вісімки та тринадцятка), то команда просто виводить середнє арифметичне (у цьому випадку 6,6), переходячи до наступного завдання. Пам’ятайте: ми говоримо про оцінки, а не залізні графіки. Причому оцінки невеликих частин проекту.

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

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

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

Я засвоїв це на власному гіркому досвіді, коли працював у Пенсильванії з компанією онлайнових продажів GSI Commerce. Пізніше їх купила 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. Щастя

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

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

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

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

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

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

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

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

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

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

Щастя – це успіх

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

Щасливі співробітники більше продають, приносять більше прибутків і менше витрат, рідше змінюють місце роботи, здоровіші й довше працюють. Або, як ідеться у статті 2005 року, де проведено мета-аналіз 225 досліджень із понад 275 000 учасників:

Щастя веде до успіху ледь не в кожній сфері нашого життя, зокрема в шлюбі, здоров’ї, товариських стосунках, громадській діяльності, творчості, а особливо в роботі, кар’єрі та бізнесі[36].

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

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

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

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

Розрахунок щастя

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

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

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

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

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

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

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

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

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

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

3. Чому ви так вважаєте?

4. Яка одна річ могла б зробити вас щасливішими в наступному спринті?

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

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

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

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

Робіть усе видимим

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

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

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

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

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

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

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

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

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

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

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

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

Доставляючи щастя

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

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

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

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

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

«Це перетворюється на велику родину, – каже керівник Zappos Рейчел Браун. – Ви запрошуєте колег додому. Проводите з ними дозвілля».

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

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

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

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

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

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

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

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

Сайт Zappos пройшов шлях від 1,6 мільйона доларів продажів у 2000 році до понад мільярда у 2008-му. Це відповідає рівню зростання в 124 відсотки щороку протягом восьми років поспіль. Не знаю, як ви, але я вважаю це доволі переконливим аргументом за забезпечення щастя людей. І Scrum є якраз тим інструментом, яким ви можете для цього скористатися.

Лопайте щасливу бульбашку

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

І вони в цьому не самотні. Журнал Harvard Business Review присвятив щастю весь свій номер за січень – лютий 2012 року. Там виявили, що:

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

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

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

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

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

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

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

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

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

Що за порода в тебе та твоїх дочок: їм хочеться, щоб мене відшмагали за те, що я говорю правду, а ти хочеш, щоб мене відшмагали за те, що я брешу. А то ще, бува, шмагають мене за те, що я держу язик за зубами…[39]

Король Лір, акт 1, сцена 4 [40]

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

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

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

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

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

Щасливі сьогодні, щасливі завтра

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

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

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

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

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

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

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

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

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

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

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

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

Що треба запам’ятати

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

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

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

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

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

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

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

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

Розділ 8. Пріоритети

Зі Скоттом Максвеллом я вперше зустрівся в «Закусочній Джонні» у Ньютоні, штат Массачусетс, кілька років тому. Я вже розповідав про нього раніше. Він – засновник компанії OpenView Venture Partners і та сама людина, яка вирахувала, що понаднормова робота породжує більше клопотів, ніж досягнень. Я пропрацював з OpenView та їхніми клієнтами майже вісім років, і всі вони демонстрували надзвичайне зростання продуктивності. Але Scrum призначений не лише для прискорення роботи команд. Він має величезний вплив, який у випадку з венчурними капіталістами набуває простої форми – прибутку. Якщо компанія не приносить грошей, це не успішне комерційне підприємство, а якесь хобі.

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

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

Люблю показувати цю діаграму Венна (див. с. 205).

Власник продукту повинен збалансувати

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

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

Беклог: що й коли робити

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

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

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

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

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

У розробці продуктів є безумовне правило, що підтверджувалося багато разів. Я вже говорив про нього раніше: 80 відсотків цінності закладені в 20 відсотках характеристик. Задумайтесь над цим на хвилину. В усьому, що ви купуєте, основна цінність – те, чого люди хочуть найбільше, – складає лише п’яту частину створеного. У випадку цієї компанії співробітники дивилися на свій величезний перелік речей, які можна включити в їхню систему побутової автоматики, і розуміли (знали), що насправді клієнти хочуть лише 20 відсотків із цього. Scrum дозволяє визначити, як створити ці 20 відсотків передусім. У традиційній розробці продуктів команди не знають, у чому полягають ці 20 відсотків, доки не завершать увесь проект. Це означає, що цілих 80 відсотків їхніх зусиль марнуються. А ви знаєте, як я ставлюсь до марнування.

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

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

Як вам це зробити? Насамперед вам потрібен хтось, хто може визначити як бачення, так і цінність. У Scrum ми називаємо таку особу власником продукту.

Власник продукту

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

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

Розробляючи її, я надихався роллю головного інженера компанії Toyota. Людина на цій посаді відповідає за всю виробничу лінію окремої моделі, наприклад, Corolla чи Camry. Для цього вона має задіяти таланти груп працівників, які спеціалізуються на створенні корпуса, коліс, електропроводки тощо. Головний інженер має об’єднати групи окремих фахівців, щоб створити єдину багатофункціональну команду, здатну зібрати авто. За межами Toyota цих легендарних головних інженерів (або шуса, як їх називають у Японії) вважають всесильними лідерами так званого «шляху Toyota». У певному розумінні це правда. Але влади при цьому вони не мають. Ніхто їм не підзвітний – радше вони самі підзвітні своїм групам. Люди можуть вказувати головним інженерам на їхні помилки, тому вони мають стежити за правильністю своїх рішень. Вони не дають нікому оцінок продуктивності, підвищень чи заохочень. Вони лише приймають рішення щодо бачення авто і способів його виготовлення – шляхом переконання, а не примусу.

Саме цю ідею я й хотів утілити в системі Scrum. Джон Шук з Інституту ощадливого підприємництва якось почав свій опис ролі головного інженера цитатою з інструкції для командного складу морської піхоти США:

Відповідальність людини за лідерство не залежить від влади… глибоко вкорінене припущення, що влада має дорівнювати відповідальності, є коренем великого організаційного негаразду. Я вважаю, що непорозуміння навколо цього питання загрозливе й проблемне, воно проникло в нашу свідомість так глибоко, що ми цього навіть не усвідомлюємо[41].

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

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

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

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

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

З роками я звів головні характеристики власника продукту до чотирьох.

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

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

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

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

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

Оглядайте, орієнтуйтесь, вирішуйте, дійте

Під час Корейської війни повітряні бої точились переважно між американськими літаками F-86 Sabre і МіГ-15 радянського виробництва. МіГ був швидшим, маневренішим, ніс більше озброєння та й узагалі переважав за всіма параметрами. Теоретично МіГи мали б очистити небо від американських пілотів. Натомість їх самих збивали в десять разів більше. Намагання визначити, як це стало можливим, сформувало тактику ведення майбутніх війн. Крім того, воно мало величезний вплив на розвиток системи Scrum.

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

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

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

Бойд умів бачити все поле бою. Ось як він сам про це розповідав:

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

Така орієнтація в просторі, здатність бачити повну картину неба та подій сформувала його військові теорії, а пізніше змінила весь спосіб ведення війн США.

Пішовши з льотної школи, Бойд вирішив вивчати інженерну справу і в процесі цього створив модель льотно-технічних характеристик повітряного судна, що описувала повітряний бій з точки зору енергетичного співвідношення. Його теорія повітряного бою «Енергія – Маневреність» (EM) ураховує кінетичну та потенціальну енергію літака в будь-якій ситуації (висоту, повітряну швидкість та напрямок), а також те, наскільки швидко можна змінити будь-яку із цих величин. Згодом ця теорія викристалізувалась у спосіб моделювання більшості бойових літаків, безпосередньо привівши до розробки F-15 та F-16, найкращих винищувачів останніх сорока років.

На жаль, згідно з теорією Бойда, МіГ-15 мав би змести F-86 Sabre із неба. Щось тут було не так. Як розповідає у своєму біографічному творі Роберт Корам, намагаючись у цьому розібратися, Бойд часто цілими днями просиджував у трансі. Він був переконаний, що його теорія правильна, але ж чому тоді співвідношення збитих було 10: 1 на користь американських льотчиків? Краща підготовка? Це могло пояснити ситуацію лише частково. Тактика? Можливо, але цей фактор знову не міг привести до такого протилежного результату. А потім його осяяло. Американські пілоти краще бачили та швидше діяли. Причому завдяки не якимось своїм внутрішнім якостям, а простим особливостям конструкції літаків. Sabre мав краплиноподібний ліхтар кабіни, тоді як у МіГа той складався з багатьох скляних панелей та перемичок, що перекривали пілотові огляд. Крім того, F-86 мав повністю гідравлічні органи керування польотом, тоді як на МіГу гідравліка відігравала лише допоміжну роль. Було відомо, що пілотам МіГ-15 доводиться спеціально качати м’язи верхньої частини тіла для кращого маневрування літаком.

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

Те саме спостерігалось і у В’єтнамі, коли я був там. На той час бої велися між іншими літаками, МіГ-21 і F-4, але краща видимість американців знову перемагала кращу маневреність радянського літака. Як сказав би Бойд, його найвідоміша інновація помістила льотчиків «усередину циклу прийняття рішень ворога».

Ця ідея стала основою ведення війн. І саме для цього я призначав Scrum – дозволити власникові продукту приймати рішення швидко, на основі відгуку клієнтів у реальному часі. Отримуючи постійну реакцію від користувачів: людини, яка клацає кнопку «Купити» на Amazon, парафіян вашої церкви, дітей у класі чи дівчини в примірювальній – ви маєте змогу постійно коригувати свою стратегію та швидше досягати успіху.

Ця ідея має дещо дивну назву «петля ООВД» (Оглядати – Орієнтуватись – Вирішувати – Діяти). І хоча декому вона може здаватись кумедною, на війні та в бізнесі вона працює дуже навіть серйозно. Проникнення всередину чийогось циклу прийняття рішень викликає в них втрату орієнтації та сумніви. Їхні реакції стають або надмірними, або недостатніми. На інструктажі для інших офіцерів Бойд казав про це так: «Виживає той, хто здатний опанувати найшвидший рівень змін»[43]. Трохи нижче ви знайдете діаграму петлі ООВД.

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

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

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

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

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

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

«Команда WIKISPEED», про яку я вже писав у розділі 4, виробляє повні прототипи їхнього авто кожного тижня. І продає їх. Ці прототипи не потрапляють на масовий ринок – WIKISPEED поки не готова до цього, – але є любителі, готові викласти за них 25 тисяч доларів. Думаючи про створення чогось, не вважайте, що не зможете отримати щось цінне аж до самого кінця. Натомість намагайтесь думати про мінімально життєздатний продукт. Який абсолютний мінімум я можу зробити, надавши при цьому клієнтові щось цінне?

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

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

Бойд каже про це так:

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

Чудовий тісний маленький світ, де немає змін… [Створіння, що живуть у такому світі] – динозаври, вони вимруть. Найголовніше тут – не стати динозавром. Якщо ви стоятимете на місці, то помрете… Усе просто: виходу немає… Отакі пироги, хлопці[44].

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

Перше робиться першим

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

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

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

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

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

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

Випуск

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

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

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

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

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

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

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

Поетапна цінність – радикально краще виведення продукту в люди

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

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

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

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

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

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

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

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

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

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

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

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

Ризик

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

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

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

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

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

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

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

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

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

Ось що вам робити завтра

Гаразд, що ви робитимете завтра для впровадження Scrum у своїй роботі? Перший крок – це скласти перелік завдань та дібрати команду. Подумайте про своє бачення продукту і почніть записувати речі, які вам потрібно зробити для його реалізації. Не потрібно писати все одразу – достатньо переліку завдань (беклогу) на тиждень. І поки члени команди проводитимуть свої щоденні зустрічі стоячи та виконуватимуть перший спринт, ви зможете підготувати достатній беклог для зайнятості команди протягом наступних двох спринтів. Ніколи не випускайте його з уваги, бо, як тільки ваша команда прискориться, вони почнуть робити більше, ніж ви вважали за можливе.

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

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

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

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

Що треба запам’ятати

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

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

Лідер – не бос. Власник продукту задає, що потрібно виконати та чому. Як команда досягатиме цього та хто саме – справа команди.

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

Оглядайте, орієнтуйтесь, вирішуйте, дійте (ООВД). Треба бачити всю стратегічну картину, але діяти тактично та швидко.

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

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

Розділ 9. Змінюйте світ

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

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

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

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

Освіта

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

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

У самому місті транспорт майже повністю складається з велосипедів. Сотні й сотні з них прямують до місцевої загальноосвітньої школи під назвою Ашрам-коледж. Як і саме місто, ця школа доволі типова для голландських навчальних закладів. Там навчається приблизно 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 року чинний губернатор Джей Інслі сказав в інтерв’ю: «Держава переважно зайнята прийняттям рішень. Ми ж хочемо знайти спосіб залишити на столі менше паперу»[45].

План губернатора містить п’ять пунктів, які можна знайти в будь-якій передвиборчій програмі: 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 до роботи співробітникам потрібно від дев’яти до шістнадцяти місяців. Вони не одразу звикають до відчуття свободи», – каже Ґреґ. Той документ був призначений прискорити занурення людей в атмосферу компанії, але Ґреґ та інші засновники билися над кожним словом, бо не хотіли, щоб це пояснення здавалося спущеним згори. У результаті перший розділ називався «Ласкаво просимо на Рівнину».

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

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

Якщо ви думаєте собі: «Ого, здається, тут багато відповідальності», – то ви не помилились[46].

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

Ґреґ описує, як це відбувалося з продуктом під назвою «Велика картина». Одним з найбільших продуктів Valve є їхня ігрова платформа Steam, яка постачає користувачам відеоігри та програмне забезпечення. На цій платформі можна знайти ігри не лише Valve, але й інших розробників. Саме таким чином сьогодні переважно й поширюються комп’ютерні ігри. Але, як згадує Ґреґ, був момент, коли він та кілька його колег злякалися, що вже досягли свого клієнтського максимуму – понад п’ятдесят мільйонів.

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

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

«Ми почали продумувати деталі, а потім зробили фільм про те, як круто це буде, і скористались ним, щоб набрати людей під проект. Самі створити потрібний код ми не могли, [тому] нам потрібно було залучити людей, які можуть».

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

«Коли якась компанія оптимізується навколо нововведення, вона зазвичай змінюється докорінним чином, усуваючи внутрішні структури та ієрархії, будь-яку внутрішню структуру», – каже Ґреґ. Valve працює так весь час. Вони не чекають, поки змінитися їх змусить та чи інша криза, а змінюються постійно. Це повсякденний спосіб роботи їхньої компанії. Ще одна цитата з пам’ятки для співробітників компанії Valve.

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

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

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

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

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

«Тому група старих працівників (кістяк) Valve, яким це набридло, стала на захист принципів компанії. Навіть якщо для цього їм довелося діяти за межами цих принципів», – каже Ґреґ. Компанія найняла одразу кілька десятків людей. Розмовляючи з Ґреґом, можна було сказати, що він вважав це помилкою. Він описує це як майже біологічну реакцію, яка дивним чином нагадує дії Microsoft проти засновників Valve. Відбулася атака на чужорідні організми для захисту цілісності системи.

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

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

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

Чи використовують вони Scrum? За словами Ґреґа, пройшовши коридором, ви побачите чимало лекційних дощок на колесах, щільно вкритих стікерами. Але вони не змушують людей використовувати цю систему, а дають самим вирішувати, яка процедура їм підходить. Як і з більшості питань, Ґреґ та інші засновники компанії утримуються від того, щоб казати комусь, що робити. Проте багато працівників Valve вирішили, що по змозі обиратимуть Scrum. І цього для мене досить.

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

Або, як співав гурт Funkadelic іще в 1970 році: «Звільніть свій розум… і ваша дупа потягнеться слідом».

Що ми не можемо зробити?

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

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

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

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

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

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

Саме це, сподіваюся, ви й винесете із цієї книжки: знання, що це можливо – ситуацію можна змінювати, а не обов’язково сприймати як належне.

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

T. E. Лоуренс, Сім стовпів мудрості [48]

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

Що треба запам’ятати

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

Scrum для шкіл. У Нідерландах дедалі більше вчителів використовують Scrum для навчання дітей. При цьому вони спостерігають майже негайне покращення результатів тестів більш ніж на 10 відсотків. І вони залучають учнів усіх рівнів підготовки – від професійного до університетського.

Scrum для бідності. В Уганді фонд Grameen використовує Scrum для постачання бідним землеробам сільськогосподарських та ринкових даних. Результат – подвоєння врожаїв та прибутків для одних із найбідніших людей на планеті.

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

Додаток. Впровадження Scrum – із чого почати

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

1. Доберіть власника продукту. Це людина, яка володітиме баченням того, що ви збираєтесь зробити чи створити, чого досягти. Вона враховуватиме можливі ризики та винагороди, що можна виконати і до чого є пристрасть. (Більше див. у розділі 8 «Пріоритети».)

2. Доберіть команду. Це люди, які насправді виконуватимуть роботу. Команді потрібно мати всі вміння та навички, необхідні для того, щоб узяти бачення власника продукту й перетворити його на реальність. Команди мають бути невеликими: золоте правило – від 3 до 9 людей. (Більше див. у розділі 3 «Команди».)

3. Доберіть Scrum-майстра. Ця людина навчатиме решту команди принципів Scrum та допомагатиме їм позбуватися всього, що їх затримує. (Більше див. у розділі 5 «Марнування – це злочин».)

4. Складіть беклог продукту та розставте пріоритети. Це перелік усього, що потрібно створити чи виконати для перетворення бачення на реальність. Беклог існує та розвивається протягом усього життєвого циклу продукту – це його дорожня мапа. У будь-який момент часу беклог продукту є єдиним кінцевим орієнтиром «всього, що колись може зробити команда, у порядку пріоритетності». Існує лише один беклог продукту. Це означає, що власник продукту повинен приймати рішення щодо розставлення пріоритетів по всьому спектру. Власник продукту має консультуватися з усіма зацікавленими особами та командою, щоб чітко відображувати, що люди хочуть і що можна створити. (Більше див. у розділі 8 «Пріоритети».)

5. Удоскональте та оцініть беклог продукту. Важливо, щоб люди, які насправді виконуватимуть завдання із цього переліку, оцінювали, скільки зусиль їм на це знадобиться. Команда має дивитись на кожен пункт переліку завдань і бачити, чи дійсно його можна виконати. Чи достатньо для цього інформації? Чи не надто великий обсяг робіт для оцінки? Чи є визначення готовності – загальноприйняті стандарти, яких слід дотриматися, щоб перевести завдання в колонку «Виконано»? Чи створює це видиму цінність? Кожний пункт має бути готовим для показу, демонстрації, в ідеалі – потенційно готовим до передачі клієнтові. Не оцінюйте завдання в годинах, бо люди абсолютно не вміють цього робити. Оцінюйте за порівняльним розміром: малі, середні чи великі. Або, навіть краще, використовуйте послідовність Фібоначчі та оцінюйте кожний пункт у балах: 1, 2, 3, 5, 8, 13, 21 тощо. (Більше див. у розділі 6 «Плануйте реальність, а не фантазію».)

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

Одним зі стовпів Scrum є те, що, як тільки команда візьме на себе зобов’язання виконати можливе, на їхню думку, протягом цього спринту, беклог блокується. Ні змінити, ні додати вже нічого не можна. Команді слід дозволити автономно працювати протягом усього спринту аж до повного виконання запланованого. (Більше див. у розділі 4 «Час» та розділі 6 «Плануйте реальність, а не фантазію».)

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

Іншим способом зробити все видимим є створити діаграму згоряння завдань. На одній її осі буде кількість балів, набраних командою за спринт, а на другій – кількість днів. Кожного дня Scrum-майстер підраховує кількість балів виконаних завдань і відзначає її на діаграмі згоряння. В ідеалі там має спостерігатись різке зниження кривої, що вестиме до нуля балів в останній день спринту. (Більше див. у розділі 7 «Щастя».)

8. Щоденний стендап. Це серце всього Scrum. Кожного дня, в один і той самий час, не більш ніж на п’ятнадцять хвилин, команда та Scrum-майстер збираються разом і відповідають на три питання:

• Що ви робили вчора, щоб допомогти команді завершити спринт?

• Що ви робитимете сьогодні, щоб допомогти команді завершити спринт?

• Чи є якісь перешкоди, що заважають вам чи команді досягти мети спринту?

І це все. На цьому зустріч закінчується. Якщо вона займає більш ніж п’ятнадцять хвилин, то ви робите щось не так. Насправді вона допомагає всім членам команди чітко розуміти перебіг спринту та стадії розв’язання його завдань. Чи всі завдання буде виконано вчасно? Чи є можливості допомогти іншим членам команди в подоланні перешкод? Завдання не розподіляються згори – команда є автономною й робить усе сама. Немає жодного детального звітування перед начальством. За усунення перешкод для прогресу команди чи якихось перепон відповідає Scrum-майстер. (Більше див. у розділі 4 «Час» та розділі 6 «Плануйте реальність, а не фантазію».)

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

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

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

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

Наприкінці зустрічі команда та Scrum-майстер мають узгодити одне покращення процесу, яке вони впровадять у наступному спринті. Це покращення процесу, яке іноді називають кайдзен, слід внести в беклог наступного спринту разом із критеріями прийнятності. Так команда зможе легко бачити, чи дійсно вони впровадили покращення і який вплив це мало на швидкість. (Більше див. у розділі 7 «Щастя».)

11. Одразу починайте наступний спринт, ураховуючи досвід команди щодо перешкод та покращень процесу.

Подяки

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

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

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

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

Головний власник продукту Алекс Браун, Джо Джастіс та решта команди Scrum, Inc. ділилися зі мною важливими ідеями, своєю невичерпною енергією та величезним досвідом.

Я також хотів би подякувати:

Професорам Гіротаці Такеучі та Ікуджиро Нонаці, чия робота запалила ідею Scrum і які пізніше стали моїми добрими друзями.

Моєму товаришеві у створенні Scrum Кену Шваберу, чия сердита впертість допомогла сформувати цю систему та зробити її силою, якою вона є сьогодні.

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

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

Примітки

1

Eggen, Dan, and Griff Witte. «The FBI’s Upgrade That Wasn’t; $170 Million Bought an Unusable Computer System.» Washington 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 р.

(обратно)

6

Takeuchi, Hirotaka, and Ikujiro Nonaka. «The New New Product Development Game.» Harvard Business Review (січень— лютий 1986 р.): 285–305.

(обратно)

7

Schwaber, Ken. «Scrum Development Process,» у збірці OOPSLA Business Object Design and Implementation Workshop, J. Sutherland, D. Patel, C. Casanave, J. Miller, and G. Hollowell, eds. (London: Springer, 1997).

(обратно)

8

Deming, W. Edwards. «To Management.» Промова в Конференц-центрі на горі Хаконе, Японія, 1950 р.

(обратно)

9

Takeuchi, Hirotaka, and Ikujiro Nonaka. «The New New Product Development Game.» Harvard Business Review (січень – лютий 1986 р.): 285–305.

(обратно)

10

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

(обратно)

11

MacArthur, Douglas. «The Long Gray Line.» Промова в Академії Вест-Пойнт, штат Нью-Йорк, 1962 р.

(обратно)

12

Там само.

(обратно)

13

Feynman, Richard. Report of the Presidential Commission on the Space Shuttle Challenger Accident, Appendix F – Personal Observations on Reliability of Shuttle. Звіт (1986).

(обратно)

14

Warrick, Joby, and Robin Wright. «U.S. Teams Weaken Insurgency in Iraq.» Washington Post, 6 вересня 2006 р.

(обратно)

15

Flynn, Michael, Rich Jergens, and Thomas Cantrell. «Employing ISR: SOF Best Practices.» Joint Force Quarterly 50 (3-й квартал 2008 р.): 60.

(обратно)

16

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.

(обратно)

17

Brooks, Frederick P. The Mythical Man-Month: Essays on Software Engineering (Reading, MA: Addison-Wesley, 1975).

(обратно)

18

Cowan, Nelson. «The Magical Number 4 in Short-Term Memory: A Reconsideration of Mental Storage Capacity.» Behavioral and Brain Sciences 24 (2001): 87—185.

(обратно)

19

Nisbett, Richard, Craig Caputo, Patricia Legant, and Leanne Marecek. «Behavior as Seen by the Actor and as Seen by the Observer.» Journal of Personality and Social Psychology 27.2 (1973): 154—64.

(обратно)

20

Milgram, Stanley. «The Perils of Obedience.» Harper’s Magazine, 1974.

(обратно)

21

Marvell, Andrew. «To His Coy Mistress,» (1681).

(обратно)

22

Ohno, Taiichi. Toyota Production System: Beyond Large-scale Production (Cambridge, MA: Productivity, 1988).

(обратно)

23

Strayer, David, Frank Drews, and Dennis Crouch. «A Comparison of the Cell Phone Driver and Drunk Driver.» Human Factors 48.2 (літо 2006): 381—91.

(обратно)

24

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 Sensation Seeking.» PLoS ONE (2013) 8(1): e54402. doi:10.1371/journal.pone.0054402.

(обратно)

25

Weinberg, Gerald M. Quality Software Management (New York: Dorset House, 1991).

(обратно)

26

Pashler, Harold. «Dual-task Interference in Simple Tasks: Data and Theory.» Psychological Bulletin 116.2 (1994): 220—44.

(обратно)

27

Charron, Sylvain, and Etienne Koechlin. «Divided Representation of Concurrent Goals in the Human Frontal Lobes.» Science 328.5976 (2010): 360—63.

(обратно)

28

Wilson, Glenn. The Infomania Study. Issue brief, / Infomania_experiment_for_HP.doc.

(обратно)

29

Womack, James P. Daniel T. Jones, and Daniel Roos. The Machine That Changed the World: The Story of Lean Production (New York: Harper Perennial, 1991).

(обратно)

30

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).

(обратно)

31

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).

(обратно)

32

Cohn, Mike. Agile Estimation and Planning (Upper Saddle River, NJ: Prentice Hall 2005).

(обратно)

33

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.

(обратно)

34

Thorndike, Edward Lee. «A Constant Error in Psychological Ratings.» Journal of Applied Psychology 4.1 (1920): 25–29.

(обратно)

35

Dalkey, Norman, and Olaf Helmer. «An Experimental Application of the Delphi Method to the Use of Experts.» Management Science 9.3 (квітень 1963 р.): 458—67.

(обратно)

36

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.

(обратно)

37

Spreitzer, Gretchen, and Christine Porath. «Creating Sustainable Performance.» Harvard Business Review (січень – лютий 2012 р.): 3–9.

(обратно)

38

Там само.

(обратно)

39

The Fool, King Lear, act 1, scene 4.

(обратно)

40

Шекспір В. Твори в 6 т. / Пер. М. Рильського. – Т. 5. – К.: Дніпро, 1986.(Прим. перекл.)

(обратно)

41

Shook, John. «The Remarkable Chief Engineer.» Lean Enterprise Institute, 3 лютого 2009.

(обратно)

42

Ford, Daniel. A Vision So Noble: John Boyd, the OODA Loop and America’s War on Terror (CreateSpace Independent, 2010).

(обратно)

43

Boyd, John. New Conception. 1976.

(обратно)

44

Там само.

(обратно)

45

Shannon, Brad. «McKenna, Inslee Outline Plans to Bring Efficiency to Government.» The Olympian, 6 жовтня 2012 р.

(обратно)

46

Valve Handbook for New Employees (Bellevue, WA: Valve Press, 2012).

(обратно)

47

Там само.

(обратно)

48

Lawrence, T. E. Seven Pillars of Wisdom: A Triumph (London: Cape, 1973).

(обратно)

Оглавление

Відгуки про книжку

Scrum Навчись робити вдвічі більше за менший час

  Передмова

  Розділ 1. Спосіб, у який працює світ, – недосконалий

    Новий спосіб мислення

    Розв’язання проблеми ФБР

    Що треба запам’ятати

  Розділ 2. Витоки Scrum

    Вчимося думати, як робот

    Не женіться за каскадною моделлю

    Перевіряйте та адаптуйте

    Змінюйтесь або помріть

    Шу-Ха-Рі

    Що треба запам’ятати

  Розділ 3. Команди

    Довга сіра лінія

    Scrum під час революцій

    Одна команда для всієї роботи

    Scrum під час війни

    Розмір має значення, але не так, як ви гадаєте

    Scrum-майстер

    Шукайте проблему не в гравцях, а в грі

    Досягнення надзвичайності

    Що треба запам’ятати

  Розділ 4. Час

    Спринт

    Щоденні стендапи

    Час і ще раз час

    Що треба запам’ятати

  Розділ 5. Марнування – це злочин

    Одна справа за раз

    Визначення пріоритетів серед проектів

    Зроблене наполовину – не зроблене взагалі

    Робіть усе правильно з першого разу

    Понаднормова праця збільшує обсяг роботи

    Будьте розсудливі

    Потік

    Що треба запам’ятати

  Розділ 6. Плануйте реальність, а не фантазію

    Планування весілля

    Розмір має значення, але лише відносно

    Послідовність Фібоначчі: усе навколо нас

    Дельфійський оракул

    Планувальний покер

    Не просто завдання, а сюжети

    Створюйте короткі сюжети

    Будьте готові, і все буде виконано

    Планування спринту

    Знайте вашу швидкість

    Що треба запам’ятати

  Розділ 7. Щастя

    Щастя – це успіх

    Розрахунок щастя

    Робіть усе видимим

    Доставляючи щастя

    Лопайте щасливу бульбашку

    Щасливі сьогодні, щасливі завтра

    Що треба запам’ятати

  Розділ 8. Пріоритети

    Беклог: що й коли робити

    Власник продукту

    Оглядайте, орієнтуйтесь, вирішуйте, дійте

    Перше робиться першим

    Випуск

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

    Ризик

    Ось що вам робити завтра

    Що треба запам’ятати

  Розділ 9. Змінюйте світ

    Освіта

    Бідність

    Державне управління

    Як ми всі колись працюватимемо

    Що ми не можемо зробити?

    Що треба запам’ятати

  Додаток. Впровадження Scrum – із чого почати

Подяки Fueled by Johannes Gensfleisch zur Laden zum Gutenberg