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ņēmumiemai, 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?

. 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!

Advertisements

2 responses to this post.

  1. Posted by Kaspars Omuls on 24/05/2011 at 09:01

    Paldies par rakstu. Domāju, ka ir vērts šādu apkopojumu veikt.

    Tomēr, man liekas, ka raksts apiet vairākus svarīgus aspektus. Lai gan – dabiski – visi cer uz labu sadarbību un tā ir visiem vajadzīga, tomēr projekta gaitā tā izvēršas tāda, kā cilvēki (visas puses) to prot izveidot. Tomēr, pastāv vairāki dabiski konflikti, par kuriem nevajadzētu aizmirst.

    1. par viendienīša domāšanu, jeb kvalitāte vs izmaksas
    Jāsaka, ka, pēc manas pieredzes, taisni projektu vadītājs bieži vien ir gatavs upurēt kvalitāti termiņu dēļ. Jo analītiķis pēc būtības ir ieinteresēts labā kvalitātē (kaut vai tā paša brenda dēļ), kamēr projektu vadītājs daudz vairāk ir ieinteresēts resursu ekonomēšanā. Tāpēc, vismaz man ir nācies saskarties ar ierobežojumiem projekta sākumā (neanalizē to, raksti dokumentu šādā veidā, utt). Projekta beigās, kad viss neizdarītais iznāk gaismā, to gribot negribot ir jāizdara. Man līdz šim nav izdevies atrast labu veidu, kā šādas attiecības risināt. Domāju, ka laba sadarbība ir iespējama tad, ja arī projektu vadītājs labi apzinās šādas pieejas sekas (bet ir jau bijis tā, ka vienkārši pasaka “jā, bet čakarēšanās vienmēr ir bijusi, kāpēc tu gribi, lai šoreiz būtu savādāk”. Tomēr, galu galā vienmēr ir bijis tā, ka ilgākā termiņā rodas problēmas)

    2. Cik esmu novērojis, scope creep bieži vien rodas divu iemeslu dēļ. Pirmais – neviens nezina, kāds ir precīzs scope (un es teiktu, ka tas neizdarītais mājas darbs pirmkārt tiem cilvēkiem, kas slēdza līgumu, un otrkārt, PM, kas uzņēmās šo projektu, nezinot tā saturu), un otrkārt – cilvēkiem ir bail teikt klientiem nepatīkamas ziņas. Protams, loģiskā rīcība no analītiķa puses (un arī no PM puses) ir scope iespējami ātri nofiksēt, tomēr ne vienmēr tas notiek. Un attiecības ar klientu pārvēršas par tādu manipulēšanu un balansēšanu, un tādas ir arī iekšējās attiecības – jo kāds tomēr būs vairāk vai mazāk tas, ko vajadzēs vainot pie neizbēgamajām nepatikšanām.

    3. Autore minēja vārdu “subordinācija”. Jāsaka, ka cik esmu lasījis par grupu vadību, tad jaunāka pieeja ir – izvairīties no hierarshiskas organizācijas un klasiski definētām lomām, un ļaut cilvēkiem izpausties atbilstoši spējām, komandai organizēties pašai. Arī mana paša pieredze liecina, ka šādos gadījumos rezultāti ir labāki

    Atbildēt

  2. Tiešām foršs apkopjums. Daži komentāri:
    Par 3šo punktu gribēju vēl piebilst, ka vismaz manā praksē iekļaušanās projekta sfērā (scope) ir tiešām ļoti būtisks faktors un ļoti bieži ir šķēpi lauzti par to, ka ir sasolīts vairāk nekā darba uzdevumā, piedāvājumā vai whatever kur iecerēts. Nekad īsti neesmu varējis to sparast, kāpēc tā notiek, bet visdrīzāk tāpēc, ka gribas izlikties labam un uz papīra jau ir tik viegli kaut ko uzrakstīt…
    Kas attiecas uz uz deguna bāšanu citur – tad iespējams no konkretā projvada viedokļa tas varbūt ir slikti, bet saprātīgā apmērā no visas o-jas viedokļa tas pat varētu būt labi, jo ne vienmēr visi zin visu.
    Jā un par pašu cīņu – tas manuprāt ir ļoti arī atkarīgs no o-jas, ja o-jā šāda cīņa vēsturiski ir izveidojusies, tad būs diezgan grūti ietekmēt un mainīt uz labo pusi. Man gan par laimi šādās iestādēs nav nācies strādāt :)

    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: