Отже, отримавши свою пачку паперів, Джонсон та Фулгем розставили пріоритети для кожної вимоги. Це було просто життєво необхідно і складніше, ніж здається. Часто люди просто кажуть, що важливе все. Але насправді слід ставити питання, яке й поставили члени команди «Вартового»: що принесе проекту найбільшу цінність? Цим і слід займатися насамперед. У розробці програмного забезпечення є правило, підкріплене десятиліттями досліджень: 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 став по-справжньому ефективним, хтось у вищому керівництві компанії має глибоко зрозуміти, що перешкоди майже рівнозначні злочину. Про те, як позбутись марнування, я розповім вам пізніше в цій книжці. Зараз же буде досить сказати, що ефект усунення зайвого вражає, але люди часто цього не роблять, бо воно потребує чесності із собою та з іншими.
4
Ohno, Taiichi.