Привіт, мені довелося брати участь у багатьох проєктах, і на кожному з них замовники розуміли завдання і роль аналітика по-своєму. Тому питання ролей аналітика на проєкті – мої особисті кров і піт болю: часто в одній особі хочуть бачити і розробника, і просунутого тестувальника з розумінням процесів автотестування, і багато-багато іншого. Проте багато вимог знаходять відображення в навичках та інтересах аналітика, але їх ще потрібно правильно сформулювати під час пошуку.
У цій статті я розповім, які ролі виконують фахівці, як змінюються їхні завдання, з ким можуть плутати різних аналітиків в IT, як їх відрізнити, і чим кожна роль корисна для різних типів проєктів. Тому що правильно обраний аналітик може замінити 2-3 фахівців різного профілю, а неправильно – не зробити нічого.
Цей гайд допоможе і замовникам, і виконавцям. Першим – чітко сформулювати бажання і потреби. Другим – розібратися у вимогах перших і краще зрозуміти себе як фахівця.
Іншими словами, типологія ролей аналітиків покликана запобігти розбіжності інтересів фахівця і клієнта. Я нерідко спостерігав ситуації, коли запити клієнтів не відображали повний список вимог, очікуваних від фахівця насправді. Наприклад, під час обговорення з’ясовувалося, що замість системного аналітика для розроблення ТЗ був потрібен аналітик 1С. Або від аналітика-джуніора за замовчуванням очікувалися навички з розроблення взаємодії конкретних систем, досить рідкісних у галузі. При цьому я не беру до уваги звичайні проблеми звичайного системного аналітика, коли доводиться занурюватися в незнайому предметну сферу або приймати справи в самому розпалі проєкту.
Аналітиків в IT можна умовно розділити на дві групи:
- Власне аналітики, які займаються бізнес- і системною аналітикою. Сюди входять бізнес-аналітики та системні аналітики, а також їхні різноманітні ролі, які різняться залежно від виконуваних завдань на проєктах.
- Ті, хто займаються аналітикою як методом дослідження чого б то не було. Ця група, навпаки, включає в себе абсолютно різнопланові спеціальності, тому цей блок у статті ми сховаємо під спойлер. Усі ці фахівці займаються різноманітними видами аналізу, що переважно виражається в аналітичних звітах.
Зміст
- Бізнес-аналітик, системний аналітик та їх підвиди ↩︎
- Бізнес-аналітик (BA) і його ролі ↩︎
- Канонічний бізнес-аналітик ↩︎
- Провідний аналітик команди ↩︎
- Операційний/процесний аналітик ↩︎
- Аудитор (процесів) ↩︎
- Спеціаліст з оптимізації процесів ↩︎
- Бізнес-аналітик як проджект-менеджер ↩︎
- Системний аналітик (SA) і його ролі ↩︎
- Інженер з вимог ↩︎
- Системний аналітик, він же full-stack аналітик ↩︎
- Системний інженер ↩︎
- Інтеграційний аналітик ↩︎
- Аналітика як метод ↩︎
- DWH-аналітик / SQL-аналітик / Аналітик баз даних ↩︎
- Data-аналітик / Дата-інженер ↩︎
- BI-аналітик ↩︎
- Висновки ↩︎
Бізнес-аналітик, системний аналітик та їх підвиди1
Бізнес-аналітик (BA) і його ролі2
Завдання бізнес-аналітика замовники та інші учасники IT-проєкту можуть розуміти по-своєму. І навіть включати сюди таку рідкісну роль ліда аналітиків, який до бізнесу відноситься досить опосередковано.
Канонічний бізнес-аналітик3
Аналіз процесів + менеджмент = вирішення проблем бізнесу в загальному вигляді
Це фахівець, який здатен зрозуміти та виявити потреби власників бізнесу на певне покращення, провести подальший аналіз наявних процесів та запропонувати зміну відповідно до потреб замовника. Саме до нього йдуть, щоб, наприклад, «підвищити на 10% прибуток за рахунок зниження загальних витрат виробництва». Причому діє цей фахівець дуже часто з боку менеджменту, а не з боку команди, що призводить до певного опору його діяльності у розробників. Якщо ж такий фахівець перебуває в команді розробки, то буває так, що він єдиний, хто може продуктивно розмовляти з менеджментом і власником бізнесу, бо бачить за мету не зібрати продукт, а дати змогу користувачеві реалізувати бізнес-завдання.
Бізнес-аналітик – перекладач з мови бізнесу на мову програмістів, який складає бізнес-вимоги (а інколи й попереднє ТЗ – про поширені помилки при його створенні писали тут). Крім того, він має формулювати запити на доопрацювання в термінах проєкту. Залежно від структури проєкту, це можуть бути загальні вимоги на кшталт «потрібно поліпшити швидкість роботи користувача з системою», а можуть бути й цілком конкретні, з кінцевою метою доопрацювань у певному модулі та способами її досягнення.
Однак найчастіше під цією роллю замовники в IT мають на увазі системних аналітиків, які розшифровують високорівневий бізнес-запит, визначають межі системи та контексту, а також збирають вимоги до розробки нової системи або доопрацювань наявної.
Провідний аналітик команди4
Аналіз процесів команди + менеджмент = вирішення проблем бізнесу і команди аналітиків
Він же тімлід аналітиків. Той самий бізнес-аналітик в IT, який дуже довго працював у великих колективах і має досвід з ведення документообігу та організації команд. Може працювати і простим бізнес-аналітиком, але частіше він потрібен у тих випадках, коли потрібно змінити методологію розробки, адаптувати велику команду аналітиків або налаштувати процеси аналітики. Іноді тімліда плутають з операційним аналітиком.
Операційний/процесний аналітик5
Аналіз процесів + менеджмент = вирішення проблем бізнесу за рахунок оптимізації процесів
На перший погляд, він нічим не відрізняється від канонічного бізнес-аналітика, описаного вище, який аналізує процеси AS IS і пропонує шуканий TO BE для озвученого замовником запиту. Тобто так має бути в ідеалі. При цьому визначення операційного або процесного аналітика найчастіше використовують поза IT, хоча насправді мають на увазі ту саму роботу за BABOK.
Іноді процесний аналітик займається не питаннями налагодження бізнесу і системи, а внутрішніми процесами команди, вибудовуванням процесів роботи з вимогами, менторством/навчанням або іншими організаційними питаннями. Тоді перетини з лідом очевидні, але різниця суттєва: лід здатний впровадити передбачувані зміни, зокрема й за умови демонстрації особистого досвіду в поточному проєкті, а процесний аналітик широких організаторських навичок не має і тільки вносить пропозиції. Апробація ж цих пропозицій лягає на вищі плечі.
Аудитор (процесів)6
Аналіз процесів = визначення проблем бізнесу
Роль рідкісна, але своєрідна: іноді великій команді аналітиків потрібен сторонній погляд, що перевіряє. А іноді це потрібно бізнесу, адже процеси потрібно перетрушувати часом дуже ґрунтовно.
Але якщо бізнес-аналітик шукає можливість поліпшень, розслідує тонкі місця – аудитор процесів шукає порушення, зіставляючи вимоги та документацію з реальним станом речей. Там, де бізнес-аналітик має домовитися – аудитор має виявити конфлікт, проблему й описати її, зазначивши найнебезпечніші ризики. Так собі роботенка. Тому важко дотримуватися принципів аудиту і бути неупередженим, перебуваючи всередині команди. Таких людей варто шукати окремо, можливо – на конкретний термін або проєкт, або в паралельний від основної діяльності відділ, такий собі відділ якості для вимог, процесів та іншого.
Спеціаліст з оптимізації процесів7
Підбір рішень + просування рішень = вирішення проблем бізнесу
Він же канбан-майстер, експерт ТРВЗ і головний раціоналізатор. Начебто і не аналітик зовсім, і до IT-систем відноситься остільки-оскільки. Ця роль раніше була дуже поширена, і зараз великі підприємства повертаються до системи ощадливого виробництва, впроваджуючи ті чи інші підходи (зокрема Канбан) – тож хто сказав, що це не потрібно під час випуску IT-систем?
Знайти відповідного фахівця, який може провести аналіз ситуації на місці (зокрема в IT-системі) і мати відповідний бекграунд – важко. Але іноді потрібен саме він, а не бізнес-аналітик, що володіє великим, але дещо відірваним від виробництва обсягом знань. Раціоналізатори – люди, які захоплюються ТРВЗ і Канбан, найчастіше мають досвід практичної роботи (навіть руками) і управління колективами у виробництві матеріальної продукції. Їхній погляд ох як може стати в пригоді.
Бізнес-аналітик як проджект-менеджер8
Аналіз поточних дій на основі процесів + менеджмент (контроль процесів) = вирішення завдань бізнесу
Якісні вимоги до продукту зобов’язані бути тестованими, перевіреними і реалізованими. І щойно ми згадуємо ці властивості, ми змушені говорити про терміни реалізації, наявність фахівців, підводні камені роботи і плани тестування. Тут же спливають діаграми Ганта, графіки роботи… Це потрібно якось модерувати.
Виокремлювати окремого фахівця на роль менеджера проєкту доцільно, коли передбачається, що він виконуватиме великий обсяг роботи – наприклад, у новому проєкті, за умови численних декомпозиційних завдань. Тобто завжди, коли процеси не налагоджені, нерівномірні. Однак найчастіше на проєктах не так багато завдань для ПМ як окремого співробітника, тому цю роль бере на себе за сумісництвом бізнес-аналітик (а іноді системний, але про нього розповімо в наступному розділі).
Навіть якщо такої ролі немає, бізнес-аналітик у будь-якому разі виконує деякі функції ПМ, бо слідкує за реалізацією підготовлених ним вимог після передання їх у розробку.
Системний аналітик (SA) і його ролі9
Інженер з вимог10
Збір та аналіз вимог + аналіз IT-системи = технічне завдання
Ця роль у класичному розумінні системного аналізу як розділу науки про опис систем (існує вона значно довше, ніж сучасні IT-корпорації) мовою математики передбачає наявність маси стандартів, подібних до IREB.
Згідно з цими стандартами, системний аналітик – це інженер вимог, який займається описом чого-небудь у вигляді умовного обмеженого концепту.
Системний аналітик, він же full-stack аналітик11
Збір вимог бізнесу + аналіз IT-системи = поставлені завдання
У класичному розумінні системного аналізу це фахівець, який описує систему через моделі її станів у будь-якій галузі. Тобто він формулює проблему, описує фактори, що впливають на неї, і пропонує способи зміни системи для досягнення заданої мети (це ми розглядали вище, у розділі про бізнес-аналітиків).
Сьогодні це фахівець ширшого профілю: він має проєктувати сховища, описувати інтеграції (іноді – буквально писати програмний код), займатися реверс-інжинірингом і багато іншого. І якщо бізнес-аналітик може бути менеджером за стилем мислення, то SA – завжди технар, який швидко заглиблюється в нову предметну галузь, маючи за плечима кілька років досвіду роботи зі схожими галузями. І в інноваційних технологіях розбирається за клацанням пальців, тож для роботи в новій сфері кращого фахівця годі й шукати.
Завдання управління йому не чужі – хоча б для того, щоб формулювати вимоги з огляду на запити бізнесу і перевіряти їхню реалізацію. Тест-план, приймання та демонстрація результатів також входять до його обов’язків.
У дуже великих проєктах роль системного аналітика обмежується саме розробкою вимог (причому технічною мовою) в усьому розмаїтті цього поняття, а в команді вона опиняється між бізнес-аналітиком, архітектором і тест-менеджером.
Системний інженер12
Аналіз оточення (системи) + аналіз IT-системи + вибір рішень = технічне завдання + передана система
Обережно: інколи так називають просунутого системного аналітика.
Дивно, але повний перелік завдань системного аналітика здатний виконувати саме фахівець з цією спеціальністю. Можна було б сказати, що SA та системний інженер — синоніми. SA також пише документацію, інколи описує інтеграції та навіть реалізує її, викладаючи на продакшн.
Системний інженер, на відміну від більш прикладного системного аналітика, здатен створювати складні математичні моделі “за наукою” — наприклад, розробити систему автоматичного керування.
Інтеграційний аналітик13
Аналіз взаємодій + аналіз IT-системи = опис взаємодій
Той самий системний аналітик, про якого мріють роботодавці сьогодні: він описує не самі системи, а конкретні взаємодії. Більше того — має не теоретичний, а конкретний досвід у зв’язуванні конкретних систем між собою або використання конкретних методів взаємодії.
На практиці його роль виконує full-stack системний аналітик. Але коли інтеграційна робота починає з’їдати більшу частину часу, а досвід звужується до кількох систем, волею-неволею варто виділити цю роль як окрему. Звісно, мова не йде про вміння проектувати REST API — інтеграційні аналітики спеціалізуються на розробці комплексу взаємодій “під ключ”. Наприклад, інтеграції брокерів повідомлень, підключення до ЄАІС або специфічних виробничих систем.
Чому варто виділити цю роль? Справа в тому, що в низці ситуацій інтеграційному аналітику не потрібне знання інших розділів знань системного аналізу — принаймні в тому обсязі, що вимагається від full-stack спеціаліста.
У наступному розділі ми поговоримо про фахівців, які застосовують аналіз для вирішення своїх завдань. Проте деякі з них не належать безпосередньо до аналітики та є спеціалістами в іншій галузі, іноді навіть такій, що не стосується IT. Однак їх усіх часто зараховують до аналітиків. Це не завжди правильно та може викликати непорозуміння між замовником і спеціалістом.
Аналітика як метод14
Як не дивно, більшість описаних у цьому розділі спеціальностей — це саме ролі, якщо ми говоримо про аналітику як науку чи сферу знань. Системний аналітик може виконувати зазначені ролі за наявності специфічних знань, але для таких завдань зазвичай шукають окремих фахівців. І це цілком логічно: навіть просте сховище даних буде спроєктовано набагато швидше вузькопрофільним спеціалістом, ніж аналітиком-універсалом.
Аналітики сховищ, даних та іншого
DWH-аналітик / SQL-аналітик / Аналітик баз даних15
Дуже умовна категорія фахівців із найрізноманітнішим бекграундом. Робота з базами даних очікується як навичка від системного аналітика. Окрема роль аналітика з роботи з БД потрібна тоді, коли необхідно щось більше, ніж просто виконувати стандартні запити. Наприклад, розробка функцій, реструктуризація або перенесення даних.
А от проєктування сховищ, яким займається DWH-аналітик, раніше доручали дуже досвідченим SQL-розробникам або системним адміністраторам. Наразі, через наявність величезних обсягів сховищ, таким фахівцям потрібен значно ширший набір аналітичних знань, щоб ефективно виконувати свої завдання.
Слід розділяти дві ролі: одна людина проєктує вимоги, а інша їх реалізує. Разом це і є DWH, але в такому випадку це тимчасова роль для розробки проєкту чи реалізації значних доробок (якщо, звісно, ви не Amazon).
Data-аналітик / Data-інженер16
Про розподіл цих спеціалізацій в інтернеті точиться багато суперечок. Мабуть, все зводиться до виконуваних завдань: один фахівець уміє розібратися в потоках даних і описати, як з ними працювати; другий здатний створити математичну модель обробки. Відповідно, і тим, і іншим може займатися аналітик, але тільки за наявності відповідних навичок (а в низці завдань — і вузькоспеціалізованої освіти).
Втім, і той, і інший не мають відношення до бізнес- або системного аналізу: набір навичок “правильного” data-аналітика включає дисципліни цих наук лише факультативно. Зі свого боку, data-аналітики можуть уміти працювати з озерами даних і створювати попередні моделі даних, писати технічні концепції, але це додатковий і дуже рідкісний навик.
BI-аналітик17
Це ще один вид аналітиків. Щодо того, хто і звідки вони, є розбіжності. Деякі вважають, що це різновид маркетологів, які займаються візуалізацією отриманих аналітичних даних і власноручним створенням систем візуалізації (розробкою вимог або налаштуванням спеціалізованих рішень “з коробки” для роботи в конкретних умовах). Хтось вважає, що ці фахівці — бізнес- і системні аналітики, здатні розробляти коректні метрики для оцінки бізнес-процесів і ставити завдання на розробку систем, які будуть однозначно представляти ці дані.
У будь-якому разі, для них передбачається самостійна робота з визначення необхідних метрик, впровадження збору даних про них та обробки — причому найчастіше з використанням конкретних систем. Все це дуже далеко від звичайного бізнес-аналізу і вимагає додаткових знань, що змушує шукати BI-аналітиків серед маркетингових та продуктових аналітиків. Але це вже зовсім інша історія — про “звірів” незнайомих, рідкісних і корисних.
Висновки18
На основі виділених ролей можна створити величезну матрицю — коли який фахівець потрібен. І все одно можна помилитися: занадто багато залежить від колективу, від особистості спеціаліста та конкретних уподобань/настроїв у команді. Вузька спеціалізація гарантує якість виконання певної роботи, але при появі нових вхідних виникають відхилення.
Тому замовник повинен чітко усвідомлювати можливі зміни в ході роботи, а аналітик — постійно розширювати свої компетенції та коригувати вузькі місця своїх знань. Але оскільки кожна роль бізнес- та системного аналітика включає в себе і особисті якості, і особистий досвід — треба враховувати, що перестрибнути напрацьовані роками звички за пів року не вийде. Не варто чекати від фахівця з інтеграцій, який кілька років розробляв API в підході API First осторонь від команди, що він одразу зможе керувати великою командою аналітиків. І навпаки.
Формуйте свої бажання та вимоги до аналітиків якісно, панове!
Дякую за увагу!
🚀Долучайтесь до нашої спільноти Telegram:
🚀Долучайтесь до нашої спільноти FaceBook:
🚀Долучайтесь до нашої спільноти Twiter X:
