Ohjelmistoprojektin aloittamiseen on olemassa monenlaisia tapoja. Tässä tekstissä käsittelemme ohjelmistoprojektin käynnistämistä yleisellä tasolla sekä toimintamalleja, jotka konsulttimme ovat kokeneet toimiviksi.

Uuden ohjelmistoprojektin aloittaminen

Kun kyseessä on kokonaan uuden tuotteen tai palvelun kehittäminen, kutsutaan sitä usein Greenfield-projektiksi. Tällaisessa tilanteessa tuotteen tai palvelun rakentaminen voidaan aloittaa tyhjältä pöydältä ilman ennalta rajoittavia tekijöitä.

Missä vaiheessa konsultti tulee mukaan tällaiseen projektiin?

Tilanne voi vaihdella asiakkaan preferenssien mukaan, mutta parhaassa tapauksessa konsultti pääsee osallistumaan jo mahdollisimman aikaisessa vaiheessa. Silloin projekti on alusta asti yhdessä tekemistä. On hyvä, jos asiakas on tässä vaiheessa määritellyt jo tuotteen vaatimukset ja jonkinlaisen kehyksen sille, mitä projektissa rakennetaan. Konsultin voi ottaa jo tässä vaiheessa mukaan ja monet konsultit tekevätkin myös palvelumuotoilua ja suunnittelua. Silloin konsultti pääsee aidosti ratkaisemaan asiakkaan ongelmia.

Monet konsultit myös nauttivat tilanteesta, jossa projektin alkuvaiheeseen osallistetaan mahdollisimman monia ihmisiä. Näin toimittaessa kaikkien osaajien asiantuntemus on käytettävissä mahdollisimman aikaisin. On esimerkiksi arvokasta, että UX-suunnittelijat ja tekniset osaajat pääsevät tekemään suunnittelutyötä yhdessä mahdollisimman varhain. Näin varmistetaan, että tekniset vaatimukset huomioidaan jo suunnitteluvaiheessa. Toteutusvaiheeseen voi liittyä suuria riskejä, mikäli projektin alkuvaiheessa edetään ilman kokonaisvaltaista näkemystä siitä, miten tuotetta tai palvelua kannattaa lähteä kehittämään.

Googlella on projektin alkuvaihetta tukevia loistavia työkaluja, kuten Design Sprint. Se mahdolistaa prosessin, jossa joukko projektin toteuttamiseen liittyviä henkilöitä suunnittelee ja tuottaa prototyyppejä tai demoja jostain asiasta viikon ajan. Ideana on luoda raamit tekemiselle ja mukana on usein eri aihealueiden asiantuntijoita.

Miten ohjelmistoprojektin teknologiavalinnat tehdään?

Myyntipalaverissa tekniseltä henkilöltä kysellään usein, millä perusteella teknologiavalintoja yleensä tehdään. Teknologioiden valinta on kuitenkin hieman ikuisuuskysymys. 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. Projektille parhaista teknologioista puhutaan paljon, mutta silti samat teknologiat toistuvat projektista toiseen. Idention konsultit pyrkivät kuitenkin aina valitsemaan parhaat teknologiat omista intohimoistaan huolimatta. Yritämme aina valita teknologiat niin, että ne ovat yleisesti käytettyjä. Silloin asiakas saa tukea ylläpitoon myös silloin, jos me emme enää työskentele kyseisen projektin parissa. Se on yksi suurimmista prioriteeteistamme.

Joskus myös asiakkaalta tulee vaatimuksia teknologioihin. Mikäli asiakkaan projektissa on tulossa esimerkiksi tiettyjä integraatioita, tai jos projekti integroituu fyysisiin laitteisiin, asettavat ne aika paljon rajoitteita työskentelyn teknologiavalintoihin. Pidempään ohjelmistokehitystä tehneissä taloissa saattaa myös olla vahvat preferenssit sille, että kaikkien teknisten toteutusten yhteydessä pyritään työskentelemään samassa ympäristössä.

Vaatimusmäärittely – miten kaivaa esiin piilotetut vaatimukset?

