Käyttäjien pitäisi pystyä testaamaan kaikki välitulokset koko hankkeen elinkaaren ajan. #
Asiakkaita kehotetaan määrittelemään tarpeensa mahdollisimman tarkasti koko määrittely- ja suunnitteluvaiheen ajan. Tämä on haastavaa kahdesta syystä. Ensinnäkin kuluttajilla on rajallinen käsitys tietotekniikan mahdollisuuksista ja mahdottomuksista. Heillä ei ole käsitystä siitä, mikä on tai pitäisi olla mahdollista, eivätkä he tiedä, mitä heidän pitäisi tai ei pitäisi haluta. Toiseksi kuluttajilta puuttuu usein perusteellinen ymmärrys omista liiketoimintaprosesseistaan.
Lukuisiin IT-hankkeisiin kuuluu organisaation nykyisten liiketoimintaprosessien tietokoneistaminen. Vaikka kuluttajat ovat työskennelleet prosessien parissa pitkään, heiltä puuttuu usein kyky suunnitella omia liiketoimintaprosessejaan. Ne voivat toimia hyvin omalla tavallaan, mutta eivät voi määritellä, mikä se on. Prosessin tarkka määrittely vaaditaan ennen kuin kehitetään tietokoneistumista ohjaavia ohjelmistoja. Asiakkaiden monimutkaisuus kasvaa, kun joudutaan selittämään nykyisiä menettelytapoja.
Kriteerien määrittely #
Määrittelyvaiheessa laadittu kriteeriluettelo on usein epätäydellinen. Ohjelmoijat luovat ohjelmiston tämän osaluettelon mukaisesti toteutusvaiheessa. Kun kuluttajat kohtaavat uusien ohjelmistojen beta-versiot, ylimääräiset tarpeet tulevat ilmeisiksi. ”Se näyttää hyvältä, mutta voisitko ehkä korjata sen, jotta minun ei tarvitse jatkuvasti syöttää salasanaani?” Ohjelmoijat valittavat usein, että asiakkaat eivät ole varmoja siitä, mitä he haluavat. Asiakkaat väittävät, että ohjelmistokehittäjien olisi asiantuntijoina pitänyt tunnistaa asiakkaiden toiveet jo aikaisemmin.
Ohjelmistoprojektiin luotiin kattava toiminnallinen suunnittelu, joka sisälsi hakemusten automatisoinnin verkkopohjaiseen palveluun. Useita asiakastarpeita koottiin. Lisättyään muutamia näyttömalleja ja virtauspiirroksia ohjelmoijat voivat aloittaa.
Asiakkaiden ja rajoitusten hallinta #
Mahdollisesti projektin ankarista aikarajoituksista tai mahdollisesti asiakkaan melko kaoottisesta organisaatiosta johtuen suunnittelijat olivat unohtaneet koostua kriittisestä osasta: manuaalisesta hallinnasta. Ohjelma käsitteli hakemukset. Koska hakemukset oli tarkoitus käsitellä automaattisesti, ohjelmoijat päättelivät, ettei ihmishallintoa tarvita. Tämä kriteeri jätettiin myös pois toiminnallisesta suunnittelusta.
Kun ohjelma toimitettiin testattavaksi, asiakas huomasi, että monissa sovelluksissa oli poikkeuksia. Näitä hakemuksia ei voida käsitellä automaattisesti, vaan ne on käsiteltävä manuaalisesti. Ohjelma toimi kuitenkin täysin automaattisesti.
The vesiputousprojektin hallinta edellyttää hankkeen todellisen tuloksen testaamista toteutusvaiheen lopussa. Tämä on myöhäistä kehitysvaiheessa . Määrittelyvaiheen, suunnitteluvaiheen ja toteutusvaiheen välillä voi kulua kuukausia tai jopa yli vuosi. Jos suunnitteluvirheitä havaitaan projektin myöhäisessä vaiheessa, voi olla kallista, ellei mahdotonta, ohjelman muuttaminen aloittamatta kokonaan uutta projektia. Koska kaikkia kriteerejä on käytännössä mahdotonta määritellä etukäteen, on toivottavaa käyttää työskentelytapaa, joka mahdollistaa (väli)tulosten testaamisen.
Vaatimusten analysointi #
Verrattaessa useita potentiaalisia ohjelmistoyrityksiä, asiakas tiedusteli mahdollisuuksia. Yksi osapuoli epäröi ja kyseenalaisti monien asiakkaan vaatimusten toteutettavuuden. Vastapuolta edusti aggressiivinen myyntiedustaja.
Kun asiakas tiedusteli tietyn pyynnön toteutettavuudesta, myyjä soitti koodaajilleen. ’Voimmeko luoda funktion, joka tekee X:n?’ Ohjelmoija, joka ajatteli pääasiassa teknisiä termejä, sanoi, että kaikki oli teoreettisesti ajateltavissa. Ohjelmoija tai myyjä eivät olleet huolissaan projektinhallinta toteutettavuus (esim. aika, raha, monimutkaisuus ja riski).
Myyjän innostus ylitti toisen osapuolen hillityn käytöksen. Asiakas valitsi myyjän aggressiivisen tarjouksen. Hiljattain hankittu projekti luovutettiin sitten projektipäällikölle ja ohjelmoijatiimille.
Jonkin ajan kuluttua kävi selväksi, että projekti ei vastannut asiakkaan odotuksia. Tämä johtui osittain siitä, että menettelyt olivat asiakkaalle paljon monimutkaisempia kuin alun perin näytti. Osapuolten välisen kiihkeän keskustelun aikana asiakas sanoi, että myyjä ”oli todennut, että toiminnallisuus X ei olisi ongelma.
