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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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