IT projektu problēmas – 2 2

Iepriekšējais raksts: http://dll.lv/it-projektu-problemas-1/

2. Ieviešanas(izstrādes) problēmas

Galvenā problēma ir projekta plānošana, vadīšana un prasību definēšana.
Joprojām projekti tiek pasūtīti prasībās norādot vispārējas lietas, kuru realizācijas redzējums ļoti atšķiras starp pasūtītāju un izstrādātāju.

Biežāk izstrādē lietotās ir Agile un ūdenskrituma metodes.

Lielākā kļūda izstrādājot ir mēģināt apvienot abas izstrādes metodes un izgudrot kaut ko pa vidam, jo abās metodēs ir iestrādātas pilnīgi cita ideoloģija, kā rezultātā sistēma tiek izstrādāta pēc ūdenskrituma modeļa, bet ar nenodefinētu specifikāciju.

Galvenās atšķirības starp metodēm:
Agile variantā sistēmas prasības tiek definētas un precizētas projekta izstrādes laikā, kā rezultātā sākuma līgums tiek slēgts par sistēmas izstrādi nenodefinējot neko speciālāku. Šādos līgumos lielākoties tiek atrunātas izstrādātāju darba stundas izmaksas, kas tiek pareizinātas ar patērēto laiku, jo sākumā laiku paredzēt nav iespējams. Šis laiks ir atkarīgs no mainīgo prasību daudzuma un izstrādājamās funkcionalitātes. Šādi līgumi ir grūti izstrādājami no juridiskās puses (nav nodefējams gala rezultāts).
Šādiem projektiem ir grūti veikt plānošanu, jo nevar paredzēt, kas būs jādara.
Vēl viena liela problēma izmantojot šo metodi ir kulturālās problēmas, jo, piemēram, grāmatvedis nebūs ar mieru, ka izstrādātājs viņu visu laiku tramda, bet izmantojot šo metodi ļoti svarīgi, lai biznesa cilvēki un izstrādātāji pēc iespējas vairāk pavadītu laiku kopā un diskutētu.
Agile nav piemērota sistēmām, kurām ir ekskluzīvas prasības, piemēram, pret drošību vai sistēmas darbības nepārtrauktību, utt.

Rezumē- gala rezultātā iegūs to, ko vēlas pasūtītājs, tomēr izmaksas nav paredzamas, tās var būt lielākas, kā sākumā paredzēts un var būt arī mazākas.

Izmantojot ūdenskrituma modeli ir iespēja, ka iegūtā sistēma nebūs tā, kura nepieciešama, jo:
prasībās ir aizmirsts kaut kas nodefinēt;
baidoties kaut ko aizmirst ir iekļauts viss un daudz kas lieks, kuru nemaz nevajadzēs.

Kā rezultātā tiek izstrādāts BMW, kaut biznesam būtu pieticis ar Opel.

Ir aprēķināts, ka daudzās sistēmās tiek lietots tikai 30% no iestrādātās funkcionalitātes.
Otrs variants, ka lielajos projektos, kur izstrāde ilgs gadu un vairāk, vienkārši nav iespējams paredzēt visas vajadzīgās lietas, jo laika gaitā prasības sistēmai mainās.

Lielākā atšķirība starp abām metodēm ir projekta vadīšanas stils, Agile metodē lielākoties projekta vadītājs, dokumentētājs un izstrādātājs ir apvienots vienā personā(vai viens, kas ļoti labi parzin visas lietas un spēj sekmīgi iesaistīties visos procesos), lai varētu veiksmīgi paredzēt izmaiņas. Kā rezultātā šāda projekta vadītāja atalgojums ir lielāks. Ūdenskrituma modelī, katrā izstrādes fāzē var tik iesaistīti citi cilvēki- prasību definētājs, programmētājs un testētājs.

3. Prasību neatbilstība vajadzībām.

To izraisa:
Komunikācijas problēmas,
Prasības netiek pārskatītas no biznesa viedokļa,
Mainīgā biznesa un apkārtējā vide.

