Трансформація процесів доставки: виклики та можливості
В умовах, коли компанії активно переходять від локального програмного забезпечення до хмарних технологій, вони прагнуть підвищити свою “гнучкість”. Це прагнення часто поширюється на всі рівні взаємодії всередині та між організаціями, і бажано, щоб ці зміни відбувалися одночасно.
Трансформація процесів, принаймні теоретично, виглядає цілком досяжною. Можна запровадити scrum-церемонії та перерозподілити персонал на нові ролі, такі як scrum-майстри, власники продуктів, менеджери доставки та scrum-команди. Інструменти на зразок Jira, Azure ADO та Miro також можна зробити обов’язковими для використання. Однак, як щодо процесів, що поєднують ці інструменти? І як змінити менталітет, поведінку та підходи до роботи? Стає очевидним, що ці зміни не відбуваються миттєво та без проблем. Давайте розглянемо причини цього.
Що таке ініціатива з трансформації процесів доставки і чому компанії до неї вдаються?
Значна частина компаній досі працює за моделлю “водоспаду”. Це передбачає наступне:
- Спочатку розробляється детальний план кінцевого продукту, включно з орієнтовною вартістю.
- Далі відбувається збір вимог, де ретельно обговорюються, аналізуються та узгоджуються всі деталі продукту.
- Проводиться оцінка і затверджується остаточний бюджет.
- Розробляється проєктне рішення, включаючи численні зустрічі із зацікавленими сторонами, створення документації та її узгодження.
- На основі проєкту реалізується рішення.
- Проводиться тестування різними методами: модульне, системне, функціональне, інтеграційне, продуктивності, регресійне, приймальне тестування та інші. Результати тестування документуються та затверджуються зацікавленими сторонами.
- Рішення розгортається в робочому середовищі, де кінцеві користувачі починають його використовувати.
- Заплановано етап підтримки для усунення можливих помилок.
Весь процес може тривати від кількох місяців до кількох років. Користувачі бачать результат лише наприкінці. Отже, після тривалого очікування настає момент істини – успіху або невдачі.
Будь-які зміни, що виникають протягом цього часу, вимагають внесення змін у дизайн, його переробки та повторного затвердження, що значно подовжує терміни проєкту.
Зрозуміло, що такий підхід не є гнучким. Кожна зміна вимагає перезапуску всього процесу.
Перехід до Agile
Як же змінити ситуацію і досягти гнучкості? У моделі “водоспаду” люди звикли працювати роками, і їхні ролі та обов’язки є усталеними. Вони не бажають змін, бо це може призвести до втрати частини їхньої влади.
Саме тому такі зміни викликають сильний опір з боку персоналу.
#1. Реструктуризація команди
Першим і відносно простим кроком є реструктуризація персоналу в scrum-команди. Команди створюються за функціональними областями або іншими логічними принципами.
На початку процес розподілу проходить досить гладко. Проблеми починаються, коли стає зрозуміло, що люди все ще прив’язані до своїх старих структур. Навіть якщо вони є частиною нових scrum-команд, фактично вони продовжують працювати за старими правилами, оскільки мають незавершені обов’язки. Керівництво, зазвичай, більше стурбоване початком нових процесів, ніж завершенням старих.
В результаті scrum-команди не є повністю відданими scrum-командами. Вони являють собою групу людей, які мають ще більше роботи. Часу на командну роботу в scrum-командах виділяється менше, ніж очікує керівництво.
Від людей очікується виконання як старих завдань, так і нових ролей в scrum-командах. Така організація з самого початку приречена на невдачу.
#2. Планування scrum-церемоній
Наказ командам проводити регулярні зустрічі (спринт-церемонії) легко визначити та запровадити. Звичайно, якщо припустити, що ваші scrum-команди не складаються з людей, які працюють у різних часових поясах (а таке трапляється часто).
Проблема виникає тоді, коли люди не відвідують церемонії регулярно. Залежно від того, хто пропускає і як часто, це може призвести до різноманітних ускладнень. Наприклад:
- Якщо власники продуктів не беруть участі в плануванні, у команди не буде нових історій для роботи. Або ж описи історій будуть настільки неякісними, що команда не зможе почати їх опрацювання.
- Відсутність scrum-майстрів призводить до втрати координації команди та її можливого розгублення.
- Якщо розробники часто відсутні, вони не можуть синхронізуватися, що ускладнює спілкування всередині команди. Також, потрібні додаткові зустрічі для надолуження прогалин, що забирає ще більше часу.
Зрештою, люди не завжди винні у пропусках церемоній. Просто система не дає їм можливості брати в них участь (див. вище про паралельні обов’язки).
#3. Стабільність команди
Можна створити scrum-команду зі структурою та церемоніями, але якщо ця команда не є стабільною протягом тривалого часу (наприклад, мінімум півроку, а краще рік), вона не зможе розвиватися та вдосконалюватися.
Без стабільності ви не зможете створити незалежну scrum-команду, що ефективно працює у спринтах. Крім того, ви будете змушені постійно навчати нових людей, що виснажує ресурси.
Це часто недооцінюється керівництвом. Ставлення до команд як до “ресурсів”, які можна переміщати від кварталу до кварталу, є вірним шляхом до невдачі.
#4. Нові ролі для тих самих людей
Ще одна перешкода – це перепризначення існуючого персоналу на нові ролі. Люди, що раніше керували командами з абсолютною владою, тепер можуть стати, наприклад, власниками продукту. Хоч це і важлива роль, вона може сприйматися як нижча по відношенню до попередньої.
Власники продуктів повинні узгоджувати свої дії зі scrum-майстрами та менеджерами програм. Вони, як і раніше, відповідальні за зміст, але меншою мірою за процес доставки. Така ситуація вимагає відмови від деяких попередніх обов’язків, що є складним для сприйняття.
#5. Підходи до роботи
Часто можна почути, що для того, щоб залишатися актуальними на ринку, де гнучкість є головною вимогою, потрібно освоїти нові підходи до роботи. Але що насправді мається на увазі під цим?
На мою думку, керівництво має на увазі “досягнення (багато) більшого за менший час”. Після створення scrum-команд очікується, що кожен її член щодня демонструватиме значно більшу продуктивність. Якщо цього не відбувається, керівництво починає ставити під сумнів ефективність гнучкого процесу.
Керівництво очікує, що кожна година буде продуктивною, і що у scrum-команд не буде простою, оскільки всі процеси будуть налагоджені. Саме так лідерство визначає “нові підходи до роботи”.
Такі очікування не відповідають реальності. Ілюзорно сподіватися, що люди почнуть працювати більше лише через зміни в процесах. Звісно, деякі можуть збільшити свою продуктивність, але більшість не зможе. Навіть ті, хто готовий працювати більше, будуть перевантажені новими завданнями.
Різниця між ціллю та реальністю
Загалом, опис кінцевої мети є позитивним і логічним. Він базується на наступних принципах:
- Стабільні scrum-команди, що працюють над незалежними невиконаними завданнями, мають чіткі KPI та OKR.
- Власники продуктів розробляють надійні дорожні карти та планують пріоритетний контент для поставок у встановлені терміни.
- Наявність беклогу з детальним описом функцій.
- Надійні процеси тестування, що виконуються паралельно з розробкою.
- Регулярні релізи продукту (в ідеалі – після кожного завершення спринту).
- Відстеження ризиків, проблем та забезпечення комунікації між різними scrum-командами.
Однак, у реальності жоден із цих пунктів не є легким для досягнення.
- Формування scrum-команд, які постійно змінюються. Час, витрачений на навчання команди процесам scrum, виявляється марним, оскільки команди реорганізуються. Дорожні карти змінюються, переносяться або скасовуються.
- Власники продуктів не мають чіткого уявлення про деталі дорожніх карт, і, як наслідок, вони напряму призначають завдання командам, які не мають часу на розробку контенту, оскільки спочатку потрібно визначити, що саме розробляти.
- Тестування виконується лише вручну, що вимагає проходження численних етапів, затверджень та складних процесів. Тестування не встигає за розробкою.
- Релізи продукту постійно затримуються.
- Комунікація між різними scrum-командами є хаотичною та неефективною, оскільки кожна команда перевантажена завданнями. Власники продуктів, як правило, призначають команді занадто багато роботи на кожен спринт, через що вони постійно перебувають у стані стресу через дедлайни.
Виправлення помилок
На основі досвіду кількох проєктів адаптивної трансформації, я хочу підсумувати основні помилки та поділитися суб’єктивними думками щодо їх подолання.
#1. Правильний розподіл обов’язків
Будь-які спроби змінити та перерозподілити обов’язки, які не відповідають принципам scrum/agile, приведуть до провалу ініціативи.
- Власники продуктів повинні відповідати за контент і підтримувати беклог. Вони несуть відповідальність за невирішені питання, і якщо беклог не є чітким, вони повинні вжити заходів для виправлення ситуації. Проте, вони не повинні впливати на призначення людей до scrum-команд або на бюджет проєкту.
- Scrum-майстри не несуть відповідальності за контент беклогу. Вони відповідають за організацію церемоній та навчання команди принципам agile. Вони не повинні бути секретарями для власників продуктів, а навпаки, мають захищати команду розробників від власника продукту та зовнішніх зацікавлених сторін.
- Кожна scrum-команда повинна мати керівника доставки. Він об’єднує власника продукту, scrum-майстра і команду розробників, визначає процеси доставки, вирішує ризики, проблеми та конфлікти. Керівник доставки відповідальний за кадрові та бюджетні питання проєкту. Його головна мета — створити для команди середовище, де кожен може проявити себе найкраще.
- Команда розробників відповідає за розробку історій з беклогу. Вони можуть допомагати власнику продукту зі створення контенту (особливо технічного), але вони не є відповідальними за історії, що визначають дорожню карту.
#2. Стабільна команда
Інвестиції в agile-навчання команди є важливими та повинні бути швидким процесом. Регулярна зміна персоналу зводить нанівець всі зусилля.
Перші п’ять спринтів можна використовувати для навчання команди основним принципам scrum. Коли ці принципи стануть зрозумілими для всіх, можна розпочати безперервний процес вдосконалення scrum-команди. Але якщо люди в команді регулярно змінюються, ви будете змушені постійно проводити навчання.
Така команда навряд чи досягне повного потенціалу продуктивності, і керівництво буде дивуватися, чому раніше (до agile-трансформації) вона була ефективнішою.
Отже, сформуйте команду, інвестуйте у її навчання, і коли команда буде впевнена у нових процесах, просто дайте їй можливість розвиватися. Це і є шлях до досконалості.
#3. Матриця RACI
Рекомендується розробити та узгодити матрицю RACI (відповідальний, підзвітний, консультований, поінформований) між усіма командами перед початком роботи. Це допоможе уникнути багатьох непорозумінь.
Це особливо важливо на початкових етапах трансформації. Інакше люди будуть постійно запитувати, хто і що повинен робити, особливо в ситуаціях, які не були чітко обговорені.
Нижче наведено приклад матриці RACI для деяких обов’язків. Для вашого проєкту може бути інший набір. Головне – зафіксувати всі відповідні.
| Завдання | Ініціатор запиту | Керівник доставки | Власник продукту | Scrum-майстер | Команда розробників |
| Планування спринту | C/I | A | C/I | R | I/D |
| Поставка релізу | N/A | I | A/I | C/I | R |
| Огляд спринту | C/I | I | R | I | C/I |
| Ретроспектива спринту | I | I | A/I | R | I |
| Уточнення беклогу | I | A/I | R | C/I | I |
Висновок
Є ще багато чого сказати, оскільки існує безліч способів і моментів, де гнучка трансформація може піти не так. Метою цієї статті було підкреслити деякі проблеми, які трапляються найчастіше.
Сама по собі ініціатива є доброю ідеєю. Проте, вона може швидко перетворитися на кошмар для всіх учасників, якщо не дотримуватися основних правил. Я наголосив на деяких з них, але головне – керуватися здоровим глуздом, і все буде добре. 🙂
Далі ознайомтеся з навчальними ресурсами для сертифікації Agile.