Selgepiirilistest nõuetest

Andres Kütt RIA / Riigi Infosüsteemi Arhitekt !20.05.14

Täna kavas

" Enne hanget " Kuidas pakkuja mõtleb " Hägusate nõuete tagajärjed

" Nõuete kirjutamisest hankesse " Ports konkreetseid soovitusi

Pakkumise kirjutaja teeb korraga kolme asja: !" Maksimiseerib käivet " Minimiseerib riske " Juhib oma aega

Kuidas pakkuja mõtleb?

• Käive on funktsioon ajast: pakkuja maksimeerib käivet kogu nähtava koostöö peale. Järelikult on hankija huvides võimalikult pikk koostööperiood mis siiski ei tekita fataalset lock-in’i

• Maksimeeritakse just nimelt käivet, mitte kasumit. Kasumit hakatakse maksimeerima hiljem vahetades tiimi liikmeid odavamate vastu ja tehes nii vähe, kui võimalik

• Pakkuja on reeglina ajalise surve all. Iga tema tööminut maksab • Iga projektiga käivad kaasas riskid. Ei ole mõtet võita pakkumist ja selle eest pikas perspektiivis peale maksta. Järelikult peab pakkuja adekvaatselt

hindama projekti riske

0 20 40 60 80 100

0.0

0.1

0.2

0.3

0.4

TuluTõenäosus

Joonisel on kahe erineva riskihinnanguga pakkumise graafikud. Mõlema puhul on tõenäosus miinusesse jääda sama, kuid ühe puhul on hajuvus (st. risk või ebamäärasus) oluliselt suurem. Kui hinnang riskidele ning seega ka potentsiaalsele tulu hajuvusele on suurem, on suurem ka küsitav hind - vastasel juhul tuleks võtta oluliselt suurem risk miinusesse jääda.

" Kõrgemat hinda " Kompetentsete pakkujate kõrvalejäämist " Riskide valesti hindamist võitja poolt

Hägusad nõuded tähendavad järelikult

Kogu riskianalüüs on loomulikult tõenäosuslik kuid need kolm järeldust kehtivad rõhuval enamikul juhtudest • Mida suuremad on riskipuhvrid, seda suurem tuleb hind. Isegi, kui puhvrid ei realiseeru, on hinnas juba kokku lepitud ja mida tagasi saada reeglina ei

õnnestu • Mingist piirist alates loobuvad kompetentsed pakkujad riske hindamast. Ühest küljest on neil definitsiooni järgi palju (vähemriskantset) tööd ja teisalt

suureneb tõenäosus hinna osas alla jääda • Mida suurem on risk, seda suurem on tõenäosus, et riske alahinnates tehakse odav pakkumine. Seega suureneb ka tõenäosus, et võidetakse just nimelt

riske alahinnates

Hägusatest nõuetest kaotab reeglina hankija !

Vähemalt kulutab ta aega ja vahendeid nurjunud projektile

Järelikult…

Kuna tarnijal on tavaliselt oma kuludest selge ülevaade, saab ta aegsasti projektist väljuda, kui projekt kahjumile läheneb. Hankijal ei ole projektist kuhugi minna ning kulude sisse nõudmine kohtu kaudu on hirmus ajamahukas.

Kõik algab ja lõpeb äriprotsessiga

Ilma äriprotsessi mõistmata ei ole võimalik kirjutada mõistlikku hankedokumenti. Äriprotsess (või selle puudumine) on kõigi tarkvaraprotsesside kriitiline edutegur. Et riigis reeglina äriprotsessist ei räägita, seda asjaolu ei muuda.

Ei tohi minna hankesse teadmata, mida saada tahetakse

Kõlab triviaalselt, eks. Aga ometi läheb rõhuv enamus tarkvaraprojekte vasakule just sel põhjusel.

" Miski, mille olulisuest pealik eile ajakirjast luges " Kolme erineva inimese vastuolulised

veendumused " Soov “nagu xxx.gov.uk aga vähema tiluliluga” " Määrus/seadus vms. juriidiline dokument !

“Teadmine” ei ole

• Teadmine ei pea olema hankija peas, teadmine peab olema ühel või teisel viisil projektile (ja seega ka hankeprotsessile) kättesaadav • Ülemuse peas olevast suuremal või vähemal määral selgest visioonist ei ole kasu, kui seda ei õnnestu konkreetseteks nõueteks tõlkida. Tavaliselt on

probleemiks juhi aja defitsiit kuid väga tihti ka tavaline võimust tingitud arrogants. • Kui organisatsioonis on rida inimesi, kel kõigil on oma selge arusaam ärirptosessist kuid kellede arusaamad ei kattu (näiteks müügil ja tootmisel on

finantsaruandlusest tavaliselt risti vasutkäivad arusaamad), ei teata tegelikult, mida tahetakse. Puudu on otsus, mida ei saa keegi kolmas organisatsiooni eest teha.

• xxx.gov.uk on konkreetne näide. Hämmastaval kombel on siiamaani elus “stiilsete www-eriefektide” mõtteviis mis vabastab selle väljendaja igasugusest vastutusest midagi kuidagi kirjeldada. Reeglina on sedalaadi väited hankes suureks punaseks laternaks mille peale vähegi mõistlik pakkuja eemale astub

• Juriidiline dokument ei kirjelda äriprotsessi vaid seab sellele teatavad nõuded. Puhtalt juriidikale toetudes ei ole võimalik tarkvara hankida.

" Hajus protsessikompetents organisatsioonis " Otsustusvõimekus ja -pädevus suuna õigsuse

kontrolliks " Toimiv mehhanism teadmise tekitamiseks

“Teadmine” on, muu hulgas,

Loomulikult on kõige praktilisem ja selgem teadmise vorm kompaktse grupi inimeste võimekus äriprotsessist omavahel oluliselt kaklemata pikalt ja põhjalikult rääkida. Siiski on teadmisel ka teised vormid: • Hajus. Keeruliste protsesside korral ei ole ei ühel inimesel ega väikesel grupil täit ülevaadet terviklikust protsessist. Küll aga võib eksisteerida rida inimesi,

kelle peades on arusaam konkreetsetest sammudest. Tüüpiliselt näiteks on letitöötajate vahetud juhid, kelle teadmisi reeglina ei ole kellelgi peakontoris. • “ma ei tea, mida ma tahan aga ma tunnen selle ära, kui seda näen”. Agiilsed arendusmeetodid tuginevad just sedalaadi teadmisele. Ehk, kuskil on

inimene, kes suudab otsustada, kas miski samm viib soovitud tulemusele lähemale või mitte. Oluline on ka otsustuspädevus. • Vahel ei olegi teadmist äriprotsessist võimalik ilmutatud kujul omada, seda eriti uudsete ning lõpptarbijale suunatud lahenduste puhul. Küll aga on

võimalik omada mõõdikuid lahenduse edu hindamiseks, läbi proovitud mehhanisme tarbija reaktsiooni mõõtmiseks jne. !Mõlemad variandid on mõistlik hankedokumentatsioonis spetsiifiliselt välja tuua, vastasel juhul võidakse hakata tegema eeldusi. Samuti on sobilik lähenemine mõlemal juhul erinev standardsest küsitlen-kolme-inimest-ja-joonistan-pildi lähenemisest.

Mõtlemist ei saa sisse osta

On kummastav, kui tihti seda siiski üritatakse. Nii era- kui avalikus sektoris. Keegi ei saa teie eest otsustada, kuidas maksu koguda, riigi ITd koordineerida või pensione välja maksta.

" Mõtete üles kirjutamist ja konsolideerimist " Mõtete formaliseerimist " Mõtete analüüsi ja kriitikat

Sisse saab osta

Need tegevused aetakse tihti mõtlemisega segi. Samas, kui puudub teadmine äriprotsessist, on (äri)analüüsi tulemus paremal juhul läbikukkumine. Halvemal juhul produtseeritakse paber, millel puudub reaalsete vajadustega igasugune seos, kuid millele tuginedes on siiski võimalik asuda programmeerima. Loomulikult ei ole selliselt punutud tarkvara kellelegi kasulik.

Kõige parem märk teadmise puudumisest: !

võimetus kirjutada mõistlikku hankedokumenti

Enese rumaluse tunnistamine on inimesele peaaegu kõige raskem asi. Mida ägedam juht, seda raskem. Samuti on keeruline hinnata kollektiivset rumalust: “mina ei tea, aga eks vanemad kolleegid ikka teavad”. !Elu näitab, et kõige parem märk teadmise puudumisest on raskused mõistliku hankedokumendi kirjutamisel. Kui ikkagi ei suudeta loetleda konkreetseid tulemeid ning nende vastuvõtukriteeriume, on suure tõenäosusega asi äriprotsessi teadmise puudumises. Kui hankedokumendi kirjutamine jääb venima on mõislik hange seisma panna ning uurida, milles ikkagi asi.

Konkreetsed soovitused nõuete kirjutamiseks

Järnevas mõned konkreetsed soovitused, mis paraku enamasti tuginevad päriselulistele näidetele. Kui te oma kirjutatu ära tunnete, siis on põhjust häbeneda.

Sest need ei anna pakkumiseks kasulikku infot. Ja reeglina ei suudeta mõistlikke prioriteete määrata.

!

!

!

Ära räägi prioriteetidest

Kui pakkumisest ei selgu, milline on prioriteetide mõju (näiteks: “faasis üks realiseeritakse tulemid prioriteetidega 1-3”) projektile, ei ole neid mõtet loetleda. Kuna pakkujal nendega midagi teha pole, on tegu müraga. !Halvemal juhul kommunikeeritakse prioriteetidega (skaalal 1-5 80% - P1, 15% - P2, 5% - P3), et tegelikult ei suudeta prioretiseerida. Järgmine suur punane latern mille peale head pakkujad eemale kõndida võivad.

Kui millegi tegemata jätmine ei mõjuta välja makstavaid summasid, seda ei tehta.

!

Kui miskit on vaja teha, siis on seda vaja, kui seda ei ole vaja teha, ei ole mõistlik sellele aega kulutada.

Ära räägi “soovitavatest” asjadest

Tarnija soovib teha nii vähe, kui võimalik. Järelikult visatakse projekti skoobist esimesel võimalusel välja, kõik mis võimalik. Teisalt on projekti skoobil kalduvus kasvada. Seega on hankedokumendis “soovitavate” asjade välja toomine vaid ebamäärasust suurendava mõjuga: pakkuja ei tea, kas tegemist on hankekomisioni esimehe lemmikteemadega, millele rõhumine annab punkte juurde, miskil koosolekul saavutatud kompromissiga kümne inimese vahel või mõne väikese ametniku tagasihoidliku sooviga.

Arendushind on ühekordne tulemi üle andmisel makstav tasu. Mõõdetakse eurodes.

!

Operatiivhind on regulaarne teenuse kvaliteedist sõltuv tasu. Mõõdetakse eurodes ajaühikus.

Operatiivne hind eraldi arendushinnast

Perioodilise ja ühekordse hinna sujuv kombineerimine on järjekordne punane latern. Tegu on kahe fundamentaalselt erineva hanke liigiga, mida isegi ühte hankesse, rääkimata ühest numbrist, on keeruline mahutada. !Esimesel juhul on tarne vastu võtmine ühekordne tegevus ning väljamakse sõltub tarne omadustest (aeg, kvaliteet, ulatus jne.). Teisel juhul on tegu igakuiste väljamaksetega, mis võivad (aga ei pruugi) olla sõltuvuses osutatud teenuse kvaliteedist.

100 tundi tööd 10.- tunnihinnaga inimese poolt on oluliselt erinev 10 tunnist tööst 100.- tunnihinnaga inimese poolt

!

Hea võimalus tiim kontrolli alla ning pakkumised võrreldavaks saada

Tunnid rollide lõikes, mitte lump sum

Ehk, pakkumises tuuakse välja rollid koos tunnihindadega (soovitavalt ka inimeste CVd, kes rolle täidavad) ning iga tarne kohta loetletakse: 1. Mis rollid tööd teevad 2. Kui mitme tunni ulatuses 3. Mis summas (mugavuse mõttes) !Selliselt vormistatud pakkumisel on järgmised head omadused: 1. Pakkumised on võrreldavad, alapakkumist on lihtsam ära tunda 2. Hilisem muudatuste juhtimine ja lisatööde tellimine muutub läbipaistvaks, kuna tunnihinnad on kokku lepitud 3. Saab kehtestada eraldi piirangud sellele, kuidas ja millal mingite rollide täitjaid vahetada saab

Alati hangitakse tulemust, mitte tööd

Hämmastavalt tihti hangitakse mingeid arusaamatuid “töid”. Viimati tegeles riik minu teada hädaabitöödega eelmise sajandi algupoolel. Sealt alates on raha kulutamise eesmärgiks ikka olnud tulemi saamine, mitte inimestele töö pakkumine ning ei ole tõenäoline, et Eesti IT-sektor hetkel toetamist vajaks.

" Mis täpselt üle antakse " Kuidas me teame, et see miski on kokku lepitud

(NB! Mitte soovitavas!) kvaliteedis " Kes võtab vastutuse vastu võtmise eest " Mil viisil sõltub rahade liikumine tarne

kvaliteedist

Seega tuleb fikseerida

Kuna hangitakse tulemust ja mitte tööd on hanke keskseks mõisteks “tarne”. Miski antakse täitjalt tellijale üle. • Tuleb loetleda kõik, mis üle antakse. Sealhulgas dokumendid, koolitused, koodiread jne. jne. Kuna tarnija minimiseerib oma kulusid, siis kehtib põhimõte:

mida ei ole üle antavate asjade nimekirjas, seda ei tehta • On oluline (sisemiselt) kokku leppida, kuidas toimub tarnete vastu võtmine. Selle kokkuleppe võib läbipaistvuse huvides ka hankedokumendis teatavaks

teha. Seejuures on oluline anda hankijale kindlus (ebamäärasuse vähendamine!), et hinnang kvaliteedile on pigem objektiivne kui subjektiivne. • Kui puudub inimene, kes konkreetselt vastutab hanke kvaliteedi kontrolli eest, siis hangete kvaliteeti ei kontrollita. Peadirektor, kes arve viseerib, peab

saama toetuda kellegi hinnangule • Tarnetest on mõtet rääkida vaid siis, kui sellel on mõju rahade liikumisele. Kui hankes/lepingus sätestatu ei võimalda tarnet tagasi lükata, osaliselt vastu

võtta vms., ei ole tarnete kirjeldamisel mõtet. Tarnija annab alati üle vähima, mille eest veel raha saab.

Ei tohi eeldada mingeid eelteadmisi hangitavast objektist

!

On kasulik hanke läbipaistvusele !

Ka su kolleegid või järeltulijad võivad olla pärit sealtsamast!

Pakkuja on Montevideost

Alati tuleb eeldada, et pakkumise koostaja on sama päeva hommikul astunud maha lennukilt, mis tuleb Montevideost ning ei tea mitte midagi ei konkreetsest süsteemist ega üldse Eesti riigist. !Põhjus (lisaks sellele, et tänapäeval võibki pakkuja olla pärit Uruguaist), on pakkujate ühetaoline kohtlemine ning eelduste (seega ebamäärasuse!) vähendamine. Kui kaks pakkujat eeldab, et kasutatakse nende koodihoidlat ja kaks, et hankija oma, ei pruugi pakkumised olla võrreldavad. !Oluline on ka meeles pidada, et hankes tegelikult dokumenteeritakse projekti ning et tarne vastu võtmisel on aluseks hankedokument. Ebamäärane hankedokument eeldab, et tarne vastu võtja omab hankedokumendi kirjutajaga sama taustainfot. See aga ei pruugi sugugi tõele vastata.

Rusikareegel: kui tükk infot võib pakkumise tegemiseks kasulik olla, lisa see hankele

!

Taustainfoga koonerdamine süvendab lock-in’i ning läheb mingist piirist alates paragrahvi alla

!

Kui infot pole, tuleb nii öeldagi

Anna kogu olemasolev taustainfo

Tänapäeval on üliharuldased juhtumid, kus on võimalik ehitada nullist täiesti uus, ühegi liideseta, infosüsteem. Reeglina peab uus asi elama vanade asjadega koos või nende funktsioone üle võtma või nendega infot vahetama, sobituma protsessidesse jne. jne. Kõike seda on pakkumise tegemisel oluline teada. !Rusikareegel: “Kui miski võib olla pakkumise tegemisel kasulik siis pane see sisse. Kui miski ei mõjuta ei otsust võitja osas ega pakkumist, jäta see välja.” !Kehtib oluline seaduspärasus: kui hankes eeldatakse pakkujalt eelteadmist süsteemsit, saavad hankes osaleda vaid eelteadmisega pakkujad mistõttu hanke võitja teadmised süsteemist aina süvenevad mistõttu muutub järjest raskemaks hankimine kelleltki teiselt mistõttu on mõistlikum tellida samalt ettevõttelt mistõttu on kasulik eeldada eelteadmisi. Ehk, nii tekivadki puukidest partnerid. !Oluline on teha vahet info puudumise ja selle mitte jagamise vahel. Kui näiteks hankega ei ole kaasas mittefunktsionaalseid nõudeid, siis peab pakkuja nende eksisteerimise kohta tegema oletusi (ebamäärasus!) ning ei ole tingimata selge, millise eelduse milline pakkuja tegi. Kui aga pakkumiskutses on kirjas “mittefunktsionaalsed nõuded puuduvad” on pakkujatel vabad käed ning eeldusi tegema ei pea.

Milline on tugi ning ressursid, mida hankija pakub?

!

Serverid? Nõupidamisteruumid? Küpsised? Koolitus? Kollaboratsioonikeskkond?

Mida sa pakkujale pakud

Igasugune tarkvaraarendus on koostöö ning iga koostöö aluseks on selge arusaam osapoolte poolt laua äärde toodavast. Jällegi on oluline märksõna ebamäärasus. Hea näide on kõikvõimalik keskkondadega seotu: kas tarnijalt eeldatakse oma testkeskkonna jooksutamist või on see hankija poolt? Samuti on tüüpiliseks arusaamatuse allikaks kontoripindade ning arvutivõrguga seonduv ning reisikulud.

Aitäh!

Andres Kütt andres.kutt@ria.ee