Ohjelmistokehityksen ostajan opas

Ohjelmistoprojektien ostaminen on kaikkea muuta kuin helppoa. Vaatimukset ostajan osaamiselle ovat äärimmäisen korkealla ja hänen tulisi ymmärtää ainakin perusteet siitä, että minkälaisista osasista erilaiset ohjelmistoprojektit koostuvat.

Tämä sivu on luotu sitä tarkoitusta varten, että hyvän idean lisäksi sinulla on myös muut, tarvittavat työkalut projektin ostovaiheen määrittelyä varten.

Tutustu sivun sisältöön ja pyydä meiltä tarvittaessa kustannusarvio ohjelmistoprojektisi toteutuksesta.

Pyydä kustannusarvio projektistasi
Pyydä kustannusarvio projektistasi

Yksinkertainen ohjelmistokehityksen ostajan opas – Devolution Oy

Alta pääset tutustumaan olennaisimpiin asioihin joita ohjelmistoa ostaessa on hyvä pitää mielessä. Yritimme tiivistää asiat niin lyhyesti ja ytimekkäästi kuin suinkin osasimme, joten toivottavasti löydä täältä vastaukset kysymyksiisi.

Mikäli sinulla on monimutkaisempia kysymyksiä joihin kaipaisit henkilökohtaista apua niin jätä yhteydenottopyyntö tai soita. Autamme mielellämme ja olemme vain yhden klikkauksen päässä.

Budjetointi ja aikatauluttaminen

Epärealistinen aikataulu, hintapaine ja ominaisuuksien karsiminen eivät tee projektista pitkässä juoksussa yhtään halvempaa – päinvastoin. Mikäli halutut ominaisuudet halutaan saada valmiiksi liian kireässä aikataulussa tai turhan tiukalla budjetilla, lopputulos on yleensä sellainen, että sitä joudutaan paikkaamaan vielä pitkän aikaa projektin päättymisen jälkeen. Yleensä myös kustannukset ovat ennakoitua korkeammat.

Mikäli päätavoite on tuottaa mahdollisimman toimiva, kehityskelpoinen, laadukas ja asiakkaille arvoa tuottava kokonaisuus, on budjettia ja aikataulua mahdotonta lukita projektin alkuvaiheessa. Jonkinlaiset raamit täytyy tietysti olla olemassa, mutta tarkemmat tavoitteet on mahdollista lukita vasta aloituksen jälkeen.

Ohjelmistoprojektin rakenne

Ohjelmistossa on harvoin kyse yhdestä yksittäisestä ulottuvuudesta. Useimmiten tarvitaankin paitsi monipuolista koodia, myös joukko erilaisia komponentteja. Tyypillisessä projektissa on mukana ainakin seuraavat ulottuvuudet:

  • Konseptointi, ideointi ja palvelumuotoilu
  • Backlog
  • Versionhallinta
  • Rajapinnat
  • Käyttöliittymäsuunnittelu (UI/UX)
  • CI/CD putken rakentaminen
  • Serverit ja erilaiset pilvipalveluratkaisut
  • Ohjelmiston- ja ohjelmistokomponenttien kehitys
  • Testaus ja laadunvarmistus

Projektin määrittely ja haasteet

Onko termi MVP tuttu? Se tulee sanoista “minimum viable product”. MVP on ajatustyökalu, jonka avulla pyritään heti projektin alkuvaiheessa listaamaan kriittisimmät osaset, jotka toimiva lopputuote tarvitsee. Kaikki muu riisutaan käytännössä pois.

MVP listaa ne ominaisuudet, jotka tekevät tuotteesta mahdollisimman yksinkertaisen sekä kilpailijoista erottuvan kokonaisuuden. Sisältö on aina projektikohtainen, mutta yleensä se sisältää seuraavat elementit:

  1. Keskeiset toiminnallisuudet (esim. tärkeät käyttötapaukset)
  2. Perus käyttöliittymä (käyttäjien tulee pystyä kokeilemaan tuotetta)
  3. Perus tekninen alusta (peruskomponentit jotka mahdollistavat tuotteen toiminnan)
  4. Testattavat hypoteesit (esim. tietyn käyttäjäryhmän tarpeiden tyydyttäminen)

Projektitiimi

Tärkein yksittäinen projektissa mukana oleva henkilö ei ole toteuttava koodari, se on kokenut, laajan ohjelmistokehitystaustan omaava projektipäällikkö. Tämä on se henkilö, joka on vastuussa ohjelmiston arkkitehtuurista, laadun varmistuksesta sekä ennen kaikkea toimivan kokonaisuuden suunnittelusta ja projektin pilkkomisesta osakokonaisuuksiin.

