7 викликів для бізнес-аналітика при виявленні вимог

Стаття написана у співавторстві з Мері Ротарь , Co-Founder IAMPM.

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

У мене економічна освіта. Коли стояв вибір між фінансами і економічною кібернетикою, я вибрала кібернетику. Після інституту мені запропонували попрацювати аналітиком-консультантом з впровадження 1С-систем. Пізніше працювала PM, потім знову повернулася в бізнес-аналіз. І ось в DataArt я вже три роки.

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

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

Перший виклик — виявити справжню бізнес-потреба

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

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

Наприклад, директор каже: «Хочу формувати звіт по цьому проекту у вигляді: співробітник/кількість витрачених годин». Бізнес-контекст цього запиту: «На проекті складнощі з оплатою від клієнта, він хоче розуміти, куди витрачається час». Відповідно і рішення може бути наступним: менеджер проекту сам формує цей звіт, вивантажує в Excel раз в тиждень і далі відправляє клієнту і директору. Співробітники, логірують час завдання, отримують нагадування залогировать його на наступний день/по п'ятницях. Це можна поширити на всі проекти.

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

Як з'ясувати справжню бізнес-потреба замовника

Для з'ясування істинних цілей бізнес-аналітику потрібно не просто слухати, а ставити запитання, наприклад:

Для чого цей функціонал потрібен в системі?
У чому конкретно рішення допоможе бізнесу?
Якої мети ви хочете досягти?
Чому потрібно автоматизувати даний процес?

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

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

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

Розповім показовий кейс про супершвидкому вирішенні проблеми клієнтської

На самому початку моєї кар'єри, коли я працювала консультантом в компанії, яка впроваджує 1С-продукти, знайомий рекрутер попросив розробити для нього систему на базі 1С. Exсel йому не вистачало: хотілося перейти на більш стандартизовану, складну і комплексну систему для обліку претендентів і замовників.

Головний запит — можливість розміщувати в системі максимально повну інформацію про кандидатів і легко знаходити потрібні дані. Він звучав абсолютно логічно, тому ми почали обговорювати деталі рішення, і в якийсь момент (каюсь, що не відразу) я подумала: «А чому ж замовнику не підходить Excel, адже це досить потужний інструмент?».

Далі у нас відбувся приблизно такий діалог:

Я: А що конкретно не влаштовує в Excel, чому вирішили перейти на 1С?

Рекрутер: В Excel зручно працювати зі списком претендентів, але коли потрібно відкрити окреме резюме, то файл доводиться шукати по всіх папок. Такий пошук незручний, займає багато часу, а в 1С процес буде простіше.

Я: У Excel є функція гіперпосилання в окремій колонці можна зробити посилання на місце розташування конкретних файлів. І тоді при натисненні на посилання відкривається одразу необхідне резюме.

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

Щоб задавати правильні питання, бізнес-аналітику знадобиться якісна попередня підготовка. Це наступний виклик: заздалегідь вивчити предметну область бізнесу замовника.

Другий виклик — знати бізнес-домен

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

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

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

Реально добре знати бізнес-домен до початку роботи на проекті

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

Знайомитися з первинними документами і оригінальними формулюваннями від замовника. До речі, тут допоможуть тікети і заявки на доопрацювання в техпідтримку.
Якщо можливо використовувати спостереження (ВАВОК навіть це виділяє як окрему техніку по виявленню вимог), то подивитися на сам процес роботи бізнес-підрозділів корисно для бізнес-аналітика.
Підписатися на періодичні видання по темі бізнесу.
Проходити внутрішні курси компанії: часто для бізнес-підрозділів проводять курси для новачків або для підвищення кваліфікації. IT-шники також можуть включитися.

Бізнес-аналітик буде почувати себе досить дискомфортно, поки не освоїться зі специфікою домену. А в дискомфорті люди схильні нападати або йти від спілкування. І тут з'являється наступний виклик — вибудовувати позитивну комунікацію, незалежно від власного настрою.

Третій виклик — будувати довірчі відносини

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

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

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

Як завоювати довіру клієнта

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

Налаштуватися на одну хвилю з замовником мені допомагає образ з «психологічного айкідо», про який говорить Ірина Хакамада:

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

Сенс в тому, щоб спочатку зрозуміти пріоритети, інтереси клієнта і вже потім перевести розмову в потрібне русло.

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

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

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

Ну і звичайно, пройшовши етап занурення в проект, БА починає добре орієнтуватися в бізнес-процесах, часто будучи knowledge holder'му — трохи чи не єдиною людиною, який з ходу може розповісти, «як це все працює». Коли бізнес-аналітик показує своє глибоке розуміння процесів, що добре знає розроблений продукт, ставить правильні питання, він привносить ту саму цінність, що зміцнює відносини між бізнесом і розробкою.

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

