Ще якихось 10-15 років тому бізнес-аналізу як окремої професії не існувало, а формулювання вимог до продукту та пошук оптимального рішення були зоною відповідальності менеджера проєкту, розробників, QA-інженерів та, власне, самих замовників. Згодом програмні рішення значно ускладнилися і стало зрозумілим, що без «сполучної ланки» між клієнтом та командою розробки проєкт, найімовірніше, приречений на провал.
З того часу бізнес-аналітики (або ВА) складають воєдино фрагменти пазла з бізнес-потреб замовника, термінів виконання проєкту, технічних можливостей та обмежень, бюджету тощо. Водночас періодично відповідають на найпопулярніші питання: чи потрібно вміти кодити для старту в професії та чи обов’язково мати досвід в іншій галузі для розуміння специфіки певного бізнесу.
Але ми пропустимо ці запитання, а натомість пояснимо та проілюструємо буденними прикладами 10 термінів бізнес-аналізу, які має знати кожен початківець. Розібратися в темі допомагає Марія Басюк, Senior Business Analyst в EPAM.
- Requirement (або Вимога) — узагальнююче поняття для набору змін, що мають цінність для замовника проєкту та реалізація яких принесе йому певну вигоду. Вимоги бувають різних типів: від бізнес-вимог, зокрема, збільшення прибутку, кількості клієнтів тощо, до функціональних — додавання нових можливостей на сайт, зміна функціонала тощо.
- Stakeholder (або Зацікавлена особа) — будь-яка людина, яка має вплив на проєкт: замовник, що надає вимоги; розробник, який пише код; спонсор, який виділяє бюджет і ще чимало учасників процесу.
- Interview (або Інтерв’ю) — один з найбільш розповсюджених форматів спілкування бізнес-аналітика із замовником для з’ясування вимог. Бізнес-аналітик повинен ретельно готуватися до інтерв’ю для того, щоб якомога більше дізнатися про специфіку запиту та проблеми, які потрібно вирішити. Інтерв’ю — це ефективний інструмент під час спілкування сам на сам, але, залежно від досвіду інтерв’юера, може проводитися і для групи осіб.
- User story (або Користувацька історія) — задача, яка створюється бізнес-аналітиком для команди розробників. Така задача має відповідати певним критеріям: INVEST – independent, negotiable, valuable, estimable, small, testable.
- Verification vs Validation (Верифікація vs Валідація) — дуже подібні, але водночас докорінно різні поняття. Верифікація — це перевірка того, чи може конкретна вимога бути реалізована наявними інструментами. Тоді як валідація допомагає з’ясувати, чи відповідає реалізація вимог бізнес-інтересам замовника та чи допоможе вона досягти певних бізнес-цілей. Заплутано? Пояснимо на прикладі меблів. Припустимо, ми запланували зібрати книжкову поличку. Під час верифікації ми пересвідчуємося, що маємо достатньо дошок, цвяхів та вільного часу на це завдання. А валідація допоможе переконатися, чи дійсно нам потрібна саме поличка. Можливо, з урахуванням кількості книг, нам потрібно збирати цілу шафу.
- Backlog (або Беклог) — список, набір майбутніх (Product Backlog) або поточних задач (Sprint Backlog), над якими працює команда. Вони можуть бути різних типів — користувацькі історії, дефекти тощо. Бізнес-аналітики постійно працюють із беклогом, адже саме тут вимоги фіксуються в тому вигляді, в якому команда розробки бере їх в роботу.
- Domain Knowledge (або Знання галузі бізнесу) — це розуміння процесів, деталей тієї сфери, до якої належить ваш проєкт. Звісно, якщо ви добре орієнтуєтеся в індустрії краси, медицині або авіації, вам буде легше одразу зануритися в проєкт та почати ефективно працювати. Проте це не означає, що ви не зможете взятися за проєкт без попереднього досвіду в цій галузі. Вам просто потрібно буде дуже багато вчитися.
- Change request (або Запит на зміну вимог) — одна з поширених ситуацій, що виникає, коли команда вже взяла певну вимогу в роботу, але з боку замовника надійшов запит на її зміну. Варто пам’ятати, що має бути певний процес, погоджений із клієнтом перед початком проєкту. Згідно з цим процесом будь-яка зміна вимог на стадії розробки повинна пройти оцінювання як бізнес-аналітиком, так і командою. Це дає змогу визначити рівень складності реалізації зміни.
- Prototype (або Прототип) — це візуалізація рішення, яка дає змогу ще до початку етапу розробки отримати зворотний зв’язок від фокус-групи. Прототипи розробляють дизайнери у тісній співпраці з бізнес-аналітиками.
- Diagram (або Діаграма) — одна з форм фіксації вимог, оскільки певні складні процеси набагато легше зобразити візуально, ніж описати текстом. Тип діаграми залежить від того, що потрібно зобразити: структуру, процес, клас, послідовність тощо. Найбільш розповсюджена мова для моделювання діаграм — UML, або Unified Modeling Language.
Дізнавайтесь більше на навчальних програмах за напрямом Business Analysis та реєструйтесь на відкриті набори!