Archive for the ‘Sistēmanalīze’ Category

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 … else to_char(to_date(’01-JAN-2500′),’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?

cut

Be creative! You have so many dimensions!

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

creative

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

identity

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

lines

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.

answer

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:

office

  • 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:

BAslud

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

Image

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:

Image

Diagrammu piemēri:

Image

 

Image

 

Image

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

Image

Eksāmena jautājumu piemēri

 Image

 

Image

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ājusiVID 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.

%d bloggers like this: