Archive for the ‘Analītiķu vakariņas’ Category

Ko par sevi nezināja sistēmanalītiķis?


Analītiķu vakariņās atcerējos reiz lasītu stāstu. Kāda žurnāliste bija nonākusi spēlē, kur bija jāpelna nauda, piedāvājot kādu savu prasmi. Kamēr tirgošanās jau gāja pilnā sparā – kāds piedāvāja deju, kāds pazīlēt uz rokas, kāds dziesmu, šī meitene apjukusi domāja – bet ko lai es piedāvāju… un tad izdomāja: pārdošu patiesu un atklātu stāstu par to, kā es redzu savu sarunu biedru! Un, ziniet – pie viņas izveidojās rinda.

Tā nu līdzīgi bija, kad mēs, analītiķi, aizrautīgi klausījāmies stāstu par sevi, kad runāja mūsu kliente. Mūsu – plašā nozīmē. Cilvēks, kam ir ilggadēja pieredze – gan pozitīva, gan negatīva. Tā bija saruna. Ne moralizēšana, ne didaktiska pamācīšana, bet unikāla iespēja atklāti izrunāties. Lai paliek tehniskās nianses, lai paliek lietas, kuras nav paredzētas publiskošanai. Lūk, kādas atziņas es pierakstīju un šur tur apņēmos laboties:

No sistēmanalītiķa (to gan var attiecināt uz ikvienu izstrādātāja pārstāvi) sagaidu patiesu ieinteresētību savā darbā, nevis atstrādāšanu.

Kad pirmo reizi atnāk analītiķis, sagaidu, ka viņam ir priekšstats par mūsu uzņēmumu, kā arī orientējas mūsu biznesa pamatos.

Pirmajā tikšanās reizē sagaidu, ka uzklausīs mani. Negaidu, ka sāks mani mācīt dzīvot!

Nepatīk, ja man saka: „uzdošu muļķīgu jautājumu”. Nav muļķīgu jautājumu!

Valoda, kādā runā ar mani… Neatkarīgi no iemesliem – varbūt grib manā priekšā izrādīties vai neiedomājas, ka esmu biznesa, nevis datorcilvēks, taču gribu sarunāties sev saprotamā valodā, bez IT žargona vai specifiskiem jēdzieniem.

Ja nedēļas laikā pēc tikšanās nesaņemu jautājumu vai komentāru par notikušo sarunu, rodas sajūta, ka par mūsu sarunu netiek domāts vai vēl ļaunāk – ir vienkārši…. aizmirsts. Un tā ir nepatīkama sajūta. Šādu sajūtu klientam nedrīkst radīt!

Risinājumi atkarībā no projekta situācijas:

sarunāt obligātās tikšanās reizi nedēļā pat tad, ja nav akūtu jautājumu, ko pārrunāt,

– katras komunikācijas beigās vienmēr norunāt, kad būs nākamā, par ko tā būs un kāds būs tās rezultāts.

Īpašs uzsvars – tiešām ir ļoti svarīgi neradīt klientam informācijas vakuuma sajūtu. Klients grib zināt aktuālu informāciju par termiņiem, par notiekošo.

Klienta īpašs lūgums analītiķiem: ja ir sarunāts termiņš, līdz kuram kaut kas tiek gaidīts no mums, un rezultāts svarīgs arī jums, lūdzu, atgādiniet arī jūs. Arī mēs esam tikai cilvēki. Nepaļaujieties, ka mēs atcerēsimies un ievērosim. Lūdzu, neizmantojiet mūsu aizmiršanu, lai kaut kādā veidā atspēlētos par kavēšanos.

Arī mans laiks ir dārgs. Tikšanās laikā ārkārtīgi svarīgi ir satikties pareizajiem cilvēkiem. Gan no savas puses gribu būt droša, ka sarunā nodrošināšu pareizos cilvēkus, gan sagaidu, ka izstrādātāja pārstāvji pilnībā pārklās sarunas tēmu.

Klients var pat nenojaust, ka projektā ir tādi arhitekti u.tml. speciālisti. Tāpēc būtu labi kādā no pirmajām tikšanām neuzkrītoši noskaidrot priekšzināšanu līmeni un īsumā izskaidrot projekta struktūru un raksturot to cilvēku pienākumus un atbildību, ar kuriem klientam būs tikšanās. Nevis vienkārši painformēt – nākamreiz man līdzi atnāks arhitekts (???!!!!).

Kad zināms, ka tikšanās laikā runa būs par konceptuāliem jautājumiem un lēmumus būtu labi pieņemt operatīvi, ir labi, ja līdzi ir arhitekts. No klienta skatījuma tas izskatās tā: „Arhitekts piebaksta projekta pārvaldniekam vai analītiķiem, abi parunājas savā starpā dažādos IT svešvārdos, pastrīdas, vienojas un klientam jau atbild vienotu – jā/nē”. Klients redz, ka speciālisti ir apspriedušies, un ir ticamība lēmumam.

Ja programmētājs bieži nāk līdzi uz tikšanos pie klienta, rodas sajūta, ka viņam īsti nav ko darīt. Tāpēc ir ļoti svarīgi vienoties par nākamās tikšanās tēmu, lai varētu paņemt līdzi tieši tos cilvēkus, kuri ir nepieciešami. Un: nevajag ņemt līdzi kodētāju. Labāk ņemt līdzi arhitektu.

Ja tomēr paņemts līdzi programmētājs, viņam jādomā, ko runā. Gadījums no dzīves: grāmatvede uztraucas, ka virsgrāmatā nepareizs ieraksts. Programmētājs mierinoši: neuztraucieties taču, visu izdzēsīsim! Grāmatvede vēl šobaltdien negribot redzēt nevienu programmētāju :-)

Gadu gaitā interesants novērojums – laba sadarbība izdodas ar sistēmanalītiķēm sievietēm. Augstu vērtēju prasmi ātri pārslēgt domāšanu no vienas tēmas uz otru, un sagadījies, ka tieši sievietēm tā piemīt teicamā līmenī. Savukārt labāka sadarbība izveidojusies ar projektu pārvaldniekiem vīriešiem. Tā nav dogma un tas nav uz stereotipiem balstīts pieņēmums – konkrētā projektā un manā pieredzē tā vienkārši ir sanācis.

Klients pieķeras pie visa, par ko viņam sarunā vai sarakstē ļauj cerēt, ka būs. Tāpēc aicinu nopietni pieiet jebkādiem solījumiem vai pat mājieniem. Dažreiz izveidojas pat tāda kā spēlīte: analītiķis – labais policists, projekta pārvaldnieks – sliktais policists, kurš pasaka, ka resursu nav, laika nav, nebūs. Būtu labi šādas spēlītes nespēlēt un ikvienam atbildēt par saviem vārdiem.

Klientam ļoti svarīgi ir zināt precīzus, pēc iespējas precīzākus termiņus. Organizācijā ir arī augstāka līmeņa plāni, kuri veidojas no zemāka līmeņa plāniem, tāpēc sagaidām no izstrādātājiem pēc iespējas precīzākus laika un izmaksu aprēķinus. Laiku pastiept ir salīdzinoši vieglāk. Izmaksas – krietni grūtāk. Tāpēc aicinājums – ļoti nopietni pieiet šādiem aprēķiniem un solījumiem.

Ir bijis laiks, kad par varītēm šķita svarīgi panākt, ka maksimāli daudzas lietas pie katras izdevības ir problēmu ziņojumi. Ar laiku nāca pieredze un tīri cilvēciska atklāsme, ka svarīga ir pozitīva sadarbība, tāpēc katrs gadījums tiek rūpīgāk izvērtēts, bez mērķa nogrūst to izstrādātājam.

Attiecības – draudzīgas, taču ne personiskas. Laiks ir dārgs un nedrīkst pieļaut, ka daļa sarunas ar laiku ievirzās gultnē „un kā tad tavam sunītim klājas?”

Negaidu, ka IT cilvēks nāks uzvalkā, taču sagaidu, ka pielāgosies klienta organizācijas videi. Lai gan par IT cilvēkiem ir zināmi stereotipi, sevišķi programmētājiem, ka viņi ģērbjas, teiksim tā, interesanti, tomēr no analītiķiem sagaidām respektu pret organizācijas ģērbšanās kultūru.

