Archive for the ‘Programmatūras izstrāde’ Category

Programmatūras iegāde


Programmatūras iegāde

IT speciālisti zina stāstīt, ka bija laiki, kad klīda nostāsti par veikliem darboņiem, kuri prata pārliecināt pasūtītāju, ka 200 megabaitu disks mēneša laikā nodilst līdz 20 megabaitiem, bet programmatūra „karas” tāpēc, ka biti sprūst šaurajā kabelī. Lai gan šie laiki ir jau (cerams) pagājuši, tomēr izpratne par programmatūras izstrādi nāk tikai par labu savstarpējai pasūtītāja un izstrādātāja sadarbībai. Cik dziļa izpratne nepieciešama – vai pietiek notiekošo saprast vispārīgos vilcienos, vai nepieciešams pamatīgi iedziļināties, tas ir atkarīgs no konkrētā projekta specifikas un ar to saistītās pasūtītāja motivācijas iedziļināties programmatūras izstrādes niansēs. Lai kā būtu progresējušas modernās tehnoloģijas, programmatūras iegādes stūrakmens joprojām ir sadarbība starp cilvēkiem ar visām no tā izrietošajām pozitīvajām un ne tik pozitīvajām sekām.

Kāpēc IT speciālisti mīl piesaukt dažādus standartus?

IT nozare ir salīdzinoši jauna, un tās attīstība bija izkliedēta pa visu pasauli un norisinājās paralēli neskaitāmās vietās, līdz ar to pasaulē uzkrājās milzīgs pieredzes apjoms par to, kādi procesi norisinās izstrādē, kādu informāciju un kur vērts iekļaut un kā izstrādi vadīt. Nozares standarti patiesībā ir šīs pieredzes apkopojums, esence, kurus var iedalīt divās lielās grupās:

  • procesu aprakstošie standarti,
  • gala rezultātu aprakstošie standarti.

Standartus pamatā izmanto, lai:

  1. demonstrētu, ka organizācija strādā pēc pasaulē atzītas un rekomendētas sistēmas un veic nepieciešamās aktivitātes – šajā gadījumā deklarē procesa atbilstību standartam,
  2. apliecinātu, ka organizācijas sagatavotie izstrādātie produkti, t.sk. dokumenti satur noteiktus informācijas vienumus, kuru esamība ir obligāts priekšnosacījums produkta kvalitātei – šajā gadījumā deklarē produkta atbilstību standartam,
  3. pasūtītājam būtu atskaites punkts, pret ko novērtēt saņemtā produkta kvalitāti papildus savām tiešajām prasībām. Piemēram, ir pasūtīts dokuments „Programmatūras prasību specifikācija”. Teorētiski, ja līgumā figurē tikai šāds nododamā dokumenta nosaukums bez jebkādām citām kvalitāti raksturojošām prasībām, kas var liegt izstrādātājam uzrakstīt 2 lapiņas ar tekstu, nosaukt to par „Programmatūras prasību specifikāciju” un iesniegt? Lai izvairītos no šādas situācijas, ir vairāki risinājumi, tostarp: pieprasīt atbilstību standartam, veidot darba grupu kopīgām dokumenta apskatēm izstrādes laikā, var piesaistīt konsultantus no malas, bet noteikti ir jābūt prasībai par rezultāta atbilstību kaut kam, lai būtu uz kā pamata pieprasīt produkta kvalitātes uzlabošanu.

Vērtējot dokumentu atbilstību IT izstrādes standartiem, ir jāsaprot, ka šajā jomā nav jānodrošina mehāniska 1:1 atbilstība. Galvenais, lai standartā rekomendētie vai pieprasītie informācijas vienumi būtu tādā vai citādā veidā atrodami attiecīgajā dokumentā. Citās nozarēs atbilstību standartam izmērīt ir salīdzinoši vienkāršāk, ja, piemēram, ir zināms, ka produkta garumam jābūt 37 centimetri vai kādas vielas daudzumam jābūt starp 3 un 4 procentiem.

IT izstrādē absolūta atbilstība standartam tiek prasīta reti un nereti ir pat kaitīga, jo standarti tomēr cenšas pārklāt pēc iespējas vispārīgāku gadījumu, paredzot visdažādākās situācijas, tāpēc praksē standartus parasti pielāgo konkrētā projekta vajadzībām. Pielāgošana notiek vai nu darba grupā kopā ar pasūtītāju (ieteicamais variants), vai pasūtītājs jau pirms līguma noslēgšanas ir pats veicis gala rezultāta prasību pielāgošanas procesu, vai izstrādes laikā izstrādātājs veic standartu pielāgošanu un nodevumā demonstrē tā atbilstību standartam, sniedzot pamatojumu, kāpēc šis pielāgojums būtu uzskatāms par atbilstošu standartam.

 Bieži novērota problēma ir standartu pārāk burtiska un formāla interpretēšana, nonākot līdz pat tādam absurdam, ka tiek pieprasīta, piemēram, prasību specifikācijas satura rādītāja pilnīga atbilstība standartam, kā rezultātā dokumentā ir sastopami pat desmitā līmeņa virsraksti (kas ir slikta prakse no tehniskās rakstīšanas viedokļa), jo standartā ir iekļauts satura rādītāja piemērs, kurā visas funkcionālās prasības ietilpst vienā nodaļā. Praksē lielai un sarežģītai informācijas sistēmai tas nozīmē papildus strukturēšanu un liekus līmeņus virsrakstos, kas apgrūtina gan strukturēšanu, gan dokumenta uztveršanu, gan papildus tērē speciālistu laiku.

 Programmatūras iegāde – projekts projektā

Standarts 1062-1998 IEEE Recommended Practice for Software Acquisition iesaka programmatūras iegādi organizēt kā projektu, kurš sākas brīdī, kad tiek izskatīta ideja par programmatūras iegādi, un beidzas brīdī, kad programmatūra vairs netiek izmantota. Šī iegāde sastāv no vairākiem etapiem – plānošana, līguma slēgšana un kvalitātes prasību definēšana, sadarbība programmatūras izstrādes laikā, pieņemšana un lietošana, kas katrs savukārt sastāv no procesiem, starprezultātiem un rezultātiem. Tātad sadarbība starp produkta pasūtītāju un produkta piegādātāju ir savstarpēji saistītu procesu kopums, kuru norisē katra no iesaistītajām pusēm piedalās ar dažādu līdzdalības un atbildības pakāpi, un šo sadarbību abpusēji jāprot vadīt un uzturēt.
Projekta gaitā abpusēji jāvienojas gan par dažādām formalitātēm, kvalitātes nodrošināšanas pasākumiem, gan par konkrētiem pienākumiem, piemēram, savstarpēji jāsaskaņo produkta nodošanas/pieņemšanas procedūra, jāvienojas, par programmatūras pieņemšanas kritērijiem, par atklāto kļūdu dokumentēšanu, smaguma klasifikāciju, to ziņošanu izstrādātājam un daudziem citiem sadarbības aspektiem.

Praksē IT izstrādātāji parasti piedāvā saskaņot savus procedūru un nolikumu variantus, vismaz būtiskākos, tomēr ļoti ieteicama ir pasūtītāja izpratne un savs skatījums par to, kuras procedūras ir būtiskākās un kas jāņem vērā, tās saskaņojot.

Sadarbības modeļi programmatūras iegādes projektā

Programmatūras iegādes projekta organizācijā var būt vairāki sadarbības modeļi.

       a) Pasūtītājs pilnībā pārzina izstrādes procesus, brīvi orientējas to organizēšanā, spēj formulēt nepieciešamos nodevumus, prasības to kvalitātei, kā arī novērtēt saņemto rezultātu atbilstību savām vajadzībām (prasībām).

