Vesiputoustekniikka on jaettu vaiheisiin. Projektijohtajien on sisällytettävä projektisuunnitelmiinsa arviot kunkin vaiheen vaatimasta ajasta (ja siten rahasta). Olemme aiemmin todenneet, että aika-arviot ovat luonnostaan ongelmallisia kaikissa projekteissa, varsinkin silloin, kun ne on asetettava projektin varhaisessa vaiheessa. Se ei vain ole mahdollista ohjelmistoprojekteissa. Harkitse mahdollisuutta, että määrittelyvaiheessa voidaan laatia laadullisesti hyväksyttävä luettelo ominaisuuksista. Periaatteessa tämän pitäisi antaa projektiryhmälle mahdollisuus antaa realistinen arvio kunkin ominaisuuden kehittämiseen tarvittavasta ajasta. Todellisuudessa on kuitenkin liian paljon epävarmuustekijöitä, jotta voidaan antaa reilu arvio:
Todellisuudessa on kuitenkin liian paljon epävarmuustekijöitä, jotta voidaan antaa reilu arvio:
- Usein havaitaan ominaisuuden kehittämisen jälkeen, että asiakas ei tarvitse sitä. Näin ollen tämän ominaisuuden kehittämiseen käytettyjä tunteja voidaan harkita turhaksi.
- Vaatimukset voivat muuttua projektin aikana.
- Pitäisikö ominaisuus tarjota korkealla vai alhaisella hinnalla? Toteutus- ja toteutustekniikoita on monia.
- Miten toiminnallisuus suunnitellaan teknisesti? Suunnittelu vaikuttaa suuresti sen luomiseen kuluvaan aikaan.
- Missä määrin toiminnan tulee olla korkeatasoista? Pitäisikö verkkosovellus esimerkiksi olla täysin käytettävissä koko ajan vai pitäisikö sen olla poissa käytöstä muutaman tunnin vuodessa?
- Ohjelmistoongelmien havaitsemiseen ja korjaamiseen tarvittava aika vaihtelee minuuteista viikkoihin.
- Kuinka kauan uuden ohjelmiston asentaminen ja integrointi asiakkaan nykyisiin järjestelmiin kestää?
- Tiedon puute mahdollisista ratkaisuista vaikuttaa entisestään aika-arvioihin. Lisäksi tarvittavan asiantuntemuksen hankkimiseen tarvittavan ajan arvioiminen on haastavaa.
Yllä oleva luettelo osoittaa, että useat muuttujat voivat vaikuttaa uuden ohjelmiston kehittämiseen tarvittavaan aikaan. Arviot ominaisuuden kehittämiseen kuluvasta ajasta projektin alussa ovat usein neljä kertaa liian pienet tai neljä kertaa liian korkeat. Tämä tarkoittaa, että tarvittava aika voi olla neljä kertaa enemmän tai neljä kertaa vähemmän kuin virheellinen arvio. Hankkeen edetessä nämä arviot tarkentuvat. Toiminnallisen suunnittelun valmistuttua marginaalia pienennetään 25 %:iin liikaa tai liian vähän. Vasta kun ominaisuus on kehitetty, on mahdollista antaa arvio suurella varmuudella.
Ohjelmistoriskit #
Projektinhallintaohjelmisto ei koskaan ole täysin virheetöntä. Jopa tunnetuille ohjelmille, joita käytetään laajalti (esim. Word, Excel, Explorer, OS X, PHP ja Flash), Internetissä on luettelo tunnetuista puutteista. Säännöllisesti markkinoille tuodaan uusia versioita, jotka korjaavat ohjelmistovirheitä. Asiakkaat vaativat joskus ohjelmiston olevan virheetön. Todellisuudessa tällainen tavoite kuitenkin tekisi ohjelmiston valmistumisesta mahdotonta. Lisäksi ohjelmistovirheet eivät useinkaan liity ohjelmaan.
Flashia käytettiin opetuspelin luomiseen. Asiakas suostui hankkimaan pelin tiedostona ja asentamaan sen omalle palvelimelleen. Projektin aikana tilaaja pyysi, että peliin lisättäisiin huippupisteominaisuus parantaakseen pelaajien kilpailukykyä. Tämä vaatisi PHP-skriptikoodin. Pelin kehittäjät kehittivät ja testasivat komentosarjakoodia omalla Linux-palvelimellaan. Se onnistui. Asiakas sai pelin ja käsikirjoituskoodin. Asiakas kuitenkin käytti Windows-palvelinta, ja jostain syystä komentosarja lakkasi toimimasta kunnolla. Parhaita arvosanoja ei säilytetty. Ohjelmoija tarvitsee lopulta viikon korjatakseen ongelman. Kuten käy ilmi, PHP ja Windows eivät aina toimi hyvin yhdessä. Käsikirjoituksessa ei kokonaisuudessaan ollut virheitä! Hän sai sen toimimaan hakkerin avulla, ja kaikki olivat tyytyväisiä – mutta kenen pitäisi maksaa tuo ylimääräinen työviikko?
Toinen ohjelmistokehitysprojekti sisälsi myös opetussovellusten luomisen. Ongelmana oli, että ohjelmisto toimi hyvin kehittäjille, mutta ei hyvä asiakkaalle. Kun kaikki muut mahdollisuudet oli käytetty, ohjelmoija päätti käydä asiakkaan luona. Kuten kävi ilmi, asiakas käytti Pentium III -konetta 1990-luvun alusta. Tietokoneen hitaus vaikutti ohjelmiston huonoon suorituskykyyn. Lisäksi ohjelmoijat kokeilivat ohjelmistoa Pentium III:ssa, ja se toimi hyvin. Lisätutkimukset osoittivat, että asiakkaan tietokone toimi hitaasti virus- ja vakoiluohjelmatartunnan vuoksi.
Hankekehityksen epävarmuustekijöiden hallinta #
Yllä olevien tapausten osoittama epävarmuus vaikeuttaa prosessia projektisuunnitelmien kehittäminen . Lisäksi se vaikeuttaa osapuolten välisiä neuvotteluja. Jonkun on kannettava tehtävään lisätyöhön liittyvät riskit. Jos maksu suoritetaan tuntikohtaisesti, asiakas kantaa kaiken riskin. Kun sovitaan kiinteästä maksusta (kuten apuraharahoitteisten hankkeiden tapauksessa), ohjelmistokehittäjä kantaa riskin. Kun mukana on enemmän kuin kaksi henkilöä, tilanne muuttuu monimutkaisemmaksi. Kenen pitäisi tässä skenaariossa vastata projektin parissa työstetyistä lisätuneista?
Usein syntyy kiistoja siitä, kenen pitäisi olla vastuussa viivästyksistä. Vastuuhenkilöä on usein vaikea tunnistaa. On täysin mahdollista, että kukaan osapuolista ei ole syyllinen, koska ”viivästyminen” johtui virheellisestä alustavasta arviosta tarvittavien tuntien määrästä. Liialliset projektitunnit ja kysymys siitä, kenen pitäisi maksaa, ovat yleisiä kiistan syitä tietotekniikka-alalla.
