Teksti perustuu Prochat-podcastin jaksoon, jossa Idention ohjelmistokehittäjät Sami Suo-Heikki ja Julius Rajala käyvät läpi sitä, miten ohjelmistoprojekti käynnistyy ja miten projektin alkuvaiheessa kannattaa yleensä toimia.
Kaikki projektit ovat tietysti omanlaisiaan, eikä niihin ole olemassa vain yhtä toimivaa mallia. Aihetta sivutaan sekä uuden projektin aloittamisen että meneillään olevaan projektiin hyppäämisen näkökulmista.
On alkamassa on uuden tuotteen kehittäminen eli Greenfield-projekti. Missä vaiheessa konsultti tulee projektiin mukaan?
Tilanne vaihtelee aika pitkälti asiakkaan preferenssien mukaan. Parhaimmillaan tilanne menee niin, että konsultti pääsee mukaan tekemiseen jo mahdollisimman aikaisessa vaiheessa. Silloin projekti on alusta asti yhdessä tekemistä. On tietysti hyvä, että asiakkaat määrittelevät aluksi vaatimukset ja jonkinlaisen kehyksen sille, mitä rakennetaan. Tässä vaiheessa konsultin voi tietysti ottaa jo mukaan. Monet konsultit tekevät palvelumuotoilua ja suunnittelua. Siinä vaiheessa lähdetään aidosti ratkaisemaan asiakkaan ongelmia.
Monet konsultit nauttivat tilanteesta, jossa osallistetaan mahdollisimman paljon ihmisiä jo projektin alkuvaiheessa. On hyvä, että kaikkien osaajien asiantuntemus on projektin käytettävissä jo mahdollisimman aikaisin. Jos lähdetään esimerkiksi graafikon toimesta taikomaan leiskoja bisnes edellä, mutta ei oteta mukaan teknisen osaajan näkemyksiä siitä mikä on mahdollista, niin toteutusvaiheeseen voi liittyä isojakin riskejä.
Googlella on loistavia työkaluja, kuten Design Sprint. Lähtökohtaisesti se on prosessi, jossa joukko projektin toteuttamiseen liittyviä henkilöitä toteuttaa prototyyppejä tai demoja jostain asiasta viikon ajan. Ideana on luoda raamit tekemiselle. Mukana tekemisessä on usein eri aihealueiden asiantuntijoita.
Miten kaivetaan esiin piilotetut vaatimukset?
Design sprint on yksi vaihtoehto tähän. Kun lähdetään projektiin mukaan, on todella tärkeää, että alkupää yhteistyöstä asiakkaan kanssa on intensiivistä työskentelyä. Projektin tai tuotteen onnistumiselle on olennaista kyky pystyä kaivamaan esiin erilaiset rajoitukset ja tarpeet sekä maali.
Meillä oli projektistartti, jossa naureskelimme sitä, että ensin käytiin läpi tekniset vaatimukset. Tämä tapahtui ennen kuin kävimme läpi korkeammalla tasolla sitä, mitä olimme edes rakentamassa. Se voi olla hieman huono lähestymistapa. On iso apu projektin onnistumiselle, jos toimintaympäristöstä saadaan kattava kuva mahdollisimman nopeasti
Hyviä kokemuksia vaatimusmäärittelystä
Identiolaisten kokemusten mukaan prototypointi on usein hyvä tapa aloittaa. Joskus bisneksen parissa työskentelevät henkilöt saattavat sanoa, että halutaan tietyn näköinen tuote. Se voi olla kuitenkin vain yhden sivun mittainen pdf, joka ei kata kaikkia yksityiskohtia. Luonnoksesta voi lähteä liikkeelle tekemällä muutaman prototyypin ja juttelemalla product ownerin kanssa siitä, miten prototyypit vastaavat eri vaatimuksia.
Prototypointivaihe voi olla muutamasta päivästä noin viikkoon. Jos protoyyppejä tekee monta viikkoa, tuote saa olla itsessään jo aika monimutkainen.
Mikä on Proof of Conceptin ja prototyypin ero?
Kun tehdään softaa, niin erilaisia asioita on tehty muissakin projekteissa. Kun haetaan Proof of Conceptia, niin silloin tulisi taklata vaikein tuotteeseen liittyvä asia ja tehdä siitä minimalistinen prototyyppi. Tällöin voidaan osoittaa, miten juuri se vaikein asia eli core toimii ja myöhemmin voidaan rakentaa kaikki liha sen ympärille. Ongelman ratkaiseminen lisää itsevarmuutta projektin onnistumiseen. Silloin ei pääse käymään niin, että ensin rakennetaan kahden kuukauden ajan taustajärjestelmiä, jonka jälkeen ymmärretään, että asiaa X ei voida tehdä.
Teknisen konsultin näkökulmasta tällä voidaan varmistaa, että asiakkaalle luvatut asiat ovat mahdollisia toteuttaa. Tottakai tilanteeseen liittyy paljon validointia, että onko tuote oikea siitä näkökulmasta, mitä markkinoilla halutaan.
On aika paljon puolivalmiin teknisen toteutuksen asioita. Mikä on prototyypin ja MVP:n ero?
MVP voidaan nähdä tuotteena, joka julkaistaan. Kun rakennamme prototyyppiä ja se on valmis, emme ala rakentamaan enää sen päälle. Prototyyppi aloitetaan puhtaalta pöydältä rakentamalla MVP:tä eli Minimum Viable Productia. MVP:n tulisi olla tuote, jossa on vähimmäisominaisuudet sillä tavoiteltavien asioiden onnistumiseksi.
Hyvä esimerkki voisi olla vaikkapa tori.fi:n tyylinen tuote. MVP olisi sellainen, että näet siellä myytävät tuotteet ja voit ottaa yhteyttä myyjään. Ylimääräisiä ominaisuuksia voisivat olla esimerkiksi tuotteiden etsiminen maakunnan mukaan ja niiden lajittelu. Ensin tehtäisiin siis MVP ja sen jälkeen rakentuvat vasta lisäominaisuudet.
”MVP-ajattelussa on myös se hieno puoli, että se myös opettaa teknisten palvelujen pariin tulevia uusia asiakkaita kehityssykliin. Kun rakennellaan tuotteita, se tapahtuu sykslisesti ja kehitystyö on usein jatkuvaa. Aina pitää osata vähän määritellä, mikä on seuraavan syklin jälkeen valmis tuote.” –Julius
Kun lähdetään projektiin, niin miten teknologiavalinnat tehdään?
Teknologioiden valinta on hieman ikuisuuskysymys. Myyntipalaverissa tekniseltä henkilöltä kysellään usein, että millä perusteella teknologiavalintoja yleensä tehdään. Ohjelmistokehittäjille on insinööreinä taottu päähän, että hopealuotia tähän ei löydy ja aina pitää olla valmis etsimään kyseiseen projektiin parhaat teknologiat.
Saattaa kuulostaa lattealta. Aina sanotaan samat asiat, mutta silti samat teknologiat toistuvat projektista toiseen. Idention konsultit pyrkivät tietysti aina valitsemaan parhaat teknologiat. Tekemisessä täytyy pitää järki mukana.
Mitä pidempään on työskennellyt alalla, sitä tylsemmiksi teknologiavalinnat ovat tulleet. Aiemmin on ollut uutuuden viehätystä. Nykyään yritämme valita teknologiat niin, että ne ovat yleisiä. Silloin asiakas saa tukea ylläputoon myös silloin, jos me emme työskentele kyseisen projektin parissa. Se on yksi isoimmista prioriteeteista.
Tulevatko teknologiavaatimukset asiakkaalta, vai pystyvätkö konsultit valitsemaan valitsemaan ne?
Silloin tällöin asiakkailta tulee vaatimuksia liittyen teknologioihin. Mikäli asiakkaan projektissa on tulossa vaikka tiettyjä integraatioita, tai jos projekti integroituu fyysisiin laitteisiin, niin ne asettavat aika paljon rajoitteita työskentelyn teknologiavalintoihin. Taloissa, jotka ovat tehneet ohjelmistokehitystä pidempään, saattaa olla vahvat preferenssit sille, että pyritään työskentelemään samassa ympäristössä kaikkien teknisten toteutusten yhteydessä.
Vielä siis lyhyesti:
- Ota aikaisessa vaiheessa ihmiset mukaan sekä kommunikoi paljon ja avoimesti. Luottamusta aletaan rakentaa jo projektin alkuvaiheessa.
- Älä vähättele prototypoinnin ja Proof of Conceptien merkitystä. Ne antavat varmuutta toteutuksen mahdollisuudelle.
Lue myös miten visualisoida ohjelmistokehityksen etenemistä.
