Virheet ja bugit kuuluvat ohjelmistokehitykseen, mutta niitä voidaan myös ehkäistä

Ohjelmistokehitys ei ole lasten leikkiä. Ohjelmistoprojektin saattaminen alusta loppuun vaatii useiden ammattilaisten ja sidosryhmien välistä tiivistä kommunikointia, jopa tuhansia tunteja työtä ja lukemattomia kupillisia kahvia. Kuten arkielämässäkin, myös ohjelmistokehityksessä tapahtuu joskus virheitä. Virheiden skaala vaihtelee tavallisista bugeista aikaa vieviin virhearvioihin ja paljon harvemmin myös projektin loppuun viemistä uhkaaviin emämunauksiin. Niinpä. Pelottavaa. Tässä avaamme kolmea yleisintä ohjelmistokehityksen sudenkuoppaa ainakin meidän taipaleellamme.

Kaikki tekevät virheitä

Sitä ei kannata kiistää. Niin kauan kuin on ihmisiä on myös virheitä. Todellisuus on, että virheitä tapahtuu niin projektitiimin sisällä, kuin sen ulkopuolellakin. Pieniä huolimattomuusvirheitä ja bugeja koodissa tapahtuu usein, mutta ne ovat osa prosessia ja niiden korjaus onkin useimmiten helppoa. Suurempia mokia voi tapahtua, jos projektitiimi ei ole tarpeeksi hyvin kartalla projektin vaatimuksista ja rajoitteista. Näitä voidaan ehkäistä tarkemmalla suunnittelulla ja mm. parantamalla kommunikaatiota asiakkaan, projektijohdon ja tiimiläisten välillä, sekä varmistamalla kaikkien ymmärtävän projektin vaiheen ja prioriteetit riittävän usein. 

Pienet projektitiimin sisäiset virheet eivät useimmiten aiheuta kovinkaan mittavia korjaustoimia, vaan ne saadaan ratkaistua sisäisesti. Näistäkin tulisi tosin ilmoittaa asiakkaalle, jotta asiakkaista ei ala tuntua siltä, että tietoa pimitetään. Viimeinen asia mitä projekti kaipaa on, että korjattavissa oleva ongelma johtaisi isompaan ongelmaan salailun vuoksi. Tosin ongelman sattuessa myös ratkaisu on hyvä esittää samalla, ettei virheestä nouse kummallekaan osapuolelle sen suurempaa stressiä. 

Suurempien vahinkojen ilmetessä on virheistä syytä viestiä mahdollisimman nopeasti asiakkaan suuntaan, sillä virhe saattaa vaikuttaa olennaisesti esimerkiksi projektin valmistumisajankohtaan ja julkaisuun. Valmistumiseen ja julkaisuun liittyy usein asiakkaan sisäistä ja ulkoista viestintää ja tehokkaalla toiminnalla voidaan välttää turhia väärinkäsityksiä ja julkisia mokia. Mitä enemmän asiakas virheestä kärsii, sitä enemmän kärsii myös yhteinen luottamus. Ja luottamus on elintärkeä säilyttää, kun yhteistyötä halutaan jatkaa pitkään.

1. sudenkuoppa: kaikki lähtee myyntiprosessista

Ennen kuin ohjelmistoprojektin toteuttamista on alettu suunnittelemaan ja ohjelmisto on pelkkä idea asiakkaan mielessä, on myynnin tehtävänä myydä ohjelmistoprojektin toteutus asiakkaalle. Tässä on ohjelmistoprojektin ensimmäisen ja pahimmillaan erittäin suurenkin sudenkuopan mahdollisuus. 

Myyjän täytyy vakuuttaa asiakas siitä, että hänen edustamansa yritys on juuri oikea toteuttamaan asiakkaan projekti. Jos myyjä lupailee asiakkaalle taivaalta kuuta, eli enemmän kuin mitä yritys pystyy tarjoamaan, on ohjelmistoprojekti jo aloitettaessa erittäin heikolla pohjalla. Jossain vaiheessa asiakkaalle valkenee, ettei yritys pysty toteuttamaan sellaista ohjelmistoa, kuin on projektia myytäessä lupailtu. Tällöin koko projekti saattaa kaatua, mikä ei ole kummallekaan osapuolelle ideaali ratkaisu. Asiakas ei saa luvatun kaltaista sovellusta ja yritys voi saada oikeudellisia seuraamuksia riippuen tehdystä sopimuksesta. Edellinen on monella tapaa siis pahin mahdollinen tulos. 

Kuvituskuva: koiranpäivät myynnissä. Adobe stock.

Myynti onkin taitolaji, jossa täytyy osata antaa mahdollisimman realistinen, mutta kuitenkin suotuisa kuva asiakkaalle siitä, mitä osataan ja kyetään tekemään. Taitava myyjä osaa sopivassa määrin hehkuttaa kollegoiden ammattitaitoa, jotta asiakas valitsee luottavaisin mielin heidät toteuttamaan projektia. Samalla myyjä asettaa riman oikealle tasolle, jolla projektista tulee varmasti vaatimusten tasoinen ja kehittäjille sopivan haastava. Moni kehittäjä kokee työn miellyttävämmäksi kun se kannustaa kehittymään. Toki kehitys vaatii aina oman aikansa eli myös aikataulun pitää olla riittävä.

Ennen nimen kirjoittamista sopimukseen kannattaa asiakkaan tehdä hieman taustatutkimusta tarjouksen tehneestä yrityksestä. Ainakin yrityksen taloustiedot kannattaa tarkistaa ja referenssit vilkaista läpi. Luotettavalla ohjelmistoyrityksellä on projektien referenssejä helposti löydettävissä omilla verkkosivuillaan. Meidän referenssimme löydät täältä. Kannattaa muistaa, että referenssit eivät pysy täysin uusimpien projektien ajan tasalla, vaan tulevat aina jäljessä sivuille. Samoin on myös meillä. 

2. sudenkuoppa: projektin laajuuden määrittely

Kun ohjelmistoprojekti on myyty asiakkaalle ja on aika ruveta suunnittelemaan projektin toteutusta, on syytä miettiä tarkasti mitä projektilta halutaan. Perusteellinen vaatimusmäärittely onkin yksi tärkeimmistä edellytyksistä onnistuneelle ohjelmistoprojektille. Vaatimusmäärittelyn käyvät läpi asiakas ja projektitiimi yhdessä, jotta kaikki ovat samalla aaltopituudella projektin laajuuden kanssa.

Vaatimusmäärittelystä tulisi käydä yksiselitteisesti ilmi, mitä ominaisuuksia ja piirteitä asiakas ohjelmistolta haluaa. On tärkeää, että edes asiakas tietää mitä ensisijaisesti ohjelmistoltaan toivoo. Pelkkä “olisi kiva, jos siinä olisi tämmönen ja tällainen ominaisuus” ei ihan riitä. Tässä asiassa voi auttaa Product owner eli projektin johtaja, sillä heillä on työnsä puolesta aiempaa kokemusta onnistuneiden projektien vaatimuksista ja ominaisuuksista. Jos vaatimusmäärittely ei ole tarpeeksi perusteellinen, on virheiden sattumisen mahdollisuus suuri. 

Määrittelyyn liittyviä virheitä voidaan käytännössä ehkäistä esimerkiksi siten, että joku projektitiimistä, esimerkiksi devaaja tai product owner osallistuu myyntiedustajan seurana speksauspalaveriin. ”Speksaus” tarkoittaa tässä tapauksessa ohjelmiston määrittelyä. Kun tiimi on itse vastuussa niin koodin tekemisestä kuin projektin koon yksityiskohtien määrittelystä, tulee harvemmin yllätyksiä. Lisäksi kaikki osalliset ymmärtävät jo ennen projektin alkua minkä kokoluokan rupeamaan ovat ryhtymässä.

