Arkisto: maaliskuu 2012



Me teemme testauksesta taidetta

19. maaliskuuta, 2012 | Kirjoittaja: Jussi Niittyviita
Kommentit: 5

Taide ei ole koskaan virheetöntä. Taide synnyttää teoksia, jotka ovat taiteilijan sisäisten ajatusten kanavointia konkreettiseksi ruumiillistumaksi. Näitä asioita ja taiteenlajeja on nykyään määriteltävissä lukematon määrä aina varhaisimmista luolamaalauksista muinaisen Egyptin eeppisten temppelien kautta moderniin audiovisuaaliseen hengentuotokseen. Kaikkia taiteenlajeja yhdistää yksi ainoa tekijä:

Taide herättää tunteita.

Taiteilijalla on lähes aina teostensa taustalla vakaa pohjavirta, vaikka pinnalla näyttäisi kuohuavankin. Tuo pohjavirta on se Fiilis, jonka taiteilija haluaa teokseensa ruumiillistuvan. Se ohjaa siveltimen liikettä pellavakankaalla, mustekynän reittiä paperilla ja sormien tanssia pianon koskettimilla. Se pitää tanssijan askeleen vakaana ja kapellimestarin tahtipuikon sulavassa liikkeessä. Kukaties se ohjaa runoilijankin kättä viinapullolle palkkapäivänä.

Fiilis on se kokonaisuus, joka heijastaa pienimmänkin valonpilkkeen taideteoksen pinnasta tarkastelijan silmään ja sitä kautta hermoratoja pitkin aktivoimaan ja kutkuttelemaan aivojemme tunnekeskusta. Fiiliksestä emme löydä emmekä edes tarkoituksella etsi mitättömiä virheitä; vain kokonaisuus merkitsee. Tuosta kokonaisuudesta joko nautimme tai emme nauti. Kun taideteos herättää Fiiliksen, on se tehnyt tehtävänsä.

Unohtakaa turhat tilastot virheitten määristä, tuotteen maturiteetista, pass-fail-suhteista ja vaatimusten täyttämisestä. Kokeilkaa joskus löytää projektinne koukeroista ja maallisesta vilskeestä Fiilis. Ehkäpä testauksenkaan tarkoitus ei ole valmistaa virheetöntä tuotetta vaan pikemminkin tuote, josta kanavoituu se suunnittelijan, arkkitehdin, koodaajan ja taiteilijan hengen syvin tuotos: Tunne.

 

Testaus voi tuplata ohjelmistotuotteen tuloksen

12. maaliskuuta, 2012 | Kirjoittaja: Antti Niittyviita
Kommentit: 8

Ohjelmistoprojekti koostuu kolmesta olennaisesta kuluerästä. Juuri rakkaudella säveltämäni loru kertoo, mistä tässä kolmen kärjessä on kysymys.

Mistä on pienet ohjelmistoprojektit tehty,

mistä on pienet ohjelmistoprojektit tehty?

Koodauksesta, testauksesta, teknisen velan mittauksesta.

Niistä on pienet ohjelmistoprojektit tehty!

Jos tällaista pientä, noin miljoonan euron, ohjelmistoprojektia pysähtyy hetkeksi ajattelemaan tarkemmin, niin sen kulurakenne voisi näyttää tältä:

  1. Koodaus. 600k€: Ohjelmiston kehittäjällä on tarve saada softa toimitusvalmiiksi. Softan kaikkien haluttujen ominaisuuksien kehittäminen vie karkeasti ajatellen saman määrän työaikaa ja rahaa kaikissa tapauksissa. Featuret vaan pitää saada valmiiksi. Sitä faktaa ei voi paeta.
  2. Testaus. 50k€: Ohjelmistoprojektin toinen oleellinen kuluerä on testaus. Tyypillisesti tavoitellessa kovaa tulosta softaprojektista testaus on se paikka mistä leikataan kustannuksia. Useimmiten testauksen kulut ovat luokkaa 5-10% kehityksen kokonaiskuluista, kun suositus olisi 20-40%.
  3. Tekninen velka. 350k€: Kaikissa ohjelmistoprojekteissa muodostuu teknistä velkaa. Se koostuu lopputuotteeseen päätyvistä virheistä ja ongelmista, jotka aiheuttavat toimituksen jälkeen kustannuksia reklamaatioiden, takuukorjausten ja päivitysten muodossa. Lisäksi se voi aiheuttaa tulonmenetyksiä, kun maine laatutuotteiden toimittajana kärsii.

Kun tällainen projekti tuottaa liikevaihtoa 1.200k€ tulos on tasolla 200.000€ (20%). Hyvin toteutettu testaus voi kuitenkin säästää ohjelmiston elinkaaren kuluja suhteella 1:3.

Testausinvestoinnin vaikutus

Testausinvestoinnin vaikutus

