Scrum. Навчись робити вдвiчi бiльше за менший час
Джефф Сазерленд


«SCRUM – найкращий спосiб з-помiж усiх, якi я знаю, щоб керувати великими й малими проектами, i, безперечно, вiн придатний для застосування й поза межами сфери ІТ». Адам Мессинджер, технiчний директор Twitter Пiдвищити ефективнiсть працi вдвiчi? Звучить, як фантастика, проте це щоденна реальнiсть для тих, хто вже живе у свiтi Scrum! Ця нова, революцiйна стратегiя органiзацii працi, створена двадцять рокiв тому Джеффом Сазерлендом для розробникiв програмного забезпечення, продовжуе доводити свою генiальнiсть пiд час вдосконалення баз даних ФБР та виробництва доступних автiвок, що проiжджають 160 км на 4 лiтрах пального, будiвництва космiчних кораблiв або ж планування весiлля чи ремонту будинку. Ця книга – розповiдь автора про народження та вдосконалення iдеi Scrum – новоi системи цiнностей, у якiй люди важливiшi за процеси, а реакцiя на змiни суттевiша, нiж дотримання плану.





Джефф Сазерленд

Scrum

Навчись робити вдвiчi бiльше за менший час



© Jeff Sutherland and Scrum, Inc., 2014

© Hemiro Ltd, видання украiнською мовою, 2016

© Книжковий Клуб «Клуб Сiмейного Дозвiлля», переклад i художне оформлення, 2016




Вiдгуки про книжку




Ця надзвичайна книжка демонструе новий спосiб спростити ваше життя та роботу, пiдвищити концентрацiю та виконувати за менший час бiльше, нiж ви взагалi будь-коли собi уявляли.

    Брайан Трейсi, автор бестселера «Зроби це зараз»



Дивовижно… Це повнiстю переверне уявлення людей про те, наскiльки продуктивними вони можуть бути насправдi… Джефф Сазерленд розкривае нетехнiчному свiтовi елегантно просту систему, якою пiсля винайдення ним Scrum уже давно користуються програмiсти та веб-дизайнери. Ця книжка показуе, як невелика, сконцентрована та вiддана iдеi команда здатна забезпечити значно вищу якiсть роботи швидшими темпами за рахунок самоаналiзу, циклiчностi та адаптацii.

    Майкл Менгi, старший вiце-президент з iнтерактивних технологiй Social@Ogilvy



Джефф Сазерленд розписав суть Scrum для широких мас. Ця книжка пiдносить Scrum вiд простого iнструмента виправлення проблем до способу життя.

    Гiротака Такеучi, професор управлiнських практик Гарвардськоi школи бiзнесу



Джефф Сазерленд е великим майстром творення високопродуктивних команд. Пiдзаголовок цiеi книжки не розкривае всiеi дii Scrum. Якщо ви не потроiте результати за третину витраченого часу, то явно робите щось не так!

    Скотт Максвелл, засновник та старший виконавчий директор OpenView Venture Partners



Джефф Сазерленд скористався очевидними, але рiдко застосовуваними принципами руху якостi, зорiентованого на користувача дизайну та ощадливоi розробки, щоб запропонувати методику, яка рiзко пiдвищуе продуктивнiсть, водночас знижуючи розчарування працiвникiв вiд типового корпоративного безглуздя. Його книжка е найкращим з усiх описiв того, як ця система може працювати в багатьох галузях.

    Джеффрi Пфеффер, професор Стенфордськоi школи бiзнесу та спiвавтор книжки «Вiд знання до справи»



Таемницею Сазерленда щодо подолання професiйних та особистих перешкод е пiдхiд до завдань iз продуманою увагою та гнучким складом розуму. Ця книжка змiнить спосiб, у який ви робите все. Навiть бiльше: вона допоможе вам почуватися добре в процесi роботи. Просто прочитайте ii i починайте робити бiльше.

    Арнольд В. Стронг, генеральний директор BrightNeighbor.com та полковник запасу армii США



Ця оманливо проста система е найпотужнiшим з усiх способiв покращити ефективнiсть будь-якоi команди.

    Лео Бабаута, творець блогу ZenHabits.net




Scrum

Навчись робити вдвiчi бiльше за менший час





Передмова


Чому Scrum?

За участю Кена Швабера я створив Scrum iще двадцять рокiв тому як швидший, надiйнiший та ефективнiший метод розроблення програм для технiчних галузей. До того часу – та навiть iще у 2005-му – бiльша частина проектiв розробки програмного забезпечення базувалася на каскаднiй моделi, за якою проект виконувався поетапно та просувався крок за кроком аж до остаточноi передачi клiентам або користувачам. Процес був повiльним, непередбачуваним i часто так i не приводив до створення продукту, який люди хотiли чи готовi були купувати. Великою проблемою цiеi моделi були затримки випуску продуктiв – на мiсяцi i навiть на роки. Заздалегiдь розробленi покроковi плани, детально викладенi в дiаграмах Гантта, переконували керiвництво, що процес розробки повнiстю контрольований, але можна було майже безпомилково сказати, що ми швидко випадемо з графiка та катастрофiчно перевищимо бюджет.

Щоб подолати цi проблеми, у 1993 роцi я винайшов новий спосiб керувати проектами – Scrum, який радикально вiдрiзнявся вiд директивних низхiдних методiв минулого. На вiдмiну вiд них, Scrum бiльше схожий на еволюцiйну, адаптивну та саморегульовану систему. Вiдразу пiсля виникнення вiн став головним способом створювати новi програми та продукти для технiчних галузей. Проте, здобувши визнання та успiх у сферi управлiння проектами програмного забезпечення та обладнання Силiконовоi долини, вiн залишаеться вiдносно маловiдомим у широкiй практицi ведення бiзнесу. Саме тому я й написав цю книжку: щоб розкрити та пояснити систему управлiння проектами Scrum рiзним компанiям за межами свiту високих технологiй. У нiй я розповiм про витоки Scrum iз виробничоi системи компанii Toyota та принципу ООВД (Оглядати – Орiентуватись – Вирiшувати – Дiяти), прийнятого в бойовiй авiацii. Я покажу вам, як ми використовуемо для виконання проектiв невеликi команди i чому це е таким ефективним способом роботи. Я поясню, як ми розставляемо прiоритети в проектах, органiзовуемо однотижневi або одномiсячнi спринти для пiдтримки робочого ритму та вiдповiдальностi всiх членiв команди, проводимо короткi щоденнi обговорення зробленого та викликiв, що неминуче виникають. Крiм того, ви побачите, як Scrum поеднуе концепцii безперервного покращення та представлення мiнiмально функцiональних продуктiв для отримання негайного вiдгуку вiд споживачiв – замiсть очiкування, доки проект буде повнiстю завершено. Як ви дiзнаетесь нижче, ми маемо досвiд застосування Scrum абсолютно для всього: вiд виробництва доступних автомобiлiв, витрата пального в яких становить один лiтр на сорок кiлометрiв, до вдосконалення баз даних ФБР до рiвня ХХІ столiття.

Дочитайте цю книжку до кiнця. Думаю, ви зрозумiете, як описаний у нiй пiдхiд може допомогти трансформувати весь лад роботи, творення нових продуктiв, планування та самого мислення вашоi компанii. Я твердо вiрю, що за допомогою Scrum можна радикально змiнити дiяльнiсть пiдприемства практично в будь-якiй галузi. Так само, як цей пiдхiд уже здiйснив революцiю у сферi iнновацiй та швидкостi, дозволивши вийти на ринок багатьом чудовим молодим компанiям, а також уможлививши неймовiрний асортимент нових продуктiв iз Силiконовоi долини та свiту високих технологiй.

Джефф Сазерленд




Роздiл 1. Спосiб, у який працюе свiт, – недосконалий



Джефф Джонсон абсолютно не чекав вiд того дня нiчого доброго. 3 березня 2010 року Федеральне бюро розслiдувань США вирiшило згорнути свiй найбiльший та найамбiтнiший проект модернiзацii програмного забезпечення. Передбачалося, що вiн дозволить не допустити надалi подiй на кшталт терактiв 11 вересня, але його спiткав один iз найграндiознiших провалiв усiх часiв. ФБР намагалось удосконалити свою комп’ютерну систему вже бiльш нiж десять рокiв, i ця спроба, схоже, вчергове зазнавала краху. Знову. І цього разу вона була дiтищем Джонсона.

Джефф прийшов у Бюро лише за сiм мiсяцiв до того, пiддавшись на пропозицiю нового керiвника iнформацiйноi служби Чеда Фулгема, з яким вiн ранiше працював у банку Lehman Brothers. Джонсон став заступником начальника управлiння iнформацiйних технологiй та отримав кабiнет на верхньому поверсi будiвлi Едгара Гувера – штаб-квартири ФБР у центрi Вашингтона. То був чудовий, просторий кабiнет. З нього навiть вiдкривався вид на монумент Вашингтона. Джефф тодi й подумати не мiг, що бiльшу частину двох наступних рокiв проведе в бетонному пiдвалi, у тiснiй кiмнатцi без вiкон, намагаючись виправити те, що всi вважали невиправним.

Джефф та його бос вирiшили визнати свою поразку i згорнути розробку програми, яка вже забрала близько десяти рокiв i коштувала сотнi мiльйонiв доларiв. На той момент було бiльше сенсу зробити проект внутрiшньою справою iнформацiйного вiддiлу й займатися ним далi самотужки. «Це було непросте рiшення, – каже вiн. – Проте роботу слiд було зробити, i то зробити добре».

Проект являв собою довгоочiкувану комп’ютерну систему, що мала ввести ФБР у сучасну еру. Рiч у тiм, що у 2010 роцi – в еру Фейсбуку, Твiтеру, Amazon та Google – ФБР усе ще складало бiльшу частину своiх звiтiв на паперi. Прийнята на той час у Бюро система називалась «Автоматизована пiдтримка слiдчих справ» i працювала на величезних ЕОМ, що були останнiм словом технiки ще в далекi вiсiмдесятi. Багато спецiальних агентiв до них навiть не пiдходили. Надто вже громiздкою й повiльною була ця система в епоху терористичних атак та злочинцiв, якi не сидять на одному мiсцi.

Коли якийсь агент ФБР хотiв щось зробити – по сутi, будь-що: заплатити iнформаторовi, вистежити терориста, скласти звiт на грабiжника банкiв, – то процедура не надто вiдрiзнялася вiд тiеi, що дiяла тридцятьма роками ранiше. Джонсон описуе ii так: «Ви складали документ у текстовому редакторi та роздруковували три примiрники. Один треба було надiслати на затвердження. Другий зберiгався на мiсцi на випадок, якщо перший загубиться. А з третiм необхiдно було взяти червону ручку – я не жартую, червону ручку – та обвести на ньому ключовi слова для занесення до бази даних. Ви складали покажчик власного звiту».

Якщо запит затверджували, перший примiрник повертався згори з присвоеним йому номером. Ви здивованi? Так, документообiг ФБР вiвся за допомогою простого номера, проставленого на аркушi. Цей метод був настiльки застарiлим та уразливим, що саме на нього поклали частину провини за те, що Бюро не змогло додати два i два й виявити членiв «Аль-Каiди», якi в’iхали до краiни за кiлька тижнiв чи мiсяцiв до 11 вересня. Один вiддiл був зайнятим своiм пiдозрюваним. У другому намагались розiбратися, чому стiльки пiдозрiлих iноземцiв раптом забажали повчитися на пiлотiв. У третьому стежили ще за кимось, але нiкому про це не казали. Проблема полягала в тому, що нiхто в Бюро не зумiв вчасно звести все це докупи.

Пiсля терактiв 11 вересня було створено спецiальну комiсiю Сенату, яка намагалася виявити основну причину, чому це сталося. Так от, на думку цiеi комiсii, аналiтики просто не змогли отримати доступ до iнформацii, яку повиннi були проаналiзувати. У звiтi сказано: «Жалюгiдний стан iнформацiйноi системи ФБР призвiв до того, що такий доступ великою мiрою залежав вiд особистих стосункiв аналiтика з членами оперативних пiдроздiлiв та груп, якi мали цю iнформацiю».

До трагiчних подiй 11 вересня в ФБР навiть не думали про проведення комплексноi оцiнки терористичноi загрози Сполученим Штатам. Для цього було багато причин – вiд зосередження окремих спiвробiтникiв на кар’ерному зростаннi до поганого обмiну iнформацiею. Але, мабуть, ключовою причиною такого значного провалу напередоднi масових терористичних атак звiт назвав технiчну недосконалiсть Бюро. «Інформацiйнi системи ФБР жахливо застарiли, – йдеться у висновку комiсii. – ФБР не вистачило здатностi знати про все, що воно знало: не було ефективного механiзму вiдстеження та обмiну основними даними».

Коли сенатори почали ставити Бюро незручнi запитання, там зазвичай вiдповiдали: «Не хвилюйтесь, ми вже розробляемо план модернiзацii». Цей план здобув назву «Вiртуальнi слiдчi справи» i мав усе змiнити. Не бажаючи втратити зиск навiть iз кризи, чиновники заявили, що iм потрiбнi ще 70 мiльйонiв доларiв на додачу до 100 мiльйонiв, уже передбачених бюджетом для реалiзацii плану. Якщо почитати тогочасну пресу, ви побачите, що слова революцiйний та перетворення лилися просто рiкою.

Але три роки потому програму згорнули. Вона просто не працювала. Анi на йоту. ФБР витратило цiлих 170 мiльйонiв доларiв платникiв податкiв, щоб купити комп’ютерну систему, якою так i не скористалося – жодним рядком коду, додатком чи клiком мишки. Увесь проект виявився однiею суцiльною катастрофою. І то була не просто якась рядова технiчна помилка IBM чи Microsoft. На кону буквально стояли людськi життя. Як сказав тодi газетi Washington Post сенатор вiд штату Вермонт Патрiк Лiхi, головний демократ у юридичному комiтетi Сенату:



У нас була iнформацiя, що могла зупинити 11 вересня. Вона лежала там i була незадiяна… Я не побачив, щоб вони виправили проблеми… Поки ми опануемо технологii двадцять першого столiття, може вже настати двадцять друге[1 - Eggen, Dan, and Griff Witte. «The FBI’s Upgrade That Wasn’t; $170 Million Bought an Unusable Computer System.» Washington Post, 18 серпня 2006 р.: A1.].


