Projektin kokonaistilannetta ei usein tiedetä

Kun aloitetaan hyväksymistestaus, on tärkeää tietää, mitkä toteutukset EIVÄT ole valmiita. Usein kun valmiusastetta tiedustelee, tulee vastaus: “Kaikki on valmista, paitsi pari pikku juttua”. Useimmiten tiedossa ei ole tarkasti, mitä nuo pari pikku juttua ovat.

Kokemukseni mukaan 10-20 % hyväksymistestauksen virheistä ei ole virheitä, vaan syynä on keskeneräinen toteutus. Näiden toteuttamattomien asioiden löytäminen testaamalla on tosi turhauttavaa ja kallista. Lisäksi se on aivan turhaa.

Esimerkkejä aiheista, joihin testaus usein kolahtaa.

• Integraatiot kolmannen osapuolen järjestelmiin. Näistä joku osa tekemättä.
• Muutospyynnöt, joita on tehty määrittelyn varrella. Varsinkin ne, jotka eivät ole vielä toteutuksessa.
• Tulosteet ovat viimeistelemättä tai ainakin osa puuttuu.
• Asiakkaan omalla vastuulla olevat toteutukset
• Avoimet asiat, joista ei ole vielä päätöstä.

Miksi tilannekuva on puutteellinen:

Yksinkertaisesti: Prosessi määrittelystä käyttöönottoon ei ole kunnossa. → Asiakkaalta uupuu reaaliaikainen näkymä toteutuksen valmistumiseen kokonaisuutena. Projektin tekeminen on pirstoutunut useisiin seurantoihin, joiden tarkkuus ja reaaliaikaisuus vaihtelevat. Ja lisänä ovat vielä ne sadat sähköpostit, jotka sisältävät päätöksiä ja dokumentoimattomia määrittelyjä.

Näin me olemme ratkaisseet toteutuksen seurannan

Kehitämme jatkuvasti ProjectTOP-ohjelmistoja sekä teemme kehitysprojekteja asiakkaillemme. Näissä projekteissa meillä ja asiakkaalla on reaaliaikainen näkyvyys siihen, mikä on valmista ja mikä ei. Kehitysprosessimme idea on seuraavanlainen:

• Kehitysprojektin alussa jaamme toteutettavan osion aktiviteetteihin tarkalla tasolla, ja aktiviteetit sopiviin toteutuspaketteihin.
• Aktiviteeteilla on määriteltynä prosessi (Avoin - Määrittelyssä - Määrittely valmis - Toteutuspäätös - Toteutuksessa - Valmis testattavaksi - Virhe / Testattu OK)
• Aktiviteeteille annetaan aikataulu ja resurssit. Vastuuhenkilöksi henkilö, jonka pitää seuraavaksi edistää aktiviteettia.

→ Näemme reaaliaikaisesti, kenellä aktiviteetti on ja missä vaiheessa prosessia.

Tästä on hieman eri variaatioita projektin luonteesta johtuen, mutta seurannan osuus menee aina näin. Esimerkiksi voimme tehdä ensin käyttötapaukset ja johtaa niistä toteutettavat aktiviteetit.

Alla esimerkki aktiviteetista.

Muutoksenhallinta, virheidenhallinta ja avoimet asiat

Tuon yllä oleva on ehkä vielä hallussa, mutta kun matkan varrella tehdään kehitysehdotuksia, muutospyyntöjä, projektille kirjataan kysymyksiä ja löydetään virheitä, niin usein pakka hajoaa. Kokonaisnäkymä menetetään. Me olemme ratkaisseet tämän seuraavasti:

• Jokaisesta kehitysehdotuksesta ja löydetystä virheestä tehdään projektille aktiviteetti.
• Kuka tahansa voi luoda projektille kysymyksen. Näistä avoimista asioistakin generoituu projektille aktiviteetti.
• Aktiviteeteilla on määritelty prosessit valmiina. Esim. Löydetystä virheestä voidaan johtaa kehitysehdotus.
• Aktiviteeteille annetaan aikataulu ja resurssit. Vastuuhenkilöksi henkilö, jonka pitää seuraavaksi edistää aktiviteettia.

→ Näemme reaaliaikaisesti, kenellä aktiviteetti on ja missä vaiheessa prosessia.

Vaatimukset ←→ Hyödyt

Kuvaamani prosessin rakentaminen onnistuu, kun seuraavat kolme kohtaa täyttyvät:

1. Tarvitaan ymmärrys kehitysprojektien kulusta alusta loppuun.
2. Tarvitaan yhteinen ohjelmisto kaikille projektin osapuolille (Ei tarkoita kasaa exceleitä ja sharepoint-sivuja.)
3. Tarvitaan halu kehittää toimintaa tehokkaammaksi. Kyky johtaa ja kommunikoi

Hyötyjä on paljon

• Merkittäviä kustannussäästöjä.
• Reaaliaikainen raportointi ja näkymä projektiin kokonaisuutena.
• Tekijöille selkeät työlistat.
• Projektipäällikölle mahdollisuus johtaa projektia.
• Toimittajan toteutuksen ja kustannusten hallinta.
• Hyväksymistestauksessa ei löydetä yllä mainittuja turhia virheitä.
• Testauksen suunnittelu helpompaa.
• Voidaan ratkaista ongelmat jo ennen niiden syntymistä.
• Kun tehdään useita projekteja yhtä aikaa, voidaan helposti priorisoida tehtäviä kokonaisuutena.

Miksi sitten hyväksymistestauksessa kolahtaa?

Aika useissa projekteissa meitä pyydetään mukaan projektiin, kun testausvaihe on jo alkamassa. Ehkä sen takia, että tarjoamme nopeasti käyttöön otettavaa testausohjelmistoa. Peli on jo usein menetetty, koska projektin tekeminen on pirstaloitunut. Toisaalta useita, haastaviakin projekteja on saatu maaliin aikataulussa ja budjetissa, kun vastaavanlainen toimintamalli on otettu käyttöön heti projektin alusta.

Esimerkki reaaliaikaisesta seurannasta alla.