Slik skaper du verdi raskere
Smidig prosess er løsningen, skrev vi tidligere. Det mener vi fortsatt! Med litt mer fartstid med smidige prosjekter, vil vi dele noen aspekter vi synes det er viktig å ta med seg.
Nøkkelen er å bryte ned det vi skal lage i mindre biter, og tørre å lansere en første versjon som ikke inneholder alt man drømmer om, eller nødvendigvis alt man har hatt fra før. Det vi skal lage bør også tuftes på brukerinnsikt og strategiske mål, som forankres i hele teamet, fremfor lange, gamle kravspesifikasjoner som fokuserer på funksjonalitet og teknologi fremfor menneskelige behov.
Mer fokus på det som faktisk skaper verdi
Fordelene med et mindre omfang er mange. Vi kan raskere lansere noe nytt – og vi kan kjapt lære gjennom møter med menneskene som skal bruke løsningen, før vi jobber videre med nye funksjoner. Det gjør det også mer fleksibelt og lettere å justere kursen underveis i prosessen, siden vi jobber avgrenset med utvalgte oppgaver, og ikke begynner på for mye for tidlig. I tillegg slipper vi å bruke tid (og penger!) på funksjonalitet som ikke er etterspurt/viktig for brukerne – men i stedet klarer å fokusere på det som skaper verdi.
I et slikt utviklingsløp, er det ønskelig å bruke tiden til rådighet på de tingene som vil skape mest verdi. Men hvordan vurderer man det, og hvordan går man frem for å finne ut hva som må lages først, og hva som faktisk kan vente?
MVP og MAP
Mange benytter MVP som begrep for den første versjonen av et produkt eller en tjeneste. MVP står for Minimum Viable Product, og kan oversettes til minste brukbare produkt. Dette er det minste vi kan utvikle, for å finne ut om vi i det hele tatt er på rett kurs ( – og deretter justere).
Det vi leverer, skal være bra nok for det målet som er satt. En MVP kan enten være en enkel løsning som vi slipper live – eller en prototype som vi tester.
I Increo har vi også omfavnet begrepet MAP, som står for Minimum Awesome Product. Dette er det minste vi kan bygge, som skaper høyest mulig verdi. Det vi bygger skal være awesome! Funksjonalitet vi er usikre på kan vi anbefale å vente med – men det vi lager skal være av god kvalitet både i kode og design. Når vi skal utvikle en ny versjon av en nettside som finnes fra før, er det MAP-begrepet som gjelder, men er det snakk om et helt nytt produkt eller tjeneste som skal testes, er det behov for en MVP.
Finn ut hva som gir verdi for bedriften – og på hvilken måte
Begrepet Verdi er stort, og når vi spør – ”hva er viktigst å prioritere nå” – kan det være fort gjort å tenke tilbake på det møtet du hadde i går hvor referansegruppa etterlyste akkurat den funksjonen, eller på kunden du snakket med i morges som spurte hvor det ble av den andre funksjonen. Så for å lettere kunne teste prioriteringene, kan det være greit med en begrepsavklaring.
Det finnes flere definisjoner av verdi, og vi tror det er viktig å forstå at verdi kan handle om mer enn “bare” penger. Vi tror videre at verdi stort sett finnes i disse fem typene:
- Kommersiell: Økt inntjening
- Marked: Tiltrekke flere kunder/nye markeder
- Effektivitet: Spare tid, gjøre ting på en smartere måte
- Kunden: Økt kundelojalitet og tilfredshet
- Fremtidig: Langsiktige valg som sparer penger på sikt
Dersom det er vanskelig å plassere ideen i en av disse – ja, da er det kanskje fornuftig å ta en liten tenkepause, dersom du (og det vil jo de fleste) vil bruke pengene du har til rådighet best mulig.
Verdibegrepet kan du lese mer om her
Synliggjør verdien ved bruk av brukerhistorier
De aller fleste oppgaver vi gjør, ender med et grensesnitt mot en sluttbruker. For å synliggjøre oppgavenes verdi (og hensikt), er brukerhistorier et nyttig hjelpemiddel. Brukerhistorier er et format for å beskrive oppgaver som vektlegger en oppgaves verdi og kriterier for ferdigstilling/aksept. De er “hands on” og handler om hva brukeren skal kunne gjøre i den digitale løsningen vi lager.
Brukerhistorier vil gi deg som kunde, designer, utviklere og testere – ja alle – en felles forståelse av en oppgave og hvorfor vi gjør det vi gjør. Et slikt felles format gjør at det blir lettere å snakke om de ulike oppgavene, og å foreta prioriteringer – samtidig som at brukerperspektivet beholdes gjennom alle ledd.
En brukerhistorie kan formuleres enkelt og greit slik:
Som en <bruker> vil jeg <hva> slik at <verdi>
Noen eksempler på brukeroppgaver:
- Som en proff-kunde vil jeg kunne søke etter varenummer slik at jeg raskt kan handle riktig produkt
- Som privatkunde vil jeg kunne be om varsling når utsolgte produkter er på lager slik at jeg kan bestille de når de er tilgjengelig
- Som Spare-Stine, vil jeg sammenligne priser for ulike produkter, slik at jeg kan ta et prisbevisst valg
- Som en admin vil jeg få en oversikt over nye meldinger som kommer inn i systemet, slik at jeg kan videresende til en ansatt med riktig kompetanse og språkprofil
Prioriter etter verdi og innsats
Ofte kan det være snakk om et stort sett med brukerhistorier, og da er det nødvendig å gjøre prioriteringer. Vi må da prøve å besvare hva som er minimum av det vi trenger før lansering (og hva vi kan vente med). Ofte er det dessuten slik at en del funksjonalitet må man ha, mens andre oppgaver og behov er ting man bør eller kan ha (men som ikke er avgjørende før man går live).
For å få litt struktur i prioriteringene kan et tips være å se på hvor mye verdi man antar de ulike oppgavene vil skape (for eksempel ved bruk av en skala fra 1-10). Om man sammenstiller dette med hvor omfattende det er å realisere oppgavene (for eksempel ved å vurdere oppgavens størrelse; er det en S, M, L eller XL oppgave?) vil man få god hjelp i prioriteringsarbeidet.
Gap ikke over mer enn du kan spise. Fokus bør være på kvalitet og ikke kvantitet. Fokuser på det vi må ha – det som skaper høyest verdi – fordi “to deliver more, deliver less!”
Trenger du hjelp til utvikling av en MVP eller en MAP? Vi hjelper deg gjerne med å skape verdi for deg og brukerne dine.
