Scrum – cпринт замість марафону

Scrum було презентовано у 1995 р. на одній із технічних конференцій. Дехто на це похитав головою, а інші сказали: «Отаке! Беремо!», і почали робити проекти по Scrum. Як наслідок – через 6 років вже на традиційних конференціях із проектного менеджменту було достатньо прихильників цієї системи. У сорочках із фланелі та футболках вони намагались все спрощувати, бо так більше простору для креативу: коли все зрозуміло та прозоро, з’являється час на роздуми та створення чогось нового. Натомість, купа правил, надлишкові вимоги та вказівки не сприяють креативу – в тій мряці немає інновацій, а саме вони потрібні будь-якому бізнесу.

Хлопців у футболках, які намагались усе спростити, їхні колеги по проектному менеджменту не сприймали серйозно. А вони, до речі,  робили важливі справи та отримували високі результати. Тож десь у 2001 р. у штаті Юта було зібрано 17 тогочасних лідерів думок. Три-чотири дні вони поспілкувались, створивши в результаті  документ, що, як пишуть у книжках, «зумовив подальший розвиток індустрії». Зараз цей документ називається «agile-маніфест». У ньому описані 4 цінності та 12 принципів управління проектами. Лише поставивши собі одне просте запитання: що відрізняє успішні проекти від неуспішних, дали змогу хлопцям досягти таких успіхів. ?

Непорушні основи гнучкості

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

Друга цінність полягає в тому, що «співпраця з замовником важливіша за обговорення умов контракту». Стосунки з клієнтом мають бути міцно побудованими, тож краще, щоб вони були нормальними. Коли клієнт прийшов до вас та попросив про щось, а ви йому «того немає у контракті», то він все одно знайде, як це обійти, але згодом ткне і вам пальцем у контракт у відповідь на якесь прохання. Такі стосунки перетворяться на перекидання контракту від клієнта до підрядника і назад, на затримки у підписанні документів, тощо, а довіри між ними не залишиться.

Третій принцип: «працюючий продукт важливіший за вичерпну документацію». Що вони там мали на увазі під документацією у 2001 р.? Всім керівникам проектів відомо, що найгірше, це коли когось з його злагодженої та крутої команди переводять на інший проект. Це одночасно і гірко, і неминуче, тож менеджер цьому протистоїть, вимагаючи від своєї команди підтримання технічної документації в актуальному стані. Такому, щоб будь-який новачок міг із цими даними за тиждень-другий стати до роботи. В цьому принципі  йдеться скоріше про ту проектну документацію, що створюється для презентацій у PowerPoint. Постає питання: на чому саме команда фокусує свою увагу? Іноді складається враження, що половину робочого часу ми витрачаємо на геніальні презентації для внутрішніх замовників, а не на створення робочого продукту для клієнта. А потім підвищують у посаді тих, хто добре все презентував, а не тих, хто працював. За геніальною презентацією часто суті не видно. Зібрались, головами похитали, подивились у PowerPoint чи Excel, розійшлись, а скільки коштів втрачено за півроку презентацій замість справи,  ніхто навіть не береться рахувати.

Четверта цінність «готовність до змін важливіша за дотримання плану». Довгострокові плани бюджетування, KPI, бонуси та інша корпоративна радість ніяк не передбачають тих змін, що можуть відбутись за рік. А на них треба реагувати.

Задача, де все зрозуміло

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

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

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

Що відбувається під час однотижневого циклу такої спрінт-роботи? Вся команда збирається о 10:00 на одну-дві години аби спланувати, що має бути зроблено за тиждень. Власне, навіть, почути, що замовник хоче, щоб для нього зробили. Всі свої побажання він має викласти у підготовленому до зустрічі файлі. Команда дає зворотній експертний зв’язок. Завдання проходять крізь декомпозицію на дрібніші, а питання допомагають з’ясувати деталі, бо там може сидіти сам диявол. Наприклад, приходить технічне завдання на 300 сторінок, команда його відкриває, а там «Хочу собачку». Ну і хто яку собі собачку уявить! Маленьку, гігантську, іграшкову чи взагалі значок e-mail. Усі ці питання необхідно задати замовнику аби мати чітке розуміння плану дій, а лише потім відпускати його з зустрічі. Велике завдання має бути розбите на дрібніші  на день максимум, так починається робота з понеділка по п’ятницю. Кожного дня команда зустрічається зі scrum-майстром хвилин на 15 біля дошки – актуалізували статус, прозвітували, попересували картки та розійшлись до роботи. Заздалегідь потрібно вирішити проблеми самоорганізації, тобто, щоб учасники команди самі знали, що до дошки треба підходити та картки пересувати в залежності від виконаних робіт. Коли планування проведено добре, з цим проблем, як правило, не виникає.

Отак, зустрічаючись щодня на 15 хвилин, люди роблять свою роботу, а наприкінці тижня знову проходить зустріч із замовником. Команда проводить демонстрацію зробленого, а замовник дає зворотний зв’язок. Усі зустрічі проводить scrum-майстер, який слідкує аби вони починались та закінчувались вчасно, робить все, щоб ніхто не почувався як на стандартних бізнес-мітингах, де народ сидить у смартфонах або перетягує одіяло один в одного, тощо.

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

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

Таке планування робить складне простим, а велике – таким, що можна виконати.

Юрій Козій, Agile-коуч, керівний партнер в Agile Drive

 

Добавить комментарий