Professional Documents
Culture Documents
Scrum
Scrum
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 вивчили
вимоги замовника та почали планувати створення системи, яка буде на
все це здатна. Було задіяно багато розумних людей, які довгі місяці
працювали над визначенням того, що треба зробити. Потім вони
витратили ще місяці на планування того, як це зробити. Вони
підготували чудові графіки, позначивши там усе, чого слід досягти, та
час, який займе виконання кожного завдання. Після цього, ретельно
дібравши кольори, вони зобразили всі частини проекту, які переходили
одна в одну у вигляді каскаду.
Каскадна модель
Що треба запам’ятати
Планувати корисно. Сліпо дотримуватися плану безглуздо.
Звичайно, малювати нескінченні діаграми спокусливо. Адже таким
чином уся робота, яку потрібно виконати щодо масштабного проекту,
відкривається на загальний огляд. Але коли ваші детальні плани
зустрічаються з реальністю, вони просто розвалюються на частини.
Закладайте у свій метод роботи можливість змін, відкриттів та нових
ідей.
Перевіряйте та адаптуйте. Після кожного маленького кроку
робіть паузу, переглядайте виконане та дивіться, чи все ще відповідає
воно вашій меті та чи можете ви щось покращити у своїй роботі.
Змінюйтесь або помріть. Прив’язка до старого способу роботи,
управління та контролю, а також жорстка передбачуваність ведуть
лише до провалу. Поки ви від них не відмовитесь, готові до змін
конкуренти залишатимуть вас далеко позаду.
Помиляйтесь швидко, щоб устигнути все виправити.
Корпоративна культура часто приділяє більше уваги різним формам,
процедурам та зустрічам, аніж створенню відчутної цінності, яку з
короткими інтервалами можуть випробувати користувачі. Робота, що
не приносить справжньої цінності, безглузда. Виробництво ж продукту
короткими циклами дозволяє отримати ранній відгук користувачів та
негайно позбутися явного марнування зусиль.
Розділ 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 стали першими онлайновими автоматами для транзакцій, яким
банки довіряли достатньо, щоб їх використовувати. Ми розгорнули їх
по всій Північній Америці. У наші дні, у яку б частину країни ви не
поїхали, банкомат знайдеться скрізь. І всі ці машини точно знатимуть,
скільки грошей на вашому рахунку. Моя команда добряче над цим
попрацювала. Ага, нема за що.
Перевіряйте та адаптуйте
У системі Scrum команди, які добре працюють, здатні досягти того,
що ми називаємо гіперпродуктивністю. Важко повірити, але серед
груп, які добре впроваджують Scrum, ми регулярно бачимо десь так від
300 до 400 відсотків покращення продуктивності. Найкращі команди
можуть досягти підвищення продуктивності аж до 800 відсотків, а
потім повторювати цей успіх знову й знову. Крім того, в результаті
використання цієї системи подвоюється якість їхньої роботи.
То як створити в Scrum-команді автономію, прагнення перевершити
самих себе, взаємозаохочення – а потім досягти гіперпродуктивності
за рахунок поєднання всього цього? Мова про це піде в решті розділів
цієї книжки, але базові принципи я збираюся подати вам тут. У
скороченій формі їх можна також побачити в додатку.
Оскільки Scrum бере початок із технік, використовуваних у
японському виробництві, не завадить трохи дізнатися, звідки їх узяли
японці. За іронією долі, вони багато чого навчилися в одного
американця – Вільяма Едвардса Демінга. Під час американської
окупації Японії після Другої світової війни Демінг працював на
генерала Дуґласа Мак-Артура. Підхід Мак-Артура до відновлення
економіки полягав у тому, щоб звільнити більшу частину вищого
керівництва японських компаній, підвищити керівників середньої
ланки та залучити до ділових операцій експертів зі Сполучених
Штатів, таких як Демінг. Вплив Демінга на японське виробництво був
надзвичайним. Він навчив сотні інженерів того, що називається
«статистичним контролем процесів». Основною ідеєю було точне
вимірювання зробленого та його якості, а також прагнення до
безперервного покращення. Не просто разового покращення, а
постійного. Слід завжди шукати, що можна покращити, і ніколи не
зупинятися на досягнутому. Для цього потрібно постійно проводити
експерименти, які вказуватимуть на можливість досягти кращих
результатів. Якщо спробувати цей метод, чи не буде він кращим за
старий? Як щодо іншого? Що як змінити один цей момент?
Відомий виступ Демінга перед керівниками японських підприємств
у 1950 році. Серед слухачів були й такі люди, як Акіо Моріта,
засновник компанії Sony. Демінг тоді сказав їм:
…хоч які чудові у вас технічні фахівці, саме ви, лідери, повинні
прагнути успіхів у покращенні якості та однорідності продукції, а
ваші техніки мають бути здатні на ці покращення. Отже, перший
крок – за керівництвом. Перш за все, техніки вашої компанії та
робітники ваших заводів повинні знати, що ви маєте завзяття для
вдосконалення якості та однорідності продукції, а також почуття
відповідальності за якість продукції.
Якщо лише говорити про це, нічого не вийде. Важливо діяти[8].
Найбільше Демінг відомий якраз своїм методом дій – циклом
ПРПД (Планувати, Робити, Перевіряти, Діяти). Цей цикл можна
застосувати до виробництва практично всього: автомобіля, відеогри чи
навіть паперового літачка.
Коли я навчаю когось застосовувати Scrum, то використовую саме
їх – паперові літачки. Я поділяю людей на команди й ставлю перед
ними завдання зробити якомога більше паперових літачків, які
літатимуть кімнатою. У команді буде три категорії людей. Одна
людина перевірятиме, скільки зроблено літачків, які дійсно можуть
літати. Друга буде частиною виробничого процесу разом з усіма, але
також звертатиме увагу на сам процес та шукатиме способи
покращення якості літачків і прискорення їх виробництва. Усі інші
концентруватимуться на виготовленні якомога більшої кількості
літачків, дійсно здатних пролетіти задану відстань за відведений на це
час.
Потім я кажу, що ми маємо виконати три шестихвилинні цикли
виробництва паперових літачків. Одну хвилину кожного циклу
команди мають Планувати, як вони збираються робити літачки, три
хвилин – Робити (виготовляти й тестувати якомога більше літачків,
дійсно здатних літати). І нарешті, дві хвилини вони мають Перевіряти.
На цьому етапі команда дивиться, як можна покращити процес
виготовлення їхніх паперових літачків. Що пішло правильно? Що –
неправильно? Чи не слід змінити дизайн? Як можна покращити процес
виготовлення? А потім вони Діятимуть. У системі Демінга «діяти»
означає змінювати ваш спосіб роботи на основі реальних результатів
і реального впливу зовнішніх умов. Та сама стратегія
використовувалась і в роботах Брукса.
Пройдіть цей цикл тричі, і, хоч що ви виробляєте – паперові
літачки чи справжні космічні кораблі, – ви станете кращими, значно
кращими (прискорившись у два-три рази і щонайменше подвоївши
якість). Саме завдяки цьому циклу Демінга – радикальній ідеї на той
час, коли її презентували японцям, – компанія Toyota і стала
автовиробником номер один у світі. Саме так працює будь-який
різновид «ощадливого» виробництва (американський термін для
використання концепцій виробничої системи Toyota) або розробка
продукту в Scrum.
Шу-Ха-Рі
Коріння 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].
То як створити команду, націлену на вищу мету, самоорганізовану
та постійно підживлювану вміннями й навичками кожного її члена? Я
витратив чимало часу, щоб це зрозуміти. Зрештою, не можна просто
кричати на людей, щоб вони були більш самоорганізовані та
надзвичайні. Мотивація має йти зсередини. Її нав’язування просто вб’є
те, що ви намагаєтесь зробити. Можливо, існує якийсь простий набір
правил, що заохочують до створення дива?
Досягнення надзвичайності
Коли члени команди починають гуртуватися навколо спільної мети
й синхронізувати свої дії, це схоже на магію. Ви відчуваєте це, коли
заходите в приміщення, де вони працюють. Ви бачите це, коли гравці
виходять на поле. Вони починають діяти надзвичайно злагоджено,
перевершуючи самих себе.
Нещодавно я гостював в одного свого друга в Копенгагені. Як ви
можете собі уявити, оскільки він європеєць, то є завзятим футбольним
уболівальником. Не пам’ятаю точно, що то був за турнір, у якому грала
його улюблена команда, але треба було бачити, як він стрибав у кріслі
та кричав до телевізора. То було видовище справжнього спортивного
фаната в дії. А потім настав цей момент: рахунок був рівним, ішли
останні секунди матчу, і м’яч був у його команди. Довгим пасом, не
дивлячись, де його партнери по команді, форвард відправив м’яч у
масу гравців перед воротами суперника. Проблема в тому, що там не
було нікого з його партнерів. На якийсь момент я відчув у грудях
порожнечу, але потім там раптом виник гравець із команди мого друга
(точно в потрібному місці та в потрібний час), який головою відправив
м’яч у сітку. Він на повній швидкості пробіг половину поля до групи
суперників перед воротами, де й скористався можливістю забити гол.
Це здавалось абсолютною несподіванкою. Але форвард, який віддавав
пас, вірив, що його товариш по команді опиниться там, де потрібно. А
партнер вірив, що м’яч опуститься туди, де він зможе щось із ним
зробити. Це був саме той різновид синхронізації, який і надихає
глядачів.
І саме цього я й хочу допомогти людям досягти за рахунок 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-лихоманку, називайте їх спринтами.
Демонструйте або помріть. Наприкінці кожного спринту майте
щось виконане – щось придатне для використання (польоту, поїздки,
чого завгодно).
Викиньте свої візитівки. Посади є показниками конкретного
статусу. Нехай за вас говорять ваші справи, а не додаток до імені.
Усі разом знають усе. Комунікаційне насичення прискорює роботу.
Одна зустріч на день. Коли йдеться про перевірку досягнень
команди, раз на день цілком досить. Збирайтесь разом на п’ятнадцять
хвилин у щоденному стендапі, дивіться, що можна зробити для
збільшення швидкості, та робіть це.
Розділ 5. Марнування – це злочин
В основі Scrum лежить ритм, який має надзвичайно важливе
значення для людей. Адже його биття відчувається в пульсуванні
нашої крові та проростає з найпотаємніших куточків наших мізків. Він
живе глибоко в наших серцях, змушуючи нас шукати вияви ритму та
усталених схем у всіх аспектах життя.
Проте вияви, які ми шукаємо, зовсім не обов’язково нас
винагороджують або несуть нам щастя. Наприклад, існують негативні
ритми наркоманів та алкоголіків або людей у стані депресії. Ви можете
пройтися коридорами ледь не будь-якого офісного центру і побачити
чимало таких негативних виявів. Майже напевне вони трапляються
там, де люди зневірились у своїх силах і почуваються загнаними в
глухий кут, перебувають у тихому відчаї, потрапивши в пастку
байдужої системи, або зляться, що їх вважають гвинтиками величезної
машини.
Це – частина багатовікового людського досвіду. Читаючи твори,
написані сотні років тому, можна знайти історії людей, чиє життя так
само було затиснуте в межах жорстокої системи, проти якої вони
почувалися безсилими. Однак десь у ХХ столітті ми, схоже, загнали
себе в ще більшу пастку. Особливо це виявляється у сфері бізнесу, де
ми створили різку деперсоналізацію, яка нібито продиктована самою
долею.
Натомість Scrum створює зовсім іншу схему. Він базується на тому,
що ми є істотами, які залежать від своїх звичок, скрізь шукають ритм,
дещо передбачувані, але й мають у собі щось магічне і здатні на
видатні вчинки. Створюючи Scrum, я думав: «Що як я зможу взяти
схеми людської поведінки та зробити їх позитивними, а не
негативними? Що як я зможу розробити ефективний
самопідкріплюваний цикл, що посилюватиме найкращі наші риси та
послаблюватиме найгірші?» Гадаю, задаючи Scrum щоденний та
щотижневий ритм, я прагнув запропонувати людям шанс полюбити
особу, яку вони бачать у дзеркалі.
Але, як і скрізь, на цьому шляху також трапляються пастки. Те, що
здається цілком надійною схемою, може закінчитися черговою
дурницею – марнуванням часу, грошей та зусиль. Розгляду цієї
проблеми я й збираюся присвятити цей розділ: марнування, яке уражає
нашу роботу, немов ракова пухлина, підриваючи нашу продуктивність,
організацію, життя та все наше суспільство.
Якось, проводячи співбесіду з одним із кандидатів на вакансію
в Scrum, Inc., я спитав, чому він хоче працювати в компанії, де
застосовуються принципи Scrum. Він розповів мені цілу історію.
Раніше він працював у фірмі, що видавала підручники та різну
допоміжну продукцію, на кшталт робочих зошитів, курсових
матеріалів, наочних посібників тощо. Його завданням було визначення
провідних учених у конкретній галузі та робота з ними щодо
виготовлення такої продукції.
У певному розумінні це було чудово. Він сам захоплювався
історією, вивчав американський колоніальний період, і робота давала
йому можливість спілкуватися з провідними фахівцями в цій галузі.
«Я пропрацював там рік, – сказав він. – Рік, витрачений на
підготовку десятків різних матеріалів. Наприкінці ж того року ми
вперше переглянули свої досягнення. І чи не половину зробленої мною
роботи було викинуто на смітник. Не тому, що вона була поганою, а
тому, що вона, бачте, виявилась неринковою або не відповідала новим
напрямам діяльності фірми. Шість місяців мого життя були цілком
і повністю змарновані».
У цей момент у його голосі прозвучали гнів та обурення. Але потім
на зміну їм прийшла рішучість: «Я сподіваюся, що Scrum такого не
дозволить, у моєї роботи буде мета, а зроблене дійсно матиме
значення».
Ви, можливо, думаєте, що це крайній випадок, коли марнування
склало аж п’ятдесят відсотків роботи. Але насправді це ще не так
і погано. Коли я приходжу в якусь компанію, то зазвичай виявляю, що
там марнується близько 85 відсотків усіх зусиль. Лише шоста частина
будь-якої виконаної роботи дійсно має якусь цінність. Глибоко
всередині нас самих, зважаючи на ритм наших днів, ми знаємо, що це
правда. Ось чому ми всі сміємось, трохи нервово, над жартами про
внутрішнє безумство та марність життя в сучасній корпорації.
Але я хочу, щоб ви знали: це не має бути кумедним. Це має бути
ганебним. Ми повинні оплакувати життя та потенціал, які марнуємо. Я
вже коротко представив вам керівника Toyota Таїчі Оно в першому
розділі цієї книжки, коли він сказав: «Марнування є злочином проти
суспільства, а не просто комерційними втратами». Його думки про
марнування глибоко вплинули на мої, і я збираюся присвятити деякий
час розповіді про них.
Оно говорив про три різні типи марнування. Він використовував
японські слова: мурі – марнування через непродуманість; мура –
марнування через непостійність; муда – марнування через
непотрібність результатів. Ці ідеї чітко співвідносяться з циклом
Демінга, про який я писав раніше: Плануйте, Робіть, Перевіряйте,
Дійте. Плануйте означає уникайте мурі. Робіть означає уникайте
мура. Перевіряйте означає уникайте муда. Дійте означає волю,
мотивацію та рішучість зробити все це. Я збираюсь розглянути ці
кроки один за одним, вказуючи на те, чого слід уникати – від
марнування ресурсів до марнування через неправильну роботу з
першого разу, марнування через надто важку роботу та емоційного
марнування через необґрунтовані очікування[22].
Будьте розсудливі
За Таїчі Оно, існують три типи марнування, які ведуть до того, що
люди працюють важче та більше часу, ніж необхідно. Я щойно
пояснив, чому понаднормова праця – це напрочуд погана ідея, але
розуміння складників марнування, яке Оно назвав мурі, тобто
«непродуманість», «нерозсудливість», є, мабуть, найпотужнішим із
доступних нам інструментів досягнення змін.
Першим складником є «абсурдність». Ви маєте ставити перед
своєю командою амбітні цілі – підштовхувати її до досягнення чогось
більшого. Але ви не маєте вести її до абсурдних, нереальних цілей.
Другим складником є «необґрунтовані очікування». Скільки разів
вам доводилося чути чиєсь вихваляння, що проект був врятований
лише завдяки їхнім героїчним зусиллям? Зазвичай ці люди отримують
поплескування по плечу, схвальні вигуки та привітання. Я вважаю це
основною помилкою в робочому процесі. Команда, яка залежить від
регулярних героїчних дій для дотримання своїх дедлайнів, не працює
так, як це має бути. Постійний перехід від однієї кризи до наступної
спричиняє вигоряння й не дозволяє досягти обґрунтованого
безперервного покращення. Це як різниця між ковбоєм, який бездумно
кидається рятувати дівчину від поганих хлопців, і дисциплінованими
морпіхами, які планомірно зачищають ворожу територію.
Третій складник цього різновиду марнування Оно назвав
«перевантаження». Це поведінка, яку художник Скотт Адамс
регулярно висміює у своїх коміксах про Ділберта. Сюди належать
обтяжлива політика компанії, що заважає роботі; непотрібна
бюрократія, коли люди змушені заповнювати форми заради форм;
пустопорожні зустрічі, що висмоктують час і не приносять жодної
користі.
Хоч Оно не згадав четвертого складника, на думку спадає також
«емоційне марнування». Воно виникає тоді, коли серед співробітників
компанії знаходиться гівнюк, якому подобається накручувати інших
і тримати їх у постійній напрузі. Такі гівнюки часто виправдовують
свою поведінку, заявляючи, що вони просто намагаються покращити
роботу колег. Насправді ж вони потурають негативним аспектам своєї
особистості, підриваючи здатність команди до покращення як ніхто
інший.
Не будьте гівнюками. Не дозволяйте, не заохочуйте та не
допускайте такої поведінки в інших.
Потік
У теоретично ідеальному світі не було б ані процедур, ані
зустрічей, ані форм, ані звітів. Натомість було б створення саме того,
чого хоче клієнт, навіть якщо той поки не знає, чого саме. Будь-яка
«процедура», якою користуються люди, була б зайвою, у тому числі
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 це може бути цінність
бізнесу, а у випадку весілля – щастя нареченої.
Дельфійський оракул
Отже, тепер ми знаємо, що добре вміємо порівнювати речі між
собою. Ми також знаємо найкращий підхід до розв’язання завдань.
Але як ним скористатись? Перелік пріоритетних речей – це все добре,
але як же нам визначити, що в нас п’ятірка, а що вісімка, що
«лабрадор», а що «вівчарка»? І навіть якщо одна людина має доволі
добру ідею, як нам переконатися, що її оцінки збігаються з думками
всіх інших? Що як вона не врахувала якихось ключових факторів?
Звісно, ця проблема не нова. Люди билися над нею десятками
років. З одного боку, різні члени команди знають різні речі, а з іншого,
існує так званий «ефект стадності». Ви бували на таких зустрічах. Це
коли хтось висуває ідею, і всі починають про неї говорити. Тоді, навіть
якщо спочатку ви були проти, то поступово погоджуєтесь, бо
погоджується група. А далі всі дружно йдуть уперед шляхом, що
здається дійсно чудовим, але із часом виявляється повним провалом.
Коли ж ви питаєте людей про це рішення, майже завжди виходить, що
всі мали якісь застереження, але не озвучили їх, бо бачили захват усіх
інших. Люди вважають, що якщо всі інші із чимось погоджуються, то
їхні власні перестороги є безглуздими чи непродуманими, а тому не
бажають виставити себе дурнями перед групою. Запам’ятайте: таке
групове мислення – не поодинока помилка. Для людей вона типова.
У літературі цей ефект пояснюється як «інформаційний каскад».
Автори статті «Теорія фантазій, моди, звичаїв та культурних змін як
інформаційних каскадів» Сушил Біхчандані, Девід Гіршляйфер та Іво
Велч сказали про це так: «Інформаційний каскад виникає, коли для
людини оптимально, поспостерігавши за діями попередників,
повторити їх, незважаючи на її власну інформацію»[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 доволі добре дає
їм раду.
Але тоді ця компанія мала ідею, яка здавалася цілком непоганою.
Вона полягала в тому, що замість оцінювання завдання кожною
окремою командою його доручатимуть найкращим оцінювачам
компанії – найрозумнішим, які дійсно розбираються в проектах
і технологіях та знають, що потрібно виконати. Так і зробили з
кількома проектами. За попередніми оцінками, один мав зайняти
стільки-то часу, інший – стільки-то і т. д. Планувалося представити
оцінки вісімдесяти багатомільйонних проектів клієнтам та командам,
які дійсно виконуватимуть роботу. Здається цілком розумним, чи не
так?
Проте цей спосіб виявився настільки неправильним, що вони
зупинили експеримент на півдорозі, після виконання лише сорока
проектів. Мені це нагадує клінічні дослідження лікарських препаратів,
зупинені через те, що ліки не лікують пацієнтів, а вбивають їх. Оцінки
були настільки далекими від реальності, що не давали ніякої користі.
Нічого не здавалося вчасно. Серед клієнтів зростало невдоволення.
Команди були деморалізовані. Це була повна катастрофа. Менеджерам
довелося швидко повернутися до оцінювання саме тими командами,
які виконуватимуть роботу. І що ви думаєте? Оцінки знову почали
збігатися з реальністю.
Із цього я виніс, що лише ті люди, які виконують роботу, знають,
скільки часу та зусиль вона потребує. Команда експертів може чудово
розбиратися в одних речах, але не розумітися на інших. Можна мати
одного фахівця з конкретної сфери діяльності, але при цьому інші
сфери залишатимуться в тіні. Як я вже казав раніше, всі команди
індивідуальні та унікальні. Кожна з них має власний темп та ритм. Це
не тісто для печива – однаковими формочками його не наріжеш.
Планування спринту
У 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-послуг. Ми
відстежили нашу швидкість і виявили, що кожного однотижневого
спринту виконуємо завдань приблизно на сорок балів. Після
запровадження показника щастя одразу виявилось, що наші сюжети не
досить добрі. Вони не були достатньо підготованими, не мали
визначення готовності та були надто розпливчастими. Я попрацював
над цим, і ми почали писати кращі сюжети. Але протягом наступного
спринту вони все ще були недостатньо добрими. Це відображали наші
оцінки щастя. У третьому спринті виникла нова проблема. Ми взялися
за неї. Так і пішло. Усього за кілька тижнів наша швидкість
збільшилася із сорока балів за спринт до ста двадцяти. Ми потроїли
продуктивність, просто питаючи, що може зробити людей
щасливішими. Як результат, наші клієнти також стали щасливішими, а
наші прибутки різко підскочили. Усе, що треба було для цього
зробити, – почати питати в команди: «Що може зробити вас
щасливішими?», а потім давати їм це.
Ми зобразили ці дані на графіку, наклавши їх на час, і побачили
кілька надзвичайно цікавих моментів. Як генеральний директор, я
зосереджений на тому, що може статись у майбутньому з нашими
прибутками, зростанням та продуктивністю. І от що я виявив: на
відміну від фінансових показників, показник щастя є прогностичним.
Фінансові дані показують, що було в минулому, але, коли ви питаєте
людей про їхнє щастя, вони дійсно проектують майбутнє. А коли вони
думають про своє щастя в компанії, то починають проектувати свої
думки про діяльність компанії. Як результат, ви отримуєте сигнал про
проблему до її виникнення. І, якщо приділяти достатньо уваги тому,
що каже вам ваша команда, можна вживати заходів та виправляти
ситуацію до того, як вона перетвориться на проблему. На графіку
нижче, наприклад, падіння рівня щастя передує падінню швидкості чи
продуктивності на кілька тижнів. Якщо дивитися лише на
продуктивність, ви не побачите негараздів, доки вони не зваляться вам
на голову, неначе гірський обвал. Але, побачивши по всій команді
падіння щастя, навіть за умови зростання продуктивності, знайте, що у
вас проблема, якою слід зайнятися, причому якнайскоріше.
Доставляючи щастя
Однією з компаній, що розглядають щастя як основу своєї
корпоративної культури, є 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 є якраз тим інструментом, яким ви
можете для цього скористатися.
Що треба запам’ятати
Це шлях, а не пункт призначення. Справжнє щастя – у процесі, а
не в результаті. Дуже часто ми винагороджуємо лише результати, але
насправді маємо заохочувати прагнення людей до надзвичайності.
Щастя – найкращий вітамін. Воно допомагає вам приймати
розумніші рішення. Крім того, коли люди щасливі, то більш творчі,
рідше звільняються з роботи та частіше досягають просто неймовірних
результатів.
Обчислюйте щастя. Недостатньо просто почуватися добре.
Потрібно вимірювати це відчуття та порівнювати його з реальною
продуктивністю. Інші показники дивляться в минуле. Щастя ж
демонструє майбутнє.
Ставайте кращим кожного дня – і вимірюйте це. Наприкінці
кожного спринту члени команди мають обирати одне маленьке
покращення, або кайдзен, яке зробить їх щасливішими. І це має бути
найважливішою річчю, якої вони досягнуть у наступному спринті.
Таємність – отрута. Не має бути нічого таємного. Усі мають знати
все, включно з інформацією про зарплати та фінансові справи
компанії. Прихованість потрібна лише людям, які керуються власними,
а не командними інтересами.
Робіть усе видимим. Заведіть дошку, що показуватиме всю роботу,
яку потрібно виконати, над чим уже працюють і що наразі виконано.
Усі мають бачити ці дані та оновлювати їх кожного дня.
Щастя – це автономія, майстерність і мета. Усі хочуть
контролювати власну долю, ставати кращими у своїй роботі та
служити меті, вищій за них самих.
Лопайте щасливі бульбашки. Не ставайте настільки щасливими,
щоб почати вірити у власне марення. Не забувайте порівнювати щастя
з продуктивністю і в разі виявлення невідповідності будьте готові
діяти. Самовдоволеність – ворог успіху.
Розділ 8. Пріоритети
Зі Скоттом Максвеллом я вперше зустрівся в «Закусочній Джонні»
у Ньютоні, штат Массачусетс, кілька років тому. Я вже розповідав про
нього раніше. Він – засновник компанії OpenView Venture Partners і та
сама людина, яка вирахувала, що понаднормова робота породжує
більше клопотів, ніж досягнень. Я пропрацював з OpenView та їхніми
клієнтами майже вісім років, і всі вони демонстрували надзвичайне
зростання продуктивності. Але Scrum призначений не лише для
прискорення роботи команд. Він має величезний вплив, який у
випадку з венчурними капіталістами набуває простої форми –
прибутку. Якщо компанія не приносить грошей, це не успішне
комерційне підприємство, а якесь хобі.
Навіть не скажу, скільки я бачив компаній із чудовими ідеями та
дійсно класним продуктом, яким усі захоплювались. Здавалося, що він
неодмінно займе ринкову нішу, що просто приречений на успіх. Адже
він такий класний. Але попри мегадози уяви, натхнення та важкої
праці, люди, які його виробляли, так і не змогли визначити, як саме
заробляти на ньому гроші.
У чому різниця між компаніями Pets.com і Zappos? Вони обидві
побачили сегмент ринку, на який люди витрачають мільярди доларів на
рік. Вони обидві побачили простіший та дешевший спосіб замовляння
й доставлення їхніх товарів онлайн. Одна компанія стала символом
провалу Інтернет-проектів та розтрати багатьох мільйонів доларів, тоді
як друга сьогодні коштує понад мільярд. Вони обидві мали бачення,
але Pets.com не мала відчуття пріоритетів. Люди там не розуміли, що й
коли треба робити.
Люблю показувати цю діаграму Венна (див. с. 205).
Власник продукту
У 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, вибір перед вами
доволі простий: змінюйтесь або помріть. Якщо не ввійдете всередину
циклу прийняття рішень ваших конкурентів, вони ввійдуть усередину
вашого. Як казав Бойд: «Що я хочу зробити, так це загнати свого
супротивника назад, усередину його… Тоді я зможу довести його до
втрати орієнтації, розгубленості, а там і до паралічу дій». Не знаю, як
ви, а я краще робитиму так сам, ніж щоб так робили зі мною.
Випуск
Отже, пріоритети розставлено. Ви знаєте, у чому полягають
80 відсотків цінності. Коли ж ви випустите ваш продукт? І тут Scrum
допоможе досягти результату набагато швидше. Коли і що б ви не
робили, вам потрібно передати це в руки безпосередніх користувачів
якомога швидше. Зробити це потрібно навіть до того, як будуть готові
20 відсотків характеристик. Достатньо буде й чогось, що нестиме в
собі хоча б крихітну частинку цінності. Я називаю це мінімально
життєздатним виробом (МЖВ). Це має бути річ, яку ви покажете
публіці на перший раз. Наскільки ефективною вона має бути? Ну, цей
продукт має дійсно працювати, хоча для людини, яка його розробляла,
він може здаватися неоковирним. Вам потрібно демонструвати свій
продукт публіці як тільки це буде можливо! Це дасть вам відгук,
необхідний для посилення вашого циклу прийняття рішень та
розставлення пріоритетів. Назвемо це версією 0.5. Уявіть фотоапарат,
що вже може робити знімки, але поки не здатний фокусуватись. Набір
меблів для їдальні всього з двох стільців. Відправлення вакцини до
п’яти із сотні сіл, яким ви намагаєтесь допомогти. Щось недороблене
майже до сміху.
Але це дає вам відгук. Виявляється, що корпус фотоапарата
насправді незручний, бо кнопка затвора не там, де треба. Дерево, з
якого зроблені стільці, погано пасує до матеріалу обіднього столу.
Через абсолютно зайву соціальну нетактовність ви примудрились
образити старійшин сіл. Завдяки цьому ви дізнаєтеся про помилки,
поки ще не надто пізно, а шкода мінімальна.
Потім, коли ви будете робити офіційний реліз чи розгортати велику
програму, вже виправите виявлені недоліки і знатимете, що люди
дійсно цінують. У прикладі з фотоапаратом може виявитися, що
спочатку користувачі казали про рівну цінність режиму панорамної
зйомки та можливості ділитися світлинами у Фейсбуку. Коли ж вони
дійсно почали користуватися продуктом, то ніколи не вмикали цього
режиму, але постійно хотіли постити фото в соціальних мережах.
Це дозволяє вам упроваджувати передусім характеристики, які
люди цінують, і випускати ваш продукт, коли виконано лише
приблизно 20 відсотків роботи. Ви знаєте, що продукт не ідеальний,
але він дуже близький до ідеалу. Кожна година, витрачена на
непотрібне «вилизування» проекту, є втраченою можливістю для
цінності.
Ризик
В основі будь-якого успішного проекту лежить управління
ризиками. Scrum дозволяє вам суттєво зменшити ризик провалу.
Трьома найпоширенішими різновидами тут є ринковий, технічній та
фінансовий ризики. Щоб було зрозуміліше, треба відповісти на три
питання. Чи хочуть люди те, що ми робимо? Чи дійсно ми можемо це
зробити? Чи дійсно ми можемо продати зроблене?
Про ринковий ризик я писав уже не раз. Scrum допомагає вам
мінімізувати його, просуваючи ідею поетапної здачі проекту. Він
дозволяє вам скоріше представляти продукт клієнтам. Отримуючи ж
ранні й часті відгуки, ви можете вносити невеликі зміни відразу, а не
опинятися потім перед необхідністю великих змін після того, як
вкладете в проект мільйони доларів і зрозумієте, що зробили зовсім не
те, чого насправді хоче клієнт. Дуже часто саме про цю річ клієнт казав
на початку процесу, але в реальності люди не знають, чого насправді
хочуть, доки не зможуть щось випробувати. Багато ділових порад
обертаються навколо швидкого провалу, який допоможе виявити
слабкі місця. Мені ж більше подобається ідея швидкого представлення
проекту клієнтам.
Технічній ризик цікавий. Питання, чи дійсно можливо зробити те,
чого хоче клієнт, доволі непросте. Особливо якщо мова йде про щось
матеріальне, що потребує заводів, інструментів та інвестицій.
Пам’ятаєте компанію, що виробляла систему побутової
автоматики? Так от, вони підійшли до цього, озброївшись так званою
«комплексною конкурентною розробкою». Простою мовою це означає
створення кількох різних прототипів, щоб виявити, який з них працює
найкраще, перш ніж запускати серійне виробництво. Наприклад, вони
знали, що їм потрібна така відеокамера, щоб клієнти бачили, хто
стукає до них у двері, і могли впустити бажаних гостей. Найдорожчою
частиною цієї камери, яка до того ж вимагала найбільше часу на
підготовку, була лінза. Зробити її з пластику? Скла? Кришталю? Який
матеріал витримає будь-які погодні умови? Який буде легко дряпатись?
Який дасть найчіткішу картинку? Скільки кожен із них коштуватиме у
виробництві?
Замість того щоб приймати рішення заздалегідь і кидатись у
виробництво стрімголов, вони створили три різні повністю
функціональні лінзи й провели порівняльні випробування. Оскільки
насправді розробники лише намагалися розв’язати питання з лінзою та
мали зробити це передусім, бо виробництво займало чимало часу, вони
тестували кожну лінзу за допомогою камери для ноутбука. Виявилося,
що найкраще заданим критеріям відповідало скло. При цьому, що дуже
важливо, вони мали змогу прийняти своє рішення, побачивши, як щось
дійсно працює. Їхній вибір базувався не на теоретичних уявленнях.
Вони мали щось, що можна було подивитись і помацати. Розв’язавши
це питання, вони змогли перейти до дизайну корпуса камери, у якому
буде встановлена лінза, та процесорів, що оброблятимуть отримане
зображення. Розставивши пріоритети щодо лінзи, компанія потенційно
зекономила собі мільйони доларів. Відомо, що Apple робить так з
усією своєю продукцією, часто створюючи десяток повністю
функціональних прототипів, а потім обираючи з них найкращий. Це
дає змогу швидкої презентації різних ідей публіці без надмірних
інвестицій.
Фінансовий ризик є тим, що спричиняє крах більшості компаній.
Вони створюють щось класне, але не можуть продати це за достатню
суму, щоб дійсно отримати прибуток. Класичним прикладом цього
є онлайнова журналістика та поступова загибель друкованих видань. З
початком Інтернет-буму в дев’яності роки минулого століття газети з
радістю розміщували свій контент у мережі. Деякі головні редактори
виявили, що навіть онлайн прибутки від реклами залишатимуться,
тому зробили цей контент безкоштовним для читачів. Проблема,
звичайно, полягала в тому, що рекламісти були готові платити за
онлайнову рекламу значно менше грошей, ніж за друковану. При
цьому вартість виготовлення контенту залишалася незмінною. Інші
намагалися встановлювати платний доступ до свого контенту, але в
мережі було стільки сайтів безкоштовних новин, що їм часто
доводилося просто змиритися з цим. Але ж тримати штат репортерів,
які дійсно виїжджатимуть на місце подій та описуватимуть побачене,
коштує дорого. Результат можна бачити у поступовому закритті
відділів новин у всьому світі.
Ідея надання якогось контенту чи сервісу безкоштовно, а
заробляння грошей на рекламі й досі превалює серед технічних
стартапів. Підприємці дивляться на приклад Facebook чи Google
і кажуть: «Я теж так можу». Проблема в тому, що такими успішними
компаніями стають далеко не всі. На початку розквіту Інтернету, коли
онлайновий простір уперше дозволив компаніям охопити конкретні
сегменти цільової аудиторії, «гіперфокусування» вважалося цінним.
Але в міру виникнення дедалі більшої кількості платформ для цього
така можливість дещо втратила актуальність.
Іншим шляхом до фінансового краху компаній є переплата за
приваблення клієнтів. Одним із прикладів цього є компанії, що
пропонують щоденні купони, на кшталт Groupon та Living Social.
Спочатку вони приваблювали клієнтів швидко та легко. Але в міру
розширення зони їхньої досяжності та збільшення клієнтури
приваблювати нових рекламодавців та людей, охочих придбати купон,
ставало дедалі дорожче. Результати можна бачити в оцінках вартості
активів цих компаній.
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
для постачання бідним землеробам сільськогосподарських та ринкових
даних. Результат – подвоєння врожаїв та прибутків для одних із
найбідніших людей на планеті.
Порвіть свої візитівки. Позбудьтеся всіх титулів, менеджерів,
структур. Надайте людям свободу робити те, що вони вважають за
найкраще, а також можливість бути відповідальними за це. Результати
вас приємно здивують.
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,
http://www.drglennwilson.com/ 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).