5 tapaa mokata softahanke

13 loka 2016 • Strategia ja liiketoimintamuotoilu

Hyvää kansainvälistä epäonnistumisen päivää !

Day For Failure nostaa kiinnostavan asian pinnalle – epäonnistumisen. Lähestyn kulmaa kuitenkin softahankkeen näkökulmasta, mutta haastan jokaisen lukijan samalla mokamaan tänään edes kerran. Palkitsevinta epäonnistumisessa on sen jakaminen kollegan, kumppanin tai vaikka ystävän kanssa.

No, mutta miten softahanke tyypillisesti mokataan? Tapoja on vähintäänkin tuhansia, kun aiheena on kompleksiset ja useasti tarpeeseen räätälöidyt sovellukset. Listaan kuitenkin näiden joukosta viisi, jotka pystytään pienellä vaivalla useasti välttämään uuden pilvipalvelun rakentamisessa.

Softahanke, jossa tekniikka on edellä

Käsi sydämellä – kuka meistä joskus ei olisi tähän syyllistynyt? Myönnän itse joskus rakastuneeni uuteen .js:ään jopa niin, että uskoin sen sopivan ihan kaikkeen – siis ihan kaikkeen. Myönnetään, että naivius on ainakin hieman vähentynyt vuosien varrella. Valitettavan usein kuitenkin kuulee edelleen ”haluan tämän toteutettavan tällä”. Täysin väärä lähtökohta ja useasti hankkeen onnistumisen mahdollisuudet on menetetty jo tässä vaiheessa.

Epäselvä projektimalli

Meitä ympäröi tänä päivänä lukemattomia projektin toteutusmalleja. Löytyy SCRUMia, agilea, kanbania, vesiputousta, prince2:sta ja lukuisia muita modifikaatioita ja soveltavia tapoja päästä tavoitteeseen. Mieti etukäteen miten haluat organisaatiosi kanssa toimia, ennen kuin lähdet kumppanisi kelkkaan. Jos toimittajasi vie projekteja esim. SCRUM-mallilla ja itse olet enemmän vesiputousorganisaation kannattaja, on yhtälö projektin onnistumiseksi jälleen vaakalaudalla – useasti jopa jälleen turhaan.

Palvelun käyttäjät unohtuvat

Edelliset kaksi voidaan vielä korjata suhteellisen helposti (lue halvalla), mutta tätä ei. Skenaariona seuraava: palveluun käytetään uskomaton määrä resursseja, hikeä, rahaa, omaa panostasi ja uskottavuuttasi. Luot hienot suunnitelmat lanseeraukselle ja kaikki on mennyt mallikkaasti hankkeen aikana. Mietit päässäsi, että vihdoin saan tämän ulos – tästä tulee MAHTAVAA! Softahanke julkaistaan ja käyttäjiltä alkaa tulla palautetta, joka on murskaavaa. Kuulet viittauksia ”edellinenkin oli parempi”. Panikoit ja alat etsiä syyllisiä ”ei tää voi olla näin”. Kyllä voi ja terveiset on täältä – katso peiliin. Raju skenaario, mutta jälleen vältettävissä esim. järjestämällä fokusryhmiä tai A/B testausta loppukäyttäjillä.

Toiminnallisuuksien priorisointi

Hieman samaa kuin yllä, mutta enemmän ihan käytännön asia. Useasti tässä mokataan, kun projektilla ei ole selkeää omistajuutta tai osaavaa projektiryhmää. Niin sanottu toiveiden tynnyri vain paisuu yli ja Trellon listat backlogista alkavat olla isommallekin näytölle järjettömät löytää yhtään mitään. Jos olet niin sanottu projektin omistaja, niin käy oman organisaatiosi kanssa jatkuvaa keskustelua toiminnallisuuksista ja osallista kumppania mukaan. Hankkeen oikeaan suuntaan menemisen voi varmistaa myös säännöllisillä demoilla. En tarkoita powerpointeja, vaan ihan konkreettisia demoja softasta.

Kiire

Joskus kiire on hyvästä, mutta softahankkeessa harvemmin. ”Tällä hankkeella on muuten kiire!” on kuitenkin suurin moka mitä voit tehdä. Annan edellisessä lauseessa olevan Teemun blogin avata aiheen tarkemmin.

Mokaaminen on useasti inhimillistä ja useasti myös todella hedelmällistä. Älkää siis missään nimessä pelätkö mokaamista vaan heittäytykää ja olkaa armollisia itsellenne.

Kiivan presenttikisan viitekehyksessä ”Far better is it to dare mighty things, to win glorious triumphs, even though checkered by failure… than to rank with those poor spirits who neither enjoy nor suffer much, because they live in a gray twilight that knows not victory nor defeat” – Theodore Roosevelt

Hyviä mokaamisia!