Noliktavas strādniekiem – pienu par kaitīgu darbu

Manuprāt, analītiķim līdz darbam pie datu noliktavas ir jāizaug, jānobriest, jānogatavinās OLTP druvā. Datu noliktava – tas ir nopietni. Tie ir lēmumi, tās ir ekspektācijas (mārketinga saukļus gan jau kādu zināt), tas ir izdarīt varen sarežģītu darbu, lai cik gudru grāmatu un visādu blogu :) būtu sarakstīts ar padomiem. Tāpat noliktavas strādnieka dienišķais būt vai nebūt: labot datus noliktavā vai gulties uz ambrazūras cīņā par labākiem avotiem?

 

Programmētāji zina – lai atrastu bagu, ir jāmāk domāt kā bags domā. Tā nu es te pārfrāzējot saku, ka DN analītiķiem pirms DN jāapēd puds sāls avota sistēmās. Jāsaprot, ko, kā un kāpēc dara avotu cilvēki, kādi grābekļi, kāds viņu domu gājiens. Ko tur liegties, pašai kā bumerangs ir situsi OLTP sistēmu izstrādātāju nepadomāšana tālāk par savu pagalmu. Neizdarāmu lietu jau parasti nav. Tikai vairāk laiku un izdomu prasa.

 

Jo vairāk runās, jo lielākā iespēja, ka noliktavas strādniekus sadzirdēs. Pielikšu atrunu, ka, protams, ir uzņēmumi, kur par šo jau tagad tiek nopietni domāts. Šeit rakstītais kompilēts no dažādu analītiķu pieredzes, nozares mītiem un leģendām. Visi piemēri anonimizēti.

 

Ideālajā pasaulē DN vs OLTP problēma ir identificēta un OLTP cilvēki ar DN cilvēkiem sadodas rokās un smaidīdami dodas uz kopīgu mērķi – vēl ideālāku pasauli. Visi zina, kādus datus un kā ņem uz DN, nosacījumi abās pusēs sakrīt, allaž savlaicīgi vienojas par izmaiņām, avota datu labošanas skripti vai nu nav nepieciešami, vai nu sakopj aiz sevis astes priekš DN, kā arī ir daudz jauku testa datu pēc pirmā pieprasījuma vai pat bez prasīšanas. Ļoti ceru, ka akurāt tā, kā pie jums.

 

Ne-ideālā pasaulē datu noliktavu cilvēkiem tik gludi neiet. Kāpēc eksistē arī neideāla paralēlā pasaule? Tāpēc, ka gadās:

 

*) avotiem un DN ir dažādi izstrādātāji (ar visām izrietošām birokrātijām),

 

*) nav cilvēka, kurš ir  ar vienu kāju avotā, ar otru noliktavā (ja būšana ir formāla, jēgas maz, bet parasti beidzas ar to, ka šo cilvēku viena no pusēm sāk arvien vairāk nodarbināt, līdz paņem pie sevis),

 

*) sistēmu izstrādei dažādi budžeti (un tad, kā saprotat, pingpongs),

 

*) avotu cilvēki ir līdz ausīm savos darbos (un, ja godīgi, nealkst rakņāties pa veciem sqliem, jo VIŅIEM viss strādā),

 

*) noliktava ieviesta ķeksīša pēc. Gala lietotāji tāpat turpina savus pirmsplūdu ekseļus, bet sākotnējais izstrādātājs piesedzās ar papīriem,

 

*) DN cilvēki izlutina lietotājus ar to, ka gan jau tiks galā, ko nu taisīt problēmu, kopš pasaulē ir izgudrota update komanda.

 

Daži gadījumi, kuros DN analītiķiem sirms mats klāt:

 

1) ja avots kādā brīdī nomaina lauka nozīmi – senāk rekins.nosutits “jā” bija ‘0’, bet kopš eiro ieviešanas “jā” kļuvis “1”. Dažreiz pat kurioza iemesla dēļ – jaunajam avota analītiķim sajuka, bet tad, kad atklāja, ka jau uztaisīts, tā arī palika.

 

2) ja lauka satura nozīme atšķiras dažādas situācijās. Ja līzinga gadījumā laukā “klients.adrese” ir pircēja adrese, bet kredīta gadījumā – galvotāja adrese. Papildus kādā specifiskā gadījumā, piemēram, ja nokavēti vairāk 3 maksājumi, tajā glabājas adrese, uz kuru sūtīts pirmais atgādinājums, bet ja nokavēti vairāk nekā 3, tad tā, uz kuru sūtīts jaunākais atgādinājums. Avota sistēmā cilvēki saliek ifus, notestē, kaut kādu daļu ieraksta izmaiņu projektējumā (kurš līdz ar citiem 376 maziem dokumentiņiem kaut kur glabājas), kaut ko koda komentāros, nodod un laimīgi aizmirst, avota formās adreses smuki salec pa laukiem. Pēc kāda laika datu noliktavu cilvēki mēģina saprast loģiku.

 

Žanra klasika ir avota sistēmu projektējumos šajā vietā frāze “tiks precizēts vēlāk” vai komentārs “Inokentijs ierakstīs”. Spoiler alert: Inokentijs tālēs zilajās.

 

DN tad rodas kaut kas līdzīgs šiem:

A) paņem uz DN kā “adrese” un ieraksta aprakstā a la “Kredīta gadījumā galvotāja adrese, citos gadījumos tas, kas aprakstīts avota dokumentācijā”. Lauks pārņemts, sirdsapziņa tīra, lai nu lietotāji paši tiek galā.

 

B) tiem, kuriem var atšķirt, izveido DN objektus a la “Līzinga ņēmēja adrese”, “Galvotāja adrese”, “Pārējās adreses”, un tad vai nu transformācijā vai pēcapstrādē, vai pārskatos sadala ar case ifiem.

 

C) DN cilvēki mistiskā veidā panāk, ka avots sakārto datus un ievieš pie sevis dažādus laukus. Vai vismaz iedod precīzus where nosacījumus.

 

D) variācija – DN cilvēki pēc labākās sirdsapziņas uztaisa. Tikmēr avota sistēmā atnāk jauns, strādīgs analītiķis un piekopj. Vienā brīdī kādam lietotājam rodas aizdomas, kāpēc kredītņēmēji tik bieži dzīvo turpat, kur galvotāji, un tad futbola sezonu var uzskatīt par atklātu.

 

3) izmaiņu atšķiršanas mehānisms. Jāpiekrīt, ka avota sistēmai ne vienmēr vajadzīgs. Uztaisa update vai fiziski padzēš. Bet DN pēc tam raķešzinātne jātaisa. Man personīgi tagad simpatizē, ja katrā avota tabulā katrai rindai ir pieejami ierakstīšanas un pēdējās koriģēšanas datumi, savukārt dzēstie ir atzīmēti kā loģiski dzēsti vai vismaz to atslēgas kaut kur uzskaitītas kā fiziski dzēstas.

 

4) avotu sistēmu datubāzes pusdokumentētas, pusaizmirstas īpatnības. Ir jauki, ja ir smuki, godīgi lauciņi un tabulas a la “darijums” ar klasificētu pazīmi, kredīts vai līzings. Vai atsevišķas tabulas “kredits”, “lizings”. Nav tik jauki, kad ir tabula “na_kustiba” ar laukiem paz1, paz2, paz3, paz4. Lien nu ārā no ādas, lai uzzinātu, ka kredīts ir tad, ja paz1=Z un paz3=9, bet līzings ja paz2=Y, paz3=4Q un nav aizpildīts paz4. Nu, ideju, cerams, sapratāt. Šis raksturīgs vecām sistēmām. Diemžēl gadās arī jaunākām, kuru izstrādātāji sapinušies meistarībā.

 

Šeit tomēr lūdzu paturēt prātā: mēs visi esam tikai cilvēki. Zinu reālu gadījumu, kur jaunpieņemtai augstas klases PLSQL programmētājai projekta cilvēki palūdza rakstīt vienkāršāku kodu. Jo viņa pabeigs darbu un aizies uz citu projektu, bet palicējiem būs jāsadzīvo ar tiem dinamiskajiem masīviem un citām grūti lasāmām konstrukcijām. Šī atziņa mani izmācīja, piemēram, likt nenorādīta datuma lookupam aizbāzni nevis … else ‘25000101’, bet kaut ko no sērijas … else to_char(to_date(’01-JAN-2500′,’DD-MON-YYYY),’YYYYMMDD’), jo otrajā gadījumā manuprāt ātrāk skaidrs, ka tas ir no aizbāžņa datuma izveidots identifikators.

 

Daži no jautājumiem, kurus labā pasaulē risina arhitekti un kvalitātes pārvaldnieki, bet, ja tas tā nav, tad DN analītiķiem galvas kūp:

 

1) Avota sistēmā dati, teiksim statusi (iesniegts, apstiprināts…) pēc idiem pielasās no dažādiem klasifikatoriem atkarībā no dokumenta tipa (ar nebūtiskām (?) niansēm – piemēram, kādam “apstiprināts” varētu saukties “pieņemts”. Bet var būt papildnianses, ka citam savukārt “apstiprināts” nozīmē pēc biznesa to pašu, ko vēl citam “iesniegts”)) – vai DN salikt vienā statusu dimensijas tabulā ar papildatribūtiem, vai pārņemt kā katram savu?

 

2) Ko darīt, ja avotā ir kļūdains risinājums, kurš netraucē avota sistēmai (lietotāji pieraduši vai nelieto to lauku)? Vai ja avota funkcionalitāte atšķiras no avota projektējuma? Kas tas ir? Bugs? Fīča? Todo? (šajā vietā atgādināšu, ka Inokentijs ir prom, bet Maija Saprātiņa, kurai to gabalu piešķīra, ir noslogota ar cita bloka iešanu produkcijā).

 

3) Ko darīt, ja, taisot ko citu, atrod kļūdu sen jau strādājošā DN gabalā? Teiksim, rakņājoties pa ETL, pamana, ka, pārņemot no rēķina preču aprakstus, sasien preces numuru ar apraksta numuru, rezultātā pirmajai precei ir piesaistīti visu rēķina preču pirmie apraksti, otrajai precei – visu preču otrie u.t.t. Kokteilis. Bet vai celt paniku, ja neviens nav sūdzējies? Ej nu zini, cik vietās un pārskatos šis jau iegājis un kā tur nokopts. Kurš metīs ar akmeni, ja DN analītiķis noklusēs, sak, pašam vēl nāksies labot, bet pietiek savā darāmā. Variācija – to taisīja Pēcis, negribas kašķēties. Apakšvariācija: par to atrašanu testētājiem algu maksā, lai viņi ziņo. Apakšapakšvariācija: negribas traucēt, jo varbūt kaut kādu nezināmu iemeslu dēļ tāda bija prasība.

 

4) Kurā vietā taisīt NVL, TRIM u.tml.? Avota datu atlases selektā? Transformācijas gabalā? Pēcapstrādē? Pirms iekļaušanas pārskatā? Vai tos likt visiem laukiem kā standartapstrādi pat tad, ja it kā nevajag?

 

5) Vai dublēt avota biznesa constraintus, teiksim, ka ievadē atļauti ‘1’, ‘2’, ‘3’, vai ņemt neanalizējot. Ir projekti, kuros taisa, lai transformācija izkrīt, ja ir ārpus diapazona. Ir, kur tādus samet speciālā tabulā izskatīšanai. Ir, kur pārņem un neliekas ne zinis. Ir tādi, kur notiek datu kvalitātes kontroles, piemēram, reizi nedēļā laiž kontrolselektu, vai DN nav parādījušies dati ārpus ‘1’, ‘2’, ‘3’. Bet – šādi kontrolselekti ir jāizdomā, jāievieš, jāuztur (!!!!!!!). Un jāzina, kā rīkoties, ja atradīsies ieraksti ar citām vērtībām. Kā saka viens mans draugs, pieredzējis analītiķis, – “nevajag meklēt kļūdu, ja nav zināms, ko ar to iesākt”.

 

Kā ietaupīt uz sirmo matu krāsošanu?

Datu noliktavu darba sludinājumos goda vietā ir KOMUNIKABILITĀTE un analītiskās prasmes. Pamatoti. Lai gan ceru, ka pārskatāmā nākotnē arvien vairāk uzņēmumos tiks šīs lietas sakārtotas, lai DN cilvēku komunikabilitātei (lasiet: ja pats mācēs sarunāt, tad (un tikai tad) dabūs korektus avota datus) tomēr nebūtu izšķirošā nozīme, bet avota sistēmu cilvēkiem informācijas sniegšana priekš DN projekta cilvēkiem būs parasts, plānots un kontrolēts darba uzdevums.

 

Tur, kur vēl ir ceļā uz to, manuprāt DN cilvēkiem ir vērts pārzināt,  saprast avota sistēmas datu struktūras un funkcionalitāti. Jo realitāte mēdz būt tāda, ka dokumentācija vairāk nebūs, nekā būs, izstrādātājiem nebūs ne laika, ne vēlēšanās iedziļināties, savukārt iespēja tikt pie pilnīgākās dokumentācijas pasaulē – avota IS izejas koda ir 1) reti kad iespējams luksuss, 2) ne jau vienmēr to kodu DN cilvēks prot brīvi lasīt.

 

Mana pieeja – ja iespējams, atrast veidu, kā padarbināt avota sistēmu, redzēt un pastrādāt, kā dati rodas, kā notiek viss process. Piemēram, ja uz datu noliktavu pārņemami izrakstīto rēķinu dati, tad kā tie rodas, kāds ir to dzīves cikls. Pie reizes jēdzieni kļūs saprotamāki. Ideāli, ja ir pieeja visai dokumentācijai, t.sk. vēsturiskajai. Lasot, kā laikā gaitā sistēmas evolucionējušas, var labāk saprast fonu, problēmas, vājās vietas. Ja ir iespēja ar SQL pie avota bāzes tikt – ņamma!

 

Papildu tai fantastiskajai brīvības sajūtai (kura DN cilvēkam ir, ja māk un tiek klāt rakstīt visādus biznesa selektus avota IS) būs arī priekšstats par DN testēšanu, jo viens no veidiem ir, ka lietotāji atver vienu dokumentu vai sarakstu abās sistēmās un salīdzina. Man ir pieredze, kā lietotājiem patika dokumenti, kurā detaļās, ar attēliem un bultiņām aprakstīts, kuri lauciņi no avota sistēmas formām un sarakstiem atbilst kuriem datu noliktavā. Piemēram, nosaukumi atšķiras (objektīvu iemeslu dēļ, jo var gadīties, ka sen jau jaunas veidlapas, bet vecajā sistēmā nemaina un visi pieraduši, ka laukā “adrese” ir personas kods), taču jaunajos projektos, t.sk. DN lieto jaunos nosaukumus.

 

Nobeigumā vispārināts ieteikums: pirms nosodīt (ja vispār ko tādu darīt), pacensties izprast domu gājienu. Ir bijis, ka sarunu sāc ar “kurš idiots ko tādu izdomāja”, bet pabeidz jau ar “kāds interesants un attapīgs risinājums”! :)

 

PL SQL developer sertifikācijas atmiņu stāsts

Programmēšanas eksāmenos velns ir detaļās (vs lomu sertifikācijās velns ir jēdzienos). Lai iegūtu Oracle PL/SQL Developer Certified Associate sertifikātu, nokārtoju divus eksāmenus –

• Oracle Database: SQL Fundamentals I
• Program with PL/SQL.

Abi ir darba ikdienas sastāvdaļa, jo lielos valsts mēroga projektos sistēmanalītiķis nereti ir cilvēks – orķestris, kam tabulu, vaicājumu, apdeitu, skatu, procedūru un trigeru diriģēšana ir ikdiena – Informix, Oracle, MS SQL, Sybase… It kā jau SQL arī Āfrikā ir SQL, tomēr apaudzēts ar fīčām un nav viegli tā uzreiz atcerēties, kurā DBVS varchar2 noteikti jānorāda minimālais garums, kurā pēc noklusēšanas ir 1 un kurā tāda varchar2 vispār nav.

Tātad, lai dokumentāli apliecinātu zināšanas, raitā tempā jādemonstrē kompilatora prasme. ~1.5 min uz jautājumu – jāizlasa, jāsaprot, parasti satur 4 atbilžu variantus, kas katra ir citāda funkciju virkne. Līdz ar to dot slēdzienu par vienu virkni ir ~20 sekundes laika. Jo ātrāk mācēsi noskanēt virkni uz tipiskām kļūdu ķeramvietām, jo vairāk laika paliks pētīt aizdomīgi pareizās:

• Vai strādās select lower(replace(trim(‘son’ from cust_last_name),’An’,’O’)) from customers?
• Kas notiek, kad izpilda select initcap(cust_first_name||’’||upper(substr(cust_city,-length(cust_city),2))) from customers?
• Vai to_number(to_number(prod_price,’$99,999.99’)*.25,’$99,999.00’) atgriezīs $6,509.75?
• Vai select lpad(substr(cust_name,instr.(cust_name,’’)),length(cust_name)-instr(cust_name,’’),’*’) from customers where instr.(cust_name,’’,-1,2)<>0 atlasīs tikai tādus klientus, kuriem ir 3 vārdi?
• Vai no sysdate var atņemt pī?

Un tā tālāk. Nācās atsvaidzināt teoriju. Iesaku Ginta Plivnas blogu – izcili mācību materiāli!!!, lasīju, uzslēdzu smadzenes uz mazkompilatora režīmu (nost ar zinātniskās bakstīšanas metodi “hmm, nez, šitāds kompilēsies?” un “tad jau piečibinās, ja šitas neatgriež”), un izvirzīju mērķi uzreiz uzrakstīt pareizi, zīmēju Venna diagrammas uz papīra.

Tehniskie izaicinājumi

Ja lieta ir gadiem lietota, tad lielos tramvajos jau aiziešana līdz eksāmena telpai ir 3/4 no uzvaras. Tomēr izgulēties uz lauriem eksāmenos nevar:

• Pieraksta izvirtības uz LV neierastiem formātiem – sākot ar tiem $1,234.67, turpinot October 25th DD-MON-RR un visbeidzot AM un PM. Nācās mācīties tos $99G99D00, $9,999V99, fxDay, fmDdspth…
• Ne visas funkcijas no eksāmena tvēruma ikdienā lietoju, tāpēc mācījos (kā, piemēram, coalesce), ko dara, argumentu skaits, obligātie, defaultie, kādi
• Argumentu vērtības un uzvedība. Piemēram, ja instr norāda negatīvu virknes garumu, tad izkritīs ar kļūdu, nevis uzskatīs par null, 0 vai 1. Atceroties šo, bija viegli ātri izslēgt pa kādam atbilžu variantam
• Funkciju virknes – vai, kā eksāmenā tādas mīl… nvl2(coalesce(decode(substr(instr(length(…. un variācijas, piemēram, – vai var joinot uz A = length(nvl(substr(coalesce(B,instr(A,1,2)),B),’null’))? uh, kādā tempā  eksāmenā nācās galvā šitos kompilēt :)
• Tipu konversijas, kur ir, kādas un kur nav pieļaujamas – decode, nvl, nvl2, kā arī ar tiem (to_number(to_date(to_char(… – ārpus eksāmena ar tiem palīdz F1 un gūgle
• Kas notiek ar NULLiem dažādās funkcijās (paldies, Gint!), vai var taisīt substr no null un vai nullif (1,null) ir tāds pats, kā nullif(null,1)? Ja concat pieliek null, vai viss rezultāts kļūst null?
• Aliasi kolonnām, joiniem, groupiem, orderiem un havingiem – kur var lietot, kur nevar, kur vajag, kur vienalga
• Ķer uz līdzīgām funkcijām – klasika ir months_between, days_between, years_between
• Daudz JOINu ar visa veida pierakstiem (+), OUTER, ķer uz USING un ON atšķirībām, uz aliasu izmantošanas niansēm

Mācību procesa izaicinājumi

• Internetā atrodami eksāmena jautājumiem līdzīgi piemēri ar nepareizām atbildēm, tāpēc vai nu jāpārbauda visas atbildes, vai svarīgi vismaz čuja līmenī mācēt nojaust, ka tā varētu nebūt pareiza. Es gandrīz visus piemēra jautājumus izspēlēju savā rotaļlaukumā – pētīju gan pareizo, gan nepareizos
• Sagūglētiem piemēriem nav atbilžu skaidrojuma. Pateikts, ka pareizā ir “B”, bet kāpēc? Variācija: rakstīts, ka pareizas ir vairākas (A,C,D…), lai gan eksāmenā pareizā var būt tikai viena. Nu tad jāsaprot, kur āķis. Forumos var atrast – lūdzu, paskaidrojiet, kāpēc… Bet ir daudz atbilžu no sērijas “kurš tad ir tāds idiots, ka neredz, ka pareizais protams ir B”
• Drilltests vietām ir pretrunā gan ar mācību materiāliem, gan praksi. Jau minētā varchar2 gadījumā – drillā pareizā atbilde skaitījās, ka tipa definīcijā var nenorādīt garumu, kamēr materiālos un praktiskajā Oracle krita ar kļūdu, ja nenorāda varchar2 garumu
• Nebija pieejama precīzi tāda vide, par kādu ir eksaminācija. Tajā, kuru es lietoju, piemēram, varēja kolonnu secību alterēt (līdz ar to prasti jāiegaumē, ka eksāmenā uz “vai var esošai tabulai nomainīt kolonnu secību?”, jāatbild “nē”)
• Drilltests, kuru dod BDA, ir vieglāks nekā reālais eksāmens. Par to parunāju arī ar BDA cilvēkiem, bet viņi jau neko ietekmēt nevar, tāds tas ir un alles. Tāpēc brīdinu – uz drillu vien nepaļaujieties

Sākumā gāja grūti ar kompilēšanu galvā – nepierasti tomēr. Centība rezultējās ar 91% (pietiktu ar 60% – slieksnis pazems, jo eksāmens IR ķēpīgs).

Notes from Business Analysis Conference Europe’2014

Luckily I had the pleasure to attend one of the most respected and awaited events in Business analyst community – Business Analysis Conference Europe’2014 as one of 416 attendees amongst delegates from UK, Germany, Malaysia, Switzerland, New Zealand, Ukraine and many other countries.

Just to fill you in some background of the audience – more than 370 BAs there – Principal, Lead, Senior, Team lead, Manager; a few nice job titles I noticed: Business analyst mentor, Managing Analyst, Principal Technologist, BA Resource Lead, IT Business analysis expert, Business Analyst Designer, Staff Business analyst, Mobile applications BA. That’s quite impressive BA density per square meter, isn’t it?

And last, but not least – three System analysts. Thanks, Canada and UK for not leaving me alone :) I did a small research and found out that this role has almost disappeared there. BA’s output usually goes to System/Enterprise/Technical architect as input, and architect collaborates with programmers. I believe we here in Latvia will experience the same soon.

Ok, moving on conference. It was a challenge to choose two-day road map when 5 tracks and 40+ interesting presentations there. The questions I had –

• Is business analysis rebrending itself towards system analysis?
• Is pretending to be agile really agile? If we have a meeting every day, are we using scrum?
• What are default values in business analysis nowadays?

So I attended 16 nice events and would like to share some of my impressions and notes. I’ve divided this entry into four main topics – Communications, Agile, Business analysis and life, Experience. First of all, let’s start with warming up. You’ll find answer later, if you are in doubt. Which is BA favorite answer?

• It’s out of scope
• Let’s have a meeting about that
• To be detailed later
• It depends
• This will be done automatically

Let me just touch on a BA manifesto I collected:

• Soft skills über alles. Everything else can be learned
• Communication – investment vs waste
• BA must have survival skills and stress management techniques (under pressure, stress etc)
• Know and do time management
• Set a goal – every week become a bit more skilled
• Ask questions! Great BA’s ask – WHY?
• Understand your values
• CARE ABOUT YOURSELF. No-one else will – you are a resource

Communication

It’s Not What You Say; it’s What’s Heard, Suzanne Robertson

• Everything is communication. It’s a lifelong challenge
• BA’s job is to move ideas from one thick skull to another: users, developers, management…
• Always invest time to align expectations, share mental model
• Avoid empty announcements, keep positive thread:
  • Flight delayed!
  • Flight delayed because of bad weather. We don’t know for how long but we will be back in 15 minutes to announce news

• Make noise free environment. Eliminate or at least reduce any
  • visual noise (too bright picture, rough wall…)
  • audial noise (phones, cars…)
  • kinesthetic noise (smell…)
• Put chairs straight, keep coffee hot, pencils sharp… or they’ll steal attention away
• If BA knows a formal modelling language, it is like knowing one more foreign language
• People write tougher than speak. Call!

 Information is beautiful, David McCandless, journalist

• Protect yourself and others from lies
• Single date is not truth. Provide context!
• $ 100 000 000 cut!!?? Is it a big deal?

Be creative! You have so many dimensions!

• Placement
• Colour
• Size
• Text
• Hierarchy
• Font
• Shape
• Motion

Animation–free from static world, Andrew Turner

• Visualize and animate requirements, events, scenarios
• A picture is worth a thousand words and one minute of video is equal to 8 million words
• 59% of executives would rather watch video than read text
• Viewers retain 95% of a message when they watch it in a video – compared to 10% when reading it in text
• Ideas when to use animation:
  • Data flow in diagrams
  • Process flow in models
  • Process before/after
  • Data transitions
  • Usability problems, solutions
  • To align expectations with assumptions

Agile

Has the relentless march toward Agile eliminated the need for Business Analysts? Andrew Jacques

• Software should be Agile unless there is a good reason to go Waterfall
• Waterfall projects can still use Agile techniques within stages
• A product owner will be involved full time, and ideally they will come from the business rather than IT
• We have docs, but it’s not a purpose
• Requirement management tools + documented code + documentation spread over requirements: f.e. JIRA attached user stories, mockups
• No «pick solution» thinking. We «buy-in» solutions
• Agile is not a way to reboot a bad team. Agile needs good team
• 3 week sprints motivates – everyone sees a real result
• Industry still has little experience maintaining agile projects

 Transition from Waterfall to Agile Tony Hanton, James Fitzgerald

• Agile is not a silver bullet
• Agile is a competency, not a methodology:
  • mindset, not template
  • culture, not methods
• It’s hard to be agile when the team doesn’t understand the business domain
• Short sprints motivate :)

Business analysis and life

The Business Analyst’s Identity Crisis Richard Shreeve, Consultancy director

Business analysis is increasingly blurred. While distinct roles yet, many of the same skills and competencies are required

Hints to survive:

• Standardize on a repository-based tool to promote the sharing and re-use of business, information, application and technology models
• Use frameworks
• Create templates
• Draw on existing models
• Search for best practices
• Use software for checking consistency etc.

Enhance your BA through UX! Yuri Vedenin

BA’s, please

• …live in user’s shoes, not process
• …start building more human centered products
• …care more about your users preparing mockups and scenarios

Thriving in a world of change Professor Eddie Obeng

When you were a child you saw a similar puzzle.  In THAT problem the lines were same length.  And you learnt the ‘correct answer’

Correct answers don’t live forever. Be aware of them.

World has changed.

By the way Professor suggests: do NOTHING of NO use!

Play! Georgiana Mannion

• «You can learn more about a person in an hour of play than you can from a lifetime of conversation»
• A game helps to get rid of teached answers
• The opposite of play isn’t work, it’s depression

A better way of working Lambert David

• ~5 meetings a day, 60% of our time on email – when did you have 3 h uninterrupted work?
• BA problem: no time to lift up your head and think…
• There IS a better way! Extract maximum from
  • Physical space
  • Technologies
  • Culture

Besides, it was interesting to learn about a company where everything is designed for BA’s to achieve maximum efficiency. Actually there is no better picture and I use my fast photo just to illustrate the idea:

• How it works there? A new project starts. Team gets it’s place. Stay, move – as your team or you wish. Where would you like work today? Go there! Find a place you feel best today or right now and work there. No reservations required, no limits set
• You are mobile. IT and data fully equipped everywhere, just plug in
• Various type of rooms for concentration
  • guaranteed silence, no other people movements near..
  • greenery, single chapels, meditation carpets, yoga…
• Different rooms for small/medium/large teams, different types for any team:
  • formal meetings, long whiteboard, interactive shared whiteboards, tables, chairs…
  • informal meetings, brainstorming, creative
  • leisure, eating, snacks, recreation, kitchens, free drinks, snacks, food
• Large open hub where all fit

Looking at the situation from a mortal’s view without having such a perfect office, what can we do TODAY?

• Don’t wait changes from top. Change yourself and you’ll have followers
• Change your environment. Make it nice, encouraging
• Never let environment to eat up you or suppress your talent. Never!!!
• Organize events
• Share problems, solve problems
• Provide feedback
• Smile, be positive and noticeable

Experiences

Can a BA add value to IS security project? Gillian Walton

• Traditionally the Information security team is too focused on physical security of devices and less focused on security of information itself….
• Through a partnership with security, business analysts can play a key role in ensuring adequate security controls are included in the systems requirements
• Lawfirm’s project; management is a sponsor
• Customers demand security
• ~6 months preparing, studying ISO/IEC 27001
• Business analyst : look at processes, document them and look no breaches possible
  • What to be protected?
  • Where are gaps?
  • Where are potential gaps?
  • Doubled, tripled data and process holders…
  • Communication channels…
  • Spreadsheets, printouts around, back and forth
• Create culture!
• that bunch was a hard nut but it was successfully moved to a new IS and later certified to ISO/IEC 27001

       – How do you know there are zero breaches?

       – I hope :) I know the processes and we did our best. Show people you DO care and do your best!

A Business Analyst Journey to a Lead Business Analyst  Isha Jain, UK IT Business Analyst of the Year ’2013

It was a totally amazing presentation! You are my stakeholders right now and I want to be sure that you step out of this room after achieving your objectives. Isha remembered every question (and name of the questioner) and got his or her confirmation after response.

When Isha started her carrier path as a business analyst, she had a lot of questions:

• What is the scope? Is it replacing system for 200 people across the department or is it more?
• What will business tell me as their requirements? Do I want to hear it?
  • System Problems?
  • Things they do in spreadsheets? (~100)?
• Will that give real Value to the programme?
• Can I be sure that the requirements will be the real business needs?
• Can I be confident that these requirements will eliminate all inefficiencies in the department and deliver real business benefits?
• Remember – people’s perception is built from how you position yourself

Naturally she was noticed and promoted. The next move was to define a BA role in the Company. I want a BA to:

• Find real requirements that give real value
• Document Requirements
• Write Business case
• Write an Investment proposal
• Create business process models
• Be bridge between business and IT
• Help developers to clarify requirements

I got authority -> people started to believe me -> people started to follow me

Before there were 7 branches and a lot of “irreplaceable” analysts. Isha was certainly sure it’s not a sustainable situation and her direction was to BA’s as a single entity (a pool). Now as a senior management Isha:

• Established framework – tools for req. management, templates, different workshop styles (200 people there)
• Created BA service catalogue to avoid people body shopping – provide services, not bodies!
• Recommends the best approach
• Leading IS and senior leaders through change
• Identifying best practices in the industry
• Provide services not just to project but to wider business
• Bringing visibility to BA Practice, mentoring BAs
• Maintains performance hubs – measure, improve
• Building Skills framework/Training catalogue

Some of Isha’s niceties:

• Think. Ask. Repeat as necessary :)
• Remember and answer questions. All questions. Always.
• Proud and happy doing my job
• Take time out to celebrate Success and Achievements

Now thank you for staying with my blog and, turning to the end of my notes, here come my findings:

• Is business analysis rebrending itself towards system analysis?
  • No – it takes over the most pleasant part of IT
• Is pretending to be agile really agile?
  • Seems yes… but not as dogma – great!
• What are default values in business analysis nowadays?
  • Communication, talented BAs, requirement management tools

And finally – the BA’s favorite answer : it depends!

Kas ir biznesa analītiķis un kam tas vajadzīgs? Bet sistēmanalītiķis?

Nesen atkal pārrunājām analītiķu asociācijā, ka nereti uzņēmēji, pasniedzēji, studenti īsti neizprot biznesa analīzes, arī sistēmanalīzes, pienesumu. Stereotips, ka vajadzīga tikai programmēšana, ir dzīvelīgs.

Grūti atbildēt pat gari, kur nu vēl īsi. Asociācijā mēģinām pēc iespējas īsāk un plašai auditorijai saprotamāk noformulēt, kas tas ir. Smagi iet… mēģinām ij ar santehniķu, ij ģimenes ārstu piemēriem…

Man tuvāka ir sistēmanalīze, esmu noformulējusi tādu kā reklāmsaukli: „ar mani komandā jūsu sistēma darīs to, ko jūs gribat, lai tā dara”. Varbūt biznesa analītiķim varētu šo adaptēt kā “ar mani komandā jūsu uzņēmums sasniegs to, ko jūs gribat, lai tas sasniedz”?

Biznesa analīze kā darbs neienāk prātā, nav motivācijas tai, BA pienākumi viltīgi ieslēpjas citos. Kas tad tur liels, vajag ieviest pašapkalpošanās portālu un e-rēķinus? Pasauksim programmētāju, uztaisīs. Jā, var paveikties un ir programmētāji, kam analīzes darbi ir asinīs kā tik pašsaprotami, ka ļauj ar lielu pārliecību sludināt– ne tāda analīze, ne analītiķi nav vajadzīgi, heh, piemirstot, ka tādi darbi patiesībā jau tiek darīti. Es jau nesaku, ka noteikti vajag atsevišķu lomu. Taču biznesa analīze pelnījusi būt saulītē, ne sētmalē.

Darba sludinājumos BA darbi mēdz slēpties zem citiem nosaukumiem – enterprise architect, consultant, solutions coordinator… Un otrādi, zem BA birkas samet visus darbus, kuri palikuši pāri. Lūk, piemērs diviem sludinājumiem ar tādu pašu amata nosaukumu:

Mans divcentu mēģinājums tantei Bauskā skaidrot, ar ko tie analītiķi atšķiras

Pieņemsim, ģimenes ārsta prakse laukos. Nodzeltējušas pacientu kartiņas plauktā pēc dzimšanas gadiem. Pa kreisi uz galda reģistrēšanas žurnāls, pa labi uz lapiņas sarakstīti tie, kuriem par potēšanu jāpiezvana.

Valdība paskatās – atkal tie igauņi mums priekšā. Steidzami vajag kaut ko izdomāt. Vajag datorizēties. Tā nu atnāk analītiķis, kuram jāuztaisa sistēma „Lauku ārsts v0.0.1.0.3.9.”

Ārste saka – man nav laika, re, kur mans palīgs, parunājieties.

Palīgs ir pavisam parasts, normāls cilvēks, zinoša mediķe, kundze pensijas gados, datora pieredzes nav.

Parasts biznesa analītiķis

Parasts analītiķis uzklausīs ārstes palīdzi un tā, kā viņa dara, arī sazīmēs modeli un sistēmas ideju. Kad jauns pacients, viņa sameklē plauktā starp veidlapām tukšu grāmatiņu, paskatās žurnālā, kāds pēdējais lietotais numurs, ieraksta uzvārdu, dzimšanas gadu, personas kodu…

Reizi mēnesī caurskata šajā mēnesī dzimušo kartiņas, lai atrastu, kuriem nav atzīmes par potēšanu. Izveido sarakstu un liek ķeksīšus pretī sazvanītajiem.

Analītiķis tā arī uzzīmē procesu, kā tas programmā notiks:

• Pacientu kartiņu ievade sākas ar to, ka no mapītes izvēlas sagatavi, tajā ievada brīvi izvēlētu numuru, ieraksta uzvārdu, pēc tam personas kodu, dzimšanas gadu…
• Potējamie: atlasām dzimušos periodā dd.mm.gggg – dd.mm.gggg un lapiņā „Potes” teksta laukā var redzēt, kādas ir, nav…

Labs biznesa analītiķis

Savukārt labs biznesa analītiķis uzklausīs, apdomās, sapratīs mērķi, sapratīs procesu, izdomās, kā vēl šo mērķi var sasniegt, spēs saprast, kādi datu vienumi ir nepieciešami, orientēsies tehnoloģiju iespējās, pamanīs procesa uzlabojumu variantus, papētīs, kā tas notiek citur. Arī datu līmenī sapratīs saites, validāciju iespējas, automatizācijas iespējas.

Pēc tam, kad izdomāts process, viņš/-a uzdizainēs sistēmu, lai tā atbalsta šo procesu.

Informācija par tiem, kuri maina ārstu, atnāks automātiski, visu veidu identifikatori ģenerēsies, potējamajiem automātiski tiks nosūtīts atgādinājuma epasts, pirms jauna pacienta reģistrācijas notiks pārbaude, vai tāds personas kods ir Iedzīvotāju reģistrā, vai nav paralēli reģistrēts citur… Ja zvana telefons ar atpazītu pacienta numuru, uz ekrāna parādīsies iespēja atvērt šī pacienta kartiņu, pierakstīties uz konsultāciju varēs arī prakses mājaslapā u.t.t.

Visticamāk, ka ārsta palīdze vispirms būs neapmierināta, tā kā tas maina ierasto, bet pēc lietošanas iepatiksies – tā vajadzētu būt, jo mums taču strādāja labais biznesa analītiķis :)

Sistēmanalītiķis

Savukārt sistēmanalītiķis jau zināmas prasības novedīs līdz lietošanai. Minētajā gadījumā visticamāk, ka viņš būs tas, kurš zīmēs konkrētās ekrānformas, pārskatus, uzprojektēs datu apmaiņu starp sistēmām, kā arī dos uzdevumus programmētājiem, testēs.

Cita piemēra gadījumā – pieņmsim (tfu tfu tfu), valdība nosaka jaunu PVN likmi un ievieš jaunu nodokli par valsts gaisa lietošanu. Sistēmanalītiķis nedomās, kāda ir patiesā vajadzība šādam nodoklim un vai var budžetu pildīt kā citādi.

Parasts sistēmanalītiķis

Pavisam parasts sistēmanalītiķis uztaisīs pie katra nodokļa lauciņu, kurā ierakstīt likmi, un pieliks ķeksīti, kur pie nodokļa ielikt lauciņā „par elpošanu”. Pēc tam katrā pārskatā, katrā apstrādē pieliks, ka gadījumā, ja šim nodoklim ķeksītis ir aizpildīts, tad…

Labs sistēmanalītiķis

Labs sistēmanalītiķis izdarīs tā, ka likmju klasifikatorā būs jauns ieraksts, kur PVNam automātiski no klasifikatora pēc perioda nolasīsies aktuālā likme. Tiks pievienots jauns ieraksts nodokļu grupu klasifikatorā un nodokļu klasifikatorā vajadzīgajiem tiks pievienota saite uz jauno gaisa nodokļu grupu.

Šeit iederētos Gojko Adzic citāts: Ja maza izmaiņa biznesā izraisa lielas izmaiņas programmatūrā, tad tā ir slikta sistēmas arhitektūra. Un arhitektūra atkal ir cits stāsts.

Kāda izcila biznesa analītiķa dzīves gājuma piemērs

Šeit vietā būs pieminēt nesen konferencē sastapto Isha Jain, UK IT Business Analyst of the Year ’2013 – izcila analītiķe, fascinējoša sieviete (starp citu, viņas māte esot latviete – Isha mani uzmeklēja, lai parunātos par Latviju).

Tēma bija A Business Analyst Journey to a Lead Business Analyst. Jau pats prezentācijas sākums bija iespaidīgs – ierodas vienkārša meitene kostīmiņā, it kā viena no mums, taču tā stāja, cieņpilns un vienlaikus pašpārliecināts smaids, un sāk ar to, ka – You are my stakeholders right now and I want to be sure that you step out of this room after achieving your objectives. Uzklausīja, ko vēlamies dzirdēt, pierakstīja uz tāfeles, un sekoja līdzi, lai tas tiek ne tikai pastāstīts, bet arī uzdevēji (atcerējās katra seju un vārdu) apstiprinātu, ka atbilde ir saņemta.

Isha sākusi kā analītiķe – ar jautājumiem. Vispirms sev:

• What is the scope? Is it replacing system for 200 people across the department or is it more?
• What will business tell me as their requirements? Do I want to hear it?
  • System Problems?
  • Things they do in spreadsheets? (~100)?
• Will that give real Value to the programme?
• Can I be sure that the requirements will be the real business needs?
• Can I be confident that these requirements will eliminate all inefficiencies in the department and deliver real business benefits?
• Remember – people’s perception is built from how you position yourself

Likumsakarīgi Isha tika ātri vien pamanīta un paaugstināta. Nu jau viņa ķērās klāt BA lomas definēšanai:

I want a BA to:

• Find real requirements that give real value
• Document Requirements
• Write Business case
• Write an Investment proposal
• Create business process models
• Be bridge between business and IT
• Help developers to clarify requirements

I got authority -> people started to believe me -> people started to follow me

Kad Isha pārņēma BA virziena vadību, National Grid uzņēmumā bija 7 virzieni (gāze, elektrība u.tml.), katrā „neaizstājami” analītiķi. Viņa saprata, ka tas nav veselīgs modelis, izveidoja analītiķu “pakalpojumus”, un ieviesa analītiķu rotāciju – BA’s as a single entity (a pool).

Šobrīd Isha ir BA senior management:

• Established framework – tools for req. management, templates, different workshop styles (200 people there)
• Created BA service catalogue to avoid people body shopping – provide services, not bodies!
• Recommends the best approach
• Leading IS and senior leaders through change
• Identifying best practices in the industry
• Provide services not just to project but to wider business
• Bringing visibility to BA Practice, mentoring BAs
• Maintains performance hubs – measure, improve
• Building Skills framework/Training catalogue

Ko viņa iesaka un pati ar savu piemēru konferencē rādīja:

• Think. Ask. Repeat as necessary :)
• Remember and answer questions. All questions. Always.
• Proud and happy doing my job
• Take time out to celebrate Success and Achievements

Lūk. Tieši tik vienkārši :) :)

23.05.2014 Analītiķu brokastu “minūtītes” : OMG OCEB 2 sertifikācija

2014. gada  23. maijā piedalījos BDA rīkotajās Biznesa analītiķu brokastīs. Kā jau zināms, bezmaksas brokastu nav un patiesībā šis bija labi noorganizēts veids, kā savākt analītiķus un pastāstīt viņiem, ka sākot ar šīgada rudeni BDA būs pieejamas apmācības un sertifikācija OMG OCEB 2 Fundamentals jeb Object Management Group Certified Expert in BPM 2™ pēc BPMN 2 notācijas. Semināru vadīja Gundega Lazdāne, BDA pasniedzēja un FMS Biznesa analīzes grupa vadītāja.

Sertifikācijai kopā ir trīs līmeņi – Fundamentals (par to ir šis stāsts), Intermediate (ar laiku arī šo varēšot BDA apgūt), Advanced. Pirmā grupa mācīsies ~24. – 26. septembrī, izmaksas varētu būt kā par 3 dienu BDA kursiem + eksāmens (nu, piemetu uz aci pēc www.bda.lv izcenojumiem, ka ~600-800 EUR).

Mērķauditorija: analītiķi – gan biznesa, gan sistēmanalītiķi.

Gala ieguvums, kādu es saskatīju – prasme un motivācija zīmēt BPMN diagrammas un, iespējams, ar laiku gan PPA papīru kalnus daļēji aizstāt ar tām, gan pašam sastrukturēt pieeju, gan savā starpā komunikācijā izmantot. Kolēģi no liela IT uzņēmuma seminārā teica, ka sākumā lietojuši kā skices paši savai saprašanai, sākuši rādīt klientam, ātri vien klienti paši sākuši pieprasīt, un tagad arī testētājiem un programmētājiem darba uzdevumi tiekot pārvaldīti caur BPMN: procesi, sadarbība, saruna, horeogrāfija (process, collaboration, conversations, choreography), jeb vienkāršāk izsakoties – vizuāli diagrammā apraksta, kādas aktivitātes kādā secībā un pie kādiem nosacījumiem notiek, kā savstarpēji mijiedarbojas un kā tiek koordinēta sadarbība.

Starp citu, pilnīgi legāla atbilde uz jautājumu – kam tāds BPMN vispār vajadzīgs? – ir arī šī: tas palīdz man kā analītiķim saprast un aprakstīt procesus.

OMG šoreiz nav Oh My God! :-), bet gan jau būs, kad sākšu pa īstam mācīties.

