Enamik tarkvaraarendusega kunagi kokku puutunud osapooli nõustub, et suurimaks probleeme tekitavaks komponendiks on see, kui pakkumise tegemisel ei saa nõudeid piisava detailsusega paika. E-äri arendusprojektide ebaõnnestumistest nõuete ähmasuse pärast ja selle vältimisest räägib ligi 12-aastase tarkvaraarenduse kogemusega Lumav Commerce OÜ (Lumav.com) ärijuht Margus Ots.
„Meid on petetud! Tahtsime Ferrarit, aga saime Moskvitši!“
„Aga te soovisite ju mootorit, kere ja nelja ratast võimalikult soodsalt ning kiiresti?“
See on üks tüüpiline olukord pärast ebaselgete nõuete esitamist. Palju sõltub siin nii tellija kui ka arendaja varasemast kogemusest ja teadlikkusest. E-äride puhul on enamikel juhtudel tellijaks kaupmees, kes oma füüsilist kaupa kas era- või ärikliendile müüb. Müües ise käegakatsutavaid ja fikseeritud tooteid, võib ta näha ka e-poe tehnilist lahendust nii-öelda tootena, mis riiulilt võetakse, kohandatakse ning üle antakse.
Tarkvaraarendaja poolt vaadatuna on aga tegemist teenusega ning aega müüakse eesmärgi saavutamiseks. Seega piltlikult öeldes – kes maksab kinni taksosõidu Tallinnast Pärnusse ja tagasi, kui selle sõidu ainuke tulemus on, et Pärnus ei paistnud päike?
Ilma pikema analüüsita „pakkuge ise lahendus välja“ stiilis pakkumiste küsimisel võtab arendaja harilikult arvesse mõned teised sarnase keerukusega projektid ja üritab anda selle põhjal tehtavatele töödele hinnangu. Vastuolud tekivad harilikult sellest, et on kirjas üldine nõue, mille taga tundide arv ning poolte vahel tekib vaidlus – mis töid selles on arvestatud? Arendaja ütleb, et arvestatud tööaja hulka mõned tööd ei mahu, aga kliendi sõnul oleks sellega pidanud arvestama.
Suuremad möödarääkimised tekivad harilikult siis, kui tegemist on suurema süsteemiga. Siis võib juhtuda, et nõudeid arenduse käigus muudetakse või arendaja ei ole pakkumise tegemisel töid planeerides kõike arvestada suutnud. Stiilis „mis on kinkekaardi funktsionaalsuse sees“ vaidluste lahendamine on tarkvaraarenduses suhteliselt tavapärane ning eriti siis, kui tellija samastab tarkvaraarenduse tellimise toote ostmisega. Nõuete täpsustamisesse investeerimine peaks olema osa müügiprotsessist.
Eraldi tellitud detailne analüüs tähendab aga tavaliselt suuremat ajalist ning rahalist investeeringut projekti algfaasis ja paindumatust, kui nõuded muutuvad. Analüüsi sügavus võib olla väga pealiskaudne (funktsionaalsuse nõue) või minna väga detailseks (lähteülesanne arendajale). Kuldne kesktee oleks analüüsida põhjalikumalt kõige riskantsemat osa (näiteks liidestust, disaini) ning muu osa jätta lahtisemaks.
Allpool kirjeldame puuduliku analüüsi üht suurimat tagajärge, millele võiks anda nimeks „Rootsi laud“.
Arendajale kahjulik „Rootsi laua“ efekt
Vanemad meist mäletavad kindlasti Eesti Vabariigi taassünni ajal tehtud reise Soome, kus hommiku- kui õhtusööki pakuti buffeedes ja süüa võis piiramatul hulgal! Kasinusega harjunud endised NSV Liidu kodanikud sõid end viimase vindini täis – endalegi meenub jäätisejärjekorras seismine. Tasuta! Kõik! Nii palju, kui soovid!
Sama efekt võib kahjuks tekkida ka tarkvaraarenduses ja seda nii kliendi kui ka arendaja kahjuks.
Kui kaupmees on tellinud põhjaliku analüüsi koos disainivaadetega ja soovib täpselt sellist lahendust, on edasine lihtne. Waterfall´i stiilis fikseeritud pakkumine tuleb koos detailsete lähteülesannetega, täpse arendusprotsessi ja tegevuskavaga. Kõik on kokku lepitud, kõrvale ei kalduta ja erimeelsused peaksid olema lihtsasti lahendatavad. Kiirema ja parema tulemuse nimel on aga otstarbekam teha arendusi jooksva hinnaga, kus on ruumi ka muudatusteks ja ümbertegemisteks.
Arendajale kahjulik „Rootsi laua“ efekt tekib juhul, kui nõuded on fikseeritud liiga üldisel tasemel, nii et lisasid on teoreetiliselt võimalik tõlgendada projekti osadena. Kuigi selles selgusele jõudmiseks on pakkumises ette nähtud orienteeruv tundide arv, on sellise olukorra lahendamine mõlemale osapoolele igal juhul ebameeldiv, kuna ootused on kummagi poole meelest kardinaalselt erinevad. Enamasti juhtuvad sellised vead kiirustades tehtud müügipakkumistel, kus on ka suur surve hinnale, mängus palju teisi pakkujaid ja tellija kogenematus.
Kaupmehe „Rootsi laua“ olukord on aga seotud enamasti projektijuhtimise protsesside mitte kokku leppimisega või mittejälgimisega (analüüs-ajahinnang-kinnitus) või kliendi poolt pole täpsustatud eelarvet. Peamisteks põhjusteks siin on kiirustamine ning perfektsionism tellija poolt või laseb arendaja projektijuht ennast tempost kaasa tõmmata.
Enamasti algavad sellised projektid väga hoogsalt ja hea tundega – arendajale meeldib klient, kes tellib põnevaid lahendusi, kliendile meeldib arendaja, kes teeb kõike ilma küsimusi esitamata.
Mida rohkem tuleb muudatusi, seda keerukamaks muutub kogu süsteemi haldamine, kuni klient või tema ülemus avastab, et viimane arve on kohe eriti suur ning tähtaega lükatakse järjest edasi. Miks keegi meid ei teavitanud?
Sel juhul tuleb kiiresti määrata eelarve, leppida kokku selle jälgimine ja hinnata ümber funktsionaalsuste prioriteetsus.
Igal juhul on „Rootsi laua“ efekt ebamugav ja emotsioone tekitav – kui oled nii-öelda üheksanda jäätise sisse pressinud ja avastanud, et buffee asemel oled sattunud tavarestorani ning lauanurgale poetatakse arve…
“Palun üks praad, juua ei soovi, aitäh!”
Kujuta ette, et jalutad keskpäeval kaaslasega vanalinnas ja kõht läheb tühjaks. Astud sisse mõnda restorani, tellid päevaprae, kuid kohvi maksab pea sama palju, kui toit ise.
Uudishimulikuna otsustad enda jaoks lahti mõtestada, millest hind koosneb ning põhjendada, miks sellist hinda nõus maksma oled.
Kõigepealt leiad internetist, et kohvi omahind on kümnetes kordades soodsam ja järeldad, et ülejäänud juurdehindlus peaks moodustuma erinevatest komponentidest nagu ruumide rent, töötaja tasu, turunduskulud, tehnika jm. Ostad prae, kugistad selle kuivalt alla ning tõttad siis koju „tasuta“ kohvi nautima.
Ka tarkvaraarenduses võib olla kiusatus tellida arendajalt ainult „vajalik“ ja ülejäänu teha ise. Usaldusliku suhte puhul võidakse osa töid kliendile anda, mida too tunneb, et saaks ise soodsamalt teha.
Tavaliselt antakse testimise suurem vastutus kliendi esindajale, kuid alati peaks täpsustama, mis faasis seda teha võiks.
Varajases faasis ja poolikut funktsionaalsust ei ole kliendi esindajal motiveeriv testida ning kohe esimese vea juures tekib soov pooleli jätta kogu tööd arendajale tagasi saates, testplaani lõpetamata. Kuna klient peab niikuinii tegema vastuvõtutestimist, on meie kui arendaja esimene soovitus oma töötajate aja säästmise nimel seda eelarvest mitte maha kärpida (ja arendajal mitte sellega nõustuda :)).
Analüüsi ja projektijuhtimise kvaliteeti oleme eelnevalt korduvalt rõhutanud ning kõik järeleandmised selles osas on kahjuks mõjutanud kas töö kvaliteeti või rahulolu suhtlusega. Analüüs tähendab lähteülesannete täpsust ning asjakohast dokumentatsiooni; projektijuhtimise osas on oluline kättesaadavus ning info suunamine kokkulepitud kanalitesse, formaati ja ajaintervallidesse.
Ideaalis oleks projektijuht kogu aeg kliendile kättesaadav ning hoiaks jooksvalt kursis, kuid sellel on oma hind nii rahalises kui kvaliteedilises mõttes.
Sellele printsiibile võiks teha suisa nimekonkursi: Mida lihtsamalt kättesaadav on projektijuht, seda vähem kvaliteetsemaks muutub kliendi poolt edastatud info.
Oleme katsetanud – väga lihtne on 24+ tundi kalendrikuus ühe keskmise suurusega projekti puhul Skypes küsimustele vastata. Mis näo teeksite, kui selliste töötundidega arvet näeksite?
Loomulikult on spetsiifilisi arendusi, suuri hooldusprojekte ja perioode (näiteks avalikustamine – ingl. k. live), kus peab suhtlema ülioperatiivselt.
Mida ma Magento (või mõne muu vabavaralise) arendajana kindlasti ei soovita, on osta disaini e-ärile täielikult sisse Magentot (vastavat platvormi) või e-ärindust üldse mittetundvalt inimeselt – sama peaks kehtima ka teiste vabavaraliste e-poe tarkvarade kohta. Hea silmaga inimene loob küll elegantseid lahendusi, kuid olemasoleva platvormi spetsiifikaga (rätseplahendustega on muidugi teine asi) kohandamine võib tekitada kibedaid vaidlusi ja tugevalt lõhkiläinud eelarvet – seda eriti juhul, kui disainer kaasatakse mitte arenduse alguses, vaid lõppfaasis „kinnitajana“.
Magento vaikimisi ette nähtud disaini kasutamine lähteülesandeks võiks küll aidata, kuid piiratud eelarve põhjal on tungiv soovitus kaasata disainer kohe alguses, kuid jätta kasutajaliidese viimane sõna platvormi tundvatele spetsialistidele.
Jätkem iidse võitluse ennast teostada soovivate loovisikute ja tehniliste töötajate vahel – nt. Apple´i laadsete äride puhul – pea piiramatu ressursiga ettevõtete pärusmaaks.
Tarkvara versioonid – lõputu kulu?
Ei ole hea tunne maksta selle eest, mille vajalikkusest sa täpselt aru ei saa. „Mida see versiooniuuendus meile lõppude lõpuks annab?“ on küsitud ilmselt tuhandetel koosolekutel ärijuhtide poolt.
Versiooniuuendused on vabavaraliste tarkvarade üks vastuolulisemaid osasid. Ühelt poolt näitab see, et platvormi haldaja üritab tehnoloogia kiire arenguga kaasas käia, pakkudes suuremat funktsionaalsust ja turvalisust, teiselt poolt tekitab soovimatuid lisakulusid arenduste näol.
Oleme varem kirjutanud nii Magento 1 toe kadumisest kui ka Magento 2 varasemate versioonide problemaatikast.
Kui ärijuhil on ees Excel erinevate kuludega ning ta peab langetama otsuse, kas teha suuremad lisatööd vanemale versioonile või tellida enne lisaks mahukas uuendus. Tundub loogilisem valida esimene variant, sest küll hiljem jõuab kogu süsteemi uuendada…
Vestlustes öeldakse selliste vanal versioonil massiivsete lahenduste kohta „arhailine“, „iidne“, „pärand“ või ka midagi koledamat.
Kui väiksed optimeerimised on ikka vajalikud, siis just suurte lahenduste ehitamine vanale versioonile võib tuua kaasa ootamatusi, millega varem arvestada ei osanud ning säästmisvõimaluse asemel tekivad arenduses hoopis ettearvamatud tehnilised viperused.
Mida suurem on süsteem, seda suurem on ka selle uuendamise kulud ning mitmeid uusi loodavaid tehnilisi lahendusi ei olegi võimalik vanal versioonil kasutada või nõuab see täiendavat investeeringut versiooni alandamisse (ingl. k. downgrade). Klient seisab samuti valiku ees, kas parandada Magento vead olemasolevas lahenduses oma kuludega või oodata uut versiooni.
Versiooniuuenduse tegemise otsus sõltub väga palju projektist endast, ärist ja arenguplaanidest –arendaja esindajana anname kindlasti ka omapoolse soovituse.
Tangot tantsitakse ikka kahekesi
On tegevusi, mis saavad toimuda ainult mõlema poole samaaegsel nõusolekul – näiteks tango tantsimine. Või teine näide, kuidas kaks kiire graafikuga inimest üritavad teineteisele helistada – üks ei saa teist kätte ja kui teine helistab tagasi, siis on jälle esimene kinni.
Nagu igas suhtes, on ka eduka arendusprojekti aluseks sünkroonne koostöö – et üks osapool ei peaks teise järgi liiga kaua ootama. Kõige tõsisemalt väljendub see puhkuste perioodil, kui kontoris olevad inimesed peavad ka väljas olijate töö ära tegema.
Kui puhkuste perioode on võimalik ette ennustada, siis haigusi, õnnetusi, tööjõu liikumist, teiste projektide ootamatut panustamisvajadust (avarii) on keeruline.
Iga olukorra jaoks B-meeskonda ei ole – eriti väikestel ettevõtetel. Ning võibki tekkida olukord, kus meeskond istub, käed rüpes, kuna ei saa kliendilt lähteülesandeid või klient ootab tööde tegemist, kuid meeskond on üle koormatud teiste probleemide lahendustega.
Ülikiire arenduse soovimisel võiks olla olemas pühendatud meeskond nii arendaja kui kliendi poolt ning paljud arendajad on seda teed läinud; see võib tähendada aga kliendi poolt jõude oleku aja kinnimaksmist.
Teine äärmus – ülikiire infovahetus ja analüüsist kohe arendusse panek – võib tunduda kliendi poolt mugavana, kuid seal on omad riskid. See eeldab väga häid protsesse ja sobivaid full-stack inimesi, sest tavalisele arendajale pole mitte midagi demotiveerivamat olukorda, kui projektijuhi pidev torkimine ning ülesannete muutumine.
See on muide üks põhjusi, miks enamik arendajaid ei soovi kliendiga otsekontaktis olla – jätkem see leib vabakutselistele.
Muu arendusprotsessi käigus on võimalik viitega asju põrgatada, kuid avalikustamise (live) ajal peavad kõik olema valmis panustama. Need hetked peab juba pikalt ette planeerima nii kliendi kui ka arendaja poolt ning arvestama ka võimalike nihkumistega.
Sarja järgmises osas vaatame, mis juhtub, kui võtmeisikud vahetuvad ja mis aitab, et projekt õnnestuks ka sel juhul.
Eelmisi osasid vaata siit:
