«Клієнт може сказати, що він це не погоджував»: інструменти та поради, як бізнес-аналітику полегшити собі життя

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

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

Затвердження вимог — один із головних кроків в аналізі циклу розробки

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

У цій статті я обмежусь загальними поняттями, найголовнішим, що вам треба знати для роботи. Детальніше про затвердження вимог ви можете почитати у книзі — A Guide to the Business Analysis Body of Knowledge (див. «Управління життєвим циклом вимог»). Загалом же буду спиратися на матеріали з цієї книги.

Корисно затвердити вимоги на старті, адже це допоможе:

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

Існує два шляхи затвердження вимог

Адаптивний підхід

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

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

Тут хочу нагадати різницю між Validate і Verify. У першому випадку ви підтверджуєте, що вимоги відповідають намірам зацікавленої сторони. В другому — перевіряєте, чи можуть вимоги відповідати передбачуваній меті. Отримуєте письмове затвердження — і беретесь за розробку. Цей підхід добре корелює з Agile-методологією.

Прогнозований підхід

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

Який шлях краще обрати, вирішуйте на етапі планування проєкту.

Переходимо до практики

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

Переходимо до спілкування із замовником. Тут ваші основні кроки наступні.

1Визначити ролі стейкхолдерів

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

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

2Вирішувати конфлікти під час обговорення

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

Саме бізнес-аналітик має сприяти позитивному спілкуванню між стейкхолдерами у конфліктних ситуаціях. Ви маєте допомогти кожній групі стейкхолдерів з розумінням ставитися до різних думок і з повагою оцінювати потреби їхніх колег по проєкту.

3Досягти спільної згоди

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

4Стежити за затвердженням вимог

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

Інструменти затвердження вимог

Стратегія змін

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

Обсяг рішень

Затверджені вимоги не повинні виходити за визначені межі рішення.

Підхід до управління

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

Юридична/нормативна інформація

Описує законодавчі правила, яких слід дотримуватися: з ким і що затверджувати, в якому порядку, які документи оформлювати тощо.

Інструменти керування вимогами

Про них детальніше я розповім трохи згодом.

Техніки затвердження вимог

Щодо технік затвердження вимог, то ВАВОК виділяє наступні:

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

Кожна з цих технік заслуговує на окрему увагу, тому знову нагадаю вам про BABOK. Я описала основні моменти, аби ви зрозуміли тут принцип роботи бізнес-аналітика.

Отже, якщо попередні етапи успішно пройдені, беремось за втілення розробки. На руках у вас мають бути затверджені вимоги і дизайн, готові до використання командою розробників або в бізнес-аналізі. І найголовніше — ви маєте письмове підтвердження згоди від замовника.

Хто може затверджувати вимоги в проєкті?

• Замовник — він головний, він все розглядає і затверджує. Його слово — останнє.
• Експерти — фахівці з профільних питань можуть залучатись до перегляду і затвердження вимог.
• Користувачі — кінцеві юзери, звісно, не затверджують вимоги, але прямо чи опосередковано перевіряють та визначають пріоритети вимог.
• Операційна підтримка — саппорт відповідає за те, щоб вимоги та дизайн підтримувались у межах обмежень, які накладені, наприклад, технологічними стандартами або планами організаційних можливостей. Інколи ця команда також розглядає і затверджує вимоги.
• Проєктний менеджер — керує всім планом реалізації проєкту. Його робота стосується і перегляду, і затвердження вимог.
• Регулятори — зовнішня або внутрішня сторона, яка надає висновки, наприклад, щодо зв’язку між нормативними актами та вимогами до проєкту.
• Спонсори — ця сторона переглядає затвердження, оцінює бізнес-обґрунтування рішення, інколи навіть дає згоду щодо обсягу продукту.
• Тестувальники — переглядають вимоги і відстежують, що вони здійсненні.

Далі я розповім про інструменти, якими користуюсь сама, а також з практики моїх колег.

Інструменти для керування вимогами

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

