Kā es mācījos CBAP eksāmenam


Tātad, labā ziņa – CBAP sertifikācija ir paveicama arī parastam mirstīgajam. Sliktā ziņa: papildus pieredzei un, iespējams, arī kursiem, tomēr ir jāpamācās.

Informācija par to, cik % un kā jānoliek eksāmens, lai skaitītos sekmīgi, netiek publiskota. Beigās vai nu saņem Congratulations vai attiecīgi, nezinu ko, pieņemsim, Sorry vai Come back later.

Internetā esot dažādi BABOK mindmapi – ne es pirmā, ne pēdējā, kas kaut ko par šo tēmu uzraksta, un daudzi pirms manis noteikti to ir izdarījuši daudz labāk par mani, bet, tā kā izlasīju to tad, kad jau bija atstrādāti savējie paņēmieni, nemaz neskatījos, lai nejauktu galvu. Iespējams, ka tie ir par maksu. Pameklējiet, kamēr jums nav sava.

Mācību māsterplāns

  1. mācībām atvēlēju 4 nedēļas (tāpēc, ka eksāmena simulācijas programma derēja 30 dienas) tieši pirms eksāmena
  2. otrdienās, ceturtdienās ņēmu pa 4 brīvām stundām, kuru laikā strādāju ar eksāmena simulācijas programmu. Uzstādīju mērķi sasniegt 95%.
  3. saplānoju pa dienām, kurās mācīšos kādus BABOK apgabalus – pa riņķi tam vismaz trīsreiz vajadzētu apiet, jo katru reizi pamani jaunas nianses.
  4. divas nedēļas pirms eksāmena sāku katru vakaru mājās ar pildspalvu uz atmiņu zīmēt tasku inputus un outputus. (Uz to pamudināja drilltests, kurā liela daļa jautājumu bija – kas ir taskam X ieejā… kas ir izejā… kuriem no šiem taskiem ieejā nav…)
  5. visu dienu pirms eksāmena paņēmu mācībām – izgāju pāris drillus, jau zināju savas vājākās vietas un tajā dienā mierīgi pārlasīju vietas, kurās jutos visnestabilāk.

BABOK. 8 nodaļas plus glosārijs. Sadalīju pa dienām un stundām, kad kuras nodaļas lasīšu. Tehniku nodaļu labāk sadalīt gabaliņos un katru dienu izlasīt par pāris tehnikām padziļināti, nekā vienā dienā skriet cauri visām 34.

Lasot meklēju analoģijas ar savu darba ikdienu. Piemēram, „Validate Solution” ir tipiskākā akcepttestēšana, kāda vien var būt. Loģiski, ka par prasību pārvaldīšanas pieeju un paņēmieniem vienojas sākumā. „Requirements package” – brīnišķīga PPS. U.tml.

Zaurēšana

Tomēr domāšana līdzi neglāba no nepieciešamības zināt pašu BABOK, kā iebiedēja drilltests, kurā daudz prasīja arī pavisam formālas lietas. Sāku ar Knowledge Area abreviatūru PMERMCEA RASAV (jūtos kā Harijs Poters, kurš murmina – Lidiooosa”) un atbilstošā secībā tasku skaitu katram 645566.

Business Analysis Planning & Monitoring

Elicitation

Requirements Management & Communication

Enterprise Analysis

Requirements Analysis

Solution Assessment & Validation

Iemācījos katram taskus ar blakusmērķi – iemācīties tasku precīzu secību. Tas bija viegli, jo taski tiešām ir loģiskā secībā izkārtoti.

32 taski, 100 inputi

Tā kā man ir laba skaitļu atmiņa, iemācos kontrolsummas (sākumā palīdzēja melodiska to nodziedāšana :-) sevišķi sirsnīgi norūcot rindu, kura sākas ar 5)

334434  4712  42243  23344  532112  334424

