Ohjelmistohankinnan lyhyt oppimäärä kantapään kautta

11.12.2018

Asiantuntemus kehitystyön ostamisen käytänteistä ja kokemus ohjelmistokehitysprojektien läpiviemisestä ovat hankkeen lopputuleman onnistumisen asteen kannalta ratkaisevia. Noviisilla ei kuitenkaan ole syytä paniikkiin, sillä ennakkoluulottomuus, avoimuus sekä yhteistyö vastuullisen toimittajatahon kanssa ovat avain menestykseen. Saimme ohjelmistoasiantuntijaverkostomme kautta harvinaislaatuista ja ensiarvoisen tärkeää tietoa ohjelmistopalvelujen osto- sekä asiakaskokemukseen liittyen. Tämä ensiostajan tarina antaa esimerkin tilanteesta, jossa petraamisen tarve on tapahtuneen johdosta tunnistettu molemmin puolin pöytää.

Ensimmäinen oma IT-hankintani käynnistyi viime keväänä. Hankintaani liittyen kävin tapaamassa muutamien ohjelmistotalojen asiantuntijoita, mutta lopullinen toimittaja valikoitui sen perusteella, että myynnin yhteyshenkilö sattui soittamaan minulle oikeaan aikaan ja kaupat tehtiin. Projektin aloitustapaamisessa kävimme läpi tarpeemme. Olimme kaikki yksimielisiä siitä, mitä oli määrä tehdä ja paljonko rahaa hankkeeseen oli budjetoitu. Minulle kerrottiin, että koodaustyö toteutetaan parin viikon sykleissä eli sprinteissä. Sprinttikäytäntö ei ollut minulle entuudestaan tuttu, kuten ei mikään muukaan asia digitaalisen tuotteen kehitystyössä.

Opin sprinttien tarkoittavan käytännössä sitä, että tuotetta koodataan esimerkiksi viikon tai kuukauden ajan, jonka jälkeen katsotaan miten työ on edennyt ja suunnitellaan jatkoa. Näin tehtiinkin pari kertaa, ja työ vaikutti edistyvän hyvin. Kesän loppupuolella menin noutamaan toimittajalta valmista tuotettamme, mutta hämmästyksekseni minulle kerrottiinkin, että sopimuksessa mainitut sata tuntia koodaustyötä olivat tulleet täyteen, eikä tuotetta ei oltu saatu siinä ajassa valmiiksi. Kerroin hämmennykseni sekä pettymykseni ja sanoin etten missään vaiheessa ollut aidosti ymmärtänyt ostaneeni vain sataa tuntia koodausta. Uskoin ostaneeni käyttövalmiin ja viimeistellyn ohjelmistotuotteen.

Luin kotona tekemäämme sopimusta suurennuslasin kanssa läpi, tai suurennuslasi oli kylläkin tarpeeton. Sopimuksessa oli täsmennetty selvästi, että olin ostanut sata tuntia koodaustatyötä. En tosin ollut huomannut kahlata pitkää ja perusteellista sopimusta tarkasti läpi, vaan luotin siihen mitä aloitustapaamisessa keskusteltiin hankkeen toteutuksesta. Minulle sanottiin, että kehittäjät voivat jatkaa koodaamista, mutta työstä aiheutuvat kustannukset tullaan laskuttamaan erikseen. Vastasin yksiselitteisesti, että projektia ei tulla enää jatkamaan. Minulla oli huijattu ja epämukava olo. Ohjelmistotoimittajan eduksi täytyy kuitenkin todeta, että asiakkaana saamani kohtelu oli kaikin puolin sekä ystävällistä että myötäelävää. Yhteyshenkilöt pahoittelivat, etteivät olleet onnistuneet viestimään minulle tarpeeksi selvästi sitä, että valmiina tulisi olemaan pikemminkin ensimmäinen kehitysversio, kuin viimeistelty sekä julkaisuvalmis tuote.


Vaihdoin asiakkuuteni toiselle ohjelmistotoimittajalle, jolle kerroin tapahtuneesta. Sain tietoa, että kyseinen tapa ostaa tiettyä tuntimäärää on alalla vallitseva käytäntö. Valtaosassa projekteista on myös tavallista, että tavoitellun lopputuleman suhteen kehitystyöhän tarvittavaa aikaa on etukäteen mahdotonta kattavasti arvioida. Ongelma ensimmäisen ohjelmistotoimittajan kanssa oli siis ollut se, että he eivät tulleet ottaneeksi ensikertalaisen rajoittunutta ohjelmistoprojektikokemusta huomioon, eivätkä riittävän selkeästi viestineet sitä, mitä itseasiassa olin ostamassa. Minulle kerrottiin, että laadukkaaseen kehitysprosessiin liittyy olennaisena osana asiakkaan säännöllinen informoiminen hankkeen yleisestä etenemisestä sekä aikatauluarvioiden paikkansapitävyydestä. Sekä suunnittelussa että edistymisessä mahdollisesti ilmenevien ongelmien tiimoilta ollaan viipymättä yhteydessä asiakkaaseen.

