Ominaisuus kerrallaan

Aloitimme huhtikuun alussa uuden projektin meille melko uudella alustalla. Projektin aluksi kävimme kaksintaistelun pääsuunnittelija Olli Raivolan kanssa siitä, mistä meidän tulisi lähteä liikkeelle.

Itse kannatin ehdottomasti käyttöliittymän kehitystä ensimmäiseksi kokonaisuudessaan. Koin sen meidän heikkoudeksi uudella alustalla ja uskoin, että alla piilevä logiikka – syötteen parsinta, tietokanta jne. – ovat peruskauraa tiimille.

Olli taas halusi lähteä pohjalta liikkeelle, koska uskoi keskustelun siirtyvän polkupyöräsuojan kattomateriaaliin. Lisäksi hän pelkäsi minun sekä asiakkaan saavan väärän kuvan edistymisestä, kun käyttöliittymä olisi valmiina.

Ja niinhän siinä kävi. Kun käyttöliittymä oli valmis aloin itse tiedustella ensimmäiseksi suunnittelijoita uusiin projekteihin. Asiakkaan fokus siirtyi pikselin viilaukseen, kun olisi voitu vielä hioa toiminnallisuuttakin.

Toisin sanoen syntyi harhakuva projektin edistymisestä ja jäljellä olevasta työmäärästä. Tiimi tosin taisi tietää koko ajan missä mennään.

Kumpi siis oli oikeassa? Ainakin itse olin väärässä, mutta Olisiko Ollin taktiikka tuonut paremman lopputuloksen?

Todellisuudessa molemmat taisi olla väärässä. Oikea lähestymistapa olisi ollut tehdä sovellus valmiiksi ominaisuus kerrallaan. Ensimmäisenä esimerkiksi yhden viestin parsiminen syötteestä, tallentaminen tietokantaan ja piirtäminen ruudulle. Tällöin edistyminen olisi ollut läpinäkyvää ja fokus olisi säilynyt jokaisen ominaisuuden hiomisessa huippuunsa kerrallaan.

Jarkko Järvenpää

Jarkko Järvenpää

6 kommenttia

Antti Virtanen sanoo:

Pidän ihan pätevänä lähestymistapana sitä että ensin tehdään yksi ominaisuus tai toiminto vertikaalisesti “päästä päähän” siten että kaikki sovelluksen olennaiset tekniset palat ovat mukana.

Valittu arkkitehtuuri ja teknologiastack on näin testattu ainakin kursorisesti heti alussa. Samoin projektin prosessi (suunnittelu, palaverit, toimitukset jne.) on koeponnistettu.

Sovelluksen kerrokset ovat nyt olemassa, joten niistä voi laajentaa horisontaalisesti seuraavaksi sitä johon keskittyminen on juuri kyseisessä projektissa järkevintä.

Asiakas on saanut heti alussa jotain näkyvää toiminnallisuutta, mikä lisää kaikkien osallisten luottamusta tehtyihin teknisiin ratkaisuihin ja prosessin liittyviin valintoihin.

Balsamiq rockaa jep.

(Tästä aiheesta voisi sanoa paljon enemmänkin.)

Molemmissa lähestymistavoissa on omat ongelmansa:

Jos projektia lähdetään toteuttamaan käyttöliittymän päästä, asiakkaalle (mutta myös toteuttavalle osapuolelle) saattaa syntyä harhaanjohtava kuva projektin valmiusasteesta. Tämä puolestaan saattaa aiheuttaa viestinnällisiä haasteita sekä asiakkaan että toteutusporukan suuntaan. Asiakkaalle on pystyttävä viestimään, miksi laskuja tipahtelee säännölliseen tahtiin, vaikka projekti “näyttää” olevan valmis. Toisaalta on motivoitava projektitiimiä, jotta perusteeton hyvänolon tunne ei pääse iskemään, vaan projektissa säilyy ns. tekemisen meininki. Lisäksi tässä lähestymistavassa joudutaan tekemään ylimääräistä työtä, jotta käyttöliittymä saadaan toimimaan ja siinä voidaan näyttää mielekästä informaatiota.

