Kuidas koostada head veebihanget? Hanke tingimuste valik

Eelmises blogipostituses rääkisin hindamiskriteeriumite valikust kui ühest levinuimast tüüpveast riigihanke koostamisel. Tegelikult on hankes veel mitmeid tingimusi, millele tuleks sügavamalt tähelepanu pöörata.

Pane mõistlik tähtaeg

Üks hea näide on pakkumuse esitamise tähtaeg. Kui sa paned  tähtajaks 4 tööpäeva (sinna sisse veel pikid nädalavahetuse, no et aeg tunduks pikem), siis tekib paljudel agentuuridel õigustatud kahtlus, et kas see hange mitte juba kellegile ette ära lubatud ei ole. Nad ei osale ka, sest see pole lihtsalt realistlik aeg.

Hea komme on panna tähtajaks vähemalt 2 nädalat. Juhul kui küsid ka testülesannet või on parajasti juuli või detsember, lisa vähemalt nädal juurde, nii saad suurema ringi häid osalejaid.

Väldi raudset kolmnurka

Teine klassikaline probleem on korraga nii eelarve, teostuse tähtaja kui skoobi jäik fikseerimine.
Olukorda, kus hankes on jäigalt fikseeritud eelarve, skoop ja tähtaeg, illustreeritakse tarkvaraarenduses mudeliga “Project management triangle” või “Iron triangle”, mis toob automaatselt kaasa kvaliteedi vähenemise, eelarve lõhkimineku või tähtaegadest ülemineku.

Tänapäeval on klassikalise e Waterfall kolmnurga asendanud Agiilne kolmnurk. Kui klassikaline mudel fikseeris jäigalt skoobi ja hakkas projekti otsast tegema (mille tulemusena reeglina ületati nii eelarvet kui tähtaega), siis agiilne lähenemine fikseerib eelarve ja tähtaja, aga jätab skoobi paindlikuks. See tähendab, et nii projekti alguses kui selle kestel tuleb regulaarselt hinnata funktsionaalsust selle järgi kui palju väärtust see kasutajale loob ja kaua selle tegemine aega võtab. Vähemväärtuslikud ja ajamahukamad featuurid langevad järjest tööde nimekirja lõppu ja lõpuks võidakse otsustada neid üldse mitte teha (sest ROI – Return of Investment – on liiga väike).

Aga nüüd liikusime juba samm kaugemale, projektijuhtimise protsessi ja skoobihalduse juurde. Hankes ma soovitan jätta vähemalt üks neist kolmest komponendist lahtiseks.

Maksimaalne eelarve on tavaliselt avalikus sektoris juba fikseeritud ja see on igati OK. Skoopi ei tasu kirjutada nö kinni ja liiga detailseks, sest keegi ei ole oraakli võimetega ja ei näe kõiki vajadusi ette (sellest rohkem edaspidi). Tähtaeg oleks mõistlik jätta kas lahtiseks või siis mitte suruda peale liiga väikest teostuse aega, a la “projekt peab valmima 3 kuu jooksul”. Kui tellijal on konkreetne ootus veebi lansseerimise aja kohta, siis peaks ta seda hankedokumendis jagama, aga see tuleks markeerida kui oodatud ja mitte kui rangelt nõutud kuupäev.

Arendajate seas on vana irooniline ütlemine, et tellija soovib kõiki projekte saada valmis kas “jõuludeks või jaanipäevaks”. Põhjusel, et eelarve raha tuleb ära kulutada käesoleva aasta sees või soovitakse projekt lõpetada enne suvepuhkuseid. Et mitte samasse mustrisse sattuda, siis planeeri oma tegevusi varakult, prioritiseeri ja mõtle läbi, kas tegelikult ikka juhtub midagi hullu kui projekt lõpeb näiteks veebruaris või oktoobris.

Realistlik eelarve

Nagu öeldud, on avaliku sektori tellijal eelarve tavaliselt fikseeritud ja see on normaalne. Nii on ka erasektoris. Kõik taandub sellele, kui palju funktsionaalsust püütakse selle rahanumbri sisse pressida. Tavaliselt kuhjatakse kokku liiga palju ja kui süveneda, siis on arvestatav osa sellest kas suhteliselt kasutu või sobiks ka palju lihtsam ja soodsam lahendus.

Ütled, et sul on kindlasti kõiki neid featuure vaja ja kohe? Reaalsuses on see tõsi väga harvadel juhtudel. 

Soovitan sul teha järgmise lihtsa prioritiseerimise harjutuse:

1. Reasta planeeritud funktsionaalsuse moodulid tabelisse (tavalise veebi korral tuleb nende arv 10..20 kandis).
2. Lisa iga mooduli rea järele selle prioriteet skaalal 1..5. Prioriteet sinu veebi kasutaja jaoks ja mitte sinu enda jaoks.
3. Sorteeri oma tabel prioriteetide järgi nii, et olulisemad funktsionaalsused on üleval pool.
   Voila! Oledki teinud läbi esimese Product Backlog-i prioritiseerimise. (Siit edasi saab minna juba edasi, ROI ehk saadava väärtuse leidmise juurde, aga jääme praegu miinimumi juurde).
4. Viimaks küsi endalt ja teistelt, kas tabeli allosas asuvaid mooduleid on üldse vaja? On neid kindlasti kohe vaja või ehk oleks võimalik need lisada ka hiljem, arendus- ja hooldusperioodi jooksul?

Kui jääd ise hätta, kaasa IT ekspert, kes aitab sul hinnata, kas planeeritud eelarve ja kirjeldatud skoop on omavahel tasakaalus nii, et hankel osaleks võimalikult palju tugevaid pakkujaid.

Kas teha üks või kaks IT  hanget?

Tahaksin rääkida veel ühest dilemmast, millega tellijad tihti hädas on – nimelt kas teha üks suur hange või kaks eraldi hanget.

Kaks eraldi hanget tähendab kõigepealt ärianalüüsi, visuaalse disaini, UX/UI analüüsi ja prototüübi hankimist, seejärel eraldi tehnilise analüüsi ja teostuse hankimist. Seejuures on esimese hanke tulemid teise hanke sisendmaterjalideks.

Üks hange tähendab kõigi nende etappide hankimist korraga.

Kui sul on kogemusi veebiprojektidega vähem ja majasisest IT tuge ka napib, siis soovitan viia veebi hankimine läbi kahe eraldi hankega. Nii võib minna küll rohkem aega, sest hanke läbiviimine võtab oma aja, aga kokkuvõttes saad parema tulemuse.

Miks? Siin on mitu põhjust, aga et teha lühidalt, siis neist kõige olulisem on järgmine.

Ärivajaduste kaardistamisel ja kasutajaliidese loomisel kerkib esile mitmeid uusi vajadusi, mille peale pole keegi varem tulnud. Või siis ilmneb karm tõde osade soovide mõttetuse kohta. Juhul kui midagi uut ei ilmne, siis on analüüsi tegija otsesõnu vilets 😉

Kui analüüs läbitud, on Sul nüüd võimalus kohendada oma planeeritud skoopi vastavalt esimese hanke tulemustele ja anda teise tehnilise hanke jaoks kvaliteetne sisend. Ja mida kvaliteetsem sisend, seda paremini sinu projekt õnnestub!

Järgmises loos räägin lähemalt tehnilise lähteülesande kirjutamisest – mida, miks ja kui palju.