Ensimmäinen ohjelmistoprojekti yritykselle. Mitä kumppanilta kannattaa vaatia?

Ensimmäinen ohjelmistoprojekti on yritykselle iso päätös, vaikka itse ohjelmisto olisi pieni. Onnistuminen ratkeaa harvoin koodissa. Se ratkeaa niissä asioissa, jotka ohjelmistokumppanin kanssa sovitaan ennen ensimmäistäkään koodiriviä.

Tilanne on tuttu monessa teollisuusyrityksessä. Tarjouslaskennassa, tilauskäsittelyssä tai raportoinnissa on työvaihe, joka tehdään käsin, vaikka kaikki tietävät, että sen voisi automatisoida. Idea on selvä, mutta omaa kehitystiimiä ei ole, eikä ohjelmistoja ole aiemmin hankittu.

Silloin ensimmäinen kysymys on yleensä, kenet valitaan. Yhtä tärkeää on se, mitä valitun kumppanin kanssa sovitaan. Hyväkin ohjelmistotalo voi toimittaa väärän asian, jos tavoite, vastuut ja hyväksymisen ehdot jäävät auki. Käymme tässä kirjoituksessa läpi, mitä kumppanilta kannattaa vaatia ja mitä teidän kannattaa valmistella itse.

Miten ensimmäinen vaihe kannattaa rajata?

Ensimmäinen vaihe kannattaa rajata niin pieneksi, että sen tulos nähdään viikoissa, ja niin todelliseksi, että tulos kertoo jotain oikeasta käytöstä. Hyvä ensimmäinen vaihe testaa projektin suurimman epävarmuuden teidän omalla aineistollanne ennen kuin koko ratkaisuun sitoudutaan.

Moni ensimmäinen ohjelmistoprojekti alkaa koko järjestelmän vaatimusmäärittelystä. Silloin ensimmäinen konkreettinen tulos nähdään vasta kuukausien päästä, ja muutokset ovat siinä vaiheessa jo kalliita. Rajattu kokeilu tai Proof of Concept kääntää järjestyksen. Ensin selvitetään, toimiiko ydinajatus. Käyttöliittymät, integraatiot ja tuotantoympäristö rakennetaan vasta sen jälkeen.

Vaadi kumppanilta ehdotus ensimmäisestä vaiheesta, jonka hinta ja kesto on sovittu etukäteen, ja selkeä kuvaus siitä, mitä vaihe todistaa ja mitä se jättää auki. Valmistelkaa itse esimerkkiaineisto, joka vastaa oikeaa käyttöä, ja nimetkää henkilö, joka arvioi tulokset oman työnsä näkökulmasta. Siistitty testiaineisto kertoo vähemmän kuin oikea, sotkuinen aineisto.

Soforin Define Build Maintain -mallissa tämä on Define-vaihe. Sen tuloksena syntyy yhteinen kuva lähtötilanteesta, priorisoitu lista kehityskohteista ja pohja päätökselle ennen investointia.

”Soforin kanssa projekti eteni vaiheittain ja hallitusti. POC-vaihe auttoi meitä varmistamaan ratkaisun toimivuuden ennen tuotantoversion rakentamista.”

Mitä teidän pitää määritellä itse?

Teidän pitää määritellä ongelma, tavoite ja mittari. Tekninen ratkaisu on ohjelmistokumppanin tehtävä, mutta kumppani ei voi tietää, mikä liiketoiminnassanne on tärkeintä, ellei sitä kirjoiteta auki.

Valmista järjestelmää ei tarvitse osata kuvata. Riittää, että osaatte kertoa, mikä työvaihe vie liikaa aikaa, missä virheet syntyvät, kuka ratkaisua käyttää ja mistä huomaatte, että tilanne on parantunut. Ero näkyy muotoilussa. ”Tarjouslaskenta nopeutuu” on toive. ”Tarjouslaskennan käsityö puolittuu ja asiakas saa tarjouksen samana päivänä” on tavoite, jonka toteutumisen voi mitata.

