fbpx

Räätälöidyt liiketoimintaratkaisut

Kokeile, testaa ja toimi tulosten perusteella

Kokeile, ja käytä vielä kerran suunnittelupöydän kautta

Piirtäisitkö minulle talon, jossa on kolme ikkunaa, katto ja ovi? Mielellään punaisen. Kiitos!

Arkkitehdin on tässä vaiheessa kysyttävä vielä monta tarkentavaa kysymystä. Millaiset asukkaat talo saa, entä kuinka monta heitä on? Rakennetaanko talo kallion päälle vai savipatjalle? Millainen infrastruktuuri tontilla on; löytyykö kunnallistekniikkaa, vai pitääkö kaikesta huolehtia itse? Kuinka tiukasti kaava määrittää talon ulkomuodon?

Myös sovelluskehityksen alkuvaiheessa voi olla vaikeaa ymmärtää ja hahmottaa, miten esitetty idea, konsepti tai näkemys toimii käytännössä, kun kaikkia toiveita, tarpeita tai rajoituksia ei ole tiedossa, eikä piirustusta tai kokeiltavaa mallia ole.

Idean tai konseptin toimivuutta on hyvä testata ennen varsinaisen tekemisen aloittamista. Hankkeen haastavuus, laajuus tai esimerkiksi taustajärjestelmien monimutkaisuus voi muuten yllättää kesken kehitysprojektin.  Käyttäjien lukuisat toiveet, tarpeet ja vaatimukset voivat myös hukuttaa ydinajatuksen alleen, ja niiden priorisointi olla vaikeaa.

Koska järeä suunnittelutyö ja ohjelmistokehitys on aikaa vievää (ja harvoin myös halpaa), on järkevää aloittaa sovelluskehitys testaamalla ja varmistamalla, onko valittu lähestymistapa oikea.

Kaksi tapaa testata

Proof of Concept eli POC

Proof of Conceptissa uusi idea, malli tai oletus testataan pienimuotoisesti. POCin aikana voidaan esimerkiksi selvittää, onko toiminnallisuuden X toteutus mahdollinen, tai keskusteleeko teknologia X teknologian Y kanssa. Lopputuotteena syntyy selvitys tai dokumentti, joka tiivistää oletuslähtökohdan sekä POCin aikana tehdyt päätelmät jatkokehitysmahdollisuuksista.

Jos jatkamme talovertausta, POCin aikana arkkitehti olisi selvittänyt kunnallistekniikan ja kaavan vaatimukset, ja haastatellut asukkaat heidän toiveidensa kartoittamiseksi. Voidaanko unelmien talo ylipäätään toteuttaa, kyllä vai ei?

Lisätietoja Systems Gardenin tavasta toteuttaa Proof of Concept löytyy täältä.

Prototyyppi

Prototyypin rakentaminen taas on POCia laajempi harjoitus, jonka avulla visualisoidaan sovelluksen toimintaa. Sen lopputuotteena on malli, joka antaa käsityksen sovelluksen käyttöliittymästä, navigoinnista ja ulkoasusta. Prototyypit voivat niiden laajuuden mukaan olla luonnosmaisia, joskus paperille piirrettyjä hahmotelmia, tai interaktiivisia käyttöliittymädemoja.

Arkkitehti piirtäisi talon ensimmäisen prototyypin paperille, ja mahdollisesti rakentaisi talosta myös karkean pienoismallin.

Lue kuvauksemme prototyypin kehittämisestä täältä.

POC osoittaa, onko tuote, idea tai ominaisuus on jatkokehityskelpoinen, kun taas prototyyppi näyttää, kuinka se tehdään.

Ensimmäisiin prototyyppeihin ei ole tarkoitus sitoutua. Prototyyppi luodaan, sitä testataan ja kerätään tulokset, ja sen jälkeen hanke pyöräytetään vielä kerran suunnittelupöydän kautta. Prototyyppi on ennen kaikkea keino kerätä tietoa. Kuinka paljon työtä sovelluksen kehittäminen vaatii? Millaisilla teknologioilla se kannattaa rakentaa? Palveleeko lopputulos liiketoimintaa ja loppukäyttäjiä, entä onko hanke kokonaisuudessaan kannattava?

Kun kokeilut on kokeiltu?

Testauksen jälkeen hanke palautetaan takaisin suunnittelupöydälle, ja mietitään mitä tehdään, ja mitä kenties jätetään tekemättä.

Havainnot, tarpeet ja ominaisuudet kootaan suunnitelmaksi. Teemme yhdessä listan ominaisuuksista, jotka sovelluksessa on oltava. Niiden perusteella arvioimme tarvittavien sprinttikierrosten määrän, ja teemme työmääräarvion kierrosten määrään perustuen. POC tai proto tekee arviosta luotettavamman.

Kun suunnitelmasta ja toteutusarviosta on sovittu hyvässä yhteisymmärryksessä, edetään sprinttimallilla vaiheittain maaliin.

Kaikkia ominaisuuksia ei ole tarkoitus toteuttaa kerralla, vaan etenemme tuttuun Scrum-tyyliin pala kerrallaan.

Mikäli toiminnallisuuksien määrä lisääntyy projektin aikana, tai sprinttikierrosten määrä kasvaa, tuumimme yhdessä, miten haluttuun lopputulokseen päästään projektin tavoitteiden, aikataulun ja budjetin puitteissa.

Niin kuin talonrakennuksessakin, yllätyksiä saattaa tulla vastaan projektin aikana. Tärkeintä on säilyttää avoin keskusteluyhteys, ja yhdessä priorisoida tarpeita ja vaatimuksia projektin edetessä.

Alupro

Faktaan perustuvia päätöksiä visuaalisilla raporteilla

R-Office & Autokeskus

Digitaalinen huollon asiakaspalvelukokemus

Borenius Asianajotoimisto Oy

Uusi työkalu riskienhallintaan

Alupro

Tuottavuusloikka ja toimitusvarmuutta toiminnanohjausjärjestelmällä

Dekra

Toiminnanohjausjärjestelmä säästää kustannuksia

G4S

Manuaaliset tilausprosessit sähköisiksi

Kiinnostuitko? Ota yhteyttä!

Ota yhteyttä ja sovi etätapaaminen. Katsotaan minkälainen ratkaisu juuri sinun yrityksellesi sopisi.

Suvi

Suvi Ranttila
suvi.ranttila@systemsgarden.com
+358 40 657 5235

8 + 14 =