Чому Agile — дієві «ліки» для бентежного світу. Колонка

Марина Мельник, засновниця компаній SkillsUp.ua та weem.pro, підготувала для AIN.UA матеріал про Agile та пояснює, чим його застосування може стати корисним і що взагалі потрібно про нього знати.

Коли Жамі Кассіо, американський футуролог, старший науковий співробітник Інституту майбутнього та професор Каліфорнійського університету, запропонував нову модель світу — BANI (Brittle, Anxious, Nonlinear, Incomprehensible), було дивне відчуття: «Ну, куди ще більш тривожно й незбагненно?»

Але світ дуже скоро побачив ковід, а пізніше — те, що ми вважали більше ніколи не може бути в нашій реальності — війну.

Тож ми продовжуємо занурюватися в неможливість прогнозування і ставити запитання:

• Що робити?
• Як пристосуватися до ще більших викликів у житті?

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

Для робочих моментів, як не дивно, рішення є, і воно вам дуже знайоме — мабуть, очевидніше, аніж могло здаватися. Мова піде про використання Agile-підходу.

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

Крім цього, Agile — така собі парасоля для низки фреймворків та методологій, які розділяють цінності та принципи маніфесту, спираються на них. А в описі програмних платформ йде більш структурована подача, що і як можемо робити для ефективної реалізації ІТ-проєктів.

Чому Agile зараз такий актуальний

Тому що ми потребуємо ці опори — філософію підтримки та взаємодопомоги. Ще більш необхідно бути гнучкішими, чути клієнтів та розуміти, що їм важливо. Зараз ми — і не тільки українці, а і весь світ — стали заручниками поточної ситуації. Це як «ефект метелика».

Agile — не тільки про таку філософію. Він має два вхідні підходи — Scrum і Kanban. Вони дають дуже чіткі інструкції, як треба будувати свою роботу, щоб через неї реалізувати всю вищезгадану філософію, усі ті цінності. У співпраці з компаніями я використовую саме Agile-практики, і щоразу мені вдається доводити їхню ефективність. Вони не про теорію, а про конкретні дії.

Складники Agile або як реалізувати цей підхід

Якщо ваша компанія вже сьогодні існує на ринку, то в неї напевно є:

• бачення;
• стратегія;
• ключові цілі;
• вибудувана операційна діяльність.

Це називається Run the business, і тут застосовується процесний підхід.

У нас є операційна діяльність компанії і частина, коли потрібно, щоб вона функціонувала «As-Is». Тут нам може знадобитися «Канбан», але в цій статті мені важливо зачепити трансформаційну діяльність — ту, яка виводить компанію на кардинально новий рівень.

Наприклад, якщо ви хочете вивести компанію на новий рівень в іншому конкурентному середовищі, відкрити офіс, запустити департамент, автоматизувати проєкт, установити нове програмне забезпечення, зробити аналітику — здобувати унікальний результат, який до цього не робила компанія — тут застосовується проєктний підхід Change the business.

Що ще може бути трансформаційною діяльністю в компанії:

• впровадження нового департаменту;
• усунення департаменту;
• виведення департаменту в аутсорс;
• налагодження автоматизації процесів усередині департаменту;
• злиття;
• розроблення програмного забезпечення;
• запуск нового продукту на ринок;
• запуск нової маркетингової кампанії;
• ребрендинг.

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

Якщо ваша компанія тільки формується, то навіть створення першого процесу йде через проєкт, наприклад, запустити напрям онлайн-продажу.

Коли функції онлайн-магазину готовий, забезпечення циклу продажу налагоджено, ми здобуваємо унікальний результат. Реліз проєкту відбувся, ми його закриваємо. Тепер він стає частиною нашого операційного процесу: працює за передбачуваним сценарієм, за яким систематично отримуємо очікуваний результат.

Якщо ми потроху доробляємо функціонал магазину, виправляємо якісь помилки — це все ще частина IT-процессу. А якщо вирішимо перейти на нову платформу — це буде новий проєкт.

Тож повернемося до проєктного підходу в BANI світі.

Щоб реалізувати у своїй компанії Agile, потрібно виконати такі кроки:

Етап 1. Створіть портфоліо всіх проєктів компанії.

Кроки:

1. Визначте, що хочете змінити кардинально. Виписуємо це з позиції проєктів (очікуваний результат, бюджет, термін).
2. Пріоритезуємо — створюємо список, де зверху розташовується найважливіший проєкт (найкраща практика, коли проєкти відрізняються за пріоритетом).
3. Відповідно до пріоритетів виділяємо людей.
4. Деякі проєкти залишаємо чекати свого часу для виконання

Етап 2. Люди (команда проєкту) деталізують та пріоритезують список вимог до результату, уточнюють бюджет, термін.

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

Такий підхід дає змогу раніше зрозуміти, що починаємо рухатися не туди, якщо це стається.

У трансформаційних проєктах я рекомендую застосовувати «Скрам».

У ньому є чітко визначені ролі, кожна з яких відповідає за певну частину роботи. Але водночас вони взаємопов’язані й ми розуміємо, що всі в одному човні:

• власник продукту — представник компанії/бізнесу, як частина команди;
• команда — люди, які будуватимуть класний продукт;
• скрам-майстер допомагає обом ролям усувати перешкоди та будувати проєктні процеси за скрамом.

Важливо, щоб ролі дійсно були зрозумілі та прийняті тими, хто грає, і реалізовувалися повною мірою.

Власник продукту або Product owner допомагає спеціалістам зрозуміти потреби. Цю роль у компанії буде грати той, хто краще всього розуміє, який результат та для чого ми хочемо здобути — відчуває бізнес та його зміни, щоб коректувати вимоги для результату, якщо команда йде не туди.

Він відповідає за те, щоб потреби ринку були відображені в продакт-беклозі (списку вимог до продукту), відповідно пріоритезуючи вимоги. Й обовʼязково пояснює команді, чому саме так. Спеціалісти приймають ці вимоги в роботу, коли вони стають зрозумілими.

Product owner’у важливо приносити бізнесу максимальну цінність своїм продуктом і мислити короткими ітераціями поставлення частин готового продукту вже кінцевим користувачам, щоб діставати зворотний зв’язок.

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

Спеціалісти працюють над реалізацією запланованих завдань упродовж двох тижнів.

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

Скрам-майстру важливо навчитися бути не контролером, не комунікувати в директивній парадигмі, а в протилежній — лідера-служителя. Servant-leadership — найбільш актуальна філософія на сьогодні.

Скрам-майстер у парадигмі «лідерство-служіння» дивиться, де і які питання мають працівники. Насамперед у продукт-овнера та команди, але можливо й у стейкхолдерів — де є проблеми, які овнер може допомогти усунути.

І тоді демонструє інший підхід до вирішення перешкод: не через менторство — «Я знаю, як робити», а через коучінг — «Як би ми могли вирішити цю проблему». Він знає, які питання поставити, щоби команда самостійно знайшла рішення. Це підхід фасилітації.

У результаті кожні два тижні ви здобуваєте такий потенційно готовий продукт як інкремент — останній артефакт скраму, спираючись на цінності agile, маючи власні цінності в скрамі, 3 ролі, 3 артефакти і 5 подій. Одна з них — двотижневий спринт. Сьогодні пропоную в режимі BANI-світу мати саме цей строк. Усе це дає змогу команді самостійно моніторити прогрес шляху за наміченим планом на прогнозований період. Рухатися короткими ітераціями, чутко реагуючи на крихкість ринку.

Тобто, головна подія скраму — спринт. Потім маємо сумісне планування — коли думку про термін виконання завдання висловлюють усі, і приходять до спільного знаменника, як рухатимуться. Також проводяться щоденні зустрічі — daily scrums, коли за 15 хвилин треба обговорити, чи команда все ще йде за планом, чи ні. У цьому допомагає burnout chart, де можна побачити створений план і прогрес за ним.

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

І, власне, ретроспектива спринта — наскільки добре рухалися, де були складності та як можуть виправити це за наступні два тижні, щоби стати ефективнішими.

Автор: Марина Мельник, засновниця компаній SkillsUp.ua та weem.pro