Hyvä kumppani perehtyy prosessiinne työpajassa tai haastatteluissa ennen hinta-arviota ja kirjoittaa auki, miten se ymmärsi tavoitteen. Se myös kyseenalaistaa tavoitteen tarvittaessa ja tarjoaa vaihtoehtoisia tapoja päästä perille. Jos kumppani lupaa toteuttaa kaiken pyydetyn kysymättä miksi, te kannatte yksin riskin siitä, että väärä asia rakennetaan hyvin.

Miten sovitaan, milloin työ on valmis?

Työ on valmis, kun ennalta sovitut hyväksymiskriteerit täyttyvät. Kriteerit kirjataan ennen toteutusta niin, että kaksi eri ihmistä päätyy niistä samaan johtopäätökseen.

Ilman kriteerejä hyväksyntä perustuu tunteeseen. Toimittaja pitää työtä valmiina, koska pyydetyt toiminnot on tehty. Ostaja on eri mieltä, koska ohjelmisto ei vielä helpota arkea. Kumpikin on omasta näkökulmastaan oikeassa, ja erimielisyys syntyy juuri silloin, kun budjetti on käytetty.

Hyvä hyväksymiskriteeri kuvaa lopputuloksen käyttäjän tilanteessa. Esimerkiksi myyjä saa puhdistetun tiedoston ilman käsityötä, ja tulos vastaa asiantuntijan tarkastamaa mallia. Kriteereihin kuuluvat myös suorituskyky, tietoturva ja se, millä aineistolla testataan.

Vaadi lisäksi testiympäristö, jossa voitte kokeilla ratkaisua itse, ja sovittu tapa käsitellä muutokset. Varatkaa kalentereihinne aikaa hyväksymistestaukselle ja päättäkää etukäteen, kuka työn hyväksyy. Kriteerit eivät lukitse koko projektia. Kun ymmärrys kasvaa, niitä voi muuttaa, kunhan muutoksesta sovitaan yhdessä ja sen vaikutus aikatauluun ja hintaan kirjataan.

Kuka päättää ja kuka vastaa projektin aikana?

Molemmilla osapuolilla pitää olla nimetty vastuuhenkilö. Kumppanin puolella hän vastaa toteutuksesta ja kertoo edistymisestä. Teidän puolellanne hän tekee päätökset ja varmistaa, että oikeat ihmiset ovat saatavilla.

Moni projekti hidastuu ostajan päässä. Kysymykseen ei löydy vastaajaa, tai päätös odottaa seuraavaa johtoryhmän kokousta. Sopikaa siksi etukäteen, mitkä päätökset tuoteomistaja voi tehdä itse ja mitkä nousevat ylemmäs.

Kumppanilta kannattaa kysyä suoraan, ketkä projektia oikeasti tekevät. Asiantuntijat, jotka tuntevat ympäristönne alusta asti, eivät tarvitse perehdytystä joka vaiheessa. Jos tiimi vaihtuu kesken, osa ymmärryksestä katoaa mukana. Soforin mallissa sama nimetty asiantuntijatiimi vastaa määrittelystä, toteutuksesta ja ylläpidosta. Vaadi myös säännöllinen katselmointi, jossa edistyminen näytetään toimivana ohjelmistona, ja tieto riskeistä heti, kun ne havaitaan.

Kenelle ohjelmisto ja lähdekoodi kuuluvat?

Omistus, käyttöoikeudet ja dokumentaatio sovitaan sopimuksessa ennen toteutusta. Ensimmäistä kertaa ohjelmistoa hankkiva yritys huomaa asian usein vasta, kun se haluaa jatkokehittää ratkaisua tai vaihtaa toimittajaa.

Lähdekoodin omistus ei ole aina yksiselitteinen. Kumppani voi käyttää valmiita komponentteja ja omaa sovelluskehitysalustaansa, mikä nopeuttaa toteutusta ja laskee hintaa. Silloin on sovittava, mikä osa koodista siirtyy teille ja mihin osaan saatte pysyvän käyttöoikeuden. Kumpikin malli voi olla hyvä, kunhan se on kirjattu. Pyydä samalla tieto kolmannen osapuolen komponenteista ja niiden lisensseistä.