Pirmā tik jauki pieaug un tad tai iztraucē. Otrā visstraujāk maina izliekumu. Trešā nedilst – ir palēciens aiz 22. Ceturtā virkne pieaug. Piektajai beigās ir glābšanas dienesta telefons un sākumā otrs lielākais kāpums. Pēdējā virkne gandrīz sakrīt ar pirmo. Nu kaut kā tā. Šīs virknes, šķiet, zināšu līdz pat pensijai.

Saliekot kopā, re, jau minibabociņš rokā.

334434 PM 6

4712 E 4

42243 RMC 5

23344 EA 5

532112 RA 6

334424 SAV 6

Nākamais solis bija atcerēties dažas sakarības.

PM blokā visiem inputā ir Asseti (pēdējam par assetiem var uzskatīt performances standartus).

E bloka sākumā trīsvienība – Case, Need, Scope.

EA blokā visiem inputā ir Business Need, izņemot pašam Business Needam.

Un vēl šādas tādas, kuras jums neko neizteiks, bet bija tādi kā atmiņas enkuri man.

Atviegloja tasku loģiskā secība un tādējādi varēja pārčekot pirms tam esošos taskus un atcerēties, ka tos vajag izmantot. Piemēram, jāatceras, ka tik cītīgi noteiktais Approach pēc tam jāizmanto.

BABOKā pie diagrammām ir arī apkopojums, kuri citi taski izmanto šo output, bet to gan nemācījos, tā kā ja zina, kas ir visiem inputā, attiecīgi zina arī, kurš ko izmanto.

Personalizēta haika

Vakaros ar pildspalvu uz atmiņu rakstot, atradu trīs vietas, kurās, par spīti visam, joprojām mēdzu kļūdīties. Šķita loģiski, ka Enterprise Architecture būtu daļa no Organizational Assets, bet taskos to nodala. Sacerēju tādu kā haiku

Kaparhitektūra SPA

Orgprassrss

Rediarhitektūras koncerti.

Kas man nozīmēja:

Assess Capability Gaps inputā ir Enterprise Arhitecture un Solution Performance Assessment

Organize Prasības Requirements inputā ir Asseti, Requirements un Solution Scope

Assess Organization Readiness inputā ir Enterprise Architecture un Concerns.

Šī visa rezultātā BABOKu arī tīri tehniski pārzināju. Atgādināšu, ka paliek spēkā nodaļu lasīšanas nepieciešamība, cītīgi domājot līdzi, jo iekalšana nelīdzēs, ja nebūs izpratnes.

Tips&tricks atbildot

Eksāmena simulācijas programma iemācīja pielāgoties jautājumu stilam. Tie ir ĻOTI rūpīgi jālasa. Atbildes ir āķīgi noformulētas. Reālajā eksāmenā divas atmest ir salīdzinoši viegli, savukārt starp pārējām divām ir ko padomāt. Dažām atšķiras tikai galotne kādam vārdam.

