Як скласти Salesforce Business Analyst Certification. Корисні поради

💡 Усі статті, обговорення, новини для аналітиків — в одному місці. Приєднуйтесь до Analysts спільноти!

Привіт! Мене звати Ліна. Я працюю Salesforce Business Analyst в ІТ-компанії Customertimes, зараз — на проєкті у сфері страхування. Уже понад чотири роки я займаюсь бізнес-аналізом: збираю, оформлюю та документую вимоги, будую співпрацю зі стейкхолдерами й допомагаю покращувати процеси.

Близько шести місяців тому я отримала сертифікацію Salesforce Business Analyst. Я склала іспит з першої спроби та вирішила поділитись корисною інформацією з усіма, хто теж планує здобути цей сертифікат. Тож у цій статті я розкажу, які теми охоплює іспит та на що саме варто звернути увагу, аби впевнено його скласти.

Salesforce BA Certification: що це, навіщо і для кого

Це відносно нова сертифікація, що зʼявилась два роки тому. Ось як її описує Salesforce:

«Програма сертифікації Salesforce Certified Business Analyst створена для бізнес-аналітиків із досвідом роботи з Salesforce. Успішний кандидат розуміє бізнес-потреби, збирає вимоги та взаємодіє зі стейкхолдерами для підтримки розробки рішень Salesforce, що сприяють покращенню бізнесу».

То ця сертифікація більше про Salesforce чи про бізнес-аналіз? Я б сказала, що все ж більше про бізнес-аналіз. Так, є теми, повʼязані саме зі Salesforce, проте програма охоплює ключові компетенції бізнес-аналітика: взаємодія зі стейкхолдерами, процесне моделювання, написання user story, створення wireframe-ів, перевірка вимог і софт скіли, як-от вирішення проблем. Усі ці навички є базовими для будь-якого аналітика.

Я впевнена: якщо ви маєте досвід роботи бізнес-аналітиком, цей іспит для вас буде цілком посильним і навіть цікавим.

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

Про іспит Salesforce BA

Питання. Іспит складається з 60 питань. Більшість — це ситуаційні запитання з одним варіантом відповіді. Вам потрібно обрати лише 1 з 3 варіантів, на відміну від інших сертифікацій Salesforce, де часто треба вибирати 2 з 4 або 3 з 5. Це робить іспит простішим. Також, як і в інших сертифікаціях, тут є до 5 тестових питань, які не оцінюються.

Час. 105 хвилин — більш як достатньо!

Прохідний бал. Потрібно набрати 72%.

Сфери знань. Іспит охоплює шість основних тем:

• Customer Discovery — 17%
• Collaboration with Stakeholders — 23%
• Requirements — 18%
• User Stories — 18%
• Business Process Mapping — 12%
• Development Support and User Acceptance — 12%

Що ж, розгляньмо кожен із цих блоків докладніше.

Customer Discovery (17%)

Цей розділ оцінює, як ви здатні зрозуміти бізнес-контекст до того, як почнете працювати над рішенням. Він перевіряє ваші вміння правильно підійти до проєкту від самого початку — зіставляти цілі з бізнес-стратегією, аналізувати поточний («as-is») стан і бачити, де рішення Salesforce можуть принести користь.

Цей блок заслуговує особливої уваги, оскільки вимагає знань, специфічних для Salesforce. Я також хочу звернути увагу на деякі відмінності між класичними підходами бізнес-аналізу — зокрема, описаними в BABOK — і методами, які пропонує Salesforce у Trailhead.

1. Software Development Lifecycle

Традиційно цикл розробки складається з шести етапів: Planning, Analysis, Design, Implementation, Testing and Integration та Maintenance. Натомість Trailhead пропонує лише чотири етапи: Build, Deliver, Operate та Analyze.

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

• Analyze. BA проводить цей етап проєкту: збирає вимоги та отримує апрув від стейкхолдерів.
• Build. BA бере участь на цьому етапі, уточнюючи бізнес-вимоги та допомагаючи з UAT.
• Deliver. BA бере участь у вирішенні питань, пов’язаних з user stories, і контролює обсяг проєкту.
• Operate. BA бере участь у цьому етапі, перевіряючи фінальні результати з ключовими стейкхолдерами.

