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!

4444=15

Katru dienu (!) šo blogu vismaz viens lasītājs atrod pēc atslēgvārdiem apmēram „4444=15” vai „4444 atbilde 15”. Nefilozofēšu par mūsdienu cilvēku spējām rēķināt, bet sagatavošu detalizētu špikeri.

Paldies aktīvakajiem risinātājiem!

twitter.com/kaaposc

twitter.com/nex_aeterna

twitter.com/uvisl

twitter.com/aigarius

twitter.com/girtskarnitis

twitter.com/RobinsRGB

Tātad:

4444444444=15

((4 + SQRT(4)) * (4 + 4) – (4 – 4 / 4)) / (4 – 4 / 4) = 15

444444444=15

(4 * 4 + 4 * 4 / 4) * (4 – 4 / 4) / 4 = 15

(4 + 4 / 4 + 4 / 4) * (4 + 4 + SQRT(4)) / 4 = 15

(4 * 4 + 4) * (4 – 4 / 4) / 4 * (4/4)= 15

44444444=15

(4 + 4 / 4) * 4 * (4 – 4 / 4) / 4 = 15

(4 + SQRT(4)) * (4 * (4 – 4 / 4) – SQRT(4)) / 4 = 15

((0,4+0,4/4)+(4-4/4)+4)*SQRT(4)

4444444=15

(4 * 4 + 4) * (4 – 4 / 4) / 4 = 15

(4+(4-4/4)*SQRT4)+4/4

444444=15

4!/4+4+4+4/4=15

(4+4/4)*(4-4/4) = 15

4*4+4-4/4-4 = 15

44444=15

(4*4*4-4)/4=15

 4!-4-4-4/4=15

SQRT(4) * SQRT(4) * 4 – 4 / 4 = 15

4444=15

4*4-4/4=15

4*4-(LOG4 4)=15

444=15

4*4-INT(SQRT(SQRT(4))=15

4*4-ROUND(SQRT(SQRT(4))

44=15

4*4-π/π=15

4*4 + e^{i * π} = 15

SQR(4)-ROUND(SQRT(SQRT(4))

INT(SQRT(SQRT(SQRT(SQRT((4!)!)))))/(SQRT(4))=15

4=15

 INT(4*π+π)=15

CEIL(SQRT(POW(4+π, e)))

INT(COS(SQRT(4)+SQRT(π))-π-e) = 15

SQR(4) + e^{i * π} = 15

kur:
e- naturālā logaritma bāze,
π ir π
i = imaginārā vienība SQRT(-1)

Šeit iepublicēti tie, kuri atbilst šādiem nosacījumiem:

1)      operācijas un standartfunkcijas lietot tikai kreisās puses cipariem  un katru ’4′ pa vienam apstrādāt, nevis ’444+44′,

2)      rezultāts katrā izteiksmē ir piecpadsmit (nevis 1+5 vai tml.),

3)      nav atļauts izmantot funkcijas, kuras, atšķirībā no standartfunkcijām, prasa papildus skaitļus, kādi šeit nav norādīti, piemēram kāpināšanu 0-tajā pakāpē (jo 0 nav dota),

4) decimālā skaitīšanas sistēma.

Komentāros drīkst rakstīt JEBKĀDUS risinājumus, lai tikai tie ir kaut cik uz šīs vienādības pusi, un drīkst operācijās iesaistīt abas vienādojuma puses, kaut vai ‘-4=1-5′, drīkst grupēt ciparus kaut vai ’44444/444′. Kaut nenoteikto trīskāršo integrāli no π, reizinātu ar Planka konstanti. Lai tie, kuri nākamreiz meklēs, brīnās, ka VAR ARĪ TĀ ;-)

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

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

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

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

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

Sertifikācija

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

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

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

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

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

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

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

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

Eksāmens

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

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

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

Manas domas

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

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

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

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

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

A. Context scope diagram

B. Requirements workshop

C. Structured walkthrough

D. Brainstorming

Non-functional requirements are best described as what?

A. Deliverables that are progressively elaborated on

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

C. External interfaces the product must have

D. Internal interfaces the product must have

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

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

B. Tester, regulator, and sponsor

C. Project manager, sponsor, supplier

D. Business analyst, tester, regulator

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

Caur studijām uz sistēmanalīzi

Sākšu ar atvainošanos, ka tālāk apskatu tikai Latvijas Universitātes datorzinātņu studiju programmu. Galvenais un faktiski vienīgais iemesls – tā ir mana dzimtā skola, kur mācījos, strādāju, mācos joprojām, tā teikt der rubrikā “100% pārbaudīts uz savas ādas”. Ļoti laba programma un arī pasniedzēji ir arī citur, piemēram, LLU Informācijas tehnoloģiju fakultātē, kā arī RTU Datorzinātnes un informācijas tehnoloģijas fakultātē – un citās augstskolās. Meklējiet, interesējieties!

Tātad. Es vēl esmu no tās akadēmiski izglītoto datoriķu paaudzes Latvijas Universitātes Fizikas un matemātikas fakultātes datorzinātņu nodaļā, kura mācījās arī matemātiskās fizikas vienādojumus un polinomu algebru. Tagad nu jau kādu laiku matemātikas īpatsvars ir mazināts (Gatis Kokins ir labi noraksturojis paradigmas maiņu matemātikas mācīšanā). Neapgalvošu, ka tagad nakts vidū protu atrisināt Košī problēmu vai parciālo otrās pakāpes diferenciālvienādojumu, taču treniņš smadzenēm tas bija labs un es nenožēloju nevienu lekciju par diferenciālvienādojumiem vai tiem iksiem ar punktiem virsū.

Iedvesmai – daži reāli dažādu sistēmanalītiķu darba starprezultātu – projektējumu piemēri

Gala rezultāts visai izstrādes komandai ir pati programma. Atrasti gūglējot pēc „projektējums” un izlaižot piedāvājumus pirkt referātus.

Izglītības informācijas sistēma Moduļu funkcionālais projektējums

E-veselības integrācijas platforma. Biznesa procesu apraksts

Programmatūras projektējuma apraksts. Valsts kanceleja. Par valsts pārvaldes darbinieku novērtēšanas sistēmas ieviešanu

LU Datorikas fakultātes datorzinātņu bakalaura programmas kursi un mans subjektīvs vērtējums to lietderībai tieši sistēmanalītiķa darbā

Bez šaubām, ka visprātīgākais ir konsultēties ar saviem pasniedzējiem  un programmu direktoriem par īpatnībām konkrētajā programmā un konkrētajā situācijā. No drošiem avotiem un arī savas pieredzes zinu, ka, piemēram, prof. Borzovs, prof. Bičevskis, prof. Arnicāns un citi labprāt sniedz padomus jaunajiem censoņiem.

Tātad, vadoties pēc savas praktiskās pieredzes, no kursiem, kuri ir uz šodienas programmu pēc to lietderīguma tieši sistēmanalītiķa praktiskajā darbā sadalīju (absolūti subjektīvi) trijās grupās:

1. MUST HAVE: noteikti mācieties kā priekš sevis! (ergh, reālajā darbā, sevišķi sākumā, par vairākiem no tiem es varēju tikai vēlēties, kaut savulaik būtu mācījusies cītīgāk)
2. SHOULD HAVE: ļoti labi būtu šo tēmu pārzināt vismaz jēdzienu izpratnes līmenī.
3. NICE TO HAVE: visi pārējie konkrētās programmas kursi noteikti noderēs redzesloka paplašināšanai un smadzeņu treniņam.

1. MUST HAVE