Окремо слід згадати й різноманітні ПЗ для керування проєктом: Trello, ClickUp, Asana тощо. Тут я розгляну декілька найбільш зручних, на мій погляд, інструментів та способів затвердження вимог.

Confluence

У цій системі ми створюємо сторінку з описом вимог до кожної обговорюваної фічі. Клієнт може затверджувати окремі вимоги за допомогою коментаря Approved або ж надсилати таск на доопрацювання. В останньому випадку ми повторюємо процес.

У цього підходу є кілька переваг:

• Наочність. Клієнт безпосередньо на сторінці конкретної вимоги пише, що цей пункт затверджено.
• Економія часу. Вам не треба створювати окреме місце для відстеження затверджень.
• Проста комунікація. Можна обговорювати всі питання на сторінці фічі, тут дуже зручні інлайн-коментарі.
• Використання макросів. Так користувачам легше зорієнтуватися в системі. Наприклад, є зручний макрос «Підпис для підтвердження». В одному проєкті наша команда використовувала макроси Status та Page Properties. Ми створили окрему сторінку, куди виводили назву фічі (або сторінки) та статус готовності вимог до розробки.

Однак зважайте і на недоліки Confluence:

• Складності контролю. Багато уваги доведеться приділяти моніторингу затверджених вимог. Хоча з цим можуть допомогти, наприклад, вищезгадані макроси Status та Page Properties.
• Ризики неоднозначності. В Confluence немає шаблонів відповідей. Клієнт може писати коментарі як йому заманеться: «Ніби ОК», «Схоже на те» тощо. Тож треба попередньо обговорити з ним це, продумати зрозумілу, єдину систему формулювань для затвердження.
• Відсутність історії видалених коментарів. Якщо клієнт недоброчесний, забудькуватий або неуважний до процесів, це може стати проблемою.

Google Sheets

Мій улюблений інструмент. Робота з ним дуже проста: створюєте таблицю з посиланнями на вимоги для затвердження і додаєте у поле «Статус затвердження». Я ще включаю функціонал коментарів, що корисно і для мене, і для клієнта.

Аргументи «за» Google Sheets:

• Відстеження історії змін. Ви можете легко зрозуміти, хто редагував документ і коли. Це знімає питання, коли хтось забув про поставлений Approved або випадково чи намірено змінив вимоги.
• Уникнення неоднозначності. Коментарі стейкхолдерів можуть бути дуже різними за формулюванням. Наприклад, у Confluence замовники у мене інколи писали фрази типу «It’s OK», «looks good» або «I think yes maybe». Але ж це неоднозначно! Тому краще за все конкретне слово Approved. До того ж ви можете налаштувати дропдаун, де клієнт обиратиме готовий варіант відповіді. Так і бізнес-аналітик, і замовник легко контролюватимуть затверджені вимоги.
• Координація команди. Якщо на проєкті є кілька аналітиків, таблиці від Google спрощують спільну роботу. Я в цьому переконалася на власному досвіді. Ми з колегою відмічали, хто описує ту чи іншу фічу, ділили обсяг робіт, відстежували процес. При цьому ми були не єдиними на проєкті — крім нас були бізнес-аналітики з Індії та Ізраїлю. Завдяки цьому інструменту ми бачили, над якими фічами працює саме наша команда.

Але приготуйтесь чимало часу витратити на налаштування Google Sheets. Ви маєте створити таблиці, продумати їх структуру, підготувати дропдауни, надати різні рівні доступів стейкхолдерам та іншим учасникам команди. Однак зручність, яку ви отримаєте в результаті, цілком виправдовує ці зусилля.

Софт для управління проєктами

Програми для менеджменту проєктів дозволяють візуалізувати процеси і легко відстежувати статуси затвердження вимог. Такого софту дуже багато. Особисто я працювала з Trello, ClickUp, Asana та MeisterTask.

Усі ці програми об’єднує кілька позитивних рис:

• Легкий контроль. Достатньо лише переміщувати картки з назвами вимог між різними колонками: Waiting for review, Approved тощо. Також можна робити картки фіч, над якими ви працюєте. Так клієнт побачить, на якому етапі опису вимог ви знаходитесь.
• Відстеження історії змін карток. Усі бачать, хто заапрувив картку і поставив їй лейбу Approved, хто перетнув її між колонками. Корисно у роботі з кількома стейкхолдерами.
• Зручна комунікація. Це те ж саме, що й у випадку Confluence: команда може обговорювати певну фічу безпосередньо в однойменній картці. Хоча після цього треба додатково вносити зміни в самому Confluence.

Щодо недоліків:

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

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

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

Мітинги

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

• Ризики заперечення отриманої згоди

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

• Ускладнений контроль за дотриманням вимог

Якщо затверджуєте вимоги на мітингу, продумайте, як у подальшому відстежувати апруви. Тут стануть в пригоді Google Sheets. У коментарях можете так писати: «Ця вимога була затверджена під час мітингу такого-то числа». І тоді якщо вам знадобиться email з мітинг-хвилинками, ви будете знати потрібну для пошуку дату.

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

Як обрати кращий інструмент?

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

• Адаптація до уподобань клієнта. Деякі досвідчені замовники вже обрали для себе зручний інструмент, наприклад, Trello. Звісно, особисто вам він може бути некомфортним. Поцікавтесь, чому клієнт обрав саме цю платформу. Може, він просто не знає можливості інших систем, кращих? Тоді ви можете показати переваги різних інструментів і обрати зручний для вас обох.
• Визначення особистості клієнта. Всі замовники різні. Хтось одразу реагує на ваші звернення, а хтось рідко. У мене був проєкт, де клієнт дуже рідко перевіряв вимоги, які накопичувалися десятками. Тоді я вирішила створити таблицю в Google Sheets, де відстежувала забуті вимоги і нагадувати клієнту про них. Він також мав доступ до цього документу і бачив, які вимоги йому треба перевірити. Врешті процес швидше.
• Оцінка обсягу проєкту. Ніколи не ускладнюйте життя собі, команді, замовнику. Для невеликого проєкту має сенс брати простий інструмент. Не варто витрачати на тулзу більше часу, ніж триває сам проєкт.

Поради наостанок

• Визначте вимоги за пріоритетом. Це відмінно працює з Google Sheets і софтом для проджект-менеджменту. Наголосіть і замовнику: «Зверніть увагу, що у списку вимоги у порядку пріоритетності!». Тоді клієнт не буде обирати сам, що перевіряти. Адже дехто перевіряє вимоги, починаючи з найкоротшого, що не завжди ОК для команди.
• Намагайтесь отримати точну відповідь. Конкретне слово Approved, а не «Виглядає добре» чи «Щось на те схоже». Точність важлива не тільки з огляду на проблеми чесності. Це насамперед потрібно для порозуміння між вами і клієнтом. Він може подумати, що ви скинули лише половину, тому й написав OK, а насправді чекав ще чогось. Зазвичай я пишу прямо: «Подивіться на це і, якщо ви це погоджуєте, напишіть Approved». Так людина чітко розуміє, що я від неї очікую, і менше витрачає часу на роздуми, як оформити відповідь.
• Відстежуйте затверджені і незатверджені сторінки. Коли сторінок багато, ви й самі можете забути, що серед них найважливіше. Завдяки системі контролю ви убережетесь від помилок та заощадите час — свій і замовника.
• Використовуйте історію змін. Я неодноразово описувала цей функціонал, але повторю: звертайтеся до нього! Історія змін, наприклад, у Trello або Asana є вашим захисником на випадок навмисних або випадкових змін.
• Не затверджуйте вимоги в месенджерах. Немає значення чи то Telegram, чи Slack. Затвердження вимог повинно фіксуватись в окремих системах або листуванні на пошті. Вам все одно доведеться відстежувати процеси апруву. Тож після кожної зустрічі в месенджері ви надсилатимете на email мітинг-хвилинки та будете збирати письмові затвердження.

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