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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

І Джонсон мав щось із цим робити.

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

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

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

Каскадна модель

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Джефф Джонсон розумів, що зайнятися цим доведеться саме йому.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

– А як ми його назвемо? – питає свиня.

– Може, «Яєчня з беконом»?

– Ні, дякую, – каже свиня. – Я тоді буду зайнята повністю, а ти лише долучишся!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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