Показово, що багато людей, якi працювали у ФБР на час провалу «Вiртуальних слiдчих справ», бiльше там не працюють.

У 2005 роцi ФБР анонсувало запуск новоi програми «Вартовий». Цього разу вона вже мала запрацювати. Цього разу вони вживуть необхiдних запобiжних заходiв, залучать вiдповiднi бюджетнi процедури, правильнi засоби контролю. Вони засвоiли свiй урок. Цiна питання? Усього якийсь там 451 мiльйон доларiв. І до 2009-го все повнiстю запрацюе.

Що тут могло пiти не так? У березнi 2010 року вiдповiдь лягла Джеффовi Джонсону на стiл. Компанiя Lockheed Martin, пiдрядник, найнятий для розробки системи «Вартовий», уже витратила 405 мiльйонiв доларiв. При цьому вони розробили лише половину проекту, i то спiзнившись у своiй роботi на цiлий рiк. Незалежний аналiз показав, що для закiнчення проекту iм потрiбно ще 6–8 рокiв, а платникам податкiв доведеться викинути на це щонайменше 350 мiльйонiв доларiв додатково.

І Джонсон мав щось iз цим робити.

Що ж тодi пiшло не так i як ситуацiю вдалося виправити? Вiдповiдi на цi питання якраз i спонукали мене написати цю книжку. Проблема полягала не в дурнях. Не можна сказати, що в Бюро не вистачало компетентного персоналу чи необхiдних технологiй. Усе гаразд було й з робочою етикою та здоровою конкуренцiею.

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

Коли чуеш, що сталося, спершу все здаеться цiлком логiчним. Перед тим як братися за контракт, спiвробiтники Lockheed вивчили вимоги замовника та почали планувати створення системи, яка буде на все це здатна. Було задiяно багато розумних людей, якi довгi мiсяцi працювали над визначенням того, що треба зробити. Потiм вони витратили ще мiсяцi на планування того, як це зробити. Вони пiдготували чудовi графiки, позначивши там усе, чого слiд досягти, та час, який займе виконання кожного завдання. Пiсля цього, ретельно дiбравши кольори, вони зобразили всi частини проекту, якi переходили одна в одну у виглядi каскаду.



Каскадна модель








Такi графiки називаються дiаграмами Гантта, на честь американського iнженера Генрi Гантта, який iх розробив. З появою в 1980-х персональних комп’ютерiв, якi спростили творення цих складних графiкiв i дозволили робити iх дiйсно комплексними, вони перетворилися на справжнi витвори мистецтва. Тепер кожен крок у проектi детально презентуеться. Кожна вiха. Кожна дата випуску. Цi графiки насправдi вражають. Єдина проблема з ними – в тому, що вони абсолютно завжди неправильнi.

Генрi Гантт винайшов своi знаменитi дiаграми приблизно у 1910 роцi. Уперше iх використав пiд час Першоi свiтовоi вiйни генерал Вiльям Крузер, начальник служби постачання та техобслуговування армii США. Тi, хто вивчав iсторiю тiеi вiйни, знають, що ефективна органiзацiя точно не була ii характерною рисою. Я так i не змiг зрозумiти, чому артефакт Першоi свiтовоi де-факто став iнструментом, який активно використовують для управлiння проектами у ХХІ столiттi. Ми начебто не ведемо бiльше «окопних» вiйн, але деякi iдеi, що лежали в iхнiй основi, з якогось дива популярнi й досi.

А просто це здаеться дуже заманливим: уся робота, яку потрiбно виконати для реалiзацii масштабного проекту, презентуеться на загальний огляд. Я бував у багатьох компанiях, де единим завданням кiлькох спiвробiтникiв е щоденне оновлення дiаграм Гантта. Проблема в тому, що як тiльки цей план зустрiчаеться з реальнiстю, то трiщить по всiх швах. Але замiсть того, щоб викинути на смiтник i сам план, i його iдею, менеджери наймають пiд нього людей, роблячи вигляд, що все чудово працюе. По сутi, вони платять фахiвцям, щоб тi iм брехали.

Ця невдала схема нагадуе звiти, якi отримувало радянське Полiтбюро 1980-х перед самим розпадом СРСР. Повний мiраж. Як i тодi, сьогоднi звiти стали важливiшими за дiйснiсть, яку вони мають описувати, i якщо виникае якась невiдповiднiсть, винною вважаеться саме дiйснiсть, а не дiаграми.

Колись давно, коли я був кадетом Вiйськовоi академii Вест-Пойнт, я спав у колишнiй кiмнатi Дуайта Ейзенхауера. Уночi мене iнодi будило свiтло вуличних лiхтарiв, яке вiдбивалось вiд золотоi таблички над камiном. Там було написано: «Тут спав Дуайт Д. Ейзенхауер». Так от, я пригадую, цей президент якось зазначив, що планувати бiй важливо, але варто лише прогримiти першим пострiлам, як ваш план iде за вiтром. Принаймнi йому вистачало здорового глузду не використовувати дiаграм Гантта.

Отже, Lockheed представив ФБР усi цi гарненькi графiки, i Бюро iх прийняло. Начебто цього разу завдання було розплановане настiльки добре, що завадити успiху не могло нiщо. «Дивiться, тут вам i рiзнокольоровi позначки, i розмiтка часу, i гiстограми».

Проте коли Джефф та його бос, голова iнформацiйноi служби Чед Фулгем, поглянули на план навеснi 2010 року, то зрозумiли, що дива не сталось: усi цi дiаграми були нескiнченно далекими вiд дiйсностi. Розглянувши реальний стан справ, цi двое усвiдомили, що розв’язати проблему просто неможливо. Новi дефекти програмного забезпечення виявлялися швидше, нiж вдавалося виправити старi.

Чед доповiв генеральному iнспекторовi Мiнiстерства юстицii, що вони зможуть завершити проект «Вартовий», узявши його розробку на себе та зменшивши кiлькiсть розробникiв. За рахунок цього вони виконають найскладнiшу половину проекту бiльш нiж уп’ятеро швидше, витративши менш нiж десяту частину бюджетних грошей. Скептицизм у зазвичай сухих звiтах iнспектора для Конгресу можна було просто-таки вiдчути на дотик. У жовтнi 2010 року, виклавши своi перестороги в дев’яти пунктах, цербери генерального iнспектора пiдбили пiдсумок: «Загалом, ми маемо великi сумнiви стосовно здатностi цього нового пiдходу завершити проект „Вартовий“ у межах бюджету, вчасно та не з гiршою, нiж зараз, функцiональнiстю…[2 - Status of the Federal Bureau of Investigation’s Implementation of the Sentinel Project. US Department of Justice, Office of the Inspector General. Report 11–01, жовтень 2010 р.]»




Новий спосiб мислення


Цей новий пiдхiд називаеться Scrum. Я створив його двадцять рокiв тому. На сьогоднi це единий перевiрений спосiб, здатний дати раду такого роду проектам. Існують два способи управлiння проектами: старий «каскадний», який марнуе сотнi мiльйонiв доларiв i часто не дае на виходi геть нiчого, i новий, який iз меншою кiлькiстю людей та за менший час може дати бiльший результат кращоi якостi, без витрат великих коштiв. Я знаю, це здаеться надто хорошим, щоб бути правдою, але результати впровадження Scrum говорять самi за себе. Вiн дiйсно працюе.

Двадцять рокiв тому я перебував у справжньому розпачi, нагально потребуючи нового способу мислення щодо роботи. Перелопативши тонни дослiджень та експериментiв, передивившись гори отриманих ранiше даних, я зрозумiв, що новий спосiб органiзацii людськоi дiяльностi потрiбен нам усiм. У цьому не було чогось надзвичайного, адже в минулому цю проблему порушували не раз i не двiчi. Пошукам ефективних способiв органiзацii працi були присвяченi ще дослiдження часiв Другоi свiтовоi вiйни. Але з тих чи iнших причин люди так i не змогли зiбрати окремi iдеi докупи. Я намагався зробити це протягом бiльш нiж двадцяти рокiв, пiсля чого менi вдалося створити систему, дуже поширену сьогоднi в першiй сферi, для якоi я ii застосував, – розробцi програмного забезпечення. Вiд таких гiгантiв, як Google, Amazon та Salesforce.com, до дрiбних стартапiв, про якi ви поки що не чули, ця система радикально змiнила пiдхiд людей до виконання поставлених у роботi завдань.

Причина ефективностi цiеi системи проста. Я взяв до уваги те, як люди дiйсно працюють, а не те, що вони про це кажуть. Я врахував результати дослiджень за десятки рокiв та найкращi практики компанiй з усього свiту i детально вивчив досвiд найефективнiших команд усерединi цих компанiй. Що дозволило iм досягти успiху? Що вiдрiзняло iх вiд iнших? Чому однi команди стають найкращими, а iншi залишаються посереднiми?

З певних причин, про якi я детальнiше розповiм у наступних роздiлах, ця система пiдвищення ефективностi команд отримала назву Scrum. Цей спортивний термiн, що означае гуртування навколо м’яча в регбi, чудово вiдображуе спосiб спiвпрацi членiв команди для пересування полем. Вiн потребуе злагодженостi дiй, едностi мети та чiткого розумiння необхiдностi ii спiльного досягнення. Це iдеальна метафора для того, чого я хочу вiд командноi роботи.

Зазвичай у ходi роботi над будь-яким проектом менеджмент хоче бачити двi речi: контроль та передбачуванiсть. Це веде до появи величезноi кiлькостi документiв, графiкiв та дiаграм, як це було у випадку з Lockheed. Здавалося б, на планування кожноi деталi йдуть мiсяцi зусиль, тому не буде жодноi помилки, жодного перевищення бюджету i все буде готове вчасно.

Проблема в тому, що такi райдужнi сценарii нiколи не реалiзовуються. Як правило, всi зусилля, витраченi на планування, спроби обмежити вiдхилення вiд прийнятого курсу та передбачити непередбачуване просто марнуються. Адже кожен проект несе iз собою виявлення нових проблем та вибухи натхнення. Намагання звести людську дiяльнiсть будь-якого масштабу до кольорових графiкiв та дiаграм не мають жодного сенсу i приреченi на провал. Вони не мають нiчого спiльного з тим, як працюють люди й виконуються проекти. Визрiвання слушних iдей та здiйснення великих справ вiдбуваеться точно не так.

Навпаки, такi обмеження призводять до розгубленостi людей, якi вже самi не розумiють, чого вони хочуть. Проекти затягуються, виходять за межi бюджету i – в надто багатьох випадках – закiнчуються безславним згортанням. Це особливо стосуеться команд, залучених до роботи зi створення чогось нового. Бiльшу частину часу менеджмент нiяк не може усвiдомити, що все поступово котиться зi схилу, аж доки не змарнуе мiльйони доларiв i тисячi годин безрезультатноi працi.

Scrum порушуе питання про те, чому робота мае вiднiмати саме стiльки часу й зусиль i чому ми так погано вмiемо визначати iх заздалегiдь. На будiвництво Шартрського собору пiшло п’ятдесят сiм рокiв. Так от, я можу заприсягтись, що на початку будiвництва каменярi подивились на епископа й сказали: «Двадцять рокiв максимум. Можливо, впораемось i за п’ятнадцять».

Scrum вiтае непевнiсть i творчiсть. Ця система закладае пiдвалини процесу пiзнання, що дозволяе командам оцiнювати не лише те, що вони створили, але й (не менш важливо) як вони це створили. Спираючись на справжню роботу команд, Scrum дае iм iнструменти для самоорганiзацii та швидкого покращення швидкостi та якостi iхньоi роботи.

У своiй основi Scrum базуеться на простiй iдеi: хоч коли почався проект, чому б регулярно не перевiряти, що вiн iде в правильному напрямку та дiйсно вiдповiдае прагненням людей? Непогано також ставити собi питання, чи iснують якiсь способи покращити вашу роботу, виконувати ii якiснiше та швидше, а також що може вам у цьому заважати.

Це називаеться циклом перевiрки та адаптацii. Як тiльки випадае вiльна хвилинка, треба зупинятись, переглядати вже зроблене, перевiряти його вiдповiднiсть визначеним ранiше вимогам та шукати шляхiв покращення своiх дiй. Це проста iдея, але ii впровадження потребуе уваги, самоаналiзу, щиростi та дисциплiни. Я пишу цю книгу, щоб показати вам, як це робиться. І не лише в компанiях з розробки програмного забезпечення. Я бачив, як Scrum успiшно застосовували для випуску автомобiлiв, управлiння пральнею, навчання студентiв, виготовлення космiчних кораблiв, планування весiлля – навiть як його застосовувала моя дружина, щоб проконтролювати виконання мною всiх домашнiх справ на вихiднi.

Кiнцевим результатом застосування Scrum – метою його розробки, якщо хочете, – е рiзке покращення продуктивностi команд. За останнi двадцять рокiв я створював такi команди безлiч разiв. Я побував генеральним директором, технiчним директором чи головним iнженером десятка компанiй, вiд дрiбних стартапiв з кiлькома людьми в однiй кiмнатцi до великих пiдприемств iз представництвами, розкиданими по всiй планетi. А вже консультантом та тренером я працював iще в кiлькох сотнях рiзних фiрм.

Результати, бувае, настiльки вражають, що, на думку провiдних дослiдницьких та аналiтичних фiрм (таких як Gartner, Forrester Research та Standish Group), старий стиль роботи вже можна смiливо вiдкинути й забути. Компанii, якi все ще чiпляються за давно вiдомi, але неефективнi iдеi управлiння та контролю, мрiючи про чiтку передбачуванiсть, просто приреченi на провал, якщо iхнi конкуренти використовують Scrum. Надто вже велика мiж ними рiзниця. Наприклад, у фiрмi OpenView Venture Partners iз Бостона, де я працюю консультантом, кажуть, що Scrum пропонуе надто велику конкурентну перевагу, щоб нею не скористатись. Люди, якi там працюють, зовсiм не бiлi й пухнастi. Це холоднi дiлки, але вони просто кажуть: «Результати беззаперечнi. Компанii мають лише два варiанти: змiнюйтесь або помрiть».




Розв’язання проблеми ФБР


Першою проблемою, з якою зiткнулась у ФБР команда проекту «Вартовий», були контракти. Адже кожна найменша змiна програми закiнчувалася контрактними переговорами з Lockheed Martin. Тому Джефф Джонсон та Чед Фулгем витратили мiсяцi, розплутуючи всi контракти, беручи розробку на себе та скорочуючи штат iз кiлькох сотень працiвникiв до п’ятдесяти. Основна команда вийшла в них ще меншою.

