IT-projekti ohjab üheselt mõistetav kokkulepe

IT-projektide ebaõnnestumiste oskusteave maailmas on märkimisväärne, spetsialistidele on tüüpilised ebaõnne põhjused enamikus teada ja nendega arvestatakse. Alljärgnevalt vaatlen IT problemaatika objektiivseid asjaolusid seni vähe käsitletud vaatenurgast ning kirjeldan abinõusid, mis on end praktikas konflikti vältimisel tõestanud. Käsitlen tänapäevast ehk internetipõhist IT-projekti vormi ning lähtun eeldusest, et selle osapooled on professionaalid, kes rakendavad projekti õnnestumiseks oma parimad arusaamad ja oskused.

Tänapäevases IT-projektis on esindatud järgmised valdkonnad: äri (suvaline organisatsioon, kes ei tee kõike ise), tehnoloogia (tavaliselt süsteemiarendusega tegelev ettevõte) ja looming.

Potentsiaalsete konfliktide algpõhjus peitub selles, et partneritena peavad toimima sisuliselt niivõrd erinevad valdkonnad, et nende koostöös tekivad nn objektiivsed konfliktid. Oluline on mõista, et konflikti põhjused ei peitu isikute erialaste oskuste vähesuses või hea tahte puudumises.

Visiooni tasandil on pilt ilus: projektis osalevad oma ala professionaalid, keda kõiki ühendab hea tahe projekt edukalt läbi viia. Äri kirjeldab partneritele ärivajadust, tehnoloogia pakub sellele sobiva lahenduse ja looming annab uutele rakendustele väljanägemise. Osapooled sõlmivad omavahel projekti läbiviimiseks kokkuleppeid. Need sõlmitakse visiooni tasandil, konkreetsust on neis üldjuhul vähe.

Paraku lähtuvad osapooled kokkuleppe sõlmimisel erinevatest eeldustest ning just neid eeldusi ei ole tavaliselt kusagil kirjas. Kuna kokkuleppeid tõlgendatakse eeldustest lähtuvalt, on eelduste erinedes ka kokkuleppe tähendus iga osapoole jaoks erinev ja kokkulepe seega mittekehtiv.

Tuleb tähele panna, et:

- iga osapool on sõlminud kokkuleppe oma parimate oskuste ja teadmiste kohaselt;- eelduste erinedes mõistavad osapooled näiliselt üht ja sama kokkulepet erinevalt;- see, et osapoolte tõlgendused erinevad, on loomulik;- konfliktid tulenevad mittekehtivate kokkulepete sõlmimisest.

Kui osapoolte vahel sõlmitud kokkuleppeid hakatakse täitma, hakkavad ilmnema ka valdkondadevahelised konfliktid.

Äri ja tehnoloogia sõlmivad omavahel kokkuleppe: äri kirjeldab, mida ta tahab, partner kinnitab, et suudab selle realiseerida. Paraku on nende sõnade taga erinevad, valdkondade erinevusest tulenevad eeldused, mistõttu partnerid tõlgendavad ka kokkulepet erinevalt. Erinevad eeldused: äri lähtub äriprotsessidest, pidades neid kõige olulisemaks. See on ju kõigile mõistetav ja loomulik. Tehnoloogiapartner lähtub tehnoloogiast, sest ta tunneb seda kõige paremini (ja selle pärast talle makstaksegi).

Üks drastiline näide illustratsiooniks. Äri ütleb, et soovib olemasoleva rakenduse võtta uues süsteemis kasutusele praegusel kujul. Äri lähtub seisukohast, et olemasoleva rakenduse funktsioonid on sobivad äriprotsessidega. Äri teeb kokkuleppe oma valdkonna tundmisele tuginedes, ta kõneleb n-ö äri keeles. Tehnoloogiapartner mõistab äri soovi tehnoloogia keeles: alles jäetakse tehnoloogia, st olemasolev rakendus jääb füüsiliselt alles ning see integreeritakse uude süsteemi. Sõlmitakse kokkulepe, et olemasolev rakendus võetakse kasutusele uues IT-süsteemis selle praegusel kujul. Pooled on näiliselt ühes ja samas asjas kokku leppinud. Probleem avaldub alles siis, kui hakatakse töid üle andma. Tulemuseks on Eesti ärimaastikul nii tavaline lehmakauplemine eelarve ja tähtaja üle.

Visiooni tasandil on pilt ilus ka siin. Äri annab disainerile lähteülesandeks luua soovitud liidestele visuaal. Sõlmitakse kokkulepe (paraku abstraktse) töö teostamiseks. Kui hakatakse reaalset tööd tegema, kerkib üles küsimus: mis see täpselt on, mida peab disainima? Äril reeglina puudub füüsiliselt mõõdetav lähteülesanne, mida disainer võiks pikselitesse valada. Visiitkaart, veebileht, reklaam, välimeedia ? need on abstraktsioonid, mille kohta on meil kõigil olemas füüsiline ettekujutus. Kohe aga, kui kasutusele tulevad terminid interaktsioon või funktsioon, on lähteülesande kirjeldamisega jännis nii looming kui ka äri. Siin on tulemuseks subjektiivne kompromiss ? kahe poole vahel lepitakse kokku mõlemaid pooli personaalselt rahuldav variant.

Loomingu ja äri konflikt ei ole nii fundamentaalne, sellest saadakse tavaliselt suhteliselt kergesti üle just tänu subjektiivsele otsustamisele. Paraku peitub just selles kompromissis ühe teise, tõsiselt fataalse konflikti peapõhjus.

Selleks peapõhjuseks on konflikt loomingu ja tehnoloogia vahel. Äri sõlmib tavaliselt kokkuleppe tehnoloogia ja loominguga eraldi. Looming ja tehnoloogia ei sõlmi omavahel üldse mingeid kokkuleppeid või siis sõlmivad neid ülima pealiskaudsusega. Kui disaini hakatakse tehnoloogilise lahendusega liitma, ilmnevad üllatused. Näiteid nendest leiab ülalolevast loetelust.

Sellised avastused on loomulikud, sest disainer ei tunne tehnoloogiat ning tegelikult ei peagi tundma. Ka on vale eeldada, et tehnoloogia mõistab, kuidas looming lähteülesandest aru saab. Tehnoloogia ja loomingu vahelises konfliktsituatsioonis saab kõige rohkem kannatada äri, sest tema varasemaid otsuseid lükatakse ümber mõlemalt poolt. Kehvemal juhul läheb osapoolte vahel üksteise süüdistamiseks ja kaob partnerlussuhe.

Osapooled unustavad ära, et nad tegutsevad ühise eesmärgi saavutamise nimel. Selles situatsioonis normaalse suhte taastamine on väga keeruline ülesanne.

Vahekokkuvõtteks tundub, et eelnevaga maalitud pilt on suhteliselt lootusetu ? kõik probleemid on loomulikud, objektiivsed ja möödapääsmatud. Tekib küsimus, kuidas siis edasi? Nagu muudegi probleemide puhuks, on siingi olemas oma metoodikad.

Paljud ehk mäletavad lapsepõlvest kaarditrikki, kus näidatakse vastasmängijale ühte kaarti, palutakse tal see meelde jätta ja pannakse kaart pakki tagasi. Seejärel laotakse kaarte ja esitatakse küsimusi, millele saab vastata jah või ei. Kaarditriki lõpuks jääb järele üks kaart, mis ongi see, mida hanekstõmmatu alguses nägi.

Triki iva on imelihtne: kuigi te ei tea oma partneri eesmärki, kasutate te valikvastustega küsimusi, millele saab anda ainult tõeväärtusega vastuseid. Küsimuste ja vastuste ühese interpreteerimisega jõuate teatud arvu küsimuste esitamise järel ainsa eesmärgini, mida kaasmängija tulemuselt ootas.

Eespool kirjeldatud konfliktide vältimiseks on olemas metoodikad, mille eesmärgiks on tagada osapoolte vahel sõlmitavate kokkulepete üheseltmõistetavus. Siinjuures pole tähtis, et üks osapool teaks teisest osapoolest kõike. Ei ole tähtis, et äri tunneks tehnoloogiat, metoodika tagab selle, et kokkulepe peab vett. Selleks vajalikud metoodikad ei ole midagi eraldiseisvat.

- Kokkulepete sõlmimise metoodika on tegelikult nõuete haldus. Selle metoodika tulemuseks on eelduste võimalikult laiaulatuslik sünkroniseerimine ja riskide maandamine.

- Tegevuste organiseerituse modelleerimine tuleneb otseselt süsteemianalüüsist, täpsemalt kasutusjuhtumite mudelist.

- Kasutajaliidese prototüüpimine käsitleb ühe osana tehnoloogilistest piirangutest tulenevaid nõudeid.

Peale süsteemianalüüsi annab hea efekti kontekstiline analüüs, mille käigus uuritakse inimesi, kes peavad loodavat tehnoloogiaalast lahendust reaalselt kasutama. Analüüsitakse äriprotsesse ja keskkonda, kus süsteemi kasutatakse (näiteks on ju suur vahe, kas uudset lahendust hakatakse kasutama kabinetivaikuses või suures teenindussaalis, kus kuvari taga seisab närviline järjekord). Kontekstilise analüüsi eesmärgiks on ärivajaduste kasutajaliidese tasemele viimine.

IT-projekti organisatsiooni võiks mahtuda veel neljas osapool näiteks nimetusega vankrijuht, kes hoiab luike, vähki ja haugi samal rajal ning seda hoolimata nende erinevas suunas sikutamisest. Tegelikult saab selle rolli enda peale võtta ka loomingu või tehnoloogia osapool.

Autor: Mihkel Lauk