Toisaalta jos projektia lähdetään toteuttamaan alhaalta ylöspäin, asiakkaan sitouttaminen projektiin ja palautteen saaminen on hieman ongelmallista. Asiakas kun useimmiten näkee projektista vain sen käyttöliittymän. Tässä vaihtoehdossa sovelluksen toimintoja ja käyttöliittymää koskeva palaute saadaan asiakkaalta kovin myöhään, jolloin riskinä on, että valmistuva sovellus ei vastaakaan asiakkaan tarpeita (varsinkin mikäli projektilla on aikataulupaineita tai projektiin varattu budjetti on ylittymässä).

Olitkin Jarkko tullut siihen tulokseen, että tämä projekti olisi kannattanut toteuttaa toiminto kerrallaan. Vaikka joissakin tilanteissa jompi kumpi kirjoituksessa esitellyistä lähestymistavoista voi olla ihan toimiva, kannatan itse nimenomaan tätä lähestymistapaa. Tässä lähestymistavassa on se etu, että projektitiimi voi reagoida asiakkaan palautteeseen nopeasti, jolloin asiakkaan saama hyöty saadaan maksimoitua. Lisäksi tämä lähestymistapa myös mahdollistaa sen, että arkkitehtuurin toimivuudesta voidaan varmistua kohtuullisessa ajassa.

En tiedä, käytettiinkö tämän projektin toteutuksissa ketteriä menetelmiä, mutta ketterässä projektissa tuon lähestymistavan puolesta puhuu sekin, että jokaisen sprintin lopputuloksena tulee syntyä toimiva ja “julkaisukelpoinen” sovellus. Tässä tavoitteessahan ei ole kyse ihan pelkästä sanahelinästä, sillä ainakin itse arvostan asiakkaan luottamuksen kautta saavutettavan työrauhan aika isona juttuna. On huomattavasti helpompi tuottaa laadukkaita ohjelmistoja, kun ei tarvitse käyttää osaa työajasta asiakkaan/myyntimiehen lepyttelemiseen.

Hei Miku ja kiitos vinkistä.

Balsamiqia on meilläkin käytetty muutamassa projektissa ja se on hyvä työkalu ison kuvan suunnitteluun käyttöliittymän osalta.

Miku sanoo:

Yksi hyvä kikka tuossa käyttöliittymäasiassa olisi käyttää suunnitteluun softaa nimeltä balsamiq (http://balsamiq.com/). Ei, en ole kyseisen firman palkattu mainostaja, vaan lähinnä tyytyväinen (vaikkakin tuore) käyttäjä 🙂
Balsamiqia käytettäessä niin projektipäällikkö kuin asiakaskin tajuaa kyseessä olevan vain prototyyppi, eikä vielä intoile liikaa softan “valmistumista”. Itse varmaan suunnittelisin käyttöliittymät ensin balsamiqlla, jonka jälkeen toteuttaisin ominaisuuden kerrallaan (ja Kunnolla), ja rakentaisin käyttöliittymää tehdyn suunnitelman mukaisesti.

Jarkko Järvenpää sanoo:

Hei Jukkis ja kiitos kommentista.

Itse en koe, että tämä vaikuttaisi jotenkin ison kuvan unohtamiseen.

Artikkelini ei missään nimessä tarkoita sitä, että kokonaisuutta ei tulisi suunnitella esimerkiksi arkkitehtuurin tai käyttöliittymän näkökulmasta. Kyse on siitä kuinka iso kuva toteutetaan.

Mielestäni myös odotusten hallinta tässä kohtaa heikentää läpinäkyvyyttä, eikä näin ole eduksi projektille tai yhteistyölle.

Jukkis sanoo:

Niin. Ongelmahan on myös siinä, että tällä periaatteella ns. big picture unohtuu, jos ominaisuus tulee kerrallaan.

Ehkä kysymys on enemmän ns. expectation managementista asiakasta kohtaan, jonka hoitaminen tuntuu aina unohtuvan tai jäävän liian pienelle hoidolle.

Liity keskusteluun