Увесь перший тиждень вони займалися тим, що робить багато людей у таких обставинах: роздруковували всi документи з вимогами. Якщо ви нiколи не бачили, на що це схоже у великих проектах, то це можуть бути сотнi й сотнi сторiнок. Я сам бачив стоси ледь не в метр заввишки. Проект за проектом люди вирiзають та вставляють у текст однi й тi самi стандартнi фрази, а потiм тi купи паперу нiхто не читае. Це просто фiзично неможливо. Але стара система змушуе людей дiяти саме так.

«Там було 1100 вимог. Стос вийшов завтовшки з десять сантиметрiв», – каже Джонсон. Особисто в мене сама думка про цi документи викликае спiвчуття до людей, якi, мабуть, витратили кiлька тижнiв свого життя, готуючи те, що не мало жодноi мети. ФБР та Lockheed Martin не однi такi – я бачив повторення цього ледь не в кожнiй компанii, де працював. Ця товста пачка непотребу якраз i е однiею з причин, чому впровадження Scrum може стати для людей такою потужною змiною. Нiхто не повинен витрачати свое життя на безцiльну роботу. Це погано не лише для бiзнесу – це вбивае душу.

Отже, отримавши свою пачку паперiв, Джонсон та Фулгем розставили прiоритети для кожноi вимоги. Це було просто життево необхiдно i складнiше, нiж здаеться. Часто люди просто кажуть, що важливе все. Але насправдi слiд ставити питання, яке й поставили члени команди «Вартового»: що принесе проекту найбiльшу цiннiсть? Цим i слiд займатися насамперед. У розробцi програмного забезпечення е правило, пiдкрiплене десятилiттями дослiджень: 80 вiдсоткiв цiнностi будь-якоi програми закладенi у 20 вiдсотках ii функцiональних особливостей. Подумайте про це: коли востанне ви користувалися функцiею вiзуального редактора у Microsoft Word? Ви, мабуть, узагалi не знаете, що це таке, не кажучи вже про те, для чого вiн потрiбний. А вiн там е, i хтось витратив чимало часу на його впровадження, але я гарантую вам, що це не набагато пiдвищило цiннiсть Word.

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

Для команди проекту «Вартовий» питання звучало так: «Гаразд, ми займаемось цим величезним проектом, який е життево необхiдним i на який ми вже викинули сотнi мiльйонiв доларiв. Коли ж вiн завершиться?» Подумавши над цим, вони пообiцяли здати роботу восени 2011 року. Але звiт генерального iнспектора, поданий восени 2010-го, був просто-таки зразком недовiри:



У ФБР стверджують, що для завершення розробки «Вартового» задiють так звану «гнучку методологiю», для якоi потрiбно менше спiвробiтникiв ФБР, Lockheed Martin та компанiй, що постачають готовi компоненти цього проекту. Загалом ФБР плануе зменшити кiлькiсть контрактних фахiвцiв, залучених до роботи над «Вартовим», iз приблизно 220 до 40. Там кажуть, що водночас i кiлькiсть задiяних у проектi спiвробiтникiв ФБР зменшиться з 30 до 12… Бюро запевнило нас, що плануе завершити «Вартового» приблизно за 20 мiльйонiв доларiв, якi ще залишились у бюджетi проекту, та не пiзнiш нiж через 12 мiсяцiв пiсля запровадження цього нового пiдходу[3 - Там само.].


Використання вислову «гнучка методологiя» чiтко показуе, як мало iнспектор знав про Scrum. Цей термiн походить iще iз зустрiчi 2001 року, на якiй я та шiстнадцятеро iнших майстрiв програмного забезпечення склали те, що стало вiдомим як «Манiфест гнучкоi розробки». Цей манiфест проголосив такi цiнностi: люди важливiшi за процеси; продукти, що дiйсно працюють, важливiшi за документування iхнiх номiнальних цiлей; спiвпраця з клiентами важливiша за переговори з ними; реакцiя на змiни важливiша за дотримання плану. Scrum – це система, яку я створив для впровадження цих цiнностей на практицi. Це не просто якась методологiя.

Звичайно, 12-мiсячну обiцянку Джонсона було дано з певною натяжкою. Адже насправдi вони не знали, коли закiнчать, – просто не могли знати. По сутi, нiхто в ФБР навiть не здогадувався, як швидко здатнi працювати iхнi команди. Саме про це я постiйно кажу керiвникам рiзного роду пiдприемств: «Я знатиму дату завершення проекту, коли побачу ступiнь прогресу членiв команди. Як швидко вони просуватимуться вперед. Наскiльки вони прискоряться».

Було також дуже важливо, звичайно, щоб члени команди визначили, що може завадити iхньому прискоренню. Джефф Джонсон говорить про це так: «Я став майстром усунення перешкод». Концепцiя перешкоди зародилась у компанii, що колись сформувала багато iдей, на яких сьогоднi базуеться Scrum. Конкретнiше, у виробничiй системi Toyota, створенiй Таiчi Оно.

Не хочу заглиблюватись тут у подробицi, але однiею з ключових концепцiй, яку ввiв в обiг Оно, е iдея «потоку». Суть у тому, що виробництво мае бути швидким та безперервним протягом усього процесу, а одним iз головних завдань менеджменту, за його словами, е виявлення та усунення перешкод для цього потоку. Усе, що стоiть на його шляху, е марнуванням. У своiй класичнiй книзi «Виробнича система Toyota» Оно дае цьому явищу моральну, а також дiлову оцiнку:



Не буде перебiльшенням сказати, що в перiод незначного зростання таке марнування е злочином проти суспiльства, а не просто комерцiйними втратами. Усунення марнування мае стати першорядним завданням будь-якого пiдприемства[4 - Ohno, Taiichi. Toyota Production System: Beyond Large-scale Production (Cambridge, MA: Productivity, 1988).].


Оно багато говорить про рiзнi види марнувань та перешкод, що можуть виникнути на шляху виробництва. Щоб Scrum став по-справжньому ефективним, хтось у вищому керiвництвi компанii мае глибоко зрозумiти, що перешкоди майже рiвнозначнi злочину. Про те, як позбутись марнування, я розповiм вам пiзнiше в цiй книжцi. Зараз же буде досить сказати, що ефект усунення зайвого вражае, але люди часто цього не роблять, бо воно потребуе чесностi iз собою та з iншими.

Джефф Джонсон розумiв, що зайнятися цим доведеться саме йому.

Командi «Вартового» знадобилося близько трьох мiсяцiв, щоб визначити, скiльки насправдi займе виконання проекту. Чому? Повернiмось до циклу перевiрки та адаптацii, про який я вже говорив ранiше. Scrum працюе шляхом визначення послiдовних цiлей, яких потрiбно досягати у фiксований промiжок часу. У випадку ФБР було вирiшено задiяти двотижневi цикли, де передбачено, що наприкiнцi кожного циклу буде готовий продукт. Це означало, що вони матимуть щось робоче, щось, що можна буде показати всiм охочим, особливо зацiкавленiй сторонi та, в iдеалi, людям, якi фактично будуть цим користуватись.

Такий метод дозволяе командам отримувати майже негайний вiдгук про свою роботу. Чи рухаються вони в правильному напрямку? Чи дiйсно те, що вони планують робити далi, вiдповiдае тому, що вони мають робити, враховуючи виявлене протягом цього циклу?

У системi Scrum ми називаемо такi цикли спринтами. На початку кожного циклу вiдбуваеться зустрiч iз планування спринту. Члени команди вирiшують, скiльки роботи вони можуть виконати протягом наступних двох тижнiв. З перелiку завдань iз розставленими прiоритетами вони обирають робочi моменти, якi потрiбно виконати, часто виписуючи iх просто на стiкери та лiплячи на стiну. Пiсля цього члени команди вирiшують, скiльки цих робочих моментiв вони зможуть виконати протягом даного промiжку часу.

Наприкiнцi спринту всi члени команди збираються разом та показують, чого вони досягли за час спiльноi роботи. Вони дивляться, скiльки цих стiкерiв дiйсно опрацьовано. Чи не заклали вони в спринт забагато, не зумiвши завершити все вчасно? Чи, може, заклали недостатньо? Тут важливо, що в них з’являеться базове вiдчуття того, як швидко вони можуть просуватися, – iхньоi швидкостi.

Пiсля демонстрацii досягнень (саме тут у гру вступае iдея Таiчi Оно) вони обговорюють не що зробили, а як вони це зробили. Вони шукають вiдповiдi на запитання: «Як можна покращити нашу спiльну роботу в наступному спринтi? Що стояло в нас на шляху протягом попереднього? Якi перешкоди знижують нашу швидкiсть?» Бiльш детальне пояснення роботи Scrum можна знайти в додатку.

І саме тому Джеффовi Джонсону знадобилося кiлька мiсяцiв, перш нiж вiн зумiв дiйсно сказати, скiльки часу займе цей проект. Вiн хотiв вимiряти швидкiсть кожноi команди протягом кiлькох спринтiв, а потiм подивитися, наскiльки вони можуть покращити свою роботу – наскiльки швидше можуть просуватися вперед. Побачивши ж кiлькiсть робочих моментiв, якi кожна команда виконала в кожному спринтi, а потiм перевiривши, скiльки iх залишилося до кiнця проекту, вiн нарештi зумiв передбачити остаточну дату завершення робiт.

Окрiм вивчення швидкостi команд, Джонсона також цiкавило, якi перешкоди iх затримували. Передусiм вiн прагнув прискорити цi команди, щоб вони почали дiяти швидше – за рахунок не понаднормовоi роботи (далi я поясню, що це шлях у нiкуди, який лише гальмуе справу), а роботи кращоi та розумнiшоi. За словами Джеффа Джонсона, його команди пiдвищили свою продуктивнiсть утричi. Порiвняно iз самим початком роботи, вони стали просуватися вперед у три рази швидше. Чому? Безумовно, вони навчилися краще працювати разом, але найважливiше, що вони визначили речi, якi iх затримували, та протягом кожного циклу й кожного спринту намагались iх позбутися.

Урештi-решт, для впровадження проекту «Вартовий» знадобилося пiвтора року кодування для створення системи бази даних i ще два мiсяцi для розгортання ii по всьому ФБР. «На нас дуже сильно тиснув час, – сказав Джонсон пiд час iнтерв’ю. – Але ви маете зрозумiти: ця система охоплюе все. Оплату iнформаторiв. Зберiгання доказiв. Слiдчi справи. Календарi. Навiть iнформацiю про нашу з вами бесiду також занесено у „Вартового“».

Яка ж частина Scrum, на його думку, е найефективнiшою? «Демонстрацiя результатiв. Прагнення до отримання продукту, який можна продемонструвати на кожному етапi». Раз на два тижнi члени команди «Вартового» демонструють, чого вони досягли. Причому демонстрацiя та обговорення здiйснюються не лише для них самих. Вони беруть своi досягнення та показують iх людям, якi фактично користуватимуться цiею системою. Усi пiдроздiли, що брали участь у проектi, присилали своiх представникiв, яких збиралося доволi багато. Там були люди з дiловодства, розвiдки, спецагенти, апарат генерального iнспектора та представники iнших державних установ. Доволi часто приходили директор та заступник директора ФБР, а також чинний генеральний iнспектор власною персоною. Натовп збирався ще той.

І саме тому вони й упорались, каже Джонсон. «Scrum стосуеться не лише розробникiв. Вiн призначений також для клiентiв та громадськостi. По сутi, це була органiзацiйна змiна, найефективнiшою частиною якоi стала демонстрацiя реального продукту».

Демонстрацiя продукту справдi була ефективною, бо люди (як би це м’якше сказати?) були доволi скептично налаштованi щодо заявленого командою прогресу. Вони просто не могли повiрити, що «Вартовий» дiйсно прогресуе, причому з дедалi бiльшою швидкiстю. «Я запевняв Конгрес, що за 5 вiдсоткiв бюджету та двадцять мiсяцiв ми збираемось досягти того, що Lockheed не змiг зробити, маючи 90 вiдсоткiв бюджету та десять рокiв, – каже Джонсон. – Але менi не надто вiрили. Ми мали подавати звiти помiчниковi генерального прокурора. Ми забезпечили повну прозорiсть поточних справ, але нашi слухачi все одно пiдозрювали якесь шахрайство. Адже кожного разу, коли вони бачили такi показники в минулому, звiти не розкривали всiеi картини i щось точно залишалось у тiнi».

Причому цей скептицизм заразив навiть решту пiдроздiлiв ФБР. «Хлопцi з пiдвалу знову збираються всiх надурити», – думали вони. Це буде лише ще одна тимчасова система, що швидко провалиться, i нам доведеться повернутись до паперових гiр.

Джефф розповiв своiй командi про рядки, якi вiн запам’ятав, коли навчався у Вiйськово-морськiй академii в Аннаполiсi. То був уривок iз промови Теодора Рузвельта «Громадянство в республiцi», з якою вiн виступив у Сорбоннi 1910 року. Його часто цитують:



Значення мае не критик, не людина, яка вказуе, де сильний спiткнувся чи де справжнiй дiяч мiг би зробити краще. На повагу заслуговуе той, хто сам на аренi, чие обличчя вкрите пилом, потом та кров’ю, хто вiдважно бореться, помиляеться, програе знову i знову, бо не бувае зусиль без помилок та поразок, але все одно прагне дiяти, хто знае великий ентузiазм, велику вiдданiсть, хто розтрачуе себе в гiднiй справi i в кращому випадку зазнае наприкiнцi трiумфу високого досягнення, а в гiршому хибить, однак пiсля великих дерзань. Тому його мiсце нiколи не буде поруч iз тими холодними та боязкими душами, що не знають анi перемог, анi поразок[5 - Roosevelt, Theodore. «Citizenship in a Republic.» Промова у Сорбонському унiверситетi, Париж, Францiя, 23 квiтня 1910 р.].


Команда таки мала кiлька затримок, доки точно не визначила, як швидко вони можуть дiяти й наскiльки складнi завдання перед ними стоять. Нарештi, у липнi 2012 року «Вартовий» було запущено. Причому запускати його довелось одразу на повну, для всiх пiдроздiлiв. Про поетапне впровадження не було й мови.

«Це вiдбулося протягом лиш одного дня, – згадуе Джефф Джонсон. – Адже в кримiнальнiй або антитерористичнiй справi якiсь подii в Лос-Анджелесi можуть бути пов’язанi з якимись подiями в Чикаго. Ми просто не могли дозволити собi жодноi втрати iнформацii. У будь-який момент часу в нас мали бути чiткi та повнi данi про стан справ».

Причому данi мали бути достатньо чiткими та повними для передачi справи в суд. Адже iнформацiя проекту «Вартовий» використовувалася для карного переслiдування людей, i ii повнота мала бути поза всякими сумнiвами.

У перший день Джефф був увесь на нервах. Вiн прийшов у свiй кабiнет та запустив «Вартового». Той завантажився. Це було добре. А потiм вiн спробував затвердити документ електронним пiдписом – рутинна повсякденна процедура, яку десятки тисяч спiвробiтникiв ФБР мусять робити весь час. І тут на екранi з’явилося повiдомлення про помилку. Система не працювала. Джонсон згадуе, що почав панiкувати, а в його головi затанцювали картини катастрофи. Але уважнiше придивившись до коду помилки, вiн зрозумiв, що все не так погано. Вiн просто не вставив свою iдентифiкацiйну картку в машину для пiдтвердження особи. Вiн вставив картку, клацнув мишкою, i «Вартовий» запрацював належним чином.

Ефект цiеi програми для ФБР був надзвичайним. Здатнiсть спiлкуватись та обмiнюватись iнформацiею фундаментально змiнила можливостi Бюро. У сiчнi 2013 року регiональне вiддiлення ФБР повiдомили про злам банкiвського рахунку одного малого пiдприемства. Перш нiж американськi банки змогли це зупинити, близько мiльйона доларiв було переведено до iншоi краiни. Скориставшись «Вартовим», мiсцеве вiддiлення скооперувалося з аташе з юридичних питань посольства краiни призначення, який повiдомив тамтешнi правоохороннi органи, а вже тi зупинили трансфер, не давши йому потрапити в банкiвську систему. Усе це сталося за лiченi години, чого просто не могло бути в епоху трьох друкованих примiрникiв та червоних ручок. У цьому й полягала рiзниця: спiймати зловмисника чи дати йому втекти зi здобиччю.

Команда «Вартового» все ще працюе в пiдвалi ФБР, прибравши лише перегородки мiж столами, щоб бачити одне одного. На стiнi висить плакат iз текстом «Манiфесту гнучкоi розробки» – принципiв, якi я допомагав писати та впровадженню яких в усьому свiтi присвятив життя. Доволi дивно для примiщення без вiкон, але неподалiк входу пiд люмiнесцентною лампою росте цiлком здорова лаванда. У цьому е певний символiзм, адже «Лаванда» була кодовою назвою прототипу «Вартового». Члени команди досi продовжують удосконалювати створену ними систему, додаючи все новi й новi функцii.

Серед прихильникiв Scrum ходить старий жарт про курку та свиню, якi йдуть разом дорогою та розмовляють.

– Слухай, свинко, я тут подумала, чи не вiдкрити нам iз тобою ресторан, – каже курка.

– А як ми його назвемо? – питае свиня.

– Може, «Яечня з беконом»?

– Нi, дякую, – каже свиня. – Я тодi буду зайнята повнiстю, а ти лише долучишся!

Суть полягае в тому, що в Scrum «свинi» – це тi, хто виконуе основну частину проекту та вiдповiдае за його результат. Натомiсть «кури» – це люди, яких iнформують про його прогрес, тобто зацiкавленi. На стiнi в кабiнетi «Вартового» висить дзвiночок у формi свинi. Коли вiн дзвонить, люди, якi зробили те, що всi вважали неможливим, знають, що кличуть iх. Є там iще один дзвiночок, на дверях, але вiн для «курей».

Свiт постiйно стае складнiшим, i робота, яку ми робимо, також набувае складностi з нечуваною ранiше швидкiстю. Вiзьмiмо, наприклад, машини. Колись я сам займався своею автiвкою, роблячи дрiбнi ремонти своiми руками. Тридцять рокiв тому я навiть мiг полагодити радiатор. Тепер же, вiдкриваючи капот, я неначе заглядаю всередину якогось комп’ютера. По сутi, саме це я й роблю, бо новий Ford мiстить у собi бiльше рядкiв програмного коду, нiж Фейсбук i Твiтер разом узятi. Створення таких складних речей потребуе масштабних людських зусиль. А кожного разу, коли люди беруться за складнi творчi справи – чи запуск ракети в космос, чи вдосконалення вимикача, чи арешт злочинця, – традицiйнi методи управлiння просто розвалюються.

І ми це розумiемо – як окремi люди, так i суспiльство в цiлому. Ми бачимо вiдгомiн нашого справжнього життя у фантазiях на офiсну тему, на кшталт зображених у комiксах «Дiльберт» чи фiльмi «Офiсний простiр». Ми всi приходимо додому з роботи та розповiдаемо нашим близьким чи друзям про божевiлля сучасноi корпоративноi «органiзацii». Ми всi чуемо, що правильне заповнення форм важливiше за виконання роботи або що нам потрiбно проводити зустрiчi для пiдготовки пiдготовчоi зустрiчi. Це просто якась дурня. Але ми все одно продовжуемо це робити. Навiть перед загрозою абсолютного та повного провалу.

Яскравим прикладом е запуск веб-сайту Healthcare.gov, призначеного, щоб американцi мали змогу обрати програму страхування здоров’я. Зовнiшнiй iнтерфейс сайту вийшов гарним. Там були мудрi поради, чiткi блоки iнформацii та чудове оформлення. За допомогою Scrum вiн був створений за три мiсяцi. Але з внутрiшнiм iнтерфейсом виникла проблема. Вiн просто не працював. Планувалося, що вiн з’еднуватиме iнформацiйно-пошукову систему з базами даних держустанов, страхових компанiй та Мiнiстерства охорони здоров’я й соцiального забезпечення. То була доволi складна дiлянка роботи. До неi були залученi понад двадцять пiдрядникiв, якi працювали над рiзними частинами та завданнями, плануючи все за допомогою технiк каскадноi моделi. Вони лише протягом кiлькох днiв тестували сайт у самому кiнцi роботи, але не проводили поетапного тестування впродовж усього проекту.

Бiда в тому, що всi все розумiли. Люди, якi працюють на цих пiдрядникiв, не йолопи – вони розумiли, що можна зробити й краще. Проте всi казали: «То не мiй клопiт». Вони виконували свiй шматок роботи – i квит. Вони нiколи не дивились на той сайт iз точки зору користувачiв, а лише з власноi. А все тому, що не були згуртованi – об’еднанi спiльною метою. Scrum же якраз i зводить членiв команди разом для досягнення великих результатiв, вимагаючи вiд усiх не лише бачити кiнцеву мету, але й покроково до неi наближатись. У проектi Healthcare.gov не було вiдповiдальноi особи, яка б наполягала, щоб усе тестувалось одразу пiсля створення, i, на жаль, у появi збоiв не було нiчого надзвичайного. Хто ж зумiв виправити ситуацiю iз сайтом? Люди, якi використовували Scrum.

Скiльки разiв вам доводилося чути про якийсь масштабний проект вартiстю в мiльйони й мiльйони доларiв, який скасовують не лише через перевищення бюджету, але й через те, що вiн просто не працюе? Скiльки мiльярдiв доларiв витрачаеться щороку, не приносячи геть нiчого? Скiльки часу вашого життя марнуеться на роботу, яка не принесе вiддачi, що наперед розумiете i ви, i ваш начальник? Із таким самим успiхом ви могли б копати ями, а потiм закидати землею iх знову.

Так не мае бути. Дiйсно не мае. Навiть якщо всi завжди казали вам, що свiт улаштований саме так, це зовсiм не означае, що вони правi. Існуе й iнший спосiб досягнення результату – зовсiм iнший спосiб роботи.

І, якщо не користуватися ним, вас переведуть на зовнiшне управлiння. Або ваша компанiя помре. У гiперконкурентному свiтi працi ХХІ столiття немае мiсця для марнування та безглуздя.

Ще важливiший момент: робота максимально продуктивним способом (таким як Scrum) не обов’язково мае обмежуватися сферою бiзнесу. Що як люди користуватимуться цим методом для розв’язування масштабних проблем, вiд яких потерпае все людство: наприклад, залежностi вiд нафти, браку освiти, нестачi чистоi води в бiдних частинах земноi кулi чи розгулу злочинностi? Що як насправдi вже давно iснуе кращий спосiб життя та роботи, а також iнакшого розв’язання проблем? Спосiб, яким дiйсно можна змiнити свiт? А вiн е. Існують люди, якi використовують Scrum для розв’язування всiх цих проблем, якi я згадав, i вони роблять велику справу.

Із цiеi книжки ви дiзнаетеся про деякi основнi способи покращити роботу людей, зрозумiете проблеми оцiнювання наших результатiв i те, чому понаднормова робота лише затягуе виконання проекту. Я проведу вас крiзь усi дослiдження та застосування iхнiх даних, якими люди, вченi та органiзацii старанно займалися протягом рокiв, i покажу, як Scrum зв’язуе iх докупи в спосiб, придатний для впровадження хоч завтра.

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




Що треба запам’ятати


Планувати корисно. Слiпо дотримуватися плану безглуздо. Звичайно, малювати нескiнченнi дiаграми спокусливо. Адже таким чином уся робота, яку потрiбно виконати щодо масштабного проекту, вiдкриваеться на загальний огляд. Але коли вашi детальнi плани зустрiчаються з реальнiстю, вони просто розвалюються на частини. Закладайте у свiй метод роботи можливiсть змiн, вiдкриттiв та нових iдей.

Перевiряйте та адаптуйте. Пiсля кожного маленького кроку робiть паузу, переглядайте виконане та дивiться, чи все ще вiдповiдае воно вашiй метi та чи можете ви щось покращити у своiй роботi.

Змiнюйтесь або помрiть. Прив’язка до старого способу роботи, управлiння та контролю, а також жорстка передбачуванiсть ведуть лише до провалу. Поки ви вiд них не вiдмовитесь, готовi до змiн конкуренти залишатимуть вас далеко позаду.

Помиляйтесь швидко, щоб устигнути все виправити. Корпоративна культура часто придiляе бiльше уваги рiзним формам, процедурам та зустрiчам, анiж створенню вiдчутноi цiнностi, яку з короткими iнтервалами можуть випробувати користувачi. Робота, що не приносить справжньоi цiнностi, безглузда. Виробництво ж продукту короткими циклами дозволяе отримати раннiй вiдгук користувачiв та негайно позбутися явного марнування зусиль.




Роздiл 2. Витоки Scrum



Для американських вiйськових пiлотiв у В’етнамi перiод проходження служби означав виконання ста польотних завдань над ворожою територiею. При цьому п’ятдесят вiдсоткiв пiлотiв були збитi. Декого вдавалося врятувати, але бiльшiсть збитих уже нiколи не поверталися. У 1967 роцi, будучи ще молодим, недосвiдченим винищувачем, я прибув iз вiйськово-повiтряноi бази Маунтiн-Хоум в Айдахо на базу королiвських ВПС Удон у пiвнiчному Таiландi для виконання найнебезпечнiшоi роботи в авiацii США – розвiдки.

Це було задовго до нинiшньоi ери дронiв та достовiрних супутникових даних. Мiй лiтак RF-4C Phantom був споряджений усiма видами зброi, обладнаний камерами та додатковим паливним баком. Моею роботою були польоти над ворожою територiею, щоб штурман мiг зняти фото до та пiсля нашого бомбардування. Бiльшiсть завдань виконувалися вночi, i я летiв крiзь тропiчну пiтьму приблизно в сотнi метрiв над землею, ледь не причiсуючи верхiвки дерев. У момент перетину кордону з Пiвнiчним В’етнамом дисплей у моему шоломi час вiд часу спалахував, наче автомат для гри в пiнбол, пiсля чого з гучним писком та свистом активувалася система попередження про ракетну атаку. Небо свiтилося вiд трасерiв зенiток, i я розумiв, що через кiлька хвилин мiй лiтак засiче ракетний радар, хiба тiльки 150 метрiв – це достатньо низько, щоб вiд нього сховатись.

У такi хвилини рiвень адреналiну в моiй кровi мав би зашкалювати, але я не втрачав голови. Навпаки, небезпека мене майже заспокоювала. Цим я завдячую тренуванням з контролю ризикiв, якi отримав вiд ВПС. Тi тренування навчили мене робити чотири речi: Оглядати, Орiентуватись, Вирiшувати й Дiяти. Зокрема, я мав спостерiгати за об’ектом розвiдки, визначати найкращий шлях у гарячу зону й назад, орiентуватись у разi неочiкуваних подiй, а потiм рiшуче дiяти на основi iнстинктiв та засвоених навичок. Зволiкання може вбити пiлота, як i безрозсудна хоробрiсть. Як тiльки мiй штурман робив потрiбнi фото, я тягнув важiль на себе та виривався з-пiд обстрiлу, хоча через перевантаження майже нiчого не бачив. Вiд тих перевантажень штурман теж часто вiдключався, а в деяких випадках i втрачав контроль над своiм кишечником. Але вiн не скаржився. Бо я завжди доставляв нас назад живими.

Тодi я був просто молодим пiлотом реактивного лiтака, який сподiвався пережити свою сотню завдань. Я не знав, що досвiд польотiв та тренувань, якi я пройшов щодо вмiння думати та дiяти в смертельно небезпечних ситуацiях, сформуе спосiб моеi роботи до кiнця життя. Я прибув до В’етнаму в 1967 роцi з двома ескадрильями винищувачiв F-4 та двома розвiдниками RF-4C, загалом сотнею лiтакiв. Ми прибули на змiну двом ескадрильям RF-101s. З п’ятдесяти RF-101s протягом одного року були збитi всi, крiм чотирьох. А тi, що залишились, мали в корпусi стiльки пробоiн, що просто не могли лiтати. Навiть не знаю, як пiлоти взагалi посадили iх пiсля останнього завдання. RF-4C був бiльш витривалим лiтаком-винищувачем, але половину наших лiтакiв однаково збили протягом року. Ми покращили показники виживання, але 50 вiдсоткiв тих, хто прибув разом зi мною, все одно не повернулися на базу. Лише кiлькох щасливчикiв вдалося врятувати з джунглiв, перш нiж iх схопили в’етнамцi.