Lai šo atrisinātu ir nepieciešama prasību vadība, kura nosaka, kuras prasības ir vajadzīgas, kuras tiek izstrādātas un kuras nē. Vēl tas ir vajadzīgs, lai varētu novelk strīpu un pateikt, ka papildus prasības netiks izstrādātas šajā etapā un pārējās tiks ieviestas jau projektu uzlabojot. Tas nodrošinās, lai prasības visu laiku netiek papildinātas un projekta nodošana netiek atlikta.

4. Izstrādātā sistēma nestrādā atbilstoši sākotnējām iecerēm.

Lielākā problēma ir testēšanā:
Jo ir aprēķināts, ka normālai testēšanai vajadzētu aizņemt 30% no izstrādes laika, bet tai tiek atlicināts pēc iespējas mazāk un, ja projekta izstrāde tiek iekavēta, tad uz NEtestēšanas rēķina produkts tiek nodots laikā.

Otra problēma testēšanā ir tā, ka netiek testēti ievadāmo datu robežgadījumi(piem, ievadīti dati ar negatīvu zīmi vai ar komatu, utt), kā rezultātā algoritms var nestrādāt kā vajag.

Svarīgs faktors ir vai biznesa puse ir iesaistīta gala testēšanā.
Kā izgāšanās piemēri tika minēti Nasas projektu problēmas, piemēram Marsa zonde, kas izšķīda pret Marsa virsmu, jo programmētājam lika uzprogrammēt, lai nosēšanās mehānisms nostrādātu 30 metrus virs Marsa virsmas, bet tas uzstādīja 30 pēdas.(Nasa izmantoja metrus, bet pārējā Amerika izmanto pēdas un collas) Kā rezultātā 125M $ izšķīst pret Marsa virsmu. Tā kā šādās kritiskās sistēmas tiek piesaistīti labākie speciālisti, kas vien ir pieejami par naudu :), tad diez vai jūsu projektos būs labāki speciālisti…

5. Neviens vai tika daži izmanto šo produktu.

Daudzi projekti netiek vienkārši lietoti, piemēram izstrādātās elektroniskās dokumentu aprites sistēmas valsts iestādēs, bet darbinieki tik un tā drukā dokumentus, kā rezultātā nekāds ieguvums no šīs sistēmas nav. Tādēļ daudzos gadījumos ir nepieciešama vadības iejaukšanās un piespiešana darboties ar sistēmu.

Ieviestās CRM sistēmas, kuras darbinieki nelieto, jo tajās ir jāreģistrē savi kontakti un pieejamā informācija par klientu, kā rezultātā pārdošanas darbinieki zaudē lielāko no savām priekšrocībām- privātos kontaktus.

Vai arī sistēma tiek lietota tikai dažos departamentos, kā rezultātā, lai sazinātos ar pārējiem tiek lietotas tradicionālā papīra pieeja, kā rezultātā atdeves no sistēmas nav.

Iniciatīvu šīs problēmas novēršanā ir jāuzņemas vadībai, kurai ir arī jārēķina darbinieku laiks un efektivitāte.

2 thoughts on “IT projektu problēmas – 2

  1. Reply ramm May 30,2009 12:27 am

    Jāsaka – tīri labs raksts.
    Faktiski jau neko jaunu tu nepasaki, bet tie cipari un procenti ļoti labi pastiprina tavus argumentus.

    btw. tie 84% par kavētajiem IT projektu termiņiem ir pasaules vai Latvijas statistika?

  2. Reply Kaspars Jun 1,2009 8:36 am

    Statistika ir no pasaules datiem, būtu interesanti tādu uzzināt par Latviju, bet diez vai kāds tādu pētījumu veiks.
    Nekas īpaši jauns un unikāls tas nav tādēļ, ka cilvēkiem patīk kāpt uz vieniem uz tiem pašiem grābekļiem un turpināt par projektu vadītājiem likt cilvēkus, kuri nemaz tādi nav.

Leave a Reply