Nosaukums	Kursa īss apraksts	Komentārs
Programminženierija	IS dzīves cikla modeļi. Programmatūras projekta plānošana.Kalendārā ilguma, darbietilpības un izmaksu prognozēšana. Sistēmas modelēšana. Programmatūras prasību pamati. Kvalitātes atribūti. Sadarbība ar IS pasūtītājiem un darbs komandā. Dokumentēšana. Pamatjēdzieni. Testēšanas modeļi, pārskats. Implementēšana un atkļūdošana. IS ieviešana un uzturēšana. Risku pārvaldība.	Cilvēks, kurš nepārzina šo, nav pelnījis saukties par sistēmanalītiķi
Prasību analīze	Pielietošana praktiskajās nodarbības, simulējot pasūtītāja un izstrādātāja attiecības. Studentus grupām tiek uzdots problēmu apgabals turpmākajam darbam visa semestra garumā. Katras grupas uzdevums ir izzināt sākotnējas pasūtītāja biznesa prasības, novērtēt IS izstrādes un ieviešanas projekta iespējamību	Cilvēks, kurš neprot šo, nav tiesīgs saukties par sistēmanalītiķi
Cilvēka – datora saskarne	Iepazīstināt ar psiholoģiskajiem, sociālajiem un tehniskajiem aspektiem, kas iespaido cilvēka darbu ar datoru. Cilvēka uztveres īpatnības. Dažādi saskarnes elementi un to pielietojums. Saskarnes novērtēšana un testēšana. Labas saskarnes izstrāde	Sistēmanalītiķim, kurš neprot izdomāt  un uzzīmēt ekrānformu, izdomāt lietotāja darbību scenāriju un novērtēt realizētās lietotāja saskarnes ērtumu, atliek tikai ietīties paladziņā un ātri rāpot prom
Datu bāzes I	Datu bāzu pamati, pamatjēdzieni (tabula, kolonna, domēns, saite, primārā atslēga, ārējā atslēga) un izveidot vienkāršu datu bāzi izmantojot datu bāzu pārvaldības sistēmu MS SQL Server	Sistēmanalītiķim, kurš neprot SQL un nepārzina datubāzes, atliek tikai ietīties paladziņā un lēnām rāpot prom
Datu bāzes II	Funkcionālās atkarības un normālformas. Datu tipi un relācijas. Glabātās procedūras, funkcijas, skati. Transakciju vadība un bloķēšana	Šīs lietas vienkārši ir jāzina. Un jāzina teicami, jo būt ļoti atkarīgam no programmētājiem nav labi – šāda nevarēšana pašam sev stipri bojā nervus
IT projektu pārvaldība	Projekta vadība, integrācijas pārvaldība, sfēras pārvaldība, riska pārvaldība, kvalitātes pārvaldība, laika pārvaldība, izmaksu pārvaldība, cilvēkresursu pārvaldība, komunikācijas pārvaldība	Lai zinātu savu vietu projektā, pārredzētu spēles laukumu (un savas izaugsmes iespējas)
Modelēšanas pamati	Iepazīstināt ar dažādiem modelēšanas veidiem un to praktisko lietošanu. Kas ir sistēmu modelēšana, modelēšanas veidi. Konceptuālā modelēšana, UML klašu diagrammas un to lietošana konceptuālajā modelēšanā. Sistēmu organizatoriskās struktūras modelēšana. Datu modelēšana. Sistēmu darbības modelēšana. Biznesa procesi, biznesa procesu diagrammas. Biznesa procesu semantika. Biznesa procesu imitācija. Tipiskākie lietojumi	Sistēmanalītiķis, kurš prot modelēt, ietaupa sev daudz laika un darba uz algoritmu un procesu aprakstīšanu un skaidrošanu
Programmatūras testēšana	Testēšanas teorijas un prakses pamati. Testēšanas nozīme kvalitatīvas programmatūras izstrādē, testēšanas metožu daudzveidība, izvēle un savstarpēja kombinēšana atkarībā no programmas specifikas. Praktiskās iemaņas testēšanā un izpratne par problēmām, kuras apgrūtina testēšanas procesu. Īpaša uzmanība pievērsta statiskajai, strukturālajai un funkcionālajai testēšanai, kā arī testēšanas procesa organizācijai	Sistēmanalītiķa darba sastāvdaļa un faktiski rezultāta kvalitātes mērs, jo sistēmanalītiķa uzdevums ir izpildīts nevis tad, kad izlaboti pēdējie komati specifikācijā un projektējumā, bet tad, kad klients lieto programmu un ir ar to apmierināts
Specifikāciju valodu pamati	Formālas specifikācijas jēdziens un dažādas konstrukciju sistēmas (valodas) specifikāciju veidošanai. Kursa ievadā tiek aplūkotas procedūru ieejas/izejas specifikācijas daļējās un pilnās korektības apgalvojumu formā. Tālākas kursa tēmas veltītas specifikāciju un modelēšanas jomā izmantotu valodu un jēdzienu sistēmu pārskatam	Noder, lai pierastu un iemācītos rakstīt un runāt izmērāmos un pierādāmos jēdzienos. Nekādu „jābūt labai, jāstrādā ātri un pareizi”.
Pamatalgoritmu analīze un optimizācija	Uzdevumu algoritmiskā risināšana, Algoritma efektivitātes analīzes pamati, Datu tipu realizācija atmiņā, Algoritmu analīzes piemēri u.c.	Šīs zināšanas ietilpst zinoša un līdz ar to konkurētspējīgāka sistēmanalītiķa džentlmeņa komplektā. Ir tik patīkami varēt iebakstīt ar pirkstu un teikt – re, labot vajag šeit
Programmēšana I	Pamatjēdzieni programmu izstrādei Programmēšanas valodas formālā sintakses aprakstīšanas metavaloda Masīvi Funkcijas Objektorientētās programmēšanas pamatjēdzieni u.c.	Teorētiski ideālā pasaulē sistēmanalītiķis izkūņojas no programmētāja, praksē nav nekas traks arī uzreiz ielekt analīzes vagoniņā. Taču, lai programmētāji tevi kaut cik respektētu, ir jāmāk sarunāties viņu valodā un saprotoši māt ar galvu vai kompetentā balsī iebilst, klausoties, ka šajā vietā jāpāriet no masīva uz blobu un lūk šīs izvēlnes pielikšanai paies vismaz divas, ja ne trīs, bet varbūt pat četras nedēļas laika
Biroja informācijas sistēmas	Dot pamatzināšanas, kas ir nepieciešamas efektīvai dalībai IT projektu pārvaldībā	Noderēs, lai orientētos gan pie klientiem lietoto sistēmu mērķos un uzdevumos, gan pašiem saprast, kam tas viss zvērudārzs vajadzīgs
Tīmekļa tehnoloģijas I	Pamatā klienta puses tehnoloģijas, lappušu veidošanas principi, valodas HTML, XHTML, CSS, JavaScript praktisku uzdevumu risināšanai, XML un tā lietojumi	Tīkls ir visur. Noderēs – gan domājot par saskarni, gan runājot ar programmētājiem
Datu struktūras un pamatalgoritmi I, II	Aplūkotas vienkāršākās un populārākās datu struktūras un pamatalgoritmi darbam ar tām: droši un vienkārši realizējami, ātri strādājoši, izmantojoši minimālu atmiņas daudzumu	Algoritma izdomāšana, pamatošana un izpratne ir tipiska sistēmanalītiķa tipisks darba uzdevums
Datorsistēmu uzbūve I	Veidot izpratni par datoru un to perifērijas ierīču uzbūvi un darbības principiem, kā arī sniegt vispārīgu priekšstatu par skaitļojamo mašīnu vēsturi, ideju ģenēzi un pārmantojamību. Informācijas jēdziens, informātikas pamatjēdzieni, bināro kodu apstrāde datoros, loģiskie elementi, datoru arhitektūra	Jāzina, kas lācītim vēderā
Datorsistēmu uzbūve II	Datorsistēmu sastāvdaļas, ievada un izvada operācijas, ievades un izvades organizēšanas vispārīgie principi, disku un video apakšsistēmas, failu sistēmas, mūsdienu datoru perifērijas ierīces un to darbības principi	Jāzina, kas lācītim galvā
Matemātiskā loģika	Iemācīties pierakstīt savas zināšanas formālā valodā; apgūt formālas izvešanas iemaņas no aksiomām, iemācīties sajust atšķirību starp formāli pierādīto un to, kas šķiet “acīm redzams”; apgūt metodes, ar kuru palīdzību datori spēj paši izdarīt secinājumus un pierādīt teorēmas	Noderēs kontekstā ar SQL zināšanām. Diezgan bieži ir jānovērtē datu korektums, sakrišana pēc replikācijām un sinhronizācijām u.tml., un tur noder saprast visus tos „A izriet no B, kurš savukārt ir vienāds ar C, bet D neizriet”
Internets, tīkla etiķete un tiesiskais regulējums	izprast kibertelpas likumus, uzzināt par to, kas ir aizliegts un kas ir atļauts, kādi ir tīkla etiķetes likumi, kā arī par to, kā aizsargāt savas tiesības, darbus un informāciju.	Palīdzēs pamanīt vismaz elementārākos juridiskos datu apstrādes riskus sistēmās
Algoritmu sarežģītība	Pierādījumi tam, ka dažu uzdevumu risināšanai neeksistē ātri strādājoši algoritmi. Rēķināšanas sarežģītības mēri. Varbūtisku, nedeterminētu un alternējošu algoritmu sarežģītība	Algoritma ātrdarbības uzlabošana ir normāls sistēmanalītiķa darba uzdevums, lai programma spētu tikt līdz trešajam tās attīstības posmam: 1) strādā, 2) strādā pareizi, 3) strādā pareizi un ātri
Matemātikas pamatjēdzieni	Parādīt tādas idejas klasiskajā matemātikā, kas tiek lietotas visdažādākajās matemātikas nozarēs	Šīs lietas ir vienkārši jāzina. Milzu pievienotā vērtība šim kursam ir datorzinātņu dzīvā leģenda, prof. Freivalds
Specseminārs		Iesaku apmeklēt cik vien var specseminārus un iztaujāt to vadītājus, kuri parasti ir nozares  guru ar mentora talantu
Nozares angļu valoda datorzinātnē		Ja nezina angļu valodu, būs grūti. Nesaku, ka neiespējami, bet nu grūti noteikti
Kursa darbs datorzinātnēs, Kvalifikācijas darbs I , II		Kas jādara – jādara.
Prakse		Vajag
Bakalaura darbs datorzinātnēs		Piemēri ar sistēmanalīzi saistītiem bakalaura darbiem no 2009. un 2010. gada: Pasta nodaļas biznesa procesu modelēšana, izmantojot GRADE rīku Budžeta plānošanas diagrammas izstrāde, izmantojot rīku definēšanas platformu GrTP Klientu apkalpošanas biznesa procesu uzlabošana IT pakalpojumu sniegšanas uzņēmumā Datorikas fakultātes izglītības procesu modelēšana Gatavas biznesa sistēmas ieviešana uzņēmumā Ražošanas procesa kontroles un pārdošanas automatizācija uzņēmumā ABC Prasību izgūšanas un analīzes procesu sakārtošana precīzai klienta vajadzību specificēšanai Uzņēmējdarbības modelēšana un vizualizēšana A/S „Preiļu Siers” produkcijas uzskaites sistēma Efektīvas uzskaites principu realizācijas noliktavas informācijas sistēmā

