Процес управління змінами в IT-компанії, або Як побороти страх роботи з чендж реквестами

Усім привіт, мене звати Катерина Віжан, я бізнес-аналітик, маю 7 років досвіду в розробці програмних продуктів. У цій статті хочу поговорити про зміни та як до них адаптуватися.

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

Ось вам приклад: бренд мобільних телефонів Blackberry. Колишній улюблений багатьма смартфон, який мав понад 80 мільйонів користувачів у всьому світі, займав вже тільки 0,2% ринку у 2016 році. А все через відмову впровадити технологію сенсорного екрану та небажання підлаштуватися під потреби ринку.

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

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

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

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

Запит на зміну. Визначення

Для початку нам потрібно визначити, що таке «запит на зміну», щоб у всіх читачів було спільне розуміння теми статі. Запит на зміни або чендж реквест — це звернення щодо внесення змін до вимог або щодо змін інформації про продукт, які висуваються зацікавленими сторонами або командою проєкту після того, як визначена погоджена версія продукту (baseline). (The PMI Guide to Business Analysis).

Типи чендж реквестів:

• Зміни системної логіки/поведінки.
• Зміни скоупу.
• Зміни в назвах/формулюваннях.
• Зміни в інтерфейсі користувача.
• Технічні зміни (інтеграції, мови програмування тощо).

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

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

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

Причини чендж реквестів

• Зацікавлена ​​сторона передумала. (1)
• Рекомендації після перегляду частини або всього рішення. (2)
• Ризики. (3)
• Регуляторні зміни. (4)
• Погано визначені/пропущені вимоги. (5)
• Внутрішні або зовнішні обмеження. (6)
• Зміни в спонсорстві. (7)
• Зміна бізнес-стратегії. (8)
• Оновлена ​​технологія. (9)
• Недостатньо ресурсів. (10)
• Стихійне лихо. (11)

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

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

Крім того, ми купили вікна з німецького профілю. Вікна, які ми планували придбати спочатку, білоруського виробництва. І ця країна, замість того, щоб відправляти свої товари в Україну на експорт, тепер відправляє в Україну балістичні ракети «Іскандер» без жодних причин. Отже, це (4) — регуляторна зміна, оскільки Україна більше не закуповує продукцію в Білорусі.

Крім того, завод Knauf, виробник будматеріалів і конструкційних систем, був знищений російською армією, яка продовжує бомбити цивільну інфраструктуру, тому тепер потрібно шукати іншого виробника штукатурки (11 + 6). Це яскравий приклад того, як форс-мажори поєднуються із зовнішніми ризиками.

Адаптивні, предикативні та змішані проєкти

Працюючи із запитами на зміни, ми повинні враховувати такі критерії:

• Тип контракту.
• Бюджет.
• Комунікацію.
• Політику клієнта.
• Фазу проєкту.
• Архітектуру.

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

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

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

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

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

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

У реальному світі програмного забезпечення ми зазвичай працюємо над змішаними проєктами... Ми офіційно працюємо по контракту Time and Materials, але часто маємо деякі обмеження.

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

• не беріть запити на зміни у поточний спринт;
• не проводьте позапланових рефайнментів вимог;
• повідомте клієнта, що ефективність роботи команди впаде;
• виключайте заплановані завдання з поточного спринту, щоб взяти в роботу запит на зміни;
• зупиніть поточний спринт і почніть новий;
• перейдіть зі Scrum на Kanban, якщо зміни відбуваються часто.

Процес управління змінами

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

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

Процес управління змінами (Change Management Process)

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

Далі опишу детальніше кожен крок цього процесу.

Визначити чендж реквест (Identify CR)

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

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

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

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

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

Баг проти запиту на зміну:

1. Клієнти не платитимуть жодних додаткових грошей за баги відповідно до fixed price контрактів. Клієнт робить заявку, провайдер послуг її оцінює, підписується договір і узгоджується ціна. Ця ціна — це сума, яку клієнт збирається заплатити. Будь-які дефекти мають бути включені в контракт, що означає, що клієнт не платитиме за це додаткових грошей, тоді як запити на зміни будуть частиною нового контракту, і клієнт заплатить за них додатково. Це хороший аргумент, щоб розібратися в тому, про що питає клієнт: про фікс багу чи про нову фічу.
2. Постачальники можуть бути оштрафовані, якщо кількість помилок перевищує допустиму кількість, зазначену в угоді про рівень послуг (SLA). Це ще одна причина, щоб боротися за чендж реквести.
3. Незалежно від того, платить клієнт за нього чи ні, дефект завжди викликає сумнів щодо задоволення; якщо у клієнта складається враження, що робота виконана неналежним чином, він може вибрати іншого постачальника, що призведе до втрати каналу доходу.
4. Незадоволена девелопмент команда. Баг може свідчити про низьку якість виконання девелопером своєї роботи, тоді як чендж реквест не піддає сумніву вміння розробника.
5. Погана статистика у звітах про помилки.

