Terry London: tarkvaraga käsitööst juhtideta organisatsioonini

Tarkvara loomine on oma olemuselt igapäevaprotsesside automatiseerimine. Lisaks robotkätele toimub väga palju igasuguseid nn paberiliigutamisi, mis kõik vajavad automatiseerimist. Eesmärk on, et inimene suudaks selles bürokraatias orienteeruda ja erisustele kiire lahenduse leida. Tarkvara abil automatiseerimise läbi on meil väga selge ettekirjutus, kuidas täpselt peavad andmed ühest punktist teise liikuma – samamoodi, nagu roboti käsi peab leidma õige koordinaadi pealt õige läbimõõduga objekti. Kirjutab Maarja Kupits.

Ka tarkvaras on probleemiks liigsed kõrvalekalded protsessist – nende tõttu tuleb automatiseerimiseks reegleid aina rohkem ja rohkem juurde kirjutada. Seega, et automatiseerida, peame eelkõige oma inimlikud protsessid lihtsaks ja ühetaoliseks tegema. Näiteks väga lihtne automaatika – lülitit vajutades läheb tuli põlema. Inimesed vajavad standardeid, nad peavad teadma, et lülitid asuvad teatud kõrgusel, on otsitavad teatud kohast ja töötavad teatud viisil. Sel viisil aitab juba nii lihtne automaatika meil paremini toimida.

Automatiseerimisest masstootmiseni

Standardiseerimine on tõlgendatav kui toote tellijale või kasutajale antud lubadus – standardset toodet kasutades on teada, kuidas see töötab – korki tuleb lahti keerata niipidi ja see tuleb lahti. Tarkvaramaailmas on sellega viimasel ajal vabamaks mindud, aga veel kümme aastat tagasi üritasid suurkorporatsioonid tarkvaratellijana peale suruda standardeid, mis tulid riistvara tootmisest. Kuna pealtnäha võib tarkvara ja riistvara tootmine olla sarnane (ja mingil määral ongi), üritati programmeerijaid panna toimima samade kvaliteedistandardite järgi. Tulemuseks on see, et kogu tootmisprotsess läheb kümme korda kallimaks ja kuna tarkvarainsener on tänases maailmas vaba hing, siis ta läheb lihtsalt tööle sinna, kus teda ei sunnita oma tööd tegema talle mittesobival viisil.

Standardiseerimisest edasi liikudes jõuame masstootmiseni. Masstootmise suureks eeliseks on, et see aitab korraga parandada paljude inimeste elujärge. Kui masstootmist ei olnud, siis olid tõepoolest ilusad ja äärmiselt kvaliteetsed asjad, aga väga väheste inimeste käsutuses. Veel mõned aastad tagasi jagati sotsiaalmeedias fotot vanast antiiksest kummutist pealkirjaga, et küll vanasti ikka osati kvaliteetseid ja ilusaid asju teha. Jah, osati küll, aga neid said endale lubada vaid väga vähesed. Teistel inimestel ei pruukinud hööveldatud laudagi olla.

Lisaks annavad automatiseerimine ja masstootmine meile vabaduse. Isegi kui inimene on mõne eriala spetsialist ja teeb oma tööd väga hästi, võib tal ükskord ikkagi tekkida soov edasi areneda või midagi muud teha. Ilma masstootmise ja automatiseerimiseta ei oleks see võimalik, sest need annavad meile võimaluse valida, kas jätkame ise käsitsi millegi tegemist või paneme seda tegema masina ja teeme oma vabanenud ajaga midagi muud, olgu siis töö, enese arendamise või vaba aja veetmise mõttes.

Masstootmise kõrval on olemas hea mõiste „mass customization“: selleks, et tootmine oleks optimaalsem, peame sarnaselt muule tootmisele ka tarkvaramaailmas keskenduma nii-öelda moodulite tootmisele. Need on tükid, mida on võimalik võimalikult paljudes kohtades ära- ja taaskasutada. Parim näide selle kohta on Lego. Legoklotsidega saab mängida, roboteid ehitada, prototüüpida, isegi oma kodu disainida või maja ehitada. Juba toote selline olemus muudab seda, kuidas me toodame – me eemaldume väga kiiresti puulusikate lihvimisest. Ideaalis võiksid tehased olla sellised, et neid ei ole nähagi – kuskil konteineris, logistiliselt ja energia kättesaadavuse mõttes efektiivses asukohas. See tundub veidi ulmeline, kuid 20 aastat tagasi tundus seda ka näiteks pilves paikneva tarkvara kasutamine.

Kuidas kood aitab toota?

Et programmeerimise abil kvaliteetsele tootmisele kaasa aidata, vajame selgeid otsuseid, kuidas äriprotsess töötab. Selleks, et midagi automatiseerida, peame teadma, mida täpselt automatiseerime. Siis on võimalik sinna ka tarkvara-riistvara arhitektuur vastu panna. Kes soovib, et tema keskkond muutuks paremaks, automaatsemaks ja kvaliteetsemaks, peab üsna täpselt aru saama, mida ta teeb. Seejärel tuleb tellijatega läbi rääkida, nende ärimaailmast tuua soovid tarkvaramaailma, ja siis need soovid programmeerijatele selgeks teha. Nemad kirjutavad sisuliselt matemaatilised valemid ja käsud, mida miski tegema peab.

Programmeerija on põhimõtteliselt kirjanik ja koodi kirjutamine on unikaalne. Näiteks viis koostöötavat programmeerijat peavad mõistma, et nad kirjutavad ühte raamatut. Nad peavad aru saama stsenaariumist ja sellest, kuhu see välja jõuab. Igal tarkvaral on lõppeesmärk, milleks seda tehakse, ja huvitaval kombel mida keerulisem on lahendus, seda hägusem on lõppeesmärk.

Kui vaatame klassikalisi hankeid, kus tellitakse teatud konkreetne n-ö tükk, siis näiliselt kõik, kes sellest räägivad, arvavad, et saavad aru, mida nad tellivad. Reaalsus on, et see, mida tellitakse, hakkab saabuma väikeste sammude kaupa. Siis tuleb teha otsus, kas programmeerijad pannakse lihtsalt kirjutama nii, nagu nemad aru saavad, või teadvustame, et tegelikult seda päris lõppeesmärki ei tea.

Keerukate tarkvarakeskkondade puhul on väga selge, et tellija peab oskama tellija olla. Kuna paraku on aga väga keeruline tellida midagi, milles endal ekspertiis puudub, siis enamus tellijaid seda ei oska. Seal tulebki appi meiepoolne product owneri roll, ehk siis keegi, kes on tellija ja töö teostaja vahepeal, ja mõnes mõttes õpetab tellijat tellima. Õigel ajal küsimata jäänud küsimus võib hiljem osutuda arhitektuuris nii kriitiliseks, et selle tagantjärele lahendamine muutub eksponentsiaalselt kallimaks.

Tootmise kvaliteedi juures tasub mainida, et tarkvara tootmise puhul on sarnaselt muule tootmisele teatud tingimused, millal see ära tasub. Selleks, et teha hea tarkvara, on vaja, et selle kallal töötaks minimaalselt kolm inimest mitu kuud, pool aastat, suurema projekti puhul aasta. Lisaks, mida ilmselt paljud ei tea – tarkvara aegub, õigemini vananeb. Mitte sellepärast, et see ise hakkaks halvemini toimima, vaid kuna ümbritsevad nõuded sellele muutuvad.

Programmi väiksus ei ole sealjuures nii kriitiline kui see, mida see endaga kaasa toob. Kui programmi saab ühe reaga valmis kirjutada ja on teada, et see jääb stabiilselt tööle, siis miks mitte seda teha. Paraku kaasneb iga kirjutatud koodireaga ka vastutus selle eest, mis pärast toimuma hakkab, kuna tehnoloogia ja nõudmised arenevad. See tähendab, et kui on tehtud tarkvaratoode, tuleb seda pärast hooldada. Hooldamine aga muutub aastate möödudes aina keerulisemaks ja kallimaks. Kahe aasta pärast on see veel suhteliselt lihtne, kümme aastat hiljem katastroof.

Juhtideta organisatsioon

Mida see küsimusi tekitav juhtideta olemine tegelikult tähendab? Selle taga on mõte „management free organisation“, mis tähendab, et kui on 120 inimest, siis peavad nad kõik olema juhid ehk 120 ise mõtlevat inimest. Need inimesed peavad endale teadvustama, mida nad siin teevad, miks nad siin on, mida nad saavutada tahavad, oskavad seda mõistlikul viisil teistele edasi anda ja samas ise aru saada, mida teised tahavad.

Kui kümmekond aastat tagasi täitsime tarkvaraarenduse tellimusi, siis umbes neli-viis aastat tagasi otsustasime oma fookuse suunata pigem disainiettevõtteks kui tarkvaraarendajaks olemisele. See ei tähenda koodi kirjutamisest loobumist – vastupidi, lisasime oma teenuste hulka ka kliendi keskkonnas oleva lahenduse disainimise nii, et kliendil on seda hea ja mugav kasutada ja see vastab tema vajadustele.

Sealt oleme praeguseks arenenud nii kaugele, et oleme ettevõtetele juba ärikonsultandid – aitame klientidel aru saada, kuidas nad veel paremini saaksid äri teha. Selle nimel olemegi viimased kolm aastat keskendunud elektroonikatööstusele, et paremini mõista, mis keeles need ettevõtted räägivad, millised on üldised ärivajadused, et sellele tarkvaramaailmast oma tõlgendus tuua ja klientide eesmärke tarkvaras realiseerida aidata.

****

Terry London on ühe Eesti suurema tarkvaraarenduse ettevõtte Proekspert AS tootejuht. Maarja Kupits kuulas tema loengut ja tegi selle olulisematest teesidest kokkuvõtte.