Повернувшись iз вiйни у В’етнамi, я здобув ступiнь магiстра статистики в Стенфордi, проводячи весь свiй вiльний час у лабораторii штучного iнтелекту. Пiсля цього я став викладачем математики в Академii вiйськово-повiтряних сил та вступив до аспiрантури з бiометрики в Медичнiй школi Унiверситету Колорадо. Там я спитав свого куратора доктора Джона Бейлара, одного з найвидатнiших дослiдникiв у сферi медицини та статистики, як написати дисертацiю, що буде корисною людям, а не валятиметься на запилюженiй полицi бiблiотеки. Вiн передав менi три сотнi статей з медичних журналiв про рак. Усi вони мiстили дiаграми онкологiчноi статистики, якi широко варiювали для людей i тварин та залежно вiд типу пухлини. Бейлар сказав, що якщо я зумiю пояснити, чому вони всi рiзнi, то зможу претендувати на докторський ступiнь. Саме це я й зробив, ставши доктором.

Але перед тим я роками намагався визначити, що вiдбуваеться в клiтинi, вiд чого вона стае раковою. Я багато дiзнався про теорiю систем i те, як лише система мае певнi стабiльнi стани. У мiру свого розвитку клiтина переходить з одного стабiльного стану в iнший. Саме визначенню правил переходу складноi адаптивноi системи з одного стану в iнший та перетворення наступного стану на позитивний замiсть негативного я й присвятив майже десять наступних рокiв свого життя.

Із часом я зрозумiв, що органiзацii, команди та люди також е складними адаптивними системами. Тi самi речi, що переводять клiтини з одного стану в iнший, роблять те саме з людьми. Щоб змiнити клiтину, ви спочатку додаете в систему енергiю. У першi хвилини там спостерiгаеться хаос, здаеться, що немае жодних правил, усе тече й мiняеться. Коли ж ви робите це з органiзацiями, намагаючись iх змiнити, люди часто неначе дурiють. Вони не можуть зрозумiти, що вiдбуваеться. Не знають, що робити. Але навдивовижу швидко, точно як клiтина, органiзацiя заспокоюеться, переходячи в новий стабiльний стан. Питання лише в тому, чи е цей новий стан кращим за старий. Клiтина ракова чи здорова? Особисто мене цiкавило таке питання: «Як можна визначити якiсь простi правила, що скеровуватимуть команди в бiльш продуктивний, щасливий, взаемопiдтримувальний, веселий та захоплений стан?» Намагаючись це визначити, я витратив ще п’ятнадцять рокiв.

За часiв адмiнiстрацii Рейгана уряд радикально урiзав гранти на науковi дослiдження, у тому числi й мiй грант вiд Нацiональних центрiв дослiдження раку, коли я був провiдним дослiдником збирання та аналiзу даних вiддiлення клiнiчних та епiдемiологiчних дослiджень Центру раку при Унiверситетi Колорадо. Поки я думав, що робити далi, до мене звернулися з компанii пiд назвою MidContinent Computer Services, де почули, що я е провiдним фахiвцем у сферi iхнiх найновiших розробок. MidContinent займалась обслуговуванням 150 банкiв у всiй Пiвнiчнiй Америцi. Свiй найновiший продукт вони назвали мережею «автоматичних касових апаратiв» (банкоматiв). Це було в далекому 1983 роцi, коли отримання готiвки зазвичай означало вистоювання довгоi черги в банку або пiд’iзд до спецiального банкiвського вiкна на вашому автомобiлi. Ви мали заповнити чек на готiвку, вказавши потрiбну суму, та передати його касировi.

Нова мережа мала залишити цю незручнiсть у минулому, але на той час у MidContinent нiяк не могли вирiшити проблему зв’язку iхнiх банкоматiв мiж собою. Їм потрiбен був хтось, хто б зайнявся вирiшенням цiеi проблеми, i вони зробили менi заманливу пропозицiю стати вiце-президентом iз роботи з новими системами. Комп’ютери iхньоi мережi нiчим не вiдрiзнялися вiд тих, на яких я роками працював над дисертацiею, а тому то була цiлком непогана угода.

Принаймнi так я собi думав. Нiщо у свiтi просто не даеться, правда? Прийшовши в компанiю, я очолив вiддiл, що користувався каскадною моделлю управлiння проектами. Там були сотнi програмiстiв, якi цiлими днями просиджували за своiми столами, вдаючи, що працюють, але нiчого не могли виконати вчасно або в межах бюджету. Щодо проекту впровадження мережi банкоматiв, то витрати на 30 вiдсоткiв перевищили прибутки. Неефективнiсть просто-таки вибивала грунт iз-пiд нiг.

Передусiм я витратив деякий час, намагаючись визначити, як там усе працюе. Можете уявити, як вище керiвництво ставилося до моiх хлопцiв. Там було багато крику, дрiб’язкових розпоряджень, пасивно-агресивноi поведiнки та вимог працювати краще й понаднормово. Але хоч як керiвництво тиснуло, проекти все одно хронiчно запiзнювались, не вкладалися в бюджет i не приносили очiкуваного результату.

Я прийшов до думки, що найкращим варiантом для нас е все це змiнити. Проблем було надто багато, щоб усувати iх окремо, тому я вирiшив створити компанiю всерединi компанii. Я попросив нашого генерального директора Рона Гаррiса дозволити менi сформувати окрему органiзацiю з усiх залучених до проекту створення мережi банкоматiв. У нас буде власна команда продажiв, власна група маркетингу та власнi фiнансисти. Рон був блискучим i творчим керiвником, який менi довiряв. Мабуть, за керiвництва когось iншого це б нiколи не вдалося реалiзувати. Почувши про мою iдею, вiн сказав менi: «Сазерленде, якщо ви хочете взяти на себе цей головний бiль, то вiзьмiть».

Я так i зробив. Я пiшов до розробникiв та менеджерiв i сказав iм: «Перше, що нам треба, це припинити робити речi, якi нас убивають». Це як у тому старому жартi про людину, яка б’еться головою об цегляну стiну лише для того, щоб вiдчути, як це добре, коли перестане. «Ми маемо визначити кращий спосiб роботи, – сказав я iм, – i почати слiд негайно».

І ми створили цiлу невеличку компанiю у формi единоi команди, подiленоi на групи. При цьому премii базувалися не на iндивiдуальнiй продуктивностi, а на продуктивностi всiеi компанii. Ми задiяли концепцii та iнструменти, якi десять рокiв потому знайшли свое мiсце в Scrum (наприклад: власник продукту, беклог проекту та тижневi спринти), детальнiше описанi нижче та викладенi в додатку. Через шiсть мiсяцiв ми стали найприбутковiшим пiдроздiлом у компанii. Прибутки на 30 вiдсоткiв перевищили видатки. Нашi системи Nonstop Tandem стали першими онлайновими автоматами для транзакцiй, яким банки довiряли достатньо, щоб iх використовувати. Ми розгорнули iх по всiй Пiвнiчнiй Америцi. У нашi днi, у яку б частину краiни ви не поiхали, банкомат знайдеться скрiзь. І всi цi машини точно знатимуть, скiльки грошей на вашому рахунку. Моя команда добряче над цим попрацювала. Ага, нема за що.




Вчимося думати, як робот


Пiсля моеi першоi кар’ери в армii, а другоi – в освiтi, прийшовши в бiзнес, я почувався свого роду аутсайдером. Проте точка зору сторонньоi людини якраз i стала одним iз найцiннiших моiх активiв. З першого ж дня для мене стало загадкою, чому люди наполягають на роботi способом, який наперед е неефективним та марнотратним, дегуманiзованим i просто гнiтючим. Гадаю, вони вважали, що так дiють усi, а тому вiн, мабуть, найкращий.

Менi дiйсно подобалося працювати в MidContinent, але я прагнув випробувати своi вмiння та навички на нових викликах. Закiнчилося це тим, що протягом наступних двох десятилiть я працював на великi й малi компанii на посадi вiце-президента з проектування або технiчного директора. У кожнiй з них я намагався досягти бiльш ефективноi спiльноi роботи команд. Улаштувавшись в одну iз цих компанiй, я опинився в Кембриджi, штат Массачусетс, усього за кiлька кварталiв вiд Массачусетського технологiчного iнституту (МТІ). Кiлька тамтешнiх докторiв та професорiв якраз заснували нову компанiю зi створення роботiв, i iм стало тiсно в iхнiй лабораторii. Розглянувши рiзнi варiанти, вони орендували офiсне примiщення в моеi компанii.

Через кiлька тижнiв пiсля iхнього переiзду сталася геть неочiкувана рiч: у мiй кабiнет забiг шестиногий робот завбiльшки з кота, який почав ганятися за мною навколо столу. Розробники вiдразу забрали його та нервово вибачилися за iхню машину, але кожнi кiлька днiв це повторювалося знову. Один iз роботiв постiйно тiкав з лабораторii та починав гасати будiвлею. Я весь час чув клацання механiчних нiг у коридорах.

У мене тодi була одна традицiя. Наприкiнцi дня в п’ятницю я завжди виставляв у своему кабiнетi вино та пиво, щоб усi члени команди могли розслабитись i неформально поспiлкуватися пiсля важкого тижня. На цi посиденьки я запрошував також моiх сусiдiв робототехнiкiв, i однiеi п’ятницi до мене завiтав Роднi Брукс. Цей викладач штучного iнтелекту МТІ був одним iз засновникiв компанii. Я спитав його, як працюють цi бродячi роботи.

«Ми десятками рокiв намагалися створити дiйсно розумну машину, – сказав вiн менi. – Витратили мiльярди доларiв i багато-багато рокiв працi, збудувавши найбiльшi комп’ютери, якi тiльки могли, з найбiльшими базами даних, але отримали лише комп’ютер, здатний обiграти людину в шахи».

Вiн пояснив, що до його роботiв застосовуеться зовсiм iнакший пiдхiд. Замiсть спроб побудувати щось iз одним-единим центральним мозком, вони збудували робота, у якого кожна iз шести нiг мала власний мозок. Процесор у спинi мав лише кiлька простих правил: уперед, назад, не наступати на iншi ноги. Чип нейронноi мережi в головi робота контролював дотримання цих правил i дiяв як реферi для всiх частин. Вiн повiдомляв ногам про те, що бачив крiзь свою камеру, коли натикався на перешкоду, – та й усе.

За словами Брукса, цiкавим було те, що кожного разу, коли робота вмикали, вiн учився ходити заново. У нього не було бази даних про розташування iнших предметiв у кiмнатi. Натомiсть його базою даних був сам свiт. Кожного разу пiсля вмикання вiн визначав розташування iнших предметiв, немов уперше. Натикався на речi й сприймав iх як реальне оточення, що означало його здатнiсть адаптуватися до будь-якого середовища.

«Давайте я вам покажу», – сказав Брукс, затягнувши мене до iхньоi лабораторii. Вiн сунув чистий нейронний чип в одного комахоподiбного робота, i я побачив, як той оживае. Спочатку робот невпевнено заспотикався кiмнатою, наче новонароджене теля, яке вперше намагаеться стати на ноги. З кожним кроком вiн ставав усе впевненiшим. Ноги швидко вчилися спiвдiяти. Уже через декiлька хвилин робот бiгав навколо. Його вмiння ходити не було анi збереженим, анi запрограмованим. Усi складники працювали разом за рахунок кiлькох простих функцiй. Цi ноги не думали, а просто дiяли. Я був надзвичайно вражений генiальнiстю та простотою цiеi системи. Тут було щось, що робило саме те, чого мене вчили робити, коли я лiтав над В’етнамом: Оглядати, Орiентуватись, Вирiшувати й Дiяти. Цей робот був iнтегрований у довкiлля й рiшуче дiяв на основi даних iз довкiлля.

– А що б сталося, – спитав я Брукса, – якби ми змогли розробити набiр простих iнструкцiй для груп людей працювати разом, точно як оцi ноги? Вони б самоорганiзувались та самооптимiзувались, як i цей робот?

– Не знаю, – вiдповiв вiн. – Чому б вам не спробувати це й не повiдомити менi, що iз цього вийшло?




Не женiться за каскадною моделлю


Я дедалi краще розумiв: якщо зможу створити систему, яка, подiбно до цього робота, координуватиме незалежнi центри рiшень iз постiйним вiдгуком про стан справ, буде досягнуто значно вищих рiвнiв продуктивностi. Розподiляючи потiк iнформацii мiж «ногами» групи, можна буде досягти ефективностi, якоi ранiше не досягав ще нiхто.

Моя розмова з Роднi Бруксом вiдбулася понад два десятилiття тому. Протягом багатьох рокiв вiн був завiдувачем кафедри робототехнiки та штучного iнтелекту МТІ, а той схожий на павука робот, якого я бачив, на прiзвисько Чингiзхан, тепер зберiгаеться в музеi Смiтсонiвського iнституту. Сьогоднi ви, мабуть, чули про одну з компанiй Брукса iRobot, що виробляе пилосос Roomba та використовуе для прибирання ваших кiмнат той самий адаптивний iнтелект, який Чингiзхан використовував, щоб ганятися за мною по кабiнету. Його остання новинка в Rethink Robotics, робот Бакстер, може успiшно спiвпрацювати з людьми в спiльному робочому просторi.

Праця Брукса мене надихнула. І в 1993 роцi я принiс цi iдеi iз собою в компанiю Easel, куди мене запросили на посаду вiце-президента з об’ектних технологiй. Керiвництво Easel хотiло, щоб моя команда за шiсть мiсяцiв розробила абсолютно нову серiю продуктiв для деяких iз iхнiх найбiльших клiентiв, таких як Ford Motor, якi використовували iхне програмне забезпечення в проектуваннi та створеннi власних додаткiв. Я сiв порадитись зi своiми розробниками й сказав iм, що, на мою думку, вони не зможуть цього зробити за допомогою старого способу розробки програмного забезпечення.

Тiею старою методикою була каскадна модель, яку я вже описував у попередньому роздiлi: усе, що стосуеться проекту, ретельно зображувалося на масштабних дiаграмах Гантта, кожне завдання точно оцiнювалось у годинах i видiлялося симпатичними кольорами, що стiкали сторiнкою, немов каскад. Цi дiаграми здавалися дуже гарними й точними, але були цiлковитою нiсенiтницею.

