Кінцевим результатом застосування 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 працює шляхом визначення послідовних цілей, яких потрібно досягати у фіксований проміжок часу. У випадку ФБР було вирішено задіяти двотижневі цикли, де передбачено, що наприкінці кожного циклу буде готовий продукт. Це означало, що вони матимуть щось робоче, щось, що можна буде показати всім охочим, особливо зацікавленій стороні та, в ідеалі, людям, які фактично будуть цим користуватись.