Raksta lasīšanai nepieciešamais tehnisko zināšanu līmenis: ⭐⭐⭐⭐⭐ (zems)
Puses un to vispārīgās atbildības jomas
Kad Pasūtītājs un Izstrādātājs vienojas par projekta izstrādi, abu pušu darbinieki faktiski kļūst par vienu komandu, lai roku rokā sasniegtu kopīgu - projekta - mērķi.
Katra projekta izstrādē iesaistītā puse, lielākoties tie būs Pasūtītājs un Izstrādātājs, atbild par savu jautājumu kopumu. Šo kopumu ietvaros pēc tam tiek definēti konkrēti uzdevumi, kas tiek piešķirti atbildīgajām personām, kas veido projekta komandu.
Pušu vispārīgās atbildību jomas dalās šādi:
| Pasūtītāja puse | Izstrādātāja puse |
|---|---|
|
|
Projekta komanda
Projekta kontekstā gan Pasūtītāja, gan Izstrādātāja puses ir viena komanda. Tā ir partnerība starp visiem iesaistītajiem, kur katrs dalībinieks pilda konkrētu lomu vai vairākas.
IT projektos visbiežāk sastopamas šādas lomas:
- Projekta īpašnieks (eng. Project sponsor)
- Projekta uzraudzītājs vadības līmenī
- Produkta īpašnieks
- Projekta vadītājs Pasūtītāja pusē
- Biznesa analītiķis
- Sistēmas analītiķis
- Projekta vadītājs Izstrādātāja pusē
- Scrum kapteinis (eng. Scrum master)
- UX dizainers un UI dizainers
- Galvenais izstrādes inženieris
- Sistēmas arhitekts
- Izstrādes inženieri jeb programmētāji
- QA inženieri
- Testētāji
- Gala lietotāji
- Ieinteresētās personas (eng. Stakeholders)
Katram projektam būs sava struktūra, kas definēs nepieciešamās lomas. Komandu izveido uz projekta laiku, un tā sastāv no dalībniekiem, kas faktiski īsteno projektu un kuriem ir uzdevumi projekta ietvaros. Ja nepieciešams, darba veiksmīgas pabeigšanas nolūkā projekta gaitā var tikt mainītas vai piesaistītas papildu atbildīgās personas.
Attēlā redzamas lomas, kas veido minimālo un optimālo projekta komandu, kas nepieciešama projekta īstenošanai. Ar zaļu attēlotas pastāvīgās lomas jeb projekta kodols, ar dzeltenu - lomas, kas izstrādes gaitā piedalās pēc nepieciešamības, savukārt ar līnijām apzīmēti pamata komunikācijas virzieni.
- Lomas, kuras veido projekta komandas kodolu - bez kurām nevar. Tās aktīvi piedalās ikdienas procesos.
- Lomas, kuras projektam pieslēdzas epizodiski: ikdienas procesos projekta ieviešanas laikā var nebūt klātesošas, tomēr ir nepieciešamas, sasniedzot konkrētus projekta stūrakmeņus.
- Lomas papildus kodola lomām optimālā projekta struktūrā. Šīs lomas atkarībā no projekta izmēra un specifikas nereti mēdz tikt apvienotas vienā komandas dalībniekā, kurš nosedz vairāku lomu atbildības sfēras, vai pārklāties ar citām lomām.
- parāda komunikācijas virzienus.
Lomu apraksti un atbildības
Piemēri no dzīves:
- Projekta vadītāja un Produkta īpašnieka lomām Pasūtītāja pusē katrai ir sava kompetence un atbildība, bet faktiski abas šīs lomas projektā pilda viens cilvēks, pēc nepieciešamības konsultējoties ar Projekta īpašnieku.
- Projekts ir tehniski specifisks, un Izstrādātāja pusē Biznesa analītiķa un Sistēmas analītiķa lomas tik ļoti saplūst, ka abas uzņemas viens cilvēks ar atbilstošu kompetenci.
- Izstrādātāja pusē netiek izdalīts ne atsevišķs Galvenais izstrādes inženieris, ne Sitēmas arhitekts, bet šīs lomas pilda dalībnieki no ikdienas izstrādes procesos iesaistītās komandas. Viņi uzņemas atbildību par tehnoloģisko ievirzi un koda kvalitāti un pēc nepieciešamības konsultējas ar kolēģiem, kas projektā paši nepiedalās.
- Pasūtītājs ir start-up tipa kompānija ar diviem dalībiekiem, kas paši ir Projekta īpašnieki, abi ir Produkta īpašnieki, abi testē piegādātos risinājumus, abi vada projektu - viens atbild par dokumentālo, otrs - tehnisko pusi. Divi dalībnieki pārvalda pilnu komandas lomu spektru Pasūtītāja pusē.
- Projekta biznesa prasību definēšana ir Pasūtītāja atbildībā, bet, balstoties iepriekšējā pieredzē un kompetencēs, Izstrādātāja puse palīdz tās nodefinēt, lai gala rezultāts maksimāli atbilstu reālo gala lietotāju prasībām. (Par priekšizpēti sīkāk iespējams lasīt šeit.)
IT projekti ir dažādi un interesanti kā pati dzīve, tāpēc nereti teorijā aprakstītās lomas savstarpēji saplūst, pārklājas un papildina viena otru. Liela nozīme šeit i komandas locekļu iepriekšējai pieredzei, prasmēm, un pāri visam - savstarpējai komunikācijai.
Tālāk iespējams detalizētāk iepazīties ar klasisku atbildību un pienākumu dalījumu pa lomām.
Lomas Pasūtītāja pusē
Projekta īpašnieks
Projekta īpašnieks (no angļu valodas - Sponsors) nereti ir arī projekta idejas autors vai tas, kurš definē projekta ieviešanas mērķi. Projekta īpašnieks ir arī tas, kurš lemj par resursu piešķiršanu projekta izpildei un ir galvenais lēmumu pieņēmējs.
Produkta īpašnieks
Produkta īpašnieks ir Pasūtītāja pārstāvis, kurš ir atbildīgs par projekta gala rezultātā radīto produktu. Tā galvenie pienākumi:
- Prasību definēšana;
- Nodrošināt komunikāciju ar Izstrādātāja pārstāvjiem, piedalīties regulārajās sanāksmēs un atbildēt uz izstrādātāju jautājumiem, sniegt nepieciešamo informāciju;
- Pieņemt lēmumus ar projekta sfēru saistītajos jautājumos.
Projekta vadītājs Pasūtītāja pusē
Praksē nereti pārklājas ar Produkta īpašnieka lomu.
Galvenie pienākumi:
- Nodrošināt komunikāciju ar Izstrādātāja pārstāvjiem. Piedalīties regulārajās sanāksmēs un atbildēt uz izstrādātāju jautājumiem, sniegt nepieciešamo informāciju;
- Pieņemt lēmumus ar projekta sfēru saistītajos jautājumos (termiņš, budžets, prioritāšu secība, izmaiņu pārvaldība);
- Nodrošināt vidi, kurā tiks uzstādīta programmatūra;
- Nodrošināt komunikāciju ar trešajām pusēm (riski, kas saistīti ar trešo pušu iesaisti projektā, aprakstīti risku tabulā);
- Nodrošināt Izstrādātāju ar testēšanai nepieciešamajiem datiem;
- Nodrošināt sistēmas testēšanai nepieciešamos resursus un vadīt testēšanas procesu gan posmu, gan visa projekta nodošanas fāzē;
- Nodevumu pieņemšanas procedūras pārvaldība.
Gala lietotāji
Lietotāji ir tie, kas izmantos projekta rezultātā izstrādāto sistēmu. Ir svarīgi šos cilvēkus iesaistīt projekta prasību definēšanas fāzē, izstrādes fāzē un testēšanā.
Ieinteresētie dalībnieki
No angļu valodas Stakeholders jeb ieinteresētie dalībnieki ir tie, kurus tieši ietekmēs projekta rezultāti: uzņēmuma vadība, stratēģiskie partneri, likumdevēji, konkurenti u.c.
Lomas Izstrādāja pusē
Projekta uzraudzība vadības līmenī
Pienākumi:
- Stratēģiskā līmenī kontrolēt projekta realizācijas plānu;
- Nepieciešamības gadījumā iesaistīties konfliktsituāciju risināšanā starp Pušu pārstāvjiem.
Projekta vadītājs Izstrādātāja pusē
Izstrādātāja puses Projekta vadītājs ir kā tilts starp Pasūtītāju un izstrādes komandu. Projekta vadītājs ir tas, kurš atbild par “kurš, ko, kur, kad un kāpēc” projekta plāna griezumā un seko līdzi, lai tiktu sasniegti projekta mērķi.
Galvenie pienākumi:
- Kontrolēt ar projekta sfēru saistītos jautājumus (termiņš, budžets, prioritāšu secība);
- Definēt projekta izstrādes laika plānu;
- Definēt komunikācijas plānu;
- Projekta resursu pārvaldība;
- Uzdevumu sadale komandas ietvaros;
- Izstrādes komandas snieguma analīze projekta sfēras griezumā;
- Izmaiņu identifikācija un pārvaldība;
- Risku pārvaldība;
- Projekta sanāksmju protokolēšana;
- Statusa atskaišu gatavošana;
- Nodevumu procedūras pārvaldība.
Scrum kapteinis
Darbojoties Agile metodoloģijas Scrum ietvarā, viena no lomām Izstrādātāja pusē ir Scrum kapteinis (eng. Scrum Master).
Galvenie pienākumi:
- Uzraudzīt, lai darba norisē tiktu ievērotas Scrum vadlīnijas;
- Visu uzdevumu izpildei pastāvošo šķēršļu likvidēšana;
- Projekta sanāksmju organizēšana un protokolēšana;
- Atbalsta nodrošināšana Produkta īpašniekam prasību un darba uzdevumu definēšanā.
Praksē, arī neizmantojot specifiski Scrum ietvaru, šai lomai raksturīgos pienākumus mēdz uzņemties Projekta vadītājs.
UX dizainers un UI dizainers
Galvenie pienākumi:
- Pasūtītāja definēto funkcionālo prasību analīze;
- Lietotāju izpēte, aptaujas;
- Definēt risinājuma lietojuma arhitektūru (UX), to optimizēt;
- Sistēmas vizuālu prototipu izstrāde;
- Lietojamības testēšana;
- Definēt sistēmas vizuālās vadlīnijas (UI);
- Dokumentēt ar dizainu saistītos lēmumus.
UI dizaina fokuss ir lietotāja saskarne: grafiskais dizains, satura formatējums, stilistika. Atbild par to, kā sistēma izskatās.
UX dizaina galvenais uzdevums ir nodrošināt nevainojamu lietotāja pieredzi, izmantojot izstrādāto sistēmu. UX dizaineri analizē lietotāju uzvedību un ekspektācijas par sistēmas darbību, veidojot viegli uztveramu lietojuma arhitektūru. Atbild par to, cik ērti sistēmu ir lietot.
Par dizaina izstrādes procesiem sīkāk iespējams lasīt šeit.
Biznesa analītiķis
Biznesa analītiķis ir atbildīgs par biznesa vajadzību pārveidi prasībās un to atbilstošu dokumentēšanu pirms izstrādes uzsākšanas.
Galvenie pienākumi:
- Biznesa procesu izpēte un analīze;
- Prasību apkopošana, formalizēšana un saskaņošana ar Pasūtītāju;
- Priekšlikumu izstrāde par nepieciešamām izmaiņām esošos vai plānotos procesos;
- Dokumentācijas izstrāde.
Sistēmas analītiķis
Šīs lomas galvenais mērķis ir biznesa prasību pārvēršana tehniskās prasībās izstrādātājiem, izveidojot visatbilstošako sistēmas tehnisko dizainu.
Praksē nereti pārklājas ar Biznesa analītiķa un Sitēmas arhitekta lomām.
Galvenais izstrādes inženieris
Tilts starp izstrādes komandu un Projekta vadītāju un/vai Biznesa analītiķi, iedodot projekta tehnisko virzienu.
Sistēmas arhitekts
Galvenie pienākumi: definēt tehnisko un funkcionālo sistēmas arhitektūru.
Praksē nereti pārklājas ar Sistēmas analītiķa un Galvenā izstrādes inženiera lomām.
Izstrādes inženieri jeb programmētāji (back-end, front-end)
Galvenās atbildības:
- Projekta izstrāde un ieviešana atbilstoši definētajiem darba uzdevumiem un kompetencei;
- Progresa dokumentēšana;
- Uzdevumu darbietilpības vērtējumi.
Front-end programmētājs strādā pie projekta redzamās daļas, nodrošinot gludu saskarnes un biznesa loģikas komunikāciju.
Back-end programmētājs strādā pie biznesa loģikas ieviešanas klientam neredzamajā, servera, pusē.
QA inženieris
Galvenie pienākumi:
- Sistēmas veiktspējas, regresa un citu automatizēto testu izstrāde;
- Code review veikšana kolēģu darbam.
Testētājs
Galvenie pienākumi:
- Izstrādes prasību analīze;
- Atbilstošu testa scenāriju definēšana;
- Manuālā testēšana un konstatēto kļūdu reģistrācija.