Musta laatikko
Vaatimusmäärittely on viimein valmis! Asiakkaan yhtiön pitkään suunnittelema ja tarpeellinen toiminnanohjausjärjestelmä on saavuttanut pisteen, jossa sen kehittäminen voidaan aloittaa. Yhtiö lähtee kilpailuttamaan ohjelmiston toimittajia ja valitsee parhaimman tarjouksen. Valitun toimittajan referenssit, hinta ja osaaminen vaikuttavat lupaavimmalta. Toimittajan kanssa istutaan alas muutaman palaverin verran ja ohjelmiston toimituksesta saadaan sopimukset allekirjoitettua. Kommunikaatio katkeaa tähän. Asiakkaan ja toimittajan välillä ei ole kehitysvaiheessa säännöllisiä palavereita ja asiakas ei pääse käsiksi projektinhallintaan saatikka sitten lähdekoodiin. Lisäksi toimittajan edustajia on hankala saada kiinni. Varsinaisten kehittäjien nimiä asiakas ei edes tiedä. Toimittaja vakuuttelee sähköpostitse, että projekti sujuu loistavasti ja pysyy sovitussa budjetissa. Tilanne jatkuu muutaman kuukauden, kunnes konsulttifirma saa projektin valmiiksi ja toimittaa sen asiakkaalle, unohtamatta tietenkään laskua. Lopullinen, valmis projekti täyttää suurin piirtein asiakkaan toimittamat vaatimukset, mutta osa konsulttifirman ratkaisuista ei vastaa asiakkaan visiota. Koska asiakas ei missään vaiheessa päässyt testaamaan kehitettävää ohjelmistoa, korjataan ilmeneviä bugeja vielä pitkään. Loppujen lopuksi asiakas sai keskinkertaisen ohjelmiston, joka merkittävästi ylitti alustavan budjetin.
Olemme juuri todistaneet surullisenkuuluisaa “musta laatikko” -projektia. Asiakas syöttää ohjelmistoon toivotut vaatimukset laatikkoon ja laatikko tuottaa näitä speksejä vastaavan tuotteen parhaaksi katsomallaan tavalla. Laatikko toimii niin kauan, kun asiakkaan ja konsulttifirman visio tuotteesta on täysin sama. Käytännössä tilanne ei kuitenkaan koskaan ole näin, sillä konsulttifirman kehittäjät tulkitsevat ja ymmärtävät vaatimukset omalla tavallaan. Koska he eivät ole yhteydessä asiakkaaseen, se kuinka hyvin heidän visionsa tuotteesta vastaa asiakkaan visiota on käytännössä arpapeliä. Kyse ei ole kehittäjien tietotaidosta, vaan yksinkertaisesti kommunikaation puutteesta.
Kehitys vaatii kommunikaatiota
“Musta laatikko” -projektilta voidaan välttyä yksinkertaisesti sillä, että asiakas ja toimittaja kommunikoivat keskenään riittävästi. Usein projektia aloitettaessa ei asiakkaallakaan ole täysin kiveen hakattua ja selkeää kuvaa lopullisen tuotteen kaikista yksityiskohdista, tai siitä, miten jokin tietty ominaisuus olisi parasta tehdä. Tällöin kehittäjät joutuvat käyttämään omaa harkintakykyään suunnitellessaan ja työstäessään projektia. Jotta vältytään niin sanotusti metsään menemiseltä kehityksen kannalta tehtyjen päätösten suhteen, pitää kehittäjien ja asiakkaan välillä olla säännöllisiä kokouksia, joissa esitellään jo tehtyjä ominaisuuksia sekä suunnitellaan tulevia ja tekeillä olevia. Juuri kehittäjien tulisi olla säännöllisesti yhteydessä asiakkaaseen. Mikäli esimerkiksi yrityksen myynnin edustaja on asiakkaan pääsääntöinen yhteyshenkilö, joudutaan helposti rikkinäiseen puhelimeen, jossa asiakkaan toiveet ja kehittäjien ehdotukset vääristyvät kulkiessaan kommunikaation välikäden kautta. Suora yhteys kehittäjien ja asiakkaan ohjelmistovastaavan välillä takaa kummallekin osapuolelle mahdollisuuden esittää asiansa oikeassa kontekstissa ja niin selkeästi kuin mahdollista.
Läpinäkyvä Kvanttori
Kvanttorilla olemme todenneet läpinäkyvyyden parantavan asiakastyytyväisyyttä ja helppottavan työtämme merkittävästi. Läpinäkyvyyden takaamiseksi käytämme Scrum-menetelmää. Nopeasti selitettynä Scrum on ketterä projektinhallinnan viitekehys, joka painottaa läpinäkyvyyttä ja reaktiivisuutta säännöllisten tapaamisten ja lyhyen aikavälin suunnitelmien ja tavoitteiden avulla. Scrumissa projekti jaetaan 1-4 viikon pituisiin jaksoihin, joita kutsutaan sprinteiksi. Jokaisen sprintin alussa asetetaan kehitystiimille tavoitteet yhdessä asiakkaan kanssa ja sprintin lopuksi kehitystiimi esittelee tekemänsä ominaisuudet. Tarkoituksena on antaa asiakkaalle mahdollisuus vaikuttaa projektin kulkuun sen jokaisessa vaiheessa ja näin taata, että tuote vastaa asiakkaan visiota. Ottamalla asiakas mukaan aktiiviseksi osaksi projektia sen alusta loppuun ja antamalla heidän tutustua keskeneräiseen tuotteeseen sekä kuuntelemalla heidän palautettaan ja toiveitaan varmistetaan yhtenäinen kuva tuotteen tilasta. Näin vältytään ikäviltä yllätyksiltä molemmin puolin. Tämän lisäksi Scrumissa on tavoitteena julkaista toimivia versioita ohjelmistosta usein, näin mahdollistaen paitsi tehokkaan testaamisen ja tarvittaessa nopean suunnan muutoksen, antaa se asiakkaalle myös mahdollisuuden katkaista yhteistyö aikaisemmin, jos jälki ei vaikuta hyvältä tai yhteistyö ei toimi.
Scrumin lisäksi Kvanttori tarjoaa asiakkailleen pääsyn projektin lähdekoodiin ja projektinhallinnan työkaluihin aina kehitysvaiheen alusta alkaen. Näin asiakas voi halutessaan tutustua koodiin tarkemmin vaikkapa kehittäjän opastuksella ja myös seurata projektiin käytetyn työn määrää ja täten projektin kustannuksia.
Läpinäkyvyys on ehdotonta
Asiakkaalla on oikeus saada realistinen kuva ostamansa ohjelmiston tilasta ja olla varmoja siitä, että heidän toiveitaan ja palautettaan kuunnellaan. Tämän moraalisen perustelun lisäksi, läpinäkyvyys auttaa myös itse ohjelmiston kehittäjiä, sillä he eivät ole ajatustenlukijoita. Jotta kehittäjät pystyvät tekemään työnsä mahdollisimman hyvin, pitää heillä olla mahdollisuus kysyä asiakkaan mielipidettä suoraan. Näin saadaan aikaiseksi ohjelmistoja, joihin asiakas on tyytyväinen ja joiden parissa kehittäjien on mielekästä työskennellä. Toisin sanoen, läpinäkyvyys on hyvän ohjelmistokehityksen vaatimus.