2. SHOULD HAVE

Algoritmu teorijas izvēlētās nodaļas

Datu aizsardzība un kriptogrāfija

Datu bāzu praktikums

Datu noliktavas

DBPS Oracle

Diskrētā matemātika I

Diskrētā matemātika II

Ievads digitālajā projektēšanā

Informācijas sistēmu drošība

Kombinatorika

Lietišķie algoritmi

Mašīnorientētā programmēšana

Objektorientētā programmēšana

Operētājsistēmas

Operētājsistēmu koncepcijas

ORACLE projektēšanas rīki

Programmēšana II

Programmēšanas valodas

Programmēšanas valodu sintakse un semantika

Semantiskais tīmeklis

Tīmekļa tehnoloģijas II

Varbūtību teorija un matemātiskā statistika

VisualBasic

Sistēmanalītiķis šķērsgriezumā

Iedvesmojos no izstādes BODIES REVEALED reklāmas un uzrakstīju tādu nelielu SISTĒMANALĪTIĶIS REVEALED.

 Labs (un īss!) apraksts latviski, kas vispār ir sistēmanalīze.

Ilustrēts materiāls – arī latviski - kas patiesībā ir sistēmanalītiķis, kā arī šīs profesijas apraksts. Un vēl apraksts par profesiju.

 Sistēmanalītiķa oficiālais profesijas standarts.

Viena parasta darbdiena kāda sistēmanalītiķa mūžā

Sākšu ar atrunām – konkrētu darbu saturs vienmēr ir atkarīgs no darba uzdevuma – vai tā ir jaunas sistēmas izstrāde, vai esošas uzturēšana un papildināšana. Jaunas sistēmas izstrādes gadījumā darbdiena būs savādāka – tā var sastāvēt kā no saistītu materiālu lasīšanas visu dienu, tā no sarunām ar klientu un iekšējām sapulcēm, kā arī projektējuma rakstīšanas un/vai modeļa zīmēšanas. No malas skatoties – visu dienu sēž un klabina taustiņus. Vai staigā apkārt ar gudru sejas izteiksmi.

Paņemšu kā izvērstu piemēru sarežģītāku gadījumu – kurā paralēli notiek kā uzturēšana, tā dažādu jaunu izmaiņu pievienošana. Šis ir izdomāts stāsts un jebkura sakritība ar reālām personām un reāliem darbiem ir nejauša. Centos rakstīt reālistiski un ticami, taču nekādā gadījumā nevajag mēģināt šo ekstrapolēt uz visu pasaules sistēmanalītiķu visām darbdienām. 