Високорівнева оцінка запиту на зміни (High Level Elicitation)

Коли ми визначили, що реквест є запитом на зміну, нам потрібно визначити обсяг вимоги, щоб зробити високорівневу оцінку.

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

Нижче ключові речі, які потрібно взяти до уваги, виконуючи імпакт-аналіз:

1. Погоджену версію вимог (baseline).
2. Конфлікт: чи суперечить запропонована зміна іншим вимогам.
3. Вигоду: що ми отримаємо після імплементації зміни.
4. Вартість: загальна вартість впровадження змін, включаючи вартість внесення змін, вартість пов’язаної переробки та альтернативні витрати (кількість інших функцій, якими, можливо, доведеться пожертвувати або відкласти, якщо зміну буде схвалено).
5. Вплив: кількість клієнтів або бізнес-процесів, на які впливає зміна.
6. Графік: вплив на існуючі зобов’язання щодо доставки, якщо зміну буде схвалено.
7. Терміновість: рівень важливості, включаючи фактори, які викликають необхідність, такі як регуляторні питання безпеки.

Оцінка впливу (Analyze Impact)

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

Запланувати сесію з оцінки (Schedule Estimation Session)

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

Оцінити (Estimate)

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

Презентувати результати оцінки (Present Estimation Results)

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

Погодити (Approve)

Необхідно отримати згоду від клієнта, щоб взяти чендж реквест в роботу:

1. Відхилені чендж реквести мають бути переведені у відповідний статус, визначений на проєкті (наприклад: Відхилений (Rejected), не актуальний (Obsolete) тощо).
2. Схвалені, але відкладені запити на зміни повинні бути пріоритезовані у відповідний реліз/ ітерацію або поміщені в беклог.
3. Схвалені для поточного релізу/ ітерації підлягають обробці.

Оновити план та презентувати клієнту (Update Timelines/Present to client)

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

Підтвердити нові строки/ запропонувати компроміси (Confirm Timelines/Offer Tradeoffs)

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

Задокументувати зміни у вимогах (Document Requirements Changes)

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

Задокументувати зміни скоупу та витрат (Document Scope/Effort Changes)

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

Оновити журнал змін (Update Change Log)

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

Опрацювати вимоги (Process Requirements)

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

Інструменти та техніка

І ось найцікавіше: як ми документуємо всю отриману інформацію. Далі ви знайдете приклади підходів документування, які я пропоную. Ці підходи проілюструю на прикладі використання Jira як інструменту для управління вимогами.

Документувати нам потрібно наступне: Зміни у вимогах (Requirements Changes) та Зміни скоупу (Scope/ Effort Changes). Далі розбираймося, як задокументувати кожний тип змін.

1. Зміни у вимогах (Requirements Changes) (див. «Задокументувати зміни у вимогах»)

1.1. Версіонування вимог

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

1.2. Додатковий тип вимог

Створіть кастомний тип вимог (issue type) в Jira, щоб легко відслідкувати оригінальну вимогу і зміну до неї.

1.3. [CR] в назві вимоги

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

1.4. Спеціальний «Archived» статус вимоги

Попередня версія вимоги стає неактуальною після реалізації новішої версії, яка включає чендж реквест. Для легшої навігації актуальними вимогами можна користуватися додатковими статусами для вимог в Jira. Або замість статусу використовувати «Actual Version» лейбл. Це дві взаємозамінні техніки, тому обирайте ту, що вам ближча.

1.5. Лейбл «Actual Version» як додатковий атрибут вимоги

1.6. Лінкування пов’язаних вимог

Нативний інструмент Jira дуже легкий у використанні та допомагає знаходити зв’язки між вимогами. Лінкуйте всі айтеми, які можуть впливати

на поточну вимогу або які можуть бути заафекчині самою вимогою.

Ось, тут можна не обмежуватись одним підходом. Необхідно вибрати ті, які доповнюють один одного, щоб досягти кінцевої цілі.

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

2. Зміни скоупу (Scope/ Effort Changes) (див. «Задокументувати зміни скоупу та витрат)

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

2.1. Додатковий тип вимог

2.2. [CR] в назві вимоги

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

2.3. [CR] лейбл

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

Сподіваюсь, що термін «чендж реквест» більше не викликає у вас нервове посмикування лівого ока. Обговорюймо разом!

P.S: так і не змогла відмовитись від використання у статті англіцизмів. Здається, що без них текст стає відірваним від реального процесу роботи бізнес-аналітика зі змінами. Якщо, все ж таки, у вас повне відторгнення англійських термінів в українській транскрипції, тоді пропоную вам познайомитись з версією моєї статті англійською мовою.