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.

Advertisements

4 responses to this post.

  1. Man vajag profesionāli kas var izveidot sakarīgu mājaslapu, bet spriezōt pār internētā pieejamās informācijas nezinātājs var nojūgties, tāpēc, lai atrastu sev piemērotāko programmētāju, izveidoju domubiedru grupu draugos.

    Laipni aicināti visi kam ir sakars vai ir interese par IT (progammēšanu , majaslapu izveidi, datorprogammām utt).

    http://www.draugiem.lv/group/18420798/programmetaji/

    Atbildēt

  2. Posted by Ģirts Karnītis on 09/12/2011 at 16:33

    Ja pa lielam – ko dara analītiķis? Principā tulko to, kas rakstīts dažādos biznesa dokuemntos un to, ko stāsta biznesa pārstāvis, tādos terminos, kurus saprot programmētāji.
    Kāpēc tas vajadzīgs? Tāpēc, ka nav valodas, kura būtu gana biznesa oreintēta, lai to saprastu biznesa pārstāvji un spētu tajā runāt, un tanī pašā laikā šī valoda būtu pietiekoši precīza un saprotama programmētājiem.
    Analītiķis ir kā tulks pa vidu un ja kāds domā, ka kaut reizi kāds klients saprot to, kas rakstīts specifikācijā, ko viņš ir parakstījis – NETICU.
    Prastais secinājums – nepieciešama valoda, kura būtu saprotama no vienas puses biznesa pārstāvim un no otras puses programmētājam. Tas ir netriviāls “topiks” un ar to es nodarbojos jau kādus gadus, līdz ar to ir pieredze un vairākos projektos šādas valodas ir pielietotas, bet tas ir garš stāsts, kuru man ir slinkums rakstīt.

    Atbildēt

  3. Paldies par rakstu!

    Dažas refleksijas.

    Personīgi es nevelku tādu striktu robežu starp programmēšanu, sistēmanalīzi un biznesa analīzi. Mērķis ir strādājoša programma, un viss pārējais ir nepieciešamais ļaunums, lai varētu noslēgt līgumu un uzbūvēt komunikācijas tiltu starp klientu un programmētāju.

    Vita, Tu raksti par “analīzes fāzi”, bet man liekas, ka analīzes fāze (t.i., ūdenskritums) ir kļūda pati par sevi. Tā ir vai nu pārāk īsa, un klienta smadzenēs nepagūst nobriest pietiekoši labi risinājumi; vai arī pārāk gara – sāk mainīties ārējie apstākļi, un tas, kas bija taisnība sākot projektu, nu jau ir meli.

    Vēl, dažādās kompānijās cilvēki strādā mazliet savādāk. Piemēram, man diezgan reti ir iespēja zināt, kas programmēs manis nospecificēto. Tāpat, manos iepriekšējos darbos (pat vienā kompānijā dažādos laika periodos) ir bijis atšķirīgs viedoklis par to, cik precīzu specifikāciju programmētājam dot – ja programmētājs zina biznesu, tad precizitātes pakāpi vajag mazāku.

    Parasti jau laika nepietiek, un es par prioritāti uzskatu pēc iespējas pilnīgi identificēt scope, tāpēc noklusētās vērtības, lauku formāti un tādas lietas bieži paliek novārtā. Apzinos, ka grēkoju, bet tai pat laikā tas ir mazāks ļaunums, nekā noklusēto vērtību dēļ atstāt neapzinātu kādu use case.

    Programmētāji ir tāda intraverta profesija, un viņi diemžēl nesaprot vienu lietu – to, ka jebkurā komunikācijā ir informācijas zudumi. Kā zināms, neverbālā komunikācija satur lielāko daļu informācijas; komunicējot ar dokumenta starpniecību, zudumi ir milzīgi. Pat pieņemot to, ka dokumentā nav kļūdas, tas ir pilnīgs, u.t.t.. Programmētājs var perfekti norealizēt specifikāciju, tomēr, no klienta viedokļa viņš būs uztaisījis moku rīku – jo veidojamās sistēmas gars ķēdītē klients -> analītiķis -> programmētājs ir pazudis.

    Tāpēc rodas jautājums, kāpēc mēs tos dokumentus rakstām? Manuprāt, vairumā gadījumu atbilde ir – lai mums būtu ko piekabināt klāt pie līguma un zināt, kurš nepilda saistības. Un iekasēt no viņa naudu. Vai zināt, ka saistības ir izpildītas. Un iekasēt naudu par to izpildi. $$$

    Pretējā gadījumā, specifikāciju rakstīšanas prakse būtu jānīdē laukā, un jāaizstāj ar cita veida komunikāciju – tādu, kuras pamatā ir personiska saskarsme, modeļi, dažāda veida piezīmes, wiki utt. Kaut kā šitā http://www.agilemodeling.com/ Tas nenozīmē, ka notiek informācijas zaudēšana – protams, ārējie interfeisi ir jāapraksta, un lietas, kas var tikt nodotas nezināmiem ārējiem piegādātājiem un piegādātāji var tikt mainīti, ir jāspecificē. Tomēr, ir starpība, vai specificēšana notiek kā obligāts izstrādes posms, vai kā post factum dokumentēšana tad, kad tas ir vajadzīgs.

    Tas laikam tā pirmajā acu uzmetienā būtu viss.

    Atbildēt

  4. Posted by e-remit on 18/11/2011 at 17:11

    Man ir sanācis strādāt abās “frontes” pusēs un vēl piehaltūrēt par testētāju, bet nu pašlaik programmēju vispār bezdokumentācijas, bieži izmaiņu gaisotnē… ;)
    Ko esmu novērojas, bieži programmētājam jāprot uzdot jautājumu, tajā ietverot arī ceļu, kā līdz tam nonāca; savukārt sistēmanalītiķim jāsaprot, ko tieši programmētājs nesaprot.
    Bet jautrākais praksē – savulaik man jautāja, kāpēc es uztaisīju tā, kur teicu, ka tā bija rakstīts. tikai tad SA saprata, ko iz uzrakstījuši. :D

    Atbildēt

Mans viedoklis:

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

WordPress.com Logo

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

Twitter picture

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

Facebook photo

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

Google+ photo

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

Connecting to %s

%d bloggers like this: