FBI:n kallis tietokoneohjelmisto suoraan roskikseen

Kieltämättä jos budjetin ylittyminen olisi merkki epäonnistumisesta, suurin osa ohjelmistoprojekteista olisi epäonnistuneita. Kyllä moninkertaista budjetin ylitystä voi silti pitää jonkinlaisen epäonnistumisena, koska silloin ei ole osattu määritellä asiakasvaatimuksia tai suunniteltua työnmäärää oikein. Niin ja tosiaan, epäonnistuminen on tasan tarkkaan sitä, miten se määritellään. Jos budjetin ylittyminen moninkertaisesti on mielestäsi normaalia, muista mainita se asiakkaalle, jolle myyt palveluasi/sovellustasi.

Niin miksihän ne budjetit niin usein ylitetään? Huonosti tunnetut asiakasvaatimukset ja testaukseen vaaditun ajan aliarvioiminen ovat varmasti usein syynä, mutta usein syynä on liian kova ja epärealistinen hintakilpailu. John Ruskin oli epäilemättä oikeassa, kun hän sanoi "There is hardly anything in the world that somebody cannot make a little worse and sell a little cheaper, and the people who consider price only are this person's lawful prey."

Eräs kyltti amerikkalaisen tulostusliikkeen edessä havainnoi hyvin myös ohjelmistoalan ( tai minkä tahansa alan) realiteetteja:

HINTA
LAATU
PALVELU
(valitse mitkä tahansa kaksi ylempää).

Moni huonosti toteutettu projekti on lähtenyt niin epärealistisella suunnittelulla liikkeelle, että olemassa olevasta ohjelmasta ja dokumentaatiosta on ohjelman valmiiksi saamisen kannalta enemmän haittaa kuin hyötyä. SIlloin projekti voisi olla halvempaa aloittaa alusta. Tämä pätee usein myös pitkittyneihin graduihin, liian laaja aihe ja materiaali voi hidastaa valmistumista, vaikka gradua olisi kirjoittanut jo puoliväliin. Tosin huonoja graduja hyväksytään jatkuvasti, kun taas huono ohjelma ei välttämättä toimi.

Niin ja jos määrittelit tehtävän väärin, ratkaisusi voi olla väärä. Aloita alusta.

Tuo on ihan totta. Asiakasvaatimusten huono määrittely johtaa aina huonoon ohjelmistoon.

"Pulauttaminen formaatista toiseen" voi olla ongelma jos koko ohjelmisto perustuu tiedon välittämiseen ja hallintaan. Se ei varmastikaan ole riittävä ongelma koko projektin hylkäämiseen, mutta en minä niin alunperin väittänytkään.

Siksi speksit pitää olla kunnossa: vaatimusmäärittelyt, arkkitehtuurikuvaukset, funktionaaliset kuvaukset, testispeksit jne. ja jokainen speksi pitää olla sekä softantekijän tarkastamia (tiimissä luetaan läpi tms) ja niissä pitää olla myös asiakkaan allekirjoitus, ennen kuin ensimmäistäkään koodiriviä suolletaan ulos. Tämän jälkeen vaatimusmäärittelynmuutokset hinnoitellaankin sitten tuntiveloituksena.