Targo tarkvara

Mis te arvate, millise elualaga tavakodanikul kõige rohkem probleeme esineb? Kas ehk kasutatud autode müüjatega? Või kinnisvaraagentidega?

Ameerikas on lahe organisatsioon nimega Better Business Bureau (BBB), kuhu inimesed saavad saata igasuguseid kaebusi ettevõttete kohta ja ka uurida, kui palju mingi firma või asutuse peale kaevatud on. Muuhulgas teevad nad ka statistikat erinevate teenuste ja tööstusharude osas. Järgmine tabel on toodud 2008 sügise seisuga:

TOP COMPLAINTS

1. Cellular Telephone Service & Supplies
2. Computers Software & Services
3. Internet Shopping Services
4. Auto Dealers – New Cars
5. Internet Services
6. Travel Agencies & Bureaus
7. Collection Agencies
8. Auto Dealers – Used Cars
9. Banks
10. Auto Repair & Service
11*. Searchers of Records
11*. Real Estate Management
13. Hotels
14. Contractor – General
15. Apartments
16. Telephone Communications
17. Wholesalers & Distributors
18*. Plumbing Contractors
18*. Movers
18*. Furniture – Retail
* Indicates a tie.

Ma arvan, et enamik selle jutu lugejaist tegutseb minu poolt esiletõstetud valdkondades. Tarkvarategijad “edestavad” kaebuste hulga poolest nii autoremontijaid kui inkassofirmasid.

Milles on asi? Töötasin ise oma eelmises elus Microsoft Office SharePoint Serveri tiimis. Microsofti põhimõtteks on “eat your own dogfood” ja üldiselt kasutasime me oma tooteid nii et seda nägu. Sellegipoolest, nüüd olen liikunud laia maailma avarustesse ja päriselus SharePointi juurutades taon tihtilugu peaga vastu seina, et kuidas küll tootesse sellised narrid ebamugavused sisse on jäänud.

Ehk siis veelkord: tunne oma kasutajat, sest ta ei ole teps mitte selline nagu sina! Kui ma vaatan kontoris enda ümber ringi, keda ma näen? Peamiselt noori, introvertseid, küllaltki kõrge haridustasemega mehi. Kes on meie kasutajad? Kui mõne kliendi koridoris ringi jalutan ja IT osakonnast välja saan, näen hoopis teistsugust pilti: inimesi on nii noori kui vanu, naisi on pigem rohkem kui mehi, kõikvõimaliku tausta, hariduse ja huvidega. Neid ei huvita karvavõrdki meie toodete tehnokraatlikud aspektid, nad tahavad, et asjad lihtsalt töötaks ja seejärel oma muu elu juurde tagasi pöörduda. Täpselt nagu mind ei huvitaks oma külmkapi konfimine, ei taha nad meie tarkvaraga tegemist teha rohkem kui hädapärast vaja.

Kuidas aga teada saada, mis inimestele tegelikult ebamugavust valmistab? Minge ja külastage oma kasutajaid. Iga sellise käigu järel tunnen ma ise, nagu oleks silmadelt kae langenud ja asjad on äkitselt palju selgemad. See soovitus ei ole mitte ainult projektijuhtidele või analüütikutele, vaid eelkõige just programmeerijatele ja muule rahvale, kes tavaliselt kasutajaga kokku ei puutu. Võin kihla vedada, et mõne sellise käigu järel kasvab dramaatiliselt teie väärtus nii kliendile kui ka organisatsioonile, kus te töötate, ja tarbijakaitseorganisatsioonid hakkavad saama teie aadressil oluliselt vähem kaebusi.

Arenguvestluste teema on jälle päevakorral ja nagu kunagi eelnevalt kirjutasin, on minu silmis väga olulisel kohal kaastöötajate poolt inimesele antav tagasiside.

Aga tagasiside teemal üks lugu, ei mäleta enam, kust see pärit on, aga loo jutustaja nimi oli Laura.

Laura elas väiksemat sorti kortermajas. Ühel päeval kuulis ta alumiselt korruselt, kuidas naaber (naabri nimi oli Susan) mängib trummi – pumm, pumm, pumm. Ja varsti oli jälle vaikus. Siis mingi aja pärast mängiti jälle trummi, siis oli jälle vaikus. Laura oli üldiselt küllaltki tolerantne inimene ja talle oli oluline naabritega hästi läbi saada, sellepärast otsustas ta, et ei tee asjast välja. Milleks ikka pinget tekitada, eks.

Järgmistel päevadel ja nädalatel kestis trummimängimine aeg-ajalt edasi ja muutus siis sagedasemaks, vahel mängiti hommikul, vahel päeval, siis ka kell kümme õhtul. Pummadi-pummadi-pumm-pumm. Nüüd läks Laural kops üle maksa. Aitab naljast. Tormas, endal pidžaama seljas, oma korterist välja ja alla korrusele ja prõmmis ukse pihta. Susan teeb ukse lahti ja vaatab Laurale ärevuses otsa.

Laura: Mida kuradit sa õige mõtled, et sa teed???

Nüüd Susan, selle asemel, et vastu karjuma või vaidlema hakata, ütleb Laurale: Hm, sa oled tõesti vihane, tule sisse.

Laura astub sisse ja räuskab edasi. Bla-bla-bla.

Susan kuulab ega ütle midagi vastu, küsib ainult: millal ma seda teen? Kui vali see on?

Laura vastab neile küsimustele ja tunneb samas, et ta rahuneb maha.

Ja äkitselt nad lihtsalt räägivad läbi küsimuse osas, mis tundus esmapilgul täiesti mustvalge!

Ja lepivad kokku, et OK, las Susan mängib päeval oma trumme, aga mitte liiga valjusti.

Jutul on mitu moraali:

Tagasiside andmise osas on inimesed tihti kahes äärmuses – nad kas ei räägi asjadest üldse või siis reageerivad üle. Oluline on siinkohal mingi mõistuslik kesktee leida ning rääkida probleemidest kohe, kui need ilmsiks tulevad.

Tagasiside saamise osas võtavad inimesed tihti kaitseasendi ning hakkavad vastu vaidlema, ilma süüvimata, milles teise inimese probleem tegelikult seisneb ja kas seal on võimalik kompromisse saavutada. Ülikergesti oleks praegu võinud juhtuda, et naised oleks lootusetult konflikti sattunud ja kumbki poleks saavutanud, mida ta tahtis, aga sellegipoolest osutus võimalikuks olukord päästa.

Hulkuvate Kasside Riiklik Inspektsioon tellis tarkvarafirmalt Joostes Marss täiendusi oma andmeregistrile. Ülesandepüstitus oli küllaltki selge ja põhjalik ning projektijuht Joosep küsis programmeerija Priidult, kui kaua asjaga läheb. Neli nädalat, vastas Priit, Joosep pani igaks juhuks puhvri mõttes veel nädala otsa ning teatas klient Kustavile, et viie nädala pärast saab asja kätte.

Priit hakkas asjaga hoolega pihta, Joosep käis regulaarselt pärimas, kuidas läheb, ja üldiselt asi sujus. Nagu programmeerimise puhul ikka ette tuleb, tekkis ka siin ootamatuid viivitusi, kuid viienda nädala lõpuks teatas Priit siiski, et kood on valmis.

Joosep helistas Kustavile, et asjad on korras, aga arvas seejärel, et vaatab ise ka siiski funktsionaalsust. Tulemused tõstsid tal ihukarvad püsti – enamvähem iga viie kliki järel rakendus crashis ja praktiliselt ühtki kasutusjuhtu polnud võimalik algusest lõpuni läbi käia.

Joosep tormas kõva kisaga Priidu juurde, et mis toimub. Aset leidis järgmine kahekõne.

Joosep: Mis bl*#¤% selle koodiga toimub??
Priit: Kood sai just valmis ja kogu funktsionaalsus on teostatud.
Joosep: No aga miks see crashib siis, jo*#¤ma*#¤% ?!?
Priit: No aga keegi pole ju seda testinud, loomulik ju, et koodis pole kõik asjad kohe päris õiged.
Joosep: Kas sa ise ei testinud siis oma asja?
Priit: Testimiseks polnud aega ette nähtud, ise küsisid, et kui kaua teostamisega läheb, mitte testimisega. Ja üldse oled ise üks hu*”%¤% !!

Oops.

Asi lõppes sellega, et Joosep istus ise järgmise paari nädala hilisõhtud töö juures ja testis erinevaid stsenaariume ning käis ka Priidul piitsaga kannul. Mõlemad olid stressis ja magamata, Kustav õiendas iga päev, et mis ikkagi toimub, pidi ju valmis olema, ning kui projekt lõpuks üle anti, tekkis seal ikkagi probleeme, sest testimine polnud nii põhjalik, kui vaja oleks olnud.

Lisaks süüdistasid Joosep ja Priit pidevalt ka teineteist asja nässukeeramise eest, Joosep leidis, et Priidu tulemus ei oleks tohtinud selline olla, Priit omakorda, et kõik on Joosepi süü selle pärast, et projektigraafikusse ei arvestatud testimise ja vigade parandamise aega.

Milles siis tegelikult asi? Minu isiklikus kogemuses ei hävi projektigraafikud mitte niivõrd sellepärast, et hinnangud oleksid ebatäpsed, kui sellepärast, et mingid tegevused unustatakse lihtsalt graafikusse lisamata.

Iidseks vaidluste allikaks on siin, et kes peaks tegelikult hoolt kandma, et kõik tegevused oleks arvesse võetud? Programmeerijad sõimavad enamasti projektijuhte, samas õppis Joosep Audentese koolis rahvusvahelist ärijuhtimist ja kuigi ta saab hästi hakkama kliendisuhtluse ja raha lugemisega, on temalt mõneti utoopiline loota, et ta täpselt teaks, mida kõike üks tarkvaraarendaja peab tegema, et asi valmis saaks. Seda enam, et “valmis” võib tegelikult erinevate inimeste jaoks tähendada väga erinevaid asju, näiteks:

• Funktsionaalsus on koodiridadena olemas
• Keegi on rakenduse peamised kasutajajuhud läbi käinud
• Programmeerija on rakendusele kirjutanud unit testid ja need töötavad
• Testija on mingi testimisplaani alusel kontrollinud, et funktsionaalsus töötab
• Tellija on formaalse kava alusel kontrollinud mitmesuguste nõuete täidetust

Jutu peamine moraal kõigile tarkvaraprojektides osalejaile on:

• Täpsustada, mida nimetatakse valmis olekuks, kuna see on olenevalt inimese taustast ja ametist väga suuresti vaataja silmades
• Teha vahet lubaduste (commitmentide), ligikaudsete esmärkide ja tõenäosuslike ajahinnangute vahel ning iga mainitava kuupäeva puhul täpsustada, millega on tegemist.

Konkreetselt programmeerijad on mitmel korral mulle kurtnud, et nende ajagraafikud on ebarealistlikud, sest ei võta kõiki tegevusi arvesse. Peamine nõu, mida ma neile olen andnud, on:

• Tavaliselt on ebarealistlik oodata, et projektijuht ise kõiki tehnilisi tegevusi meeles jõuab pidada ja nende kohta eraldi ajahinnanguid küsida. Seega peaks programmeerija tõusma oma positsioonilt natuke kõrgemale ja ise järele mõtlema, mis on tegelikult projekti õnnestumiseks vaja teha.
• Selle asemel, et keskenduda oma ajahinnangute kitsale definitsioonile ja anda ainult koodikirjutamiseks kuluv aeg, eelda, et niikuinii tuleb sul teha hulk muid asju nagu unit testide kirjutamine, komponenditestimine, süsteemitestimine, vigade parandamine jne. Kui on teada, et keegi teine mingi osa nendest tegevustest enda kanda võtab, on väga hea, aga üldiselt seda ei juhtu ja vaikimisi on parem need kohe hinnangutena kirja panna. Mõte siis selles, et lõpuks tuleb need tegevused niikuinii ära teha, iseasi, kas ületundidena või mingil mõistlikul ajal.
• Kuus kuud hiljem ei mäleta üldjuhul keegi, kui kaua see asi tegelikult aega võttis, küll aga mäletavad inimesed hästi, kas 1) tähtajad pidasid 2) kui hästi tulemus toimis. Töötasin kord koos ühe arendajaga, kelle ajahinnangud alati väga kõrged tundusid. Kui teda aga lähemalt üle kuulata, tuli välja, et tegelikult oli ta graafikusse lisanud ka väga täpsed ja detailsed ajahinnangud sellele, kui palju teste ta ise tahab kirjutada, kui palju võtab aega funktsionaalsuse testijale üleandmine ja tutvustamine, potentsiaalsete vigade parandamine jne. Ja tulemuseks oli, et kuigi ta lõpetas oma lõigu nominaalselt teistest hiljem, oli ta projekti testimis- ja stabiliseerimisfaasi lõpuks teistest ees ning tema kood töötas palju paremini kui kellelgi teisel. NB! See ei tähenda, et kõik võiks lihtsalt oma ajahinnanguid hakata kahega korrutama, vaid seda, et inimesel tuleb tõesti hoolikalt järele mõelda, kui palju nendele ekstra tegevustele kulub ja neid detailselt hinnata!
• Vahel väidavad ülemused või kliendid, et testimine pole oluline, või et selle eest niikuinii ei maksta. Ma arvan, et selline seisukoht on tihti tingitud valdkonna puudulikust tundmisest. Kui keegi tõesti ütleb, et ärme neid lisategevusi graafikusse pane, siis ma soovitan nad enda jaoks sellegipoolest kirja panna ning lihtsalt “koodikirjutamisele” juurde liita. Elu on näidanud, et lõpuks tuleb sellised tegevused nii või teisiti ära teha ja kuna shit flows downhill, näidatakse pärast ikka näpuga progeja peale, et tema tegi halvasti.