Šāds modelis praksē ir efektīvs un tiek iegūts labs rezultāts. Jo kvalitatīvāk noformulētas prasības un lielāka izpratne izstrādes laikā, jo izstrādātājam vieglāk plānot un koncentrēt savus resursus tieši prasībām atbilstoša produkta izstrādei.

       b) Pasūtītājs sadarbībā ar izstrādātāju kopīgiem spēkiem formulē savas prasības, izstrādā un saskaņo dažādo savstarpējās sadarbības procesu dokumentus (izmaiņu vadības padomes nolikumu, dokumentu konfigurācijas pārvaldības procedūru u.c.).

Latvijā praksē visbiežāk izmantotais modelis. Pasūtītāja darbinieki paši organizē un vada programmatūras iegādi. Lai to paveiktu, tiek gan meklēti darbinieki ar atbilstošām iemaņām, gan apmeklētas dažādas apmācības, gan tiek studēta literatūra par IT projektu izstrādi.

        c) Pasūtītājs piesaista konsultantu, kurš kopā ar pasūtītāju sagatavo nodevumu sarakstu, kvalitātes prasības katram nodevumam un dažādu procesu dokumentāciju vai vismaz tās kvalitātes kritērijus. Sadarbību ar izstrādātāju pamatā veic pasūtītājs pats, nepieciešamības gadījumā piesaistot konsultantus.

Arī šis risinājums tiek diezgan bieži praktizēts, sevišķi valsts iestādēs un organizācijās, kuru pamatbizness ir stipri atšķirīgs no IT. Konsultanta slēdziens par nodevuma kvalitāti gan atvieglo pasūtītāja darbu, gan kalpo par kāda pieņemta lēmuma pamatojumu.

        d) Pasūtītājs programmatūras iegādi uztic zinošam „būvuzņēmējam”, deleģē tam sevis pārstāvēšanu sadarbībā ar izstrādātāju un pats piesaistās tikai finansēšanā un gala produkta lietošanā.

Dārgs un riskants risinājums, kura laikā tāpat jāsadarbojas ar „būvuzņēmēju” un jānodrošina, lai prasības vienādi saprot gan „būvuzņēmējs”, gan izstrādātājs. Praksē izrādās, ka arī šajā gadījumā pasūtītājam tomēr ir nepieciešama izpratne par programmatūras izstrādes un iegādes procesiem un nenotiek tā, ka kāds no malas atnāk un izdara pilnīgi visu.

Kur var iegūt zināšanas par programmatūras iegādi?

Diemžēl kompānijām, kuru vārds tirgū vēl nav nostabilizējies, mēdz būt arī interese par to, kādas ir pasūtītāju vājās vietas un kā tās var izmantot savā labā. Lai no tā pasargātos, ieteicams programmatūras iegādē iesaistīt zinošus speciālistus, pilnīgai drošībai – apvienojumā ar izstrādātāju, nozarē labu reputāciju iemantojušu stabilu kompāniju.

Veidi, kā iegūt programmatūras iegādes projektu pārvaldībai nepieciešamās zināšanas, ir vairāki, sākot no akadēmiskām studiju programmām, turpinot ar apmācību kursiem, konferencēm un profesionālajiem semināriem. IT izstrādes kompāniju mājas lapās nereti ir atrodami līdzīgu apmācību piedāvājumi, jo kam gan, ja ne pašām izstrādātāju kompānijām ir vislabāk zināma nozares virtuve, kā arī ir vērā ņemama pieredze gan par to, kā vajadzētu rīkoties, gan par to, kā nevajadzētu. Zināmākā no kompānijām ar līdzīgu apmācību ilggadēju piedāvājumu bija Rīgas Informācijas tehnoloģijas institūts.

Pasūtītāja darbinieki noteikti jāapmāca izstrādāto procesu konceptuālo risinājumu lietošanā, pielāgošanā un ieviešanā organizācijā. Iespējams izmantot dažādas savstarpēji saskaņotas apmācību formas – mācību materiālus, atsevišķu pasūtītāja darbinieku – tālāko konsultantu sagatavošanu, visu iesaistīto darbinieku apmācīšanu, seminārus u.c.

Pirms apmācībām jānoskaidro pasūtītāja priekšzināšanas, jo pilnīgi iespējams, ka daudzi no nozares terminiem var būt pasūtītājam nezināmi vai maz zināmi, piemēram, dokumenta dzīves cikls, izmaiņu pieprasījums, problēmziņojuma dzīves cikls, apskate, akcepttestēšana un citi. Svarīgi, lai apmācībās un izstrādātājos mācību materiālos katram no tiem būtu skaidrojums pasūtītājam uztveramā līmenī.

P.S. Raksts tapis 2005.gadā, bet vērtēju, ka joprojām aktuāls

Sadarbība ar priekšnieku


Cenšos strādāt pēc šādiem principiem:

1. Netērē vadītāja laiku. Ir labi saņemt apstiprinājumu no vadītāja jautājumā, par kuru nav īstas pārliecības, taču nākamreiz, kad grasies to darīt, pajautā sev, vai vadītājs varēs dot labāku atbildi. Vairumā gadījumu tā nebūs, tāpēc paļaujies uz sevi un netērē vadītāja laiku ar liekiem jautājumiem.

2. Piedāvā risinājumus, ne problēmas. Daudzi darbinieki pie vadītāja vēršas ar problēmām. Vadītāja ievērību gūsi, ja, apspriežot ar darbu saistītās problēmas, pati spēsi piedāvāt vismaz dažus risinājumus.

3. Uzņemies atbildību. Arī pieļaujot kļūdas, ir iespējams izpelnīties atzinību. Tā vietā, lai paskaidrojumus sāktu ar atvainošanos, atzīsti, ka esi rīkojusies nepareizi, piebilstot, ka nākamo reizi darīsi citādi.

4. Negaidi mierinājumu. Neiedomājies, ka vadītājam ir terapeita spējas, tāpēc kontrolē emocijas, lai vadītājs nebūtu liecinieks dusmām un asarām. Vadītājam tevi jāredz kā cilvēku, kas rāmi tiek galā ar problēmām.

5. Esi pieejama. Neesi saīgusi, ja vadītājs uzdod nepatīkamu uzdevumu. Saskati to kā jaunu izaicinājumu un nesaki, ka nespēji to izdarīt. Tas palīdzēs tev pašai, un arī vadītājs tevi ievēros.

6. Nedomā, ka vadītājs ir muļķis. Vadītāji par saviem darbiniekiem zina vairāk, nekā viņi iedomājas. Tāpēc, ja grasies melot, ka esi saslimusi, nesūti īsziņas vai e-pasta vēstules, bet gan piezvani un izskaidro situāciju, kāpēc nevari būt darbā.

7. Atceries, ka arī vadītājs grib tev patikt. Arī vadītājam ir svarīgi saprast, kā viņa darbu vērtē padotie, tāpēc nekautrējies pateikties par atbalstu un cita veida palīdzību.

8. Nečīksti. Pat ja visu laiku nežēlojies vadītāja klātbūtnē, viņš ātri uzzinās, kuri staigā pa biroju, žēlojoties par problēmām. Tevi ievēros, ja nepievienosies čīkstētāju pulkam un ar problēmām tiksi galā pati.

9. Izmanto iespēju paklusēt! Nokavēto pateikt paspēsi arī vēlāk. Atsaukt pateikto – nekad.

p.s. diemžēl es vairs neatceros, no kurienes pirms vairākiem gadiem smēlos iedvesmu šī saraksta sastādīšanai. Iespējams, tā bija publikācija kādā avīzē.

Programmatūras izstrādes projekta vadītāja piezīmes


 Lai cik plaši būtu pieejami pētījumi par projektu vadīšanu, ikviens programmatūras izstrādes projekta vadītājs savulaik ir pionieris un pirmatklājējs vadīšanas praksē, līdz ar pieredzi krājot secinājumus un ieteikumus. Šajā rakstā apkopotas vairāku programmatūras izstrādes projektu vadītāju populārākās atziņas.

KAS TAS IR – PROJEKTS?

Projekts = Termiņš + Sasniedzamais rezultāts + Budžets

Projekts ir uzdevums ar parametriem “sākuma un beigu datumi”, “sasniedzamais rezultāts”, “budžets”.

Projekta vadītājs = Zināšanas + Entuziasms + Pieredze

Projekta vadītājs ir cilvēks, kuram jāsasniedz rezultāts atvēlētajā laikā un ar resursiem, ko var atļauties saskaņā ar atvēlēto budžetu. Vadītājs var izmantot savas zināšanas un spējas, piesaistīt citu cilvēku zināšanas un spējas, kā arī izvēlēties palīglīdzekļus. Projekta veiksmes gadījumā vadītājs var pamatoti lepoties ar pakāpienu savā karjerā, un sevišķi augstu kotējas vadītāji, kuri izveduši projektu no krīzes situācijas. Projekta neveiksmes gadījumā atbildība pilnībā jāuzņemas vadītājam.

 Ar projektiem savas dzīves laikā sastopas ikviens cilvēks, un patstāvīgi cilvēki ar laiku pierod arī sadzīvē domāt projektu vadīšanas kategorijās – uzstāda konkrētus mērķus, nosaka laiku, rēķinās ar līdzekļiem. Filozofiski uz to paskatoties, visa cilvēka dzīve ir kā liels projekts ar daudziem apakšprojektiem, kuri laika gaitā kļūst arvien sarežģītāki:

  • bērnudārzā – “Zelta rudens”: sasniedzamais rezultāts – atrasta krāsaina kļavas lapa;
  • skolā – kontroldarbs matemātikā: 45 minūtes laika, atbildei jāsakrīt ar skolotāja rīcībā esošo;
  • augstskolā – programmēšanas kurss: 3 mēneši, atzīme >=8, budžetu veido stipendija un studiju kredīts;
  • darbā – programmatūras izstrāde: 2 gadi, izstrādāta un ieviesta norēķinu sistēma, 600 000Ls.

 VADĪŠANA

Prakse liecina, ka 80% no uzdevuma prasa 50% no atvēlētā laika. Ja 80% no uzdevuma ir izdarīti 80% no atvēlētā laika, tad ļoti iespējams, ka termiņš tiks nokavēts.

 Plašāk pazīstamas un arvien praksē pārbaudītas sakarības, ar kurām vadītājs var rēķināties, ir tā sauktās 80:20 sakarības, piemēram:

  • 80% labumu var nodrošināt ar 20% no prasību realizācijas,
  • 20% profesionālāko programmētāju rada 80% koda,
  • 20% vājāko programmētāju rada 80% no atklātajām kļūdām.

 Ja vadītājs nespēj atbildēt uz kādu projekta jautājumu, tad viņam jāzina, kā šo atbildi  iegūt. Vadītājam jāvar pieņemt jebkuru ar projektu saistītu lēmumu – vai nu pašam, vai deleģējot lēmuma pieņemšanu speciālistam (piemēram, vai datu bāzei piekļūt ar ODBC vai OLE DB?). Jebkurā gadījumā vadītājs ir atbildīgs par lēmuma sekām.

 Vadītājam, kurš pats nav programmējis, ir ievērojami grūtāk vadīt programmatūras izstrādes projektu nekā cilvēkam, kurš karjeru ir sācis kā programmētājs. Labi, ka projektā ir galvenais speciālists, kurš pārzina tehnoloģisko pusi un spēj pieņemt lēmumus, taču šādos gadījumos pastāv projekta dubultās vadīšanas risks un vadītājam jābūt gatavam strādāt tādos apstākļos.

 Ja projektā ir problēma, vadītājam jādomā tālāk par konkrētās problēmas atrisināšanu – viņam jāzina, kā mainīt sistēmu, lai šādas problēmas neatkārtotos, un jāspēj sistēmu mainīt.