Rīki, ar ko dalībnieki darbā zīmē, tika minēti gan bezmaksas, gan maksas: QPR,  SPARX Enterprise Architect, Bonita, MS Visio.

Par eksāmenu (raksta beigās ir ar Gundegas laipnu atļauju pielikti daži iespējamu jautājumu piemēri)

Šim eksāmenam (atšķirībā no CBAP u.tml) nav priekšnosacījumu – nevajag apmācību punktus, pieredzi u.tml. Samaksā un kārto. Pagaidām nav zināms, vai būs nepieciešama resertifikācija, bet paskatījos, ka dažiem citiem līdzīgiem ir ik pa 3 gadiem.

Tests, 90 jautājumi. Lai nokārtotu, jāatbild uz 62. Laiks – 120 minūtes (jo angliski un mēs neesam angļi. Angļiem ir 90).

 Eksāmena % sadalījums:

• 40% – BPMN notācijas zināšanas – ko nozīmē kurš elements, kā raksta scenārijus, kā veidojas modelis u.tml.
• 15% ir par BMM jeb Business Motivation modeling – stratēģiskā domāšana, vīzija, misija, taktika. Jebkas, ko uzņēmumā darām, ir attiecināms (saistīts) ar kādu augstāku mērķi, kā to nodrošināt.
• 30 % – pamatzināšanas, pamatjēdzieni, kā arī – kas ir biznesa procesi, kā veidojas organizācija, kā rodas un veidojas procesi, apakšprocesi, darbības principi, plūsmas
• 15% – augstā (virspusējā) līmenī – pārvaldības ietvari, kvalitāte, mērījumi

Domāšana

Vairākkārt tika runāts, ka šīs nav „plikas zīmēšanas” apmācības, bet ir vairāk – domāšana, pieeja, attieksme. Visam pamatā ir mērķis, uzņēmuma mērķa esamība un virzība uz to ir uzņēmuma brieduma indikators. Izslēdzam pieeju ”daru šito tāpēc, ka man tas jādara”. Tā vietā: „daru tāpēc, ka tā sasniedzu mērķi X”. Skaidri saprotams, kāds process, kas to sāk, kas beidz, ko dara, kāds rezultāts, kādi nosacījumi.

Subjektīvā daļa – vai es to gribu?

Pašlaik nezinu. Ohohoo, protams, patiktu pamosties ar šīm zināšanām (un sertifikātu :-) ), bet šobrīd kārtoju Oracle programmēšanas sertifikāciju, tāpēc par šo padomāšu ne gluži rīt, bet nākamgad. Diagrammas zīmēju, bet jāatzīst, tās ir stipri vienkāršas, salīdzinot ar BPMN 2.

