Читать книгу Scrum. Навчись робити вдвічі більше за менший час - Джефф Сазерленд - Страница 6

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

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

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

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

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

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

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

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

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

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

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

Не буде перебільшенням сказати, що в період незначного зростання таке марнування є злочином проти суспільства, а не просто комерційними втратами. Усунення марнування має стати першорядним завданням будь-якого підприємства[4].

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Значення має не критик, не людина, яка вказує, де сильний спіткнувся чи де справжній діяч міг би зробити краще. На повагу заслуговує той, хто сам на арені, чиє обличчя вкрите пилом, потом та кров’ю, хто відважно бореться, помиляється, програє знову і знову, бо не буває зусиль без помилок та поразок, але все одно прагне діяти, хто знає великий ентузіазм, велику відданість, хто розтрачує себе в гідній справі і в кращому випадку зазнає наприкінці тріумфу високого досягнення, а в гіршому хибить, однак після великих дерзань. Тому його місце ніколи не буде поруч із тими холодними та боязкими душами, що не знають ані перемог, ані поразок[5].

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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