Projektinhallintakonsultti Minna Hanhikorpi aloittaa vaatimusmäärittelykolumninsa tiedustelemalla havaintoja liian tarkoin määritellyistä projekteista. Valitettavasti keskustelu on ollut tauolla. Muuten Minna olisi varmasti saanut kasoittain vastauksia.
Otetaan esimerkiksi liian tarkasta määrittelystä kuvitteellinen verkkokauppaprojekti. Innokas projektipäällikkö selvittää asiakkaalta, minkälaisia ominaisuuksia rakennettavaan palveluun pitäisi tulla. Ominaisuudet kirjataan formaaliin ja virallisen näköiseen dokumenttiin, jossa asiakkaan laveat selostukset esitetään tiiviisti ja yksiselitteisesti. Dokumenttiin tulee 38 sivua kapulakieltä, jota asiakas ei jaksa edes lukea. Asiakas kuitenkin luottaa projektipäällikköön ja sanoo: "Juuri tällaisen me haluamme". Tyytyväinen projektipäällikkö kutsuu koolle AD:n ja ohjelmoijan kertoen: "tällainen pitäisi tehdä, aikaa on kuusi viikkoa".
Kuka pitää yhteyttä asiakkaaseen?
Vaikka toteutustiimikin olisi käynyt projektinhallintakonsultin kurssilla ja määrittelydokumentin sanasto olisi heille tuttua, tulee jossakin vaiheessa kuitenkin tarvetta kysyä jotakin. Ensin kysytään tietenkin projektipäälliköltä. Jos hyvin käy, projektipäällikkö ohjaa toteuttajan ottamaan suoraan yhteyttä asiakkaaseen. Kysymykseen saadaan nopeasti selväkielinen vastaus. Projektipäällikkö pidetään ajan tasalla, mutta keskustelu käydään suoraan kysyjän ja vastaajan välillä. Viestintää hankaloitetaan turhaan, jos projektipäällikkö ottaa yhteyttä asiakkaaseen, kysyy kysymyksen omalla projektinhallintajargonillaan ja höylää asiakkaan vastaukset sovitun muutostenhallintaprotokollan läpi.
Pahimmassa tapauksessa vastaus löytyy jo vaatimusmäärittelystä. Esimerkiksi verkkokauppaa määriteltäessä on sovittu, että jokainen tuote kuuluu tasan yhteen tuoteryhmään. Kysymyksiä ei tarvitse esittää; palvelu rakennetaan aikataulussa. Järjestelmän pilotointikin sujuu mutkattomasti, ja vasta käyttöönoton jälkeen asiakas soittaa ja kertoo, että autostereot pitäisi saada näkyviin sekä hifilaitteissa että autotarvikkeissa. Pieni muutos, paljonko maksaa ja kauanko kestää?
Tietokantaan pitää lisätä yksi taulu. Kaikki SQL-kyselyt menevät samalla uusiksi. Tuotteiden ylläpitokäyttöliittymä pitää suunnitella uudelleen. Ja koska muutoksia tulee sinne tänne, kaikki pitää taas testata kattavasti. Pienelle muutokselle tulee hintaa puolet verkkokaupan alkuperäisestä hinnasta.
Kaikkea ei voi aina kirjata etukäteen
Verkkokauppa on esimerkkinä siksi huono, että kaikki ovat nähneet niistä hyviä ja huonoja toteutuksia, ja niiden toiminta on helppo ymmärtää. Esimerkin mukaiset ongelmat ovat hankalampia, kun tehdään asiakkaan omaa toimialaa palvelevaa sovellusta. Innokkaalla projektipäälliköllä ei ole määrittelyn aikana aikaa perehtyä asiakkaan tarpeisiin riittävästi pystyäkseen varautumaan kaikkiin yllä olevan esimerkin kaltaisiin tilanteisiin. Kaikkien asiakkaan prosessien sisäistämiseen menisi vuosia, ja projektipäällikön tunnitkin pitäisi laskuttaa.
Vaatimusmäärittelyssä ei aina voida ottaa kaikkea huomioon. Kaikille Hanhikorven vertauskuvallisille taloille ei voi rakentaa ensin kivijalkaa. Jos kivijalka on valettu ja seinät muurattu, erkkerin tai uuden makuuhuoneen lisääminen on toivottoman kallista. (Sitä paitsi nakkikioskia rakennettaessa kivijalka on usein turhan jykevä). Onneksi verkkopalvelut eivät ole taloja, eikä niitä tarvitse rakentaa vesiputousmallin mukaisesti.
Vaihtoehtoisia tapoja
Joissakin projekteissa ja joidenkin asiakkaiden kanssa parhaisiin tuloksiin päästään, kun ensin pyöritellään pelkkiä staattisia HTML-sivuja, joilla pyritään simuloimaan rakennettavaa palvelua. HTML:n muokkaus on helppoa ja halpaa, ja kaikkea on mahdollista muuttaa.
Joskus paras lähestymistapa on inkrementaalinen kehitysmalli. Selvitetään asiakkaalta vain, mitkä ovat järjestelmässä kaikkein tärkeimmät elementit ja niiden väliset suhteet. Tehdään näiden tietojen perusteella tietokanta ja pari skriptiä, joihin toteutetaan vain olennaisin toiminnallisuus. Kysytään asiakkaalta, ollaanko oikeilla jäljillä, ja mitkä ovat seuraavaksi tärkeimpiä asioita.
Näissäkin toteutustavoissa on omat ongelmansa. HTML-sivujen ulkoasun hiomiseen voi kulua viikkoja, kun asiakas ei oikein osaa päättää, olisiko otsikko parempi punaisena vai oranssina. Kerroksittain kehittyvä palvelu voi kasvaa käsittämättömäksi spagettikeräksi. Toisaalta asiantuntevat AD:t ja käyttöliittymäsuunnittelijat osaavat tehdä perusteltuja ehdotuksia ja hyvä visu syntyy nopeasti. Taitava ohjelmoija pitää koodinsa kurissa. Jokainen ammattilainen saa keskittyä siihen, missä itse on paras.
Lapio tai lusikka tarpeen mukaan
Hanhikorpi arvelee, että hyvin määritellystä projektista saattaa tulla sellainen kuin pitikin. Siihen on helppo yhtyä. Eri mieltä Minnan kanssa olen siinä, että hyvin määritelty olisi aina tarkasti määritelty. Uusmedia-alalla varmasti moni on ollut mukana projekteissa, joissa määrittely on ollut seuraavan tyylinen: "Tarvittaisiin kampanjasaitti tuotteelle hilavitkutin, launch 1.9. Mukaan joku kiva peli." Kyseessä on vanha tuttu asiakas, joka luottaa toimittajaan. Ideoidaan, tehdään ehdotus, näytetään sitä asiakkaalle, asiakas on innoissaan, saitti julkaistaan. Kaikki kiittelevät, miten tästäkin selvittiin nopeasti, edullisesti ja ilman rasittavaa byrokratiaa.
Erilaisia verkkoprojekteja toteuttavalla yrityksellä pitäisi olla valmiudet toimia joustavasti, vaikkapa kolmen eri projektimallin mukaisesti. Projektipäällikön ammattitaitoon kuuluisi asiakkaan ja projektin esitietojen perusteella päättää, millä menetelmällä kyseinen projekti saadaan hoidettua tehokkaimmin. Joskus paras tapa on protoilu, joskus XP, usein vesiputousmalli.