Itsekkäästi asiakkaan asialla

Bisnesarvoa tuottava, loppukäyttäjäystävällinen sovellus ei ole itsestäänselvyys. Jotta laadukas ohjelmisto voi syntyä, on ainakin seuraavien transitioiden onnistuttava projektin aikana:

• Idea → Bisnestarve

• Bisnestarve → Konsepti

• Konsepti → Design + Arkkitehtuuri

• Walking skeleton → MVP

Näiden siirtymien hankaluus piilee siinä, että usein asiaa on lähestyttävä hyvin erilaisia menetelmiä käyttäen. Siinä missä Design Thinking, UCD ja palvelumuotoilu toimivat ideoinnissa, konseptoinnissa ja yleisessä kartoittamisessa, ovat ohjelmistokehityksen menetelmät erilaisia ja keskittyvät enemmän yksityiskohtiin. Moniosaavan tiimin rakentaminen kaikkien näiden vaiheiden tueksi ja siirtymien onnistumiseksi onkin taitolaji.

Idean kiertokulku

Asiakkaan edustaja saattaa heittää ilmoille jonkun idean alkuworkshopissa, joka dokumentoidaan korkean tason kaavioon kokonaisprosessista. Idea saa jatkossakin kannatusta, joten se päätyy lopullisiin käyttöliittymädesigneihin suunnittelijan pöydälle. Toteutusvaiheessa huomataan kuitenkin, että joku suunnitelman osio ei toimi sellaisenaan arkkitehtuurihaasteista johtuen. Käyttöliittymäsuunnittelija muuttaa jotain osiota designeissa, jotta se on mahdollista toteuttaa. Kehitystiimi toteuttaa suunnitelman mukaan. Alkuworkshopeissa tehty Service Blueprint tai vastaava kaavio voi olla kuitenkin arvokas myöhemmin. Korkean tason kaaviot eivät vanhene kovin helposti, jos ne on tehty laadukkaasti. Muutaman vuoden päästäkin tällaiset kaaviot ovat hyödyllisiä perehdyttämisessä.

Onnistuneet siirtymät ohjelmistoprojektissa

Mitä yhteistä on onnistuneille (tiedon) siirtymille ohjelmistoprojekteissa?

• Iterointi ja yhteisymmärrys: Ensi-ideoita on hyvä tutkia hieman lisää ja pyrkiä löytämään myös muiden henkilöiden ideat saman asian ratkaisuun. Ideoita, konsepteja ja ajatuksia on vielä kevyt muuntaa oikeaan suuntaan, ennen kuin ollaan toteuttamassa vääränlaista ohjelmistoa.

• Kommunikointi: Tämä on se liima, joka pitää kokonaisuuden kasassa. Kommunikointia voi olla palaveeraus, dokumentointi, valkotaululle piirtäminen, keskustelu, videotallenne, kaavio jne.

• Moniosaava tiimi, joka tuntee myös toisten työskentelytavat: Preferoiduista työskentelytavoista ja käytänteistä on hyvä sopia jokaisen tiimin kesken. On hyödyllistä, jos yhteiseen terminologiaan ja käytänteisiin on sitouduttu. Tämä on tapahduttava jokaisen tiiminmuodostuksen aikana uudestaan, ellei kyseessä ole muutaman hengen tiimi, joka on tehnyt useita vastaavia hankkeita.

• Erilaisten metodologioiden ymmärtäminen: Ohjelmistokehityksessä käytetään niin laajalti erilaisia metodologioita, ja osaamisalueita on valtavasti, joten voi olla haastavaa ymmärtää, mitä toinen henkilö on tekemässä. Tällaisessa tilanteessa voi pyytää selitystä, jotta ymmärtää edes summittain mistä on kyse. Kahden tiimiläisen päällekkäiset osaamisalueet ovat mielenkiintoisia, sillä niissä uutta tietotaitoa voi sovittaa omaan semanttiseen ymmärrysviitekehykseen.

• Erilaiset perspektiivit ja tarpeet: Työstettäessä pieniäkin yksityiskohtia on hyvä muistaa korkean tason asiakaslähtöinen tarve, jota ollaan ratkaisemassa.

• Henkilökohtainen reflektointi: Usein puhutaan tiimien toiminnasta, mutta minä unohtuu. On hyvä myös pystyä reflektoimaan omaa toimintaa tiimissä ja omien tekojen seurauksia. Kun tuntee oman toimintansa projekteissa, voi aktiivisemmin välttää omia "sokeita kohtiaan".

Yhteenveto

Lopulta laadukkaan ohjelmiston kehittäminen on jatkuvaa tasapainoilua eri menetelmien, tiimin osaamisen ja liiketoiminnan tarpeiden välillä. Onnistuneet transitioiden hallinnat ja sujuva yhteistyö erilaisten työskentelytapojen kanssa ovat keskeisiä tekijöitä, jotka erottavat onnistuneet projektit epäonnistuneista. Jokaisen osapuolen panos, iterointi, selkeä kommunikointi ja kyky reflektoida omaa tekemistään varmistavat, että kehitysprosessi pysyy suunnassa ja tuottaa liiketoimintaa tukevan, käyttäjäystävällisen lopputuloksen.