Скрам-команда і стейкхолдери: як підвищити продуктивність сучасної розробки?

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

Проблема

Одна з найгостріших проблем у взаєминах між замовниками та розробниками — це брак комунікації, внаслідок чого виникає низка таких загроз:

• створення не того продукту, який очікував замовник;
• відсутність головного функціоналу або наявність другорядного чи навіть зайвого;
• хронічна затримка релізів;
• збільшення витрат у зв’язку з необхідністю перероблювати;
• втрата переваг (репутаційні ризики, послаблення позицій на ринку тощо).

Це вказує на необхідність пошуку вирішення цих проблем та потребу в гармонійній комунікації для досягнення мети.

Сім сфер скрам-команди

Останнім часом скрам-підхід ступив крок уперед і став іще ближчим до бізнесу.
В офіційному посібнику “Скрам” (Scrum Guide 2020) сказано про сім сфер відповідальності скрам-команди:

1. Взаємодія зі стейкхолдерами.
2. Верифікація.
3. Підтримка.
4. Операційна діяльність.
5. Експериментальна діяльність.
6. Дослідницька діяльність.
7. Розробка (а також будь-яка інша діяльність, допомагає досягти мети розробки).

Проблема, яку ми розкриваємо у цій статті, стосується першого пункту в переліку — взаємодії зі стейкхолдерами. Це передбачає такі риси скрам-команди:

• інтегрованість (і внутрішню — діяльність розробників, тестувальників, аналітиків та ін. інтегрована між собою, і зовнішню — діяльність команди не є “апендиксом” в організації, а інтегрована у її бізнес);
• цілісність (кросфункціональність, автономність, відповідальність кожного учасника);
• компетентність (кожен учасник команди зокрема й команда в цілом виконують чітко окреслені ролі та обов’язки).

Насамперед ідеться про “класику” — скрам-майстер тренує команду, щоб забезпечити належну реалізацію мети розробки, власник продукту представляє інтереси стейкхолдерів, а команда розробників створює продукт.

Симптом цапа-відбувайла

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

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

Говорячи про “крок уперед” і розвиток Скраму, я маю на увазі те, що:

1. Сучасний Scrum усвідомлює цю проблему.
2. Сучасний Scrum має для неї рішення.

Рішення полягає у зміщенні акценту з однієї ролі (наприклад, власника продукту) в бік відповідальності з боку всієї команди. Це передбачає зменшення шкідливої залежності від однієї персони та допомагає прискорити розробку.

Звучить напрочуд просто, однак реалізувати перехід від пошуків “крайнього”, “винуватого”, “цапа-відбувайла” до командної відповідальності — вкрай непросто. Щоб цього досягти, команда має бути зрілою, і скрам-майстер має зростити її до такого рівня (див. перелік рекомендованих статей на цю тему у кінці статті).

Стейкхолдери

Хто такі стейкхолдери? У контексті розробки ІТ-продукту — всі, кого вона стосується.

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

Проблема гармонійних взаємин зі стейкхолдерами

У кожного підрозділу компанії своя специфіка, тому в корені взаємодії між ними закладений певний конфлікт. Для того, щоб досягти мети розробки (product goal), сучасний скрам ставить завдання — досягти гармонії у цій взаємодії.

На побудову гармонійних взаємин можуть більшою мірою впливати одні, а не інші учасники розробки. Наприклад, власник продукту, скрам-майстер чи експерт. Природним чином виникають:

• залежність від такої фігури;
• загроза токсичності (за досягнення всієї команди хвалять одного “улюбленця публіки”, що викликає заздрість, відчуття несправедливості й демотивовує команду).

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

Хто і як має вирішити проблему взаємин зі стейкхолдерами

Ми вже з’ясували, що покладати надію окрему особу (наприклад, власника продукту) у цьому питанні — хибний і застарілий шлях.

Сучасний Scrum наполягає на посиленні ролі скрам-команди. Відповідно, “взаємодія зі стейкхолдерами” стоїть першим пунктом у переліку сфер відповідальності скрам-команди в офіційних постулатах Скарму.

Отже, саме самоорганізована скрам-команда відповідає за формування гармонійних взаємин зі стейкхолдерами.

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

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

Чорна скринька

Але як саме “команда відповідає”? Scrum свідомо залишає цю містику команді. Проілюструємо це прикладом “Чорної скриньки”.

На вході маємо низку завдань, що потрібно виконати. На виході — бажаний результат. Посередині — чорна скринька. Коли результат задовольняє або перевищує очікування всіх сторін — нікого не хвилює, що всередині “скриньки”.

Футбол