8:20 Darbdiena sākas. Apsveicināšanās, datora ieslēgšana, puķes apliešana, kamēr dators startējas. E-pastu ātra pārlūkošana, vai ir kaut kas jauns vai steidzams parādījies. Šoreiz nav, ir tikai ziņojumi no testa vides robotiem, kas liecina, ka procesi notiek atbilstoši iecerēm. Tātad var strādāt pēc sava plāna – testēt programmētāju pabeigtās izmaiņas un labojumus, analizēt rezultātus, turpināt projektēt jaunās izmaiņas. Apskatās, ka uz nakti atstātais testa rezultātu datu analīzes skripts sekmīgi izpildījies un pēc brītiņa varēs pieķerties analīzei.

 8:35 Īsa vārdu apmaiņa ar projekta vadītāju par dienas plānu. Fonā visu dienu, kā vienmēr, nāks e-pasti – gan rīku ģenerēti par ziņojumu un uzdevumu statusa maiņām, gan no testu robotiem, gan kolēģu sarakste par projekta jautājumiem, gan dažas ziņas no vēstkopām par jaunumiem ar sistēmanalīzi saistītās jomās (e-pasti ir izveidoti, lai būtu ērti darbam, lai būtu operatīvi pamanāmi).

 8:45 E-pastu nopietna pārlūkošana, atbildēšana. Vienā apstiprina, ka jā, piedāvātais risinājums ir saprasts pareizi. Otrā, ka piekrīt kolēģa piedāvātajām izmaiņām citā risinājumā. Trešajā, ka atbildei nepieciešama detalizētāka analīze, kuru veiks triju dienu laikā. Pieraksta savā darbu plānā šo uzdevumu un termiņu.

 9:10 Ķeras pie testa skripta rezultātu analīzes. Tā kā pašu testēšanas un pārbaudes algoritmu ir izdomājis jau iepriekš, tagad vien saraksta numurētus pārbaužu pieturas punktus. Uzraksta vairākus SQL (pagaidu tabulu veidošana, salīdzinoši vaicājumi, nu, tāds vidēji sarežģīts SQL). Izpilda katru uzdevumu, atzīmē rezultātus (kamēr vaicājumi pildās, var pagūt pārskriet ar acīm ziņu virsrakstiem). Viens vaicājums atgriež aizdomīgu rezultātu – uzsāk rakstīt pārbaudes vaicājumu, šoreiz tas būs jau sarežģītāks SQL.

 10:05 Ienāk e-pasts par iespējamu problēmu programmā un uz šādiem ziņojumiem noteikti jāreaģē tūlīt. Pieraksta, ciktāl ticis ar iesākto darbu (tā kā nezina, kad pie tā atgriezīsies) un kāds solis bija ieplānots nākamais (lai pēc tam vieglāk ielekt atpakaļ uzdevumā), un pārslēdzas uz e-pastā aprakstītās situācijas analīzi. Apskatās, kā šī funkcionalitāte ir projektēta, sagatavo testēšanai vajadzīgos datus, darbina programmas testa vidē, skatās, kāda informācija kurā situācijā saglabājas datubāzē, secina, ka apstrāde notiek korekti un saprot, kāpēc radušās aizdomas par problēmu. Piezvana sūtītājam un īsumā izstāsta būtību, pēc tam uzraksta garāku skaidrojumu e-pastā un nosūta.

 11:05 Saņem informāciju, ka jāuzsāk konkrētu iepriekš projektēto izmaiņu izstrāde. Sagatavo datubāzes struktūras izmaiņu pieprasījumu un reģistrē darba uzdevumu programmētājam ar norādi, ka DB procedūras datu atlasei un trigeri datu tālākapstrādei sagatavos pats analītiķis.

 11:30 Atgriežas pie uzsāktās testu datu analīzes. Pabeidz datu vaicājumu (SQL), izpilda, secina, ka testpiemērs ir veiksmīgi uzķēris retu, specifisku situāciju, kuras apstrāde arī ir jāparedz. Izmaiņas DB procedūrā veiks pats, par laimi, to varēs izdarīt salīdzinoši ātri, apmēram stundas laikā. Īsi apraksta savu veikto analīzi pēc būtības, izsvītro konkrēto darbu no uzdevumu saraksta un pieraksta jaunu uzdevumu sev – iestrādāt labojumu. Aiziet, uztaisa tēju un atpūtina acis.

 12:15 Programmētājs pienāk pajautāt, kā rīkoties specifiskā situācijā. Pastāsta un, lai neaizmirstas, pieraksta komentārus pie darba uzdevuma, par ko vienojās.

 12:30 Kolēģi sauc pusdienās. Dodas ar’.

 13:00 Īsa iekšējā sapulce

 13:10 Lasa un atbild uz e-pastiem. Vienā apstiprina, ka izmaiņu būtība ir saprasta pareizi, otrā atbild uz jautājumu par funkcionalitāti, trešajā uzraksta savas domas par iecerēto algoritmu un papildinājumus tam. Dažos e-pastos pieraksta papildjautājumus un pārsūta atbildīgajiem kolēģiem. Dažus sev atzīmē kā darāmus darbus.

 13:40 Brīdi domā, vai turpināt vakar iesākto projektēšanu, vai rakstīt jaunās DB procedūras, vai pielikt no rīta atklāto vajadzīgo apstrādi. Novērtē, ka dokumentam līdz termiņam vēl ir laiks un ka programmētājām tāpat ir ko darīt, tāpēc ķeras pie testētās procedūras papildināšanas. Raksta, testē, testē, raksta, komentē kodu, testē, palaiž izpildei ilgāku datu analīzi vidē, kur tas netraucē darbu pārējiem. Redzams, ka ir ok. Iečeko un atzīmē konkrēto funkcionalitāti kā sekmīgi notestētu, kā arī pieraksta informāciju testētājam. Ķeras pie jaunajām procedūrām (šoreiz diezgan vienkāršs PL/SQL). Izdomā nosaukumus atbilstoši norunām, raksta, testē, testē, raksta, komentē kodu, ko nozīmē kurš parametrs, testē. Kad ir OK, uzliek testa vidē un dod ziņu programmētājam, ka, ciktāl no sistēmanalītiķa atkarīgs, ir izdarīts, procedūras var sākt lietot. Trigeri (vidēji sarežģīts) nolemj rakstīt rīt – pieraksta sev pie darba uzdevumiem.

 15:50 Jaunu, steidzami apstrādājamu e-pastu joprojām nav. Turpina vakar iesākto izmaiņu projektējumu. Vakar vakarā ienākušas pāris idejas galvā, pārspriež ar kolēģiem. Vienu izdiskutē un atmet, divas ir derīgas, tās apraksta. Lasa saistītos materiālus, uzzīmē ekrānformas skici.

 17:20 Vēlreiz pārlūko e-pastus, uz vairākiem atbild, atzīmē izdarītos darbus un sastāda plānu rītdienai, atzīmējot svarīgākos pa prioritātēm. Ja neuzradīsies ārkārtas darbi, tad rīt būtu labi pabeigt projektējumu, lai var izziņot apskati, kā arī domājams, programmētāji būs izdarījuši savus uzdevumus, tie būs jātestē un jāapstrādā tālāk. Arī trigeri būtu labi uzrakstīt un notestēt, lai vienlaikus ar programmētāja darba izpildi varētu sākt testēt funkcionalitāti kopumā. Izlasa pāris rakstus no vēstkopas un grāmatzīmi pieliek mapītē kolekcijai pie interesantiem rakstiem, kas var noderēt.

 Tā pamazām oficiālā darba diena arī beigusies. Neoficiāli darba domas vēl kādu laiku fonā griezīsies.

 Sistēmanalītiķa darba plusi

• Atkarībā no darbavietas iekšējām norunām, ja nav tikšanās ar klientu, iespējams, ka var ģērbties brīvi (vismaz – brīvāk) un staigāt kaut čībiņās (smukās, kārtīgās)
• Pieejams dators, internets, nereti arī iespēja pagatavot tēju vai kafiju
• Parasti ir darbi, kurus kādreiz var veikt no mājām
• Parasti ir iespēja vajadzības gadījumā vienoties par elastīgu darba laiku – kam lekcijas, kam bērnu koncerti, kam vēl kas
• Darbs pats par sevi mēdz būt ļoti interesants un daudzveidīgs – var kā dokumentus rakstīt un modeļus zīmēt, tā programmēt, kā vadīt prezentāciju, tā stūrītī neviena netraucēts lasīt materiālus – pēc vajadzības, pēc spējām un pēc interesēm
• Meitenēm varētu patikt, ka ir daudz kolēģu puišu, savukārt puišiem – ka kolēģes meitenes ir itin saprātīgas. Kaut gan – kādam tas var šķist arī mīnuss :-)
• Darba kolektīvs parasti ir motivēts un gudrs, tā kā šajā nozarē bez smadzenēm neiztikt
• Ja apnīk sistēmanalīze vai atrod sevī citu aicinājumu, vienmēr ir specializēšanās vai izaugsmes iespējas un praktiski jebkurā IT izstrādes virzienā – uz programmēšanu, uz testēšanu, uz grupas vai projekta vadību, uz kvalitātes vai datubāzes pārvaldību – kur sirds kāro un galva spēj
• Profesija, paldies datoriķu Dievam, ir visai pieprasīta un arī desiņai uz maizes var sanākt. Pie tam, ar šajā profesijā attīstīto domāšanu un pieeju darbam domāju, ka nebūtu sarežģīti arī piemācīties klāt un mainīt darbības lauciņu, sevišķi tajā, kurā ir specializējušies konkrētā darbā

