Lisaks hinna kasvule on kõrgel projektiriskil veel tervelt kaks olulist negatiivset omadust. Millised täpselt, sellest kirjutab ITuudistes Riigi Infosüsteemi arhitekt Andres Kütt.
Kõigepealt, mida kõrgemad on projekti riskid, seda suuremaks võib venida vahe tehtud pakkumise ja tegeliku projekti hinna vahel. Risk töötab mõlemas suunas. See aga tekitab, eriti riigi puhul, olulise eetilise probleemi, sest jätkusuutlikult mõtlev pakkuja ei taha ju kliendilt liiga suurt marginaali koorida.
Riski kasvades hakkavad hinnad järjest kiiremini üles minema ning ühel hetkel kaobki mõistlikel ettevõtetel huvi hanke vastu. Oma riskide maandamiseks tuleks teha kõrge hinnaga pakkumine mille võiduvõimalused on väiksed ning pakkumise võitmine toob ilmselt kaasa eetilised probleemid. Tegijatel tööst puudu ei tule ja reeglina valitakse madalama riskiga projekte.
Järelikult, ebaselgetest nõuetest tulenev risk surub pakkujate hulgast välja just need ettevõtteid, keda tegelikult pakkuma soovitakse. Teiseks on oluline aru saada, et riskile antud hinnang on alati subjektiivne.
Madalama riskihinnanguga ettevõte teeb oluliselt madalama pakkumise ning ilmselt ka võidab pakkumise. Kõik on hästi, kui tegu on kogenud inimestega, kes suutsid riske maandada. Aga mis siis, kui tegu oli vale riskihinnanguga? Sel puhul on paremal juhul tulemuseks puuduliku mahuga lahendus ja halvemal juhul terve projekti kõrbemine tellija ja täitja vaheliste konfliktide tõttu.
Mida suurem on projekti reaalne risk, seda rohkem ruumi on seda alahinnata ja seega ka võimalus, et seda tehakse. Ebaselged nõuded aga kasvatavad tõenäosust, et pakkumise võitja on riske valesti hinnanud.
Teise olulise hägusate nõuete probleemi mõistmiseks, mõelgem uuesti minu esimeses postituses toodud näitele aukude kaevamisest (Kummale kutsele saab madalama hinna: kas kutsele ”kaevake mulle krundile sada auku” või kutsele ”vajan sada 50cm korda 50cm korda 100cm-st auku aiapostide tarbeks”?-toim.).
Vaatamata sellele, kuidas pakkumist aukude kaevamiseks küsiti, on üks hetk võimalik välja kuulutada võitja. Aga kuidas me teada saame, et töö on tehtud? Mõni ülbe pakkuja võib lihtsalt sadakond korda labida maasse lüüa ja hiljem, leping peos, raha küsida: ”Tahtsite, auke, palun, siin nad on. Makske nüüd arve ära”.
Reeglina ei huvita meid ju mitte töö, vaid selle tulemus. Ka raha makstakse vähegi mõistliku lepingu puhul välja just nimelt tehtu üle andmise alusel. Kui aga nõuded on ebamäärased, kuidas me teame, et üle antav neile vastab? Nagu juba Irvik-kass ütles: ”Kui sa ei tea, kuhu minna tahad, viivad kõik teed kohale”.
Paraku tuleb arvestada, et kuskil on üks suhteliselt kõrge ülemus, kes oma allkirjaga arvete tasumise kinnitab ning temal on suurte numbritega paberile oma signatuuri panemisel kirjandusklassikast väga vähe kasu.
Siinkohal tõstavad kõik agiilsete arendusmeetodite pooldajad näpu püsti ja ütlevad ”Oota! Aga sa ju ei tea hankesse minnes, mida sa saada tahad?”.
Jah, nii see tõesti on. Reeglina me ei tea tarkvara tellides täpselt, mida see tegema hakkab. Küll aga peab meil eksisteerima väga selge arusaam lahendatavast probleemist. Ilma sügava arusaamata projekti ärilisest tulemist, ei tohi hankesse minna.
Oluline on eristada hangitava sisu ja vormi. Ehk, meie tarkvarahanke kontekstis seda, mida programm teeb sellest, milline see programm välja näeb. Põhjused on sügavad ja olemuselt ärilised. Programmi kasulikkus tuleneb otseselt sellest, mida ta teeb. Tema abil võib raha teenida või kokku hoida, kasvatades nii meie tulusid. Programmi vorm on aga see, mida tuleb hiljem hooldada ja arendada, mis sisaldab turvavigu, mis vajab keerulist riistvara jne. Laias laastus võib öelda, et programmi vorm on see, mis kasvatab meie kulusid.
Kokku tuleb aga kena väike võrratus: hanke summa peab olema väiksem, kui sisu poolt tekitatav tulu, millest on lahutatud vormi poolt tekitatav kulu. Ilma selgete nõueteta vormile, ei saa me kuidagi tagada, et need numbrid positiivsed välja paistaksid.
Kindlasti on veel mitmeid põhjuseid, miks oma nõuete ebaselge väljendamine halb on, kuid olulisem sai siin ehk ära öeldud. Tähelepanelik lugeja kindlasti märkas, et toodud argumendid on esitatud hankija vaatepunktist. Kogemus näitab, et reeglina kaotabki sedalaadi olukordades hankija, mitte pakkuja.
Kõige lihtsamal juhul on raisatud aega ebaõnnestunud hankele, halvemal juhul hangitakse midagi jubedat ja üritatakse seda hiljem ka kasutada.
Autor: Andres Kütt
Seotud lood
Riigi Infosüsteemi arhitekt Andres Kütt jätkab IT-hangete nõuannete jagamist. Täna tuleb juttu sellest, milliseid teadmisi tuleks IT-hangete puhul arvesse võtta.
Olles mitmes artiklis lahanud hangete mõistlike nõuete teemat, annab Riigi Infosüsteemi arhitekt Andres Kütt nüüd ka mõned soovitused nende koostamiseks.
Põhjuseid, miks tasub enne hankesse minekut hangitav põhjalikult läbi lugeda, on palju, kuid on kaks põhjust, millel on oluline mõju nii projekti hinnale kui ka projekti tulemusele.
Kujuta ette, et sinu ettevõte on nagu maja, mis peab vastu vihmale, tormile ja ajahambale. Selle tugevus sõltub vundamendist, kandvatest seintest ja katusest. Kui mõni neist pole paigas, võib maja muutuda ebastabiilseks.