Проведемо паралель із футболом. Нападники забивають голи й тому найпершими дістають вінець слави. Незважаючи на це, в інтерв’ю журналістам вони часто запевняють: “Перемога — заслуга не моя, а всієї команди”. Якби не пас півзахисника, нападник не зміг би реалізувати гольовий момент. Якби не захисники й воротар — команда пропустила би купу голів і не змогла виграти. Щось схоже відбувається і в роботі скрам-команди.

Приклади з практики

Два поверхи

Компанія мала власні ІТ-платформи й свій штат розробників. Програмісти комфортно розташувалися у прозорій залі на 24-му поверсі хмарочоса, у той час як бізнесмени на 25-му.

Представники бізнесу несистемно вимагали від “айтішників” виконати те чи те завдання й не завжди отримували очікуваний результат, внаслідок чого сформували негативне ставлення до колег. Це породило нездоровий клімат в компанії й погано впливало на результати. (Таку ж проблему зі ставленням бізнесу до ІТ я спостерігав і у випадку аутсорсу!) Двадцять п’ятий поверх відверто зневажав мешканців двадцять четвертого, які почувалися деморалізованими! Про яку мотивацію могла йти мова?

Керівництво компанії запросило мене запровадити Scrum в один із проектів розробки.

Перше, що я зробив, це попросив компанію долучити до нашої команди власника продукту, який представлятиме інтереси всієї компанії, і переселити його з 25-го (де були представники бізнесу) на 24-й (до когорти айтішників). На основі скрам-моделі я сформував нову скрам-команду.

Перебування представника бізнесу (Product Owner) у самій серцевині створення продукту допомогло усунути безліч перешкод, зібрати цінні відомості, донести важливу інформацію до стейкхолдерів. Гармонійні стосунки з ними у взаємодії з власником продукту, який перебував на території розробників, було сформовано. Позитивні результати відчули всі — вже за перший місяць роботи за скрам-моделлю.

Щоб досягти бажаного результату, як скрам-майстер я переконався тому, що:

• Усі учасники скрам-команди розуміють очікування стейкхолдерів;
• Змінено стиль комунікації на ненасильницький (існує повага до колег, неприпустимий тексичний стиль спілкування — зверхній, принизливий чи навіть нахабний);
• Стейкхолдери зрозуміли очікування з боку команди розробників й почали взаємодіяти (оперативно надавати необхідні відомості, пояснювати тощо).

Тандем

Замовником наших консалтингових послуг був інвестиційний банк, що мав розробити цифрове рішення для одного зі своїх сервісів.

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

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

За старою школою, каміння мало би полетіти у власника продукту. “Це він винуватий у тому, що вимоги стейкхолдерів було нечітко озвучено” — щоб шукати крайніх, багато розуму не треба. Це також не відповідає сучасному Скраму.

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

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

Завдяки такому тандему ми успішно досягли гармонійних взаємин із замовником і мети продукту (product goal).

Варто зауважити, що команда зі свого боку також спрацювала професійно — поводилася проактивно, ставила всі питання, необхідні для того, щоб якнайкраще зрозуміти очікування та вимоги замовника, і щоб “тандему” були зрозумілі потреби розробників.

Без “тандему”, імовірно, ніхто не взяв би відповідальності на себе, за старою звичкою звинувачуючи власника продукту. Натомість, результат порадував усіх:

1. Релізи виходили частіше, ніж раніше.
2. Витрати часу й інших ресурсів було скорочено вдвічі.
3. Замовник отримав якісний продукт, що бездоганно виконував найважливіші функції (неважливі ми прибрали взагалі).

ВИСНОВКИ

1. Розвиток Scrum ще більше задовольняє потреби сучасного бізнесу через емпірично доведений підхід до функціонування скрам-команд.
2. Менеджерам необхідно усвідомити власну відповідальність за формування гармонійних стосунків із розробниками, надаючи їм необхідну інформацію та фахівців, які допоможуть усунути бюрократичні та інші перешкоди на шляху створення продукту.
3. Учасникам розробки необхідно зростати у зрілу й інтегровану команду (де інтегровані і внутрішні, і зовнішні сфери роботи), що здатна самостійно вирішувати проблеми для виконання продуктової мети.

Посилання

П’ять рівнів переходу на Agile: самокеровані команди
Рольова модель Scrum
Рольова модель Scrum: як виникла і чому важлива
Самокеровані та самоорганізовані команди: Початок
Мій перший фейл у запровадженні аджайл-культури
SAFe: Які компанії потребують масштабування?

ДОЛУЧИТИСЯ ДО AGILE.LIVE

• Найближчі сертифікаційні тренінги Agile.Live: Professional Scrum Product Owner (PSPO), Advanced Scrum Master with PSM II Certification
• Підписатися на сторінку у LinkedIn
• Підписатися на Telegram-канал Agile.Live
• Підписатися на You-канал Agile.Live