Allikas: Äri-IT Kevad 2026
Autor: Kristina Ilves, DIGMATIX Estonia kvaliteedi- ja metoodikajuht
Kuidas tagada, et luuakse lahendus, mida tellija tegelikult vajab?
Edu mõõdupuuks saavad selgelt kokkulepitud disain, tellija aktiivne kaasamine ja vastutuse võtmine ning üheselt mõistetav kommunikatsioon. Toon välja olulisemad juurutuse tulemust mõjutavad aspektid tellija ja partneri koostöös. Disain ei ole üksnes partneri ülesanne, vaid koostöö, kus tellijal on oma osa.
Mida disain tähendab ja milleks seda tarvis on?
Kui analüüs vastab küsimustele mida? ja miks?, siis disain vastab küsimusele kuidas?. Disain seob tervikuks äriprotsessid ja -vajadused ning konkreetsed lahenduskäigud. Hästi loodud disain on lahenduse kavand, mis aitab juhtida riske, eelarvet ja ootusi. Disaini võib luua eraldi etapis, aga ka põimides sisulised tegevused analüüsi või hoopis arenduse ja testimisega. Sel juhul on see teadlik valik, kus juhitakse ka kaasnevaid riske.
Disain tähendab
- lahenduse läbimõtlemist ja kavandamist;
- lahenduskäikude kirjeldamist detailsusega, mis võimaldab adekvaatselt hinnata arendusmahte ja süsteemi päriselt üles ehitada, st seadistada, arendada, testida ja kasutusele võtta;
- kokkuleppelises ulatuses ja viisil prototüüpimist enne kogu süsteemi valmis arendamist.
Disain pole üksnes arendustöödeks vajalik tehniline dokument, vaid ka tellija ja partneri vaheline kokkulepe selle kohta, kuidas tellija vajadused lahendatakse ja kuidas äriprotsessid lahenduses toimima hakkavad.
Ebamäärase ja lahtiste otstega disaini korral on ka arendamine, testimine, ajakava ning eelarve ebamäärased. Samuti on ebamäärase disaini põhjal keeruline koostada kasutusjuhendit. Ebamäärasus tekitab vaid probleeme.
Juurutuse adekvaatse pakkumise saab üldjuhul teha alles siis, kui lahendus on läbi mõeldud, arendusmahud hinnatud ja on teada, milliseks kujuneb skoop ja millise lahenduskäigu kasuks tellija otsustab.
Disaini töötubades lähtub konsultant disaini kavandist ja võimalikke lahendus- käike tutvustades varem kogutud ja skoopi määratud vajadustest. Võtmekasutajad saavad anda vahetut tagasisidet, vajaduse korral tehakse disainis muudatusi. Töötubades või kodutöödena toimub ka lahenduse seadistamine. Kooskõlastatakse lahenduskäigud, millele hiljem antakse kirjalik kinnitus.
Mõistete ühtlustamine ja ühine keel
Ka disainis tuleb teadvustada, et osapooled võivad oma tausta tõttu sõnu erinevalt tõlgendada. Kui see risk pole varem jutuks tulnud, on disainis viimane aeg selguse huvides kokku leppida oluliste sõnade ja terminite tähendused, tuua vajaduse korral näiteid ning kokkulepped kirja panna.
Selgust aitab tagada ka kokkulepe, et sõnade tõlgendamisel lähtutakse Sõnaveebi portaalis toodud tähendusest.
Dokumenteerimine
IT-lahendustes pole miski iseenesestmõistetav. Ühe jaoks on endastmõistetav üks, teisele teine asi. Näiteks ärianalüüsi lahenduse loomisel mängivad olulist rolli aruannete kasutamise üksikasjad. Keegi ei oska eeldada, kui tihti tahetakse näha uuendatud andmeid – kas iga viie minuti tagant, kord päevas, järgmisel hommikul, kord nädalas või harvemini. Niisiis pole midagi iseenesestmõistetavat, valikud võivad olla seinast seina ning kui tellija pole otsust välja öelnud, võib lahenduse muutmine hiljem kalliks maksma minna.
Kriitilised vajadused ja lahendused tuleb must-valgel kirja panna. Lähtume kokkuleppest, et lahenduses saab realiseeritud vaid see, mis disainis kirjas on. Mida kirjas pole, seda ei ole ega tule enne, kui tehakse uued kokkulepped.
Kindlasti tuleb kooskõlastada, missugune disaini dokumentatsioon koostatakse, kus seda hoitakse ning kas toefaasis jätkub dokumenteerimine sarnase loogikaga. Selguse huvides võib küsida partnerilt dokumenteerimise näiteid.
Kvaliteetne disainidokument on
- arusaadav tellija võtmeisikutele, vähendades arusaamatusi ja möödarääkimise riski;
- piisavalt konkreetne arendaja jaoks, säästes arendustöödeks kuluvat aega;
- ajakohane, tagades nii tellijale kui partnerile ülevaate tarkvaras hallatud protsessist ja lahendusest;
- aluseks testimisel, uute lahenduste juurutamisel, muudatuste tegemisel ja versioonivahetustel.
Disainidokument koostatakse ja kinnitatakse enne arendustööga alustamist kas kogu lahenduse tervikliku dokumendina, äriprotsesside kaupa või toefaasis juurde arendatud lahendustele.
Meie kui tarkvarapartneri seisu- kohast on dokumenteerimine lahenduse vältimatu osa. Professionaalne on dokumenteerida nii, et ka „tulevased põlved“ saavad lugedes aru, kuidas lahendus toimib ja kuidas see on seotud ülejäänud süsteemiga. Ei tellija ega partneri töötajad pole firma või kliendi külge laulatatud. Ei saa ka eeldada, et kümnete klientide protsessid ja lahendused on spetsialistidel une pealt meeles. Vähetähtis pole ka see, et ajakohane dokumentatsioon annab tellijale suurema vabaduse vajaduse korral partnerit vahetada.
Uut lahendust juurutades paneme disaini kirja ka olulised välistused, siis on teadlikud otsused üheselt selged (näiteks jätkata mõnes töölõigus käsitööd, mitte seda automatiseerida).
Mida konkreetsemalt ja detailsemalt kirjeldada, seda kindlam on soovitud tulemus. Enamasti tegutseme aga piiratud ressursi tingimustes, seetõttu peab ka dokumenteerimisel kuhugi piiri tõmbama. Siin tulevad muu seas mängu tellija investeerimisvalmidus ja riskitaluvus. Vahel otsustab tellija lahenduse dokumenteerimise arvelt kokku hoida, sest näeb, et konsultant ja arendaja suudavad ka selleta vajalikud arendused ära teha. Suudavadki, kuid pole haruldased juhud, mil aastate pärast tellitakse dokumenteerimine tagantjärgi, sest riskid on hakanud valusasti realiseeruma. See kõik on aga märksa kulukam kui kohe dokumenteerimine.
Prototüüpimine
Prototüüpimisel võib olenevalt kokkuleppest olla erinev tähendus. Oluline on, et osapooled saavad asjast ühtemoodi aru.
Prototüüp võib olla näiteks
- kokkuleppelises ulatuses seadistatud standardlahendus
- või lisaks ka teatud piirini arendatud lahendus.
Viimasel juhul koostatakse ja kinnitatakse alguses vaid disaini kondikava. Seejärel seadistatakse ja arendatakse prototüüp, tutvustatakse seda tellijale, kogutakse tagasisidet ning otsustatakse koos, kuidas muudatusette- panekute või optimeerimise vajadustega edasi liikuda. Ja alles siis täiendatakse disaini. Selline prototüüpimine eeldab üldjuhul paindlikumat eelarvet, kuid on samas keerukate lahenduste korral kindlam viis ootuspärase tulemuse tagamiseks.
Muudatused ja skoobijuhtimine
Kõik mõistavad, et disaini luues võivad vajadused täpsustuda ning lisanduda võib ka täiendavaid vajadusi. Igal juhul oleneb edasine tellija ja partneri kokkulepetest ning muidugi ka eelarvest ja ajakavast.
Üldpõhimõte on siiski see, et kui mõnda teemat ei ole skoopi määratud, siis on tegemist lisandunud ehk skoobivälise vajadusega.
Skoobijuhtimine on meeskonnatöö – oma vastutust kannavad nii tellija kui partner. Lisavajadustele, ilmnenud probleemidele ja erimeelsustele tuleb otsa vaadata, läbi rääkida ning olukord lahendada.
Kui otsustatakse täita ka lisandunud vajadused, ei saa eeldada, et lõpptähtaeg jääb samaks. Tavaliselt tuleb lisavajaduste täitmiseks lõpp- tähtaega edasi nihutada.
Tellija roll ja vastutus
Disain eeldab tellija aktiivset osalust ja vastutuse võtmist.
Võtmekasutajate osalemine disaini- ja seadistamistöötubades annab neile piisavad teadmised uue lahenduse kohta. Vahel aitab töötoas tähelepanu hoida meeldetuletus, et võtmekasutaja vastutab oma valdkonna seadistuste korrektsuse ja disainis toodud lahenduskäikude kinnitamise eest.
Partnerina teadvustame, et lahenduse ülearendamine on riskantne. Ka seda riski saab vähendada tellija kaasamisega lahenduse loomisel.
Hiljemalt disainimise ajal alustatakse ka andmeülekande plaani koostamist, et saada ülevaade andmetega seotud infost ning anda tellijale võimalus alustada andmete korrastamise ja ette- valmistamisega.
Partneri ülesanne on pakkuda lahendusi ja alternatiive ning anda teavet nende eeliste ja varjukülgede kohta.
Tellijal tuleb otsustada:
- millised protsessid automatiseeritakse ja millised jäävad käsitööks;
- milline mugavus on investeeringut väärt, lähtudes potentsiaalsest töövõidust;
- millised on prioriteedid ning millised lahendused on ärikriitilised ja millised mitte.
Oluline on kõiki asjaosalisi otsustest ja nende tagamaadest informeerida. Probleemid tekivad, kui juhid on kinnitanud 10-tunnise suurt käsitööd tähendava lahenduse, kuid lõppkasutajad ootavad 100-tunnist automatiseeritud imet. Disain ja asjakohane kommu- nikatsioon aitavad ootuseid juhtida ja vaidlusi vähendada.
Olulise osa tellija tööst on dokumentidega tutvumine, partneriga konsensuse leidmine ning dokumentide kinnitamine.
Enne arenduse töösse võtmist peab selle disain olema kinnitatud. Muidu võib juhtuda, et tehakse midagi, mida pole kokku lepitud, ja sellest tekib vaidlusi. Disaini süvenemine ning selle kinnitamine vähendavad oluliselt riski, et tulemus ei vasta soovitule.
Olenevalt kokkuleppest tutvuvad võtmeisikud dokumendiga kas jooksvalt selle koostamise käigus või alles siis, kui kõik on valmis. Igatahes on võimalik anda tagasisidet, küsida täpsustusi ja teha muudatusettepanekuid.
Mõnikord tekib võtmeisikutel dokumendi kinnitamisel ebakindlus. Disaini tehnilistest kirjeldustest pole alati lihtne aru saada, kammitseb ka teadmine, et kinnitamine on siduv. Siis on abiks spetsialistide selgitused ning prototüübi näitlikustamine asjakohaste andmete, demode ja ekraanipiltide abil. Nii saab mõtted paremini liikuma, tuleb väärtuslikku tagasisidet ja tellija on kindlam vastutuse võtmisel.
Partnerina me ei eelda, et tellija mõistab näiteks liidese tehnilise disaini üksikasju. Küll aga peavad tellija võtmeisikud veenduma ja kinnitama, et dokumenti lugedes on selge, mis andmed liidese kaudu liiguvad ning kas, kuidas ja mis tingimustel ärikriitiline info ühest kohast teise liigub. Kas see toimub automaatselt või peab midagi ka käsitsi tegema? Kas on olemas eeldatud ja loodetud sisend vajaliku protsessi jaoks?
Selge ja konkreetne disain koos asjakohase kommunikatsiooniga aitavad vältida olukorda, kus lahendust kasutama hakates hüütakse: „Aga miks see nii on, peaks hoopis teisiti olema!“