2. Інструменти аналізу в Salesforce

Як бізнес-аналітик, ви маєте вміти проаналізувати, як працює клієнт, щоб виявити проблемні зони та запропонувати покращення. Ось ключові інструменти Salesforce, з якими ви працюватимете:

• Health Check — корисний для огляду безпекових налаштувань в org, допомагає виявити та усунути вразливості.
• Salesforce Optimizer — чудовий інструмент для аналізу продуктивності системи, генерує рекомендації з покращення обслуговування, ефективності та рівня використання.
• Entity Relationship Diagram (ERD) — використовується для візуалізації об’єктів, полів і зв’язків. Часто демонструється стейкхолдерам, щоб пояснити бажану модель даних у Salesforce.
• Org Impact Analysis Report — допомагає зрозуміти, як зміни в метаданих можуть вплинути на інші налаштування в org. Дуже важливий для управління оновленнями та забезпечення стабільності.

Корисні поради:

1. Будьте готові до запитань, де потрібно буде визначити фазу проєкту та роль BA на цьому етапі.
2. Думайте як problem-solver. Від вас не вимагають запам’ятати екрани налаштувань Salesforce — натомість зосередьтеся на методах, які допоможуть зрозуміти справжні потреби клієнта.

Collaboration with Stakeholders (23%)

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

Цікавий момент у Trailhead порівняно з BABOK — це розділення групових технік на дві категорії: техніки збору вимог (Elicitation techniques) та техніки роботи зі стейкхолдерами (Stakeholder techniques). У класичних підходах усі вони об’єднані як elicitation techniques, а Salesforce акцентує на відмінностях — це важливо пам’ятати на іспиті.

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

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

Корисні поради:

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

Business process mapping (12%)

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

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

У Trailhead не згадують BPMN-діаграми (Business Process Model and Notation), які ми зазвичай використовуємо в бізнес-аналізі. Натомість у них представлено UPN — Universal Process Notation. Це простий для бізнесу спосіб моделювання процесів. Кожна діаграма UPN містить не більше 8–10 блоків діяльності (activity boxes). Кожен блок описує: що відбувається (завдання), хто відповідальний (користувач або система) та які системи залучені.

Що справді зручно в UPN — це можливість деталізації. Кожен блок можна розгорнути в підпроцес, якщо потрібно, — таким чином загальна картина залишається простою, але при цьому є змога заглибитися в деталі.

5 принципів UPN:

• Не більше 8–10 блоків діяльності на екрані
• Можливість деталізації — перехід від блоку до нижчого рівня
• Можна додати супровідну інформацію до кожного блоку
• Керування переглядом та редагуванням відповідно до прав доступу
• Контроль версій і журнал змін на рівні діаграми.

Корисні поради:

1. Очікуйте запитання, які перевіряють ваші вміння відрізняти поточний процес (AS-IS) від майбутнього (TO-BE).
2. Не забувайте про п’ять принципів UPN!

Requirements (18%)

Цей розділ присвячений тому, як ви збираєте, перевіряєте та документуєте вимоги. Важливо розуміти різницю між вимогами до скоупу проєкту (Scope requirements) і користувацькими історіями (User stories), а також відмінність між функціональними та нефункціональними вимогами — більшість запитань на іспиті стосується саме функціональних. Також потрібно знати основи методологій Scrum і Kanban — зокрема, як працювати зі стейкхолдерами, керувати беклогом і організовувати вимоги в межах кожного підходу. Окрім того, обовʼязково знати інструменти для відстеження вимог, зберігання документації та контролю версій.

Цікаво, що на Trailhead є розділ, присвячений Git і GitHub — технічним інструментам. Я готувалась до таких запитань, але так і не зіткнулась з жодним під час сертифікації. Утім, базове уявлення про них буде корисним.

Хотіла б зупинитись на відмінностях між вимогами (requirements) та користувацькими історіями (user stories) — це часто трапляється у запитаннях. Requirements описують потреби й обмеження проєкту, зазвичай вони неструктуровані та подані детально, технічною мовою. Натомість User stories — це короткі структуровані описи функціоналу з погляду кінцевого користувача, написані простою мовою для нетехнічної аудиторії.

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

