torstai 29. syyskuuta 2011

Miksi isolla rahalla tehdään epäonnistuneita ohjelmistoja?

VR on päässyt toistuvasti otsikoihin epäonnistumisistaan. Uusimpana on laajempaakin keskustelua kirvoittanut verkkokauppauudistus. Uuden järjestelmän käyttöönotto epäonnistui jokseenkin täydellisesti mm. siksi, että kenellekään ei ollut tullut mieleen, että uutta palvelua haluaisi ensimmäisenä päivänä käyttää niin moni. Ei tullut mieleen, vaikka koko uudistuksen tavoite oli varmaankin juuri lisätä verkkoasiointia ja matkojen ostamista entistä ennakoivammin. Jälkikäteen on ollut helppo todeta myös joistakin muista vastaan tulleista ongelmista, että niiden olisi pitänyt jäädä kiinni viimeistään järjestelmän hyväksymistestausvaiheessa.

Fiasko on kirvoittanut keskustelua IT-alan toimintatavoista yleensäkin. Epäonnistumisia on paljon, ja varmaan lähes jokainen joka joutuu työssään käyttämään tietokonetta, pystyy nimeämään ohjelmiston, joka on vaikeakäyttöinen, ei täytä tarvetta johon se on hankittu, tai jonka toiminnassa on muita selkeitä ongelmia.

IT-alan toimintatavat saattavat monessakin suhteessa tuoda mieleen rakennusalan ongelmat: on vaikea löytää osaavia tekijöitä, alihankintaketjut saattavat aiheuttaa yllätyksiä, aikatauluissa ei juuri koskaan pysytä, ja lopputulos saattaa herättää asiakkaan mielessä kysymyksen, onko kyhäelmästä vastannut modernin ajan käsityöläinen ikinä tullut edes ajatelleeksi, mihin tarkoitukseen tuote on tehty.

On jopa esitetty väitteitä, että IT-alalla tehdään bisnestä epäonnistumisilla. Kun alkuperäinen toimitusprojekti ei täytäkään asiakkaan tarpeita, saadaan rahakkaita jatkoprojekteja ja mahdollisuus laskuttaa ylläpitotöistä.

On aika rankka väite sanoa, että joku tekisi tahallaan asioita väärin saadakseen myöhemmin laskuttaa virheiden korjaamisesta. Tällä toimintatavalla on myös vaikea tehdä kannattavaa bisnestä, ellei koko ala toimi samalla logiikalla. Entä millainen mahtaa olla ammattiylpeys henkilöllä, jonka tehtävänä on tahallaan tehdä virheitä? Moni kokee turhauttavaksi jo sen, että kiireen ja joskus myös puutteellisen ohjeistuksen vuoksi ei ole mahdollisuutta tehdä asioita niin hyvin kuin haluaisi. Sitäpaitsi isolla rahalla toteutettavat kokonaisuudet ovat yleensä niin monimutkaisia, ettei tarvita tarkoituksellista yrittämistä ongelmien aikaansaamiseen. Niitä kaikkia kun on erittäin haasteellista saada ehkäistyä.

Rakennusalaa ja IT-alaa yhdistää ehkä myös se, että monien asiakkaiden on vaikea uskoa, miten paljon asioiden kunnollinen tekeminen vie aikaa ja rahaa. Tarjouskilpailun voittaakseen on luvattava toteutus nopeasti ja halvalla, ja koska varmoja asiakkaita ei ole, joskus on pakko myydä vaikka ei voi vielä tietää, riittävätkö resurssit jos tehdyt tarjoukset menevät läpi. Tilanne ei varmaankaan ole otollisimmillaan luomaan näille aloille toimijoita, jotka pärjäisivät ensisijaisesti laadulla.

Lisäksi olemme niin riippuvaisia tietojärjestelmistä, että niitä joudutaan hankkimaan hyvin monenlaisiin organisaatioihin, eikä hankintaprojekteista vastaavilla välttämättä ole aina riittävää osaamista saati aikaa tehtäväänsä. Isossa organisaatiossa ohjelmistoa saattaa käyttää myös hyvin eri tyyppisiä käyttäjiä, joiden tarpeet ohjelmiston käytössä ovat keskenään täysin erilaisia. Kun ei olla ostamassa asennusvalmista valmisohjelmistoa vaan joudutaan tekemään toiminnallisuuksia asiakkaan tarpeisiin, IT-toimittaja voi tehdä työnsä hyvin vain jos asiakas pystyy kertomaan, mitkä nämä tarpeet ovat.

Harva asiantuntija tuntee asiakkaansa prosessit niin hyvin, että hän voisi arvata miten kaikki eri tyyppiset loppukäyttäjät tulevat ohjelmistoa käyttämään. Jos toimituksen pohjana on kilometrin mittainen ominaisuuslista, mutta ei kunnollista tietoa loppukäyttäjien eri rooleista ja tehtävistä, eli siitä millaisten asioiden olisi sujuttava helposti ohjelmistoa käytettäessä, ei ole ihmekään jos lopputulos aiheuttaa nurinaa viimeistään käyttöönottovaiheessa.

Toki IT-toimittajan pitäisi pystyä kertomaan asiakkaalle, millaisia riskejä liittyy esim. määritysvaiheen tai testaussuunnittelun huolimattomaan läpikäyntiin, sekä esittää kysymyksiä jotka auttavat asiakasta miettimään vaikkapa juuri suorituskykyyn liittyviä tarpeitaan tarkemmin.

Mikä tilanteeseen auttaisi?

Ideaalimaailmassa IT-toimittaja saisi haastatella jokaista käyttäjäryhmää tarpeiden selvittämiseksi, ja ohjelman käyttötavat kuvattaisiin yhdessä asiakkaan kanssa tavalla, joka ei aseta liikaa rajoituksia toteutukselle mutta varmistaa valmistuvan ohjelmiston tukevan asiakkaan prosesseja. Joskus toimituksen voisi myös jakaa osiin tavalla, joka tarjoaisi mahdollisuuden päästä kokeilemaan järjestelmän käyttöä ennen kuin kaikki toiminnot on toteutettu, jolloin todelliset tarpeet voisi olla helpompi löytää kuin tehtäessä määritystä puhtaasti paperilla.

Tosimaailmassa projektin aikataulu ei välttämättä mahdollista tätä, eikä asiakas aina edes halua päästää loppukäyttäjiä vaikuttamaan lopputulokseen.

Ja jos toteutuksen venyessä päätetään kiriä aikataulua nipistämällä testauksesta, ei pitäisi olla kovin yllättävää, jos asiakkaan käyttöön asennettu ohjelmisto ei toimikaan kuin junan vessa.

Ei kommentteja:

Lähetä kommentti