Sistēmanalītiķa darba mīnusi

• Sēdošs darbs pie datora
• Daudz jādomā. Dažreiz dienas beigās galvā dūc kā transformatoru apakšstacijā
• Gluži kā advokātam un psihoterapeitam, ir jāprot turēt muti par konkrētām lietām un niansēm un vispār jābūt augstai iekšējās ētikas un savstarpējo attiecību kultūras latiņai
• Darba taustāmo sasniegumu atkarība no datora – uz neapdzīvotas salas tomēr būtu vieglāk izdzīvot, ja prastu arī malku skaldīt un ugunskuru iekurināt
• Jābūt gatavībā, ka kaut kas risināms, analizējams var „uzkrist uz galvas” jebkurā brīdī – t.i. nav garantijas, ka vienmēr izdosies iecerētajā laikā beigt darbdienu vai ka tiks pusdienās
• Jāprot pedantiski un akurāti strādāt, dokumentēt izdarīto, izpildīt dažādas iekšējās norunas
• Jābūt pacietīgam un iecietīgam, jāspēj vienu un to pašu ar smaidu uz lūpām skaidrot vairākas reizes, sarunāties, uzklausīt sarunbiedru, neuzspiest savu viedokli un vienlaikus prast pārliecinoši argumentēt savas domas
• Jāpierod pārbaudīt divreiz (un neticēt nevienam :-) )
• Būtu labi piemist spējai domāt ātri – tas sevišķi noder apspriedēs, kur izvirza risinājumu variantus
• Tā kā darbu apjoms var gadīties arī viļņveidīgs, ir jāpiemīt stresa noturībai un jāspēj, vismaz ļoti, ļoti jācenšas pēc iespējas nekļūdīties arī steigā
• Darba laikā parasti jābūt sasniedzamam 

Kvalitatīvas lietotāju dokumentācijas izstrāde

Šajā rakstā aplūkoti kvalitatīvas lietotāja dokumentācijas izstrādes aspekti, aprakstot dokumentācijas tapšanas procesā veicamos uzdevumus un sniedzot praktiskus ieteikumus.

Ievads

Analizējot veiksmīgi un neveiksmīgi iedzīvinātu programmatūru izstrādes pieredzi, redzams, ka galvenokārt tieši no programmatūras gala lietotāju apmierinātības ir atkarīgs, vai konkrētā programmatūra iedzīvosies (ar administratīvām metodēm vien programmatūru uzturēt pie dzīvības iespējams īslaicīgi). Programmatūras izstrādātājs, kurš parasti ir ieinteresēts produkta veiksmīgā iedzīvināšanā, pārsvarā komunicējas ar pasūtītāja pārstāvjiem un dažādu iemeslu dēļ nereti vispār nestrādā ar gala lietotājiem. Kā komunikācija ar tiem kalpo:

1)      pati programmatūra,

2)      lietotāja dokumentācija

un sekmīga rezultāta sasniegšanai tām abām jābūt kvalitatīvi izstrādātām. Šajā rakstā aplūkoti lietotāja dokumentācijas izstrādes aspekti, ar lietotāja dokumentāciju saprotot tradicionālo, drukāto dokumentāciju un tādu, kas lietojama analogi drukātai.

Lietotāja dokumentācija

Lietotāja dokumentācijā esošo informāciju bieži vien izmanto programmatūras palīga veidošanai un mācību materiālu izstrādē. Veicot pasūtītāja darbinieku apmācību darbam ar programmatūru, ieteicams lietotājus iemācīt strādāt arī ar lietotāja dokumentāciju.

Izplatītākie stereotipi un patiesība par dokumentētajiem un dokumentēšanu

Pastāv vesela kaudze ar stereotipiem – ka izstrādāt lietotāja dokumentāciju ir ļoti vienkārši, ka to var darīt jebkurš, kurš prot lietot Word, ka dokumentēšana ir vienmuļa un garlaicīga. Izplatītākie stereotipi un patiesība par dokumentētajiem un dokumentēšanu ir šādi:

Stereotips	Patiesība
“Uzrakstīt manuāli – kas var būt vienkāršāk par to”	Kvalitatīva lietotāju dokumentācija, kura tiek izstrādāta nevis formālam nodevumam, bet gan reālai lietošanai, ir nopietns, plānojams un rūpīgi vadāms darbs, kurš prasa gan IT, gan psiholoģijas zināšanas, gan atbilstošas rakstura iezīmes.
Dokumentētāja darbā praktiski nekādas zināšanas nevajag, pietiek, ja prot rakstīt Word	Dokumentētājam jābūt divdabim: gan labi jāorientējas IT, gan jābūt apveltītam ar izcilu valodas izjūtu un teicamām gramatikas zināšanām (labi, ja ir akadēmiskā izglītība vienā no šīm sfērām, tomēr filologa izglītība negarantē izcilu rezultātu – pārbaudīts praksē). Jāzina par  cilvēka uztveres īpatnībām un jāpārzina kvalitatīvas lietotāja saskarnes principi. Zinošus dokumentētājus bieži vien iesaista kā konsultantus lietotāja saskarnes izstrādē, testēšanā un uzlabošanā.
Par dokumentētāju var kļūt jebkurš	Dokumentētājam gan jāspēj veikt rutīnas darbs un pedantiski jāievēro projektā pieņemtie darbu reglamentējošie dokumenti un norunas, gan jāpiemīt iniciatīvai, radošai dzirkstij un fantāzijai, lai spētu lietotājiem saprotami izskaidrot sarežģītas lietas.
Dokumentēšanā var iesaistīt īslaicīgi bez darba esošos darbiniekus	Īslaicīgai piesaistei bez iepriekšējas apmācības un pieredzes var piesaistīt uz laiku citus darbiniekus, taču šādā situācijā būtiski palielinās risks, ka dokumentētāji aprakstīs to, ko zina, nevis to, ko vēlas zināt lietotājs. Šādā īslaicīgas piesaistes gadījumā nepieciešama sevišķi profesionāla dokumentācijas procesa vadība, rūpīgi izvēloties konkrētus uzdevumus šiem dokumentētājiem un pārraugot to izpildi.
Dokumentēšana ir vienmuļa un garlaicīga	Tā varētu šķist, ja darbu veic steigā un formālam nodevumam. Strādājot motivētā komandā un sakārtotā izstrādes vidē, dokumentēšana ir profesionāli izaicinošs un aizraujošs process, dialogs ar lietotāju un nemitīgi jāizdomā veidi, kā lietotāju iemācīt, kā palīdzēt saprast, kā izskaidrot, kā uzminēt utml.
Laba dokumentācija var izglābt sliktu programmu.	Ja programmatūra izstrādāta nekvalitatīvi un ir neērta darbam, dokumentācijā jāsniedz ieteikumi un risinājumi (workarounds), taču vislabākā dokumentācija neizglābs no bojāejas sliktu programmu.

Patiesībā kvalitatīvas lietotāja dokumentācijas izstrādāšana ir nopietns un sarežģīts darbs, kura veikšanai gan jāpārzina konkrētais problēmapgabals, gan jābūt IT speciālistam, gan jāpiemīt labām komunikācijas (sevišķi rakstiskās) spējām. No vienas puses dokumentētājam jāspēj pedantiski veikt rutīnas darbs, no otras puses jāpiemīt radošai dzirkstij, lai spētu lietotājiem saprotami izskaidrot sarežģītas lietas. Zinošs dokumentētājs parasti pārzina labas lietotāja saskarnes principus un var ieteikt uzlabojumus programmatūras lietotāja saskarnei, jo dokumentācijas izstrādes laikā var labi pamanīt nekonsekvences. Iesaistot dokumentēšanā cilvēku no malas, palielinās risks, ka dokumentētājs aprakstīs to, ko pats zina, nevis to, ko nepieciešams zināt lietotājam.

Lietotāja dokumentācijas komplekta saturs

Lietotāja dokumentāciju parasti sastāda triju veidu dokumenti, kuros dažādos griezumos tiek sniegta informācija par programmatūru un tās darbināšanu (divi pirmie dokumenti var būt apvienoti vienā, skaidri nodalot šos pēc būtības atšķirīgos materiālus):

1)    lietotāja instrukcija – programmatūras darbināšanas apraksts, kas ietver pilnu programmatūras aprakstu, paskaidrojot katru tā elementu (tipveida elementus, logus, katra loga visus laukus, visas ieprogrammētās pārbaudes, ziņojumus, utt.).

2)    lietotāja rokasgrāmata – skaidrojums par to, kā ar šīs programmatūras palīdzību izpildīt to vai citu funkciju (t.s. scenāriju), kas ietver programmatūras elementu savstarpējo sadarbību, izsaukšanas secību, funkcionalitātes ierobežojumus u.c.

3)    administratora rokasgrāmata – sistēmas administratoriem paredzēta dokumentācija, saistīta ar dažādu specifisku funkciju veikšanu.

Dokumentācija var sastāvēt no vie­na vai vairākiem dokumentiem atkarībā no izklāstāmās informācijas apjoma un audi­to­rijas vajadzībām. Parasti jaunai programmatūrai sākotnēji izstrādā gan instrukciju, gan rokasgrāmatu, sevišķi, ja auditorijas lielākā daļa ir nepieredzējuši lietotāji. Vairāku gadu prakse rāda, ka pieredzējuši datorlietotāji labprātāk strādā ar rokasgrāmatām (jo lietotājam pēc būtības savā darbā jāveic konkrētas biznesa funkcijas, nevis jāaizpilda atsevišķas formas, nekā ar instrukcijām, tāpēc līdz ar atjauninātu programmatūras versiju parādīšanos ir vērts vākt un analizēt lietotāju ieteikumus par to, vai vērts turpmāk uzturēt abu veidu dokumentus.

Lietotāja dokumentācijas plānošanas etaps

Kvalitatīvas lietotāja dokumentācijas izstrāde ir plānota aktivitāte, projekta komandā laikus plānojot un iesaistot dokumentēšanas speciālistus. Dokumentācijas plānošanas etapā jāveic šādi uzdevumi:

• ­jādefinē izstrādājamo dokumentu komplekts un jāiden­tificē mērķauditorija, lai noteiktu izklāsta stilu un detalizācijas lī­me­ni,
• iespēju robežās jāanalizē programmatūras izstrādes vide un paredzamās darbināšanas īpatnības, lai iezīmētu ieteicamāko dokumentēšanas veidu, stilu un paņēmienus,
• jāņem vērā pasūtītāja izteiktās vēlmes attiecībā uz lietotāja dokumentāciju,
• jāvienojas par izstrādes standartiem, ņemot vērā līgumā pausto apņemšanos (ja tāda ir),
• ja dokumentācija jāraksta vairāk nekā vienā valodā, tad papildus šajā rakstā minētajiem pasākumiem jāņem vērā arī laiks tekstu sinhronizācijai, jāplāno, kad un kā to sākt un darīt (man ir pieredze ar dokumentācijas izveidošanu un uzturēšanu trijās valodās – tas bija labs izaicinājums),
• vai un kā projekta situācija ļauj identificēt dokumentāciju, kā atškirt dokumenta laidienus, kā nodrošināt viennozīmīgu sasaisti ar dokumentēto programmatūru. Varianti ir vairāki: a) nodrošināt, ka ir pieejama tikai aktuālā dokumentācija, tādējādi garantējot aktualitāti b) ielikt dokumentācijā informāciju par aprakstītās programmas versiju. Tomēr, izvēloties pirmo, vienmēr jāpatur prātā, ka sarunā ar pasūtītāju vienmēr jābūt iespējai pārliecināties, ka abi runājat par vienu un to pašu dokumenta laidienu. Ja nav iespējams identifikāciju atkārtot katrā lappusē, der, piemēram, norunāt lappusi, kurā maziem burtiņiem to ierakstīt vai vismaz faila nosaukumā atspoguļot, sliktākajā gadījumā – dokumenta īpašībās (properties),
• kā arī citi konkrētā projekta situācijā nepieciešamie uzdevumi.

Atkarībā no projektā pielietotas izstrādes metodikas, iedibinātajiem kvalitātes pārvaldības mehānismiem, pastāvošajiem riskiem, iepriekšējas pieredzes u.c. faktoriem projekta izstrādes laikā tiek pieņemts lēmums, kurā brīdī uzsākt dokumentācijas rakstīšanu, un šis brīdis var atšķirties no sākotnēji ieplānotā. Svarīgi atrast īsto brīdi, lai izvairītos no situācijas, kad jāpārstrādā uzrakstīts teksts (labot bieži vien izrādās grūtāk, kā to pašu uzrakstīt no nulles) un lai nenotiktu tā, ka pēdējā brīdī steidzīgi tiek rakstīta dokumentācija, ietaupot uz kvalitātes rēķina. Prakse gan rāda, ka pat pie vislabākās plānošanas dokumentētāju slodze ievērojami palielinās, tuvojoties projekta nobeigumam, tāpēc jau laikus jāparedz, lai kopumā šī noslodze izlīdzinātos un mazinātos risks, ka pēdējā brīdī steidzīgi tiek rakstīta dokumentācija, ziedojot kvalitāti. Šo risku var samazināt, apzinoties dokumentācijas izstrādes procesa svarīgumu un ņemot vērā šajā rakstā sniegtos ieteikumus, tomēr domāju, ka praksē nekad neizdosies pilnībā novērst.

Lietotāja dokumentācijas izstrādes uzsākšana

Pirms dokumentācijas izstrādes uzsākšanas, dokumentētājiem, nepieciešamības gadījumā sadarbībā ar pieaicinātiem ekspertiem, kopīgi jāvienojas par:

• konkrētiem veicamajiem darbiem (piemēram, nodaļām dokumentā vai programmatūras funkcijām), to secību, sadalījumu, atbildīgajiem un termiņiem,
• konsekventas un vienveidīgas terminoloģijas (pazīmes lauks, izvēles rūtiņa, …) izmantošanu, norunājot mehānismu, kā darba gaitā ieviest jaunus terminus,
• organizācijā jau esošu iestrāžu (veidnes, tipveida satura rādītāji u.c.) izmantošanu vai pielāgošanu,
• dokumentācijas izklāsta stilu un detalizāciju (censties ne dziļāk par 3. līmeņa virsrakstu). Ideja: varētu izgudrot un piemēros izmantot kādu personu ar interesantu vārdu, kura lietotājiem asociētos ar konkrēto programmatūru. Varbūt pasūtītājam ir jau savs tēls, piemēram, Centis Ūbele? Ieteicams pārrunāt arī nepieļaujamos piemērus (ministrs Bin Ladens? Lietotājs Harijs Poters? Pensionārs Lāčplēsis? Kā uz tādiem reaģēs lietotājs?),
• vienoties, vai lietotāju uzrunā „Jūs”, vai lieto trešo personu, vai neitrālo: „Ja Jūs vēlaties dzēst dokumentu…”, „Ja lietotājs vēlas dzēst dokumentu”, „Ja nepieciešams dzēst dokumentu…”, „Ja jādzēš dokuments…”,
• vienoties, vai lietot pavēles formu, vai vajadzības „Nospiediet [OK]”, „Jānospiež [OK]”,
• vienoties, vai lietos tagadnes formu (atveras logs, atvērsies logs, tiks atvērts logs u.c.),
• katram gadījumam pārrunāt nepieciešamību nodrošināt, lai piemēros vai aprakstos neparādās reālu personu dati, piemēram, pašu dokumentētāju adreses,
• kur un kā iegūs korektus testa datus, vai dokumentācijā liks ilustratīvus piemērus ar skaidrojumiem, vai pareizi aizpildītus dokumentus kā piemērus,
• testa datu un fotografējamo programmatūras logu iegūšanas vidi un līdzekļiem (piemēram, vai dokumentācijā pieļaujams fotografēt logus ar reāliem datiem, kur un kā iegūt testa datus u.c.), rīku licencēm,
• attēlu apstrādi: vai pieļaujami papildus elementi uz attēliem, piemēram, norādes vai izcēlumi. Ja jā, tad kādā stilā? Vai dokumentētājiem ir rīks, kas nodrošina ērtu apstrādi attēliem? No prakses – ir projekti un situācijas, kurās ekrānattēli tiek fotografēti un pēc tam laboti, aizkrāsojot daļu datu vai aizstājot ar atļautām vērtībām,
• tehniskām izstrādes lietām, piemēram, dokumentācijas izstrādes vides piedāvāto iespēju izmantošanu šķērsatsaucēm, virsrakstu atkārtošanu, ja tabula ir izvietota uz vairākām lapām, failu glabāšanas vietu u.c.,
• dokumentu konfigurācijas pārvaldību – versionēšanu (1,2,a,b,…), melnrakstu nodalīšanu,
• nākošo kopīgas sanākšanas (dokumentu apskates) laiku,
• u.c. konkrētā projekta situācijā piemērotiem jautājumiem, piemēram, darba kārtību vienlaicīgai strādāšanai ar vienu dokumentu, uzrakstīto fragmentu nodošanas kārtību tālākai apstrādei utt.

Formāli šo vienošanos mēdz saukt par lietotāja dokumentācijas izstrādes uzsākšanas apskati, un dažreiz pasūtītājs vēlas saskaņot šīs apskates rezultātus.

Lietotāja dokumentācijas izstrāde

Dokumentācijas izstrādes laikā, pat tad, ja projektā pieejamas aktuālas un detalizētas prasību specifikācijas un projektējumi, nepietiek ar kopēt-ielīmēt no šiem dokumentiem, jo tie ir rakstīti citai auditorijai un citā griezumā. Dokumentētājs ņem vajadzīgo informāciju, pārveido to atbilstoši lietotāja dokumentācijas mērķauditorijai un papildus informāciju gūst:

• darbinot un pētot programmatūru, praktiski izspēlējot aprakstāmos scenārijus un modelējot piemērus,
• iztaujājot sistēmanalītiķus un testētājus gan par funkcionalitāti, gan par lietotājam ieteicamo rīcību problēmu un kļūdu gadījumos,
• caurskatot izmaiņu pieprasījumus un testēšanas pierakstus,
• iespējams, pat caurskatot programmatūras kodu (piemēram, lai atrastu kļūdu ziņojumu veidus vai precīzu kāda ziņojuma tekstu),
• iepazīstoties ar pasūtītāja darba specifiku, normatīvajiem aktiem un veidojot saturīgus piemērus, kuri pēc būtības atbilst lietotāju reāli veicamajam darbam, un nepieciešamības gadījumā tiekoties ar pasūtītāja darbiniekiem,
• u.c. konkrētā projekta situācijā piemērotos veidos.

Līdztekus jau minētajam par stilu, detalizācijas pakāpi un terminu vienveidību jāapzinās, ka lasītājiem – lietotājiem ir jāgūst vajadzīgā informācija un tajā pašā laikā tos nedrīkst pārslogot ar informācijas gūzmu, tāpēc papildus jau minētajam par stilu, detalizācijas pakāpi un terminu vienveidību jāņem vērā arī rakstiskās komunikācijas īpatnības, tostarp:

• noformējuma viendabīgums, līdzvērtīga līmeņa sadaļās atspoguļota līdzvērtīga detalizācija,
• noformējuma psiholoģiskie aspekti (piemēram, veids, kādā piesaistīt lietotāja uzmanību sevišķi svarīgai informācijai, krāsu lietošana),
• lasīšanas ērtums (piemēram, acis nepārslogojošs attēlu un teksta izvietojums un proporcijas),
• lietošanas ērtums (piemēram, apjomīgu dokumentu sadalīšana, kompaktā un ērti izdrukājamā formā pasniegta informācija, kas lietotājam varētu noderēt ikdienā),
• jaunu laidienu lietošanas ērtums (piemēram, varbūt lietotājam varētu būt ērti izdrukāt tikai mainītās sadaļas un aizstāt tās savā iepriekšējā izdrukā).

Lietotāja dokumentācija

Būtiskāko faktoru kopums

Kvalitatīvu lietotāja dokumentāciju nodrošina šādu būtiskāko faktoru kopums:

• sakārtoti programmatūras izstrādes procesi projektā (organizācijā), piemēram, izmaiņu pārvaldība, dokumentācijas izstrādes vadlīnijas u.c.,
• kvalificēts dokumentēšanas procesa vadītājs – pieredzējis eksperts ar skaidru vīziju par lietotāja dokumentāciju un tās mērķiem, spēju motivēt darbam dokumentētājus,
• akurāts galvenais atbildīgais par dokumentu (iespējams apvienot ar dokumentēšanas procesa vadīšanu), kurš uzņemas dokumenta tehnisko salikšanu un rediģēšanu,
• motivēta dokumentētāju komanda, kurā, ieteicams, vismaz puse ir ar iepriekšēju pieredzi dokumentēšanā,
• dokumentācijas testēšana, ko veic profesionāli testētāji saskaņā ar savām darba instrukcijām, metodiskajiem materiāliem u.c. materiāliem, kas pielāgoti tieši lietotāja dokumentācijas testēšanai (par šo plānoju sagatavot atsevišķu rakstu),
• dokumentācijas regulāras apskates, kurās piedalās gan tās izstrādātāji, gan pieaicināti citi organizācijā esošie eksperti (skats no malas),
• dokumentācijas izstrādes vides (piemēram, Word) iespēju pielietošana (piemēram, automātiskas šķērsatsauces),
• sadarbība ar pasūtītāju, gūstot praktiski pielietojamu darba scenāriju un piemēru idejas, kā arī rosinot pasūtītāju izteikt savas vēlmes,
• vienošanās ar pasūtītāju par dokumentācijā iekļaujamajām organizatoriskajām lietām (piemēram, vai likt atsauces uz MK noteikumiem, vai likt ieteikumu lietotājam, pie kā griezties, lai iegūtu lietotāja vārdu un paroli, vai atstāt to citām instrukcijām – jārēķinās, ka šāda organizatoriska rakstura informācija var mainīties un programmas dokumentāciju būs grūti uzturēt).

Lietotāja dokumentācija tenderos un ikdienā

Interesanti papētīt tenderos izteiktās prasības pret lietotāja dokumentāciju (iespējams, par šo tēmu sagatavošu atsevišķu rakstu). Lielākoties pausta uzticība standartiem (sevišķi Latvijas, prasot izstrādāt atbilstoši tam) un, acīmredzot, paļaušanās uz izstrādātāja profesionalitāti un godaprātu, jo prasības reti kur tiek minētas detalizēti, parasti tādas ir tenderos, kuru izsludinātājiem ir negatīva pieredze programmatūras ieviešanā, un pie iepriekšējās sistēmas trūkumiem norādīts, ka nav pietiekami kvalitatīvi izstrādāta lietotāja dokumentācija.

Vairākos tenderos, kuros aprakstīta iepriekšējā sistēma, pie tās trūkumiem minēts, ka nav pietiekami detalizēti vai kvalitatīvi izstrādāta lietotāja instrukcija – jo lietotāja dokumentācijas kvalitāti tās saņēmējs var novērtēt tikai pēc reālas darbošanās ar programmatūru. Ja sadarbība ir veiksmīga, tad iespējams lūgt papildināt vai pārstrukturēt dokumentāciju, taču visdrošāk ir veikt preventīvos pasākumus – gan iekļaut tenderī detalizētas prasības, gan izstrādes laikā darīt zināmas savas vēlmes lietotāja dokumentācijai. Izstrādātājam vienmēr ir vieglāk strādāt, zinot spēles noteikumus, un lielāka varbūtība, ka rezultāts tiešām atbildīs gaidītajam.

Būtībā, šajā rakstā sniegtos ieteikumus un akcentus var pielietot ne tikai programmatūras lietotāja dokumentācijas izstrādē. Par anekdoti kļuvis ne viens vien citāts no pavirši tulkotām vai izstrādātām sadzīves tehnikas lietošanas instrukcijām. Pat lasot lietotāja dokumentāciju cilvēka dzīvības funkciju saglabāšanai kritiskos brīžos (kurai teorētiski vajadzētu būt pārdomātai līdz pēdējam vārdam un izstrādātai pēc vislabākās prakses) – pirmās palīdzības sniegšanas instrukciju, diemžēl, atradu ne vienu vien klasisku kļūdu, ko bieži ievēroju arī programmatūras lietotāja dokumentācijā, piemēram, aprakstīta rīcība (saindēšanās gadījumā izraisīt vemšanu), minēti izņēmumi (nedrīkst izraisīt vemšanu, ja ir saindēšanās ar skābēm, sārmiem u.c.), taču nav paskaidrots, kā rīkoties šajos izņēmuma gadījumos. Šādi iespējami pārpratumi ir jāparedz  jau dokumentācijas izstrādes laikā. Ja tas nav izdarīts, tad tie noteikti ir jāievēro un  jānovērš dokumentācijas rediģēšanas laikā.

Jāatceras, ka, ja programmatūra izstrādāta nekvalitatīvi un ir neērta darbam, tad lietotāja dokumentācijā gan ir jāsniedz ieteikumi un risinājumi (workarounds), taču pat visperfektākā dokumentācija neglābs no izgāšanās sliktu programmatūru.

Nobeigumā – daži kuriozi no rediģēšanai iesniegtām lietotāju rokasgrāmatām (pārējie atrodami šeit: http://sistemanalize.wordpress.com/2011/03/09/joki-it/):

• aprakstot darbu ar mirušo personu reģistru, kā piemērs bija sniegts aizpildīts reģistrs ar tobrīd valdībā esošajiem ministriem,
• “ja uzspiedīsiet uz ēkas, tad parādīsies un aktivizēsies šīs ēkas īpašnieki”,
• “pagaidiet, kamēr logā parādīsies personas”,
• “tiks dzēsti visi parādnieki, kuru kadastrālā vērtība pārsniedz 10 latus”,
• “nospiežot tiks likvidēti visi lietotāji”.

Dokumentācijas izstrādei rekomendējamie standarti

LVS 66:1996 Informācijas tehnoloģija. Programmatūras lietotāja dokumentācija ir labs teorētiskais uzziņu materiāls par ieteicamo dokumentācijas struktūru un vispārīgo saturu. Maz konkrētu ieteikumu, taču to sniegšana nav standarta pienākums. Standarts ir viegli pielāgojams un izprotams, sevišķi, ja paralēli ir iespēja skatīt konkrētu dokumentācijas piemēru, kas izstrādāts pēc šī standarta, vai konsultēties ar zinātāju.

ISO/IEC 12119 Information technology – Software packages – Quality requirements and testing īsi un ļoti vispārīgi raksturo dokumentācijā iekļaujamo obligāto minimumu, lai dokumentāciju vispār varētu uzskatīt par kvalitatīvu.

IEEE/EIA J-STD-016  Standard for Information Technology. Software Life Cycle Processes. Software Development) detalizēts un ļoti apjomīgs, veidots visiem dzīves gadījumiem, un ar to iepazīties ir vērts ikvienam lietotāja dokumentācijas izstrādes vadītājam. Reālajā dzīvē šo standartu parasti pielāgo, kas praktiski izpaužas kā izvēlēta vajadzīgā prasību apakškopa dokumentācijai.

ISO/IEC 15910:2004 – ISO/IEC 12207 -dokumentēšanas procesa izvērsums. Lietotāja dokumentācijas izstrāde ir process ar dzīves ciklu, kuram ieejas dati, procesa plāna izstrāde un tajā iekļaujamās informācijas tipi, mērķauditorijas noteikšana, procesa veikšanai nepieciešamo resursu aprēķināšana, procesa laikā veicamās aktivitātes, izejas dati – rezultāti. Ļoti vispārīgi apraksta prasības noformējumam, neiedziļinoties detaļās  Pielikums ar dokumentācijas izstrādes darbietilpības novērtējumu vairākos griezumos un paņēmienos
Nosaka, ka dokumentam vismaz vienreiz jāveic lietojamības testēšana, definējot prasības, plānojot testus, apstrādājot rezultātus.

ISO/IEC FDIS 18019:2004 – Vadlīnijas liet. dok. izstrādei – lietotāju vajadzību noteikšana, iekļaujamā informācija un tās pasniegšana. Iekļauti pārbaudes punkti procesa, lietojamības testu un satura plānošanai, teksta noformējumam, ir kontroljautājumu saraksti procesa plānošanai, auditorijas analīzei, noformējumam, testēšanas etapam (izceļot apskates, lietojamības testus, sistēmas testus), saturam, navigācijai, noformējumam. Ņemot par pamatu standartā esošos kontroljautājumu sarakstus un papildinot tos, var sagatavot labu pamatu dokumentācijas testēšanai

IEEE Std 1063-2001 (atkārtoti apstiprināts 2007) – aprakstīts lietotāja dokumentācijas struktūra un saturs, komponentes (titullapa, satura rādītājs, attēlu saraksts, alfabētiskais rādītājs u.c.) un ieteicamās satura vienības tajos. Pozitīvi, ka daudzas rekomendācijas ir aprakstītas izmērāmā veidā, piemēram, ieteicami ne vairāk kā 4 līmeņu virsraksti, elektroniski vajadzīgo informāciju vēlams atrast ar ne vairāk kā 3 klikšķiem, satura rādītāju veido, ja dokumentam ir vairāk kā 8 lapas, attēlus numurē, ja to ir vairāk kā 5 u.c. (uz šī standarta iepriekšējās versijas bāzes ir izstrādāts LVS66-96)

Raksts bāzēts uz manas oriģinālās publikācijas žurnālā “Datorpasaule” 2003.gadā