© Jeff Sutherland and Scrum, Inc., 2014
© Hemiro Ltd, видання українською мовою, 2016
© Книжковий Клуб «Клуб Сімейного Дозвілля», переклад і художнє оформлення, 2016
Ця надзвичайна книжка демонструє новий спосіб спростити ваше життя та роботу, підвищити концентрацію та виконувати за менший час більше, ніж ви взагалі будь-коли собі уявляли.
Дивовижно… Це повністю переверне уявлення людей про те, наскільки продуктивними вони можуть бути насправді… Джефф Сазерленд розкриває нетехнічному світові елегантно просту систему, якою після винайдення ним Scrum уже давно користуються програмісти та веб-дизайнери. Ця книжка показує, як невелика, сконцентрована та віддана ідеї команда здатна забезпечити значно вищу якість роботи швидшими темпами за рахунок самоаналізу, циклічності та адаптації.
Джефф Сазерленд розписав суть Scrum для широких мас. Ця книжка підносить Scrum від простого інструмента виправлення проблем до способу життя.
Джефф Сазерленд є великим майстром творення високопродуктивних команд. Підзаголовок цієї книжки не розкриває всієї дії Scrum. Якщо ви не потроїте результати за третину витраченого часу, то явно робите щось не так!
Джефф Сазерленд скористався очевидними, але рідко застосовуваними принципами руху якості, зорієнтованого на користувача дизайну та ощадливої розробки, щоб запропонувати методику, яка різко підвищує продуктивність, водночас знижуючи розчарування працівників від типового корпоративного безглуздя. Його книжка є найкращим з усіх описів того, як ця система може працювати в багатьох галузях.
Таємницею Сазерленда щодо подолання професійних та особистих перешкод є підхід до завдань із продуманою увагою та гнучким складом розуму. Ця книжка змінить спосіб, у який ви робите все. Навіть більше: вона допоможе вам почуватися добре в процесі роботи. Просто прочитайте її і починайте робити більше.
Ця оманливо проста система є найпотужнішим з усіх способів покращити ефективність будь-якої команди.
Чому Scrum?
За участю Кена Швабера я створив Scrum іще двадцять років тому як швидший, надійніший та ефективніший метод розроблення програм для технічних галузей. До того часу – та навіть іще у 2005-му – більша частина проектів розробки програмного забезпечення базувалася на каскадній моделі, за якою проект виконувався поетапно та просувався крок за кроком аж до остаточної передачі клієнтам або користувачам. Процес був повільним, непередбачуваним і часто так і не приводив до створення продукту, який люди хотіли чи готові були купувати. Великою проблемою цієї моделі були затримки випуску продуктів – на місяці і навіть на роки. Заздалегідь розроблені покрокові плани, детально викладені в діаграмах Ґантта, переконували керівництво, що процес розробки повністю контрольований, але можна було майже безпомилково сказати, що ми швидко випадемо з графіка та катастрофічно перевищимо бюджет.
Щоб подолати ці проблеми, у 1993 році я винайшов новий спосіб керувати проектами – Scrum, який радикально відрізнявся від директивних низхідних методів минулого. На відміну від них, Scrum більше схожий на еволюційну, адаптивну та саморегульовану систему. Відразу після виникнення він став головним способом створювати нові програми та продукти для технічних галузей. Проте, здобувши визнання та успіх у сфері управління проектами програмного забезпечення та обладнання Силіконової долини, він залишається відносно маловідомим у широкій практиці ведення бізнесу. Саме тому я й написав цю книжку: щоб розкрити та пояснити систему управління проектами Scrum різним компаніям за межами світу високих технологій. У ній я розповім про витоки Scrum із виробничої системи компанії Toyota та принципу ООВД (Оглядати – Орієнтуватись – Вирішувати – Діяти), прийнятого в бойовій авіації. Я покажу вам, як ми використовуємо для виконання проектів невеликі команди і чому це є таким ефективним способом роботи. Я поясню, як ми розставляємо пріоритети в проектах, організовуємо однотижневі або одномісячні спринти для підтримки робочого ритму та відповідальності всіх членів команди, проводимо короткі щоденні обговорення зробленого та викликів, що неминуче виникають. Крім того, ви побачите, як Scrum поєднує концепції безперервного покращення та представлення мінімально функціональних продуктів для отримання негайного відгуку від споживачів – замість очікування, доки проект буде повністю завершено. Як ви дізнаєтесь нижче, ми маємо досвід застосування Scrum абсолютно для всього: від виробництва доступних автомобілів, витрата пального в яких становить один літр на сорок кілометрів, до вдосконалення баз даних ФБР до рівня ХХІ століття.
Дочитайте цю книжку до кінця. Думаю, ви зрозумієте, як описаний у ній підхід може допомогти трансформувати весь лад роботи, творення нових продуктів, планування та самого мислення вашої компанії. Я твердо вірю, що за допомогою Scrum можна радикально змінити діяльність підприємства практично в будь-якій галузі. Так само, як цей підхід уже здійснив революцію у сфері інновацій та швидкості, дозволивши вийти на ринок багатьом чудовим молодим компаніям, а також уможлививши неймовірний асортимент нових продуктів із Силіконової долини та світу високих технологій.
Джефф Сазерленд
Джефф Джонсон абсолютно не чекав від того дня нічого доброго. 3 березня 2010 року Федеральне бюро розслідувань США вирішило згорнути свій найбільший та найамбітніший проект модернізації програмного забезпечення. Передбачалося, що він дозволить не допустити надалі подій на кшталт терактів 11 вересня, але його спіткав один із найграндіозніших провалів усіх часів. ФБР намагалось удосконалити свою комп’ютерну систему вже більш ніж десять років, і ця спроба, схоже, вчергове зазнавала краху. Знову. І цього разу вона була дітищем Джонсона.
Джефф прийшов у Бюро лише за сім місяців до того, піддавшись на пропозицію нового керівника інформаційної служби Чеда Фулгема, з яким він раніше працював у банку Lehman Brothers. Джонсон став заступником начальника управління інформаційних технологій та отримав кабінет на верхньому поверсі будівлі Едгара Гувера – штаб-квартири ФБР у центрі Вашингтона. То був чудовий, просторий кабінет. З нього навіть відкривався вид на монумент Вашингтона. Джефф тоді й подумати не міг, що більшу частину двох наступних років проведе в бетонному підвалі, у тісній кімнатці без вікон, намагаючись виправити те, що всі вважали невиправним.
Джефф та його бос вирішили визнати свою поразку і згорнути розробку програми, яка вже забрала близько десяти років і коштувала сотні мільйонів доларів. На той момент було більше сенсу зробити проект внутрішньою справою інформаційного відділу й займатися ним далі самотужки. «Це було непросте рішення, – каже він. – Проте роботу слід було зробити, і то зробити добре».
Проект являв собою довгоочікувану комп’ютерну систему, що мала ввести ФБР у сучасну еру. Річ у тім, що у 2010 році – в еру Фейсбуку, Твітеру, Amazon та Google – ФБР усе ще складало більшу частину своїх звітів на папері. Прийнята на той час у Бюро система називалась «Автоматизована підтримка слідчих справ» і працювала на величезних ЕОМ, що були останнім словом техніки ще в далекі вісімдесяті. Багато спеціальних агентів до них навіть не підходили. Надто вже громіздкою й повільною була ця система в епоху терористичних атак та злочинців, які не сидять на одному місці.
Коли якийсь агент ФБР хотів щось зробити – по суті, будь-що: заплатити інформаторові, вистежити терориста, скласти звіт на грабіжника банків, – то процедура не надто відрізнялася від тієї, що діяла тридцятьма роками раніше. Джонсон описує її так: «Ви складали документ у текстовому редакторі та роздруковували три примірники. Один треба було надіслати на затвердження. Другий зберігався на місці на випадок, якщо перший загубиться. А з третім необхідно було взяти червону ручку – я не жартую, червону ручку – та обвести на ньому ключові слова для занесення до бази даних. Ви складали покажчик власного звіту».
Якщо запит затверджували, перший примірник повертався згори з присвоєним йому номером. Ви здивовані? Так, документообіг ФБР вівся за допомогою простого номера, проставленого на аркуші. Цей метод був настільки застарілим та уразливим, що саме на нього поклали частину провини за те, що Бюро не змогло додати два і два й виявити членів «Аль-Каїди», які в’їхали до країни за кілька тижнів чи місяців до 11 вересня. Один відділ був зайнятим своїм підозрюваним. У другому намагались розібратися, чому стільки підозрілих іноземців раптом забажали повчитися на пілотів. У третьому стежили ще за кимось, але нікому про це не казали. Проблема полягала в тому, що ніхто в Бюро не зумів вчасно звести все це докупи.
Після терактів 11 вересня було створено спеціальну комісію Сенату, яка намагалася виявити основну причину, чому це сталося. Так от, на думку цієї комісії, аналітики просто не змогли отримати доступ до інформації, яку повинні були проаналізувати. У звіті сказано: «Жалюгідний стан інформаційної системи ФБР призвів до того, що такий доступ великою мірою залежав від особистих стосунків аналітика з членами оперативних підрозділів та груп, які мали цю інформацію».
До трагічних подій 11 вересня в ФБР навіть не думали про проведення комплексної оцінки терористичної загрози Сполученим Штатам. Для цього було багато причин – від зосередження окремих співробітників на кар’єрному зростанні до поганого обміну інформацією. Але, мабуть, ключовою причиною такого значного провалу напередодні масових терористичних атак звіт назвав технічну недосконалість Бюро. «Інформаційні системи ФБР жахливо застаріли, – йдеться у висновку комісії. – ФБР не вистачило здатності знати про все, що воно знало: не було ефективного механізму відстеження та обміну основними даними».
Коли сенатори почали ставити Бюро незручні запитання, там зазвичай відповідали: «Не хвилюйтесь, ми вже розробляємо план модернізації». Цей план здобув назву «Віртуальні слідчі справи» і мав усе змінити. Не бажаючи втратити зиск навіть із кризи, чиновники заявили, що їм потрібні ще 70 мільйонів доларів на додачу до 100 мільйонів, уже передбачених бюджетом для реалізації плану. Якщо почитати тогочасну пресу, ви побачите, що слова революційний та перетворення лилися просто рікою.
Але три роки потому програму згорнули. Вона просто не працювала. Ані на йоту. ФБР витратило цілих 170 мільйонів доларів платників податків, щоб купити комп’ютерну систему, якою так і не скористалося – жодним рядком коду, додатком чи кліком мишки. Увесь проект виявився однією суцільною катастрофою. І то була не просто якась рядова технічна помилка IBM чи Microsoft. На кону буквально стояли людські життя. Як сказав тоді газеті Washington Post сенатор від штату Вермонт Патрік Ліхі, головний демократ у юридичному комітеті Сенату:
У нас була інформація, що могла зупинити 11 вересня. Вона лежала там і була незадіяна… Я не побачив, щоб вони виправили проблеми… Поки ми опануємо технології двадцять першого століття, може вже настати двадцять друге[1].
Показово, що багато людей, які працювали у ФБР на час провалу «Віртуальних слідчих справ», більше там не працюють.
У 2005 році ФБР анонсувало запуск нової програми «Вартовий». Цього разу вона вже мала запрацювати. Цього разу вони вживуть необхідних запобіжних заходів, залучать відповідні бюджетні процедури, правильні засоби контролю. Вони засвоїли свій урок. Ціна питання? Усього якийсь там 451 мільйон доларів. І до 2009-го все повністю запрацює.
Що тут могло піти не так? У березні 2010 року відповідь лягла Джеффові Джонсону на стіл. Компанія Lockheed Martin, підрядник, найнятий для розробки системи «Вартовий», уже витратила 405 мільйонів доларів. При цьому вони розробили лише половину проекту, і то спізнившись у своїй роботі на цілий рік. Незалежний аналіз показав, що для закінчення проекту їм потрібно ще 6–8 років, а платникам податків доведеться викинути на це щонайменше 350 мільйонів доларів додатково.
І Джонсон мав щось із цим робити.
Що ж тоді пішло не так і як ситуацію вдалося виправити? Відповіді на ці питання якраз і спонукали мене написати цю книжку. Проблема полягала не в дурнях. Не можна сказати, що в Бюро не вистачало компетентного персоналу чи необхідних технологій. Усе гаразд було й з робочою етикою та здоровою конкуренцією.
Головною проблемою був спосіб роботи. Саме так, спосіб роботи більшості людей. Проблема полягала в тому, яким чином ми вважаємо за потрібне виконувати роботу, бо нас так учили.
Коли чуєш, що сталося, спершу все здається цілком логічним. Перед тим як братися за контракт, співробітники Lockheed вивчили вимоги замовника та почали планувати створення системи, яка буде на все це здатна. Було задіяно багато розумних людей, які довгі місяці працювали над визначенням того, що треба зробити. Потім вони витратили ще місяці на планування того, як це зробити. Вони підготували чудові графіки, позначивши там усе, чого слід досягти, та час, який займе виконання кожного завдання. Після цього, ретельно дібравши кольори, вони зобразили всі частини проекту, які переходили одна в одну у вигляді каскаду.
Каскадна модель
Такі графіки називаються діаграмами Ґантта, на честь американського інженера Генрі Ґантта, який їх розробив. З появою в 1980-х персональних комп’ютерів, які спростили творення цих складних графіків і дозволили робити їх дійсно комплексними, вони перетворилися на справжні витвори мистецтва. Тепер кожен крок у проекті детально презентується. Кожна віха. Кожна дата випуску. Ці графіки насправді вражають. Єдина проблема з ними – в тому, що вони абсолютно завжди неправильні.
Генрі Ґантт винайшов свої знамениті діаграми приблизно у 1910 році. Уперше їх використав під час Першої світової війни генерал Вільям Крузер, начальник служби постачання та техобслуговування армії США. Ті, хто вивчав історію тієї війни, знають, що ефективна організація точно не була її характерною рисою. Я так і не зміг зрозуміти, чому артефакт Першої світової де-факто став інструментом, який активно використовують для управління проектами у ХХІ столітті. Ми начебто не ведемо більше «окопних» війн, але деякі ідеї, що лежали в їхній основі, з якогось дива популярні й досі.
А просто це здається дуже заманливим: уся робота, яку потрібно виконати для реалізації масштабного проекту, презентується на загальний огляд. Я бував у багатьох компаніях, де єдиним завданням кількох співробітників є щоденне оновлення діаграм Ґантта. Проблема в тому, що як тільки цей план зустрічається з реальністю, то тріщить по всіх швах. Але замість того, щоб викинути на смітник і сам план, і його ідею, менеджери наймають під нього людей, роблячи вигляд, що все чудово працює. По суті, вони платять фахівцям, щоб ті їм брехали.
Ця невдала схема нагадує звіти, які отримувало радянське Політбюро 1980-х перед самим розпадом СРСР. Повний міраж. Як і тоді, сьогодні звіти стали важливішими за дійсність, яку вони мають описувати, і якщо виникає якась невідповідність, винною вважається саме дійсність, а не діаграми.
Колись давно, коли я був кадетом Військової академії Вест-Пойнт, я спав у колишній кімнаті Дуайта Ейзенхауера. Уночі мене іноді будило світло вуличних ліхтарів, яке відбивалось від золотої таблички над каміном. Там було написано: «Тут спав Дуайт Д. Ейзенхауер». Так от, я пригадую, цей президент якось зазначив, що планувати бій важливо, але варто лише прогриміти першим пострілам, як ваш план іде за вітром. Принаймні йому вистачало здорового глузду не використовувати діаграм Ґантта.
Отже, Lockheed представив ФБР усі ці гарненькі графіки, і Бюро їх прийняло. Начебто цього разу завдання було розплановане настільки добре, що завадити успіху не могло ніщо. «Дивіться, тут вам і різнокольорові позначки, і розмітка часу, і гістограми».
Проте коли Джефф та його бос, голова інформаційної служби Чед Фулгем, поглянули на план навесні 2010 року, то зрозуміли, що дива не сталось: усі ці діаграми були нескінченно далекими від дійсності. Розглянувши реальний стан справ, ці двоє усвідомили, що розв’язати проблему просто неможливо. Нові дефекти програмного забезпечення виявлялися швидше, ніж вдавалося виправити старі.
Чед доповів генеральному інспекторові Міністерства юстиції, що вони зможуть завершити проект «Вартовий», узявши його розробку на себе та зменшивши кількість розробників. За рахунок цього вони виконають найскладнішу половину проекту більш ніж уп’ятеро швидше, витративши менш ніж десяту частину бюджетних грошей. Скептицизм у зазвичай сухих звітах інспектора для Конгресу можна було просто-таки відчути на дотик. У жовтні 2010 року, виклавши свої перестороги в дев’яти пунктах, цербери генерального інспектора підбили підсумок: «Загалом, ми маємо великі сумніви стосовно здатності цього нового підходу завершити проект „Вартовий“ у межах бюджету, вчасно та не з гіршою, ніж зараз, функціональністю…[2]»
Цей новий підхід називається Scrum. Я створив його двадцять років тому. На сьогодні це єдиний перевірений спосіб, здатний дати раду такого роду проектам. Існують два способи управління проектами: старий «каскадний», який марнує сотні мільйонів доларів і часто не дає на виході геть нічого, і новий, який із меншою кількістю людей та за менший час може дати більший результат кращої якості, без витрат великих коштів. Я знаю, це здається надто хорошим, щоб бути правдою, але результати впровадження Scrum говорять самі за себе. Він дійсно працює.
Двадцять років тому я перебував у справжньому розпачі, нагально потребуючи нового способу мислення щодо роботи. Перелопативши тонни досліджень та експериментів, передивившись гори отриманих раніше даних, я зрозумів, що новий спосіб організації людської діяльності потрібен нам усім. У цьому не було чогось надзвичайного, адже в минулому цю проблему порушували не раз і не двічі. Пошукам ефективних способів організації праці були присвячені ще дослідження часів Другої світової війни. Але з тих чи інших причин люди так і не змогли зібрати окремі ідеї докупи. Я намагався зробити це протягом більш ніж двадцяти років, після чого мені вдалося створити систему, дуже поширену сьогодні в першій сфері, для якої я її застосував, – розробці програмного забезпечення. Від таких гігантів, як Google, Amazon та Salesforce.com, до дрібних стартапів, про які ви поки що не чули, ця система радикально змінила підхід людей до виконання поставлених у роботі завдань.
Причина ефективності цієї системи проста. Я взяв…