Mis läheb valesti?

Tahaksin lugeda üles põhjused, millede pärast tarkvaraprojektid raskustesse satuvad. Olen varsti paarkümmend aastat sellel alal. Uued keeled, uued metoodikad, uued tehnoloogiad aina tulevad. Aga vead on samad nagu nad koguaeg on olnud.  Neist on räägitud ikka ja jälle aga samu asju aina juhtub ikka ja jälle.  Äkki siis räägitakse liiga vähe? Või siis ollakse mingitel müstilistel põhjustel alati sunnitud neid vigu tegema? Iga lause edaspidi siin artiklis on viga, mida tihtilugu tehakse. Igas projektis tehakse alati mitu tükki. Ime on et üldse õnnestub asjad valmis saada. Suudaksin enamuse kohta näidendi kirjutada sellest, kuidas nad tulevad ja miks nad valusad on.  Seega, kuivalt ja lakooniliselt:

Ettevalmistus, enne projekti, siis kui tööd pole veel tegelikult alanud

Reserveeritakse algselt liiga suur meeskond. Inimesed istuvad ettevalmistuskoosolekutel ja haigutavad. Raisatakse liigselt aega ja seda on raske müüa. Sama juhtub, kui tööd on mingi (välise) pudelikaela taga kinni.

Visioon

Projektil puudub selge visioon. Midagi on aga see on puudulikult vormistatud ja selle tähendus läheb lahku erinevate inimeste peades. Mõnedele olulistele küsimustele pole vastatud, võimalik et pole isegi mõeldud.
Mida see projekt annab? Miks ta seda annab? Millal ta seda annab? Kuidas ta seda annab? Kus ta seda annab? Kellele ta seda annab? Vahetevahel püütakse teha toodet, mille loomiseks oleks eelnevalt vaja teha tulemuslikke teadusuuringuid tarvaraarenduse vallas.

Planeerimine, hindamine

Planeerimine on kas puudulik või ebapidev. Kasutatakse ajahinnanguid otse tähtaegadena. Ajahinnang on tavaliselt umbropsu antud mingi töö alamhulga kohta. Unustatakse mingid tööd, mida vaja teha ajahinnangutesse ja edasi plaanidesse lisamata. Kellelgi, kellest oleneb on aga ebareaalsed ootused või hinnangud. Surve on  korrigeerida neid tähtaegu alguses veelgi optimistlikumateks, mitte projektimahtu suuremaks. Töö käigus lisatakse uusi nõudeid aga plaane ei korrigeerita. Edasi, kui jäädakse ajast maha siis loodetakse mingi imega tagasi teha ja kinni püüda. Lõpuks, kui tekivad tõsised probleemid jäetakse planeerimine üldse sinnapaika. Viimaks on kõigile selge, et projekt hilineb ja siis hinnatakse tähtajad ümber, aga millegi pärast püütakse veel uusi nõudeid käigult juurde lisada või koguni visiooni laiendada.

Nõuded

Tihtilugu hüpatakse projekti alguses kodeerima isegi ilma olulisi nõudeid välja selgitamata. Nõuded küll mingisugused on aga ikka ei vasta oluliste asjade kohta olulistele küsimustele (Mida? Miks? Millal? Kuidas? Kus? Kes?). Ei ole selge, mida tehakse, kaugel ollakse ja mida üldse tähendab sõna “valmis”. Olulised nõuded võivad ka üldse mainimata olla. Teisest küljest võib juhtuda, et püstitataud on liiga palju nõudeid, näiteks selliseid nõudeid, mida pole visiooni täitmiseks tegelikult vaja. Kuna nõuete hulk on ähmane siis arenduse käigus kipuvad sisse ronima aina uued nõuded.

Disain

Paljudes projektides pole tihtilugu üldse disaini. Eri meeskonnaliikmed implementeerivad eri nõudeid rahuldades  samasisulist funktsionaalsust või koguni omavahel vastuolulist funktsionaalsust. Disainides usaldatakse mingisugust algdokumentatsiooni rohkem kui tegelikkust. Programmeerides usaldatakse disaini rohkem kui tegelikkust. Kui avastatakse lahknevus tegelikkusega siis dokumentatsiooni ei korrigeerita.

Meeskond

Puudu on mingite oluliste osapoolte osavõtt projektist. Näiteks puudub väline osapool, kes saaks aidata olulistes küsimustes, mille kohta meeskonnal puutub kompetents. Või veelgi kitsamalt ja tüüpilisemalt: meeskonnal pole üldse lõppkasutajapoolset tagasisidet.  Meeskond peab läbi ajama mingite müügimeeste seisukohtadega. Lisatakse tööjõudu hilinevasse projekti, sellega koormates olemasolevat meeskonda üle valgustamistöödega. Kolmandad osapooled, kes töödes osalevad, ei saa oma asjadega õigeaegselt hakkama, tekitades pudelikaelu ja viivitusi. Geeniusi on vähe võtta. Töötajad on sobimatud, muude probleemidega koormatud või kogenematud. Parimad ja tugevaimad on seotud korraga mitme projekti või liiga mitme tööga sama projekti raames.

Töömeetodid

Miskeid töid püütakse teha kangelaslikult, rohke ületunnitööga ja muude ekstreemsustega. Tehakse õudsat koodi või veaparandusi, “mis vähegi töötab”. Arendajad teevad muude ülesannete raames neid huvitavat niksu ja naksu, mida tegelikult vaja pole. Programmeerija on sunnitud kliendiga otse suhtlema ja teda nõustama või toetama töö asemel. Häid suhteid (firmasiseseid, ülemustega) peetakse olulisemaks headest tulemustest. Jaanalinnupoliitika: inimesed näevad, et asi on mäda, aga kas pigistavad ise silma kinni, ei maini probleeme (et mitte olla “süüdlane” neis), või neid ei võeta kuulda.

Tehnoloogiad

Osa koodi, vajalikke faile, teeke või muud sellist ei ole koodihaldussüsteemis. Usutakse, et  miski uus tehnoloogia või meetod lahendab kõik probleemid imeväel. Näiteks Scrum. Kui palju vigu nendest, mis ma siin nüüd toon ta väldib ja kui palju mitte? Uute tehnoloogiate ja vahenditega võib asi isegi harjumatutele keerulisem olla, aga sellega ei arvestata. Uuele versioonile või tööriistale poole töö pealt üleminekuga kaasnevad kulud,  millega ei arvestata.

Kvaliteedikontroll

Kvaliteedikontroll, review ja testimine on kas puudulik või ebapiisav. Automaatteste pole. Püütakse toode kokku panna ja välja lasta kas liiga tihti või liiga vara, ilma piisava testimiseta. Vigane asi raiskab kõigi aega ja jätab ka klientidele halva mulje.

Riskihaldus

Riskimaandamine puudub projektist ja plaanidest. Kõik, millest siin juttu oli on ju riskid, ja kõigile meile tuttavad. Peale selle on projektides teisi spetsiifilisi riske, aga siintoodud kipuvad esinema lõviosas projektidest.

Kui keegi oskab veel mainida mõnda tüüpviga, mis mul mainimata jäi,  siis tere-aga-tulemast laske aga tulla.

3 thoughts on “Mis läheb valesti?”

  1. Vamps, see on üks Väga Hea jutt. Igaüks peaks ilmselt korra või kaks aastas selle uuesti läbi lugema.. ja leidma, et kurat.. jälle :)

  2. Ma postitasingi selle vist aasta tagasi või nii, kuhugi intrasse. Kes selle siia pani? :) Kõige parem oleks seda lugeda täitsa uue projektiga alustades või hädas projektile appi minnes. Aitab aru saada, mille sees sa siis seekord oled. ;)

  3. Ja lisaks meeskonna peatüki juurde Peteri printsiibi IT maailmas – head arendajad kiputakse edendama halbadeks projektijuhtideks :)

    Ehk palju te teate aastakümnete kogemusega arendajaid nagu vamps?

Leave a Reply

Your email address will not be published. Required fields are marked *