Konsultointi – Miten ohjelmistoprojekti startataan?

Erika Bergström6.10.2020 · 5 min

Prochat-podcastin Konsultointi-sarjan uudessa jaksossa Sami Suo-Heikki ja Julius Rajala pallottelevat ajatuksia projektien starttaamisesta ja siitä, miten projektien alkuvaiheessa kannattaa yleensä toimia.

Kaikki projektit ovat tietysti omanlaisiaan, eikä niihin ole vain yhtä toimivaa mallia. Aihetta sivutaan sekä uuden projektin aloittamisen että meneillään olevaan projektiin hyppäämisen näkökulmista.

Otetaan tällainen hypoteesi, että alkamassa on uuden tuotteen kehittäminen eli Greenfield-projekti. Missä vaiheessa konsultti tulee projektiin mukaan?

– Tämä vaihtelee aika pitkälti asiakkaan preferenssien mukaan. Parhaimmillaan tilanne menee niin, että konsulttina pääsee mukaan tekemiseen jo mahdollisimman aikaisessa vaiheessa. Silloin se on alusta asti yhdessä tekemistä. On tietysti hyvä, että asiakkaat määrittelevät aluksi vaatimukset ja jonkinlaisen freimin sille, mitä rakennetaan. Voihan siinäkin tietysti olla konsultit mukana – monet konsultit tekevät palvelumuotoilua ja suunnittelua. Siinä lähdetään oikeasti ratkaisemaan asiakkaan ongelmia.

Itse nautin konsultoinnista, 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 onhan siinä aika suuria riskejä toteutusvaiheessa.

Googlella on ihan loistavia työkaluja tähän, kuten heidän Design Sprint. Lähtökohtaisesti se on prosessi, jossa viikon aikana joukko projektin toteuttamiseen liittyviä henkilöitä toteuttaa prototyyppejä tai demoja jostain asiasta. Ideana on luoda jonkinlaiset raamit tekemiselle. Mukana tekemisessä on eri aihealueiden asiantuntijoita.

Miten sitten kaivetaan piilotetut vaatimukset?

– Design sprint on yksi vaihtoehto tähän. Ylipäätään kun lähdetään projektiin mukaan, on todella tärkeää, että alkupää yhteistyöstä asiakkaan kanssa on intensiivistä työskentelyä. Se, että pystytään kaivamaan mahdollisimman tarkasti rajoitukset ja tarpeet ja maali sille projektille tai tuotteelle, on olennaista sen onnistumiselle.

Meillä oli eräs projektistartti, jossa naureskelimme hieman sitä, että ensin käytiin läpi tekniset vaatimukset – ennen kuin kävimme edes high-level overviewta siitä, mitä ollaan edes rakentamassa. Se voi olla vähän huono lähestymistapa hommaan. On todella iso apu projektin onnistumiselle, jos saadaan mahdollisimman kattava kuva toimintaympäristöstä mahdollisimman nopeasti.

Onko sinulla Sami hyviä kokemuksia vaatimusmäärittelystä, joita haluaisit jakaa?

– Prototypointi on aika solid tapa aloittaa. Olen tottunut siihen, että bisneshenkilöt sanovat, että halutaan tämän näköinen tuote. Se on usein kuitenkin vain yhden sivun mittainen pdf, joka ei kata kaikkia yksityiskohtia. Siitä voi lähteä liikkeelle tekemällä muutaman prototyypin ja jutella product ownerin kanssa, että miten prototyypit vastaavat eri vaatimuksia.

Prototypointivaihe voi olla muutamasta päivästä noin viikkoon. Jos protoyyppejä tekee monta viikkoa, niin tuote saa olla kyllä jo aika monimutkainen.

Paljon jutellaan myös Proof of Consepteista. Mitä sanoisit, mikä on Proof of Conseptin ja prototyypin ero?