Ko pavisam noteikti varu apgalvot: brīdī, kad man BPMN ieinteresēs pa īstam, es iešu uz šiem kursiem, jo BMPN 2 standarts uz 508 lapām ir, piedodiet autori, bet miega zāļu piesātināts. Tāpēc labāks veids, kā to apgūt, būs kursi un ikdienas lietošana.

Caurskrienot BPMN 2 – bildītēs

Notācija ir ļoti bagāta – daži piemēri (vairākas no šīm es nezināju) – nokopēju no sagūglētiem slaidiem par BPMN 2 tutorial:

Diagrammu piemēri:

 

 

Horeogrāfijas piemērs (arī nokopēju no sagūglētiem slaidiem par BPMN 2 tutorial)

Eksāmena jautājumu piemēri

 

 

Jautājums uz ribas – lēns selekts, ko nu?

Ir šāda datu bāze (pieraksts nosacītā sintaksē):

Abonents (AbonentsNr int, Vards varchar(20), Uzvards varchar(20)) primary key (AbonentsNr);
Izdevums (IzdevumsNr int, Nosaukums varvhar(255), Tematika varchar(50)) primary key (IzdevumsNr);
Abonements (AbonementsNr int, AbonentsNr int, IzdevumsNr int, DatumsNo date, DatumsLidz date) primary key (AbonementsNr), foreign key (IzdevumsNr) references Izdevums (IzdevumsNr), foreign key (AbonentsNr) references Abonents (AbonentsNr)

Abonents 100 000 ierakstu, Izdevums 100 ierakstu, Abonements 500 000 ierakstu.

Sistēma izpilda SQL pieprasījumu:

SELECT * FROM Abonents WHERE AbonentsNr in (SELECT AbonentsNr From Abonements, Izdevums WHERE Abonements.IzdevumsNr = Izdevums.IzdevumsNr AND Izdevums.Tematika=”Lauksaimniecība”)

Pieprasījums izpildās lēni. Ko nu?

P.S. šis raksts nav tāpēc, ka personīgi man būtu problēmas atrisināt šāda veida uzdevumus. Vienkārši – interesē, kādus risinājumus komentāros piedāvās lasītāji.

Un šeit ir manas solītās pārdomas (pievienotas 13.01.2012) – kāds būtu mans domu gājiens.

1) indeksi (sk. Jāņa komentāru zemāk). Iemesls, kāpēc kā pirmo lieku indeksus, nevis acīmredzami nepieciešamo selekta optimizēšanu, ir šāds: lai uztaisītu vienkāršu indeksu, nevajag ne daudz prāta, ne daudz laika, tāpēc šis ir risinājums – aizbāznis, kurš var atvieglot dzīvi ĀTRI.

2) selekta optimizēšana. Daži no komentāros minētajiem variantiem (Gatis, Kaspars, Jānis) ir tīri ok.

select distinct a.*
from Izdevums i
inner join Abonements ab on ab.IzdevumsNr = i.IzdevumsNr
inner join Abonents a on a.AbonentsNr = ab.AbonentsNr
where Izdevums.Tematika = ”Lauksaimniecība”

Un ātri izdarāmais:

… WHERE AbonentsNr in (SELECT AbonentsNr From … )” vietā rakstīt WHERE EXISTS (SELECT … ). Jo ar EXISTS tiek meklēts pirmais ieraksts, kas atbilst kritērijam, kamēr ar AbonentsNr in … vispirms ir jāatlasa visi ieraksti, kas atbilst tam.

Arī šis Jāņa man patika:

Uztaisi klasifikatoru “Tematika”, un Izdevums.Tematika aizvieto ar Izdevums.TematikaNr, kuru taisi par foreign.key. Rezultātā nemeklē pēc teksta ”Lauksaimniecība”, bet pēc iepriekš atlasīta Tematika.Nr.

Un Jāņa doma par materializēto skatu.

2 ar pusi) tabulas iespējamā pārslodze – varbūt tajā ir neaktuāli dati, kurus vienreiz vajag aizarhivēt prom, un varbūt vajag padomāt par informācijas dalīšanu pa vairākām tabulām, piemēram, līdzko pienācis DatumsLidz, tā ieraksts ar kāda procesa palīdzību tiek automātiski pārnests uz vēsturisko datu tabulu.

2 ar trim ceturtdaļām): pārliecināt klientu, ka viņam patiesībā šāda vaicājuma rezultātu nemaz nevajag :-) :-) :-) (reveranss Gintam)

3) servera jauda – atmiņa, ātrums, kāds ir, ko var uzlabot?

3 ar pusi) pārbaudīt, kāds ir datu pārsūtīšanas ātrums savienojumā + datu attēlošanas uz ekrāna ātrums. Varbūt pats selekts izpildās ātri, taču problēma ir tur, ka tehnika rada sajūtu, ka tas izpildās lēni?

3 ar trim ceturtdaļām) izvietot tabulas uz dažādiem diskiem, tādējādi paātrinot fizisko nolasīšanu. Jā, šāds risinājums vairāk ir apsverams lielākiem datu apjomiem, taču kā variantu pieminu.

 4) datubāzes iespējamā pārslodze – izvērtēt iespēju samazināt datu apjomu vai pieprasījumu apjomu citās tabulās.

4 ar pusi) Ja esošā DBVS, par spīti veiktajiem pasākumiem ir par vāju, domāt par iespēju apstrādāt datus ar jaudīgāku DBVS.

Par iesūtītajiem komentāriem – sirsnīgs paldies visiem, kuri atsaucāties. Godīgi – mani sajūsmināja doma, ka par tabulas primāro atslēgu miera vējos tiek pieļauta iespēja, ka tā varētu būt telefona numurs :-). Un arī otrādi – ka lauku AbonentsNr int primarykey – var izlasīt kā telefona numuru ne brīdi nenošauboties :-) Mācība priekš manis: citreiz piemēros saukt par Id, nevis Nr. Izlasīju un pasmaidīju, ka dažreiz sistēmanalītiķis не читатель, sistēmanalītiķis писатель. Viens otrs komentārs atgādināja pasaki man savu problēmu  un es pateikšu, kāpēc tā nav atrisināma.

Lielākā daļa komentāru bija par paša selekta optimizēšanu vien, nepiesaucot iespējamos ārējos apstākļus. Ja šis būtu eksāmens, es teiktu – draugi, izkāpsim ārpus kastītes! Bet šis nebija eksāmens. Ceru, ka arī jums bija interesanti. Oficiālāku literatūru par dažādām optimizēšanām gūglējiet paši – papilnam.

Īsa pamācība problēmu ziņošanā

Katrā jokā ir daļa joka. Arī šajā:  Новое телешоу: «Битва IT-экстрасенсов» – IT-шники проникают в головы юзерам и угадывают, что они нажали и почему “ничего не работает”

Retorisks jautājums: ko lai dara IT atbalsts (nereti tas ir sistēmanalītiķis), saņemot šādas sūdzības?

• nevaru ieiet ministrijā! (nestrādāja ministrijas mājaslapa)
• nekas nestrādā! (drukāšanas spiedpoga nepieejama)
• es neko nedarīju, bet neko nevaru padarīt! (lietotājvārda un paroles lauciņus bija sajaucis vietām)

Sūdzībām par IT kļūdām vai nepilnībām ir divi iemesli:

a)      cilvēks vēlas atvest dvēseli – tad var tālāk šo nelasīt un turpināt kaitināt mūs ar saviem „nekas neiet!”. Bez šaubām, arī šada atgriezeniskā saite ir vairāk kā nekas un ir iemesls aizdomāties.

b)      cilvēks vēlas saņemt palīdzību vai risinājumu. Tālākā tekstā daži ieteikumi, kā to sasniegt. Ceru, ka komentāros padalīsieties ar savu pieredzi par to, kādus problēmziņojumus patīk un kādus nepatīk sūtīt/saņemt, lai mums šeit ir kas vairāk par manu subjektīvo viedokli.

1. Norādīt programmu un versiju.
2. Soli pa solim aprakstīt veiktās darbības, lietojot tādus nosaukumus, kādi ir programmā. Uzrakstīt, kurā laukā un kādus datus ievadīja un kad ko nospieda.
3. Kļūdu ziņojumus citēt, nevis tēlaini pārstāstīt un interpretēt. Ideālā gadījumā – pievienot ekrāna attēlu. Šeit arī mans aicinājums visiem, kuri problēmas pieteikumu nodrošina webformā: nodrošināt iespēju pievienot failu ar attēlu! Vēlams, lai papildus kļūdas ziņojumam attēlā ir redzama programmas versija, pārlūkprogrammas adrese (ja ar pārlūkprogrammu darbina), pulksteņlaiks. Personīgus konkrētus datus drīkst aizkrāsot. Ja tie dati ir tādi pavisam personīgi, tos pat vajag aizkrāsot – lai gan IT speciālistus parasti saista ļoti nopietnas konfidencialitātes saistības un arī darba ētika nepieļauj izpaust darba informāciju, tomēr pašā sūtīšanas procesā uz e-pastu vai mazums kas var gadīties.
4. Norādīt, vai problēma ir atkārtojama. Ja ir informācija, kad problēma pirmo reizi parādījās vai kad tās vēl nebija – norādīt arī to.
5. Ja ir – sniegt savus ieteikumus vai aprakstīt savu vēlmi, ko sagaida no IT atbalsta. Acīmredzamu kļūdu gadījumā, protams, skaidrs, ka sagaida problēmas novēršanu, taču tādi acīmredzamu kļūdu tīrradņi ir retāki nekā situācijas, kur lietotājam šķiet, ka ir uztaisīts nepareizi. Var gadīties, ka IT cilvēki negribēs uzsākt spēlīti „mēģināsim uzminēt, ko no mums īsti grib”.
6. Izmantotā pārlūkprogramma (ja ar pārlūkprogrammu darbina).
7. Norādīt, vai problēma pastāv, ja veic līdzīgas darbības ar citiem datiem (ja, piemēram, nevar saglabāt viena veida dokumentu, vai izdodas saglabāt cita veida dokumentu? Kāda?)
8. Norādīt, vai problēma pastāv, ja cits lietotājs no šī paša datora pieslēdzas un veic minētās darbības.
9. Norādīt, vai problēma pastāv, ja pats pieslēdzas no cita datora ar to pašu lietotāja vārdu un paroli.
10. Norādīt savu kontaktinformāciju  un ļaut noprast, vai precizējoši jautājumi tiek laipni gaidīti :-)

Nevēlams piemērs:

Pēc saglabāšanas saņēmu kļūdu ka it kā neesot pareizi sarēķināts – tas nav taisnība!

Labāks piemērs:

1. Pieslēdzos sistēmai X, versija 1.2.33.
2. Izvēlnē „Sākt ievadi” izvēlējos veidot jaunu dokumentu „Dokumenta nosaukums” un ieliku ķeksīti pie „veidošu tiešsaistē”.
3. Atvērās ievadforma. Laukā A ievadīju 5, B ievadīju 2, C ievadīju 10, D atzīmēju radiopogu „Bez PVN”.
4. Nospiedu pogu [Saglabāt]. Parādījās kļūdas ziņojums „Laukā C norādītā vērtība neatbilst formulai A*B”.
5. Problēma ir atkārtojama, kad veicu šīs pašas darbības vēlreiz.
6. Izmantoju pārlūkprogrammu MS Internet Exprorer 8.0.123. Problēma ir atkārtojama arī ar Mozilla FireFox.
7. Problēma neatkārtojas, ja uz mana datora sistēma ar to pašu pārlūkprogrammu pieslēdzas cits lietotājs un veic šīs pašas darbības.
8. Problēma atkārtojas, ja ar savu lietotājvārdu un paroli pieslēdzos no cita datora.
9. Problēmu konstatēju 14.12.2011. Iepriekšējo reizi šādas darbības veicu 12.12.2011 un problēmas nebija.
10. Pievienoju ekrāna attēlu.
11. Lūdzu 1) novērst problēmu, ka parādās ziņojums par C  neatbilstību formulai, lai gan ievadītā vērtība ir korekta un formulai atbilst un 2) atļaut laukā C ievadīt arī formulai neatbilstošas vērtības un par nesakritību parādīt informatīvu brīdinājumu, nevis kļūdas ziņojumu.
12. Tālrunis saziņai: 67654321, e-pasts aaa@bbb.cc – droši jautājiet, ja nepieciešams.