Я знав, що в Easel каскадна модель викине нас за межi дедлайнiв на мiсяцi, якщо не роки. Ми мали розробити зовсiм iнакший спосiб управлiння проектами. Я пiшов до генерального директора i сказав, що дiаграми Гантта не для нас. Вiн був шокований i вимагав пояснити чому.

– Скiльки дiаграм Гантта ви бачили за свою кар’еру? – спитав я.

– Сотнi, – сказав вiн.

– А скiльки з них справдилися?

– Жодноi, – вiдповiв вiн пiсля паузи.

Саме тодi я й пояснив йому, що збираюся презентувати наприкiнцi мiсяця робоче програмне забезпечення, а не невиконану дiаграму Гантта. Вiн зможе випробувати його сам i переконатися, що ми на правильному шляху. Ми маемо спробувати це, якщо хочемо вкластись у вiдведенi строки.

Кiлька тижнiв ми з командою витратили на читання сотень документiв, книжок та статей з органiзацii команд i розробки продукту. А потiм один розробник якось принiс статтю з Harvard Business Review вiд 1986 року, написану двома японськими викладачами економiки Гiротакою Такеучi та Ікуджиро Нонакою. Вона називалася «Розробка нового продукту. Новi правила гри». Такеучi та Нонака вивчали команди кiлькох найбiльш продуктивних та iнновацiйних компанiй свiту: Honda, Fuji-Xerox, 3M, Hewlett-Packard та iнших. Вони стверджували, що старий спосiб розробки продукту, заданий фазовою системою планування програм NASA, – каскадна модель – дефектний у своiй основi. Натомiсть найкращi компанii використовують ступеневий процес розробки, який е швидшим та гнучкiшим. Цi команди мають рiзнопрофiльних фахiвцiв, автономiю та взаемопiдтримку. При цьому вони ставлять перед собою мету вийти за межi досягнутого ранiше. Вони прагнуть чогось бiльшого за самих себе. Менеджмент не диктуе iм, що робити. Навпаки, керiвники компанiй виступають у ролi лiдерiв-слуг та посередникiв, зосереджених на прибираннi перешкод зi шляху iхнiх команд, а не на вказiвках, котрий продукт розробляти i як. Японськi викладачi порiвнювали робочий процес iз грою в регбi й казали, що найкращi команди дiють так, немов гуртуються задля досягнення спiльноi мети, що й називаеться Scrum: «…м’яч пасуеться всерединi команди, яка рухаеться полем як едине цiле»[6 - Takeuchi, Hirotaka, and Ikujiro Nonaka. «The New New Product Development Game.» Harvard Business Review (сiчень— лютий 1986 р.): 285–305.].

Коли стаття Такеучi та Нонаки тiльки вийшла, вона наробила галасу, але то було за сiм рокiв до того, як ми прочитали ii в Easel. Усi нею захоплювались, але нiхто нiчого iз цим не робив. Пересiчний американський менеджер був не здатний осмислити ii iдеi, навiть попри те, що Toyota швидко збiльшувала свою частку ринку, використовуючи цей пiдхiд. В Easel нам не було чого втрачати. Ми вирiшили спробувати, хоча стаття й описувала бiльше виробничу сферу, а не розробку програмного забезпечення. Я вважав, що iхнi iдеi приведуть до чогось фундаментального, процедури, що описувала б найкращий спосiб спiвпрацi людей у будь-якiй сферi дiяльностi. Адже вони чудово вкладалися в усi iншi експерименти, якi я проводив iще з моеi першоi роботи у приватному секторi в MidContinent.

Це стало офiцiйним народженням Scrum. Ми здали готовий продукт вчасно, ще до закiнчення шести мiсяцiв, не перевищивши бюджет i з меншою кiлькiстю помилок, нiж у будь-якому попередньому замовленнi.

Можливостi цiеi новоi форми управлiння проектами так мене надихнули, що вся моя майбутня робота зосередилась на вдосконаленнi Scrum для компанiй. У 1995 роцi разом iз Кеном Швабером я презентував на дослiдницькiй конференцii Асоцiацii обчислювальноi технiки працю пiд назвою «Спосiб розробки SCRUM», яка систематизувала цi практики. Пiсля того ми вiдмовилися вiд слiв великими лiтерами та дещо допрацювали цю iдею, але основнi принципи залишаються незмiнними; а компанii, якi прийняли цей спосiб, зазвичай отримують негайнi переваги[7 - Schwaber, Ken. «Scrum Development Process,» у збiрцi OOPSLA Business Object Design and Implementation Workshop, J. Sutherland, D. Patel, C. Casanave, J. Miller, and G. Hollowell, eds. (London: Springer, 1997).].




Перевiряйте та адаптуйте


У системi Scrum команди, якi добре працюють, здатнi досягти того, що ми називаемо гiперпродуктивнiстю. Важко повiрити, але серед груп, якi добре впроваджують Scrum, ми регулярно бачимо десь так вiд 300 до 400 вiдсоткiв покращення продуктивностi. Найкращi команди можуть досягти пiдвищення продуктивностi аж до 800 вiдсоткiв, а потiм повторювати цей успiх знову й знову. Крiм того, в результатi використання цiеi системи подвоюеться якiсть iхньоi роботи.

То як створити в Scrum-командi автономiю, прагнення перевершити самих себе, взаемозаохочення – а потiм досягти гiперпродуктивностi за рахунок поеднання всього цього? Мова про це пiде в рештi роздiлiв цiеi книжки, але базовi принципи я збираюся подати вам тут. У скороченiй формi iх можна також побачити в додатку.

Оскiльки Scrum бере початок iз технiк, використовуваних у японському виробництвi, не завадить трохи дiзнатися, звiдки iх узяли японцi. За iронiею долi, вони багато чого навчилися в одного американця – Вiльяма Едвардса Демiнга. Пiд час американськоi окупацii Японii пiсля Другоi свiтовоi вiйни Демiнг працював на генерала Дугласа Мак-Артура. Пiдхiд Мак-Артура до вiдновлення економiки полягав у тому, щоб звiльнити бiльшу частину вищого керiвництва японських компанiй, пiдвищити керiвникiв середньоi ланки та залучити до дiлових операцiй експертiв зi Сполучених Штатiв, таких як Демiнг. Вплив Демiнга на японське виробництво був надзвичайним. Вiн навчив сотнi iнженерiв того, що називаеться «статистичним контролем процесiв». Основною iдеею було точне вимiрювання зробленого та його якостi, а також прагнення до безперервного покращення. Не просто разового покращення, а постiйного. Слiд завжди шукати, що можна покращити, i нiколи не зупинятися на досягнутому. Для цього потрiбно постiйно проводити експерименти, якi вказуватимуть на можливiсть досягти кращих результатiв. Якщо спробувати цей метод, чи не буде вiн кращим за старий? Як щодо iншого? Що як змiнити один цей момент?

Вiдомий виступ Демiнга перед керiвниками японських пiдприемств у 1950 роцi. Серед слухачiв були й такi люди, як Акiо Морiта, засновник компанii Sony. Демiнг тодi сказав iм:



…хоч якi чудовi у вас технiчнi фахiвцi, саме ви, лiдери, повиннi прагнути успiхiв у покращеннi якостi та однорiдностi продукцii, а вашi технiки мають бути здатнi на цi покращення. Отже, перший крок – за керiвництвом. Перш за все, технiки вашоi компанii та робiтники ваших заводiв повиннi знати, що ви маете завзяття для вдосконалення якостi та однорiдностi продукцii, а також почуття вiдповiдальностi за якiсть продукцii.

Якщо лише говорити про це, нiчого не вийде. Важливо дiяти[8 - Deming, W. Edwards. «To Management.» Промова в Конференц-центрi на горi Хаконе, Японiя, 1950 р.].


Найбiльше Демiнг вiдомий якраз своiм методом дiй – циклом ПРПД (Планувати,Робити,Перевiряти,Дiяти). Цей цикл можна застосувати до виробництва практично всього: автомобiля, вiдеогри чи навiть паперового лiтачка.

Коли я навчаю когось застосовувати Scrum, то використовую саме iх – паперовi лiтачки. Я подiляю людей на команди й ставлю перед ними завдання зробити якомога бiльше паперових лiтачкiв, якi лiтатимуть кiмнатою. У командi буде три категорii людей. Одна людина перевiрятиме, скiльки зроблено лiтачкiв, якi дiйсно можуть лiтати. Друга буде частиною виробничого процесу разом з усiма, але також звертатиме увагу на сам процес та шукатиме способи покращення якостi лiтачкiв i прискорення iх виробництва. Усi iншi концентруватимуться на виготовленнi якомога бiльшоi кiлькостi лiтачкiв, дiйсно здатних пролетiти задану вiдстань за вiдведений на це час.

Потiм я кажу, що ми маемо виконати три шестихвилиннi цикли виробництва паперових лiтачкiв. Одну хвилину кожного циклу команди мають Планувати, як вони збираються робити лiтачки, три хвилин – Робити (виготовляти й тестувати якомога бiльше лiтачкiв, дiйсно здатних лiтати). І нарештi, двi хвилини вони мають Перевiряти. На цьому етапi команда дивиться, як можна покращити процес виготовлення iхнiх паперових лiтачкiв. Що пiшло правильно? Що – неправильно? Чи не слiд змiнити дизайн? Як можна покращити процес виготовлення? А потiм вони Дiятимуть. У системi Демiнга «дiяти» означае змiнювати ваш спосiб роботи на основi реальних результатiв i реального впливу зовнiшнiх умов. Та сама стратегiя використовувалась i в роботах Брукса.

Пройдiть цей цикл тричi, i, хоч що ви виробляете – паперовi лiтачки чи справжнi космiчнi кораблi, – ви станете кращими, значно кращими (прискорившись у два-три рази i щонайменше подвоiвши якiсть). Саме завдяки цьому циклу Демiнга – радикальнiй iдеi на той час, коли ii презентували японцям, – компанiя Toyota i стала автовиробником номер один у свiтi. Саме так працюе будь-який рiзновид «ощадливого» виробництва (американський термiн для використання концепцiй виробничоi системи Toyota) або розробка продукту в Scrum.




Змiнюйтесь або помрiть


Причина того, чому новий спосiб управлiння проектами був таким важливим i чому стiльки рiзних компанiй його прийняли, почасти полягала в надзвичайно поганому станi розробки програмного забезпечення. Проекти майже завжди не вкладалися в строки та бюджет, а часто й взагалi не працювали. І це було не через тупiсть чи жадiбнiсть людей – скорiше рiч була в способi iхнього мислення про роботу. Вони наполягали на застосуваннi каскадноi моделi, казали, що все можна планувати заздалегiдь, навiть що умови не змiнюються в ходi багаторiчного проекту. А це вже просто божевiлля перед лицем таких змiн.

Я переконався в цьому на власному досвiдi в компанii BellSouth, коли вiдвiдував iх як консультант багато рокiв тому. Вони мали висококласних iнженерiв, багато з яких прийшли з вiдомого дослiдницького центру Bell Labs. Вони iдеально дотримувались каскадноi моделi. Бралися за величезнi проекти на 10 чи 20 мiльйонiв доларiв. Могли зiбрати всi вимоги замовника, потiм зачинитися на вiсiмнадцять мiсяцiв i вчасно й чiтко в межах бюджету видати саме те, що просив замовник. Вони були однiею з дуже й дуже небагатьох компанiй у всьому свiтi, яким це вдавалося. Проблема полягала в тому, що на цьому етапi замовники хотiли вже iншого. Обставини змiнювались. Дiловi цикли скорочувались, а клiенти вимагали бiльш iнтерактивного обслуговування.

Мене запросили подивитися, чи зможу я допомогти BellSouth визначити, що вони роблять неправильно. Дуже скоро я зрозумiв, що неправильним був увесь спосiб iхньоi роботи. Це може бути неприемно чути, коли вам здаеться, що ви все робите як слiд. Тому одного дня, коли я став перед повною залою, де було 150 iнженерiв BellSouth, i сказав, що якщо вони не перейдуть на iншу, бiльш iнтерактивну модель, то не втримаються на поверхнi, мене не схотiли слухати. Вони всi були дiйсно розумними людьми, але вважали моi iдеi черговою управлiнською маячнею.

Я нiяк не мiг переконати iх, тому просто знизав плечима й пiшов, залишивши iм останне попередження: «Змiнюйтесь або помрiть»… Компанii BellSouth бiльше не iснуе.




Шу-Ха-Рi


Корiння Scrum проростае з японського мислення та практик. Коли я нещодавно iздив до Японii, щоб зустрiтися з професором Ікуджиро Нонакою, вiн пояснив менi, що в його краiнi Scrum аж нiяк не вважаеться новомодною управлiнською дурницею. До нього ставляться як до способу дiй, способу iснування, способу життя. Навчаючи людей застосовувати цю систему, я часто розповiдаю про мiй власний досвiд вивчення японського бойового мистецтва айкiдо протягом кiлькох рокiв.

Подiбно до айкiдо чи, можливо, танго, Scrum е чимось, що дiйсно можна вивчити лише на практицi. Завдяки постiйнiй практицi та вдосконаленню ваше тiло, розум i дух з’еднуються в одне цiле. У бойових мистецтвах ви вивчаете концепцiю пiд назвою Шу-Ха-Рi, яка вказуе на рiзнi рiвнi майстерностi. У станi Шу ви знаете всi правила та форми. Ви повторюете iх, наче танцювальнi па, тому ваше тiло всотуе iх. При цьому ви не вiдхиляетесь анi на крок.

У станi Ха, опанувавши форми, ви можете робити щось нове. Наприклад, додавати новi повороти до ваших танцювальних па.

У станi Рi ви вже здатнi вiдкинути форми, якi дiйсно опанували на практицi, й вiльно творити, адже знання сутi айкiдо чи танго так глибоко вкорiнилось у вас, що ii вiдображуе кожен ваш крок.

Scrum дуже подiбний до цього. Вiн потребуе практики та уваги, але також безперервного зусилля для досягнення нового стану, в якому речi просто течуть i вiдбуваються. Якщо ви колись спостерiгали за вiдомими танцюристами чи гiмнастами, то знаете, що iхнi рухи можуть здаватись легкими та майже позбавленими зусиль, немов вони нiчого не роблять, а просто живуть. Здаеться, вони не можуть бути десь в iншому мiсцi, а лише там, де в той момент перебувають. Я вiдчув це одного дня, коли крихiтний майстер айкiдо без жодних зусиль вiдправив мене полiтати, причому зробив це так, що я акуратно впав на мат, немов дитина, яку нiжно вкладають у колиску.

Ось чого ви маете досягти за допомогою Scrum. Я всiм зичу досягти цього стану в iхньому життi. Робота зовсiм не повинна вас засмоктувати. Вона може плинути потоком, бути виявленням радостi, шляхом до вищоi мети. Ми можемо бути кращими. Можемо бути великими майстрами своеi справи! Нам просто потрiбна практика.

Решту роздiлiв цiеi книжки я присвячую розгляду конкретних аспектiв Scrum одного за одним. Таке глибоке занурення покликане детально пояснити вам поняття та структуру Scrum. У додатку ви можете знайти текст пiд назвою «Впровадження Scrum – iз чого почати» (стислий опис цiеi системи), але вiн лише розповiсть вам що робити. Якщо ж ви пiдете зi мною до кiнця, я розповiм навiщо.




Що треба запам’ятати


Зволiкання подiбне до смертi.Оглядайте, Орiентуйтесь, Вирiшуйте, Дiйте. Знайте, де ви е, оцiнюйте своi варiанти, приймайте рiшення та дiйте!

Шукайте вiдповiдi ззовнi. Складнi адаптивнi системи дотримуються кiлькох простих правил, якi вони засвоюють iз довкiлля.

Видатнi команди мають своi особливостi. Це рiзнопрофiльнi фахiвцi, автономiя та взаемопiдтримка.

Не гадайте. Плануйте, Робiть, Перевiряйте, Дiйте. Плануйте, що ви збираетесь робити. Робiть це. Перевiряйте, чи вiдповiдае це тому, що ви хотiли. Дiйте з огляду на це та змiнюйте спосiб своеi роботи. Повторюйте це в регулярних циклах i досягайте за рахунок цього безперервного покращення.

Шу-Ха-Рi. Перш за все, засвоюйте правила та форми, а як тiльки опануете iх, вносьте щось нове. Наприкiнцi, досягнувши стану високоi майстерностi, вiдкидайте форми i просто будьте – глибоко засвоiвши все вивчене та приймаючи рiшення майже пiдсвiдомо.




Роздiл 3. Команди



Саме команди виконують проекти у свiтi працi. Існують команди, якi виробляють автомобiлi, вiдповiдають на телефоннi дзвiнки, проводять хiрургiчнi операцii, програмують комп’ютери, готують новини та проникають у дверi захоплених терористами примiщень. Безумовно, iснують також окремi ремiсники чи художники, якi виконують роботу самотужки, але саме команди обертають Землю. І саме на них базуеться Scrum.

Усi це розумiють, але в бiзнесi ми надто часто зосереджуемось виключно на окремих особах, навiть якщо виробництво е командним зусиллям. Подумайте про рiзного роду бонуси, пiдвищення в зарплатi чи посадi, якими винагороджуеться продуктивнiсть у компанiях. Зазвичай усе спрямоване на якогось окремого виконавця, а не на команду. А це, як виявляеться, велика помилка.

Менеджери часто скеровують зусилля на окремих осiб тому, що це iнтуiтивно здаеться iм правильним. Ви хочете мати найкращих людей, а люди рiзнi, тому зосередьтесь на найкращих виконавцях, i ви матимете кращi результати, правда? На жаль, усе не так просто.

Вiзьмiмо, наприклад, процедуру отримання студентами оцiнок пiд час занять. У Єльському унiверситетi особливо складним вважаеться курс комп’ютерного програмування професора Стенлi Айзенштата CS 323. Коли студенти почали скаржитись на те, скiльки часу займае кожне завдання, професор не зробив свое завдання простiшим, а почав вiдстежувати, скiльки часу потрiбно кожному студентовi на його виконання. Потiм Джоел Спольскi, який пройшов курс Айзенштата в далекi 1980-тi, а тепер мае власний бiзнес iз програмного забезпечення, порiвняв отриманi данi з реальними оцiнками, якi люди отримували. Вiн хотiв з’ясувати, чи iснуе якась кореляцiя мiж часом, витраченим на проект, i отриманою студентом оцiнкою. Цiкаво, що не iснуе. Однi люди працюють швидко й отримують «вiдмiнно», а iншi працюють довго, а отримують те саме. Єдиною рiзницею е кiлькiсть витраченого на завдання часу. Як же застосувати це в бiзнесi?

Ну, якщо ви менеджер, то вам, схоже, краще найняти не просто робiтникiв, якi отримують оцiнки «вiдмiнно», а тих, хто отримуе iх за найкоротший час. У Єльському дослiдженнi найшвидшi студенти перевершували своiх повiльних товаришiв у спiввiдношеннi 10: 1. Вони були в десять разiв швидшими, а оцiнки отримували такi самi високi. У десять разiв – це вражае, так? Тому схоже, що компанii мають наймати найшвидших людей i позбуватися повiльних. Це здаеться найкращим пiдходом до пiдвищення продуктивностi, але iншi чинники можуть бути ще важливiшими.

Якщо ви поглянете на команди, а не на окремих осiб, то побачите дещо цiкаве. Існують дослiдження, де переглянуто близько 3800 рiзних проектiв, вiд виконання роботи в бухгалтерських фiрмах до розробки програмного забезпечення для бойових кораблiв i технiчних проектiв в ІВМ. Аналiтики дивилися на данi продуктивностi не окремих осiб, а лише команд. І, якщо вивчити, як працювали команди, ви побачите щось дивне. Якщо найкраща команда могла виконати завдання за тиждень, скiльки, на вашу думку, це займало в найгiршоi команди? Ви, можливо, гадаете, що вийшло спiввiдношення, яке спостерiгалось у Єлi, – 10: 1 (тобто повiльнiй командi потрiбно було понад два мiсяцi, щоб досягти того, що швидка команда робила за тиждень). Однак правильна вiдповiдь та, що мiж командною й iндивiдуальною продуктивнiстю iснуе значно бiльша рiзниця. Насправдi повiльнiй командi треба було не десять тижнiв на роботу, яку швидка команда могла виконати за тиждень, а двi тисячi тижнiв. Отакою великою е рiзниця мiж найкращою i найгiршою командами. То на чому слiд зосередити вашу увагу? На iндивiдуальному рiвнi, де ви можете досягти покращення в десять разiв, якщо якимось дивом зробите всiх своiх працiвникiв генiями? Чи на командному рiвнi, де можна збiльшити продуктивнiсть до нечуваних розмiрiв, навiть якщо просто зробити своi найгiршi команди посереднiми? Звичайно, якщо нацiлюватись на посереднiсть, то ii ви й отримаете. Але що, як ви зможете зробити всi своi команди найкращими?

У певний час у певному мiсцi з певними невеликими групами людей усе стае можливим. Навiть якщо ви нiколи не мали таких команд, ви бачили iх у дii. Ви чули про них захопленi розповiдi. Про iхнi можливостi складають легенди. Особисто я вирiс поблизу Бостона i живу там зараз, а тому менi спадають на думку такi видатнi команди, як Celtics 1980-х у баскетболi чи New England Patriots часiв Тома Брейдi в американському футболi. Коли цi команди виходили на поле, здавалося, вони грають не в ту гру, що всi iншi. Пересування, кидки та удари, якi колись здавалися неможливими, раптом стали звичайною частиною плану гри. Це було так, наче на цих гравцiв спустилося просвiтлення i деякий час вони просто не могли помилятися. Ларрi Берд рухався майданчиком i пасував м’яч навiть не дивлячись, здавалося б, у порожнечу. Але, коли м’яч уже виходив за межi поля, Кевiн Мак-Гейл просто виникав саме там, де вiн i мав бути. А потiм кидав м’яч на край знову, наче не дивлячись, – i Роберт Перiш тут-таки опинявся в iдеальнiй позицii для кидка. Таке абсолютне поеднання мети й довiри якраз i робить команду видатною.

Нам усiм випадало бачити такi команди. Декому з нас пощастило попрацювати з однiею з них (чи бiльше) у своему життi. Коли я створював Scrum, то шукав те, що мають надефективнi команди, але не мають iншi. Чому так виходить, думав я, що однi команди змiнюють свiт, а iншi в’язнуть у посередностi? Що спiльного мають мiж собою дiйсно чудовi команди? І, ще важливiше, чи можемо ми iх вiдтворити?

Виявляеться, вiдповiдь е ствердною.

У своiй оригiнальнiй працi «Розробка нового продукту», де описане те, що пiзнiше стало Scrum, професори Такеучi та Нонака дали характеристики команд, якi вони бачили в найкращих компанiях свiту.

1. Надзвичайнi. Вони мають вiдчуття надзвичайноi мети. Ця вища мета дозволяе iм переходити зi звичайних у надзвичайнi. Цiлком реально саме рiшення бути не пересiчними, а видатними змiнюе iхнiй погляд на самих себе та своi можливостi.

2. Автономнi. Цi команди самоорганiзованi й самокерованi. Вони мають право приймати власнi рiшення про свою роботу та втiлювати iх у життя.

3. Багатофункцiональнi. Цi команди мають усi вмiння й навички, необхiднi для виконання проекту: планування, проектування, виробництва, продажiв, дистрибуцii. Причому цi навички пiдживлюють та пiдсилюють одна одну. Один iз членiв команди, яка розробила революцiйну нову камеру для Canon, описав це так: «Коли всi члени команди перебувають в однiй великiй кiмнатi, чиясь iнформацiя стае вашою навiть без зусиль. Потiм ви починаете мислити категорiями того, що стоiть на першому або на другому мiсцi для групи загалом, а не лише для вашоi дiлянки»[9 - Takeuchi, Hirotaka, and Ikujiro Nonaka. «The New New Product Development Game.» Harvard Business Review (сiчень – лютий 1986 р.): 285–305.].

То як створити команду, нацiлену на вищу мету, самоорганiзовану та постiйно пiдживлювану вмiннями й навичками кожного ii члена? Я витратив чимало часу, щоб це зрозумiти. Зрештою, не можна просто кричати на людей, щоб вони були бiльш самоорганiзованi та надзвичайнi. Мотивацiя мае йти зсередини. Їi нав’язування просто вб’е те, що ви намагаетесь зробити. Можливо, iснуе якийсь простий набiр правил, що заохочують до створення дива?




Довга сiра лiнiя


Я повертаюся думками до того часу, коли був частиною однiеi з таких дивовижних команд. Це було на початку 1960-х, коли я навчався у Вiйськовiй академii Сполучених Штатiв, бiльш вiдомiй як Вест-Пойнт. В останнiй рiк там я був призначений iнструктором моеi кадетськоi роти L2, яку ще називали «Вiльною парою»[10 - Пара винищувачiв, завданням яких е спостереження за ходом бою тазнищення окремих лiтакiв супротивника. (Прим. перекл.)].

У 1963 р. у Вест-Пойнтi було двадцять чотири роти з номерами вiд A1 до M1 та вiд A2 до M2. Тричi на тиждень цi роти виходили на плац i карбували крок у повнiй параднiй формi, з гвинтiвками на плечi та шаблями на боцi, бiлими ременями та погонами. Цi параднi шикування були в Академii справжнiми змаганнями протягом майже двох столiть. На той час наша рота вже бiльш як сто рокiв пасла заднiх у загальному залiку.

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

Спочатку зауваження були простими. «Чарлi встромив шаблю в багнюку». «Джим не розвернувся синхронно з усiма». «Салют Дейва вийшов недостатньо чiтким». Не було жодних покарань чи звинувачень. Були просто факти, викладенi всiма iншими iнструкторами пiд час оцiнювання. Однак це були причини, чому L2 посiдала останнi мiсця в рейтингу.

Через кiлька тижнiв кадети вiдточили свою технiку шикувань, але рота продовжувала отримувати низькi оцiнки. Залишалась одна причина – ii командир. Його команди були недостатньо чiткими i вiддавалися не тодi, коли треба. Звичайно, менi довелось вiддуватися за критику командира, але у вiдповiдь я просто казав: «Оцiнки е оцiнки. Я лише показую вам, що вони означають. Кадети зробили все, що вiд них залежало. Тепер проблема у вас. Чи хочете ви ii виправити? Чи збираетесь програвати вiчно?» Через кiлька тижнiв L2 стала найкращою ротою у Вест-Пойнтi.

Найшанованiшим кадетом в iсторii Академii був генерал Дуглас Мак-Артур. Вiн мав найвищi оцiнки з усiх кадетiв, якi звiдти випустились, i був провiдним полководцем в обох свiтових вiйнах. Як генерала армii та кавалера медалi Пошани, у кадетському корпусi його особливо поважали.

За рiк до того як я став iнструктором своеi роти, у травнi 1962-го, вiн виступив у нас зi своею останньою промовою. Щоб повнiстю зрозумiти ii вплив на кадетiв, ви маете належним чином уявити собi цю сцену. У величезнiй кам’янiй залi з масивними колонами та гiгантськими люстрами, що звисають зi стелi, зiбрались три тисячi чоловiкiв у сiрiй кадетськiй формi. Бiля однiеi стiни над усiею залою здiймався помiст заввишки в десять метрiв. Генерал Мак-Артур, тодi вже доволi немiчний, зiйшов на помiст i виступив iз промовою, яку сьогоднi називають «Довга сiра лiнiя» (за кольором форми кадетiв).



Ви – цемент, який з’еднуе всю будiвлю нашоi нацiональноi системи оборони. З ваших лав виходять видатнi полководцi, якi беруть у своi руки долю Нацii, коли зазвучать набати вiйни.

Довга сiра лiнiя нiколи нас не пiдводила. І, якщо вам доведеться пiти в бiй, мiльйони солдатських душ в оливковому, хакi, синьому та сiрому пiднiмуться з-пiд своiх бiлих хрестiв, карбуючи цi магiчнi слова: Обов’язок, Честь, Батькiвщина[11 - MacArthur, Douglas. «The Long Gray Line.» Промова в Академii Вест-Пойнт, штат Нью-Йорк, 1962 р.].


Я пам’ятаю, як при цьому всiм здалося, що за спиною Мак-Артура, який залишав кадетам свiй останнiй заповiт, дiйсно вишикувався цей легiон солдатських душ. І три тисячi мужнiх чоловiкiв, загартованих для вiйни, яким не так легко заплакати, не могли стримати слiз.