Корисні поради:

1. На іспиті можуть бути запитання зі сценаріями, наприклад: Стейкхолдер дає нечіткі вимоги — що робити? Як вирішити конфлікт пріоритетів між бізнес-користувачами? Який метод збору вимог краще застосувати, якщо стейкхолдери мають розбіжності?
2. Прагніть бути чіткими, зрозумілими для інших та налаштованими на співпрацю. Вимоги мають бути повними, зрозумілими, узгодженими — і з контрольованими версіями.

User stories (18%)

Цей розділ охоплює кілька ключових тем: структура User stories, чекліст INVEST, як писати чіткі acceptance criteria, як правильно документувати історії, відстежувати зміни та розрізняти критерії приймання (acceptance criteria) та визначення готовності (definition of done).

У чому різниця між Acceptance criteria та Definition of done? Definition of done застосовується до всіх user stories та містить необхідні завдання, за якими команда може вважати інкремент продукту завершеним — з фокусом на якість. А от Acceptance criteria є унікальними для кожної історії. Вони складаються з набору тверджень, які можна перевірити на «так/ні», дозволяють протестувати функціональність, визначити, чи задоволено вимогу, та зосереджені на зручності використання.

Корисні поради:

1. Типові запитання тут: Чи є ця user story повною? Чи ці acceptance criteria можна протестувати? Чи зрозуміє розробник, що саме потрібно реалізувати?
2. Іспит перевіряє ваші вміння розпізнавати неповні або нечіткі історії — готуйтеся виявляти, яких acceptance criteria не вистачає.

Development support and user acceptance (12%)

Цей розділ про сапорт та валідацію результатів проєкту — чи відповідає рішення вимогам — та про підтримку під час UAT (User Acceptance Testing).

Особливо важливим тут є внесок бізнес-аналітика в процес UAT, зокрема його участь на кожному етапі та в ухваленні Go/No-Go рішень. Під час підготовки до іспиту мені здалося цікавим і новим саме поняття Go/No-Go, оскільки раніше я з ним не стикалась. Саме тому хочу звернути на нього вашу увагу.

Go/No-Go рішення — це процес затвердження або відхилення функціоналу перед його випуском у продакшн. Спочатку я думала, що таке рішення приймають виключно стейкхолдери. Однак у Trailhead зазначено, що Go/No-Go рішення приймає бізнес-аналітик разом зі стейкхолдерами. «Go» означає, що функціонал готовий до релізу, тоді як «No-Go» — що поки не готовий. У такому разі команда має ще раз переглянути результат, виправити помилки та внести необхідні покращення перед релізом.

Яку участь бере бізнес-аналітик у процесі UAT:

• Планування UAT та розробка тест-кейсів: Оскільки саме аналітик збирає та формує вимоги, він/вона найкраще розуміє, що саме потрібно перевірити під час тестування.
• Визначення тестувальників: Бізнес-аналітик взаємодіє з представниками різних департаментів, тож може залучити найбільш відповідних людей до тестування різного функціоналу.
• Виконання тест-кейсів: Це гарантує, що реалізоване рішення працює у живому середовищі й відповідає очікуванням користувачів.
• Узгодження результатів і фінальна зустріч: Аналітик разом із розробниками та власниками бізнесу переконується, що всі покращення відповідають цілям проєкту.

Корисні поради:

1. Основний момент — готовність до релізу. Ви допомагаєте переконатися, що рішення відповідає бізнес-потребам і не дасть збоїв на продакшині.
2. Можливе запитання: «Функціонал не проходить UAT — що потрібно зробити перед релізом?» Будьте готові запропонувати правильні наступні кроки.

Успішного SF BA іспиту!

Ми розглянули всі ключові теми іспиту для сертифікації Salesforce Business Analyst. Щоб підготовуватись було ще простіше, я додаю список корисних ресурсів — від офіційного гайду до навчальних модулів і практичних тестів. Бажаю вам успішної сертифікації!

• Офіційний гайд до іспиту
• Trailmix
• Модуль підготовки
• Додатковий гайд від Focus on Force
• Практичні тести для Business Analyst