Коли з головою поринаєш у свої завдання, часом, не знаєш, що кожного дня робить колега за столом праворуч. Щоб виправити цю ситуацію, будемо розбиратися з професіями в IT. Із девелоперами і тестувальниками зрозуміло, вони продукт створюють. PM — спірний персонаж, але є майже в кожній команді, так що з якими питаннями до нього йти, всі вже розібралися.
А ось навіщо потрібна людина з модною професією Business Analyst (BA), ніхто чомусь не розуміє. Може здатися, що він цілий день пише документацію та забирає багато часу, обговорюючи якісь рішення з командою. Чим займається бізнес-аналітик, якщо вже є PM і технічний письменник?
Хто такий бізнес-аналітик — черговий прошарок менеджменту або кращий друг розробника? Пояснимо в цій статті.
ХТО ТАКИЙ БІЗНЕС-АНАЛІТИК
Бізнес-аналітик — це людина, яка стоїть між бізнесом і командою розробки. Він збирає і виявляє вимоги до майбутнього продукту або функцій системи, а потім перекладає їх на зрозумілу для інженерів мову.
Обов’язки BA в команді можуть варіюватися, але на всіх проєктах та у всіх вакансіях бізнес-аналітика вказані 4 основні функції.
- Управління вимогами: їх виявлення, підготовка і деталізація, поділ запитів на вимоги і «якісь не дуже важливі забаганки».
- Стратегічний аналіз: у багатьох компаніях BA разом з топ-менеджментом працює над стратегією розвитку компанії і проєкту, оскільки знає продукт найкраще.
- Проєктування рішень: підготовка документації та інколи створення прототипів. Усе, щоб придумати і донести до команди, яким чином рішення будуть розроблені та імплементовані.
- Управління продуктом: комунікація з дизайнерами, інженерами, стейкхолдерами, бізнесом і Product Owner-ами.
НАВІЩО ПОТРІБЕН БІЗНЕС-АНАЛІТИК
Уявіть ситуацію, замовник надсилає розробнику посилання на конкурентів і каже: «Мені потрібен сайт! Точнісінько, як ось цей!» Програміст: «Я не розумію, що значить “точнісінько”. Дайте ТЗ, менше доведеться переробляти».
Замовник йде до свого друга, за сумісництвом бізнес-аналітика, поскаржитися на програміста. Далі — діалог між замовником і бізнес-аналітиком.
Замовник: Ось ти мені скажи, ЩО ТУТ НЕЗРОЗУМІЛОГО? Взяти і зробити точно такий самий сайт, невже так складно повторити?
Бізнес-аналітик (сумним голосом): Ну, взагалі-то, я на боці програміста. Незрозуміло в твоєму запиті абсолютно все. Зараз доведу. Давай разом подивимося, що саме тобі подобається в цьому сайті. Тут є кнопка «Порівняти», вона тобі потрібна?
Замовник: Ні, не потрібна.
Бізнес-аналітик: У цих людей на сайті окрема сторінка для доставки і ще одна — для оплати, тобі точно потрібно дві верстати або можна доставку й оплату об’єднати в одну сторінку?
Замовник: Можна поєднати, мені й справді дві сторінки нічим заповнювати.
Бізнес-аналітик: Бачиш, вже виходить не один в один, правда?
Замовник: Я, напевно, мав на увазі швидше візуальне оформлення.
Бізнес-аналітик: А програміст говорив про функціонал.
Цей кейс показує, наскільки по-різному можна розглядати один і той же продукт (у цьому випадку сайт). Виходить, BA — та людина, яка може врятувати проєкт від «зробили, але не те». Тому залучати бізнес-аналітика краще до того, як команда зіткнеться з проблемами в комунікаціях із замовником.
Першим дзвіночком, що без BA не обійтися, можна вважати занадто поверхневі вимоги від замовника (як у прикладі вище). Трапляється й зворотна ситуація, коли команда начебто робить класні речі, але не може розповісти клієнтові, що саме розроблено, оскільки використовує занадто технічні терміни, які клієнт просто не розуміє.
Здається, мав би замовник технічний бекграунд, це могло б вирішити всі питання. А ось і не вгадали. Підковані в технічному плані замовники замість того, щоб сфокусуватися на складанні ТЗ, можуть почати розповідати команді, що і як робити, не володіючи достатньою експертністю у сфері. Або гірше того — починають писати код і відстоюють його імплементацію в проєкт. У цій ситуації BA виступає в ролі психолога: нагадує замовнику про те, що на нього працює команда професіоналів, і своїми діями він просто уповільнює процес розробки. Команду, в свою чергу, просить ставитися лояльніше до замовника і не надсилати йому посилання на Вікіпедію.
Є і третій тип проблем у комунікаціях — коли те, яким замовник бачить продукт, занадто відрізняється від того, що команда вважає оптимальним рішенням бізнес-потреби. Бізнес-аналітик у подібних ситуаціях виступає своєрідним рефері й об’єднує кращі пропозиції з двох варіантів, попутно аргументуючи зміни для обох сторін. Стривайте, але це більше схоже на роботу Project Manager-а, хіба ні?
В якомусь сенсі так і є. Не у всіх компаніях виділені окремі люди на обидві ролі, а з вимогами працювати потрібно в будь-якому випадку. Однак, у середніх і великих проєктах і у бізнес-аналітика, й у PM-а роботи вистачає на цілий день (ще й з овертаймами).
ОДИН ДЕНЬ БІЗНЕС-АНАЛІТИКА В IT
Давайте опишемо звичайний день, за який бізнес-аналітик встигає виконати всі свої базові функції. Звичайно, так проходять далеко не всі будні BA. Залежно від поточних завдань і стадії розвитку проєкту, змінюється кількість часу, робота бізнес-аналітика адаптується, але в ідеальному світі без палаючих дедлайнів розклад BA може виглядати наступним чином.
10:00 — 12:00 ДОПОМОГА КОМАНДІ
В окремих випадках комунікація з командою може займати мало не цілий день. В ідеальному розкладі за ці дві години BA відповідає на питання, коли щось незрозуміло і бере участь в обговоренні проблемних ситуацій.
Бувають випадки, коли в роботу беруть на перший погляд просту задачу, а під час виконання виявляється, що є технічні обмеження, і затверджене раніше рішення займе значно більше часу.
BA організовує мітинг, на якому пояснює команді початкову бізнес-потребу і питає, чи може команда запропонувати рішення, яке займатиме меншу кількість часу і ресурсів. Якщо оптимальне рішення знаходять, то бізнес-аналітик змінює вимоги. Ні — саме час «порадувати» клієнта новиною.
BA завжди повинен чітко розуміти, наскільки конкретна вимога важлива для клієнта, і чи потрібно додатково обговорювати із ним зміни. Спочатку краще питати все. Розуміння, в якій ситуації можна прийняти рішення самостійно, приходить із досвідом.
Що важливо при роботі з командами:
- Бути на зв’язку мало не 24/7.
- Фокусуватися на вирішенні проблеми: з’ясувати, в чому суть, перевести розмову в позитивно-конструктивне русло і запропонувати альтернативне рішення.
- Ескалувати проблеми вчасно: не намагатися все вирішити самостійно.
- Промовляти труднощі, з якими може стикнутися проєкт у разі змін. Вчасно повідомляти стейкхолдерів.
Важливо не зависати на комунікації з командою і навчитися розуміти, коли всі поточні питання вирішені і можна сконцентруватися на іншому завданні.
12:00 — 14:00 НАПИСАННЯ ДОКУМЕНТАЦІЇ
У документації є один мінус: якщо вона занадто велика, її ніхто не читає.
Що робить бізнес-аналітик на цьому етапі:
- Створює специфікації.
- Описує user stories/acceptance criteria/use cases.
- Формулює нефункціональні вимоги — описує умови, в яких система ефективна. Наприклад: «Система повинна бути відмовостійкою і сумісної з Google Chrome…».
- Моделює бізнес-процеси.
- Прототипує рішення.
Що важливо при написанні специфікацій:
- Заздалегідь визначити необхідні артефакти.
- Описувати вимоги ДОСИТЬ детально: ні більше, ні менше.
- Розуміти принципи usability.
- Дотримуватися нотацій у роботі з діаграмами.
14:00 — 15:00 ОБІД
Обід — це ідеальна можливість у неформальній атмосфері дізнатися про людей і поспілкуватися з командою, тому бажано не обідати на самоті.
15:00 — 18:00 КОМУНІКАЦІЯ З КЛІЄНТОМ
Робочі наради — це ті зустрічі, на яких можна не просто дізнатися про вимоги, але й докопатися до істинної потреби клієнта. Іншими словами, відповісти на питання «навіщо нам це потрібно?» і подумати, чи дійсно рішення оптимальне, чи є ще варіанти. Щоб спілкуватися із замовником однією мовою, потрібно розбиратися у предметній області бізнесу.
У ході таких інтерв’ю відбувається збір, виявлення й уточнення вимог, демонстрація документів, прототипів, моделей, діаграм, демо продукту або навіть готового рішення.
Важливо! Валідіруйте результати із замовником і обов’язково зберігайте «аппруви». Навіть скрін повідомлення в особистому листуванні вважається «аппрувом». Доступ до того ж Slack клієнта у будь-який момент можуть закрити, тому важливо, щоб ви зберігали «аппруви» у себе, поряд із вимогами.
18:00 — 19:00 КОНСУЛЬТАЦІЇ З ТЕХЛІДАМИ
Коли BA складає вимоги, він повинен розуміти всі суміжні технічні деталі. Навіть, якщо він уміє писати код, на проєкті за ним закріплені інші завдання, тому обов’язково потрібно радитися з тими, хто зайнятий розробкою: архітекторами, тім/техлідами й предметними фахівцями.
На таких консультаціях обговорюються високорівневі вимоги: яким чином їх краще спроєктувати, впровадити, декомпозувати тощо. Якщо в команді немає архітекторів, потрібно йти до розробників і радитися з ними. Прямий обов’язок BA — розуміти предметну область з усіх точок зору: не лише з боку бізнесу, а ще й з технічного.
ІЗ КОГО ВИХОДИТЬ ХОРОШИЙ BA
У бізнес-аналіз можна прийти як із бізнесу, так і з розробки. Сильні BA виходять із технічних письменників, оскільки вони розуміють, як саме формується хороша документація. З бізнесу в BA виростають менеджери, економісти і навіть спеціалісти з команди підтримки, оскільки вони розбираються у болях і потребах клієнта.
Роль BA в компанії можуть виконувати різні фахівці.
| Sales Manager | Спеціаліст із продажів — перший, хто починає виявляти вимоги і розуміти, що ж хоче клієнт. Досвідчені сейлзи прокачують необхідні навички BA, щоб грамотно зібрати першу інформацію про можливий продукт. |
| Account Manager | Аккаунт менеджер багато знає про продукт і побажання клієнта, так що може зорієнтувати замовника, куди розвиватися. |
| Product/ Project Manager | У межах роботи PM-ам доводиться доносити вимоги до команди і керувати ними, тому на більш-менш серйозному проєкті не обійтися без знань бізнес-аналізу. |
| Тімлід або найдосвідченіший розробник | Девелопер може виконувати роль BA, якщо замовник володіє хоча б якоюсь технічною компетенцією. Ця модель найчастіше зустрічається в аутсорсингу. |
| QA інженер | Тестувальник розуміє, що саме команда повинна розробляти. У ході тестування QA складає тест-кейси, і ці кейси — чи не єдина документація, за якою працює команда за відсутності BA. Це не найкраща практика, але, тим не менш, вона має місце бути. До речі, QA-фахівцям потрібно кілька місяців, щоб освоїти додаткові техніки, необхідні для BA, й піти в бізнес-аналітику. |
| UI/UX дизайнер | Дизайнери багато комунікують із клієнтами і працюють зі зворотним зв’язком. Вони можуть розповісти команді, що і як повинно працювати. Оскільки дизайнер не розбирається в розробці, роль BA на таких проєктах дизайнер ділить із командою. |
| Scrum master, Scrum team | Якщо команда працює по моделі Agile, ці фахівці можуть брати на себе роль BA. |
ЯК СТАТИ BA?
Якщо після прочитання статті вам здалося, що бізнес-аналіз може стати наступним етапом вашого кар’єрного росту — це хороша ідея. Навіть якщо після навчання ви передумаєте змінювати роботу, знання бізнес-аналізу істотно підвищать вашу цінність на ринку.
Щоб вирости в бізнес-аналітика, потрібно:
- Зрозуміти роль бізнес-аналітика у своїй компанії, адже завдання від проєкту до проєкту можуть сильно відрізнятися.
- Визначити свої поточні компетенції і порівняти з матрицею компетенцій BA. Іноді одна компетенція (наприклад, гарна англійська) може стати вирішальною.
- Виділити відсутні компетенції і пройти по ним навчання.
- Оволодіти основними техніками і методиками BA. Впроваджувати отримані техніки в роботі та відстежувати результати.
- Подати резюме на junior позицію із супровідним листом. Важливо написати, чому ви хочете працювати в цій компанії і чому вона повинна вас найняти: що ви для цього зробили, які курси пройшли і що вмієте. Не бійтеся разом із резюме подавати тестові проєкти, які робили в процесі навчання — вони стануть чудовим прикладом вашої першої роботи.
Комусь робочий день бізнес-аналітика здаватиметься нудним, хтось вирішить, що це — робота мрії (спокійніше, ніж у проєктних менеджерів, але, все одно багато комунікації і впливу на результат). У будь-якому разі, знання бізнес-аналізу з кожним днем стають все більш затребуваними на ринку, тому, якщо ви хочете розвиватися в IT, варто прокачатися в роботі з вимогами.
Чи можна стати бізнес-аналітиком без досвіду
Так, стати бізнес-аналітиком без досвіду можливо, і багато початківців починають кар’єру в цій галузі. Це не найлегша професія, але якщо ви хочете працювати в IT, не фокусуючись на програмуванні, бізнес-аналіз – вдале рішення. Однак для цього потрібно пройти кілька ключових етапів:
Освіта та курси
Почати можна з отримання знань в області бізнес-аналізу. Для цього підходять як спеціалізовані курси, так і програми в рамках університетської освіти. Важливо обрати програму, яка дає не тільки теоретичну базу, але і практичні навички роботи з інструментами бізнес-аналізу. Таким курсом є I AM BA від IAMPM. Ми спеціально його розробили для тих, хто хоче з нуля стати бізнес-аналітиком.
Розвиток ключових навичок
Бізнес-аналітик повинен бути знайомий з інструментами для аналізу даних, моделювання процесів і документування вимог. Це включає в себе:
- Знання SQL, Excel, BI-інструментів (наприклад, Power BI).
- Навички роботи з UML, BPMN, а також створення користувацьких історій і критеріїв прийняття.
- Розуміння процесів розробки та реалізації проєктів в Agile і Waterfall.
- Досвід роботи з інструментами для документування вимог (Jira, Confluence).
- Аналітичне мислення і здатність вирішувати проблеми.
- Навички спілкування із зацікавленими сторонами.
- Знання стандартів і методів аналізу ризиків.
- Досвід роботи з інструментами моделювання даних і процесів (Visio, Lucidchart).
- Знання в області фінансового аналізу та оцінки ефективності проектів.
- Знання статистичного аналізу та методів роботи з даними.
- Застосування методик оцінки продуктивності процесів.
- Досвід роботи з інструментами управління проектами (MS Project, Trello, Asana).
- Вміння працювати з API та інтеграціями.
Виглядає страшно? Але на курсі для бізнес-аналітиків I AM BA ми проходимо всі ці теми. Ви отримуєте повний набір навичок, щоб стати джуніор бізнес-аналітиком в IT. А при виборі пакету з гарантією працевлаштування ми знайдемо вам роботу або повернемо гроші за навчання.
Практика і портфоліо
Отримання практичного досвіду — це один з найважливіших етапів. Навіть якщо у вас немає досвіду в бізнес-аналізі, можна почати з роботи над реальними проєктами через стажування, проекти на фрілансі або навіть через практику в освітніх проєктах. Це дасть можливість вивчити реальні завдання і побачити, як теорія застосовується на практиці.
На нашому курсі для новачків з бізнес-аналізу ми даємо реальні проекти в портфоліо. Тому ви виходите не просто зі знаннями, а з впевненим практичним досвідом і готовим портфоліо, яке можна показувати на співбесідах.
Мережевий нетворкінг і пошук наставника
Важливо не тільки розвивати навички, але й будувати професійні зв’язки. Присутність на заходах для аналітиків, участь в онлайн-спільнотах і пошук наставника — це відмінні способи для того, щоб прискорити свою кар’єру в бізнес-аналізі.
Пошук роботи
Спочатку можна подавати заявки на молодші позиції (Junior Business Analyst) або в ролі стажера. Компанії часто готові брати новачків, якщо вони виявляють інтерес і готовність розвиватися, а також якщо у них є базові навички і прагнення вчитися.
Стати бізнес-аналітиком без досвіду можливо, якщо ви готові інвестувати час в навчання, розвивати практичні навички і шукати можливості для практики.
Часто задавані питання
Чи можна стати бізнес-аналітиком без досвіду?
Так, стати бізнес-аналітиком без досвіду можливо. Це вимагає проходження спеціалізованих курсів, розвитку ключових навичок і отримання практичного досвіду через стажування або невеликі проекти. Важливо показати готовність вчитися і розвиватися в цій галузі.
Як розвивати аналітичне мислення для бізнес-аналізу?
Аналітичне мислення розвивається через регулярну практику аналізу даних і рішень. Потрібно працювати з реальними кейсами, виявляти закономірності і шукати оптимальні рішення для різних проблем. Читання професійної літератури і участь в аналітичних проектах також допомагає поліпшити ці навички.
Як спілкуватися із зацікавленими сторонами для збору вимог?
Для ефективного збору вимог важливо ставити правильні питання, бути уважним до деталей і слухати всіх учасників. Потрібно вміти переформулювати вимоги, уточнювати їх і надавати рішення, які відповідають бізнес-цілям. Також корисно використовувати методи візуалізації та прототипування, щоб переконатися, що всі сторони правильно розуміють одна одну.
Чим відрізняється робота в Agile і Waterfall для бізнес-аналізу?
В Agile бізнес-аналітик працює з командою в умовах постійних змін і гнучкості, часто переглядаючи вимоги і пріоритети. У Waterfall процес більш структурований, вимоги фіксуються на початку проекту, і зміни відбуваються рідше. В обох випадках аналітик повинен бути готовий до різних підходів в управлінні проектом і взаємодії з командою.
Які кар’єрні перспективи у бізнес-аналітика в IT?
В IT бізнес-аналітики можуть розвиватися в різних напрямках, включаючи ролі старших аналітиків, керівників проектів, менеджерів по продуктах або навіть переходити в ролі в управлінні продуктами. Перспективи зростання залежать від досвіду і навичок, з можливістю поглиблення в більш технічні або стратегічні області, такі як Data Science або управління процесами.