Ролі в скрамі: хто є хто
Одна з перших речей, яку слід зрозуміти організації при переході на скрам, — це те, як ролі в скрамі відрізняються від традиційних ролей на проєкті. У скрамі всього три ролі, та вони не узгоджуються зі звичними для нас посадами. Почнемо з короткого визначення кожної з них:
- Власник продукту — носій бачення (цілісної картини) продукту.
- Скрам-майстер — допомогає команді ефективно використовувати скрам в розробці продукту.
- Команда розробки — розробляє продукт.
Це чудово, та досі малозрозуміло для організації, що поки не знайома зі скрамом. Більше того, ці ролі дещо нагадують каскадну модель, тому напрошуються порівняння: власник продукту — це наче спонсор чи як? Не зовсім. Давайте розберемося детальніше.
Власник продукту: той, що несе цінність для бізнесу
На власникові продукту тримається успіх проєкту: ця людина визначає, яку роботу потрібно виконати, і розставляє пріоритети. Йому або їй потрібно знати, які результати очікуються від проєкту і чому саме такі результати важливі — для клієнтів, ринку й організації. Власник продукту також представляє всі ці інтереси перед командою проєкту, в ході роботи діючи як помічник-експерт.
Важлива відмінність власника продукту від будь-якої іншої ролі в традиційному проєктному менеджменті — він залишається активно залученим увесь час. Наприклад, власник продукту оцінює роботу, що лишилася, і виставляє за нею нові пріоритети, коли потреби змінюються і приходить новий зворотний зв’язок. Це докорінно відрізняє його від традиційного спонсора, який відразу визначає об’єм робіт. До того ж, власник продукту відповідає за те, щоб донести до всіх учасників процесу їхній вплив на команду.
Для скрам-ініціатив власник продукту — це людина, що несе бізнес-цінність; він фокусується на тому, щоб робота відповідала тій, яку потрібно виконати для досягнення цілей проєкту. Це створює для нього спокусу контролювати процес, та слід пам’ятати: роль власника продукту не передбачає такого контролю (детальніше зупинимось на цьому, коли говоритимемо про команду розробки). Власнику продукту необхідно бути дисциплінованим і утримуватися від спроб контролювати активності команди розробки. В цьому йому допомагає скрам-майстер.
Скрам-майстер: захисник
У ролі скрам-майстра два окремих компоненти. По-перше, він захищає команду, турбуючись про те, щоб усі учасники проєкту, особливо в команді розробки, могли робити свою роботу не відволікаючись. Деякі з відволікаючих факторів можуть бути прямо пов’язаними з роботою — наприклад, якщо власник продукту порушує кордони і починає нав’язувати команді свій підхід до роботи. Або ж скрам-майстру доводиться захищати команду від організаційних змін чи внутрішніх проблем — наприклад, ініціювати заміну непрацюючих комп’ютерів, підтримувати тишу на робочому місці тощо.
По-друге, (крім команди) скрам-майстер захищає сам процес скраму. Це експерт, що знає, як працює скрам і як його застосовувати. Йому (їй) потрібно відповідати за те, щоб власник продукту й команда розробки не виходили за межі скрам-фреймворку. Додатково скрам-майстер може навчати інших членів команди застосовувати скрам якомога ефективніше.
Ця роль сильно відрізняється від традиційної ролі менеджера проєктів, як би часто їх не порівнювали. Менеджери проєктів відповідають за управління щоденною роботою команди, це задає напрямок і їхньої щоденної роботи. У той же час, єдине, що формально зобов’язаний підтримувати скрам-майстер — це процес.
Команда розробки: автономний колектив
Усе це приводить нас до логічного питання: хто ж відповідає за те, щоб люди виконували свою роботу? Ось тут у гру вступає команда розробки. Типова скрам-команда включає від п’яти до дев’яти людей, які виконують основні функціональні ролі, необхідні для завершення проєкту. В розробці програм це архітектори, тестувальники, розробники й дизайнери; та всі ці посади важливі лише для позначення вмінь людини.
Команда діє спільно: вона визначає, як досягти цілей. Для окремих фіч, над якими вона працює, пріоритет визначає власник продукту. Те, як виконується робота, визначає скрам-процес, за який відповідає скрам-майстер. Решту вирішує команда, а скрам-майстер має максимально сприяти тому, щоб усе відбувалося саме так. Наприклад, кожен учасник команди може взяти на себе по одній фічі з уточненого беклогу продукту і самостійно вирішити, як саме йому або їй виконувати свою роботу.
Такі повноваження — основа скраму. Вони встановлюють тісну співпрацю між учасниками команди і створюють позитивне робоче середовище. Хоч командна робота присутня і в моделі водоспаду, та в останній нею керує менеджер проєкту, команда не самоорганізована.
Синергія: співпраця при унікальності ролей
В цій статті ми поверхнево пройшлися по трьох ролях у скрамі, та навіть цей огляд показав, що всі ролі скраму унікальні — це не просто нова версія ролей із моделі водоспаду. Більше того, кожна роль доповнює інші; успіх проєкту залежить від того, наскільки повно засвоєна кожна роль і наскільки вони можуть взаємодіяти. Коли організація переходить на скрам, їй необхідно підтримувати всі три ролі, вирощувати в них експертизу й уникати порівнянь із моделлю водоспаду.
Перекладено й адаптовано командою BrainRain за матеріалами Scrum Alliance
