IT lahenduste arendamine tundub tihti IT-ga mitteseotud inimesele mingi müstiline tegevus, mida patsiga poisid (ja mõni tüdruk) kuskil pimedas keldris teevad. Vähe sellest, üldiselt on tarkvaraarendus väga kallis ja võtab tihti rohkem aega kui see võtma peaks. Ja isegi kui raha on olemas, siis pole neid patsiga poisse kuskilt võtta, kes sinu asja arendama tuleks.
Tõepoolest, Eestis on märgatav puudus kvalifitseeritud IT tööjõust ja see ei aita kuidagi kaasa tõsiasjale, et Eesti ettevõtted panustavad liiga vähe automatiseerimisele ja kaasaegse tehnoloogia kasutamisele, et oma protsesse efektiivistada. Kuid see on teine teema ja las see praegu jääb.
Tulles tagasi tarkvara arenduse juurde, patsiga poistest ja pimedatest keldritest on täna muidugi asi kaugel. Tehnoloogiaettevõtete kontorid on uhkemad kui kunagi varem ja tänu mitmekesisusele on müüt “tavalisest arendajast” ehk patsiga poisist sisuliselt kadunud.
Jääb järgi küsimus aja ja raha kohta. Kui kallis on kallis, jääb igaühe enda otsustada, aga püüan natuke selgitada, mis seal “pimedas keldris” tavaliselt toimub.
Enda mõtete selgitamiseks kasutan maja ehitamise protsessi kui metafoorilist näidet. Kujutame lihtsustatult ette, et tarkvara või tootearendus sarnaneb suures pildis ehitusega – keegi tellib maja, keegi ehitab selle, keegi hakkab seda kasutama ja nii edasi.
Ma räägin tootearendusest üldiselt, sest see on see, mis on suures pildis oluline. Kui me ehitame maja selle tulevastele elanikele, siis me tahame ehitada sellist maja, mida need elanikud päriselt ka tahavad ja vajavad, mitte lihtsalt katust üle seinte. Tarkvaraarendus (katus ja seinad) on ainult üks osa tootearendusest.
Toote omanik peaks alati nägema suurt pilti ja tegema oma otsused sellest lähtuvalt. Tootearendus ei ole ärategemise probleem (millegi kiiresti valmis tegemine), vaid avastamise probleem (õigete asjade tegemine).
Kuhu kaovad aeg ja raha?
Tootearenduses kulub aeg suuresti kolme erinevat liiki töö peale – uue maja ehitamine (uus funktsionaalsus/toode), olemasoleva täiendamine (teeme midagi paremaks) ja nagu ikka, iga töötav asi vajab hooldust ja remonti (tarkvara tehnoloogiate uuendamine, refaktoreerimine jne). Lisaks pakume me tuge maja omanikele (töö tellija/tootejuht) ja elanikele (tarkvara kasutaja), kellel ka aeg-ajalt küsimusi ja probleeme tekib.
Laias laastus võib öelda, et kolmandik ajast saab ehitada uusi maju, teine kolmandik tuleb jätta olemasolevate täiendamisele ja viimane kolmandik kulub hooldustöödele ning muudele organisatoorsetele tegevustele.
Miks ehitamine tundub alati nii kaua aega võtvat?
Laiendame metafoori veelgi ja oletame, et uusi maju planeeritakse aasta alguses. See esimene kolmandik ajast. See on tegelikult üsna väike aeg kogu kuluvast ajast ja ootused on sellele perioodile suured, tahetakse teha palju – tavaliselt isegi ebareaalselt palju. Suurte ehitiste puhul on mitu keerukat nüanssi, mis kõik mõjutavad ühe või teise asja valmimist. Kõigepealt tasub mainida, et see, mida planeeritakse, on tavaliselt pealkirjade tasemel, stiilis: “maja”, “suurem maja”, “mingi maja”. Algus on pehmelt öeldes hägune. Töö käigus plaanid muidugi täpsustuvad ja kindlasti muutuvad oluliselt. Seega see, mis aasta alguses planeeritakse, ei teostu suuresti aasta lõpuks eeldatud kujul. See on OK, sellepärast vaadatakse plaane jooksvalt üle ja vajadusel muudetakse.
Äri või toote omanik peaks endale teadvustama fakti, et plaanid kindlasti muutuvad ja olema valmis selle muutusega ka toime tulema (ja isegi sellest kasu lõikama!). Selline paindlikkus peab tiimis/protsessis olemas olema, et muutusi sujuvalt hallata. Ma ei ütle, et planeerimine vajalik ei oleks – on küll, aga plaanid ise on lõpuks üsna kasutud. Sellepärast peaks alati fookuses olema väärtuse loomine, mitte pimesilmne plaani järgimine, et saavutada kokkulepitud tähtaeg ja skoop planeeritud eelarve raames.
Kui lõpuks selle “mingi maja” ehitamiseni jõutakse, siis on tõsiasi see, et detailsed ehitusprojektid, kus täpselt kirjas, mida ja kuidas vaja, puuduvad. Ehk siit algab loomingulisus ja määramatus, mis kunagi otsa ei saa. Samuti ei pruugi tulevane majaomanik ka täpselt teada, millist maja ta tahab. Aga ta kindlasti tahab maja. Võib-olla oskab ta öelda, et see maja võiks olla kivist ja punane, vahest isegi selgub, mitu korrust seal võiks olla, aga edasi läheb juba keeruliseks. Jamaks läheb muidugi siis, kui 5-korruselise maja asemel tuleb ehitada 25-korruseline. Veel olulisem on teada, mida tulevane elanik oma uuest majast ise ootab. Aga tema ei oska üldse midagi öelda enne, kui on poole jalaga juba sisse kolinud. See on OK, sellepärast ehitataksegi kõigepealt üks korrus ja siis hakatakse korruseid juurde ehitama ja olemasolevaid sisekujundama.
Detailsete projektide puudumine toob kaasa olukorra, kus tegelikult pole teada, kaua “punase ja kivist” maja ehitamiseks aega läheb. Kui see maja on valmis ja tahetakse järgmist “punast ja kivist”, siis see ei aita ka kuidagi, sest üldjuhul ei ehitata enam kunagi täpselt samasugust maja. Ning teate isegi, kui palju annab sisekujundusse aega ja raha matta ja igasugustesse muudesse pisiasjadesse, mis lõpuks võtavad suure tüki ajast. See on ka OK, sest kontekst muutub kiiresti, soovid ja vajadused muutuvad kiiresti ja seega on mõistlik olla võimalikult paindlik. Oluline on jõuda tulemuseni, mida päriselt vaja on, mitte ehitada suvalist planeeritud kipskarpi põllumaale. Sellist paindlikkust ja kohanemisvõimet muutustega toime tulemiseks nimetatakse tänapäeval agiilsuseks.
Kaks asja, mida tootearenduse juures peaks alati meeles pidama.
Esiteks, ära kunagi küsi kliendi käest, mida ta tahab. Selle asemel küsi, millisele probleemile ta lahendust soovib. See annab sulle võimaluse tegeleda päris probleemiga, mitte kellegi unistustega. Unistusi ja soove on alati palju rohkem kui talente ja aega nendega tegemiseks. See tähendab, et sa ei jõua kunagi sellesse punkti, kus oleks piisavalt inimesi ja ressurssi, et kõiki neid unistusi täita. See omakorda tähendab, et sinu fookus peaks alati olema järgmise kõige olulisema asja leidmine ja siis sellega tegelemine just väärtuse loomise perspektiivist.
Teiseks, toote omanik saab aidata “õigete asjade” tegemisele kaasa sellega, et tükeldab need tööd nii väikesteks mõtet omavateks tükkideks kui võimalik. See annab talle ja kogu tiimile vajaliku paindlikkuse reageerimaks kiiresti muutustele ja samuti aitab see saada kiiremat tagasisidet. Kui see osa töötab hästi, siis lõpptulemusena ehitatakse ka paremaid tooteid.
Omanikuks olemine tähendab vastutust
Probleeme tekib ka siis kui omanik ei suuda ära otsustada, millist maja ta kõige rohkem (st järgmisena) saada tahab ja brigaad peab mitut maja korraga ehitama. Siis läheb objektide vahel liikumiseks jube palju aega ja tegelikult mõlemad majad saavad hiljem valmis. Samuti, kui me juba ühte maja ehitame ja selgub, et on vaja pisem kuur vahepeal püsti panna, siis läheb kogu varustuse kolimisele palju aega. Ja kui esimesele objektile tagasi jõutakse, siis on juba meelest läinud, kus või mis pooleli jäi. Kui “kivist ja sinise” maja ehitamisel on mingil põhjusel kindel tähtaeg ja on teada, et kogu järelejäänud aeg kulub tõenäoliselt selle peale ära, aga ikka on vaja “puust ja punane” veel vahepeal lisaks teha, jääb omanikule arusaamatuks, et kui see “puust ja punane” vahele võetakse, siis “kivist ja sinine” ei saa kuidagi “õigeks” ajaks valmis saada.
Üks kõige suuremaid raiskamisi tarkvara arenduses on mitme asja korraga tegemine. Teisisõnu, on laialt levinud illusioon, et kui teha mitut projekti korraga, siis saab tiimist kuidagi rohkem välja pigistada või rohkem asju valmis. See ei ole nii! Paralleelne töö on tihti toote omaniku võimetuse vili otsustada, mis on järgmine kõige olulisem asi, mida teha ja sellepärast alustataksegi mitut asja korraga (sest kõik peab ju eilseks valmis saama). Mida rohkem asju korraga töös on, seda rohkem võtab aega nende valmis saamine ja see aeg kasvab eksponentsiaalselt. Toote omanik peab olema teadlik sellise tegevuse tagajärgedest ja tegema kõik, et sellist olukorda ei tekiks.
Loomulikult on siin veel rida asju, mis kõik maja valmimist mõjutab – kui palju omanik kohal on ja kui hästi ta oskab oma soove väljendada, kui tihti need muutuvad; vahest jäävad brigaadi liikmed haigeks ja vahest läheb mõni isegi teise ehitusfirmasse tööle. Siis on vaja uus inimene leida. See on päris keeruline, sest ehitatakse jube palju ja tihti ehitatakse üsna keerulisi asju, st suvaline kellumees tänavalt ei saa sellega hakkama. Aga see on OK kui sul on hea mainega ettevõte, sa ei ehita mingeid suvalisi kipskarpe ja ehitad neid maju endale. Endale ehitamine on palju mõnusam. Tekib tunne nagu hakkaks ise seal elama ja siis tahad ikka paremini teha. Lisaks, hooldama peab nagunii ise edasi. Parem juba siis kohe alguses korralikult teha. Otsustada saab ka rohkem. Ja teiste ehitusfirmade töötajad teavad seda.
Täiendused ja hooldused
Teine kolmandik ajast läheb olemasolevate majade täiendamisse. See on sisuliselt prognoosimatu tegevus ja need soovid võivad tulla lauale ükskõik kuskohast – omanik tahab midagi oma maja juures muuta või teha remonti või tuleb seaduse muudatus, kus kästakse kõik aknad välja vahetada. Sisuliselt on see töö, mis kukub sülle maja omanikuks olemisega, sealjuures siiski väikse võimalusega otsustada, mida ja millal teha. Aga see on OK, sest hea omanik teab, kus ta prioriteedid on. Eks?
Viimane kolmandik ajast kulub maja hooldusele ja remondile. Need on asjad, mille peab kindlasti ära tegema. Kui ikka purikad on talvel räästa küljes, siis tuleb need ära võtta. Kojamees ja koristamine on ka üldiselt vajalik, muidu ei taha keegi seal elada. Vahest peab vundamenti putitama või lausa midagi välja vahetama. Või näiteks turvalisus. Kriitiliselt oluliste majade puhul on see nüanss, et turvasüsteemid uuenevad väga kiiresti ja tihedalt. Neid süsteeme on pidevalt vaja uuendada, sest muidu võib juhtuda, et keegi murrab sisse ja varastab elanike vara ära. Siis on jama. Aga see kõik on OK, sest hea omanik teab, et kõik peab olema vinks-vonks. On ju nii?
Süsteemide omamisel on hind ja seda ei tohi alahinnata.
Iga süsteem vajab järjepidevat hooldust samamoodi nagu maja või auto. Kui sellesse piisavalt ei investeerita, siis kasvab tehniline võlg ja lõpuks muutub süsteem kasutamatuks. Kui ignoreerida tehnilist võlga, siis see ainult kasvab ja ei kao kuhugi iseenesest nagu ma olen näinud korduvalt toote omanikke lootmas. Lõpuks ollakse olukorras, kus äriliselt vajalikku muudatust ei saa enne teha kui tehniline võlg on eemaldatud, sest see otseses mõttes blokeerib selle asja tegemist, mida teha tahetakse. Ja siis see viimane kolmandik ajast ei ole enam üks kolmandik, see on oluliselt rohkem. Kas pole?
Lihtsatele küsimustele pole alati lihtsaid vastuseid
Olenemata eelnevast jutust, tarkvara arendamise ja maja ehitamise vahel on siiski mõned olulised erinevused. Näiteks ei tehta tarkvara arenduses detailseid projekte, vaid sketšid ja detailid otsustatakse pigem jooksvalt. Need asjad on nii põhjusega. Valmimise progressi oma silmaga näha pole lihtne, sest pole kerkivaid „seinu“ ja kui lõpuks töö nö valmis peaks olema, siis 2/3 ajast läheb edaspidi endiselt uuendustele ja hooldusele. Toote- ja tarkvaraarendus on kompleksne protsess – see on loominguline ja ei ole väga hästi ennustatav. Kui majad oleks ehitatud nii nagu tarkvara, siis enamus neist ei seisaks püsti.
Tarkvara arenduses on kindlasti rohkem paindlikkust, aga selle tulemusena ka rohkem võimalusi ehitada asja, mida tegelikult vaja pole või mida keegi kasutada ei taha. Sellepärast on hea tulemuse saavutamiseks olulised pehmed asjaolud – alustades koostööst, kommunikatsioonist ja meeskonna füüsilisest asukohast, lõpetades kollektiivse intelligentsuse ja mõtteviisidega. Õpiku järgi tegemine ei vii ka tavaliselt hea tulemuseni – mis töötab ühel, ei tööta teisel. Oluline on õppida, katsetada ja leida võtted, mis sinu kontekstis, sinu inimestega ja sinu toodetega toimib.
Seega, kui palju “kivist ja punane” maja maksab? See oleneb. Aga millal võib ühe ehituse valminuks lugeda? Ausalt öeldes, siis kui keegi seda enam ei kasuta.
Rainer Tikk
LHV IT arendusjuht
Tweet
