Räätälöidyt liiketoimintaratkaisut
Kokeile, testaa ja toimi tulosten perusteellaKokeile, 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
G4S
Kiinnostuitko? Ota yhteyttä!
Ota yhteyttä ja sovi etätapaaminen. Katsotaan minkälainen ratkaisu juuri sinun yrityksellesi sopisi.
Pirkka Paronen
pirkka.paronen@systemsgarden.com
+358 50 592 1207