Blogi | Teknologia

Sovelluksen ensimmäiseen versioon vain olennainen

Sovelluksen ensimmäiseen versioon valitaan pienin kokonaisuus, jolla käyttäjä voi tehdä tärkeän tehtävän alusta loppuun. Rajaus ei tarkoita keskeneräisen toiminnan hyväksymistä, vaan sivuun jätettävien tarpeiden tietoista valintaa.

Kirjoita yksi käyttäjän tavoite

Kuvaa kuka käyttää sovellusta, missä tilanteessa ja mitä hänen pitää saada aikaan. Esimerkiksi huoltotyön tilaaminen sisältää tarpeen ilmoittamisen, tarvittavat tiedot ja tiedon siitä, että pyyntö on vastaanotettu. Pelkkä lomakkeen lähetysnappi ei vielä muodosta koko käyttäjäpolkua.

Lisää välttämättömät poikkeukset: mitä tapahtuu, jos tieto puuttuu, lähetys epäonnistuu tai pyyntöä pitää muuttaa? Näiden käsittely voi olla tärkeämpää kuin uusi lisäominaisuus.

Jaa ominaisuudet päätöksen perusteella

Merkitse välttämättömät osat, kokeilussa selvitettävät asiat ja myöhemmäksi siirrettävät toiveet. Perustele jokainen ensimmäiseen versioon tuleva toiminto käyttäjän tehtävällä.

Raportointi, automaatio ja laajat asetukset voivat joskus odottaa. Turvallista käyttöä, tiedon säilymistä tai olennaista saavutettavuutta ei kuitenkaan pidä käsitellä pelkkänä myöhempänä koristeena. Soveltuvat vaatimukset arvioidaan palvelun käyttötarkoituksen mukaan.

Sovi hyväksymisen esimerkit

Pyydä toimittajan kanssa konkreettiset tilanteet, joilla toteutus hyväksytään. Käyttäjän pitäisi pystyä kokeilemaan sama tehtävä kuin alussa kuvattiin. Määrittele myös kokeilun havainnot ja se, kuka päättää seuraavasta kehitysvaiheesta.

Sovelluskehityksen tarjous voidaan pyytää tälle rajatulle kokonaisuudelle. Jos tärkein tehtävä ei vielä ole selvä, tilaa ensin suunnittelu tai prototyyppi. Se voi tuottaa paremman hankintapäätöksen kuin laaja ominaisuuslista, jonka osien tarpeellisuutta kukaan ei ole testannut.