Uz „Tu”, ja vispār, tad piedāvā pāriet klients.

Vai komanda ir izstrādātāji, vai izstrādātāji + klienta pārstāvji? Atkarīgs no projekta un izstrādātāja, tomēr viela pārdomām – ko uzskatīt par komandu.

Klients nevienā situācijā IT jautājumos nedrīkst sajusties pārāks par izstrādātāju!

Reizēm klientam gribas satikt valdes locekli, kurš pasaka un nodrošina pārliecību, ka jūs mums rūpat, jūs mums esat interesants un mēs iesim ar jums kopā līdz uzvarošajam galam!

Pozitīva pieredze: bija praktikante, kura pusgadu strādāja, ielauzījās biznesā un aizgāja pie izstrādātāja strādāt par testētāju. Nodevumu kvalitāte ievērojami uzlabojās attiecībā uz biznesa funkcionalitātes kvalitāti.

Darbinieku maiņa: svarīgi, lai būtu kvalitatīvi nodotas lietas. Izstrādātāja pienākums ir nodrošināt, lai aizejošais darbinieks to korekti izdara. Patiesībā ideālā gadījumā uz pēdējo tikšanos vai pat vairākām varētu atnākt kopā vecais un jaunais. Tādējādi klients redzētu, ka pēctecība tiek nodrošināta, un būtu sirds mierīgāka.

Negatīva pieredze: uz tikšanos atnāca cilvēks, kuram ne tikai nebija priekšstata par klienta biznesu, bet kurš nebija pat pacenties noskaidrot, kā notiek sadarbība ar klientu. Klients bija spiests tērēt savu laiku, „apgaismojot” paša apmaksāto izstrādātāju par to, kā viņi savā starpā strādā. Ja biznesa nezināšanu vēl varētu piedot, tad šāda attieksme jau bija zem katras kritikas.

PPS gribētu, lai ir izkārtota atbilstoši savam biznesa procesam – tā, kā ir ērtāk lasīt klientam, nevis ērtāk strukturēt izstrādātājam. Būtu labi savlaicīgi saskaņot satura rādītāju. Specifikācijā patīk bildes, modeļi. Patīk, ka ir aprakstīti algoritmi.

 Ārkārtīgi svarīga ir vienprātība definīciju izpratnē. Svarīgi iedomāties un saskaņot arī it kā vispārzināmus jēdzienus. Piemēram, „gads”. Personāla pārvaldei – gads, kopš darbinieks stājies darbā. Izstrādātājam – kalendārais gads.

Projekti notiek nevis starp organizācijām, bet starp cilvēkiem. Cienīt vienam otru un – cienīt vienam otra laiku. Un – sajust gan vārdos, gan darbos, ka sistēmanalītiķis un pārējie strādā, lai atvieglotu klienta dzīvi.

Mēs dažreiz pārmetam, ka ierēdņi aizmirst, ka strādā mums, nodokļu maksātājiem. Bet vai mēs, sistēmanalītiķi, vienmēr, vienmēr atceramies, ka strādājam jums, klienti? Sirsnīgs paldies klientei par šo sarunu!

P.S. un mums paveicās, ka starp klausītājiem bija vēl viena klientu pārstāve, arī sistēmanalītiķe, kura ik pa brīdim padalījās arī savā pieredzē. Jāteic, tie organiski papildināja sarunu.

Analītiķu vakariņas un CBAP sertificēšana


Kas cits sistēmanalītiķim asti un profesijas prestižu cels, ja ne pats?

Tagad arī Latvijā ir tāda iespēja. Biedrība http://latvia.theiiba.org, tviterī http://twitter.com/iiba_latvia. Lai iestātos, jābūt lielās IIBA asociācijas biedram. IIBA – Starptautiskais biznesa analīzes institūts. Katra mēneša pēdējā trešdienā ir “Analītiķu vakariņas” (kolosāls nosaukums :-) ).

Īsumā par 30.03 „Analītiķu vakariņu” iespaidiem

