Milloin projekti alkaa upota?
Jokainen IT-projekti alkaa samankaltaisesti. On kunnianhimoisia suunnitelmia, aikataulu, ensimmäisten mockupien esittely ja usko siihen, että muutaman kuukauden kuluttua yritys alkaa käyttää modernia järjestelmää. Aluksi kaikki näyttää lupaavalta, mutta ajan myötä ilmenee ensimmäiset viivästykset. Määräaikaa siirretään viikolla, myöhemmin kuukaudella. Virheiden määrä kasvaa, viestintä toimittajan kanssa vaikeutuu ja vastaukset alkavat kuulostaa: "Hetki vielä", "Se on vain pieni korjaus" tai "Olemme jo maalissa."
Jonkin ajan kuluttua käy ilmi, että valmiin tuotteen sijaan yritys on jäänyt keskeneräisen projektin kanssa, jota kukaan ei halua ottaa vastaan.
Se on paljon yleisempi skenaario kuin luulisi.
Suurin ongelma ei ole koodi
Useimmat yrityksen omistajat olettavat, että jos projekti ei toimi, syynä on huonosti kirjoitettu koodi. Joskus näin onkin. Käytännössä ongelma on kuitenkin usein syvemmällä.
Dokumentaatio puuttuu. Arkkitehtuuri on syntynyt "juoksevassa prosessissa". Automaattisia testejä ei ole. Integraatiot on tehty väliaikaisesti. Uusia toiminnallisuuksia on lisätty analysoimatta vaikutusta koko järjestelmään. Tuloksena jopa pieni muutos aiheuttaa uusia virheitä.
Se on vähän kuin talon remontti ilman suunnitelmaa. Jokaisen huoneen saa vielä viimeisteltyä, mutta ajan myötä käy ilmi, että seinät eivät ole siellä missä niiden pitäisi olla, putkistot on vedetty satunnaisesti ja uudistus muuttuu yhä kalliimmaksi.
Milloin kannattaa sanoa "stop"?
Yksi vaikeimmista hetkistä yrityksen omistajalle on päätös lopettaa yhteistyö tähän asti olleen toimittajan kanssa. Monet yrittäjät lykkäävät tätä päätöstä liian pitkään.
Miksi?
Koska projekti on jo syönyt paljon rahaa.
Koska aika on hukkaan.
Koska ehkä "se vielä onnistuu".
Psykologia kutsuu tätä uponneiden kustannusten ilmiöksi. Mitä enemmän olemme jo investoineet, sitä vaikeampaa on myöntää, että nykyinen suunta ei vie minnekään.
Silloin tällöin paras päätös ei ole lisätä budjettia samaan ongelmaan, vaan pysäyttää projekti ja analysoida tilanne rauhassa.
Voiko joka projektin pelastaa?
Ei. – Ja on syytä sanoa se rehellisesti.
On projekteja, joiden korjaaminen maksaisi enemmän kuin niiden uudelleenrakentaminen. Tapahtuu myös, että käytetty teknologia on jo vanhentunutta tai arkkitehtuuri on suunniteltu siten, ettei jatkokehitys ole mahdollista.
Siksi ensimmäinen askel ei koskaan saisi olla lupauksien antaminen.
Ensimmäisenä pitäisi tehdä auditointi.
Vasta kun koodi, dokumentaatio, infrastruktuuri ja prosessit on analysoitu huolellisesti, voidaan vastata siihen, kannattaako olemassa olevaa ratkaisua korjata vai aloittaa uusi projekti.
Hyvä teknologiakumppani ei sano sitä, mitä asiakas haluaa kuulla.
Se sanoo sen, mikä on asiakkaan kannalta parhaaksi liiketoiminnallisesti.
Miltä projektin pelastaminen näyttää käytännössä?
Yllättävää kyllä, se ei ala ohjelmoinnilla.
Ensin on ymmärrettävä, mitä käsillä on.
Me analysoimme järjestelmän arkkitehtuurin, koodin laadun, moduulien välisen viestinnän tavat, datan turvallisuuden, suorituskyvyn ja jatkokehitysmahdollisuudet. Tarkistamme dokumentaation, muutoshistorian ja käytetyt teknologiat. Usein jo muutaman päivän jälkeen tiedämme, missä varsinainen ongelma sijaitsee.
Vasta sen jälkeen laaditaan toimintasuunnitelma.
Joskus riittää koodin järjestäminen ja muutamien keskeisten elementtien korjaaminen. Toisinaan on tarpeen uudistaa valittuja moduuleja. Joskus järkevin ratkaisu on rakentaa uusi järjestelmä hyödyntäen sitä, mitä on jo saavutettu.
Ei ole kahta identtistä projektia.
Samoin ei ole yhtä reseptiä niiden pelastamiseksi.
Miksi projektin ottaminen haltuun on vaikeampaa kuin uuden rakentaminen?
Asiakkaat kysyvät usein tätä.
Vastaus on yksinkertainen.
Kun rakennamme järjestelmän alusta alkaen, tiedämme jokaisen suunnittelupäätöksen. Tiedämme, miksi tietty ratkaisu valittiin ja mitä oletettiin.
Ottaessamme jonkun toisen projektin haltuun meidän pitää ensin palauttaa tuo tieto.
Se on vähän kuin ottaa vastaan talon rakentaminen ryhmältä, joka jätti työmaan ilman suunnitelmia, dokumentaatiota ja tietoa siitä, mitä on tehty.
Siksi projektien pelastaminen vaatii paitsi ohjelmointitaitoja myös arkkitehtonista, analyyttista ja suunnittelukokemusta.
Teknologiakumppanin tulisi olla kanssasi myös silloin, kun ongelmia ilmenee
Hyvä software house ei mitata arvoaan vain sillä, miten projekti aloitetaan.
Arvo mitataan sillä, miten se reagoi, kun vaikeuksia ilmenee.
Kaikkea ei voi ennakoida. Liiketoimintavaatimukset, teknologiat ja käyttäjien tarpeet muuttuvat. Keskeistä on kuitenkin se, osaako tiimi löytää ratkaisun, viestiä riskit selkeästi ja tehdä yhdessä asiakkaan kanssa parhaat päätökset.
Juuri silloin luottamus rakentuu.
Miten työskentelemme Web24:ssä?
Olemme hyvin varovaisia projekteissa, jotka vaativat vastaanottoa tai haltuunottoa.
Emme anna lupauksia ensimmäisen keskustelun jälkeen.
Ensiksi analysoimme tilanteen. Tarkistamme, mitä on tehty, mitä voidaan hyödyntää ja mitä täytyy rakentaa uudelleen. Vasta sen jälkeen laadimme suosituksen ja suunnitelman jatkotoimille.
Tavoitteemme ei ole kirjoittaa seuraavia tuhansia rivejä koodia.
Tavoitteemme on saada projekti siihen pisteeseen, että se alkaa aidosti tukea liiketoiminnan kasvua.
Yhteenveto
Jos projektisi on jumiutunut, toimittaja lakannut vastaamasta, aikataulu on olemassa enää teoriassa ja seuraavat korjaukset tuottavat lisää virheitä, se ei vielä tarkoita, että kaikki olisi menetetty.
Monissa tapauksissa ongelma voidaan ratkaista.
Mutta pitää aloittaa yhdellä askeleella – perusteellisella tilanteen analyysillä.
Sillä ennen kuin alat pelastaa projektia, kannattaa ensin selvittää, miksi se alkoi upota.
