Tarkvaraarenduse kohta on levinud rida linnalegende – näiteks, et see on kliendile kulukas ja aeganõudev, et arendaja töö nõuab head haridust ja pakub alati kõrget tasu või et tarkvaraettevõtted on jõukad ja edukad. Selles loos ei hakka me ühtegi neist väidetest kinnitama ega ümber lükkama, vaid vaatame hoopis arendustöö köögipoolele.

Mida teevad erinevates rollides spetsialistid tarkvara loomise juures? Kuidas tegelikult valmivad lahendused, millest mitmeid Sa tõenäoliselt ka ise sageli kasutad? Olgu see siis tööl, koolis või kodus, Eesti ühiskonna liikmena ning erinevate teenuste kliendina. 

Fujitsu Estonia tarkvaraosakonna tööst räägivad osakonna juht Marek Sokk, meeskonnajuht Mait Koppel, projektijuht Margus Malva, analüütik Reeni Mikkelsaar ja arendaja Ardi Aasmaa.

Töö projektiga algab müügifaasist. Meie fookus on valdavalt avalik sektor ja enamasti tegeleme suurte projektidega, mis tulevad meile läbi hangete.

Iganädalasel meeskonna koosolekul vaatame üle, millistele projektidele tahame pakkumise teha. Otsus sõltub sellest, kas need kattuvad valdkondadega, kus me juba tegutseme ja kus meil on nii tehnoloogia kui  valdkonna teadmised.

Huvi pakuvad ka sellised projektid, mida näeme oma tulevase arengusuunana. Peame kaaluma, kas meil on konkreetse töö jaoks vaba ressurssi ning kas suudame pakkumise teha konkurentsivõimelise hinnaga, aga samas ärile kasumlikult.

Kui oleme hanke võitnud, läheb see juba meeskonnajuhi ja projektijuhi kätte. Osakonna juhina jään aga alati vajadusel toetama ressursside hankimise või kliendiga suhtlemise olulistel hetkedel.

Osalen projektis aktiivselt juba pakkumise koostamise faasis. See on päris suur töö, sest hangetes tuleb esitada mahukas dokumentatsioon. Mõnikord on nõutud ka proovitöö, mille jaoks on vaja leida ressursse ja eraldada selle tegemiseks aega.

Kui pakkumine osutub edukaks ja oleme projekti võitnud, on minu ülesanne komplekteerida meeskond – leida inimesed kõigisse vajalikesse rollidesse ja panna nad ühtse tiimine tööle.

Uue projektimeeskonna kokkupanek on omajagu keeruline ülesanne. Tuleb veenduda, et vajalike oskustega inimestel on ajaliselt võimalik selle töös osaleda. Kui kõiki inimesi ei leidu meie meeskonnas, siis kaasame spetsialiste teistest osakondadest, välistelt partneritelt või Fujitsu teistest riikidest. Fujitsu Estonia  tarkvaraosakonnas töötab umbes 70 inimest ja lisaks kasutame 15 inimest allhankijatena.

Väliste spetsialistide arv on praegu suur, sest kasv on olnud kiire ja samas tempos töötajaid juurde värvata ei ole jõudnud. Sel aastal oleme värvanud üle 20 inimese, kuid see pole piisav, sest projektide käive on kasvanud 100% – eelmise aasta 1 mln eurolt 2 miljonini selle aasta lõpuks.

Värbamine on oluline osa tiimijuhi tööst ja see käib tegelikult kogu aeg. Kõige keerulisem on just heade arendajate leidmine, teiste rollidega on lihtsam.

Kas värvata enne või pärast hanke võitu? Tegelikult paralleelselt. Ühelt poolt ei saa võtta inimesi ootele ja teiselt poolt ei saa ka värbama hakata alles siis, kui projekt on võidetud. Need peavad käima käsikäes. Projekti on ka väga raske müüa, kui inimesi selle jaoks saadaval ei ole.

Pärast lepingu sõlmimist algab tegelik elu projekti köögipoolel. Algav töö on mulle juba põgusalt tuttav, sest projektijuht osaleb ka pakkumise ettevalmistamisel.

Projektijuhi ülekandeks on kommunikatsioon erinevate osapoolte – tellija ning meeskonna liikmete – vahel, tööde planeerimine ning nende jagamine tiimile. Projektijuht jälgib tööde skoobist ja eelarvest kinnipidamist ning tegeleb inimeste igapäevase juhtimisega.