– Jos tehdään softaa, niin monia asioita ollaan tehty muissakin projekteissa. Kun haetaan Proof of Conseptia, niin silloin tulisi taklata se vaikein asia tuotteessa ja tehdä siitä minimalistinen prototyyppi. Silloin voi osoittaa, miten se vaikein asia eli core toimii ja myöhemmin voidaan rakentaa kaikki liha sen ympärille. POCin rakennuksessa on mielestäni siis tärkeintä taklata se vaikein asia, vaikka ei sitä tietenkään tarvitse valmiiksi saada. Silloin on kuitenkin itsevarmuutta projektin onnistumiseksi. Ei käy niin, että ensin rakennetaan kahden kuukauden ajan taustajärjestelmiä ja sitten tajutaan, että emme voi tehdä ollenkaan asiaa X.

Ainakin usein minun näkökulmastani teknisenä konsulttina tällä voidaan varmistaa, että asiakkaalle luvatut asiat ovat mahdollisia toteuttaa. Tottakai on varmasti paljon validointia, että onko tuote oikea siitä näkökulmasta, mitä markkinoilla halutaan.

Jatketaan vielä hetki prototyypeistä. On aika paljon sellaisia hähmäisiä, puolivalmiin teknisen toteutuksen asioita. Mikä sitten on prototyypin ja MVP:n ero?

– Näkisin, että MVP on kuitenkin jo tuote, joka julkaistaan. Kun rakennamme prototyyppiä ja se on valmis, emme ala rakentamaan enää sen päälle. Siinä vaiheessa kun tehdään prototyyppiä, niin aloitetan puhtaalta pöydältä 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 se, 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

Tekninen konsultointi on se mitä teemme. Kun lähdetään projektiin, niin miten teknologiavalinnat tehdään?

– Tämä on käytännössä ikuisuuskysymys. Tuntuu, että melkein jokaisessa myyntipalaverissa tekniseltä henkilöltä kysellään, että millä perusteella teknologiavalintoja yleensä tehdään. Meille 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.

Onhan tuo vähän latteaa. Aina sanotaan noin, mutta silti samat teknologiat toistuvat projektista toiseen. Pyrimme tietysti aina valitsemaan ne parhaat teknologiat. Olisihan se hullua, jos tieten tahtoen lähtisimme rakentamaan fronttia Asseblyllä - tai muuta yhtä kamalaa. Järki täytyy pitää mukana.

Mitä pidempään on työskennellyt alalla, sitä tylsemmiksi teknologiavalinnat ovat tulleet. Aiemmin on ollut sellaista uutuuden viehätystä. Nykyään yritämme kelailla, että teknologiavalinnat tehtäisiin niin, että ne teknologiat ovat kohtuullisen yleisiä. Silloin asiakas saa tukea ylläpitoon myös silloin, jos Identio ei enää työskentele kyseisen projektin parissa. Se on yksi isoimmista prioriteeteista. Pitää mahdollistaa myös toisen devaajan hyppääminen projektiin.

Tulevatko teknologiavaatimukset yleensä asiakkaalta, vai pystyvätkö konsultit valitsemaan valitsemaan ne?

– Silloin tällöin tulee asiakkailta vaatimuksia liittyen teknologioihin. Mikäli asiakkaan projektissa on tulossa vaikkapa 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ä koitetaan työskennellä 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 Conseptien merkitystä. Se antaa varmuutta toteutuksen mahdollisuudelle. Kun prototyyppeja ja POCeja on saatu valmiiksi, niin siinä vaiheessa on hyvä hetki alkaa kehittää oikeaa tuotetta. MVP:n määrittely on tämän jälkeen yleensä aika kohdillaan. MVP ei yleensä täytä edes kaikkia asiakkaan ensimmäisiä toiveita tuotekokonaisuudelle. MVP:n halutaan olevan tarpeeksi pieni, jotta pystytään viemään minimituote testaukseen asti. Jokaisen MVP:n rykäisyn aikana tiimillä alkaa nousta ideoita, kun tuote alkaa rakentua, siinä nähdään potentiaalia ja ihmiset inspiroituvat. Kehittäminen on jatkuvaa priorisointia projektin onnistumisen kannalta.


Kirjoittanut

Erika Bergström

Copywriter