User login

Languages

Projektu vērtēšana 2 (atziņas, lasot literatūru)

Kā jau minēju iepriekšējā bloga ierakstā par projektu vērtēšanu, pēdējā laikā lasu diezgan daudz par šo tēmu, konkrēti, "Software Estimation: Demystifying the Black Art" Steve McConnell un "Estimating Software Costs: Bringing Realism to Estimating" by Capers Jones. Gribu padalīties ar dažām iegūtajām atziņām.

 

1. Man patika, kā Steve McConnell ir nosaucis vārdos dažas vispārzināmas lietas, ar ko vērtēšanā diezgan bieži gadās saskarties. 

  • vērtēšana nav vienošanās. Skaidrs, ka projekta ieinteresētās puses, kā sponsors, vai projekta vadītājs, vai lietotājs, var domāt, ka vērtējuma nosišana uz leju un iekalšana akmenī liks programmētājiem ātrāk strādāt. Patiesībā, vērtējuma mākslīga nosišana uz leju nepaātrina projekta realizāciju, bet ievieš tajā tikai papildus stresus un liekas darbības (piemēram, ja nevaram parādīt klientiem gatavu rezultātu, parādīsim vismaz starprezultātu --> tērējam jau tā deficīto laiku, lai nodrošinātu demo parādīšanu). Patika šis posteris par nepareizu vērtējumu nodarīto ļaunumu. Protams, man gan liekas, ka, lai ko teiktu zinātnieki, praktiski pazeminātiem vērtējumiem parasti ir pārāk daudz atbalstītāju, jo vairumam no iesaistīto īstermiņa interese ir, lai projekts notiktu (pat tad, ja no klienta (sponsora) interešu viedokļa labāk to būtu nesākt)
  • IT projektu sakarā ir pieņemts runāt par vērtēšanas problēmu. Steve McConnell raksta, ka tāda vispārīga vērtēšanas problēma nepastāv, pastāv pārāk zemas novērtēšanas problēma. Viņš uzskata (un es viņam piekrītu),  ka darbietilpības pārvērtēšana, pirmkārt, notiek reti, otrkārt, tā ir daudz vieglāk menedžējama (galu galā, tā vai savādāk, bet projektam ir kaut kāds vadītājs vai koordinators, kuram vajadzētu zināt, ka kāds no cilvēkiem mokās bezdarbībā, un šo lietu salabot)
  • lai zinātniskāk pateiktu, ka kamēr nav prasību, tikmēr vērtēšana ir minēšana kafijas biezumos, Steve McConnell lieto jēdzienu nenoteiktības konuss jeb uncertainty cone (patiesībā jau pirms viņa to lieto Boehm). Nekas jauns, bet jau zināmās lietas attēlotas grafiski. Starp citu, precizitāte eksperta vērtējumam brīdī, kad prasības vēl nav skaidri zināmas, ir ar kārtu 4, t.i., reālā darbietilpība var būt 4x lielāka. Tā vismaz domā Boehm & McConnell.

2. vērtēšanas metožu formulas diezgan daudz pasaka par dažādu faktoru nozīmi projekta realizācijā. Piemēram, saskaņā ar COCOMO II, viens no visvairāk ietekmējošiem faktoriem nelielos projektos ir analītiķa sniegums (faktiski, otrs svarīgākais ietekmējošais faktors aiz programmatūras sarežģītības). Lielākos projektos šis faktors daļēji zaudē nozīmi, un lielāku nozīmi iegūst "process maturity", citiem vārdiem sakot, procesu sakārtotība. 

3. Steve McConnell grāmatā tiek runāts par tādu jēdzienu kā diseconomies of scale. Nezinu, kā to pareizi pārtulkot, Ērika Reinterta grāmatā "Kā nabadzīgās valstis kļuva bagātas ... un kāpēc nabadzīgās valstis paliek nabadzīgas" līdzīgas parādības apzīmēšanai tika lietots termins "dilstošā atdeve". Augošā atdeve nozīmē to, ka ražošana masveidā kļūst arvien lētāka uz vienu saražotās produkcijas vienību (rūpniecība, t.sk., programmatūras produktu ražošana). Dilstošā atdeve nozīmē, ka, palielinoties mērogiem, vienas vienības saražošana kļūst arvien dārgāka (izejvielu eksports, lauksaimniecība). Saskaņā ar COCOMO II modeli, izstrādes darbietilpība neaug lineāri attiecībā pret programmatūras lielumu, bet straujāk (dēļ projekta organizācijas, komunikācijas, u.t.t.), t.i., lielāki IT projekti ir neefektīvāki nekā mazi. Nekāds jaunums tas nav, tomēr, patīkami, ka zināmā lieta labi pamatota. Arī, secinājums IT jomas kūrētājiem (pieņemot, ka šādi cilvēki eksistē) - IT pakalpojumu eksports mērogojamības ziņā līdzinās izejvielu eksportam - pieaugot apjomam, efektivitāte samazinās. Ja arī ir labi, ka tādā veidā Latvijā un konkrētās firmās ienāk nauda, tad tomēr ilgermiņā tā augt nevar.

4. Capers Jones raksta, kā pamatot vērtējumu - jābūt vēsturiskiem datiem (vai arī sīkai work breakdown struktūrai). Viņš raksta, ka 60% gadījumos projekta sponsori noraida vērtējumu kā pārāk lielu, un daudzos gadījumos notiek mēģinājumi (ne obligāti no sponsoru puses - mana piezīme)  tos mākslīgi nosist uz leju (un, ja tas izdodas, tad nepatikšanas sākas tā pa īstam). Šinī kontekstā, es pilnībā atbalstu ideju par vērtējumu pamatošanu uz vēsturiskajiem datiem, jo tad tie ar laiku kļūtu daudz precīzāki; no otras puses, esmu skeptisks par šī argumenta nozīmi, aizstāvoties pret apzinātu mēģinājumu vērtējumu samazināt. Domāju, ka vairāk ir atkarīgs no organizācijas kultūras, un klienta, projektu vadības, un citu iesaistīto cilvēku izpratnes par IT procesiem. 

Paldies, ka lasījāt. 

Laimīgu Jauno gadu!

 

Komentāri

Pievienojiet komentāru

Plain text

  • HTML birkas nav atļautas
  • Interneta lapu un e-pastu adreses automātiski tiek pārveidotas par saitēm.
  • Automātiska rindu un rindkopu veidošana
  • Each email address will be obfuscated in a human readable fashion or, if JavaScript is enabled, replaced with a spam resistent clickable link. Email addresses will get the default web form unless specified. If replacement text (a persons name) is required a webform is also required. Separate each part with the "|" pipe symbol. Replace spaces in names with "_".
Image CAPTCHA
Ievadiet attēlā redzamos ciparus
Error | Kaspara Omula mājas lapa
Enter your Kaspara Omula mājas lapa username.
Enter the password that accompanies your username.

Kaspara Omula mājas lapa

Error

The website encountered an unexpected error. Please try again later.