Четвертий виклик — вирішувати конфлікти у вимогах стейкхолдерів

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

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

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

У мене була така ситуація: замовнику для інтеграції з системою кастомера необхідно було заповнити маппінг майстер-даних довідників зі списками компаній, адресами та іншим. У нього цей список був один (коди, імена і так далі), а у його кастомера ті ж назви були написані по-іншому. Відповідно, треба було зберігати маппинги.

Спочатку було незрозуміло, кому доручити маппінг, тому що цим могли б зайнятися два відділи: обробки замовлень і контролю майстер-даних. Здавалося очевидним, що це робота для відділу контролю. Однак після розмови з'ясувалося, що вони займаються майстер-даними, глобальними для всіх систем корпорації. А от відділ обробки замовлень знає конкретного клієнта, його дані, тому простіше доручити їм «замапить» дані системи.

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

Як домовитися зі стейкхолдерами

Невирішений конфлікт може заблокувати роботу цілої групи стейкхолдерів

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

Можна спробувати альтернативний спосіб вирішення конфлікту:

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

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

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

П'ятий виклик — захистити систему від поганих рішень

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

Наприклад, замовник наполягає, що потрібна складна додаткова функціональність. Потім з'ясовується, що вона не критична і необхідна лише невеликій групі користувачів. Виклик для БА — делікатно, але твердо пояснити клієнту, що перекручувати всю систему, щоб одна група людей користувалася продуктом так, як вона це бачить, — це далеко не найкращий вихід.

Як погане рішення може виглядати в інтерфейсі.

На сторінці «Фінанси» кожен замовник захотів свій блок, і вийшов еклектичний інтерфейс, складний для розуміння. Сторінка переповнена інформацією, але в підсумку кожен блок потрібен тільки одному клієнту.

Як не пропустити невдале рішення

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

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

При виявленні поганих рішень аргументи БА можуть бути такими: «Наші бізнес-процеси стандартизовані і виглядають наступним чином. Давайте подумаємо, чому ви хочете саме таке рішення, з якої бізнес-потреби виходите? Можливо, ми знайдемо оптимальні способи виконати завдання без того, щоб ламати впроваджений у вирішенні бізнес-процес».

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

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

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

В результаті ми не зламали свої процеси та бізнес-потреба клієнта також була задоволена.

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

Шостий виклик — підтвердити домовленістю

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

Якщо БА ігнорує фіксацію і узгодження, то виникають кейси в стилі: «Хіба ми це не обговорювали?». Або на довгострокових проектах вже на етапі розробки з'являються фрази: «Не пам'ятаємо результатів, але ми це обговорювали і зробили, як здалося правильним». Особливо небезпечно не підтверджувати домовленості в аутсорсингу, тому що будь-які непорозуміння виливаються в додатковий бюджет або зрив дедлайну і призводять до серйозної розмови з замовником.

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

Як фіксувати домовленості

Для мене оптимально зберігати результати спілкування з замовником в примітках (meeting minutes) і відеодзвінки. А для збору зворотного зв'язку та підтвердження вимог зручно використовувати, наприклад, прототипи.

Замітки і запис відеодзвінків

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

Розробка прототипу

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

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

Сьомий виклик — пережити on-site переговори

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

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

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

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

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

Як відчути себе комфортно

Нерозуміння культурних особливостей може зіпсувати перше враження й ускладнити роботу з замовником

На on-site переговорах важливо відчувати себе зручно, впевнено, виявляти дружелюбність. Впевненість і доброзичливий настрій — це складові першого враження, яке БА справляє на людей. Для доброго самопочування на переговорах on-site важливі три речі:

Професійно налаштуватися на тему зустрічі: чітко уявляти питання і цілі обговорення, підготувати всі презентації. Це найважливіше.
Якщо це переговори з людьми іншої культури, краще заздалегідь пошукати інформацію про національні особливості або розпитати колег, які вже їздили в країну.
Дотримуватися дрес-код. Ще один важливий момент у переговорах on-site. Самим універсальним для переговорів вважається стиль smart casual. При цьому завдання БА — одягнутися так, щоб було зручно. Якщо ви зовсім не звикли носити піджак і відчуваєте себе некомфортно, це теж буде впливати на переговори.

Замість висновку

Якщо коротко, то справлятися з викликами при виявленні вимог мені допомагають кілька речей:

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

Опубліковано: 25/05/20 @ 10:00
Розділ Різне

SEO Блог