Текст бизнес-книги "Scrum. Навчись робити вдвічі більше за менший час"

Автор книги: Анатолий Верчинский

Раздел: Управление и подбор персонала, Бизнес-книги

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

– Не знаю, – відповів він. – Чому б вам не спробувати це й не повідомити мені, що із цього вийшло?

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

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

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

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

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

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

– Скільки діаграм Ґантта ви бачили за свою кар’єру? – спитав я.

– Сотні, – сказав він.

– А скільки з них справдилися?

– Жодної, – відповів він після паузи.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Шу-Ха-Рі

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


[Закрыть].

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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