Varsinkin kokemattomille myyjille voi sattua helppoja ison luokan virheitä, kun asiakkaille ollaan speksaamassa räätälöityjä ratkaisuja. Asiakkaat harvemmin haluavat täysin samanlaisia toteutuksia kuin ohjelmistotalojen edelliset projektit, joten hinta voi vaihdella paljonkin samankaltaisten projektien välillä. Kuvitellaan vaikkapa asiakashallinnan työkalu. Siinä sanan “hallinta” merkitys tulisi määritellä tarkasti, koska se voi tulkinnasta riippuen pitää niin paljon asioita sisällään. Riittääkö vain asiakkaiden siirtelyominaisuus paikasta toiseen? Vai onko ensisijaisen tärkeää myös hallita asiakkaiden tietoja samassa näkymässä? Isojen eroavaisuuksien välille mahtuu jopa tuhansien työtuntien eroja. Siksi tarkka määrittely on niin tärkeää.

Vaatimukset voivat toki muuttua ja niitä pitääkin päivittää projektin aikana kun aihetta tulee, mutta liika vaatimusten muuttaminen vaikeuttaa ja pitkittää projektin valmistumista. Ne myös kertovat heikosta suunnitteluvaiheesta. Kesken projektin tapahtuvat muutokset aiheuttavat yleensä ylimääräistä työtä ja lisäkustannuksia.

3. sudenkuoppa: kommunikaatio

Vaikka vaatimusmäärittely onkin yksi tärkeimmistä ohjelmistokehitysprosessin vaiheista, on kommunikaatiolla valtavan suuri osa koko projektin ajan. Kommunikaation tulee olla helppoa ja kaksisuuntaista.

Projektijohdon tehtävä on viestiä asiakkaalle projektin etenemisen vaiheista ja asiakkaan tehtävä taas on pitää projektijohto ajan tasalla mahdollisista muutoksista projektin vaatimuksiin tai toteutukseen. Jos kommunikaatio takkuaa kumpaan suuntaan tahansa, on projektin saattaminen toivotulla tavalla loppuun lähes mahdotonta.

Kuvituskuva: kommunikointia parhaimmillaan. Adobe stock.

Viestintään pystytään vaikuttamaan varmistamalla nopea ja selkeä kommunikaatiokanava, esimerkiksi Slack-viestintäalusta. Sähköposti ja puhelin ovat myös perinteisiä ja tehokkaita viestimiä, vaikka niissä on omat etunsa ja haittansa. Sähköposti ei ole yhtä helppolukuinen kuin Slack ja täyttyy viesteistä nopeasti. Puhelu taas katkaisee aina ajatuksen ja työnteon soidessaan, mikä on henkisesti raskasta.

Viestintäkanavan valinnan lisäksi tulee sopia mihin aikaan eri osapuolet ovat tavoitettavissa ja millä aikataululla yhteydenottoihin vastataan. Selkeät pelisäännöt varmistavat, että yhteistyö on saumatonta ja tieto kulkee osapuolten välillä, kuten pitääkin. Asioiden olettaminen ei edistä asioiden etenemistä. 

Loppukaneetti

Vaikka virheitä sattuukin, voidaan niiden merkitystä ja todennäköisyyttä vähentää huomattavasti parantamalla eri sidosryhmien välistä kommunikaatiota, sekä ottamalla opiksi aikaisemmista virheistä. Osaavan ohjelmistokehityskumppanin valitsemalla voi myös merkittävästi vähentää virheiden riskiä ja samalla varmistua siitä, että mahdolliset virheet osataan ratkaista. 

Me Verticsillä huomaamme panostavamme yhä enemmän ohjelmistoprojektien suunnitteluun ja asiakasviestintään. Jos itse innostuit lähtemään kokeilemaan asiakkaan puolta prosessissamme, niin laita viestiä hello@vertics.co.