Eile toimusid riigikogu valimised, millest mulle jäi kõige rohkem meelde Aarne Rannamäe kümnessetabav kirjeldus olukorrale - "Eesti IT tiiger on tardunud topiseks", et otsustasin selle lause tagamaid veidi enda vaatevinklist lahata. Olles ise viimased 6 aastat rääkinud kõigile oma klientidele, et testimine ei ole luksuskaup vaid hädavajalik, et mitte hiljem piinlikust tunda ja suuri summasid PR kampaaniate või kohtuvaidluste peale kulutada, siis eile õhtune fiasko valimiste infosüsteemiga ning sellest järgmisel päeval tekkinud PR kampaaniad meedias tekitasid minus "äratundmisrõõmu". Olen sellises olukorras juba mitmeid kordi olnud - projekti alguses olen eksootiline nabatantsija või hullumeelne, keda on lihtsalt lõbus projekti alguses meelelahutuseks vaadata, mida vürtsidab väga suur "ega meiega see ei juhtu" enesekindel suhtumine, sest "meil on väga tugev arenduspartner ja meil kõigil on siit projektist võita". Paraku näitab minu viimase 6 aasta kogemus, et ikka juhtub küll ja alati kõige ebasobivamal ajal, millele minu poolt järgneb "ma ju rääkisin sulle" tagantjärele tarkus. Mitte, et ma oleksin VVK juures oma nabatantsu numbrit teinud, kuid räägin oma enda kogemustest mõndade klientide juurest ja olen üsna veendunud, et ka selles projektis valitses selline ülioptimism ja enesekindlus. Olen aru saanud, et testimist, kui teenust ei ole võimalik ette müüa vaid ikka tagantjärele. Ma ise nimetan seda müügiprotsessi "ämbrimüügiks". Näeb see välja järgmine: kohtun kliendiga, kes pole väga IT võimekas - teisisõnu äriettevõtte, kes on alustamas uut IT projekti. Räägin talle, mida ta peaks tegema oma riskide maandamiseks, mis tegevusi on vaja teha ja palju tellija ressurssi kulub ühe tarkvara projekti peale - keskeltläbi 60% mahust on tellija tegevusi ja 40% arendaja tegevusi. Lisan siia veel kirjelduse, mida oodata ühest tarkvaraprojektist ning jään siis ootama reaktsiooni. Teisisõnu kirjeldan arenduse tellijale võimalikult palju ämbreid, millesse ta võib astuda, kui ta sellele ja sellele tähelepanu ei pööra. Reeglina mind kuulatakse ära, surutakse kätt ja öeldakse, et kõik on kontrolli all ja meiega sellised asjad ei juhtu. Möödub umbes 6 kuud. Järgneb meediateade, kus öeldakse, et süsteemi valmimine viibib või on tekkinud "tehnilised probleemid" - ühesõnaga enamus projekti eel kirjeldatud ämbreid on juhtunud. Edaspidi suhtutakse minu juttu selle kliendi juures tõsisemalt. Ämbrimüük tehtud :)
Hiljuti ilmus Maili artikkel Novaatoris, mida refereeris omakorda Delfi (http://www.novaator.ee/ET/it/moista_moista_mis_see_on_nahtamatu_kui_tehtud_nahtav_kui_tegemata/) (ja on varem avaldatud ka siin blogis), mis rääkis testimisest, kui hindamatust infoallikast tarkvaras leiduvast või siis ka puuduvast kvaliteedist. See sai suhteliselt hävitava hinnangu kommentaatorite poolt, kes arvasid, et kõike testida pole võimalik ja testimine ei garanteeri süsteemi toimimist. Kõik ilus ja kena ning olen 100% selle argumendiga nõus. Kvaliteeti ei ole võimalik süsteemi sisse testida vaid testimine annab infot, kas selles süsteemis on minged kvalitatiivseid omadusi olemas või on tegemist järjekordse ämbriga. Kvaliteet tekib ikka tarkvara väliselt rakendades teadlikku ja metoodilist lähenemist ning maksimaalselt edutoonud protseduuride kordamist järgnevates projektides. Selleks on loodud väga palju arenduse etalonmudeleid, mida võiks ka meie arendajad tõsisemalt järgida koos arenduse tellijatega. Seniks kestab paraku nn "kauboikapitalism". Viimane on siis suhtumine tarkvara, kui ärilahenduse arendamisse, millega tarkvara tellija peaks saama oma äri edendada ja paremaks muuta. Mõiste ÄRI ei tähenda siinkohal alati rahateenimist vaid mingi organisatsiooni eksisteerimise mõtet. Avalik sektor ei ole rahateenimise eesmärgil loodud, kuid ÄRI käib seal samamoodi nagu näiteks pangas.
Aga kuidas siis testimisega saada äriliselt olulist infot? Keskendub ju testimine vigade otsimisele? Ühelt poolt jah, on arendustestimine, mille fookus on funktsionaalne korrektsus ja teiselt poolt on äritestimine, mille fookuses on süsteemi rakendumine. Mõlemad testimised on ülimalt olulised ja annavad erineval tasemel infot - üks projektiriskidele ja teine äririskidele. Riskipõhine testimine jäetakse tihtipeale ära, loodetakse, et äririskid ei realiseeru või ei tehta seda piisava põhjalikkusega. Tuleb selget vahet teha projektiriskidel ja äririskidel. Projektiriskid ilmnevad arenduse käigus - arendajad on üle koormatud, eelarve liiga väike, inimesed haigestuvad, tellija ei ole piisavalt kättesaadav, palju vigu jne. Äririskid on need, millele arendaja ei mõtle ja ei peagi mõtlema. Seda peab tegema äripool e tarkvara tellija - süsteem ei täida oma eesmärki, lõppkasutajad ei võta süsteemi kasutusele, jõudluse- koormuse ja robustsuse probleemid jne.
Kuidas siis riskipõhiselt testida ja kuidas teha "riskitestimise plaan"? Millele tähelepanu pöörata? Riskide kaardistamiseks ja juhtimiseks on palju erinevaid meetodeid. Täpsemalt võib igaüks uurida ISO 31010 standardit, kuid kiirelt oluliste riskide hindamiseks sobib selline lähenemine:
Esiteks, loo äririskide maatriks ja lisa sinna 6 mõõdet: risk, esinemise tõenäosus (madal = 0,1, keskmine = 0,5, kõrge = 1), riski mõju ärile (väike = 0,1, keskmine = 0,5, suur = 1), maandamisvõimalused, maandamise kulu, maandamata jätmise kulu (tekkiv kahju). Ürita täita veerud nii hästi kui oskad. Kui sa ei oska midagi hinnata, siis ole pigem pessimist, kui optimist ja hinda väärtust suuremaks, kui madalamaks. Otsuse tegemiseks, tee järgmine tehe:
riski tõenäosus * mõju * maandamata jätmise kulu.
Kui see number tuleb suurem, kui maandamise kulu, on mõistlik see risk pigem maandada, kui maandamata jätta.
Näiteks, ettevõte e-müügikeskkond, 1MEUR käibega:
Risk:
Teenus ei suuda piisavalt palju päringuid teenindada ja süsteem kukub kokku
Tõenäosus:
Keskmine
Mõju:
Suur, sest tulemuseks on mainekahju, klientide rahulolematus, võimalikud kohtuprotsessid ja hilisemad PR kulud
Maandamisvõimalused:
Tuleb läbi viia koormus- jõudlus- ja robustsustestid
Maandamise maksumus:
12 782 EUR
Maandamata jätmise maksumus
PR kulud 1000 EUR
Kohtukulud klientidele kahju tekitamises (partnerid ei saanud tellida kaupa ja äri seisis) 10 000 EUR
Klientide kaotus 100 000 EUR (10%)
äri peatumine vigade likvideerimise ajaks 83 000 EUR (1 kuu käive)
Testida või mitte?
0,5*1*194 000 = 97 000 EUR
Kas potentsiaalne 97 KEURi kahju kaalub üles 12 KEUR säästmise? Siia pole lisatud partnerite omavaheliste suhete keeruliseks muutumisest tingitud kulu, sest tõenäoliselt sama partneriga enam ei jätkata, ning uus partner peab eelmise partneri loodud tarkvara üle võtma, et seda edasi arendada.
Tulles tagasi valmiste ja valimiste infosüsteemi juurde, siis millised on selle süsteemi potentsiaalsed ärikahjud? Raha ju sellega ei teenita, kuid valimiste institutsiooni usaldusväärsus ja arendaja usaldusväärsus said maksumaksja raha eest päris oluliselt kannatada. Ma ei ole täielikult veendunud, et riigil ei tule tagantjärgi ka mõne valimisel osalenud kandidaadiga kohut käia või ei sea keegi kogu seda e-valimiste temaatikat kahtluse alla. Igatahes mina jään põnevusega ootama.
"Ämbrimüük" on täies hoos!
Testida või mitte?
0,5*1*194 000 = 97 000 EUR
Kas potentsiaalne 97 KEURi kahju kaalub üles 12 KEUR säästmise? Siia pole lisatud partnerite omavaheliste suhete keeruliseks muutumisest tingitud kulu, sest tõenäoliselt sama partneriga enam ei jätkata, ning uus partner peab eelmise partneri loodud tarkvara üle võtma, et seda edasi arendada.
Tulles tagasi valmiste ja valimiste infosüsteemi juurde, siis millised on selle süsteemi potentsiaalsed ärikahjud? Raha ju sellega ei teenita, kuid valimiste institutsiooni usaldusväärsus ja arendaja usaldusväärsus said maksumaksja raha eest päris oluliselt kannatada. Ma ei ole täielikult veendunud, et riigil ei tule tagantjärgi ka mõne valimisel osalenud kandidaadiga kohut käia või ei sea keegi kogu seda e-valimiste temaatikat kahtluse alla. Igatahes mina jään põnevusega ootama.
"Ämbrimüük" on täies hoos!
Kommentaare ei ole:
Postita kommentaar