Projektin alkuvaiheessa on tärkeää selvittää piilotetut vaatimukset. On todella tärkeää, että yhteistyön alkuvaihe asiakkaan kanssa on intensiivistä työskentelyä. Projektin tai tuotteen onnistumiselle on olennaista kyky pystyä kaivamaan esiin erilaiset rajoitukset ja tarpeet sekä maali. Design sprint on yksi ratkaisu piilotettujen vaatimusten kartoittamiseen.

Vaatimuksia voidaan kartoittaa esimerkiksi käyttäjäroolien ja erilaisten toiminnallisuuksien kautta tai vaikkapa seuraamalla vanhajn järjestelmän käyttöä ja prosesseja.

"Meillä oli kerran projektistartti, jossa kävimme ensin läpi projektin tekniset vaatimukset. Tämä tapahtui ennen meille oli korkeammalla tasolla selitetty, mitä olimme edes rakentamassa. Tällainen lähestymistapa ei välttämättä ole paras mahdollinen. On iso apu projektin onnistumiselle, jos toimintaympäristöstä saadaan kattava kuva mahdollisimman nopeasti." – Ohjelmistoinsinööri, Identio

Monet ohjelmistokehittäjämme ovat kokeneet, että prototypointi on usein hyvä tapa aloittaa vaatimusmäärittely. Joskus bisneksen parissa työskentelevät henkilöt saattavat aloittaa siitä, minkä näköinen tuote halutaan. Tämä saattaa kuitenkin olla vain yhden sivun mittainen pdf-tiedosto, joka ei kata kaikkia yksityiskohtia. Projektitiimi voi tällöin 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. Prototyyppejä ei välttämättä kannata pyöritellä viikkotolkulla, koska silloin tuotteesta voi tulla jo aika monimutkainen.

Mikä on Proof of Conceptin ja prototyypin ero?

Softaa rakennettaessa ollaan usein tilanteessa, jossa samankaltaisia asioita on aiemmin tehty myös muissa projekteissa. Kun haetaan Proof of Conceptia, niin silloin tulisi taklata vaikein tuotteeseen liittyvä asia ja tehdä siitä minimalistinen prototyyppi. Tällöin voidaan osoittaa, että juuri se vaikea asia, core, toimii ja sen ympärille voidaan myöhemmin rakentaa muut toiminnallisuudet. Ongelman ratkaiseminen lisää itsevarmuutta projektin onnistumiseen. Tällaisessa tilanteessa ei pääse käymään niin, että taustajärjestelmien rakentamiseen käytetään ensin pari kuukautta ja vasta sen jälkeen ymmärretään, että jotain muuta asiaa X ei voida toteuttaa.

Teknisen konsultin näkökulmasta tällä voidaan myös varmistaa, että asiakkaalle luvatut asiat ovat mahdollisia toteuttaa. Tilanteeseen liittyy tietysti myös validointia siitä, kaivataanko markkinoilla sellaista tuotetta, jota projektissa rakennetaan.

Entä mikä on prototyypin ja MVP:n ero?

MVP eli Minimum Viable Product voidaan nähdä tuotteena, joka julkaistaan. Prototyypit ovat malleja tuotteesta. Prototyyppejä voidaan rakentaa useita ja kun ne ovat valmiita, ei niiden päälle enää rakenneta. MVP:n tulisi olla tuote, jossa on vähimmäisominaisuudet sillä tavoiteltavien asioiden onnistumiseksi. Se keskittyy siis enemmän markkinaan ja tietyn ongelman ratkaisemiseen. Prototyyppi taas keskittyy tuotteeseen, eikä sen tarvitse olla vielä oikea toimiva järjestelmä.

Käytetään esimerkkinä vaikkapa tori.fi:n tyylinstä tuotetta. MVP olisi sellainen, jossa näemme myytävät tuotteet ja voimme 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 se hieno puoli, että se opettaa teknisten palvelujen pariin tulevia uusia asiakkaita kehityssykliin. Kun rakennellaan tuotteita, se tapahtuu syklisesti ja kehitystyö on usein jatkuvaa. Aina pitää osata vähän määritellä, mikä on seuraavan syklin jälkeen valmis tuote.” – Julius Rajala, ohjelmistoinsinööri, Identio

Yhteenveto – tärkeää ohjelmistoprojektin aloittamisessa

• 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.