Dokumentaatio on toinen puoli omistajuutta. Ilman sitä ohjelmisto on käytännössä yhden tekijän varassa, vaikka koodi olisi teidän. Varmistakaa myös, että tunnukset, ympäristöt ja koodivarasto ovat teidän nimissänne.

Mitä ensimmäisen ohjelmistoprojektin jälkeen tapahtuu?

Projektin jälkeen ohjelmisto siirtyy ylläpitoon, ja ylläpidon ehdot kannattaa sopia ennen käyttöönottoa. Ohjelmisto tarvitsee päivityksiä, valvontaa ja korjauksia, ja käyttäjät keksivät käytön myötä uusia tarpeita.

Ensimmäisen ohjelmistoprojektin yleisin yllätys on, että projekti ei pääty julkaisuun. Käyttöympäristö, tietoturvapäivitykset ja integroidut järjestelmät muuttuvat jatkuvasti. Jos ylläpidosta ei ole sovittu, ensimmäinen häiriö ratkaistaan kiireessä, eikä kukaan tiedä, kuka siitä vastaa.

Vaadi ylläpitosopimus, jossa on vasteajat, vastuut ja hinnoitteluperuste, sekä sovittu tapa kerätä ja priorisoida jatkokehitystarpeet. Varatkaa ylläpidolle budjetti jo projektibudjetin rinnalle ja nimetkää sisäinen omistaja, joka vastaa ratkaisusta käyttöönoton jälkeen.

Hyvässä sovelluskehityskumppanuudessa ylläpito on osa kokonaisuutta. Soforilla jokaiseen tehtyyn sovellukseen liittyy aina sovellusylläpito, ja käytössä havaitut kehitystarpeet palaavat suunnitteluun. DXF-siivouksen ratkaisu rakennettiin alusta asti laajennettavaksi, joten siihen voi lisätä uusia tietokenttiä ja tiedostotyyppejä rakentamatta pohjaa uudelleen.

Miksi tarkka vaatimusmäärittely ei yksin riitä?

Ensimmäistä ohjelmistoprojektia valmisteleva yritys haluaa usein kirjata kaiken etukäteen, jotta hinta ja lopputulos olisivat varmoja. Ajatus on ymmärrettävä. Käytännössä paksukin määrittely jättää aukkoja, koska tarpeet tarkentuvat vasta, kun käyttäjä näkee ensimmäisen toimivan version.

Turvallisuus syntyy rakenteesta. Rajattu ensimmäinen vaihe, mitattava tavoite, sovitut hyväksymiskriteerit ja lyhyt palautesykli pitävät riskin pienenä silloinkin, kun kaikkea ei tiedetä alussa. Kiinteä tavoite ja joustava toteutustapa vievät yleensä paremmin perille kuin kiinteä määrittely.

Muistilista ensimmäiseen tapaamiseen ohjelmistokumppanin kanssa

Näillä kysymyksillä näet nopeasti, miten kumppani aikoo hoitaa ensimmäisen projektinne.

1. Millainen olisi rajattu ensimmäinen vaihe, ja mitä se maksaa?
2. Miten perehdytte prosessiimme ennen hinta-arviota?
3. Miten hyväksymiskriteerit sovitaan, ja kuka ne kirjaa?
4. Ketkä projektia tekevät, ja pysyvätkö he samoina ylläpidossa?
5. Miten näemme edistymisen projektin aikana?
6. Kenelle lähdekoodi kuuluu, ja mitä valmiita komponentteja käytätte?
7. Mitä dokumentaatiota toimitukseen kuuluu?
8. Mitä ylläpitoon kuuluu, ja miten jatkokehitys hinnoitellaan?

Jos kumppani vastaa näihin konkreettisesti jo ensimmäisessä tapaamisessa, olette hyvässä alussa. Sofor toteuttaa ohjelmistoprojekteja yrityksille niin, että sama nimetty tiimi kulkee mukana määrittelystä ylläpitoon.