Provocările unui Business Analyst

R>esponsabilitatea unui Business Analyst constă în înțelegerea nevoii de business, analiza și modelarea proceselor de business, asociate dezvoltării proiectelelor software. De regulă aceste proiecte sunt complexe, iar Business Analyst-ul trebuie să obțină informații din toate sursele disponibile. Și nu este o sarcină ușoară. Întregul proces de dezvoltare al proiectelor, pune Business Analyst-ul în situația de a se confrunta cu o serie de provocări. Care este cea mai mare provocare? Probabil ar fi dificil de stabilit, dar am putea afirma că următoarele provocări au o greutate semnificativă și un impact direct, pozitiv sau negativ, în activitățile zilnice ale unui Business Analyst.

Atingerea obiectivelor propuse

De câte ori nu ați fost nevoiți să organizați diverse întâlniri, având obiective diferite? Și cumva fără să vă dați seama ați ajuns în următoarea situație: "ne-am întâlnit, am vorbit două ore pe subiectul stabilit și nu am hotărât nimic"? Indiferent de obiectivul dorit a fi realizat (identificarea oportunităților sau a persoanelor interesate, documentarea cerințelor, analiza proceselor) este recomandat ca înainte de orice, să aveți o imagine de ansamblu asupra nevoii de business și a obiectivelor proiectului. Mai exact, unde anume vă situați, sau în ce faza a proiectului sunteți. E bine să știți înainte de a începe ședința ce anume vreți să obțineți în timpul propus. E bine să vă concentrați pe ceea ce puteți realiza, în funcție de priorități, iar lucrurile nerezolvate care necesită o analiză mai amănunțită să le stabiliți într-o viitoare sesiune.

Stabilirea unei relații de colaborare cu persoanele interesate

Una dintre marile provocări cu care se confruntă un Business Analyst este aceea de a înlătura barierele de comunicare (fie din cadrul echipei, fie din cadrul organizației). Și pentru a reuși, Business Analyst-ul trebuie să depună un efort suplimentar ca să afle răspunsuri la toate problemele.

Ce se poate face în această situație? Identificați acele persoane interesate care definesc nevoia de business, care dețin informații importante sau care au un cuvânt de spus cu privire la soluția implementată. Simplul motiv că acestea nu vor să împărtășească informații, ar trebui să ridice un semn de întrebare. Și este de datoria Business Analyst-ului să înțeleagă motivele care stau la baza acestui comportament:

• Sunt ele rezistente la schimbare? Sunt obișnuite cu modul lor de lucru și de aceea nu acceptă sau nu sunt confortabile cu noul sistem?
• Avem de-a face cu probleme legate de orgolii sau chestiuni politice?
• Sau pur și simplu nu înțeleg de ce procesul schimbării se întâmplă cum se întâmplă.

Înțelegând motivele care stau în spatele acestui comportament, puteți să acționați în consecință! Ceea ce trebuie să faceți și funcționează în cele mai multe cazuri, este să câștigați încrederea clientului. Acest lucru de regulă se întâmplă după câteva sesiuni de lucru împreună. O dată inițiat contactul cu clientul, există și comunicare mai bună. În cazul în care nu se poate comunica direct (se recurge la comunicare la distanță), atunci este nevoie de ceva abilități și calități suplimentare din partea unui Business Analyst precum: atitudine pozitivă, comunicare eficientă, orientare spre rezolvarea problemelor, spirit de echipă, încredere, flexibilitate, adaptabilitate. Pentru a facilita o conexiune cu clientul, puteți încerca replici de genul: "ce ați mai facut, de când nu am mai vorbit?"; "cum e vremea?". Apropiați-vă clientul! Câștigați încrederea clientului și stabiliți relații de lungă durată. Implicați-l activ în dezvoltarea proiectului, ascultați-l!

Facilitarea ședințelor

Având responsabilitate de lider, câteodată Business Analyst-ul este nevoit să îndeplinească mai multe roluri. De exemplu să faciliteze ședința și în același timp să noteze ideile esențiale. Se face o greșeală când se asociază rolul de scribe cu rolul de facilitator.

Câteva trucuri care vă ajută să fiți eficienți:

• Folosiți o agenda listată cu spații libere între subiecte/întrebări, pentru a putea completa cu răspunsurile corespunzătoare;
• Folosiți template-uri;
• Folosiți acronime (NC - noi cerinte);
• Imediat după ședință notați toate ideile importante;
• În timpul ședinței lăsați-vă câteva minute pentru a verifica dacă a fost acoperit tot ceea ce v-ați propus;
• Stabiliți un timp necesar și încercați să vă încadrați în acest timp - ce e mult strică;
• Concluzionați cu sublinierea ideilor principale asupra cărora toată lumea s-a pus de acord - acest fapt reflectă că obiectivul ședinței a fost atins. De multe ori ceea ce vi s-a părut că ați înțeles poate să fie total diferit de ceea ce au înțeles ceilalti participanți la ședință.

Investiție în cerințe de calitate

Există o fabulă veche care vorbește despre șase orbi care întâlnesc pentru prima dată un elefant. Deși aceștia nu puteau vedea elefantul, doreau foarte mult să știe cum arată unul. Fiecare din cei șase au pus mâna pe elefant, pe o diferită parte a elefantului. Primul cuprinde cu mâinile un picior al elefantului și spune: "A, elefantul e exact ca un copac". "Nu-i adevarat", spune cel de-al doilea care ținea elefantul de coadă. "Elefantul e ca o franghie". Cel de-al treilea orb a fost lăsat mai de o parte, si replică: "Elefantul e ca un perete". Al patrulea, cu mâna pe trompă, se bagă și el în seamă și zice."Nu aveți dreptate. Elefantul e ca un șarpe". Al cincilea atinge colții elefantului și spune că este o sulița pe când ultimul, hotărât, spune că toți ceilalți se înșeală și că elefantul e de fapt un ventilator (acesta ținând elefantul de ureche)¹.

Morala fabulei și legătura cu tema noastră de astăzi? Toți cei șase au dreptate. Elefantul are toate cele șase caracteristici descrise de ei , dar nici una nu descrie în ansamblu ceea ce reprezintă un elefant, pentru că fiecare a descris elefantul din propriul lui punct de vedere.

Același raționament se poate aplica și în cazul documentării cerințelor. E o practică bună de urmat să dezvoltați/să analizați cerințele din unghiuri diferite. Folosiți "DE CE" întrebări (DE CE/DE CE acum/DE CE nu). Evitați pot/aș putea/ar trebui, sau alte întrebări care pot conduce la un răspuns. Care este scopul? Să comparați cerințele provenite de la diferite persoane interesate și să revelati erori/duplicități sau interpretări diferite. Dacă există , atunci reprezintă probleme ce trebuie rezolvate imediat.

Alinierea diferitelor viziuni

S-a expus anterior cum aceeași funcționalitate a sistemului poate avea înțelesuri diferite, reprezentând viziuni diferite, din perspective diferite. Acestea provin de regulă din domeniul de activitate al persoanelor cheie (într-un fel vede produsul angajatul din departamentul de marketing și în alt fel cel din IT). Alinierea viziunilor într-o singură direcție reprezintă o adevărată provocare, pentru că de acest lucru depinde dacă proiectul va avea succes sau nu.

Ce se poate face? Business Analyst-ul trebuie să realizeze o viziune de ansamblu a întregului business, având mereu în vedere care este nevoia reală de business ce trebuie satisfăcută; să ia în considerare toate perspectivele, să cunoască organizația (mediul, produsul, piața, competitorii), și persoanele interesate (care sunt, nivelul de putere/interes), atitudinea lor vazavi de soluția implementată ( vor susține soluția sau vor fi total împotrivă și vor crea blocaje?).

Business Analyst-ul trebuie să dea dovadă că este un bun mediator și un bun negociator, astfel încât să faciliteze drumul spre o înțelegere/compromis.

Lipsa de angajament a persoanelor cheie

Participarea persoanelor interesate este esențială, căci acestea dețin informații relevante asupra business-ului, cu impact asupra dezvoltării proiectului, dar și pentru că trebuie să aprobe cerințele. Dacă nu avem acordul lor iar colaborarea este una dificilă, atunci proiectul poate fi într-un impas.

Iată câteva situații, mai des întâlnite, în relația Business Analyst - Stakeholders:

• Persoane cheie neimplicate- sunt cei care în trecut au fost implicați în planificarea și configurarea unui proiect care nu s-a finalizat tocmai în cele mai bune condiții, și care acum prezintă temeri în asumarea responsabilităților asupra etapei de documentare a cerințelor ("dacă nu s-a luat ceva în considerare?", "dacă am omis ceva?"). Acest lucru pune și Business Analyst-ul într-o situație dificilă, pentru că nici el la rândul lui nu vrea ca ceva important să fie scăpat din vedere. Ce se poate face? Dacă este timp, folosiți tehnici de descoperire a cerințelor (brainstorming, workshop-uri) și mai puțin interviuri, observări. Aceste tehnici antrenează idei noi și creativitatea în grup. Asigurați persoanele interesate că dacă ceva a apărut pe parcurs, sau nu a fost luat în considerare până în acel moment, respectivele cerințe vor primi prioritate maximă și vor fi implementate în următoarele versiuni/build-uri ale sistemului.
• Persoane cheie care ajung greu la un compromis - sunt cei cu personălități puternice, cu viziuni diferite asupra unei caracteristici ale sistemului. Ce se poate face? Subliniați faptul că dacă nu se ajunge la un acord comun, acest lucru înseamnă un risc pentru că se pierde timp, și pot să apară presiuni și frustrări în cadrul echipei. Asigurați-i că ați luat în calcul toate părerile/punctele de vedere și compromisul în sine nu le va afecta performanța sau siguranța locului de muncă.
• Persoane cheie dezinteresate- sunt cei care consideră că proiectul nu este important. Ce se poate face? Încercați diplomația. De exemplu, dacă vă adresați direct persoanei, (telefon/ e-mail):" Andrei, nici un alt angajat din această companie nu cunoaște sistemul la fel de bine ca tine. Și din acest motiv, chiar avem nevoie de tine. Ai avea o contribuție semnificativă dacă ai participa activ la ședințe, și ne-ai împărtăși din cunoștințele tale. Așa ne putem asigura că totul este la locul lui, și funcționează corespunzător". Dacă lipsa participării acestui stakeholder are o influență majoră asupra viitorului proiectului, atunci e bine să implicați și o persoana cu putere de influență/decizie din cadrul organizației sau managerul de proiect.

Un Business Analyst tehnic sau non-tehnic

Trebuie un Business Analyst să dețină cunoștințe despre ultimele tehnologii, despre detaliile tehnice ale sistemului? Și dacă da, care ar fi gradul de înțelegere al acestor lucruri? Cât de tehnic ar trebui să fie un Business Analyst? Părerile sunt împărțite. Dar ceea ce este sigur și toată lumea este de acord cu, este că un Business Analyst ar trebui să dețină suficiente cunoștințe tehnice sau competențe tehnice cât să-i faciliteze comunicarea cu echipa de dezvoltare. În ceea ce privește relația cu clientul, Business Analyst-ul trebuie să înțeleagă în ce fel tehnologia poate îmbunătăți business-ul, astfel încât să poată contribui la găsirea celei mai potrivite soluții. La fel de important este că "Tehnologia nu trebuie să dicteze niciodată direcția în care merge business-ul!". Din acest motiv răspunsul la întrebarea "Este posibil să fii o persoană non-tehnică și totusi să excelezi ca și Business Analyst" este cu siguranță DA. Desigur, în acest caz trebuie să compensezi cu alte abilități precum: gândire critică și analitică, comunicare eficientă, abilități de leadership.

Nu uitați

Literatura de specialitate cât și cei ce își desfășoară activitatea ca Business Analyst recomandă să investigăm întotdeauna cauzele problemelor, să nu tratăm doar simptomele. Să alegem agilitatea și nu perfecțiunea, mai exact organizațiile să fie receptive la presiunile externe astfel încât să recunoască din timp importanța soluțiilor oportune și relevante.

Dar mai presus de toate, se recomandă să fim mereu flexibili și adaptabili oricărei situații sau audiențe. Putem avea concepte, practici bune de urmat, experiență, însă, pentru că este imprevizibil și pentru că poate avea un impact atât pozitiv cât și negativ în toate nivelurile de funcționare, factorul uman rămâne, din punctul meu de vedere, cea mai mare provocare.