Kun projekti on suunniteltu ja purettu järkeviin osakokonaisuuksiin kokeneen ohjelmistokehittäjän toimesta, toteutettavat osakokonaisuudet on helppo jakaa tuoreiden ohjelmistokehittäjien työpöydille.

Valitettavasti toteuttavan yrityksen koko ei usein korreloi projektissa mukana olevien henkilöiden kompetenssiin tai kokemukseen. Hyvin usein tilanne on itse asiassa se, että isoilla toimijoilla projektissa mukana olevat avainhenkilöt ovat suhteellisen tuoreita tekijöitä.

Teknologiavalinnat

Kokenut projektipäällikkö osaa aina perustella miksi projekti tulee hänen mielestään toteuttaa tietyllä tavalla tai teknologialla. Usein projektipäällikkö osaa ehdottaa myös vaihtoehtoisia toteutustapoja tai ainakin kertoa, että miksi niitä ei kannata hyödyntää.

Modernissa ohjelmistokehityksessä toimitaan yleensä seuraavien teknologioiden parissa:

  1. Pilvipalvelut (AWS, Azure, Google Cloud)
  2. Käyttöliittymäkehitys (React, Angular, Vue)
  3. Tietokantateknologiat (MySQL, PostgreSQL, MongoDB)
  4. Kehitystyökalut (Visual studio code, Atom, Sublime text)
  5. Automaattiset testaus- ja integrointityökalut (Jenkins, CircleCI)
  6. Versionhallinta (Git, Mercurial)
  7. Ohjelmointikielet (Javascript, Python, C++)

Laadunvarmistus

Ainoa tapa varmistua ominaisuuden tai koodin toimivuudesta tapahtuu testaamalla. Meillä onkin periaate, että mikäli koodia tai ominaisuuksia ei ole testattu, niitä ei ole olemassa.

Testiautomaatio-, CI/CD- ja DevOps-periaatteet ovatkin erottamaton osa nykyaikaista ohjelmistokehitystä. Kun edellä mainitut toimintamallit ovat alusta asti mukana, on projektin aikana mahdollista tehdä nopeita kokeiluja ja ne päästään myös demoamaan välittömästi asiakkaan suuntaan.

Hinnoittelu (toteutuneen työn mukaan)

Kokemuksen kautta olemme havainneet, että ohjelmistokehityksessä on ainoastaan 2 järkevää tapaa hinnoitella projektit:

  1. Tuntihinta toteutuneen työn mukaan
  2. Tehtäväperusteiset maksut itse kehittämämme toimintatavan mukaisesti.

Kuten kappaleessa “budjetointi ja aikatauluttaminen” käytiin läpi, projektin muotoa tai lopputulosta on täysin mahdotonta lukita 100% vielä alkuvaiheessa. Ketterän kehityksen periaatteita noudatettaessa, toimivin tapa hinnoitteluun tapahtuukin toteutuneiden tuntien perusteella. Ellei kyseessä ole hyvin pieni ja yksinkertainen sovellus.

Hinnoittelu (tehtäväperusteiset maksut)

Tehtiin projekti sitten tuntihinnalla tai prosessimme mukaan, kehitys etenee aina “sprinteissä”. Nämä ovat 1-4 viikkoa kestäviä kehitysjaksoja. Yksittäinen sprintti alkaa sillä, että sen sisältö suunnitellaan yhdessä ostajan kanssa. Lopetus puolestaan tapahtuu aina ostajalle esitettyyn demoon, jossa on helppo päättää, että aloitetaanko uusi sprintti vai lopetetaanko projekti tähän.

Ostajan kannalta tämä on äärimmäisen riskitön eteneminen. Asiakkaan ei tarvitse koskaan ostaa valmista projektia, vaan hän näkee kuinka työskentelymme toimii 1-2 viikkoa kestävän testijakson aikana. Mikäli työn etenemiseen tai laatuun ei olla tyytyväisiä, asiakkaan on helppo valita toinen toimija.

IPR oikeudet

Ainoa oikea tapa toimia on se, että projektin päättyessä kaikki oikeudet materiaaleihin ovat asiakkaalla. Muussa tapauksessa päädytään ns. “yhden toimittajan loukkuun”, jossa kaikki jatkokehitys on säänneltyä ja kallista.

Mikäli lähdekoodi sekä muut materiaalit on oikeasti tarkoitus antaa asiakkaan vapaaseen käyttöön, on enemmän kuin olennaista, että yksikkö- sekä muu testaus on toteutettu sisäänrakennettuna. Mikäli koodia ei ole testattu ja/tai se on huonosti dokumentoitua voi toimittajan vaihtaminen olla aiottua haastavampaa.