Vadītājam ir jāzina un ir jājūt vietas, kuras varēs precizēt programmatūras izstrādes gaitā. Nav vērts censties izstrādāt 100% atbilstošu projektējumu un praktiski nav projektu, kurus praksē izdotos pilnībā izstrādāt pēc ūdenskrituma modeļa.

Jo vairāk problēmu iespējams atrisināt sarunājoties, jo profesionālāks vadītājs. Un otrādi – jo profesionālāks vadītājs, jo vairāk jautājumus var nokārtot sarunu ceļā.

PASŪTĪTĀJS

 Ja vien tas ir iespējams, tad piedāvājums un cenu aprēķins jāiesniedz Pasūtītājam personīgi, izskaidrojot un pamatojot savu piedāvājumu.

Jo mazāka sadarbības pieredze, jo vairāk jautājumu jārisina klātienes sarunās. Kad izveidots pamats ilgstošai sadarbībai, tad var atļauties daļu problēmu risināt e-pastā vai telefoniski.

Paralēli formālajiem pasākumiem (izmaiņu vadības padomes utml.), svarīgi “uztaustīt” Pasūtītāja procesus pārzinošu cilvēku vai cilvēkus, kuriem var uzdot jautājumus par dažādām situācijām. Ideāli, ja šis cilvēks ir arī oficiālā kontaktpersona par attiecīgajiem jautājumiem, jo var teikt, ka projekta panākumi ir proporcionāli tam, cik veiksmīgi izveidojas sadarbība ar šo cilvēku vai cilvēkiem.

Pēc iespējas ātrāk vajag vizualizēt Pasūtītājam iespējamo rezultātu, sākotnēji kaut vai sarunas laikā to uzskicējot uz papīra. Mūsdienu rīki ļauj ātri un viegli uzzīmēt ekrānformas pirms programmēšanas uzsākšanas.

DELEĢĒŠANA

Jāprot prognozēt darbinieka spēju veikt uzdevumu. Ja darbinieka spējas nav zināmas, tad, deleģējot uzdevumu, sākotnēji jāpieņem, ka darbinieks nepārzina konkrēto jomu, un uzdevums jāizstāsta sīki un smalki. Jāpārliecinās par deleģētā uzdevuma izpildi.

Efektīvākais veids, kā pārliecināties, vai darbinieks sapratis uzdevumu, ir palūgt viņam atstāstīt,  kā viņš ir sapratis uzdevumu.

SECINĀJUMI

Projektu vadīšana ir vairāku zinātņu apvienojums un programmatūras izstrādes projektu gadījumā tās ir – datorzinātne, vadība, psiholoģija, ekonomika. Mūsdienās ģeniāli atklājumi visvairāk tiek izdarīti kombinētajās zinātnēs, piemēram, klasiskajā matemātikā jaunu un ģeniālu atklājumu ir maz, toties, apvienojot matemātiku ar fiziku un ķīmiju, tika radīti pirmie kvantu datori.

Programmatūras izstrādes projektu vadīšana ir formalizēta pieeja apvienojumā ar mākslu, un speciālisti visā pasaulē strādā, lai šajā jomā palielinātu formalizētās pieejas % un samazinātu mākslas %. Pašlaik šī procentuālā attiecība programmatūras izstrādes projektu vadīšanas praksē, manuprāt, ir 50 pret 50 un, kamēr tā nav būtiski mainījusies, tikmēr labs programmatūras izstrādes projektu vadītājs joprojām būs datorspeciālists, psihologs, ekonomists un nedaudz arī burvju mākslinieks.

 Publicēts žurnālā Datorpasaule, 2004.g. janvārī

%d bloggers like this: