Miks te arvate, et ma midagi tean?

Kas teil on vahel olnud tunne, et te olete üks väga edukas petis: kõik usuvad, et te olete ilus, tark ja osav, kuid tegelikult on teil lihtsalt vedanud? Näiteks peetakse teid mingi asja tunnustatud eksperdiks ja kuulatakse hoolega kõiki teie mõtteid ning ettepanekuid, kuigi enda arvates on teil teemast ainult pealiskaudne ja udune arusaamine. Või panevad õpetaid koolis teile täiesti lambist kõrgeid hindeid. Või räägivad inimesed, kui hea ja sõbralik ja muidu tore te olete, aimamatagi, et tegelikult olete te üks paras tõbras (ja sokid on ka pesemata).

Kui jah, siis palju õnne*, teil on petise (pettuse) sündroom (impostor syndrome)! Petise sündroomi puhul tunneb inimene, et teda peetakse kelleski teiseks – kelleksi targaks/tugevaks/heaks, kuid iga hetk või juhtuda midagi, mis tema tegeliku pale kõigile lõplikult paljastab. Ehk siis siin on kaks osa:

  • uskumine, et ma ei ole see, kellena ma paistan
  • kartus, et see välja tuleb ja sellest tingitud tegevused või tegevusetus

Esimene osa on huvitav – inimene usub, et tema tulemused, positsioon, töökoht või -tasu ei ole saavutatud tänu tema oskustele, teadmistele või võimetele, vaid näiteks:

  • õnnele (“olin õigel ajal õiges kohas”, “pakkusin esimese pähe tulnud lahenduse, lihtsalt vedas”)
  • isiklikele sümpaatiatele, meeldimisele (“ma meeldin õpetajale/ülemusele”)
  • muudele parameetritele (“olen kukk kanakarjas”, “teisest rahvusest inimene on ju huvitav” või muu nö “auhinnaline koht”, põhimõtteliselt vähemuste eelistamine)
  • väga suurele isiklikule tööle (“tegelikult olen ma rumal, aga ma õpin hästi palju”)

Inimese uskumust ei kõiguta järjepidevad ning pikaajalised objektiivsed märgid, näiteks tõepoolest hinded, kolleegide ja klientide tagasiside, otsesed töötulemused jms. Kõiki selliseid märke tõlgendatakse otseselt pettuse tulemustena, kõiki eksimusi aga “tegeliku mina” väljendustena.

Kõige levinum esmane petise sündroomi kogemus on koolist või ülikoolist – ühel hetkel te saate kiita millegi eest, mille kohta te ise tunnete, et tegelikult te teemat hästi ei valda. Näiteks võetakse teie mingi koolikirjand või uurimustöö ja palutakse mingil kuulsal konverentsil ette kanda. Teised esinejad on kõik tuntud tegijad ja te ei saa kuidagi aru, kuidas teie küündimatu käkerdis äkki nüüd siia seltskonda sattus. Aga teete vaprat nägu – ja enamasti “petategi” kõik ära, inimesed isegi kiidavad. Ja sealt see alguse saabki. Teine traditsiooniline avaldumishetk on lapsevanemaks saamine/olemine/kasvamine – “püha taevas, ma olen tegelikult täiesti suvaline nolk, ma ei tea lastest midagi ja nüüd pean hakkama kellegi teise eest vastutama. Elu sees ei ole ma nii tark kui minu vanemad/kõik teised korralikud lapsevanemad”.

Hea uudis on see, et seesama kuulus konverents – ka enamus ülejäänuid tunnevad ennast petistena. Lihtsalt vähe pikema staažiga. Enda petise tundmise eeldus on tegelikult mingi saavutatud tase valdkonnas. Näiteks lastekasvatuse kõige kõvamad “eksperdid” on kõik need, kellel lapsi ei ole. Et aru saada, et sa midagi ei tea, on vaja päris palju teada. Petturi sündroomi erilisteks riskigruppideks on naised, akadeemiline seltskond, kõrge saavutusvõimega inimesed ja vähemused. Laiemalt kõik, kes on jõudnud kaugele, aga on probleeme enesekindlusega.

Üks huvitavamaid näited Eestis on laskesuusataja Roland Lessing, tema suust näiteks laused “Ma pole lamades kunagi osanud lasta.”, “Laskmine läks täna lihtsalt õnneks. Lasta pole ma kunagi osanud.”  ja muud sellised. Kuigi tegemist on Eesti praeguse hetke kõige kõvema laskesuusataja – MK etappidel kohad 2, 7, 10.

Teine pool ehk hirm pettuse ilmsikstuleku ees paneb inimesi tegema kummalisi asju. Võidaksegi minna edaspidi teadlikult pettuse peale välja – näiteks tõepoolest manipuleerides, meeldida proovides, isegi äärmuslikke meetodeid kasutades (plagiaat vms). Või hoopis üritatakse vältida kõiki selliseid situatsioone, mis “nõuavad” enda tõestamist – näiteks loobutakse vabatahtlikult tööst (“enne, kui minu ebakompetentsus välja tuleb”), ei kandideerita konkurssidel, ei minda võistlustel starti. Mõlemal juhul asi psühholoogiliselt siiski kurnav, sest mõlemat liiki tegevused ainult süvendavad petturi tunnet ja see omakorda “avastamise” kartust. Surnud ring.

Sellised tundeid tunnevad mingil eluhetkel kõik terve enesekriikameelega inimesed, kuid enamasti ei hakka see elu segama. Keerulisematel juhtudel – võib. Hea uudis on see, et intelligentsed inimesed, kes selle alla kannatavad, on võimelised ka ümber õppima. On erinevaid teraapiad, eneseabiraamatuid ja lihtsalt nimekirju. Kõige tähtsam on aus ja objektiivne mõtlemine. Inglise keeles kutsutakse seda “pardi testiks” (duck test) – “Kui see kõnnib nagu part, ujub nagu part ja prääksub nagu part, siis see on part”. Ehk kui su tulemused on head ja inimesed arvavad, et sa oled hea, siis sa ilmselt oledki hea.

Lisalugemist:
http://www.director.ee/neurootilise-pettuse-sndroom-mis-ohud-vivad-selle-taga-peituda-kui-juht-ennast-petisena-tunneb/
http://en.wikipedia.org/wiki/Impostor_syndrome
http://www.forbes.com/sites/margiewarrell/2014/04/03/impostor-syndrome/

* Palju õnne selles mõttes, et enamasti vaevab see tõepoolest just üle keskmise võimekaid inimesi, oskusteta inimestel on pigem Dunning–Krugeri efekt, nad ülehindavad oma võimeid ja oskuseid.


Kujutlusvõime jõud

Kujutage ette, et viibite mõnel soojal lõunamaa saarel mererannas. Lebate mugaval lamamistoolil ja vaatate, kuidas lained laisalt rannale voogavad. Taevas on sini-sinine ja meri teist värvi sini-sinine, palmid õõtsuvad kergelt pea kohal ja õrn tuulehoog kõditab varbaid. Kiiret pole kuhugi, kõht on täis, tuju hea. Kaalute vaikselt, kas minna ujuma, tellida ettekandjalt veel üks kookospähklijook või tukkuda niisama… Pange korraks silmad kinni ja proovige kõike seda ette kujutada.

Tuli soe ja pehme tunne? Täpselt sama edukalt (või veel edukamalt) on võimalik tekitada ka negatiivseid tundeid – hirmu, viha, ärevust. Tegelikult me teeme seda kogu aeg meenutades minevikku ja ette kujutades tulevikku. Mõne ebameeldiva sündmuse meenutamine paneb meid ka praegu halvasti tundma, tulevase puhkuse ettekujutus tekitab hea tuju – ilma et reaalsuses midagi muutuks.

Meie aju ei ole tegelikult väga taibukas, tal on tõsiseid probleeme reaalsuse ja fantaasia eristamisega. Lapsed õpivad selle ära umbes 5-6 eluaasta paiku (päkapikke pole olemas!), kuid ka siis on see tunnetuslik ning põhineb teadmistel ja varasematel kogemustel – mis asjad on üldse võimalikud. Aga isegi täiskasvanuna oleme und nähes tavaliselt üsna kindlad, et see toimub päriselt, teatud psüühikahäired ja meelemürgid tekitavad sama efekti ka ärkvel olles (http://et.wikipedia.org/wiki/Luul). Ning isegi kui me teame, et meie kogemus ei ole reaalne, vaid põhineb kujutlusvõimel, on emotsioon vägagi reaalne – raamatut lugedes voolavad siiski pisarad ja arvutimängus luurates on närvid läbi nagu politseikoeral, kuigi me teame väga hästi, et see kõik on “mängult”.

Hea on aga see, et me võime selle nõrkuse enda kasuks pöörata ning see on üks väga võimas ja kasulik oskus. Mitte küll päris sellel tasemel, nagu kadunud Minn ütles – “Külm on ainult emotsioon”, aga abiks on ikka. Ehk kui tuju on kehv, võiks proovida meelde tuletada või ette kujutada olukorda, kus oli hea olla. Hakkab parem. Muuseas, seda me tegelikult tihti teemegi: ümbritseme ennast ilusate plakatite-piltidega, kuulame lemmiklaule, sööme kindlaid sööke, mis seostuvad meile heaoluga.

Oskus on teha seda teha teadlikult, nö tellimise peale ja varieerida emotsioone. Enimlevinud on ilmselt magamaminekuks rahunemine, aga sama edukalt saab ennast häälestada avalikuks esinemiseks, keeruliseks läbirääkimiseks, pingeliseks tööks, raskeks võistluseks, milleks iganes. Ehk siis juba ette valime ise selle meeleseisundi, milles me tahame olla ja ise tekitame selle endale. Välistest tingimustest hoolimata. On veel erinevaid nõkse, kuidas soovitud meeleolu nagu lülitist sisse-välja lülitada – põhimõtteliselt tuleks tekitada endal Pavlovi refleks, kus pilt, puudutus, heli või lõhn vallandab mingi käitumise või emotsiooni. Neurolingvistilises psühholoogias öeldakse selle kohta ankur (anchor).

Selliste võtete kasutamine nõuab aga eelnevat harjutamist (nagu ka kõik muud oskused). Harjutada tuleks võimalikult turvalises keskkonnas ja esialgu lihtsate mälestuste olukordadega. Ning proovida kasutada kõiki meeli – pilt, helid, puudutused, lõhnad. Detailsuse aste on valikuline, aga kõige olulisem on saavutada soovitud tunne. Eriti efektiivne on situatsioon niimoodi meelde jätta siis, kui see reaalselt toimub, siis on hiljem lihtsam ka meenutada.

See ei ole aga sugugi mitte ainus kujutluse kasutusviis. Teistest viisidest aga hiljem, huvilised võivad lugeda Tallinna Ülikooli õppematerjale – http://www.tlu.ee/opmat/ts/TST6007/visu/index.html


Kasutajalood, mittefunktsionaalsed nõuded ja ärakasutajalood

Kasutajaloo (user story) konseptsioon on tarkvaraarenduses väga tuttav. Selle formaat ja ülesehitus üldiselt lihtsad – “<Rollina> tahan <teha seda>, et <saavutada midagi>”. Näiteks:

“Bussijuhina tahan näha nimekirja järgmise päeva liinidest, et saaksin ennast ette valmistada”.

Kasutajalood keskenduvad enamasti mingile funktsionaalsusele, seega toote omanikule (product owner)/tellijale/lõppkasutajale lihtsalt mõistetavad, seega ka hinnatavad-võrreldatavad (prioritiseeritavad). Mittefunktsionaalsed nõuded on aga sageli märksa udusemad – “süsteem peab toetama 1000 samaaegset kasutajat”. Keda see huvitama peaks, mis on selle prioriteet?

Teatud pingutusega võib ka mittefunktsionaalsed nõuded ümber kirjutada kasutajalugudeks:

  • Suurem osa lehekülgi peab avanema alla 1 sekundi, sealhulgas kõik enamkasutatavad leheküljed. ->
    • Kasutajana tahan, et kõik enamkasutatavad leheküljed avaneks alla 1 sekundi, et minu töös ei oleks tarbetuid katkestusi süsteemi taga oodates.
  • Süsteemi peab saama kasutada Chrome, Firefox, IE kui ka Safari veebilehitsejaga ->
    • Kasutajana tahan süsteemi kasutada nii Chrome, Firefox, IE kui ka Safari veebilehitsejaga, et ma ei peaks arvutisse installeerima spetsiaalset brauserit.
  • Info allikas, selle muutmise ja hävitamise fakt peavad olema tuvastatavad ->
    • CIOna tahan, et kogu info allikas, selle muutmise ja hävitamise akt on tuvastavad, et saaksin vajadusel esitada neid tõendina kohtusse.

Ja nii edasi. See aitab tellijat ühe või teise nõude tähtsuse hindamisel ja ideaalses scrumi-maailmas backlog’i (ametlik tõlge “tegemate tööde nimekiri” on selgelt pikk. Päkkloog? Varn (nagu homse varn)? Tööde kuhi?) järjestamisel ning tööde tellimisel.

Päris kasutajalood need aga siiski ei ole, sest noh, 1 sekundi reegel peab jääma kehtima igavesest ajast igavesti ja seega on üsna keeruline võtta kätte ja see ära realiseerida. Realiseeritav tundub olevat pigem mingisugune koormustesti/monitoorimise lugu. Näiteks:

“Projektijuhina tahan, et iga tarne järgselt jookseks automaatselt koormustest, mis tuvastab 1 sekundi reeglile vastavust, et ennetada jõudlusprobleeme.”

Omaette ooper on arenduse käigus selguvate vigade, probleemide või täiendustega, mis ei tulene otseselt nõuetest. Näiteks leitakse mingi turvaauk; vajadus muuta arhitektuuri (reafaktoreerida); kasutajaliidese ebakõla; lihtsalt kole kood. Ükski neist ei pruugi tunduda kliendile/lõppkasutajale eriti tähtis – kõik ju toimib muidu ka. Arendaja mõttes on need aga tõsised asjad, millel hiljem võivad olla tõsised tagajärjed.

Üks viis neid teadvustada ja prioriteeti tõsta on ärakasutajalood (abuser story). Põhimõtteliselt on tegu negatiivsete kasutajalugudega, millel on ROI(1) (return on investment) asemel ROI(2) (risk of inactivity). Tavaliselt räägitakse neist turvalisuse juures ja tüüpiline näide:

“Kurja häkkerina tahan varastada krediitkaartide andmeid, et saaksin kalleid asju osta”.

Ärakasutaja võib aga olla ka laisk kasutaja, agar klikkija, lihtsalt hästi palju kasutajaid, ajahädas arendaja, halb liidestatud süsteem ja nii edasi. Näiteks:

“Laisa kasutajana ma ei viitsi otsida ja sisestada aadressi juurde postiindeksit ja jätan selle täitmata, et säästa ennast post.ee lehele minekust ja selle asemel midagi meeldivamat teha.”

“Ajahädas arendajana ma ei kontrolli enne koodi push’imist, kas minu koodimuudatus lõhub olemasolevat funktsionaalsust, et jõuda rohkem uusi funktsionaalsusi lisada”.

“Halva liidestatud süsteemina ma jätkan sobimatu vastuse puhul süsteemi pommitamist päringutega, et siiski oma vastus saada”.

Need lood on võib-olla juba arusaadavamad – esimesel juhul on risk on postindeksi puudumine või vale indeksi sisestamine. Võib-olla peaks olema teenus, mis ise indeksi leiab? Teisel juhul on risk toodangus ilmnevad regressioonid ja lahenduseks automaattestid (ja võib-olla commit hook vms). Kolmandal juhul on risk koormus süsteemile. Nüüd säilib lootus, et tellija/toote omanik suudab ka selliseid vigu ja täiendusi paremini koos teiste kasutajalugudega tähtsuse järjekorda sättida.

Ärakasutajalugu ei ole tegelikult päris kasutajalugu. Tal on küll sarnane formaat, ja kui kasutajalool on vastuvõtukriteeriumid (acceptance criteria), siis ärakasutajalool on kummutamiskriteeriumid (refutation criteria) ehk mingid tingimused, mille puhul võime öelda, et vastav ärakasutaja tegevus ei ole võimalik. Kuid ärakasutajalugu ei kirjelda kuidagi tegevust. Ideaalis oleks ärakasutajalugu eepos (epic), mille all oleks konkreetsed kasutajalood:

“Tavakasutajana tahan, et süsteem leiaks ise postiindeksi vastavalt aadressile, et ma ei saaks teha vigu ega peaks seda mujalt taga otsima”

“Projektijuhina/kasutajatoe juhina tahan, et peamised kasutusstsenaariumid oleksid kaetud automaattestidega, et ma ei peaks tegelema live-keskkonna regressioonidega.”

Ärakasutajalugu on üks võte, mis aitab pöörata tähelepanu riskidele, mis ühe või teise asja tegemata jätmisega kaasneda võivad ning leida seal seest tegelikke kasutajalugusid.


Hinnates tundmatut

Eluline probleem tänapäeva Eesti tarkvaraarenduses: “Meil on vaja lisada süsteemile BDOC tugi nii lugemiseks kui ka loomisel. Kaua selleks läheb?”. “Eee… misasi see BDOC on? Kaks päeva? Kaks nädalat? Kaks kuud?”. Ehk siis vahel (või siis üsna tihti) tuleb ette olukordi, kus meile visatakse ette mingi uus tehnoloogia, tundmatu probleem või lihtsalt üks hiiglasuur tükk (“Vajalik aruandemoodul” – heal juhul järgneb sellele 20 lehekülge mingisugusel tasemel nõudeid või kirjeldust). Sellisele asjale on väga lihtne anda kiire ja täpne hinnang, mis ei pea absoluutselt vett (vt ka “Mis on Peipsi järve ruumala?” jms @Targo tarkvara ). Kui aga sõber klient või kallis projektijuht tahab pisut reaalsemaid vastuseid, siis tuleb enne hinnangu andmist pisut eeltööd teha.

Kui meile visatakse ette meile tundmatu küsimus või probleem, siis sõltuvalt detailsuse tasemest on meil neli eeltöö varianti:

  • Eelanalüüs
  • Uuring (research)
  • Väljalöök (spike)
  • Trasseer (tracer, tracer bullet)

Eelanalüüs

Kui probleemi kirjeldus on väga hägus, nii et ei ole täpselt aru saada, milles üldse probleem on ja mida tegelikult vaja on, siis lendab peale analüütik ja teeb eelanalüüsi. Eelanalüüsi mõte on jõuda probleemi tuumani ja kirjeldada lahendus vähemalt kasutajaloo/kasutusloo/sooviloo (User Story, need on näited eestikeelsetest vastetest) tasemel, samuti tuvastada olulised tehnilised kitsendused-vajadused (riistvara, liidesed jms).

Uuring

Kui probleem on enam-vähem selge, aga tehniliste lahendusviiside kohta pole jätkuvalt kellelgi aimu, siis tuleb ilmselt asja pisut uurida. Tüüpiline uuring tähendab otsingumootorite, foorumite ja isikliku kontaktvõrgustiku kammimist – kas kellelgi on olnud sarnane probleem ja mida nad selle lahendamiseks teinud on? Tüüpilised näited on mingite uute komponentide lisamine – otsinguserver, tekstituvastus, arhiivimoodul, andmalaod ja äriintelligents. Uuringu järgselt peaksime teadma, milliste vahenditega me probleemi lahendame.

Väljalöök (spike)

Ma olen väga solvunud, et niivõrd olulisele agiilse arenduse terminile ei ole eestikeelset vastet! Seega kasutan elektrotehnilist terminit. Igatahes – kui meil on teada probleem ning enam-vähem ka lahendusviis või -vahend, siis see ei tähenda veel, et me oskaksime lahenduse sobivust tegelikult ka hinnata. Väljalöök on põhimõtteliselt tehniline prototüüp (proof of concept – jälle, mis on vaste?). See on see koht, kus kirjutatakse koodi – mis küll hiljem ära visatakse. Põhimõtteliselt proovitakse järgi, kas valitud lahendus sobib probleemi lahendamiseks – torgitakse keerulisemaid liideseid; tehakse algelised koormustestid vms. Väljalöök ütleb – jah, pakutud lahendus teeb seda, mis meil vaja on. Nagu kasututajaliidese prototüüp, on ka väljalöögi kood mõeldud äraviskamiseks (praktikas – keeruline). Väljalöögi näide on põhimõtteliselt debugimine vea olemuse teadasaamiseks või käsitsi tehtud andmebaasipäringud.

Trasseer (tracer bullet, teine link)

Vt eelmise lõigu esimest lauset. Seekord kasutame sõjandusterminit. Trasseer on mingi kitsa osa toodangukvaliteedile vastavalt realiseerimine. Trasseeri järel teame, mille pihta me laseme ja kaugel me märgist oleme. Ehk näeme ära, milliseid teisi komponente muudatus puudutab ja kui suured need muudatused tegelikult on. Pärast trasseeri peaks olema disain selge, tehnilised ülesanded fikseeritud ja põhimõtteliselt jääb ainult koodi kirjutamise vaev. Trasseeri saab kasutada ka toodangus – näide kuulsusrikka analüüsimooduli puhul võiks olla üks enamkasutatav raport.

Nagu eelnevast jutust järeldada võib, suudame algsele hägusale probleemile viisakaid hinnanguid anda alles pärast trasseeri. Arendajad võivad nüüd lugemise pooleli jätta ja järgmisel korral BDOC-küsimusele rahulikult vastata “Ma ei oska praegu vastata, aga kui ma seda ühe päeva uurin, siis juba oskan”.

Nendel, kes allkirju jahivad või oma sajalisi luhvitama peavad, tekivad kindlasti küsimused “Kes selle kõik kinni maksab?” ja “Millal ikkagi valmis saab?”.

Teine küsimus on lihtsam. Tavaliselt eraldatakse sellistele eeltöödele kindel aeg, ajakarbistamine või ajalahterdamine (timeboxing) on asja nimi. Ehk siis antakse ette mingi piiratud aeg, mis ülesandele kulutada. Planeerimise (ja näiteks scrumi) mõttes on tegu täiesti tavalise ülesandega – kuluvat aega on kogemusele tuginedes täiesti võimalik hinnata, ülesande realiseerimist saab planeerida ja lõpus hinnata, kas on tehtud või mitte. Pärast seda suudame järgmisele etapile anda juba märksa täpsema hinnangu. Scrumis võib selliseid uurimisi planeerida sprintidesse või lihtsalt eraldada sprindi lõpus mingi aja, et järgmise sprindi ülesandeid täpsustada. Reaalsete projektide puhul (ideaal-maailmas) peaks kõik selle läbi tegema enne kliendile tähtaegade või mahuhinnangute andmist. Aga vaata ka järgmine lõik.

Kogu see eelanalüüs-uurimine-väljalöök-trasseer võib kulutada märkimisväärselt aega (=raha) ja samas on nagu väga vähe reaalseid tulemusi. Ainult trasseer on päriselt ka kasutatav, aga see võib olla ka ainult murdosa kogu lahendusest. Rahanumbrite vaates tegeleb arendaja tundide-päevade kaupa lihtsalt mingi voodooga – öelgu kohe oma hinnang ära, veel parem – tehku lahendus ka kohe ära, kui keeruline see ikka olla saab??? Ideaalmaailmas käivad aga raha ja mõistus käsikäes ja kõik need kirjeldatud tegevused suurendavad tõenäosust, et klient saab ka selle, mida tegelikult vaja on. Kogu tarkvara-arenduse teooria korrutab “mida varem viga avastatakse, seda odavam on parandamine”. Kaks päeva midagi lihtsalt uurida on tundub päris pikk aeg, aga kui alternatiiv on kaks nädalat arendada ja siis avastada, et “nii ikka ei saa”, siis võib-olla ikka tasub uurida (Einsteini arvamus). Uurimisele kulutatud aeg ei ole kunagi mõttetu, see on rubriigist “töötame targemini, mitte rohkem”. Iseasi on selleks reaalselt ka aja leidmine ja eraldamine, kuna

  1. tavaliselt on tähtaegadega jube kiire
  2. klient maksab töötava tarkvara eest

Tark klient tellib ja maksab muidugi ka uurimise eest, sest ta saab aru, et lõppkokkuvõttes maksab ta siis vähem. Mitte-nii-targa kliendi puhul peab kallis projektijuht mingeid muid kavalusi välja mõtlema, näiteks arveldama järgmise kuu arenduste uurimised eelmise kuu realisatsiooni sisse või midagi muud taolist. Fikseeritud hinna, tähtaja ja skoobiga projektide puhul (näiteks riigihanked) on lugu keerulisem ja üleüldse tuleks sellistest projektidest karjudes kaugemale joosta, aga ka siin on lõppkokkuvõttes odavam kulutada aega uurimisele, kui hiljem ägada ebareaalsete ajahinnangute ikkes.

Head uurimist!

Inspiratsioon:
Chris Sterling – Managing Software Debt: Building for Inevitable Change (Agile Software Development Series)

Research, Spikes, Tracer Bullets, Oh My!

 


Tehniline võlg ja tema intressid

Intelligentsed inimesed saavad üldiselt võla ja laenu põhimõttest päris hästi aru – saan praegu palju raha, hiljem maksan rohkem raha tagasi. Ilmselgelt on selline tegevus kõige kasu(m)likum laenu andjale (pangad, eksole:)), kuid teatud tingimustel ka laenajale. Lihtsustatult – laenu on mõtet võtta siis, kui see aitab sul tulevikus rohkem teenida või vähem kulutada.

Tarkvaraarenduses on kasutusel termin tehniline võlg (Wikipedia, Martin Fowler), mis on põhimõtteliselt laen tulevase produktiivsuse/tootlikkusse arvelt. See tähendab, et praegu toodan ühes ajaühikus hästi palju uut funktsionaalsust, hiljem toodan vähem, sest tegelen hoopis varem realiseeritud asjade parandamisega. Võrreldes rahaga on tarkvara tootmise produktiivsus aga suhteline ja mittemõõdetav (Martin Fowler ja technicaldebt.com), mis ajab asja mõnevõrra keerulisemaks. Teatud tingimustel võib produktiivsust ka rahaga mõõta – kui tiim, mis alguses teenis korralikku kasumit muutub pealtnäha põhjuseta vähem kasumlikuks, siis tõenäoliselt võeti millalgi tehnilist laenu (tekkis tehniline võlg) ja nüüd makstakse intresse. Kahjumisse keeramine tähendab, et inkasso tuli ukse taha ka põhiosa välja nõudma.

Tehnilise võla alla käib kõik, mis muudab uute asjade lisamise või süsteemi käigushoidmise järjest kulukamaks/aeglasemaks, näiteks:

Võlg Intressid
lihtsalt halb kood koodist arusaamine nõuab suurt pingutust, muutmisel ootamatud regressioonid
ebapiisav kvaliteet suur osa aega ja energiat läheb vigade parandamisele
sobimatu arhitektuur / suur keerukus sisemine arhitektuuri ei toeta enam edasi arendamist, väike muudatus nõuab fundamentaalseid muudatusi
build’i ja paigalduse keerukus uued paigaldused on mitmenädalased ettevõtmised, sest on palju eel- ja järeltingimusi, et süsteem tööle hakkaks
jagamata teadmus õppimiskõver – mõne süsteemi osa kohta ei tea keegi, kuidas see toimib (Ants teadis, aga ta enam ei tööta meil…)

Ilmselgelt pole see jaotus lõplik ja need kõik omavahel tihedalt seotud, aga soojenduseks käib küll.

Kuidas võlg tekib? Põhjuseid on palju, kuid jagaks need neljaks:

Põhjus Lühidalt Kuidas tekib tarkvaramaailmas? Vaste “päris maailmas”
teadlik risk investeering – oodatav kasu ületab intresse lepinguliste kohustuste täitmiseks (leppetrahvid) või turueelise saamiseks (kiire prototüüp) planeeritud investeeringud
teadmatus ei teata ega osata paremini algaja programmeerija teebki imelikke asju “väikses kirjas tekst” näiteks krediitkaardilepingul
hoolimatus ei huvita arendaja, analüütik või testija, kes vaatab ainult oma kitsast pilti – “mina saan oma linnukese kirja, pärast tulgu või veeuputus” “peaasi, et praegu palju raha on, küll kuidagi tagasi maksan (veel parem – keegi teine maksab)”
tähtajad lihtsalt on vaja asi kindlaks ajaks ära teha lepingust tulevad tähtajad või kindla hinnaga tööd ootamatud väljaminekud või ootamatult vähenenud sissetulekud

Esimene on mõistlik, kuid ei tohi unustada, et võlg on võõra oma ja mida varem tagasi maksta, seda parem (liitintress!).

Teine on väikestes kogustes paratamatu – keegi ei sünni targana. Siia alla käivad ka pisemad hooletusvead. Seda aitavad vältida näiteks koodiülevaatused, staatilised analüsaatorid ja kõige rohkem hariv kirjandus. Enamasti on tegemist probleemiga, mida on üsna lihtne kontrolli all hoida ja ajapikku jääb seda vähemaks.

Kolmas on puhtalt pahatahtlik. Jaole saada aitavad samad meetmed, mis teadmatuse puhulgi, kuid aeg seda viga ei paranda. Kui teil sellised “sõbrad” tööl on, siis ilmselt pole vaenlasi vajagi. Soovitan tõsist südamest- südamesse vestlust või eriala vahetust (näiteks juristiks või poliitikuks).