Ameklēju pirmoreiz (un nožēloju, ka palaidu garām iepriekšējās – jo bija tik jauki). Tēma bija – analītiķu sertifikācija un jaunpienācējiem stāsts par to, kas ir IIBA Latvijas nodaļa. Kas attiecas uz terminoloģiju „biznesa analītiķis” vs „sistēmanalītiķis”, vakar izskanēja, ka biznesa analīze ir daļa no sistēmanalīzes, lai gan precīzas definīcijas neesot un par to jau agrāk esot risinājušies kaismīgi strīdi.  Manā subjektīvajā skatījumā biznesa analīze un sistēmanalīze būtībā ir dažādas lietas. Biznesa analītiķis skatās, kā pārvaldīt, teiksim, klientu pieņemšanas procesu (un var pat nezināt, ka tur kaut kur ir programma), savukārt sistēmanalītiķis parasti saņem jau puslīdz gatavu procesu, kuru saprot (intervē, lasa, pēta, skatās…), tad formalizē un novada līdz strādājošai programmai tā procesa atbalstam (žargonā to sauc par bardaka automatizāciju). Ļoti labs sistēmanalītiķis sevī apvieno abas šīs lietas: vispirms sakārto (optimizē, konsolidē, novērš pretrunas…) biznesa procesus un tad liek tos programmā. Bet… te iederas šī bildīte.

Sertifikācija

Nosacīti 1.līmenis: CCBA: Certification of Competency in Business Analysis – demonstrēt, ka analītiķa spējas atbilst noteiktam pamatprasību kopumam. Tēlaini varētu pielīdzināt prašanai braukt ar vieglo auto.

Nosacīti 2.līmenis (augstāks) CBAP: Certified Business Analysis Professional— vecākajiem analītiķiem kā pierādījums, ka spēj pacelt dažādas sarežģītības projektus. Skaitās augstākā sertifikācijas pakāpe, ko var iegūt profesionālis informācijas sistēmu un biznesa sistēmu analīzes jomā. Tēlaini varētu pielīdzināt spējai ar auto palīdzību izbraukt astotnieku, veikt sarežģītu loģistiku un vispār pārvaldīt autoparku.

Sertifikācijai ir pamatīgas priekšprasības, noteikts prakses stundu skaits (atšķirīgs CCBA un CBAP), noteikts profesionālās pilnveidošanās stundu skaits un divas rekomendācijas. Tāpēc formalitātes jāsāk kārtot ļoti savlaicīgi, vismaz pāris mēnešus iepriekš jāsāk vākt informācija. Priekš CBAP:

• Sufficient Work Experience – 7,500 hours (i.e., five (5) years) of BA work experience in the last ten (10) years engaged in tasks specifically aligned with the BABOK®.

