Причина ефективності цієї системи проста. Я взяв до уваги те, як люди дійсно працюють, а не те, що вони про це кажуть. Я врахував результати досліджень за десятки років та найкращі практики компаній з усього світу і детально вивчив досвід найефективніших команд усередині цих компаній. Що дозволило їм досягти успіху? Що відрізняло їх від інших? Чому одні команди стають найкращими, а інші залишаються посередніми?
З певних причин, про які я детальніше розповім у наступних розділах, ця система підвищення ефективності команд отримала назву Scrum. Цей спортивний термін, що означає гуртування навколо мяча в регбі, чудово відображує спосіб співпраці членів команди для пересування полем. Він потребує злагодженості дій, єдності мети та чіткого розуміння необхідності її спільного досягнення. Це ідеальна метафора для того, чого я хочу від командної роботи.
Зазвичай у ході роботі над будь-яким проектом менеджмент хоче бачити дві речі: контроль та передбачуваність. Це веде до появи величезної кількості документів, графіків та діаграм, як це було у випадку з Lockheed. Здавалося б, на планування кожної деталі йдуть місяці зусиль, тому не буде жодної помилки, жодного перевищення бюджету і все буде готове вчасно.
Проблема в тому, що такі райдужні сценарії ніколи не реалізовуються. Як правило, всі зусилля, витрачені на планування, спроби обмежити відхилення від прийнятого курсу та передбачити непередбачуване просто марнуються. Адже кожен проект несе із собою виявлення нових проблем та вибухи натхнення. Намагання звести людську діяльність будь-якого масштабу до кольорових графіків та діаграм не мають жодного сенсу і приречені на провал. Вони не мають нічого спільного з тим, як працюють люди й виконуються проекти. Визрівання слушних ідей та здійснення великих справ відбувається точно не так.
Навпаки, такі обмеження призводять до розгубленості людей, які вже самі не розуміють, чого вони хочуть. Проекти затягуються, виходять за межі бюджету і в надто багатьох випадках закінчуються безславним згортанням. Це особливо стосується команд, залучених до роботи зі створення чогось нового. Більшу частину часу менеджмент ніяк не може усвідомити, що все поступово котиться зі схилу, аж доки не змарнує мільйони доларів і тисячі годин безрезультатної праці.
Scrum порушує питання про те, чому робота має віднімати саме стільки часу й зусиль і чому ми так погано вміємо визначати їх заздалегідь. На будівництво Шартрського собору пішло пятдесят сім років. Так от, я можу заприсягтись, що на початку будівництва каменярі подивились на єпископа й сказали: «Двадцять років максимум. Можливо, впораємось і за пятнадцять».
Scrum вітає непевність і творчість. Ця система закладає підвалини процесу пізнання, що дозволяє командам оцінювати не лише те, що вони створили, але й (не менш важливо) як вони це створили. Спираючись на справжню роботу команд, Scrum дає їм інструменти для самоорганізації та швидкого покращення швидкості та якості їхньої роботи.
У своїй основі Scrum базується на простій ідеї: хоч коли почався проект, чому б регулярно не перевіряти, що він іде в правильному напрямку та дійсно відповідає прагненням людей? Непогано також ставити собі питання, чи існують якісь способи покращити вашу роботу, виконувати її якісніше та швидше, а також що може вам у цьому заважати.
Це називається циклом перевірки та адаптації. Як тільки випадає вільна хвилинка, треба зупинятись, переглядати вже зроблене, перевіряти його відповідність визначеним раніше вимогам та шукати шляхів покращення своїх дій. Це проста ідея, але її впровадження потребує уваги, самоаналізу, щирості та дисципліни. Я пишу цю книгу, щоб показати вам, як це робиться. І не лише в компаніях з розробки програмного забезпечення. Я бачив, як Scrum успішно застосовували для випуску автомобілів, управління пральнею, навчання студентів, виготовлення космічних кораблів, планування весілля навіть як його застосовувала моя дружина, щоб проконтролювати виконання мною всіх домашніх справ на вихідні.
Кінцевим результатом застосування Scrum метою його розробки, якщо хочете, є різке покращення продуктивності команд. За останні двадцять років я створював такі команди безліч разів. Я побував генеральним директором, технічним директором чи головним інженером десятка компаній, від дрібних стартапів з кількома людьми в одній кімнатці до великих підприємств із представництвами, розкиданими по всій планеті. А вже консультантом та тренером я працював іще в кількох сотнях різних фірм.
Результати, буває, настільки вражають, що, на думку провідних дослідницьких та аналітичних фірм (таких як Gartner, Forrester Research та Standish Group), старий стиль роботи вже можна сміливо відкинути й забути. Компанії, які все ще чіпляються за давно відомі, але неефективні ідеї управління та контролю, мріючи про чітку передбачуваність, просто приречені на провал, якщо їхні конкуренти використовують Scrum. Надто вже велика між ними різниця. Наприклад, у фірмі OpenView Venture Partners із Бостона, де я працюю консультантом, кажуть, що Scrum пропонує надто велику конкурентну перевагу, щоб нею не скористатись. Люди, які там працюють, зовсім не білі й пухнасті. Це холодні ділки, але вони просто кажуть: «Результати беззаперечні. Компанії мають лише два варіанти: змінюйтесь або помріть».
Розвязання проблеми ФБР
Першою проблемою, з якою зіткнулась у ФБР команда проекту «Вартовий», були контракти. Адже кожна найменша зміна програми закінчувалася контрактними переговорами з Lockheed Martin. Тому Джефф Джонсон та Чед Фулгем витратили місяці, розплутуючи всі контракти, беручи розробку на себе та скорочуючи штат із кількох сотень працівників до пятдесяти. Основна команда вийшла в них ще меншою.
Увесь перший тиждень вони займалися тим, що робить багато людей у таких обставинах: роздруковували всі документи з вимогами. Якщо ви ніколи не бачили, на що це схоже у великих проектах, то це можуть бути сотні й сотні сторінок. Я сам бачив стоси ледь не в метр заввишки. Проект за проектом люди вирізають та вставляють у текст одні й ті самі стандартні фрази, а потім ті купи паперу ніхто не читає. Це просто фізично неможливо. Але стара система змушує людей діяти саме так.
«Там було 1100 вимог. Стос вийшов завтовшки з десять сантиметрів», каже Джонсон. Особисто в мене сама думка про ці документи викликає співчуття до людей, які, мабуть, витратили кілька тижнів свого життя, готуючи те, що не мало жодної мети. ФБР та Lockheed Martin не одні такі я бачив повторення цього ледь не в кожній компанії, де працював. Ця товста пачка непотребу якраз і є однією з причин, чому впровадження Scrum може стати для людей такою потужною зміною. Ніхто не повинен витрачати своє життя на безцільну роботу. Це погано не лише для бізнесу це вбиває душу.
«Там було 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-місячну обіцянку Джонсона було дано з певною натяжкою. Адже насправді вони не знали, коли закінчать, просто не могли знати. По суті, ніхто в ФБР навіть не здогадувався, як швидко здатні працювати їхні команди. Саме про це я постійно кажу керівникам різного роду підприємств: «Я знатиму дату завершення проекту, коли побачу ступінь прогресу членів команди. Як швидко вони просуватимуться вперед. Наскільки вони прискоряться».