Відповідаю на 11 популярних питань бізнес-аналітиків-початківців. Я - Денис Гобов, бізнес-аналітик з досвідом роботи 20+ років в ІТ-компаніях. Останні 10 років окрім роботи в проєктах я активно займаюсь навчанням бізнес-аналітиків всіх рівнів, починаючи з початківців і закінчуючи Senior BA/Product Owner. В цій статті я зібрав найпопулярніші питання, які бізнес-аналітики-початківці ставлять мені і моїм колегам. Сподіваюся, відповіді будуть корисні всім, хто тільки збирається стати бізнес-аналітиком в ІТ, незалежно від поточного місця роботи та посади. Як стають бізнес-аналітиками в IT: моя історія
Сьогодні ІТ індустрія є "магнітом" для багатьох. Але напрямок безпосередньо програмування підходить не для всіх. Тоді починають розглядати можливі варіанти: тестувальник, керівник проекту, аналітик. Я, навпаки, спочатку був розробником, а згодом став бізнес-аналітиком. Це також досить поширений професійний шлях.
На початку двохтисячних, ще в інституті, я потрапив до великого проекту — ми розробляли для «Укрзалізниці» систему, яка автоматизувала управління пасажирськими перевезеннями (бронювання та купівля квитків, складання розкладу, ведення інформації про вільні місця тощо). У проекті всі були рівними, кожен трохи спілкувався з клієнтом, писав код і тестував. Там, де завдання були відносно простими, схема працювала, але на одній складній підсистемі цей підхід дав збій. Замовник не прийняв наш перший реліз, потім другий.
Причина в тому, що ми недостатньо глибоко розібралися в бізнес-процесах замовника, не до кінця розуміли поточний і бажаний стан. Відповідно, код не міг бути правильним, скільки релізів не випускай. Так, у компанії з'явився запит на нову позицію.
Замість безпосередньо програмування більшість часу у проекті я став приділяти спілкуванню з клієнтом, документуванню його потреб, продумуванню варіантів , які ці потреби можна задовільнити. І зрозумів, що мені більше подобається не писати код, а розумітися, що потрібно клієнту і як це краще зробити. Хто ж такий бізнес-аналітик?
Це людина, яка спочатку визначає, де знаходиться бізнес клієнта і де він має бути (куди ми йдемо?). Потім разом із замовником та командою прописує "маршрут", щоб із мінімальними витратами принести максимальну користь бізнесу. Це якщо коротко.
Бізнес-аналітик потрібний на всіх трьох етапах проекту.
1. Передпроектний аналіз (Discovery phase). Займає, як правило, 2-6 тижнів. Завдання аналітика – дослідити поточний стан бізнесу, його потреби та визначити межі рішення: що робимо, а що робити не будемо. Це верхньорівневий аналіз. Якщо, скажімо, клієнт впроваджує ERP — аналітик визначає, які модулі потрібні, з чим інтегруємося, які будуть типи користувачів.
Головна складність на цьому етапі – сформувати єдине бачення для замовника та розробника: куди йдемо, що робимо та що не робимо.
2. Аналіз у межах проекту. Може тривати півроку, рік та більше. Бізнес-аналітик працює з детальними вимогами: виявляє, описує, моделює та погоджує. Управляє запитами на зміни, якщо у процесі з'явилися нові бізнес-завдання, змінились закону, що регулюють діяльність клієнта, з'явилися чи змінилися побажання зацікавлених осіб.
3. Постпроектний аналіз. Після релізу аналітик оцінює, наскільки рішення відповідає початковому баченню, що заважає приносити заявлену цінність, які вдосконалення можна/треба зробити. Оновлює базу знань з продукту, якщо планується подальший супровід/розвиток системи або це передбачено контрактом. З ким працює бізнес-аналітик?
Іноді кажуть, що бізнес-аналітик – перекладач між бізнесом та IT. Я вважаю, що це скоріш людина, яка організовує спільну роботу. Це рівноправний учасник "круглого столу", за яким сидять розробники, тестувальники, менеджери проекту, замовник, його постачальники та клієнти, регулятор в особі відділу контролю якості, держави та міжнародних організацій. Ось фактично з ними так чи інакше працює бізнес-аналітик. Чим відрізняється бізнес-аналітик в ІТ від інших бізнес-аналітиків?
З висоти пташиного польоту всі бізнес-аналітики роблять те саме. Вони вивчають роботу організації замовника та пропонують способи досягнення бізнес-цілей. Це можна зробити різними способами, наприклад за допомогою перерозподілу обов'язків у колективі, зміни бізнес-процесів, винесення якихось робіт на аутсорс. Тобто не обов'язково потрібно розробляти нове програмне забезпечення (ПЗ).
Відмінність бізнес-аналітика в IT полягає в тому, що його головний інструмент для досягнення цілей — саме програмне забезпечення. У його проекті основною задачею є розробка нового, доопрацювання існуючого чи впровадження готового (з "коробки") ПЗ. Який вигляд має робочий день бізнес-аналітика?
Основна частина робочого часу йде на спілкування з командою, щоб донести вимоги замовника, проговорити варіанти реалізації, відповісти на існуючі та зібрати нові питання. По-друге, спілкування із клієнтом: виявлення вимог, фіксація домовленостей, визначення пріоритетів. По-третє, "паперова" робота: підготовка документів з описом, або аналіз існуючих документів, що є джерелами вимог. Які компетенції потрібні бізнес-аналітику? Ось що відрізняє гарного бізнес-аналітики.
Широкий кругозір. Знання предметних областей, специфіки різних видів діяльності дозволяє швидше зануритися в проект та говорити з клієнтом однією мовою. Плюс потрібно пам'ятати патерни вирішення завдань, які можна перевикористовувати в проектах.
Розвинені комунікативні навички. Якщо вам важко спілкуватися з людьми та доносити інформацію у зрозумілому вигляді, можливо, ця робота не для вас. Існує, щоправда, класифікація, згідно з якою є бізнес-аналітики та системні аналітики. Вважається, що перші більше спілкуються з людьми, а другі працюють із документами, і їм можна бути нелюдними інтровертами. Насправді такий поділ зустрічається рідко. Принаймні у великих аутсорс-компаніях бізнес-аналітик і системний аналітик зазвичай одна й та сама особа.
Аналітичне мислення. Насправді це означає, що аналітик вміє генерувати різні варіанти вирішення завдання.
Розвинена емпатія. Вміння подивитися на проблему з різних точок зору. Зрозуміти, що відчувають замовник та кінцевий користувач. Подивитися на постановку завдання очима команди: розробників, тестувальників. Це допомагає відразу врахувати багато потенційних складнощів, запитань і побажань.
На сайті Art of Business Analysis ми зібрали розширений перелік базових компетенцій бізнес-аналітика. Це те, що потрібно розвивати. Що є результатом роботи бізнес-аналітика? Головний результат - зниження невизначеності у замовника та команди: з'являється розуміння, куди і як рухатися.
У більш приземленому плані результат — документи: перелік функціональних та нефункціональних вимог, історії користувача, моделі — вони стають основою беклогу (впорядкованого переліку завдань для команди). Команда розуміє що і в якому порядку необхідно зробити. бачить, що в порядку робити. І замовник може підтвердити: "Так, це саме те, що я хочу".
Ще один результат - база знань, яка потрібна, щоб розуміти, на основі яких вимог система була побудована. Вона стане в нагоді для супроводу системи та перевикористання в інших проектах. Які рівні-грейди у бізнес-аналітиків? Кожна компанія має свою класифікацію. Розповім, як ми в DataArt визначаємо джуна, мідла, синьйора та експерта.
Джун може приносити користь, але не є самостійною бойовою одиницею. Йому можна доручити, наприклад, задокументувати результати зустрічі і перетворити їх на вимоги за шаблоном.
Мідл вирішує стандартні завдання у рамках типових проектів. Він працює самостійно, йому не потрібна підтримка.
Синьйор вирішує складні нестандартні завдання, для яких немає шаблонів. Часто синьйор виступає ментором для мідлів та джунів.
Основна цінність експерта – у навчанні інших бізнес-аналітиків. Він має величезний досвід, він підкаже, який інструмент для цього завдання працює краще, які підходи до побудови рішення застосувати оптимальніше, з якими потенційними завданнями/проблемами проект може зіткнутися в майбутньому. Які точки входу до професії? Якщо ви вже працюєте в IT (дизайнер, розробник, тестувальник тощо), можна спробувати такі варіанти:
Програми внутрішньої перепідготовки. У великих компаніях найчастіше такі програми є.
Поєднання ролей. Можна працювати, умовно, тестувальником і допомагати бізнес-аналітику на своєму проекті. Зазвичай це рутина на кшталт документування вимог по шаблону, підготовки протоколів за результатами обговорень.
Коли наблизитесь до рівня джуна, беріть участь у внутрішніх ініціативах з розробки або покращення систем, що використовуються вашою компанією. Часто такі ініціативи вигадують, щоб джуни мали можливість попрактикуватися, перш ніж їм довірять клієнтські завдання. Як правило, це відбувається у неробочий час і не завжди оплачується. Натомість напрацьовується досвід та репутація.
Якщо працюєте не в IT:
Трейні-програми. Великі компанії проводять набір до своїх шкіл. Це відбувається нерегулярно, тому слід стежити за анонсами. Туди непросто потрапити, але я наполегливо рекомендую спробувати. Перше, що запитають у такій школі — наскільки хороша ваша англійська. Ще перевірять, наскільки серйозними є ваші наміри і чи вмієте ви зрозуміло висловлювати свої думки. Щоб закрити всі пункти, в DataArt, наприклад, просять написати есе англійською про себе та свою мотивацію. Найкращих випускників компанії беруть на практику, на позицію трейні чи джуна.
Участь у стартапах, навчальних проектах. Напевно, у вас є знайомі, які створюють інтернет-магазин або мобільний додаток. Думаю, вони готові користуватися вашими послугами безкоштовно. Такого досвіду буде достатньо, щоб на базовому рівні розібратися, що від бізнес-аналітика чекає замовник та команда.
Робота з Ментором. Шукати ментора можна у своїй компанії, у тематичних чатах у Telegram та Facebook, через знайомих — будь-де. Варто заздалегідь визначитися, що ви хочете прокачати з ментором і придумати, що можете дати натомість. Ментор відповідатиме на запитання, радитиме літературу, даватиме завдання та перевірятиме їх.
Про що запитують на співбесідах?
Окрім перерахованих вище софт-скіллів майбутніх колег цікавлять ваші хард-скіли та технічні знання.
1. Виявлення вимог. Ви знаєте техніки, які для цього використовуються та вмієте їх застосовувати: інтерв'ю, аналіз документів, мозковий штурм тощо.
2. Специфікація та моделювання вимог. Ви вмієте інформацію щодо проекту викласти у структурованому вигляді або змоделювати.
3. Управління змінами. Ви знаєте, за яким циклом проходить запит на зміну, які запитання потрібно ставити замовнику.
4. Пріоритизація. Ви вмієте визначати порядок виконання задач та можете обґрунтовувати своє рішення.
5. Прототипування. Ви можете прототипувати візуальні елементи майбутнього рішення, наприклад, за допомогою Balsamiq, Axure або Figma.
6. Декомпозиція. Ви знаєте, як розбити складне завдання на декілька підзавдань.
7. Методологія. Ви розумієте принципи Agile, її відмінності від каскадної моделі та знаєте, як будується робота бізнес-аналітика залежно від методології.
Які саме технічні знання перевіряють на співбесідах — дискусійне питання. Найчастіше запитають про SQL, т. е. досвід написання запитів до баз даних. Точно потрібно знати принципи, за якими будуються програмні продукти. Добре розуміти принципи об'єктно-орієнтованого програмування та роботи з API.
Що читати і дивитися бізнес-аналітику-початківцю? Книги. Якщо ви погуглите це питання, вам обов'язково потрапить на очі BABOK (Business Analysis Body of Knowledge). Це звід знань від Міжнародного інституту бізнес-аналізу (IIBA) — найавторитетнішої асоціації у нашій сфері. Однак я BABOK на початковому етапі не рекомендую, незважаючи на те, що я євангеліст цієї книги і проводжу тренінги на її основі. По-перше, вона величезна. По-друге, побудована як довідник і, якщо почати з неї, у голові утворюється каша. Приступайте до цієї книги, коли напрацюєте практичний досвід — тоді краще зрозумієте, що там написано. Замість BABOK раджу шість книг. 1. Handbook for CPRE Foundation Level від IREB. Дозволить зрозуміти термінологією бізнес-аналізу та інженерії вимог. Розповсюджується безкоштовно в електронному вигляді.
2. Карл Вігерс "Розробка вимог до програмного забезпечення". Іноді кажуть, що це біблія для бізнес-аналітиків-початківців. Переклад на російською неідеальний, тому рекомендую читати англійською.
3. IIBA Global Business Analysis Standard. Це "вичавка" з BABOK, підготовлена IIBA. Розповсюджується безкоштовно.
4. Алан Купер «Психлікарня в руках пацієнтів». Легко читається. Цікавий погляд на індустрію, програмне забезпечення та позицію бізнес-аналітика.
5. Dean Leffingwell. Agile Software Requirements. Допоможе зрозуміти специфіку роботи з вимогами у рамках agile-проектів.
6. Джозеф О'Коннор «Мистецтво системного мислення». Вебінари та статті:
1. Мій вебінар, присвячений підготовці до співбесіди.
2. Доповідь Use Case VS User Story – порівняння двох найпопулярніших технік специфікації вимог.
3. Дві статті про те, як описувати вимоги до інтеграцій: файловий обмін та API.
4. Багато корисного на англомовному ресурсі Modernanalyst. Форум, список із трьох сотень книг, архів вебінарів та анонси майбутніх виступів. Що робити, щоб підвищити ймовірність успішного проходження співбесіди та пришвидшити перехід від трейні/джуна до наступної сходинки?
Наразі існує безліч курсів і тренінгів по бізнес-аналізу. Я раджу обирати ті, де:
тренер є практикуючих фахівцем із значним досвідом в професії та у викладанні. Додатковими ознаками професіоналізму є виступи на тематичних конференціях і наявність статей на професійну тематику. Перевірити це можна через той самий Linkedin. Якщо досвіду менше 5 років, то виникають справедливі сумніви в професіоналізмі тренера.
Відгуки по тренінгу: шукаємо в Facebook/Google Map/Linkedin. А ще краще - знайти своїх знайомих, що вже проходили навчання там. Зробити це можна в тому самому Linkedin шукаючі людей із сертифікатом/зазначеним навчанням у відповідного тренера/центру навчання.
Наявність практичної частини: Теорія це добре, але без закріплення на практиці вона мертва.
Домашні завдання: Це додаткова можливість закріпити отриманні знання. Якщо практика, згадана в попередньому пункті, це біль про групову роботу, то домашня - індивідуальна.
Кількість людей в групі: цей пункт напряму пов’язаний з пунктами 3 та 4. Якщо група більше 30 (вже мовчу про 50-75-100) людей, то тут ви зможете отримати лише теорію. Навіть поставити запитання тренеру буде проблематично. Мовчу вже про відпрацювання технік/інструментів на практиці.
Наявність нереалістичних обіцянок: якщо бачите фрази "гарантуємо працевлаштування", "стан професіоналом за 5 тижнів", "100 гарантія сертифікації" - для вас це має бути стоп-сигналом. Вас намагаються ввести в оману.
Цільова аудиторія курсу: якщо ви новачок, шукайте тренінг, що розрахований для новачків, якщо досвідчений професіонал - шукайте курс розрахований на них. Якщо курс спеціалізований, то визначте, наскільки ця тема є для вас важливою прямо зараз, чи зможете ви використати ці знання на практиці? Ну а якщо ви спитаєте мене, який тренінг я би порадив БА-початківцю, то відповім наступне: приходьте на курс BABasics.Online від Дениса Дніпровського.