Neljas on kõige salakavalam ja kõige levinum. Tihtipeale maskeerib ta ennast esimeseks, kuid seejärel “unustatakse” võlg ära ning tulevad juba uued tähtajad. Samuti kiputakse just tähtaegade puhul esimesena ohvriks tooma “mitteproduktiivsed” tegevused nagu koodiülevaatused, refaktoreerimine, automatiseerimine, koolitused jms, mis tekitavad hiilgava võimaluse teisele ja kolmandale kategooriale. Teoorias on vältimine muidugi lihtne – tuleb planeerida realistlikud tähtajad! Praktikas on tarkvaraarenduse täpne planeerimine segu raketiteadusest, peenest psühholoogiast, OCD-st ja nunnudest kassipoegadest. Väikelapsed ja Kettamaailma jumalad tulevad esimesena meelde – planeeri mis sa planeerid, lõpptulemuseks võib vabalt olla ka 42.

Ei, tegelikult saab ka tarkvaraarendust üsna täpselt planeerida ning tulebki. Detailid on juba teine ja hoopis pikem jutt, aga näpunäiteid ikkagi:

  • arvesta süsteemi loomulikku riknemist – tarkvara allub termodünaamika teisele seadusele:). Ehk lihtsustatult – et tarkvara oleks sisemiselt korras, tuleb selle nimel pidevalt tegutseda. Siia alla käib refaktoreerimine, arhitektuuri korrastamine, automatiseerimine, samuti dokumentatsiooni ajakohasena hoidmine. See aeg tuleb arendusse sisse planeerida. Kliendile selle aja maha müümine on muidugi kunst.
  • pane tähele väikseid märke – kui arenduste kiirus vaikselt kukub või live-toe koormus tõuseb, siis see võib olla märk tehnilisest võlast.
  • iga ajaline surve tekitab tehnilist võlga – kui tiim peab tähtajaks tarnima, siis tuleb järgmine tsükkel planeerida väiksema koormusega, sest tuleb maksta intresse ning soovitav oleks ka põhiosa tagasi maksta.
  • usalda arendajaid – kui arendaja ütleb, et korralikult tegemine võtab x tundi, siis võtabki (või kauem). Kui survestada lühema aja peale (nt y tundi), siis tuleb see hiljem ümber teha ja aega läheb x-y/2+n tundi, kus n suureneb vastavalt sellele, kui palju hiljem see ümber tehakse.
  • kui miski on liiga ilus, et olla tõsi, siis ilmselt nii ongi – kui tundub, et tiim liigub üle ootuste hästi, siis tõenäoliselt võetakse vaikselt kvaliteedi arvelt laenu.
  • arvesta liitintresse – hilisem tagasimaksmine on märksa kulukam. Samuti võib võla ignoreerimisel minna pankrotti – ühtegi uut arendust ei ole võimalik teha ilma aeganõudvate parandusteta, kuid selleks ei ole raha/aega.

Lõpetuseks temaatiline laul – Eestimaa on võlgu (parafraseerime – tarkvara on võlgu).

Vaata ka:


SharePoint 2010 – ei saa kustutada tühja kausta

Ütleme, et on mingi SharePointi dokumenditeek, kus on üks näiliselt tühi kaust (kataloog). Kausta kustutamisel saab aga vea:

Mõni teine kasutaja on faili välja möllinud või redigeerimiseks lukustanud.

Esialgne vaatlus ei tuvasta kaustast ühtegi dokumenti, ei sisse- ega välja möllitud. Konks võib olla aga dokumentides (failides), mis on üles laetud, aga ei ole veel kordagi sisse möllitud ning mis on nähtavad ainult kasutajale, kes dokumendi üles laadis. See võib juhtuda, kui on teegis on sisse lülitatud sisse- ja välja möllimine ning versioneerimine.

Igal juhul tuleb lahendamiseks minna teegi sätetesse ja valida sealt “Sissemöllitud versioonideta failide haldus”. Seal kuvatakse kõik sellised failid ning parasjagu sisseloginud kasutaja saab need “omistada” = need jäävad sellele kasutajale välja möllituks. Seejärel saab need vastavalt vajadusele sisse möllida või kustutada.


Agiilne treening

See idee pärineb ühelt kolleegilt, kes seostas muusika ja tarkvaraarenduse – protsess on agiilne ja iteraktiivne ning pärast arendust minnakse live’i (mõnikord minnakse kohe live’i – eriti kõvadel meestel tuleb asi ka siis hästi välja, aga see kuulub rubriiki “ärge seda kodus järgi tehke”). Ma nüüd väänan sellele ideele veel ühe vindi juurde ja räägin hoopis agiilsest treeningust.

Soojenduseks sõnaseletusi tarkvaravõhikutele:

  •  agiilsus (agility) – eestikeelne vaste oleks väledus või kohanemisvõime. Tarkvara-arenduses töökorraldus, kus kliendilt saadakse pidevat tagasisidet tarkvara kvaliteedi ja prioriteetide kohta. Algsest plaanist kinnipidamine ei ole oluline, tähtis on anda kliendile kiiresti töötav tarkvara ning seda hiljem vajadusel täiendada ja muuta.
  • iteratiivsus – maakeeles kordamine. Tarkvara-arenduse kontekstis tähendab, et erinevad protsessi osad (analüüs-arendus-testimine-live) käiakse läbi korduvalt, lühikeste perioodide kaupa ja iga kord võetakse ette ainult mingi väiksem osa tarkvarast. 

See oli siis meelevaldne lühikokkuvõtte, huvilised võivad vaadata agiilse tarkvaraarenduse manifesti või Wikipediat.

Agiilsust saab aga suurepäraselt rakendada ka spordis ja kui päris aus olla, siis seda ka tehakse, aga ei nimetata just päris nii. Milline oleks siis agiilne sport? Kohandame Agile Manifesto ideid ja saame:

Sporti tehes ning teisi spordi tegemise juures aidates oleme leidnud selleks tööks paremaid viise.
Oleme hakanud hindama:

  • reaalset tulemust rohkem, kui kõikehõlmavat treeningplaani
  • inimesi ja nendevahelist suhtlust rohkem, kui protsesse ja -vahendeid
  • koostööd treeneri, ametnike ja sportlase vahel rohkem, kui reegleid ja käske
  • reageerimist muutunud oludele rohkem, kui algse plaani järgimist

Ka parempoolsetel teguritel on väärtus, kuid me hindame vasakpoolseid tegureid kõrgemalt.

Mida see kõik ikkagi tähendab? 

Kõigepealt peab olema mingi visioon tulemusest, milleni me tahame jõuda, mida me tahame saavutada, miks me sporti teeme (vastavalt – millist probleemi meie tarkvara lahendab).
Seejärel on mingisugune plaan, kuidas selleni jõuda – arvestades olukorda, millest alustamine. Ei pea olema eriti detailne (see on üldanalüüs).
Siis võetakse üldplaanist mingid osad, mis on kõige tähtsamad, millega tegelemine aitaks meid kõige rohkem edasi ja viiakse need ellu (vastavalt – ühe komponendi/funktsionaalsuse detailanalüüs ja realisatsioon).
Järgneb testimine spordis, mis ongi testmine ja live oleks siis võistlus. Treeningvõistlus on pre-live:)
Testimine annab sisendi hindamisele: kas me jõudsime eesmärgile lähemale? Kas meie eesmärk on üldse õige? Kas üldplaan kehtib? Mis on järgmine üldplaani osa?
Ning kõik algab otsast peale. Sealjuures on olulised inimestevahelised suhted – avatud ja sõbralik suhtumine, kuna eesmärk on ühine (tulemus/töötav ja kasulik tarkvara). Autoriteedi asemel kehtivad kokkulepped. Plaanid on olemas, aga neid võib muuta.

See võib kõlada üsna kaootiliselt ja paradoksaalselt ongi kaose vältimiseks ka agiilsel arendusel üsna kindlad raamid ja protsessid:) Näiteks on mingid fikseeritud ajavahemikud, mille jooksul plaane/kokkuleppeid ei muudeta ja kindlad ajad, millal kõik need üle vaadatakse. Samuti on raudkindel reegel teiste inimeste ja nende arvamuse austamine. Aga üldiselt panebki iga meeskond (mitte võistkonna tähenduses, vaid siis ametnikud-treenerid-sportlased/kliendid-analüütikud-arendajad-testijad kompott) paika omad reeglid ja seejärel austab neid – seni, kuni need uuesti üle vaadatakse.

Ja ideaalis liigume me samm-sammult muudki parema tuleviku poole! Alati kui ma kirjutama hakkan, jõuan ma tagasi ühe põhimõtte juurde – tee mis tahad, peaasi et hea saab:)


Naljad meiliserveriga

Üldiselt ma väga sellistest asjadest väga ei taipa ja väga ei tegele, aga kuna ma olen ühes MTÜs see inimene, kelle poole pöördutakse, kui “arvutitega mingi jama” on, siis vahel ikka trehvab.

Ühesõnaga – umbes aasta tagasi kolisime meiliserveri Google Appsist “oma” meiliserveri peale (teenusepakkuja juurde). Sai MX kirjed palutud ära vahetada ja puha. Kõik toimis. Ja siis järsku, paar nädalat tagasi naljakas lugu – umbes üle ühe meilid läbi ei tule. Ja mitte nii, et ühest kohast tulevad ja teisest mitte, vaid ka samast kohast saates täiesti üle ühe.

Tundub müstiline? Kogenud adminnid ilmselt vaataks ainult peale ja kohe teaks, mina pidin ikka pisut mõtlema. Tegelikult oli asi lihtne – teenusepakkuja üks nimeserver viitas õigele meiliserverile, aga teisel oli huvitaval kombel Google Appsi kirjed. Kusjuures esimene kontroll seda ei tuvasta (sest sellele vastas “õige” nimeserver), vaid tuligi teha kaks päringut.

 


Rutiin – sõber või vaenlane

Kui rutiinist räägitakse, siis pigem negatiivses mõttes – rutiin on midagi igavat ja üksluist. Töökuulutustes ei leia eriti lauseid “lubame rutiinset tööd”, ikka lubatakse vaheldusrikkust. Tegelikult on rutiinil hoopis laiem tähendus, hõlmates kõiki meie harjumusi, eelistusi ja ka rituaale. Selles mõttes vajab iga inimene rutiine ja rutiinsus.

Lühidalt on rutiin meie harjumuspärane käitumine, millel on omad eelised. Rutiin on:

  1. efektiivne ja ökonoomne, sest me oleme seda palju-palju teinud
  2. poolenisti alateadlik (reflekside tasemel), ei nõua ka erilist vaimset pingutust
  3. tekitab kindlus- ja olukorra kontrollimise tunnet, sest kõik toimub nii nagu alati

Näited rutiinidest võib tuua seinast seina, neil on võib olla erinev ajaline mõõde või detailsuse aste. Rutiin on see, kuidas meile meeldib hambaid pesta; kuidas meie päevakava tavaliselt läheb – millal sööme, millal töötame, millal magame; kuidas kevadel teeme suurpuhastuse ja sügisel käime seenel; millises järjekorras me ajalehte loeme.

Spordis on väga spetsiifilisel kohal näiteks võistluseelne rutiin, mis sisaldab tavaliselt ajaliselt järgnevaid erinevaid tegevusi, sh ka mõtteid. Näiteks maastikujooksu võistlusel:

  • 55-50min enne starti – numbri kinnitamine, stardi- ja finishikorralduse uurimine
  • 50-40min – rahulik soojendusjooks, rajaga tutvumine
  • 40-25min – fartlek (erineva pikkuse ja intensiivsusega intervallid), raja tehnilisemad kohad, raja läbimise plaan
  • 25-20min – lõdvestusjooks, joomine
  • 20-10min – tualett, venitused, taktikaline plaan. 5 min jalad ülesse
  • 10-7 min – kerge jooks, lühikesed kiirendused
  • 7-5 min – venitamine ja hooglemine, võistlusplaani kordamine
  • 5 min – viimane joomine, lahtiriietumise alustamine
  • 3 min – stardikoridori
  • 3-0 min – stardiks valmistumine

See on selline võrdlemisi üldsõnaline ja vaba tõlgendamisega rutiin, palju on iga tegevuse sees valikuvõimalusi ja detaile ei ole välja toodud – peamiselt sellel põhjusel, et ma ei viitsi nii palju kirjutada. Tegelikult sisaldab rutiin vähemalt sportlase/treeneri peas iga viimast kui harjutust ja tegevust.
Sellel on kaks eesmärki:

  1. kõigepealt veenduda, et kõik vajalikud asjad saaksid enne võistlust tehtud, midagi ei jääks kahe silma vahele
  2. hoida ärevust kontrolli all (paljuski läbi esimese punkti)
  3. tekitada teadlikult positiivne emotsionaalne foon

Kolmas punkt on huvitavam ja mõeldud edasijõudnutele, aga esimesed kaks on ilmselt mõistetavad. Selliselt saab rutiine edasi kanda ka päris elusse ja paljud kannavadki. Igasugused nimekirjad, protseduurid ja reeglid on täpselt seesama asi. Tüüpiline on reisile minek või tarkvara puhul tarne: meil on üsna täpselt teada, kes millal mida teeb ja põhimõtteliselt peaks see vähendama igasuguseid ebameeldivaid üllatusi. Elagu rutiin!

Albert Gray on öelnud: „Edu saladus peitub selles, et edukad on muutnud harjumuseks nende asjade tegemise, mida ebaõnnestujatele teha ei meeldi.” Palju lihtsam on teha tüütuid, raskeid või ebameeldivaid asju poolautomaatselt, muutes nad rutiinseks. Hommikurutiini sisse käib hambapesu. Õhtuse rutiini sisse käib järgmise päeva asjad kokkupanek. Kohe pärast trenni panen asjad kuivama. Kui sellised tegevused on automaatsed, siis on palju vähem võimalusi ka mõelda, et “ah, ei viitsi praegu”. Teed ära ja kogu muusika. Rutiin tuimestab, aga ka negatiivseid elamusi. Teine võimalus on lihtsalt tegevus kalendrisse kirja panna. Kui hambaarsti aeg on kokku lepitud, lähed kohale nagu viis kopikat, samamoodi trenni. Ja enne kui märkad, ongi sellest saanud rutiin või harjumus. (Mul on kirjutamise jaoks ka oma kalendris korduv meeldetuletus:). Ega ma alati suuda seda õigel ajal täita, aga ma siiski kirjutan rohkem kui lihtsalt niisama oodates, kuni inspiratsioon peale tuleb. Mulle alati ei meeldi kirjutada, aga mulle väga meeldib, kui ma olen kirjutanud. Aga see on jälle juba teine teema.)

Rutiinil on aga ka kuri kaksikvend nimega rituaal. Rituaali saab alguse tavaliselt rutiinist ja selle taga on jällegi soov olukorda kontrollida. Rituaal on tuttav, annab meile turvatunde ja positiivse emotsiooni. Samuti meeldib inimloomale oma käitumist ratsionaliseerida ja leida igalt poolt põhjuseid. Tekitatakse omamoodi Pavlovi refleks – treenisin kõvasti, panin punased sokid jalga ja võistlus läks hästi, järelikult tuleb võistluse õnnestumiseks punased sokid jalga panna. Kusjuures see tegelikult toimibki, just eneseusku nõudvate tegevuste juures – platseeboefekt. Ja närides sama maitsega nätsu õppimise ajal ja eksami ajal on tulemused paremad. Aga sellistes rituaalides peitub oht, sest nende algne sisu läheb kaotsi ja jääb alles tühi kest. Rituaali religioosne täitmine ei taga siis soovitud tulemust – punased sokid võivad ju aidata eneseusku üleval hoida, aga tulemuse tagab siiski treenimine, mis rituaalist hoopis välja jäi. Või mis juhtub siis, kui punased sokid on kadunud? Tugevalt rituaali uskuva inimese võistlus võibki ebaõnnestuda, kuigi treenitud on väga hästi.

Minu definitsiooni järgi on rituaal algsest eesmärgist kaugenenud jäik rutiin. Rutiin on tegelikult paindlik ja arenev, olles pidevas muutumises. Mõni rutiin kaotab oma otstarbekuse ja kaob, mõni tuleb juurde. Mõni tekib iseenesest (eriti kahjulik rutiin – näiteks teleka ees söömine!), mõne jaoks tuleb pingutada. Seda paralleeli võib tõmmata ka kõiksugu organisatsiooniliste protsesside juurde: see, et protsess on välja mõeldud ja kirja pandud, et tähenda veel, et see kunagi muutuda ei tohi. Siis on oht muutuda tühjaks rituaaliks.

Et jutt liiga pikas ei lähe, lõpetan parem ära. TL;DR: pange rutiin enda kasuks tööle ja proovige tagurlikest rituaalidest lahti saada.


Miks on SharePoint nagu naine?

  1. On suuteline tegema maailma kõige keerulisemaid asju mängleva kergusega, kuid jääb jänni kõige lihtsamate asjadega
  2. Temas on palju sellist, mille toimimisest tal hästi endalgi aimu pole
  3. Temas on palju sellist, mida teadus/juhendid seletada ei suuda
  4. Kui tema eest hoolitseda, on ta imeline. Jäta hooletusse – ja oled peagi suure jama otsas.
  5. Kõik on disainitav ja seadistatav, aga see nõuab palju teadmisi, aega, raha ja kannatust.
  6. Tihti langetakse valikul petliku välisilme ohvriks.
  7. Versiooniuuendused on väga piinarikkad ja lõppevad tihti ka vana versiooni toetamisega
  8. Mõnikord on lihtsalt “ootamatu tõrge”

Teiste arvamused: SharePoint is Like Sex – The Top 11 ReasonsSharePoint is like a woman (video)