Oikein suunnitellun testauksen avulla 100k€ lisäinvestointi laatuun voisi auttaa löytämään jopa 1000 bugia enemmän projektin aikana. Tekninen velka jäisi näistä ongelmista syntymättä ja ne voitaisiin korjata jo tuotekehityksen aikana. Lisäinvestoinnin avulla mainittu kolmen kuluerän summa onkin vain 800k€, mutta mitä se sitten tarkoittaa?

No tietysti lisää rahaa! Ohjelmistotuotteen tulos kaksinkertaistuu ja laadukkaampi tuote tekee myös varmasti paremmin kauppansa!

Miksi julkiset IT-hankkeet niin usein menevät pieleen?

5. maaliskuuta, 2012 | Kirjoittaja: Jaakko Sakaranaho

Tietoviikko pohdiskelee aihetta, että voiko julkisella sektorilla huonosta IT-hankkeesta kieltäytyä. Siellä puhutaan hienoja sanoja ja kerrotaan, että hieno strategia ict-hankintoihin pitäisi olla. Minä uskon, että IT-strategiatyöryhmistä ei löydy ratkaisua tähän ongelmaan.

Toimikoon tämä kirjoitus enemmän hahmotelmana ja keskustelunavauksena, kuin ilmiselvänä faktana. Kirjoituksen tarkoituksena pohdiskella, minkä vuoksi julkiset it-hankkeet epäonnistuvat niin usein. Aluksi käyn lyhyesti läpi lähteiden it-hankkeiden onnistumisten ja epäonnistumisten syytä. Sitten kuvataan lyhyesti julkisten it-hankkeiden kilpailutusmenettelyt. Voi olla, että nuo kaksi asiaa liittyvät toisiinsa.

Googlettamalla ”Why software projects fail” löytyy sivustokaupalla syitä, miksi it-projektit ylipäätään voivat mennä pieleen. Listoilla on hieman eri painotuksia, mutta jokaisessa nousee esille loppukäyttäjän näkökulman puute. Siis se, että hankkeen speksaa, kilpailuttaa, tilaa ja hyväksyy jokin aivan muu taho, kuin loppukäyttäjät. Lisäksi johdon tuki oli usein puutteelista tai jopa olematonta. Oleellista on huomata, että teknologiset haasteet tai henkilöiden ”epäkurantti” osaaminen eivät olleet lähellekään yhtä merkityksellisiä tekijöitä.

Onnistuneille projekteille ominaista on, kuten edellisen kappaleen perusteella arvata saattaa, että loppukäyttäjät ovat alusta asti osallisena projektiin. Tämä auttaa paitsi tekemään toimivamman softan, helpottaa se myös käyttöönottovaihetta, kun ohjelmisto on tuttu. Loppukäyttäjien mukanaolo puolestaan johtaa väistämättä siihen, että ohjelmiston vaatimuksia lisätään, muutetaan ja poistetaan kehitystyön edetessä. Tämä vaatii joustavia kehittäjiä ja projektipäälliköitä, jotka oikeasi haluvat saada asiakkaan tyytyväiseksi ja tuotteen erinomaiseksi.

Julkiset IT-palveluiden kilpailutukset etenevät kutakuinkin seuraavasti:

  1. Julkinen yksikkö päättää, että tarvitaan Järjestelmä.
  2. Julkinen yksikkö saattaa tehdä tietopyynnön, missä potentiaalisilta toimittajilta pyydetään kommentteja.
  3. Hankittavan Järjestelmän vaatimusmäärittely tehdään parhaan kyvyn ja osaamisen mukaan. Mukana arvailemassa saattaa olla myös tulevia käyttäjiä
  4. Toimittajat kilpailutetaan ja valitaan kokonaistaloudellisesti edullisin

Valitulla Toimittajalla on speksi, jonka perusteella ohjelmisto pitää toteuttaa kiinteään hintaan. Muutosten tekeminen on hankalaa, koska se muuttaa Toimittajan aikataulutusta ja sitä kautta kasvattaa kuluja tai vaihtoehtoisesti Julkisen yksikön tulisi kasvattaa budjettia. Se on aika hankalaa julkisella sektorilla, joten mennään alkuperäisen suunnitelman mukaan.

Näin ollen, julkisissa hankinnoissa on rasitteena kilpailutuksesta ja kilpailulainsäädännöstä johtuva rakenteellinen ongelma. Loppukäyttäjien tiedon ja asiantuntemuksen hyödyntäminen projektin kuluessa on tehty kutakuinkin mahdottomaksi. Ja kuten aikaisemmin todettiin, on se suurin yksittäinen syy, miksi IT-hankkeet epäonnistuva.

En tunne kilpailulainsäädäntöä kovin hyvin. Jos kilpailutuksen voisi hoitaa siten, loppukäyttäjät saadaan järkevästi mukaan hankkeeseen, niin lakimuutoksia ei silloin tarvittaisi. Ainoastaan osaamista ostoihin. IT-järjestelmän kilpailutusta ei voida tehdä samoilla menetelmillä, kuin lumen aurausta tai lämpöpumppujen asennusta.

Avaan keskustelun!