Русский военный корабль, иди нах*й.
Пожертвувати на армію
×
Упс! Не вдала спроба:(
Будь ласка, спробуйте ще раз.

Що таке change requests та як з ними працювати. Чекліст для бізнес-аналітиків

IT-команда NIX
IT-команда NIX
10 листопада 2022 9 хвилин читання

Кожен бізнес-аналітик хоча б раз стикався з клієнтами, які постійно приходять до команди із 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. Оновлення документації

Фінальний етап обробки чейндж реквесту — зробити айдейт усієї документації за проєктом. Сюди входять:

  • Вимоги
  • Технічний дизайн
  • Проєктні плани
  • Тест-плани
  • Навчальна документація
  • Документація з бізнес-процесів

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

Якщо ви хочете поділитися з читачами SPEKA власним досвідом, розповісти свою історію чи опублікувати колонку на важливу для вас тему, долучайтеся. Відтепер ви можете зареєструватися на сайті SPEKA і самостійно опублікувати свій пост.
50 UAH 150 UAH 500 UAH 1000 UAH 3000 UAH 5000 UAH
0
Прокоментувати
Інші матеріали

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

Владислав Миронович 19 годин тому

Чому під час війни і атак по енергетичній інфраструктурі варто використовувати електронні документи

Владислав Миронович 2 грудня 2022 18:00

Як Україні втримувати таланти в умовах війни та після перемоги

Юлія Лапко 2 грудня 2022 16:00

План безперервності бізнесу: ключові поради, як досягти стійкості

GlobalLogic Ukraine 2 грудня 2022 13:30

Корисні сервіси, які спростять життя українським експортерам

Володимир Жиляєв 1 грудня 2022 16:00