Yhteistyön kehittyessä uuden ohjelmistotoimittajan kanssa olin jo enemmän kartalla siitä, miten ohjelmistoprojektiin sisältyvät osasuoritteet sekä prosessit käytännössä etenevät. Tapasimme säännöllisesti, vaihdoimme eri kanavien välityksellä tilannekatsauksia ja puhuimme perinteiseen malliin myös puhelimessa. Olin työparini kanssa koostanut omat ajatuksemme ja kehittäjien työn helpottamiseksi laatinut vuokaaviomallin siitä, miten käyttäjän kuuluisi navigoida palvelussa. Näin oli helppo varmistua siitä, että käyttäjänäkymät etenevät oikeassa järjestyksessä ja käyttökokemus säilyy miellyttävänä. Kuvalliset hahmotelmat toimivat enemmän keskustelun avaajina ja kehittäjät pystyivät paremmin omaksumaan, mitä tuotteelta toivotaan. Hankkeen budjettirajoite oli hyvin sitova, mikä viestittiin hyvin selvästi kehitystiimille. Tuotteen ominaisuuksia muokattiin budjettirajoitteen sanelemissa puitteissa siten, että jäljelle jäivät vain kaikkein tärkeimmät ominaisuudet. Täten tuote oli mahdollista kehittää siihen kuntoon, että pystyimme ottamaan sen koekäyttöön tutkimushankkeessamme.

Ohjelmistoprojektin hankinta sekä läpivienti oli minulle itselleni äärimmäisen opettavainen kokemus. Nyt tiedän, että ensimmäisen yhteistyötahon tarkoituksena ei ollut millään tavalla johtaa minua harhaan, vaan kyse oli puhtaasti informaation epäsymmetriasta. He olivat tottuneet toimimaan kokeneempien asiakkaiden kanssa, eivätkä ottaneet huomioon että alalla vallitsevat käytännöt eivät olleet minulle entuudestaan tuttuja. Seuraavalla kerralla olenkin astetta viisaampi ja ymmärrän ohjelmistokehitysprojektien haasteita sekä sopimusteknisiä reunaehtoja paljon paremmin.


Ohessa muutama tärkein matkan varrella opittu asia ostajan muistilistalle:

  • Mieti tarkkaan, kenelle tuote on suunniteltu ja minkälainen vaikutus sillä pyritään saamaan aikaiseksi. Viesti tämä mahdollisimman seikkaperäisesti ohjelmistotoimittajalle.
  • Mitkä seuraavista ovat lopputuleman kannalta kaikkein kriittisimmät vaikuttimet; hinta, aika, laajuus vai laatu? Viesti näiden osalta mahdollisimman seikkaperäisesti. Ohjelmistotoimittajan tehtävänä on muistuttaa, että jos hinta ja aika ovat pääkriteerit, niin tällöin laadun sekä laajuuden suhteen joudutaan tinkimään.
  • Edellisiin liittyen mieti alustavasti itse sekä yhdessä ohjelmistoasiantuntijoiden kanssa, mitkä ovat tärkeimmät ominaisuudet mitä palvelussa/tuotteessa täytyy olla ja mitä ilman projektia ei kannata toteuttaa – Varmistukaa siitä, että projekti on toteutuskelpoinen.
  • Älä mieti palvelun käyttökokemusta ja vuokaaviota liian valmiiksi, vaan luota ohjelmistotoimittajan asiantuntijuuteen. Kokeneilla palvelumuotoilijoilla, ohjelmistokehittäjillä ja UI/UX-suunnittelijoilla on mitä luultavimmin kokemuksia siitä, miten ideasi voidaan toteuttaa yksinkertaisesti sekä kustannustehokkaasti.
  • Varaudu alussa koeponnistamaan, jotta mahdollisuudet hankkeen realistiselle toteutumiselle saadaan selvityksi.
  • Varaa ja kalenteroi aikaa säännölliseen yhteydenpitoon ohjelmistokehitystiimin kanssa.
  • Älä pelkää näyttää sitä, ettet ymmärrä. Pyydä ja vaadi että asiat väännetään sinulle tarvittaessa rautalangasta. Mikäli ohjelmistohankinnat ovat sinulle uutta, tämä on mahtava tilaisuus oppia!

shopping_cart

Ohjelmistohankinta suunnitteilla?

Etsitkö proaktiivista, ketterää ja luotettavaa yhteistyökumppania, jolla aidosti toimivien ratkaisujen toteuttaminen on kaiken toiminnan keskiössä?

Lue lisää »

« Paluu

CONTACT US »
OTA
YHTEYTTÄ »

Jätä yhteydenottopyyntö

Palaamme asiaan pikimmiten!