Tennisberg: tehakse seda, mille eest saab rohkem raha

Tennisberg esineb 25. märtsil Äripäeva seminaril "PARIMAD PRAKTIKAD: Kuidas juhtida IT arendusprojekte strateegiliselt ja kasumlikult?" Ta räägib oma ettekandes sellest, kuidas ettevõtted satuvad tarkvaralõksu ja millised on valikud, et edasi liikuda.Järgneb lühiintervjuuKuidas satub ettevõte platvormilõksu? Kas kliendi sidumine ongi ärimudeli osa?Programmeerijale on aeglase koodi kirjutamine lühikeses perspektiivis lihtsam ja kiirem kui kiire koodi kirjutamine, mittetöökindla koodi kirjutamine on lihtsam kui kõiki juhtumeid arvesse võtva koodi kirjutamine ning mittelaiendatava ja mittehallatava koodi kirjutamine on kiirem ja kergem kui hästi laiendatava ja hallatava koodi kirjutamine. See programmeerimisel kuluva aja vahe muutub projektieelarvetes konkreetseteks tööpäevadeks ning eurodeks. Konkreetselt laiendatavuse ja hallatavuse osas on vahe ehk 20-50%. Kuna valdav enamik tarkvaraprojekte viiakse läbi põhimõttel „võimalikult kiiresti ja odavalt“, ei jää selleks lihtsalt võimalust.Aga seda, et keegi peaks konkreetset plaani, „kuidas me saaksime kirjutada sellist koodi, et klient meiega võimalikult seotuks jääks“, pole ma oma 18-aastase tarkvarakarjääri jooksul kordagi kohanud. Pigem on vastupidi, tehnikud tahaks juba professionaalse uhkuse pärast luua võimalikult head tulemust, kuid ajaline ja rahaline surve ei lase neil seda saavutada.

Miks juhtub mõnikord nii, et arendaja ei tule vastu kui klient soovib tarkvaras muudatusi, mis tema äriprotsesse paremini toetaksid?Tarkvaratööstuse üks iseloomulikumaid jooni on see, et ülesandeid, mida tarkvara abil saaks lahendada, on mitu korda rohkem kui inimesi, kes neid lahendusi suudaks luua. Praktiliselt igal programmeerijal on lai valik teemasid, mille kallal ta töötada saaks. Firmadel on tööde valiku osas määravaks ühelt poolt lihtne mikroökonoomika – tehakse seda, mille eest rohkem raha saab - ning teiselt poolt kvalifitseeritud inimeste saadaval olek.Paljude arenduste puhul on asi ka selles, et arendus ise võib väike olla, kuid see toob kaasa suuri pikaajalisi probleeme kasutajatoe või toote üldise hallatavuse osas.

Millal peaks ettevõte kaaluma tarkvara(platvormi) vahetamist?See on natuke nagu küsida, millal on õige aeg uus auto või korter soetada – kõik situatsioonid on erinevad ja kõigi vajadused on erinevad.Tarkvara peamiseks probleemiks on see, et „väikesi“ muudatusi ja täiendusi tehakse nii palju, et lõpuks ei suuda keegi enam lahenduse kogukeerukust hoomata. Järgnevate muudatuste tegemine hakkab põhjustama vigu, vigade parandamine jälle teisi vigu – nokk lahti, saba kinni.Nagu auto korralik hooldamine pikendab selle eluiga, nii on ka tarkvara puhul (teatud kuludega) võimalik tulevases arenduses tekkivaid probleeme ennetada. Tarkvara „hooldamine“ tähendab koodi nn refaktoreerimist – keerukust püütakse vähendada, sisemisi algoritme üldistada. Vahetamise küsimus on üldiselt rahaline otsus – kui hooldust mitte teha, lähevad muudatused järjest kallimaks, kuni mingil hetkel on uue tegemine lihtsalt odavam kui vana parandamine. Seda, kas tarkvara on sisemiselt „hukka läinud“, pole väljapoole aga enamasti näha, seda saab hinnata vaid lähtekoodi uurimise abil, mis vajab kogenud spetsialisti. Parim soovitus on siin kliendi ja arendaja vahelise usaldusliku suhtluse kultiveerimine, et tekkivatest probleemidest varakult ja ausalt räägitaks.

Mida tarkvara(platvormi) vahetamine tavaliselt tähendab ettevõtte jaoks?Migratsiooni edukus sõltub enamasti sellest, kui hästi kliendi organisatsiooni erinevad osad kaasatud on, mida rohkem klient ise panustab, seda sobivam on tulemus. Tarkvara paigaldamine (eeldusel, et meil on valmistarkvara) on enamasti protsessi kõige lihtsam osa, keerukus tekib inimestepoolse omaksvõtmise ning andmemigratsiooni juures.

Inimeste osas tuleb kindlustada, et nad teavad, mis toimuma hakkab, mis hakkab olema parem, mis halvem (väga harva lähevad asjad ainult ühesuunaliselt paremaks), ning neid adekvaatselt koolitada.Andmemigratsiooni keerukus varieerub nullvariandist (otsustame, et vanu andmeid polegi vaja) kuni täiemahulise tarkvaraprojektini, kus tuleb analüüsida esialgset andmete formaati, seda, kuidas andmeid transformeerida, et nad uue süsteemiga sobiks, luua spetsiaalsed andmete ülekandmise vahendid jne. Suuremahulise tarkvara puhul pole sugugi harv, et Eesti organisatsioonid kulutavad puhtalt andmemigratsioonile näiteks 6+6 (kliendi aeg ja arendaja aeg) inimkuud.