• Expertise in the BABOK® Guide Knowledge Areas – Demonstrated experience and expertise (i.e., a minimum of 900 hours (i.e., 6 months) in at least 4 of the 6 BABOK® knowledge areas.

• Minimum Education – You must meet the minimum education requirement of high school or equivalent.

• Adequate Professional Development Hours – 21 hours of BA-related professional development within the last 4 years.

• Evidence of Certification Suitability – Two references to indicate that you are a suitable candidate for the CBAP® certification, whether a career manager, an internal or external client or a CBAP® recipient.

Eksāmens

150 jautājumi ar atbilžu izvēlēm, ilgums 3.5h. Sākot ar marta vidu, šos sertifikācijas eksāmenus Latvijā piedāvā kārtot Baltijas Datoru akadēmija (BDA). Pagaidām BDA nepiedāvā sagatavošanās kursus un apmācību biznesa analītiķiem – tādas iespējas jāmeklē citur, piemēram, http://www.thebamentor.com.

Eksāmenā nav atļauts izmantot nekādus palīgmateriālus (arī EN-LV vārdnīcu ne). Var izvēlēties, kārtot uz datora (rezultātu ok/neok pasaka uzreiz pēc eksāmena) vai uz papīra (tad rezultāts mēneša laikā).

Būtībā tā ir zināšanu pārbaude pret BABOK (Business Analysis Body of Knowledge). Jāpiebilst, ka šī grāmata nav metodoloģija. Tā drīzāk ir enciklopēdija par to, kas biznesa analītiķim ir jāzina un no kā sastāv pats analīzes process, atslēgvārdi un jēdzieni, kas ir requirement, kas ir rule, kas ir enterprise architecture, kas ir business architecture, pārklājuma matrica utt. T.i. ja analītiķim-praktiķim nesagādātu lielas grūtības argumentēt (lasiet: dažreiz arī demagoģēt), ka pareizas ir visas vai vairākas atbildes, jāatceras, ka šajā sertifikācijā pareizā atbilde būs tas, ko par to saka BABOK. Un ļoti rūpīgi jālasa jautājuma formulējums: ja tur ir jautāts „which is best for understanding”, tad tas nenozīmē, piemēram, „which is best for solving”.

Manas domas

Iestāšanās IIBA: viennozīmīgi PAR ($65 gadā). 30.03 sistēmanalītiķu vidējā koncentrācija uz kvadrātmetru bija iespaidīga. Sajūta – kā jau starp savējiem. Īpaša atzinība RTU mācībspēkiem – bija klāt un izteica gatavību operatīvi pielāgot un papildināt savas mācību programmas arī ar zināšanu sniegšanu šādas sertifikācijas vajadzībām. Tā kā es esmu LU patriote, strādāšu, lai aktīvāk savestu kopā LU Datorikas fakultāti ar IIBA Latvijas biedrību. Galu galā Matemātikas un informātikas institūtā (MII) top mūsu pašu zinātnieku izstrādāts izcili labs rīks (esmu to redzējusi darbībā projektos un doktorantūras ietvaros lietoju arī pati), platforma – kurš zina GRADE, lūk, šis rīks ir tāds kā super-turbo GRADE ar iespēju veidot gan savas domēnspecifiskas valodas, gan veikt modeļu transformācijas, gan ērti zīmēt labas diagrammas, un analītiķi būtu īstā mērķauditorija – gan darīt zināmas praktiķu vēlmes zinātniekiem, kamēr siltas, gan apdomāt iespēju šo rīku izmantot sava darba atvieglošanai.

CBAP sertifikācija (izmaksas ap $450-$1200 (tas ja ņem kādus kursus): būtu interesanti. Dzirdēju baumu, ka LV tenderos jau esot parādījušās prasības, lai būtu šie sertifikāti (te gan jāpatur prātā, ka var būt kāmīša skrējiena efekts – tie, kuri sertificēsies, var pielikt pūles, lai šādu prasību arvien biežāk iekļautu, tādējādi liekot pārējiem neatpalikt, jūs jau atceraties slaveno atziņu – ir ātri jāskrien, lai noturētos uz vietas). Kā minēja viena no dalībniecēm, startējot uz ārzemēm tādu kompetences pierādījumu – CBAP – esamība esot pašsaprotama lieta.

Latvijā šobrīd ir divas CBAP sertificētas sistēmanalītiķes, drīzumā noteikti būs vēl – un tas vedina domāt, ka principā tas IR izdarāms, gan priekšnosacījumi izpildāmi, gan eksāmens nokārtojams. Par sevi vēl domāšu, jo gribēšana kā tāda ir, taču ar brīvo laiku tā ir kā ir. 

CBAP sertifikācijas jautājumu piemēri (atbildes ir šajos slaidos) un vēl 150 piemēri

What technique might be used to help familiarize the project team with the existing solution scope?

A. Context scope diagram

B. Requirements workshop

C. Structured walkthrough

D. Brainstorming

Non-functional requirements are best described as what?

A. Deliverables that are progressively elaborated on

B. Nothing. If they do not function they must be design elements

C. External interfaces the product must have

D. Internal interfaces the product must have

Which of the following roles have the most effect on the business analysis approach selected?

A. Business analyst, implementation SME (subject matter expert), project manager

B. Tester, regulator, and sponsor

C. Project manager, sponsor, supplier

D. Business analyst, tester, regulator

P.S. Katrā ziņā savā plānotājā jau ierakstīju nākamās Analītiķu vakariņas. Jāpiesakās savlaicīgi, vietu skaits ierobežots, ir arī neliela dalības maksa.

%d bloggers like this: