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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

– А потім?

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

– А потім?

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

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

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

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

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

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

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

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

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

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

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

• квіти

• запрошення

• церква

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