Увi снi я знову чую гуркiт гармат, автоматнi черги, дивне та скорботне гудiння поля бою. Але наприкiнцi своiх днiв я подумки повертаюся до Вест-Пойнту. Адже там завжди лунають цi слова: Обов’язок, Честь, Батькiвщина.

Сьогоднi моя остання вечiрня повiрка разом iз вами. Але я хочу, щоб ви знали: коли я пiду назавжди, моi останнi свiдомi думки будуть про кадетський корпус, знову i знову[12 - Там само.].


Досi кожен кадет в Академii перед випуском зобов’язаний вивчити цю промову напам’ять, рядок за рядком, слово за словом. Вона стала духовною настановою кадетського корпусу та офiцерського корпусу США загалом: Обов’язок, Честь, Батькiвщина.

Майже через рiк пiсля тiеi промови генерал Мак-Артур помер. Потрiбно було обрати одну з рот для урочистого маршу на його похоронi. І що ви думаете? Пiд траурний барабанний бiй за катафалком, що вiз труну одного з найвидатнiших генералiв Америки, iшла «Вiльна пара» – рота, яка понад сто рокiв була найгiршою серед кадетiв.

Через кiлька мiсяцiв пiсля похорону я востанне марширував зi своею ротою пiд час церемонii випуску з Вест-Пойнту. Марширували всi двадцять чотири роти, i через ii мiсце в алфавiтi L2 йшла передостанньою. Пiсля церемонii мiй майбутнiй тесть спитав мене:

– Оця рота, друга з кiнця. Вони вiдрiзнялися вiд усiх решти. Іншi маршували, а вони, здавалось, не торкалися землi. Хто це був?

– Це була моя рота. – сказав я йому. – Цi люди ховали генерала Мак-Артура.

Моя рота досягла надзвичайностi.




Scrum пiд час революцiй


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

Площа Тахрiр сьогоднi вже стала синонiмом египетськоi революцii та невпинноi боротьби в цiй краiнi, але до сiчня 2011 року це була просто ще одна брудна, забита транспортом кiльцева розв’язка в центрi Каiра. На пiвнiч вiд неi розташована рожево-червона будiвля Єгипетського музею, на пiвдень – високi стiни Американського унiверситету в Каiрi та знаменита урядова будiвля Могамма. На заходi ви знайдете штаб-квартиру Нацiональноi демократичноi партii египетського диктатора Хоснi Мубарака, а також штаб-квартиру Лiги арабських держав. Хоч як дивно, на схiдному кiнцi площi був американський фастфуд KFC, що невдовзi став тилом для протестувальникiв, якi кидали камiння та тiснили полiцiю.

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

А в наступному мiсяцi сталося неймовiрне. Лише через те, що люди збиралися разом та говорили свое «нi», один iз найдавнiших та наймогутнiших диктаторських режимiв Близького Сходу був повалений. Цi люди виходили день за днем, нiч за нiччю, заповнюючи собою площу та створюючи нову краiну, де не правив диктатор Хоснi Мубарак, а громадяни могли вiльно висловлювати своi думки. Вони змiнили свiй свiт.

Для журналiстiв це стало грандiозною подiею iсторичноi ваги. Серед тих, хто приiхав до Каiра ii висвiтлювати, була й бригада Нацiонального громадського радiо (NPR), одного з провiдних медiа Сполучених Штатiв. Але спочатку продюсери та репортери були настiльки заскоченi зненацька, що не встигали за подiями, губили матерiали, плутали репортажi та ледь-ледь задовольняли вимоги свого керiвництва у Вашингтонi.

Виправити ситуацiю був посланий Джей Джей Сазерленд, мiй син. Як досвiдчений вiйськовий кореспондент та продюсер, вiн був направлений до Каiра, щоб узяти на себе безперервну пiдготовку репортажiв. Адже подii там набули надто великого масштабу, щоб не виходити в ефiр кожного дня, у кожному випуску новин та кожноi години. Джей Джей опинився в краiнi, де не працювали аеропорти, iноземцi вiдчайдушно намагалися виiхати, а мобiльний зв’язок та Інтернет були вiдключенi. Вiн був там старшим продюсером, але (дуже подiбно до iнструктора у Вест-Пойнтi) продюсер NPR е радше не типовим менеджером чи керiвником, а посередником та органiзатором – тим, хто допомагае чи сприяе. Завданням Джей Джея було допомагати командi виконувати найкращу роботу, яку вони тiльки могли. Не розповiдати iм, що робити, а забезпечувати iх усiм потрiбним. Керiвництво наказувало готувати репортажi та виходити в ефiр кiлька разiв на день, а вже як це зробити, визначала сама команда на мiсцi, вирiшуючи, що саме висвiтлювати i в якому форматi радiопередачi.

На диво, через деякий час команда почала успiшно працювати, причому саме через складнощi зв’язку з вашингтонським керiвництвом. Адже радiйникам довелося дiяти переважно на власний ризик. Постiйнi прямi вказiвки отримувати було просто неможливо, а подii розвивалися дуже швидко, тому для виконання роботи командi довелося самоорганiзовуватись. Однiею з ключових концепцiй у системi Scrum е якраз те, що члени команди самi вирiшують, як вони збираються працювати. Керiвництво вiдповiдае лише за виставлення стратегiчних цiлей, а вже як iх досягти, мае вирiшувати команда. Той, хто не був тодi в Каiрi, просто не мiг слiдкувати за тим, що вiдбуваеться. Майже щодня команда NPR готувала низку репортажiв на наступний день, але подii змiнювались так блискавично, що всi цi повiдомлення майже миттево застарiвали. На площi Тахрiр вiдбувалася масштабна сутичка, лунала якась гучна заява, хтось подавав у вiдставку, i вся робота команди йшла псу пiд хвiст. Раптом виявлялося, що iм майже нема чого вчасно видати в ефiр.

Успiху ж iм вдалося досягти за допомогою Scrum. Вказiвки керiвництва вимагали вiд них виходити з репортажами кожнi дванадцять годин: у вранiшньому випуску та у вечiрньому пiдсумковому. Щоразу Джей Джей звертався до команди й ставив iм три дуже простi запитання: «Що ви робили iз часу нашоi останньоi розмови? Що ви збираетеся робити до нашоi наступноi розмови? І що стоiть у вас на шляху?» Цей звичайний ритуал Scrum змушував кореспондентiв говорити й дiлитися один з одним своiми думками. Але головною роботою Джей Джея, як де-факто Scrum-майстра, було стежити, щоб перешкоди, на якi скаржилися члени команди на однiй зустрiчi, усувалися до наступноi. Перешкодою могло бути що завгодно – вiд проблем з египетською бюрократiею до вiдсутностi безпечного готельного номера, вiд пошуку водiiв та перекладачiв до визволення кореспондентiв iз катiвень жахливоi египетськоi таемноi полiцii «Мухабарат».

Як же це все покращилось? Можу вас запевнити, що хаос, пов’язаний iз загальною непевнiстю, особистими сварками та нездатнiстю миттево видавати новини, швидко перетворився на добре змащений механiзм, яким начальству навiть не доводилось керувати. Натомiсть члени команди керували самi собою. Протягом наступних кiлькох тижнiв бригада NPR у Каiрi пiдготувала бiльше репортажiв, нiж хтось узагалi вважав за можливе. Причому якiсть усiх цих новин була вищою, нiж пропонували конкуренти, за що журналiсти врештi-решт отримали навiть кiлька нагород. То був справжнiй успiх, якого не вдалося б досягти, якби команду не захопило вiдчуття мети (розповiсти про одну з найвидатнiших подiй у iхнiй кар’ерi) i якби вона не мала автономii (здатностi самим вирiшувати, як висвiтлювати рiзнi аспекти великоi подii).

Сьогоднi Scrum використовуеться в усiх сферах роботи Нацiонального громадського радiо – вiд веб-дизайну до журналiстського збирання даних та створення нових передач. Використовують його також команди Chicago Tribune, New York Times, Washington Post i ProPublica. Адже, коли дедлайни пiдпирають, швидкiсть потрiбна всiм.




Одна команда для всiеi роботи


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

Класичним прикладом цього е так звана модель «фаза-брама», за допомогою якоi розробляли програму космiчних шатлiв та iншi проекти NASA в 1960-тi – 1980-тi роки. Сьогоднi ця модель дуже змiнилась, але ось як вона працювала колись. Першою йшла фаза дослiдження, коли люди вирiшували, на що вони збираються замахнутись – можливо, збудувати ракету, що полетить на Мiсяць. Група стратегiв збиралась у кiмнатi й починала про це фантазувати. А далi йшла «брама», коли менеджер або група менеджерiв пiдписували проект як вартий розробки. Другою фазою було визначення масштабу робiт, коли спецiалiсти з вимог та стандартiв вирiшували, що мае бути зроблено. Потiм iшла друга «брама» та ще ряд зустрiчей, пiсля яких усi пiдготованi документи вели до наступноi фази – створення пiдприемницького завдання та плану проекту. Далi всi цi плани проходили ще ряд обговорень та узгоджень, пiсля чого наставала ще одна фаза – розробки, де починалося справжне створення продукту. Пройшовши ще кiлька обговорень та процес пiдготовки документiв, продукт передавався абсолютно iншiй групi для наступноi фази – тестування. Цi люди нiколи не бачили продукту ранiше, але тестували його, пiдписували, що з ним усе гаразд, а потiм проштовхували його до наступноi «брами» або ряду нескiнченних обговорень, iз наступною купою документiв, яких нiхто не читав. І лише пiсля цього продукт потрапляв до шостоi групи людей, якi дiйсно вводили його в експлуатацiю. Виснажливо навiть просто писати про це. А для NASA така робота була звичною.

Якось на початку 1980-х керiвники компанii Fuji-Xerox приiхали до Америки повчитись, як працюе вiдома космiчна агенцiя. Коли ж вони запровадили тi самi процедури в себе в Японii, то вiдразу зiткнулися з падiнням якостi. Кiлькiсть збоiв пiшла вгору, а вiд iхньоi продуктивностi лишилися тiльки кола на водi. Вони швидко вiдмовились вiд цього процесу, боячись, що вiн може призвести до повноi катастрофи.



Із цим цiлком може погодитись комiсiя пiд керiвництвом Вiльяма Роджерса, яка розслiдувала причини катастрофи космiчного корабля «Челленджер» у 1986 роцi. Як написав у своему вiдомому «Додатку F» до звiту комiсii фiзик Рiчард Фейнман: «Цiлком може виявитись, що з будь-якою метою, чи то для внутрiшнього споживання, чи то для зовнiшнього, керiвництво NASA перебiльшуе надiйнiсть своеi продукцii до фантастичних показникiв»[13 - Feynman, Richard. Report of the Presidential Commission on the Space Shuttle Challenger Accident, Appendix F – Personal Observations on Reliability of Shuttle. Звiт (1986).].


Факт залишаеться фактом: якщо поглянути на найкращi команди (схожi на тi, що iснували в Toyota чи 3M, коли Такеучi й Нонака писали свою працю, або на тi, що iснують у Google, Salesforce.com чи Amazon сьогоднi), ви не побачите там такого розподiлу ролей. Члени всiх команд разом виконують усю роботу, вiд початку до кiнця.

Розгляньмо iнший приклад. У компанii Salesforce.com за гнучку iнфраструктуру релiзiв вiдповiдае Нiкола Дурамбе. Вона керуе роботою приблизно двохсот Scrum-команд у компанii, яка постiйно потрапляе в рейтинги ста найкращих роботодавцiв за версiею журналу Fortune та найбiльш iнновацiйних компанiй свiту за списком Forbes. Вона каже, що вважае Scrum «таемним соусом» своеi роботи. «Коли ми були стартапом, то робили якийсь великий релiз три чи чотири рази на рiк. Але в 2005–2006 роках, коли ми зросли та розширились, управляючи проектами типовим каскадним способом, цей показник упав до одного разу на рiк. Так залишати було не можна. Тому ми запровадили Scrum. Пiсля того релiзи в нас пiшли тричi на рiк. Не так уже багато великих пiдприемств здатнi похвалитися тим самим».




Конец ознакомительного фрагмента.


Текст предоставлен ООО «ЛитРес».

Прочитайте эту книгу целиком, купив полную легальную версию (http://www.litres.ru/pages/biblio_book/?art=23006811&lfrom=362673004) на ЛитРес.

Безопасно оплатить книгу можно банковской картой Visa, MasterCard, Maestro, со счета мобильного телефона, с платежного терминала, в салоне МТС или Связной, через PayPal, WebMoney, Яндекс.Деньги, QIWI Кошелек, бонусными картами или другим удобным Вам способом.



notes


Примiтки





1


Eggen, Dan, and Griff Witte. «The FBI’s Upgrade That Wasn’t; $170 Million Bought an Unusable Computer System.» Washington Post, 18 серпня 2006 р.: A1.




2


Status of the Federal Bureau of Investigation’s Implementation of the Sentinel Project. US Department of Justice, Office of the Inspector General. Report 11–01, жовтень 2010 р.




3


Там само.




4


Ohno, Taiichi. Toyota Production System: Beyond Large-scale Production (Cambridge, MA: Productivity, 1988).




5


Roosevelt, Theodore. «Citizenship in a Republic.» Промова у Сорбонському унiверситетi, Париж, Францiя, 23 квiтня 1910 р.




6


Takeuchi, Hirotaka, and Ikujiro Nonaka. «The New New Product Development Game.» Harvard Business Review (сiчень— лютий 1986 р.): 285–305.




7


Schwaber, Ken. «Scrum Development Process,» у збiрцi OOPSLA Business Object Design and Implementation Workshop, J. Sutherland, D. Patel, C. Casanave, J. Miller, and G. Hollowell, eds. (London: Springer, 1997).




8


Deming, W. Edwards. «To Management.» Промова в Конференц-центрi на горi Хаконе, Японiя, 1950 р.




9


Takeuchi, Hirotaka, and Ikujiro Nonaka. «The New New Product Development Game.» Harvard Business Review (сiчень – лютий 1986 р.): 285–305.




10


Пара винищувачiв, завданням яких е спостереження за ходом бою тазнищення окремих лiтакiв супротивника. (Прим. перекл.)




11


MacArthur, Douglas. «The Long Gray Line.» Промова в Академii Вест-Пойнт, штат Нью-Йорк, 1962 р.




12


Там само.




13


Feynman, Richard. Report of the Presidential Commission on the Space Shuttle Challenger Accident, Appendix F – Personal Observations on Reliability of Shuttle. Звiт (1986).