Mul on praegu käsil 2 aktiivset projekti.

Üks neist on Eesti.ee ettevõtte portaali osa, suur riigihankega võidetud töö, mille meeskonnast suur osa ei ole Fujitsu töötajad. Selle projekti jaoks on tiim kokku pandud mitme ettevõtte osalusel.

Teine projekt on ühine ERP meekonnaga, kus meie tiimi osaks on luua uus veebipõhine moodul PERHi ERP süsteemile. Selles osalevad Fujitsu Hispaania kolleegid. Võtan neid kui oma inimesi, aga kui ka nemad lugeda väliseks ressursiks, siis on ka selles projektis osa arendajatest “võõrleegionärid”.

Selliste hajusate meeskondadega töötamisel on oma eripärad. On vaja rohkem aega sisseelamiseks ja ka igapäevaseks suhtluseks. Sihipäraselt on vaja ehitada ühtset tiimitunnet ja ühise eesmärgi nimel tegutsemise tahet, sest juriidiliselt on allhankijad selle tööga lõdvemini seotud. Lisaks nõuab võõrkeeles töötamine  hoolikat kuulamist, üle kordamist ja selgitamist.

Kõik see nõuab rohkem aega, samas ei ole tähtaegade nihutamine enamasti võimalik. Nii et tiim peab kohanema töö käigus, nö. jooksu pealt.

Majaväliste ressurssidega koostöö on projektijuhile küll väljakutse, aga samas annab osalejale kindlasti lisaväärtust, näiteks võimaluse näha teistsugust töökultuuri ja üksteiselt õppida. Meie üks tugevus ongi võime ja oskus kaasata erinevaid ressursse. Oleme globaalne ettevõte ja me saame teha koostööd Fujitsu teiste riikide üksustega.

Analüütik vastutab kogu projekti käigus loodud funktsionaalsuse eest, et see vastaks kliendi nõuetele.  Analüütiku ülesanne on selgeks teha, mis tulem peab projekti lõpuks valmis olema ja millised dokumendid on vaja kliendile esitada. Analüütik loob erinevatest materjalidest ja eri kanalitest tulevast sisendist, mille hulgas on ka palju “müra”, selge ülesande arendajatele ja samas ka selge ülevaate tellijale.

Analüütiku roll algab juba hankesse mineku otsusest, kus kaalume, kas see töö on meile sobiv. Pärast hanke võitu on esimene asi saada skoop paika – kaardistada nõuded, nõuete pealt kasutuslood, andmemudel, kasutajaliidese vormide hulk ja keerukus, erinevad liidesed, vajadusel ka teistest süsteemidest andmete ületoomine jms.

Mina kirjutan analüüsi esmajärjekorras enda arendajate jaoks – et neil oleks sellest kasu. See aga tähendab, et analüüs on kohati väga tehniline. Kui klient ei ole infosüsteemide tellijana veel nii kogenud, teeme temaga analüüsi koos-lugemist, kus ma veendun, et klient päriselt ka saab aru, mis seal kirjas on.

Dokumentatsiooni struktuuri loomisel võtan eeskuju sellest, missugust analüüsi klient on harjunud lugema. Nii on tal lihtsam ka loodavat sisu mõista. Analüüsi kirjutamisega paralleelselt olen tavaliselt koostanud ka klikitava prototüübi, mis annab kliendile nö. käega katsutava nägemuse loodavast lahendusest ja maandab hilisemaid riske nõuete mitmeti tõlgendamise osas.

Suuremad arendusprojektid jagatakse tükkideks ning analüüs ja arendus liiguvad omavahel ühe sammu võrra nihkes – ühe etapi arendus käib samal ajal, kui järgmise jaoks tehakse analüüsi. Analüütik osaleb projektis selle algusest kuni lõpuni.

Kui projekti alguses on rõhk rohkem kliendiga suhtlemisel ja analüüsi kirjutamisel, siis projekti edenedes tuleb palju suhelda ka arendajate ja testijatega. Projekti lõpus valideerib analüütik kõik selle, mis me kliendile üle anname, et nõuded oleks täidetud.

Arendaja töö sõltub palju sellest, kas tegemist on hooldusprojektiga, kus tehnoloogia on juba paigas ning suur osa üldfunktsionaalsusest ette antud, või hakatakse nullist uut tarkvara tegema.

Paljudes hangetes on ka juba väga täpselt ette kirjutatud, milliseid raamistikke tuleb kasutada, teistes aga antakse vabad käed ise valimiseks. Kui saame tehnoloogilised valikud ise välja pakkuda, siis arutavad arendajad läbi, mis need olla võiks.

Valikud sõltuvad nii meie oskustest, varasemate projektide kogemustest kui kliendi poolt kehtestatud nõuetest. Üritame uuesti kasutada seda, mis on hästi õnnestunud ja välja vahetada neid lahendusi, mis pole olnud edukad.

Töö algab üldfunktsionaalsuse ehitamisest, seejärel läheme analüüsi järgi edasi konkreetsemate ülesannete juurde. Arendaja suhtleb analüütiku ja testijaga igapäevaselt kogu projekti vältel. Me teeme väga tihedalt koostööd.

Samuti võib arendaja abi minna vaja analüüsifaasis, kui analüütik ei tunne sügavuti mõne uuema tehnoloogia nüansse. Ja kuigi meie ettevõttes koostavad andmemudeli peamiselt analüütikud, on alati võimalik paluda arendaja abi mudeli valideerimisel.

Püüame vältida olukordi, kus klient muudab oma algset nõuet, kui ta valminud lahendust näeb, sest sellisel juhul tuleb muuta juba nii arendust kui analüüsi. Lahenduse prototüüpimine on siin suureks abiks.

Kui arendus on alles nii varases faasis, et midagi ei ole kliendile näidata, siis on abiks prototüüp. Muutuste tegemine prototüübis on palju lihtsam kui hiljem koodis. Niipea, kui midagi juba on valmimas, paigaldame selle kliendile vaatamiseks ja tagasiside andmiseks testkeskkonda.

Kliendi kaasatus ja osalemine on võtmetähtsusega. Kliendiga suhtlemiseks on kõik kanalid avatud – telefon, Teams, Skype, e-mail, füüsilised kohtumised ja koosolekud. Kui klient töötab kaasa, siis tuleb loodav süsteem lõpuks selline, nagu tal vaja on. Kui mitte, siis agiilne arendus ei toimi, vaid taandub waterfall´iks. Siis hakatakse asju ümber tegema projekti lõpus. Mida hilisemas faasis midagi muuta, seda kallim see on.

Valmis tööle kehtib garantii, mille raames parandatakse esile tulnud vead. Vigadele reageerimise kiirus sõltub lepingu nõuetest, vea kriitilisusest ja konkreetsest tarkvarast. On variante, kus hakkame veaga tegelema järgmisel tööpäeval, aga on ka selliseid, mille jaoks on ööpäevaringne valve.

Mõnikord juhtub, et projekt võetakse vastu vaegtöödega, sest mõnda osa ei ole erinevatel põhjustel valmis jõutud. Seda juhtub just riigihanke projektidega, kus tähtaega muuta ei saa. Hilinemine võib olla tingitud erinevatest asjaoludest, näiteks tööks vajaliku sisendi viibimine. Siis tehakse puuduv osa ära hiljem.

Fujitsus saame üsna paindlikult oma tööaega valida, alguse ja lõpu kellaaeg ei ole väga rangelt paika pandud. Ka puhkuse aega saab ise valida, see ei ole kogu tiimil koos kindlal ajal. Võimalik on vajadusel töötada osakoormusega, et selle kõrvalt näiteks magistrikraadi teha.

Projektide meeskonnas vahelduvad projektid üsna kiiresti, paari aasta tagant. Inimesed ei ole 5-6 aastat kinni ühes projektis. Arendajale annab see mitmekesiseid kogemusi, võimaluse areneda ning õppida erinevaid tehnoloogiaid.

Samas paljudele meeldib olla just tootearenduses – tunda üht asja sügavuti kõigi detailideni. Meil on see võimalus Persona tootemeeskonnas. Arendajatel on seal ekspertidena väga suur sõnaõigus tarkvara edasise käekäigu osas kaasa rääkida ja suunata seda, kuidas mingi funktsionaalsus lahendatakse.

Nii et meil on mõlemad võimalused esindatud ühe katuse all.

Kui tunned, et sooviksid meiega liituda, siis loe võimalustest lähemalt ja võta ühendust Fujitsu Estonia karjäärilehel!

Uued postitused meie blogis