Tellija tüübid IT arendusprojektides

Tarkvaraarendus on tiimitöö. Tänapäevased süsteemid on tehnoloogiliselt keerulised, samas eeldatakse nendelt nii head kasutajakogemust kui kiiret edasiarendatavust.

Arenenud on ka tarkvara loomise metoodikad – varasema suurte tükkide kaupa rahulikus tempos arendamise asemele on pea kõikjal tulnud paindlikud ja iteratiivsed meetodid, mis vajavad pea igapäevast kokkupuudet tellija ja arendaja vahel.

On vaimustav töötada koos tellijatega, kes on uuest süsteemist selgelt huvitatud. Sellistelt tellijatelt saab väga head sisendit süsteemi funktsionaalsuse ning selle prioriteetsuse osas. Nad oskavad kaasa rääkida tehnoloogilistes valikutes ning neil on projekti jaoks piisavalt aega. Sellistes meeskondades tekib koostöö ja usaldus, kus kõik on väljas ühise eesmärgi nimel ning tulemused räägivad tavaliselt enda eest.  

Kahjuks ei lähe mitte alati nii. Olles hästi teadlikud, et ka meie ise oleme täiuslikkusest kaugel, võtsime siiski julguse kokku ning kirjutasime allpool läbi kerge huumoriprisma tellija esindajatest, kelle osalemine projektis teeb selle kõigi jaoks palju suuremaks väljakutseks, kui vaja oleks.  

NB! Tegemist ei ole reaalsete inimestega ning nimede kokkulangevus võib olla juhuslik.

Nähtamatu Mart

Mart on tellija poolt määratud töögrupi liige või raskemal juhul projektijuht, keda pole pea kunagi koosolekutel kohal. Ka ei vasta ta mõistliku ajaga kirjadele ega helista tagasi; sisend, tagasiside ja otsused venivad.

Kui muid tellija esindajaid on projektis piisavalt, pole olukord väga hull ning vajaliku sisendi võib saada ka teistelt töögrupi liikmetelt. Kui mitte, on asjad halvasti: projekti meeskonna motivatsioon kannatab, projekt venib pikemaks kui plaanitud või hullemal juhul võib sootuks läbi kukkuda.

Benji-Triin

Triin on võtmetähtsusega tellija esindaja. Tal on oluline mõju projekti üle ja ka soov oma panus anda, kuid mis iganes põhjusel pole piisavalt aega või jaksu, et sellega pidevalt tegeleda. Oma tiimi ta lõpuni ei usalda, samas on tal tugev usk enda arvamuse õigsusse ning veendumus, et juba tehtud otsuseid saab alati muuta.

Triin osaleb projektis kaootiliselt – vahel tihedamini, vahel pikalt eemal olles. Projekti jooksva käekäiguga ta eriti kursis pole, küll aga meeldib talle otsustada ning uusi nõudeid püstitada, et siis taas ära kaduda. Selle tulemusel käib projektis üks pidev tõmblemine, pinged ja stress on üleval ja meeskonna positiivset meelestatust on keeruline hoida.

Andres ja Pearu

Mida paindlikum on arendusmudel, seda rohkem puutub kogu tiim igapäevaselt kokku sisulise tellijaga. Erinevalt Mardist ja Triinust on Andres ja Pearu alati kohal, aga kahjuks on nad pidevalt karvupidi koos.

Koosolekud veedetakse vaieldes ja kokkuleppeid on raske saavutada, mis omakorda mõjub halvasti kogu meeskonna motivatsioonile. Kui see on kombineeritud veel nõrga projektijuhiga, on tulemuseks kaos. Arenduspartner ei saa endale võtta lepitaja ja/või otsustaja rolli!

Arendaja saab kuulata mõlema osapoole argumente ja soove ning selle põhjal lahendusi pakkuda, kuid edukaks projektiks on vaja, et sisulise tellija rollis olevad inimesed soovivad koos töötada sama eesmärgi nimel.

Disainifänn Janno

Jannot huvitab tegelikult vaid üks tahk projektist – väljanägemine ehk visuaalne disain, mitte niivõrd see, mida uus süsteem üldse tegema peaks. Koostöö Jannoga, nagu iga oma ala fänniga, on põnev.

Oluline on siiski meeles pidada, et disain pole süsteem ning Janno ei tohiks olla sisulise tellija ainus esindaja. Vastasel korral on oht, et mõni oluline lõik või funktsionaalsus kogu projektist võib jääda läbi analüüsimata ning realiseerimata.

Tehnoloogiaguru Peeter

Tema teab täpselt, kui palju mingi asi arenduses peab aega võtma, tunneb kõige kuumemaid tehnoloogilisi lahendusi ja tihti surub peale oma lemmiktehnoloogiaid.

Näiteks võib Peeter mõnel konverentsil olla näinud demo lahendusest või raamistikust, mis on alles beetas, kuid tegelik kokkupuude või kogemus tal sellega puudub. Tegelikkuses see lahendus ei tööta nii, nagu esialgu sooviti ning siis hakkab Peeter näpuga hoopis arenduspartneri poole näitama ja väitma, et antud lahendust ei suudeta mõistlikult rakendada.

Kokkuvõttes tekitatakse nii palju peavalu ja ebavajalikku lisatööd kõikidele osapooltele.

Kokkuvõttes

Hea tarkvarasüsteem on tellija ja arendaja ühislooming. Süsteeme loovad inimesed ning nõrkused, olgu nad tellija või arendaja poolel ning tulenegu nad ebapiisavatest oskustest, ühekülgsusest, aja- või huvipuudusest, jätavad tulemusele alati oma jälje.

Ülal kirjeldasime väljakutseid tellija poolel, kuid kindlasti tuleb sellele postitusele ka järg, kus räägime enda vigadest!