Profesia de business analyst a devenit în ultimul timp importantă pentru fiecare echipă de proiect. Am discutat cu invitații noștri principalele caracteristici și provocările acestei profesii:
Blanka Nagy - ServiceNow Business Analyst @ Accesa,
Andreea Domide - ServiceNow Business Analyst @ Accesa,
Romeo Boda - Business Consultant @ msg systems Romania,
Ovidiu Mățan: Vă invit să vă realizați o scurtă introducere
Blanka Nagy: Am terminat specializarea Management-Engleză și sunt în Accesa de doi ani jumătate, lucrând ca BA (Business Analyst). Momentan, lucrez pe un proiect intern, dar am lucrat pe multe alte proiecte și pe implementarea modului de lucru Agile. Proiectul intern la care lucrez momentan este centrat pe gestionarea riscului unde am personalizat fluxurile de lucru folosind un agent virtual și integrare cu OpenAi în anumite situații.
Andreea Domide: Sunt în Accesa la Oradea de nouă ani și câteva luni. Am început ca programator, dar de un an lucrez ca BA. Faptul că am început de pe o poziție tehnică mă ajută să pregătesc toate elementele de care au nevoie programatorii. Momentan, lucrez pe un proiect de Service Request Management, și lucrăm la integrări cu furnizori de diverse servicii.
Romeo Boda: Lucrez la .msg pe proiecte Automotive pentru Mercedes. Proiectul este vechi, de opt ani, iar eu lucrez la el de doi ani. Migrăm un sistem foarte vechi, iar funcția mea este de Business Consultant și Proxy Product Owner.
Acum zece ani, nu exista meseria de BA. Ce face un BA?
Romeo Boda: Așa este. Exista rolul de Requirements Engineer, de unde s-a desprins rolul de Business Analyst. Nici în SCRUM nu exista acest rol. Pe scurt, reprezintă puntea dintre client și programatori. Un BA trebuie să afle cerințele, să le detalieze, să le documenteze cât se poate, astfel încât să se poată apoi crea User Stories ce vor fi discutate la ședințele de Refinement, apoi estimate și duse în muncă.
Andreea, ce ai avea de adăugat?
Andreea Domide: Din experiență, pot spune că rolul unui BA este ca acei care ocupă rolul de stakeholder să nu înnebunească programatorii.
Ce este un stakeholder? Cum se comunică cu ei?
Andreea Domide: În cazul meu, lista celor cu rol de stakeholder este propusă de Project Manager, ceea ce îmi arată că sunt multe subiecte ce trebuie abordate în cadrul proiectului. Când domeniul de definiție sau scope-ul se modifică, se poate schimba și lista de persoane cu rol de stakeholder. Practic, ne dăm seama că pe o anumită temă, trebuie să găsim alt specialist, așa-zisul Service Owner. Un stakeholder aprobă dacă un anumit aspect a fost implementat corespunzător. Cerințele le discut cu un stakeholder, apoi transform cerințele într-un story sau mai multe, le dau programatorilor să lucreze, testez, iar implementarea o prezint celor cu rol de stakeholder pentru aprobare.
Romeo Boda: Cu siguranță, depinde de la caz la caz. Ceea ce Andreea descrie seamănă mai mult cu un Product Owner. Rol de stakeholder pot avea multe persoane, de la un Board de oameni la un finanțator, de la utilizatori finali cu care ai interviuri la oameni interni care pot să își dea cu părerea asupra proceselor.
Cum facem requirements de AI ca BA?
Blanka Nagy: Am integrat cu un agent virtual un flux de lucru de OpenAI, asta însemnând că limităm prin roluri anumiți utilizatori care accesează un portal, pun întrebări, iar OpenAI aduce răspunsul. Am lucrat doar cu o integrarea simplă, generică.
Care este diferența dintre un Project Manager și un BA?
Blanka Nagy: Pe un proiect bine stabilit, un Project Manager este responsabil de partea operațională. Un BA lucrează mai mult în dezvoltare, având o legătură strânsă cu programatorii. Un Project Manager are o întâlnire cu un BA o dată pe săptămână sau pe sprint unde primește ultimele informații, dar ședințele Daily Scrum sunt identice și informative pentru ambele roluri.
Un stakeholder aduce un requirement nou. Poți să îl influențezi? Poți să îi spui ce se poate face mai bine sau mai diferit?
Blanka Nagy: Am avut oportunitatea să fiu în conversații directe cu un stakeholder, iar așteptarea este ca tu să explici ce este de făcut și cum, deoarece ai mai multă experiență. De obicei, sunt destul de deschiși, mai ales dacă au deja experiența proiectelor anterioare. Nu facem Business Cases, acestea fiind definite. Este de menționat că ține de latitudinea unui BA să clarifice în detaliu anumite aspecte.
Ce ar trebui să facă, să citească sau să învețe o persoană care dorește să devină BA?
Andreea Domide: Înainte de a lucra pe ServiceNow, am avut alte două proiecte. Unul a fost un tool de ITSM unde am lucrat cinci ani. Apoi, timp de doi ani, am lucrat pe un tool de Identity and Access Management. Pe ambele proiecte am fost consultant, termeni care sunt vagi, deoarece fiecare înțelege ce vrea. Făceam și BA, și programare, câte puțin din toate, dar când am venit pe ServiceNow, separarea aceasta de roluri mi s-a părut foarte interesantă. Uneori, îmi este dor să scriu cod, dar mă bucur că pot ajuta programatorii, scriind story-uri clare. Practic, știind produsul, am ales să mă concentrez asupra zonei acesteia de BA. Având background tehnic, sunt deseori întrebată cum ar fi mai bine să fie implementată tehnic o funcționalitate. Uneori, este foarte greu să mă opresc de la a scrie atât story-ul, cât și soluția tehnică.
Romeo Boda: Certificări nu aș recomanda în primii ani. Certificările vin după câțiva ani de experiență. Am șase ani de experiență și încă nu am certificare. Nu știu dacă m-ar fi ajutat sau dacă m-ar fi încurcat. Dacă știi să folosești Google, poți citi foarte multe subiecte pe această temă. Cea mai bună metodă este a învăța făcând.
Poți să ai conflicte cu un stakeholder dacă nu acceptă ceea ce îi spui tu?
Romeo Boda: Sigur. Absolut. E bine să detaliezi cât poți, să pui cât mai multe întrebări și să setezi așteptările ca să nu primești remarci de genul: De ce nu e gata funcționalitatea din moment ce e gata sprintul? Ține de noroc să găsești un Product Owner care are și background tehnic, și de business, deoarece așa vei livra funcționalitatea cu defecte puține.
La câți oameni dai de lucru? Câți oameni deservești?
Romeo Boda: Depinde de proiect, de cât de repede trebuie livrat proiectul și de ce buget există. Am avut și echipe de 4-5 programatori și echipe de 24 de programatori.
Folosești tooluri speciale când scrii Use Case-uri sau User Story-uri?
Andreea Domide: Eu sunt așa, mai de modă veche. Folosesc Notepad++ ca să îmi păstrez toate gândurile și, ulterior, aranjez totul frumos în sistemul ServiceNow.
Blanka Nagy: Avem un modul de Agile Development în ServiceNow pe care îl folosim. Este customizabil, astfel încât să fie ușor pentru un BA să scrie story-urile.
În programare, foloseam și folosim Design Patterns. Sunt ca niște rețete la tipuri de probleme. Voi aveți așa ceva?
Andreea Domide: Din experiența mea, nu avem astfel de Design Patterns, dar, dacă ne referim la ServiceNow, anumite functionalități se vor implementa similar. Dacă ai o interfață de ServiceCatalog unde ai tot felul de requesturi, acolo toate formularele se implementează la fel referitor la ceea ce vede utilizatorul, la cum se transmit mesajele etc. Destul de rar ai nevoie de ceva mai special, deși acest lucru este posibil.
Romeo Boda: Avem template-uri, șabloane pe care le refolosim. Sunt speciale pentru backend, frontend, diverse funcții. Depinde de cât de experimentat ești pe proiect. Dacă primești un requirement nou și știi că s-a implementat ceva similar care a fost catalogat drept element reutilizabil, atunci știi de unde să pornești și, evident, termini munca mai repede.
Voi dați de lucru programatorilor. Ce relație aveți cu programatorii? Sunteți iubiți?
Romeo Boda: Depinde de preferințele programatorului, de cât de strict este cu Acceptance Criteria. S-ar putea să fie nevoie să dai în lucru un story unde nu ai încă toate elementele definite sau clare, iar, dacă programatorul nu înțelege ce are de făcut, va veni să te întrebe, ceea ce este enervant și pentru mine, și pentru el. Încercăm să mulțumim și clienții, și programatorii.
Andreea Domide: Nu sunt în sală programatori care lucrează cu mine, dar eu consider că ne înțelegem bine. Încerc să definesc rolurile și story-urile cât pot de bine. Anunț dacă nu știu anumite detalii, dar fac tot posibilul să le clarific. Sunt mereu disponibilă. Facem ședințe în care putem partaja ecranul. Când fac verificările, mă uit la implementare și cu un ochi de programator, deci mă uit prin cod.
Blanka Nagy: Sunt de acord cu Andreea. Cred că cel mai important este că protejezi programatorul. Când le arăt calendarul meu și câte ședințe am, programatorii cu care lucrez chiar se bucură că îi scutesc pe ei de atât de multă interacțiune.
(întrebare din sală): Cât de important este Domain Knowledge pentru un BA și care ar fi provocările dacă acest Domain Knowledge lipsește?
Blanka Nagy: Cred că este foarte greu. Nu cred că cineva care nu a mai auzit până acum de ServiceNow poate scrie story-uri. Nu cred că poți avea discuții serioase cu clientul în care să poți oferi sfaturi. Nu poți da exemple, nu poți estima corect.
Andreea Domide: Dacă nu ai Domain Knowledge e greu și pentru tine, și pentru ceilalți, deoarece toți din jurul tău vor fi confuzi. Dacă ajungi într-o astfel de situație, pune deoparte câteva zile și obține acel Domain Knowledge.
Romeo Boda: Eu pun partea de Domain Knowledge undeva mai jos. Ai intrat pe proiect, deci va veni cu timpul și partea de Domain Knowledge. Cu cât înțelegi mai bine proiectul, clientul și utilizatorii, cu atât îți va fi mai ușor. Atâta timp cât utilizatorii produsului nu sunt experți, adică atâta timp cât ei nu au mai mult Domain Knowledge decât tine, ești OK. Trebuie însă să înțelegi partea de requirements (cerințe) ca să poți da mai departe informația programatorilor.
(întrebare din sală): Ca BA, urmați metodologia SCRUM sau Agile? Impresia mea este că voi trebuie să fiți undeva mai sus, mai aproape de client, nu de partea tehnică. Ca să răspund la o întrebare anterioară legată de certificări, cred că BABOK conține toată teoria despre ce înseamnă să fii BA.
Blanka Nagy: Folosim Agile și SCRUM. Apropierea de client ține mai mult de etapa de culegere de requirements (cerințe). Ca task principal, trebuie să ții aproape de un stakeholder pentru a putea transmite mesajul cât mai clar programatorului. Dacă un Project Manager discută cu un stakeholder, iar tu ești în aceeași ședință cu ei, este mult mai greu să reia discuția și să explice cu exactitate programatorilor ce este de făcut.
Andreea Domide: Există un mod de lucru în Agile și SCRUM, apoi există particularități sau întârzieri care strică totul. Încercăm cu toții să respectăm principiile Agile. Cât de mult deviem sau nu, depinde de proiect și de echipă.
Romeo Boda: Ca BA, natural și instinctiv, vrei să te apropii de client, deoarece, dacă clientul este fericit, 90% din lucruri vor merge bine. Personal, sunt mai apropiat de echipele de programatori, dar eu am și rol de Proxy Product Owner. Cu clientul petrec o oră pe zi, iar cu colegii trei ore pe zi la ședințe.