“Чому в нашій ситуації рольова модель не працює?” Стара культура не дає ходу молодій динамічній моделі. Конфлікт старої та нової парадигм становить один із найбільших ризиків у запровадженні Scrum-підходу загалом і формуванні скрам-команд зокрема.

Актуальність проблеми

Головна причина успіху розробки продукту — команда. Вона ж є головною причиною провалів.

Про команду, командний дух, командного гравця, командну гру, командну єдність (перелік “корпоративної командності” можете продовжити самостійно) написано сотні книг і проведено безліч тренінгів. Чому в такому разі одні компанії виводять продукт на ринок швидше, ніж інші?

Очевидно, що поняття “команди” кожен розуміє по-своєму. Проте у Scrum існує чітка концепція команди, що виникла не на рівному місці. (Про шлях скрам-команд див. у нашій попередній статті “Рольова модель Scrum: як виникла і чому важлива”).

Тож у цій статті розглянемо геніальну, мінімалістичну та напрочуд ефективну модель команди в Scrum, якою вона є сьогодні. Її також називають рольовою моделлю, адже йдеться про певні ролі, що обов’язково мають бути в кожній скрам-команді. Відсутність бодай однієї свідчить про відсутність Scrum. Може йтися про “подобу” до скраму, його імітацію, гібридну чи скрамоподібну модель, проте не Scrum.

Як було раніше

Отже, у 1980-х навчилися виробляти user-friendly товари з кнопочками, у 1990-х розплодилося розмаїття допоміжних професій, що дозволяло програмістам зосереджуватися на кодуванні. Однак розмаїта свита, що звідусіль оточувала розробників, а також складні багаторівневі структури організаційного менеджменту, стали серйозною проблемою у 2000-х.

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

Квест “Знайди винуватого”

Коли щось ішло не так, розпочинали квест “Знайди винуватого”. Першими були тестувальники, які швидко передавали естафетну паличку програмістам, які, зі свого боку, звинувачували бізнес-аналітиків, які розводили руками, бо керувалися даними, що їм підсунули ІТ продуктові менеджери, які не могли зрозуміти, які до них можуть бути претензії, бо на засіданні виконавчого комітету підрозділу імплементації інноваційних технологій було вирішено імплементувати рішення, згідно з яким і було проведено аналіз даних, вимоги до яких попередньо погодили на зборах вищого керівництва у відповідності до рішення стейкхолдерів…

Ціла когорта експертів та високоповажних осіб “мали очі, та не бачили, мали вуха, та не чули”. Дорослі люди з дипломами та регаліями передавали одне одному звинувачення, мов футболісти київського “Динамо” м’яч, залишаючись на своєму ж полі.

Дві особистості

Це набридло двом особистостям, чиї імена варто надовго закарбувати на дошці пошани — Кен Швабер і Джеф Сазерленд. Ці хлопці:

Розуміли специфіку розробки продукту.
Чули голос кінцевого споживача.
Розуміли сутність бізнесу та різницю між його старою та новою парадигмами.
Обожнювали оптимізацію процесів.
Розуміли нові вимоги часу, в якому опинився світ на початку третього тисячоліття.

Настала мить, коли вони зрозуміли сутність пекла, про яке писав колись Данте. Звинувачуючи одне одного, натовп причетних до розробки осіб спускався за спіраллю на дно, тягнучи за собою всю компанію!

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

Насправді Кена Швабера й Джефа Сазерленда цікавило не точкове вирішення технічної проблеми ще одного проекту. Вони прагнули винайти новий системний підхід, що:

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

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

Власник продукту

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

Часто власник продукту має значно ширші повноваження щодо продукту, аніж його безпосередній керівник. У Scrum-підході рішення власника продукту скасовувати чи модифікувати не можна. Це захищає команду від деструктивних втручань чи капризів керівників вищої ланки.

Окрім високої відповідальності, власник продукту — це місточок комунікації між усіма учасниками розробки, а також голос користувачів та замовників для кросфункціональної команди.

Унікальним чином одна особа (власник продукту) замінила суєтну діяльність близько двадцяти посадовців різного типу.

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

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

Формування рольової моделі

Геніальним рішенням запровадити роль власника продукту, Кен Швабер і Джеф Сазерленд одразу відчули різницю, а саме:

Спрощення процесів;
Економія часу;
Збереження енергії співробітників;
Підвищення зосередженості на меті, що покращило якість роботи;
Заощадження коштів.

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

Разом із власником продукту, було введено обов’язкову роль скрам-майстра (див. далі) та конкретизовано поняття “команда розробників”. Так рольову модель Scrum було сформовано остаточно.

Які виникають ризики і що з ними робити

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

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

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

Скрам-майстер

Цю роль виконує скрам-майстер. До його ролі також входять:

Допомагати команді оцінювати і прогнозувати;
Керування часом (time-box);
Самоорганізація та самокерування команди (скрам-майстер має “виростити” таку команду, допомагати їй стати “командою п’ятого рівня” — див. докладніше у статті “П’ять рівнів переходу на Agile: самокеровані команди”);
Забезпечення автономності (привести команду до рівня самостійності, ініціативності й відповідальності за відповідними критеріями й цінностями Scrum);
Трансформація культури;
Керування самим фреймворком Scrum;
Усунення перепон і перешкод на шляху команди (зазвичай втручання з боку керівників різного рівня, брак даних, потреба в додатковій експертизі тощо).