Кожен бізнес-аналітик хоча б раз стикався з клієнтами, які постійно приходять до команди із change requests — запитами на певні зміни у вимогах. Подекуди замовники ставляться до цього несерйозно. Можуть забувати про свої прохання чи взагалі згодом заперечувати їх. Щоб уникнути таких проблем, бізнес-аналітику варто комплексно підходити до процесу. А саме грамотно продумати обробку подібних запитів.
Бізнес-аналітики IT-команди NIX діляться власним чеклістом, щоб допомогти всім колегам.
1. Короткі нотатки за підсумками мітингів
Зазвичай їх називають «мітинг-хвилинками». Це ключові моменти, які ви обговорили із замовником та можете сходу переказати їх. Що мають містити такі нотатки:
- Дату та назву мітингу. Вони допоможуть зорієнтуватися в документації.
- Детальний зміст щодо зміни вимог. Інформація буде корисною для тих учасників команди, які не брали участь в обговоренні. Пропишіть у документі ключові слова, за якими пізніше зможете легко знайти його.
- Необхідність чейндж реквесту. Опишіть причини змін до вимог. Так команда чітко розумітиме, навіщо це робиться, а замовник за потреби зможе відновити деталі розмови.
- Терміни оцінки. Напишіть клієнту, що сhangelog з новим естімейтом ви надасте йому, як тільки надішлете всім цю «мітинг-хвилинку».
- Додаткову інформацію. Наприклад, документація, необхідна для внесення змін.
Радимо продублювати повідомлення у кілька каналів комунікації з клієнтом. Наприклад, ми у себе використовуємо Slack та email. Так ви знизите ймовірність того, що замовник не помітить або загубить повідомлення в одному з каналів.
2. Аналіз чейндж реквесту
Далі варто заглибитись у суть запиту. На що варто звернути увагу, досліджуючи change request:
- Зрозуміти об'єм необхідних змін.
- Розібрати, які плануються покращення у користувальницькому флоу.
- Розрахувати вплив цих змін на перебіг та результати проєкту.
- Визначити, хто з учасників команди працюватиме над змінами і чи потрібні додаткові фахівці.
3. Обговорення змін із командою
- Заплануйте мітинг
Іноді команди не хочуть обговорювати чейндж реквести на щоденних мітингах або вчитуватись у зміни в документації. Тому зручніше і швидше провести спільну зустріч, присвячену лише новому запиту.
- Поясніть колегам, що має змінитися і чому
Розкрийте всі деталі та опишіть передбачувані наслідки як у продукті, так і в процесі розробки.
- Підготуйте пропозиції
Вислухайте оцінки чейндж реквесту від команд. Обговоріть можливі сценарії реалізації або доопрацювання змін, які зроблять їх кращими. Потім поділіться ідеями з клієнтом.
- Донесіть запит на зміни до всіх стейкхолдерів
Кожна зацікавлена особа на проєкті повинна знати, що відбувається і чому, які наслідки від цих змін слід очікувати. Повідомте кожного про кроки, які плануються.
Зверніть увагу на останній пункт. Варто синхронізувати всіх учасників процесу для пошуку єдиного виваженого рішення. Одного разу в одному проєкті на боці замовника у нас був техлід, який не зважав на сторонні пропозиції. Він «різав» буквально всі ідеї щодо технічної імплементації. Це дуже позначалося на настрої та мотивації нашої команди. В результаті ми вирішили залучити до обговорень ще й інших стейкхолдерів. Нам вдавалося збирати багато різних точок зору і знаходили найкращий варіант реалізації чейндж реквесту. Тут головне — пояснити замовнику причину ескалації, тобто розширення кола учасників таких мітингів.
4. Оцінка запиту
Часто замовники просять вказати кінцеві терміни впровадження змін. Це зрозуміла річ. Однак у разі великої кількості чейндж реквестів можуть виникнути проблеми з естімейтом. Впорядкуйте процес наступним чином:
- Створіть канал для оцінки. Ми запускаємо його в Slack, де я в окремих повідомленнях описую конкретні зміни.
- Надайте вдосталь потрібної інформації. Доповнюйте повідомлення важливими для розробників даними, наприклад, посиланням на дизайн.
- Запитайте у команди про реальний естімейт. Попросіть колег якомога точніше оцінити кількість годин на виконання конкретного чейнджу.
- Якщо наразі складно дати оцінку естімейту, повідомте про це клієнта. Так може статися, скажімо, через необхідність застосувати ще незнайомі розробникам технології. Поясніть замовнику причини затримки з оцінкою робіт і обов'язків додайте: як тільки технічні фахівці глибше розберуться в темі, ви надасте точну оцінку.
- Просіть оцінювати навіть реалізовані зміни. Іноді ще до відправки чейнджлогу розробники можуть зробити невеликі зміни. Підготовка естімейту їм може здаватися нелогічною у такому випадку, але все одно це структурує інформацію і важливо для замовника.
- Фіксуйте прогрес втілення змін. Відмічайте чейндж реквести, які вже опрацьовані та реалізовані. Особисто я у Slack використовую для цього стікери. Вони допомагають зрозуміло сортувати документацію.
5. Створення тасків
Використовувати можете будь-яку зручну вам систему. Тут весь процес описується на прикладі Jira, з якою працює наша команда. Під кожен change request ми створюємо окремий таск. Що важливо пам'ятати:
- Вказуйте лейбл «change request». Так вам буде легше сортувати всі завдання на проєкті.
- Перелінкуйте таски. Завдання, які стосуються нових змін, потрібно пов'язати з вихідним таском функції, що обговорюється. Це зробить прозорим і зрозумілим процес впровадження змін.
- Додайте естімейт. Оцінка має бути вказана з термінами реалізації чейнджу.
- Проставте спринт. Позначте, в якому спринті команда візьме в роботу цю задачу. Клієнт повинен знати, коли конкретно розробники почнуть впроваджувати зміни. Самого лише естімейту недостатньо. Припустимо, задачу оцінено в три дні. Замовник може думати, що відлік часу починається сьогодні. На демо від нього ви можете почути щось на кшталт: «Я у вівторок сказав це виправити, а ви ще навіть не взялися». Тому раджу чітко позначити старт роботи і наголосити клієнту — він не буде миттєвим у цьому ж спринті.
6. Формування чейнджлогу
Цей документ дозволяє структурувати та зафіксувати всі обговорення та процес втілення змін. Щоб простіше працювати з журналом чейндж реквестів…
- Тримайте чейнджлог окремо. Ми в команді маємо спеціальну сторінку в Confluence в розділі Supplementary Documentation.
- Надсилайте журнал окремою гілкою. Для листів із чейнджлогами варто завести призначений лише для таких документів ланцюжок повідомлень.
- Відправляйте по кілька листів. Як правило, надсилаємо пачку мейлів наприкінці тижня, аби щодня не завантажувати клієнта повідомленнями.
Що має містити зразковий чейнджлог:
У заголовку варто вказати дату отримання запиту на зміни. Можна додати ще й назву мітингу, де ви обговорювали чейндж реквест (для зручності клієнта). У кожному чейнджлозі прописати порядковий номер і тип змін. Можете використовувати наступні варіації:
- Added — для запитів на нові фічі, що розширюють скоуп робіт.
- Changed (tech implementation) — для змін у технічній імплементації.
- Changed (requirements — Backlog features (BF)) — для чейндж реквестів, які ще не брали в роботу.
- Changed (requirements — Completed features (CF)) — для впроваджених змін або тих, що досі в роботі.
- Removed — для вилучених зі скоупу фічей.
Інші обов'язкові поля чейнджлогу включають:
- Change description — стислий опис змін для замовника.
- Initiator — автор запиту (пишемо ім'я клієнта).
- Reasons — причини внесення змін за словами їх ініціатора.
- Ensuing consequences — ключові результати аналізу запиту клієнта і подальших змін, які запустить цей чейндж.
- Effort consequences — перелік учасників команди, які будуть задіяні в роботі над чейндж реквестом.
- Timeline impact — естімейт від розробників.
- Jira / Confluence — посилання на документацію і таски, пов'язані з чейндж реквестом.
- References — посилання на «мітинг-хвилинки» з коментарями по датам і ключовим словам.
- Additional links — інша додаткова інформація (наприклад, посилання на дизайн чи оновлену архітектуру).
7. Оновлення документації
Фінальний етап обробки чейндж реквесту — зробити айдейт усієї документації за проєктом. Сюди входять:
- Вимоги
- Технічний дизайн
- Проєктні плани
- Тест-плани
- Навчальна документація
- Документація з бізнес-процесів
Як бачите, обробка змін до вимог є доволі об'ємною роботою. Однак ваші зусилля варті того, адже зроблять комунікацію з клієнтом прозорішою і менш стресовою. Особливо якщо, одразу отримавши новий запит, ви правильно налаштуєте процеси у команді. Спробуйте цей чекліст — і нехай вам все вдається!