Paldies!

Par procesu īsumā

Sadarbībā Pasūtītājs – Programmatūras uzturētājs parasti līgumos ir atruna, ka darba gaitā vienosies par noteiktu problēmziņojumu apstrādes un kļūdu un defektu novēršanas procesu, tajā skaitā arī par to, kāda informācija iekļaujama problēmziņojumā. Šāda pieeja izmantota, piemēram:

Valsts vides dienesta informācijas sistēmas izstrāde un ieviešana

VSAA Likumdošanas izmaiņu realizēšana SAIS

Robežapsardzības informācijas sistēmas „RAIS 2009” izveidošana. Kvalitātes nodrošināšanas plāns

Viens no detalizēta apraksta piemēriem – par procesu, ne paša problēmziņojuma saturu (tas tur nav definēts), ir , piemēram, Valsts ieņēmumu dienesta rīcībā esošās izmaiņu pārvaldības sistēmas apraksts – tur var gūt priekšstatu par to, ka problēmas ziņojums ir “objekts”, kurš tiek pakļauts nopietnai apstrādei. IT nozarē problēmziņojumu apstrāde notiek projekta kvalitātes pārvaldības ietvaros un pašu apstrādes procesu mēdz saukt par problēmziņojumu un izmaiņu pieprasījumu pārvaldību. Bieži tiek lietotas abreviatūras PZ (problēmziņojums, problēmas ziņojums, problēmas pieteikums) un IP (izmaiņu pieprasījums). Nopietnos projektos problēmziņojumu apstrādes ietvaros no IT speciālistiem tiek prasīta atbildība par rezultātu, tiek analizēts veiktais darbs, nepabeigto pieteikumu statistika, veikti dažnedažādi citi mērījumi par darba kvalitāti un veikti arī citi pasākumi, lai stimulētu vēlmi reaģēt uz problēmziņojumiem: atrisinot vai pieteicējam korekti izskaidrojot, kāpēc ir tā kā ir.

Gala lietotāji

Ja Pasūtītājs – Izpildītājs līgumu gadījumā vēl ir salīdzinoši viegli iedibināt kārtību, kā noformulēt problēmziņojumus, tad grūtāk ir gadījumā, kad par problēmu ziņo gala lietotājs, ar kuru nav slēgti ne līgumi vai vienošanās par PZ saturu, ne veikta apmācība, kā pareizi pieteikt problēmu. Materiālu ir diezgan maz un maz arī ticams, ka lietotājs pirms problēmas ziņošanas (gadās kā sinonīms “emociju izlikšanas”) meklēs – nu kā tad to pareizi darīt. Tas arī saistīts kā ar konkrētā cilvēka komunikācijas iemaņām un emocionālo inteliģenci, tā ar vispārējo izpratni, ka tas par IT-sensiem taču ir tikai joks.

Akadēmiskajās apmācībās

Par problēmu ziņošanu parasti runā saistībā ar testēšanu un testēšanas gaitas dokumentēšanu, ne reālo lietošanu. Piemēram:

Latvijas Universitāte: “Problēmas apraksts. Katrai problēmai tiek pievienots apraksts, kurš varētu sastāvēt no sekojošiem vienumiem: ievades, gaidāmajiem rezultātiem, faktiskajiem rezultātiem, anomālijām, datuma un laika, procedūras soļa, vides, mēģinājumiem atkārtot, testētājiem, novērotājiem. Katrā ziņā šajā nodalījumā ir jācenšas sniegt pēc iespējas plašāku informāciju, lai spētu problēmu novērst.”

LLU Informācijas Tehnoloģiju fakultātes studentu mācību projekts: “Ja eksistē un ir fiksēta problēma vai kļūda, tā jāapraksta pēc iespējas norādot visu informāciju, kas varētu būt nepieciešama problēmas novērsējam(-iem). Piemēram, apraksta, kāda ir programmas reakcija uz dotajām komandām.”

Ja lasāt kāds akadēmiskās vides pārstāvis – lūdzu, ieguldiet savu artavu arī jūs problēmziņošanas darbaudzināšanā.

IT cilvēkiem

Tomēr – nav ko bārt lietotājus par dīvainiem problēmziņojumu formulējumiem, bet:

1. Protams, protams, rakstīt programmas bez kļūdām. :-)
2. Veidot sistēmu tā, lai no esošajiem datiem iespējams diagnosticēt problēmu pat nesagaidot lietotāja pieteiktu ziņojumu.
3. Nodrošināt iespēju ērti paziņot par radušos problēmu, pasakot priekšā, kāda informācija tiek gaidīta, un ar iespēju pievienot pielikumu. Nokaitināts lietotājs, kuram nav iespējas darīt zināmu savu bezgalīgo un pamatoto sašutumu, atradīs iespēju to paust, ticiet man – bet tas jau būs Delfu vai Tvnet komentāros, tviterī u.tml.
4. Sūtot lietotāja ziņojumu no programmas, automātiski pievienot tehnisku informāciju, kas palīdzēs diagnosticēt.
5. Kad ir iespējams, izglītot, ka IT atbalsts ir nevis robotu bars vai melnais caurums, kurā neatgriezeniski sabirst nabaga cilvēku sūri grūti rakstītie teksti, bet ir dzīvi cilvēki, kuri gan grib palīdzēt, gan cer saņemt precīzu, izsmeļošu informāciju.
6. Portāliem, kurus lieto jaunieši, problēmu ziņošanu organizēt sevišķi pārdomāti un savā ziņā uzņemties viņu problēmziņošanas kultūras veidošanas un audzināšanas lomu.
7. Aicināt nevis “ziņot par kļūdu” vai “pieteikt problēmu”, bet aicināt “sniegt ieteikumus uzlabošanai”, “izteikt viedokli”, “sazināties ar izstrādātājiem” – kaut kā tā.

No manas pieredzes par problēmu ziņošanu

Atzīšos, esmu aktīva kā nātrijs – ja pamanu kļūdu vai nepilnību – informēju par to, negaidot, ka problēma gan jau uzsūksies. Galu galā – labākajā gadījumā manu ieteikumu ņems vērā, sliktākajā – nu pa galvu taču nesitīs.

www.latvija.lv – šodien, 16.12.2011 neatradu iespēju nosūtīt problēmziņojumu, bet esmu pirms kāda laika sūtījusi. Iespaids toreiz bija graujoši slikts un to stāstīju studentiem kā ļoti sliktas prakses piemēru: milzīgs teksta ievadlauks, pēc kura aizpildīšanas un mēģinājuma nosūtīt – parādījās kļūdas ziņojums, ka atļauti tikai 250 simboli! Lieki piebilst, cik dusmīga biju par veltīto laiku izsmeļošam aprakstam (vēl trakāk bija vienā citā portālā, kur pēc rūpīga apraksta nosūtīšanas mēģinājuma saņēmu “Neizdevās nosūtīt!” – un forma tika attīrīta bez iespējas atgūt ievadīto tekstu). Toreiz vairākas reizes Latvija.lv rakstīju ieteikumus (katru no tiem tātad bezmaz vai tvitera formātā) – piemēram, palielināt ziņojumā atļauto simbolu skaitu, vismaz papildināt nosaukumu “Problēmas apraksts (līdz 250 simboliem) vai uzlikt ievadlauka ierobežojumu, lai fiziski nevar ierakstīt garāku, šādā gadījumā jauki būtu arī skaitītājs, cik simbolu vēl atlicis – kā tviterī. Šodien neredzu iespēju “Nosūtīt ziņojumu”:

Swedbank internetbanka  – nebija viegli iedomāties, ka iespēja nosūtīt ziņojumu meklējama zem „Noderīga informācija”. Esmu sūtījusi desmitus reižu. Atbild ātri, profesionāli un argumentēti, ar pateicību par izrādīto interesi un norādes uz nepilnībām patiešām tiek ņemtas vērā.

VID EDS demo versija (Identifikators demo, parole demo), no kuras ņemts attēls – produkcijas VID EDS sistēmā ir tieši tāda pati iespēja – atrodama salīdzinoši vienkārši: izvēlne „Sūtīt vēstuli” un var izvēlēties vajadzīgo tēmu. Procesu neesmu izmēģinājusi. VID mājaslapā ir arī adrešu saraksts, uz kuru var sūtīt e-pastu, t.sk. par problēmām:

E-csdd.lv: ir labi saskatāma kontaktu sadaļa, iesūtīt pieteikumu var tikai e-pastā. Tiesa, uz manu 21. oktobrī nosūtīto jautājumu uz norādīto palidziba@… tā arī nesaņēmu atbildi, bet tas ir cits stāsts.

Līdzīga pieeja – kontaktu sadaļa ir izmantota arī Rīgas pašvaldības pakalpojumu portālā:

Lattelecom iespēju nosūtīt problēmas ziņojumu arī atrodu salīdzinoši viegli. Neesmu izmēģinājusi:

Kā redzējāt no piemēriem, vairākums aprakstu ievadāmi vai sūtāmi uz e-pastu brīvā tekstā, tātad – cerams, izmantosiet šajā rakstā sniegtos ieteikumus :-)

Starp citu – Rīgas tirdzniecības tehnikuma Helpdesk – viena no retajām vietām, kur atradu, ka problēmziņojumu var pieteikt daļēji strukturētā veidā:

Katram gadījumam piebildīšu, ka nepretendēju uz visaptverošu apskatu vai rūpīgu, metodisku analīzi ar vispārinošiem secinājumiem. Šie ir daži no tiem, ar kuriem man pašai ir bijusi saskare vai kurus izdevās ātri atrast ar Google meklētāju.

Paldies visiem lasītājiem par pacietību un sevišķi liels paldies visiem, kuri komentāros ierakstīsiet savas domas un piedzīvojumus, kā arī dosiet arī norādes uz  konkrētiem piemēriem.

Kā sadzīvot ar programmētājiem?

Iedvesmu smēlos 28.09.2011 Analītiķu vakariņās, kur cunftes māsas un brāļi dalījās pieredzē.

Dažādi avoti dažādi uzskata, vai sistēmanalītiķis izaug no programmētāja, vai programmētājs no sistēmanalītiķa. Nepiekrītu ne vienam, ne otram, jo tas asociējas, it kā viens no šiem būtu nākamais attīstības līmenis otram. Ja nu tomēr kāds ļoti grib kastas, speciāli viņam mēģināšu šādu līdzību: reiz lasīju medicīnas raksta komentāros: ārsts bez medmāsas neiztiks, bet laba medmāsa iztiks bez ārsta. Tā sistēmanalītiķis bez programmētāja neiztiks, bet labs programmētājs bez sistēmanalītiķa iztiks.

Liriska atkāpe: klausoties vienu no runātājiem, sapratu, ka, lai gan kritikas objekts bija specifikācija, tomēr nepārprotami tika kritizēts analītiķis kā sugasvārds, viss darba process ar viņu – acīmredzot kaut kas neiet tik gludi kā gribētos. Nenocietos un pajautāju – kura būtu  programmētāja izvēle no divām galējībām “slikts dokuments + analītiķis, kurš spēj atbildēt uz jautājumiem” vs “labs dokuments + analītiķis, kurš nespēj to komentēt”? Pēc īsa pārdomu brīža (kā man šķita, īstermiņa kārdinājums – ja patiešām (!) būtu labs dokuments, da nu to analītiķi :-), visu taču bez viņa varētu uztaisīt – pret darbu ilgtermiņā: ko tad, kad sāksies izmaiņas?), uzvarēja draudzība un salīdzinājums ar zivi un makšķeri, kur labāk makšķere: cilvēks, kurš spēj konsultēt un atbildēt.

Morāle: vispār jau “mēs abi” viens otram esam vajadzīgi un ir jauki, kad izdodas gūt baudu no procesa. Lai mums izdodas!

1. Projektējuma un/vai darba uzdevuma kvalitāte. Saņemamies, analītiķi!

Vakariņās daudz kritikas, man par lielu pārsteigumu, izskanēja faktiski par elementārām lietām, par kurām šķita, ka tām jau nu vajadzēja būt izmirušām līdz ar dinozauriem – par projektējuma un/vai darba uzdevuma tehniskās rakstīšanas kultūru: nedefinēta, pat pretrunīga terminoloģija, neizmērāmi jēdzieni, slikta vai neviendabīga prasību detalizācija, trūkst atsauču, prasību pārprotamība (jā, jā, ir gadījies. Arī viens no vakariņu analītiķiem pasmaidīja, ka pirms atvaļinājuma uzrakstījis prasību, atgriezies, izlasījis un reakcija – kurš <pašcenzēts> šo <pašcenzēts> rakstījis?).

Kritika arī par saturu pēc būtības – nav aprakstīti visi algoritma zari, kādas kontroles nepieciešamas, nav saprotams, kur kļūda, kur brīdinājums, kādā stāvoklī jāatgriežas programmai pēc darbības izpildes, kādas noklusētās vērtības liekamas, kāda funkcija kam seko, kas klasifikatoros, kas un kā lasāms no datubāzes, kas parametrizējams, kas šujams kodā. Labi, neizlikšos svētāka par Pāvestu, it kā es allaž rakstītu tikai perfektus projektējumus, bet nu goda vārds par šo pārmetumu daudzumu nobrīnījos.

Intuīcija saka, ka mazāk šādu kļūdu ir tiem analītiķiem, kuri iepriekšējā dzīvē paši ir bijuši programmētāji. Tas nav obligāti, taču kaut kā vajadzētu atrast veidu pabūt programmētāja ādā. Man palīdz tas, ka šo to pati programmēju. Ja tas ir manis pašas projektēts, tad cenšos iztēloties, kā būtu, ja cits iedotu šo darba uzdevumu – kāda informācija man būtu vajadzīga.

2. Aprunāties par to, kā programmētājs vēlētos strādāt. Parasti sistēmanalītiķiem ir manevra iespējas pielāgoties. Kāds programmētājs vēlas pilnu kopskatu uz sistēmu un izpratni, kāda tajā ir loma katrai funkcija, cits izdara (pārkodē) sev uzdoto gabalu, atdod un staigā laimīgs. Jāsaprot starp rindiņām, jo reti kurš tā tiešā tekstā teiks, ka pārējais viņam neinteresē. Patiesībā svarīgāk ir nevis neizdarīt to, ko negrib, bet censties izdarīt to, ko grib.

Praksē zinu, kurš precīzi un klusu izpildīs to, ko esmu uzrakstījusi (arī ja esmu kļūdījusies – i aci nepamirkšķinās. Atzīšos – tas disciplinē :-) ). Zinu, kurš šaubīgā vietā pārjautās pirms izpildes. Zinu, kurš nāks un izklāstīs savas domas, bet kurš teiks, ka viņam viss vienalga, un kurš – ka var uzprogrammēt jebkādas analītiķa vēlmes, lai tikai dodu uzdevumu. Zinu, kuru ļoti kaitina, ja kaut kas nav uzreiz saprotams, un kurš ir mieramika, zinu, kurš strādās kamēr uztaisīs un kurš strādās līdz 16:59. Attiecīgi savu manevru iespēju robežās ar katru no viņiem rēķinos, pielāgojos. Patiesībā jau šie atšķirīgie stili ir ļoti interesanti un ne par vienu no viņiem neteikšu, ka būtu sliktāks vai labāks par pārējiem.

3. Ļaut programmētājam koncentrēties uz viņa darbu – neapgrūtināt ar lietām, kurām JĀBŪT atrisinātām analīzes līmenī. Programmēšanas pasaule ir interesanta un daudzpusīga: tehnoloģijas un standarti, koda izstrādes vadlīnijas, nosaukumu konvencijas, debugi un exceptioni, branči un integritāte, atkārtojamizmantojamība un mantošanas, iebūvētas un jaunveidojamas metodes, masīvi un cikli, vārdu sakot, lietas, kurās cilvēkam no malas var būt līdzīgas sajūtas kā skatoties zvaigznēs un mēģinot saprast, cik tālu tās ir. Programmētājam pietiek ko noņemties ar to visu, un lai vēl turētu rociņu analītiķim?

4. Konsultēties ar programmētājiem – cik viegli vai sarežģīti ir šāds variants, kā konkrētajā situācijā labāk rīkoties, kāda konceptuāli būtu prātīgāka rīcība. Tas dažreiz nav viegli, sevišķi tad, kad šķiet, ka pati gudra. Gadās, ka tas, ko analītiķis iecerējis “lai vieglāk uzprogrammēt” un jau sasolījis klientam, izrādās, ka programmētājam dēļ tā jāveido speciāla apstrāde.

5. Uz programmētāju jautājumiem atbildēt ASAP. Jo jautājums parasti nozīmē, ka virpa vai nu ir izslēgta, vai nu kaut kur ir risks palikt pagaidu vai nepabeigtam risinājumam.

6. Vienoties, varbūt var paskatīties rezultātu vēl pavisam darba variantā, kaut lietotāja saskarni.

7. Kad iespējams, censties savus ieteikumus apkopot, jo ir kaitinoši ik pa laikam atgriezties pie jauniem sīkumiem. Atvainoties programmētājam vai vismaz vainīgi pasmaidīt, ja tā gadās. Tomēr – ja nu ir tā sanācis, labāk lai gadās nokaitināt programmētāju, nevis kaut ko neizdarīt tāpēc, ka “ai, neērti bija prasīt”.

8. Pārbaudīt, pirms dot kāda sūdzību programmētājam kā darba uzdevumu viņa kļūdas labošanai. Ai, mēdz gadīties, ka kļūdas cēlonis ir pavisam cits… kaut vai DB dati, kas sabojāti un varbūt pat paša analītiķa neuzmanības dēļ. Protams, jāskatās, kas projektam tobrīd ir izdevīgāk un kāda veida sūdzība tā ir – var vienoties, ka programmētājs pats veiks problēmas cēloņa izpēti, taču tai būtu jābūt norunai, nevis praksei.

Īsumā tas arī viss. Aiz kadra paliek profesionālās lietas – to apgūšanai ir akadēmiskā skola. Mans blogs vairāk velk uz dzīves skolas pusi.

Visbeidzot, draudzēties vai ievērot distanci? Profesionāļi var gan tā, gan tā – esmu pārliecinājusies, ka tam nav izšķirošas nozīmes. Nu, jā, tā personīgi patīkamāk ir koleģiāli draudzēties. Un noder šad tad pievaldīt mēli :-). Nu, vismaz censties.

P.S. Kamēr neesmu uzrakstījusi analītiķa lietošanas pamācību, tikai viens ieteikums programmētājiem: pašam nelabot pa kluso analītiķa kļūdas vai it kā kļūdas. Vai nu aprunāties, vai taisīt kā likts.

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.

Sistēmanalītiķa sadarbība ar projekta vadītāju

Pildu iekšējo apņemšanos uzrakstīt savas domas par kārtējās, šoreiz 27.04.2011 Analītiķu vakariņās skatīto tēmu. Par pamatu paņēmu Vladimira Ivanova prezentāciju un tajā izvirzītos apskatāmos jautājumus.

Viss šeit tālāk paustais ir manas kā ilggadējas sistēmanalītiķes absolūti personīgās un vēl absolūtāk subjektīvās domas.

Sākšu ar pārfrāzētu stāstu iz dzīves, kuras oriģināls skan šādi: Ārstu kongress. Uzstājas aizrobežu bērnu ārsts. Pieceļas kājās Latvijas ārste un jautā – sakiet, bet kā jūs cīnāties ar mātēm? Aizrobežu ārsts izbrīnīts pārjautā – cīnāmies? Mēs necīnāmies! Mēs ar viņām sadarbojamies!

Tātad. Sistēmanalītiķim jautā: kā tu cīnies ar projekta vadītāju? – cīnos? Es necīnos! Es ar viņu sadarbojos! Vai – Projekta vadītājam jautā: kā tu cīnies ar sistēmanalītiķiem? -cīnos? Es ar viņiem sadarbojos! Tas pats ir spēkā – programmētājam par testētāju, sistēmanalītiķim par dokumentētāju utt. Mēs sadarbojamies pat tad, ja no malas kādam savureiz šķiet, ka cīnāmies. 

1. Ko projektu vadītājs sagaida no sistēmanalītiķa IT projektā. Kādi ir analītiķa pienākumi, atbildība?

Visvienkāršākais, protams, būtu to pajautāt konkrētajam vadītājam, ja nu viņš gadījumā sagaida kafijas pienešanu :-) Bet, ja nopietni – es domāju, ka sagaida šīs lietas:

1)  Profesionalitāti (šo tālāk uzskatīšu kā pašsaprotamu un vairs neiztirzāšu – programmatūras izstrādes procesa izpratne, prasību analīze, modelēšana, SQL, projektēšana, spēja un vēlme rakstīt dokumentus, kvalitātes pasākumu ievērošana un uzlabošana, korekta attieksme pret klientu, laba un konstruktīva komunikācija ar pārējiem komandas locekļiem u.tml.);

2)  Sistēmisku, ilgspējīgu pieeju, atbildību par rezultātu un domāšanu ne tikai par to, kā tagad atrisināt problēmu, bet ar skatu nākotnē – kā tas ietekmēs citas sistēmas, kas notiks, kad DB ierakstu skaits pieaugs, cik tas ir adekvātiem resursiem realizējams konkrētajā situācijā, vai neradīs nepedagoģisku precedentu vai tieši otrādi – varbūt radīs labu precedentu u.t.t. (zināmā mērā iekļaujas profesionalitātē, tomēr izdalīju atsevišķi, esmu redzējusi (diemžēl, jaunībā pieredzes trūkuma dēļ arī pašai ir gadījusies) viendienīšu domāšanu ar visām no tā izrietošajām sekām);

3)  Patstāvību darba uzdevumu izpildē (nevis rafinētu slaistīšanos cerībā, ka neviens nepamanīs, ka vecais darbs jau beidzies un jauns nav uzdots). Viena no mana priekšnieka frāzēm, kas joprojām silda sirdi – par tevi man sirds mierīga, jo zinu, ka tu strādā, nav jāpārprasa, vai tev ir ko darīt un nav jāskatās uz nagiem (kā šad tad ir gadījies ar vienu otru);

4)  Iekļaušanos norunātajos termiņos un savlaicīgu izrunāšanu par iespējamām nobīdēm, to cēloņiem un iespējamiem risinājumiem. Līdzko ir aizķeršanās – nekavējoties jāiet un jārisina, jājautā, jāprecizē. Protams, ar mēra izjūtu (labāk apkopot jautājumus, nevis ik pēc 5 minūtēm skriet jautāt kārtējo lietu). Ja šis tiek ievērots, vadītājs nepārmet ne pačalošanu tviterī, ne ziņu palasīšanu pīppauzēs;

5)  Spēju uzdot jautājumus, nepaļaujoties uz pieņēmumiem „ai, bet es toreiz domāju, ka ar to domāts tas!”. Prasmi un vēlēšanos domāt, runāt un rakstīt izmērāmos jēdzienos. Nevis „datu operatoram nebūs ilgi jāgaida uz transakciju pabeigšanu”, bet ja izpildās nosacījumi x, tad 95% no transakcijām jāapstrādā laikā, kas mazāks par 1 sekundi. Nekādu „jāstrādā ātri un labi” vai „jāizpilda visas lietotāja prasības”;

6)  Pacietību. Gan apdomājot, gan meklējot materiālus, gan atkal un atkal skaidrojot un pamatojot savu domu, gan runājot ar dažādas kvalifikācijas klientiem, gan apmācot jaunos komandas locekļus (personīgi man ļoti noder diezgan ilgais pasniedzējas darba rūdījums);

7)  Interesi par jaunumiem tehnoloģijās – vismaz jēdzienu izpratnes līmenī. Analītiķus parasti tās tik ļoti neskar kā programmētājus, tomēr ir labi saprotoši māt ar galvu, kad par tām tiek runāts;

8)  Analītiķa pienākumi un atbildība? Atkal pieminēšu anekdoti. Tātad, stjuarte vadā pasažierus ekskursijā pa lidmašīnu – re, pirmajā stāvā baseins, otrajā sporta zāle, trešajā mākslīgā pludmale, ceturtajā restorāni, piektajā golfa laukums, sestajā sēdvietas. Ekskursijas noslēgumā – а теперь попробуем с этой фигней взлететь! Lūk, tas arī ir analītiķa pienākums – taisot golfa laukumu piektajā stāvā, nodrošināt arī, lai būtu iespējams ne tikai kopumā с этой фигней взлететь, bet arī lidot ilgi  un laimīgi.

9)  Visbeidzot, pats galvenais – izveidot noturīgu analītiķa brendu jeb zīmolu. Ja Vita teica, ka risinājums ir pārbaudīts un strādā OK, tātad – ar mierīgu sirdi varam to dot klientam. Nevis – nu, analītiķis it kā domā, ka ok, bet nu nez, kā būs, varbūt jāpalūdz, lai Jānis arī apskatās, ka tik nav kaut kas savārīts.

2. Analītiķa iesaistīšanās citos projekta posmos

Visos. Analītiķis ir tas, kurš bāž un bāzīs degunu visos posmos, kuru citi lamās visos posmos un kurš mēģinās stoiskā mierā to visu izturēt, labot, ko var labot, un mēģināt iemārketēt par fīčām vai vismaz sadzīvot ar to, ko vairs nevar labot vai kā labošana kopumā neatmaksāsies.

Koncepcija, prasību specificēšana, analīze – analītiķis pašsaprotami.

Programmēšana – savu iespēju robežās, dažreiz pat virs tām, analītiķis tur līdīs, sevišķi, ja programmētāju komanda, teiksim tā, nav pilnībā patstāvīga. Analītiķis parasti ir tas, kurš sacer vai vismaz pārlasa lietotājam rādāmo ziņojumu tekstus un ir tikai normāli, ja programmētājs prasa – iedod man tekstu šādai situācijai (ja tas jau nav PPA ielikts). Ir reizes, kad programmētājs piedāvā citu risinājumu, sak, mums jau ir uztaisīts šāds, vai varam lietot to? Ir reizes, kad ir vienalga, kā konkrēto vietu realizēt, tad analītiķis var teikt – uztaisiet, kā jums šajā gadījumā vieglāk. Bieži notiek apspriešanās – klau, vai šajā vietā ir iespējams šo logu uztaisīt tā, šo pogu tā un pēc šī taustiņa nospiešanas šitā? Programmētājs nereti atbild: VISS ir iespējams, saki, kā vajag, viss būs. Noklusējot, ka šīs pogas uztaisīšanai tā, vajadzīgas 2 nedēļas, bet šitā – 1 diena :-) .

Jāpiešaujas pie katra programmētāja, un domās tiek uzturēta tāda lieta kā programmētāja koeficients. Piemēram, ja Jānis pasaka, ka viņš to uztaisīt 3 dienās, reāli gan jau aizies visas sešas, tātad Jāņa koeficients ir 2. Ja Ieva saka, ka viņai tas prasīs divas dienas, parasti aiziet trīs, tātad Ievas koeficients 1,5. Šie koeficienti paši par sevi nav ne labi, ne slikti, svarīgi, ka tādi vispār ir, ar tiem vienkārši klusiņām jārēķinās. Par šādu koeficientu esamību viņi parasti nezina, tieši tāpat, kā sistēmanalītiķi ne vienmēr zina, kāds ir viņu koeficients projekta vadītāja acīs :-) Ideālajā pasaulē koeficients ir 0,8-1. Mazāk gan nevajag, liels risks kvalitātes zudumam.

 3. Ko projektu vadītājs nesagaida no sistēmanalītiķa, bet kur analītiķi mīl ielīst?

Pirmais, kas nāk prātā – klientiem uz savu galvu sasolīt zelta kalnus. Pēc tam ir neērta situācija un jādomā, ko darīt. Vai mēģināt izpildīt gandrīz neiespējamo (t.i. neadekvāti resursietilpīgo), vai analītiķis pats atsauks savu solījumu un kādā veidā, vai to darīs projekta vadītājs… un jūs jau zināt, kādas izjūtas pārņem, ja kādam ņem kaut ko nost, kas ir apsolīts.

Otrs, ko vadītājs negaida no analītiķa – dot vērtīgus norādījumus un neapšaubāmi zelta vērtas pamācības citiem, kā darīt viņu darbu, sevišķi vēl, ja runa ir par citiem projektiem. Tad gadās, ka tie projektu vadītāji mēdz vairāk vai mazāk uzkrītoši apjautāties, vai tiešām konkrēto analītiķi pietiekami nenodarbina, ka viņam atliek laiks bāzt degunu citu lietās?

4. Kāda loma projektā analītiķim ir teorijā un kāda tā ir praksē

Teorijā, manuprāt, analītiķim ir mazāka loma nekā praksē.

Ideālajā pasaulē analītiķis nodod ideālu projektējumu un aidā tālēs zilajās, pārējo paveic ideāli programmētāji, testētāji, dokumentētāji.

Reālajā pasaulē analītiķis ir visur – piedalās sapulcēs, sēž blakus programmētājam, stāsta testētājam, kas tajā vietā domāts, dokumentētājam norāda, ka šeit ir с точностью до наоборот, un sagatavo LASIMANI nodevumam.

Ja man liktu izvēlēties vienu galējībām – vai nu analītiķa ir tik daudz, ka bail konservu bundžu vaļā vērt, vai viņa pārējos posmos nav nemaz, es izvēlētos pirmo.

 5. Cik projekta vadītājam jāzina par biznesu, jāiedziļinās problēmās

Esmu piedzīvojusi un pārdzīvojusi dažādus vadītājus. Sākot ar tādiem, kuri reizi divās nedēļās paprasa progresa % (ja godīgi, nemaz nebija slikts variants :-) ), beidzot ar tādiem, kuri pāri visam kabinetam sauc – „nē, tajā vietā pogai jābūt pelēkai!”, laikā, kad klusiņām runāju ar programmētāju.

No projekta vadītāja sagaidu ne tik daudz biznesa zināšanas (tam ir biznesa zinātāji un sistēmanalītiķi), kā gribētos kopskatījumu uz sistēmu (protams, ja vien tas projektā nav manis pašas pienākums). Viņš mierīgi var nezināt detaļas, bet būtu labi, ja zinātu atbildi uz jautājumu – klau, vai mums sistēmā ir precedents šādam konceptuālam risinājumam? Atkal ne detaļās, bet lielos vilcienos. Nu, piemēram, vai šāda veida datu apmaiņu kādā vietā risinām caur DB sinonīmiem vai noteikts, ka jālieto tikai webservisi? Protams, ja uz šo jautājumu projektā var atbildēt cits vai tas ir kaut kur labi dokumentēts, vai kā citādi atrodams, tad projekta vadītājs to drīkst nezināt – atbildētājs tikpat labi var būt kā galvenais programmētājs, tā arhitekts, tā cits analītiķis.

Galvenais, lai ir nodrošināts kāds, kas to zina.

Vai projekta vadītājam jāvar aizvietot analītiķi?

Jā. Gan projekta vadītājam, gan analītiķim jāvar aizvietot vienam otru, bet! – uz neilgu laiku, ne ilgāku par nedēļu, maksimums divām, ja tās savlaicīgi plānotas. Aizvietošana praksē gan nereti izpaužas tā, ka analītiķis administratīvi pieskata projekta vadītāja uzsāktās lietas un klientam pasaka vai nu to, ko pats analītiķis droši zina, vai vienojas par laiku, kad klients saņems atbildi vēlāk [kad būs atpakaļ projekta vadītājs], savukārt, kad projekta vadītājs aizvieto analītiķi, tas izpaužas tā: iespēju robežās pārplāno darbus uz laiku, kad analītiķis atgriezīsies, pieskata jau esošo darbu izpildi un informē interesentus par laiku, kad analītiķis būs atpakaļ. Dziļāku aizvietošanu darba ikdienā nesaskatu par obligātu, jo ne velti ir lomas – projekta vadītājs un ir analītiķis. Tad jau ir jārunā par riska menedžēšanu gadījumam, ja kāds no tiem izstājas.

Galu galā, ja tie būtu viens un tas pats, tad vai nu uzreiz būtu divi vienā, vai divi vadītāji, vai divi analītiķi.

6. Projekta vadītājs/analītiķis –kādi plusi, mīnusi

 Atkarīgs no projekta lieluma, galu galā ir projekti, kur visu izdara viens cilvēks. Ja projekts ir tik mazs, ka abas šīs lomas var sekmīgi apvienot – uz priekšu! Runājot par lielāku projektu – tādi paši plusi un mīnusi kā pats sev ķirurgs. Kājas pirkstu sev saoperēt var, bet ir vietas, kur tomēr jāuztic darbs citam, lai cik labi pats to prastu un izprastu. Līdz ar ko es teiktu, ka lielā projektā labāka kombinācija (ja vispār jākombinē!) būtu projekta vadītājs–galvenais arhitekts, nevis projekta vadītājs–analītiķis.

 7. Ieteikumi analītiķiem, kā veidot attiecības ar projektu vadītāju.

Papildus šiem – ieteikums viens: veidot attiecības, nevis gaidīt, ka tās izveidosies pašas, чудом. Pašsaprotami – strādāt no sirds. Un vērot, kā projekta vadītājs strādā, vai viņam pieņemamas ir strikti lietišķas attiecības, vai koleģiāla draudzība. Šeit universālas receptes nav, tik vien kā mans ieteikums – analītiķim censties pielāgoties vadītaja stilam. Gan tāpēc, ka pastāv subordinācija, gan tāpēc, ka projekta vadītājam tīri cilvēciski darbu nasta ir vēl smagāka. Jā, protams, analītiķim tā arī ir milzīga, tomēr, cik esmu piedzīvojusi labus projekta vadītājus, esmu redzējusi, cik daudz viņi strādā un kāds ir atbildības līmenis, un ļoti cienu viņu darbu.

Sliktais piemērs, kā nevajag darīt – epizode iz dzīves. Reiz, sensenos laikos… gadījās tā, ka biju dikti laicīgi pieteikusi atvaļinājumu, tad nomainījās projekta vadītājs un es kaut kā automātiski pieņēmu, ka viņš taču zina, ka tūlīt iešu atvaļinājumā. Bet viņš daudzo darbu pārņemšanas laikā to nebija ievērojis, un radās neveikla situācija – bija ieplānojis man darbus un rēķinājies ar mani, bet es – žvirkt! atvaļinājumā… (nevarēju pārcelt). No tā mācījos šādas kļūdas neatkārtot – man vajadzēja nevis pieņemt, bet laicīgi aprunāties. Jā, formāli man bija taisnība, bija iepriekšējā vadītāja saskaņots savlaicīgs iesniegums personāla pārvaldē. Bet cilvēciski man pilnīgi noteikti nebija taisnība.

Un vispār, ja tiks izpildīts 1.punktā minētais, tad 99,9%, ka attiecības ar projekta vadītāju būs labas :-) !

P.S. Kas attiecas uz pašu Vladimira prezentāciju – no manas puses visdziļākā cieņa un prieks par to, ka cilvēks, kura CV varētu aizņemt sīkā fontā kādas trīs lappuses, stāstu par sevi sāka ar to, ka ir divi burvīgi bērni!