Blogisarja Kehitysprojektin testauksesta, Osa 7/11

Kirjoituksia ohjelmistotestauksen suunnittelusta ja johtamisesta.

Näkökulmana:

• Liiketoiminnalle kriittiset kehitysprojektit, joissa IT vahvasti mukana.
• Yksi tai useampia ulkoisia toimittajia.
• Asiakkaan henkilöstö liiketoiminnasta testaamassa. Ovat liiketoiminnan ammattilaisia, eivät ohjelmistotestauksen.
• Testauksen tavoitteet: 1. Varmistaa, että käyttöönotettava ratkaisu tukee liiketoiminnan tarpeita 2. Varmistaa, että käyttöönotto ei vaaranna liiketoimintaa.

Realisoituvatko kehittämisen hyödyt?

Jotkut asiakkaat ovat kuvanneet ERPin tuotantoympäristöä kehitysehdotusten hautausmaaksi. Tarkoittaen, että kehitysehdotuksia kyllä toteutetaan, mutta hyötyjä ei saada oikeasti liiketoiminnan käyttöön. Muutamia yleisiä syitä, miksi näin käy:

1. Kehitysehdotus toteutetaan, vaikka taustalla ei ole aitoa business casea.
2. Kehitysehdotuksen tarvemäärittely epäonnistuu
3. Alkuperäinen tarve hämärtyy toteutusprosessin aikana
4. Toteutus ei vastaa määrittelyä – Virhe ei jää testauksessa kiinni

Jatkuvan kehittämisen prosessi

Alla on esimerkki kehittämisprosessista, jonka mukaisesti kehitämme ProjectTOP ohjelmistoja. Jokaisen yrityksen prosessi on tietysti omanlaisensa.

Nostan esiin muutamia asioita, mitkä ovat meille tärkeitä:

• Panostus hyödyksi nopeasti: Kehittäminen sopivan kokoisissa palasissa, jotta investointi alkaa tuottaa nopeasti
• Reaaliaikainen seuranta ja raportointi: Tiedämme jatkuvasti jokaisen kehitysehdotuksen tilan ja henkilöiden kuormitukset.
• Katkeamaton ketju: Jokaisen kehitysehdotuksen historia on nähtävillä. Kuka pyysi ja mitä, miten määritelty, miten toteutettu. Testaaja voi tarkistaa, vastaako toteutus alkuperäistä pyyntöä.
• Henkilökohtaiset työlistat: Koska jokaisella on samaan aikaan useampia projekteja, tarvitaan yksi työlista, jossa on kaikki tekeminen.
• Jatkuva kehittämisen kehittäminen: Vaikka olemme tehokkaita, niin pyrimme jatkuvasti parantamaan kehitysprosessiamme.

1. Kehitysehdotus toteutetaan, vaikka taustalla ei ole aitoa business casea

Kehittämisen tulisi tukea yrityksen strategiaa. Jotta tämä varmistetaan, tulee muutospyyntö analysoida ennen toteutuspäätöstä. Varmistetaan, että kehittämisen panostus tuottaa ja ohjaa yritystä oikeaan suuntaan. Aidolla business casella estetään myös se, ettei kehittämisen suuntaa määrää esittäjän auktoriteetti. ”Satuin istumaan lounaalla Päällikön kanssa, ja hän ehdotti että…..”

Jos kehitysehdotuksen tekijä ei viitsi täyttää Business case -lomaketta, niin silloin kehitysehdotus ei todennäköisesti ole toteuttamisen arvoinen. ”Pikku jutut” kuormittavat yllättävän paljon ja kasvavat usein paljon isommiksi, kuin ehdottaja ymmärtääkään.

Kehittämisen tulisi kuitenkin olla ketterää, joten älä tee business case -analyysistä liian byrokraattista. Kehittämisessä on myös eri tasoja. Aidosti pienet hienosäädöt tulee päästä putkesta läpi joustavasti.

Ongelmat, jos toteutetaan epärelevantteja kehityspyyntöjä:

• Strategianmukainen kehittäminen hidastuu, koska panostetaan vääriin asioihin
• Järjestelmiin tehdään muutoksia, jotka eivät tue strategiaa. Arkkitehtuuri pirstoutuu
• Kehittämisen investointi ei tuota toivottua hyötyä

2. Kehitysehdotuksen tarvemäärittely epäonnistuu

Pahimmillaan kehitysehdotus on kuvattu Excelissä kahdessa solussa + sähköpostikeskustelussa. Jos selkeää tarvemäärittelyä ei saada toteuttajalle, niin toteutuksesta tulee vain hyvä arvaus alkuperäisestä tarpeesta. Ongelmahan on kovin inhimillinen. Jollain on idea siitä mitä pitäisi tehdä, mutta hän ei osaa kuvata sitä selkeästi. Tai kuvauksesta jätetään pois asioita, jotka oletetaan lukijan ymmärtävän ilmankin. Tarvemäärittelyn tekemistä pitää kehittää koko ajan. Kysyä ja kyseenalaistaa. Sen voi tehdä myös ystävällisestikin, jotta kehittymistä oikeasti tapahtuisikin.

3. Alkuperäinen tarve hämärtyy toteutusprosessin aikana

Jos kehittämisen työkaluna on Excelit + sähköpostit + erilliset dokumentit, niin silloin päätöksenteko on usein erillään kehitysprosessista. Kehitysprosessin aikana käydään keskusteluja, joissa muutospyyntöä rikastetaan tai lievennetään. Jos prosessin ketju ei ole katkeamaton, saattaa alkuperäinen tarve unohtua. Toteutetaan ratkaisu, joka ei palvele liiketoimintaa.

Kun tehdään toteutuspäätöstä, tulisi olla käytettävissä informaatio kehitysehdotuksen historiasta. Alkuperäinen tarve, business case, suunnitelma toteutuksesta, keskustelut…
Näin varmistetaan, että toteutukseen lähtee kehitysehdotus, josta on hyötyä liiketoiminnalle.

4. Toteutus ei vastaa määrittelyä – Virhe ei jää testauksessa kiinni

Jos muutoksen testaajalla ei ole käytössä alkuperäistä tarvemäärittelyä ja sen muutoshistoriaa, niin testaaminen jää vain teknisen toteutuksen toimivuuden varmistamiseksi. Usein olen joutunut tilanteeseen, jossa itse muutospyynnöstä on vain nimi. Konsultti ja asiakas ovat keskustelleet muutoksesta, mutta keskustelua ei ole dokumentoitu. Jolloin on kaksi vaihtoehtoa edetä:

1. Uskoa että ymmärtää muutoksen tarkoituksen annetusta vihjeestä -> Tuotantoon saattaa päästä muutos, joka ei vastaa liiketoiminnan tarvetta.
2. Alkaa selvittään, mistäs olikaan kyse. -> Käytetään aikaa tehottomaan tekemiseen.

Ja kun kaikilla on kädet täynnä töitä, niin helposti valitaan ensimmäinen vaihtoehto. Jos muutos on kompleksinen, niin liiketoiminnan tarve saattaa jäädä toteutumatta. Yksi näppärä konsti on muutoksen varmistamiseksi, on tehdä ohje/versiotiedote testauksen aikana. Sen avulla voi kommunikoida liiketoiminnan kanssa, onnistuttiinko.

Nykymaailman kiire aiheuttaa kehittämiseen yhden ison ongelman: Jokainen tekee oman osuuden siten, miten se on nopeinta tehdä. Kehitysprosessin alussa hosuminen tuottaa yleensä huonon lopputuloksen. Järjestelmällinen tekeminen, oikeilla työkaluilla on paljon tehokkaampaa