Monesti asiakkaan mielestä projektipäällikkö on firman tyhmin jätkä. Hän ei ole joustava, ei ota kuuleviin korviinsa uusia ehdotuksia ja on luotaantyöntävä. Miksihän näin on?
Yleensä asiakkaalta tulevat muutokset ovat pieniä muutoksia. Ainakin heidän omasta mielestään. Mitä muutoksen käsittely tarkoittaa projektille?
Ensinnäkin kutsuu paluu suunnittelupöydän ääreen. Pitää tarkistaa että uusi idea ei ole ristiriidoissa vanhojen kanssa. Seuraavaksi suunnitellaan toteutus ja aikataulutetaan se. Lopulta uusi idea toteutetaan ja testataan. Pitää tarkistaa, onko järjestelmä edelleen yhtenäinen ja vakaa. Jos näin on, on uusi idea saatu vietyä ohjelmistoon.
Samaan aikaan asiakas haluaa pitää kiinni alussa sovituista (IT-alalla todennäköisesti hyvin tiukoista) aikatauluista. Lisää rahaa ei haluta maksaa. Projektin myöhästymisestä sakotetaan. Samalla kuitenkin jo pelkkä ehdotus viivästyttää projektia. Projektipäällikkö joutuu asettamaan jonkun tutkimaan (tai tutkimaan itse), voidaanko uusi ominaisuus toteuttaa. Vaikka toteutukselle löytyisi este ja sitä ei toteutettaisi, aikaa on silti mennyt hukkaan.
Entä jos ajan säästämiseksi nopeutetaan hieman suunnittelua. Tehdään vanhojen ratkaisuiden pohjalta ja säästetään näin aikaa. Se saattaa oikeasti toimia ja ohjelmisto valmistuu aikataulussa sopimuksen mukaan. Jos kyseessä on asiakkaalle räätälöity ohjelmisto, on sopimukseen todennäköisesti kirjattu myös ylläpito. Ohjelmiston elinkaaressa ylläpitoon kohdistuvat kulut ovat noin 67% koko kuluista. Eli suurimman laskun asiakas saa ylläpidosta. Tätä ei yleensä käsitetä.
Ylläpitovaiheessa löydetyt virheet ja korjaukset maksavat 4-10 kertaa enemmän, kuin kehitysaikana tehdyt korjaukset tai parempi suunnittelu (yleensäkin ajan kulutus). Vertauskuvana voidaan pitää kerrostaloa, jonka alimman kerroksen seinät on rakennettu huonosti ja ne pitää uusia. Projekti tulee olemaan todella massiivinen.
Vaikka projektipäällikkö ennen kaikkea on huolissaan omasta projektista, niin hän silti pitää myös asiakkaan puolta. Kun ohjelmoija kirjoittaa hyvää ja ylläpidon kannalta mietittyä koodia, säästöt ylläpitopuolella kompensoivat mahdolliset menetykset kehitysaikana nopeasti.
Nyrkkisääntönä voidaan pitää, että mitä aikaisemmin ohjelmistokehitysprosessissa säästetään aikaa, sitä enemmän se lopulta maksaa. Esimerkkinä voidaan ottaa Denverin lentokentän matkatavarankäsittelyjärjestelmä, joka budjetoitiin olevan 200 miljoonan dollarin projekti. Laatujärjestelmän puuttuessa ja suunnitteluvirheiden takia projekti myöhästyi aikataulusta 16 kuukautta ja maksoi asiakkaalle 3 miljardia dollaria yli budjetin. Syyllisten haku on tietenkin vähän turhaa, mutta asiakkaan lisäksi ongelmia lienee aiheuttanut kehittymättömät ohjelmistotuotantoprosessit, suurien projektien hallinan vaikeus ja ehkä ihan yksilötasolla tehdyt virheet.
Vaikka tarinastani voisi saada sellaisen kuvan, että asiakas on softafirman pahin vastustaja, niin ei kuitenkaan ole. Ennen kaikkea peräänkuulutan myös asiakkaan ammattitaitoa. Jos kyseessä on edes hieman pikku projektia isompi, suosittelen lämpimästi ulkoisen avun käyttöä ohjelmiston tilaamisessa. Halvin tarjous ei ole välttämättä paras ja tiukimman työaika-arvion esittäjä ei välttämättä toteuta ratkaisua nopeiten. Konsultin palkkio on kuin karkkiraha siihen verrattuna, että joudutaan kuukausien ja kuukausien viivästyksiin.
! Teen kandityötä ohjelmistotuotantoprosessien soveltamisesta pienyrityksiin. Kirjoitan blogiin työhön liittyviä (mutta ei välttämättä kuuluvia) mietintöjä.
.jpg)