Tipiskākie manis pamanījumi:

  • Ja jautāts par vēlamo rīcību situācijā, jāizlasa, vai prasīta pirmā ieteicamā rīcība vai labākā ieteicamā rīcība. Tām ir pilnīgi dažādas atbildes.
  • Ja jautājumā prasīts kaut kas par izmantoto tehniku, tad nedrīkst iekrist un atbildēt ar uzdevumu, kurā to tehniku pielieto. Runājot līdzībās, ja jautā par sfērisku zirgu vakuumā – atbildi par sfērisku zirgu vakuumā, nevis ar viedokli par teorētisko fiziku! Tavu VIEDOKLI eksāmenā vispār nejautā neviens, samierinies.
  • Pastāv risks sajaukt uz atmiņu. Piemēram, prasīts, ko dara vienas analīzes (feasibility study) laikā, un ir smuka apaļa atbilde, kas atmiņā skaidri ataust, ka tāda, jā, jā, bija Babokā, tieši tādiem vārdiem. Un gribas to atzīmēt. Bet patiesībā… tā smukā atbilde būtu pareiza tad, ja jautājums būtu par citu analīzes veidu (benchmarking). Tajā pašā laikā īstais variants ir pārfrāzēts līdz nepazīšanai, vārdi aizstāti ar sinonīmiem.
  • Jāķer atslēgvārdi. Piemēram, līdzko parādās „user has to wait 5 sec”, tā skaidrs, performance un nefunkcionāla prasība. Ja jautāts par prasību izzināšanas paņēmienu un neuzkrītoši pieminēta izplatīšana, skaidrs, ka runa ir par anketēšanu, jo seminārus neizplata. Vai, ja cita starpā pieminēts, ka izpildes laikā prasību secība var tikt mainīta, skaidrs – runa par prasību prioritizēšanas uzdevumu.
  • Analītiķis nenosaka biznesu. Analītiķis analizē biznesu. To, kādi organizācijai ir mērķi – iekarot 50% tirgus daļu vai samazināt klientu vidējo gaidīšanas laiku pie telefona līdz 3 minūtēm, to nosaka uzņēmuma vadība. Analītiķis izjautā, pārliecinās un ka sapratis pareizi.
  • Jāmāk atšķirt desire no need. Piemēram, tas, ka cilvēks grib, lai specifikācijai ievadā kā pirmais teikums tiek ierakstīts Līguma numurs, ir vēlme. Vajadzība ir, teiksim, pierādīt, ka Līgums ir izpildīts, jo sagatavots tajā prasītais dokuments. Un tad BA strādā un domā, kādā veidā šo vajadzību nodrošināt. Varbūt pietiek, ja Līguma numuru norāda pavadvēstulē? Varbūt tieši otrādi, šis numurs ir tik būtisks, ka to vajag trekniem lieliem burtiem katrā specifikācijas lappusē?
  • Jāuzmanās nesajaukt BA darbus ar projekta pārvaldnieka darbiem, piemēram, projekta risku pārvaldība vai termiņu pagarināšana nav BA darbs. Ja atbilžu variantos parādās opcija jautāt kaut ko projekta vadītājam, tas ir drošs signāls, ka iespējams, tā arī ir. Līdzko skarts projekta (nevis analīzes) scope, budžets vai termiņi, tā noteikti tūlīt projekta vadītājs.
  • Savukārt prasību izzināšanas plānošana ir tīrs BA darbs un tajā projekta pārvaldnieka loma faktiski aprobežojas ar to, ka viņš iekopē BA sagatavoto plānu lielākā projekta plānā un nodrošina BA visu vajadzīgo darbam. Tas man bija pat tāds kā pārsteigums – BA autonomija BABOK izpratnē. 
  • Nevel vainu uz citiem. Ja jautā, kurš vainīgs, ka ieviestais risinājums nav tāds, ko klients gribēja, un viena no opcijām ir Business analyst, esi diezgan drošs, ka tā ir pareizā :-)
  • Nemēģini savu darbu uzgrūst citiem. Ja jautāts, kam jāizdara uzdevums, piemēram, kam jānodrošina, lai testētājam būtu informācija par akceptēšanas kritērijiem vai lai lietotāji saprastu, kāpēc būs jādarbina reizē vecā un jaunā sistēma, atkal – ja viena no opcijām ir Business analyst, esi diezgan drošs, ka tā ir pareizā. Tomēr – uzmanīgi. Operatoru atlaišana sakarā ar centrāles datorizāciju vai manuāļu nokopēšana un izdalīšana nav BA darbs.
  • Neliec citiem strādāt brīvdienās arī tad, ja TEV tas ir pašsaprotami (sak, ja vajag, tātad vajag). Ir jautājumi, ko darīsi, ja izrādās, ka nolīgtais piegādes termiņš ir piegādātāja valstī brīvdiena? Ir atbildes varianti arī, ka lūgsi strādāt, mēģināsi sarunāt pārcelt šo brīvdienu u.tml. Ja ir atbildes variants – novēlēšu priecīgus svētkus un cilpošu aprunāties ar projekta vadītāju – tas būs īstais.
  • Oi, kā var iekrist uz skaistiem jēdzieniem, kādu BABOKā vispār nav vai tie kā jēdzieni var eksistēt, tikai nav BABOKā: piemēram: traceability tracking, unified model, non-functional requirements modeling, logical thinking, predefined walkthrough u.c. Lai būtu jautrāk, tad īstais jēdziens savukārt noslēpts aiz sinonīma, kurš BABOKā kaut kur glosārijā aiz piektā komata pieminēts, ka daži to mēdz saukt arī tā.
  • Ja jautājuma formulējumā ir pateikts, ka cēloni atrast nevarēja (nevis – ka pagaidām vēl nav izdevies) un jautāts, ko darīt, tad atbildē nevajag atzīmēt to, kurā piedāvāts mēģināt pameklēt vēlreiz un rūpīgāk. Ir jāpieņem, ka ir sniegts fakts: nevarēja, un jāiesaka, piemēram, veidot manuālu workaroundu.
  • Terminoloģija un angļu valoda ir jāzina patiešām labi. Dažas atbildes nesapratu. Tad pārējie, saprotamie varianti, jāizvērtē trīstik rūpīgi, lai saprastu, vai likt uz tumšo zirdziņu. Vārdnīcu lietot nav atļauts. Uz sitiena atceros, ka nezināju, ko nozīmē “stalemate”. Jautājums bija, kurā situācijā analītiķim ir lietderīgi nākt klajā ar alternatīvu un jaunām idejām, un varianti – kad prasību autori konfliktē savā starpā, kad ir šis stalemate u.tml. Pēc pārējiem variantiem nojautu, ka tā varētu būt nekustēšanās no vietas.
  • Jāizvairās no atbildēm, kuras satur „always”, „never”, „must”.
  • Vecais labais teiciens, ka vecums nav arguments un jaunība nav trūkums (vai otrādi). Respektīvi, ir situācijas apraksts, ievadā apmēram: Lakšmi projektā prasību autori visi ir pārplēsušies savā starpā [..] vai Augstākā vadība pieprasījusi Martinam ārkārtas ziņojumu par analīzes progresu [..], un jautājums: kas tevi tajā dara bažīgu? Vismaz viens no variantiem būs “tas, ka X ir gados jauns analītiķis un bez pieredzes”. Šī atbilde noteikti nebūs pareizā. Pareizā būs, piemēram: iesaistīto pušu analīzes laikā nav līdz galam identificēti atslēgas cilvēki (key stakeholders) vai Business Case nesatur nodaļu par projekta ieguvumiem.
  • Ir (un vairāki) jautājumi no sērijas – kuriem taskiem inputā ir outputs no taska X vai līdzīgā stilā – kuri taski nelieto inputā outputu no taska Y. Šeit līdz vai nu tikai iemācīšanās, vai visa pārējā tik laba zināšana un saprašana, ka var atļauties uz šiem jautājumiem riskēt ar mēģinājumu trāpīt uz izjūtu. Tāpat jau visu neiemācīsies, un ir psiholoģiski jāatļauj sev kaut ko arī nezināt. Piebildīšu, ka eksāmenā, atšķirībā no drilltesta, šādu jautājumu ir krietni mazāk.

Kopumā – tas bija manī pašā radies mīts, ka BABOK ir kaut kas no sfēriska zirga pārlidojumiem starp galaktikām. Patiesībā BABOK satur to, kas analītiķim jau ir asinīs, tikai – jāmāk saskatīt un pazīt. Es iemācījos :-) turu īkšķus par jums!

Advertisements

One response to this post.

  1. Posted by Leo on 12/11/2013 at 15:29

    Kolosāls rakstiņš, paldies autoram par pūlēm! (ceru, ka sertifikācijas autori to nelasīs, lai vēl vairāk nesarežģītu jautājumus ;)).

    Like

    Atbildēt

Mans viedoklis:

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Mainīt )

Twitter picture

You are commenting using your Twitter account. Log Out / Mainīt )

Facebook photo

You are commenting using your Facebook account. Log Out / Mainīt )

Google+ photo

You are commenting using your Google+ account. Log Out / Mainīt )

Connecting to %s

%d bloggers like this: