Slik gjennomfører du et prosjekt med rask prototyping
Rask prototyping kan være et nyttig verktøy for oss som digitale prosjektledere, slik at vi kan hjelpe kunder som stiller spørsmålene «Men vil dette fungere?» og «Hvordan vil dette fungere?» Ofte er det enkle, men frustrerende svaret ganske enkelt: «Det vet vi ikke ennå – men la oss hjelpe deg med å finne det ut.» En god måte å finne det ut på, og en metode som blir stadig mer populær blant byråer og kunder, er rask prototyping – å investere litt for å ta en informert beslutning om produktets levedyktighet før man gjør store investeringer.
Bransjen vår beveger seg i lynfart, og som digital prosjektleder må vi være raske til å tilpasse oss nye arbeidsmetoder. Et aktuelt eksempel på dette er rask prototyping. For ni måneder siden hadde jeg aldri jobbet med et prosjekt for rask prototyping, og nå har jeg nettopp fullført mitt fjerde prosjekt for rask prototyping for å teste produktets levedyktighet raskt. Så hvis du ikke allerede har jobbet med et prosjekt for rask prototyping, er jeg ikke i tvil om at et slikt prosjekt snart dukker opp for deg.
Dette innlegget forklarer ulike måter å undersøke produktets levedyktighet på og gir deg noen veiledende prinsipper som kan hjelpe deg med å håndtere digitale eller analoge prosjekter i høyt tempo med selvtillit.
Continue Reading for Free
Create a free account to finish this article, plus get ongoing access to timely insights and practical resources.
Have an account? Log In
Men først: Hva er rask prototyping?
Rask prototyping viser til prosessen som brukes til å utvikle et konseptbevis eller raske prototyper. En prototype er nyttig for å teste om et konsept er gyldig. Den gjør det mulig å utvikle flere funksjoner raskere, men dette skjer vanligvis på bekostning av kvaliteten, og derfor vil produktet for det meste være til engangsbruk.
Prototyper finnes i ulike former og størrelser
Selv om det finnes flere måter å undersøke produktets levedyktighet på, er dette tre tydelige tilnærminger:
- Konseptbevis – Et konseptbevis er en svært enkel demonstrasjon av produktet som er ment å kastes, og som brukes til å teste ideen bak produktet før det bygges.
- Rask prototype – En rask prototype er en enkel første versjon av produktet som kan testes med reelle brukere for å få større trygghet for produktet før den fullstendige utviklingen.
- Minimum levedyktig produkt (MVP) – Et MVP er den første versjonen av produktet med produksjonskvalitet, der man bygger opp fullt fungerende funksjoner for brukerne.
Hvor trygg du er på produktet, bør være den viktigste faktoren når du avgjør hvilken tilnærming du skal velge.
Jo større risiko ideen innebærer = desto raskere bør du gå frem.
Noen vil kanskje si at hvis en idé innebærer risiko, bør du bruke mer tid på å tenke gjennom den før du bygger den. På noen måter har de rett. Du kan validere et behov nesten uten å bygge noe som helst. Det finnes utallige eksempler på valideringstesting som det er verdt å undersøke.
Men når du først vet at det finnes et behov, er den eneste måten å bevise dette behovet på å bygge noe, lansere det så raskt som mulig i sin enkleste form, få tilbakemeldinger og gjenta prosessen. Vi har opplevd utallige ganger at når du undersøker en idé, vil kunden uunngåelig si «Dette ville jeg kjøpt», men når produktet lanseres, øker ikke salget.
«Dette ville jeg definitivt kjøpt» – 100 personer
Personer som faktisk vil kjøpe det = 10
Jeff Sheldon (@ugmonk) 1. september 2016
Rask prototyping reduserer risiko hver gang ved å forkorte tilbakemeldingssløyfen og sørge for at du bygger et produkt som vil selge.
Slik vet du hvilken som passer for deg
| Prototypingstil | Trygghet | Hvor falsk | Hvor mye til engangsbruk |
|---|---|---|---|
| Konseptbevis | Lav | Helt | Helt |
| Rask prototype | Middels | Delvis | Delvis |
| Minimum levedyktig produkt | Høy | Svært lite/ingen | Bygget for å vare |
For å kunne bygge ting raskt må du være åpen for å utvikle nye prosesser og arbeidsmetoder.
Veiledende prinsipper for å håndtere prosjekter med rask prototyping
Å arbeide på måtene som er beskrevet nedenfor, krever en ny tankegang. Jeg anbefaler at du starter prosjektet med et internt oppstartsmøte for å gå gjennom disse prinsippene og forklare hvorfor de er viktige. Dette vil bidra til å sikre at hele teamet er samkjørt fra starten, vet hva som forventes av dem, og er klar over hvor og hvorfor prosjektet kan skille seg fra det de er vant til.
1. Vær forberedt på å gjøre mindre
Dette vil sannsynligvis bety mindre planlegging i forkant enn du er vant til, og innebære at du må være komfortabel med å ha:
- Ingen eller minimale akseptansekriterier
- Ingen deloppgaver i brukerhistoriene
- Ingen estimater
Det du mister i en rigid prosess, vinner du igjen i hastighet, tillit og kommunikasjon. Omfavn mangelen på kontroll.
Dette prinsippet vil minne hele teamet på at det er greit å forkaste velkjente prosesser for å kunne levere fungerende programvare raskere. Det er lurt å jevnlig spørre seg selv og teamet «er dette den raskeste måten å gjøre x på?».
2. Vis, ikke fortell
Siden du planlegger mindre på forhånd, kommer du til å snakke og tegne mer under utviklingen. Det kan være lurt å utvide scrum-møtene slik at dere kan snakke litt mer detaljert om funksjonen før teamet begynner å bygge den den dagen. Som ordtaket sier, sier et bilde mer enn tusen ord. Noen ganger er en skisse av siden, en innholdsmodell eller et diagram som viser hvordan systemet skal bygges, nok til å komme i gang, og deretter kan du iterere videre på dette.
Dette prinsippet vil skape trygghet hos deg og kunden. Alle liker å se fremgang, og det å vise frem arbeidet regelmessig gir mulighet for tilbakemeldinger i tide, noe som dermed reduserer sløsing.
3. Be om tilgivelse, ikke tillatelse
I de fleste grundige programvareutviklingsprosesser er enighet avgjørende. Du ønsker at produkteieren skal godkjenne akseptansekriteriene, og som prosjektleder vil du vite at teamet ditt har forstått kravene før de skriver en eneste kodelinje.
Med raske prototyper er det viktig at teamet ditt føler seg bemyndiget til å bygge det slik de best forstår det på det tidspunktet, for så å vise frem arbeidet så raskt som mulig, innhente tilbakemeldinger og iterere.
Å oppnå enighet fra starten vil forsinke arbeidet, og arbeid går sjelden til spille hvis teamet viser hva de jobber med, tidlig og ofte.
Dette prinsippet er særlig nyttig for utviklere. Det legger ansvaret på dem for først å utforme og bygge en funksjon med liten ekstern påvirkning. Vi bygger ofte for mye og kompliserer ting unødvendig fordi vi ikke alltid ser den tekniske kompleksiteten som ligger i forespørslene våre. Derfor er det en god fremgangsmåte å stole på at utviklerne i teamet avgjør hva den enkleste implementeringen er, og bygger dette først.
For at dette skal fungere, er det avgjørende at utviklerne dine har en dyp forståelse av prosjektet, slik at de kan ta de riktige beslutningene for prosjektet og bare bygger akkurat nok.
4. Oppmuntre alltid teamet til å vise hva de jobber med (selv om det er stygt)
Denne prosessen er inspirert av prototypingsprinsippene fra Government Digital Services.
Vanligvis viser vi bare kundene funksjoner når de er ferdige. I prosjekter med rask prototyping er det viktig å vise dem så snart de fungerer, slik at du kan redusere sløsing, iterere og endre retning ved behov.
Få det til å fungere. Vis frem saken.
Gjør den pen. Vis frem saken.
Få den til å skalere. Vis frem saken.
Dette prinsippet fritar teammedlemmene fra følelsen av at de bare bør vise frem arbeid når det er gjennomgått av en designer eller ferdig testet. Feir arbeid som pågår.
5. Velg fysiske prosesser fremfor nettbaserte
Som Brett Harned sier, styrer vi prosjekter med tankene våre, ikke med verktøyene våre. Ikke vær redd for å legge bort prosjektstyringsverktøyene dine. Visualiser arbeidet, bruk en fysisk oppgaveliste, fest skisser, brukerflyter og personaer på veggen, og ha scrum-møtene rundt den. Se på den ofte, og oppmuntre folk til å ta eierskap til å flytte kortene og feire utrullingen av nye funksjoner. Hvis kunden din ikke sitter sammen med dere, kan du fotografere alt og dele det på Slack, slik at de ikke blir holdt utenfor.
Det kan være vanskelig å prøve ut en ny prosess. Å visualisere arbeidet vil sannsynligvis sette i gang samtaler som ikke ville ha oppstått hvis dere satt i Hangouts og så på et digitalt brett. Det blir raskt tydelig hvis et fysisk kort ikke har blitt flyttet på en dag, eller hvis det er for mye arbeid som pågår. Fysiske prosesser gir et ekstra lag med åpenhet som du, tro meg, vil være evig takknemlig for når alt føles uklart.
6. Vær fantastiske mot hverandre
Det er naturlig å føle seg overveldet når du prøver å innføre en ny prosess og arbeidsmåte, særlig når den også er ny for deg. Led likevel med trygghet, og oppmuntre teamet når de sliter. Lytt oppmerksomt til bekymringene deres, og vær villig til å justere prosessen underveis. Sørg for at prosessen ikke legger ekstra press på teamet ditt. Rask prototyping handler om å jobbe smartere, ikke hardere.
Avhengig av personlighetene i teamet ditt vil noen teammedlemmer omfavne denne nye arbeidsmåten, mens andre kanskje vil motsette seg den. Vi lærer alle i ulikt tempo, og hver fagdisiplin vil håndtere ulike utfordringer når de tilpasser seg å arbeide på en ny måte. Som PM bør du være oppmerksom på dette og forsøke å skape et støttende og trygt miljø for teamet – sitt sammen, drikk te og følg jevnlig opp alle for å se hvordan det går med dem.
7. Minimer forstyrrelser
Det kan noen ganger være vanskelig å vite hvor du som PM kan inngå kompromisser med en ny prosess, og hvor du bør stå fast. Når det gjelder å akseptere nye endringer midt i en sprint, bør du fortsette å si imot og si nei. Det er viktig at teamet ditt ikke blir forstyrret når en sprint starter. Å beskytte tiden deres er det mest verdifulle du kan gjøre.
Dette prinsippet gir teamet mulighet til å si imot forespørsler. Det er sannsynlig at dere gjennomfører sprinter på én uke, og med et så kort tidsvindu har dere ikke råd til å miste tid. Sørg for støtte fra resten av selskapet, slik at folk føler at de kan utsette interne møter eller andre ansvarsområder og konsentrere seg fullt ut i denne perioden.
Slik får du hurtig prototyping til å fungere for deg
Jeg har opplevd denne nye arbeidsmåten som svært givende, selv om den til tider føltes kaotisk, rotete og ute av kontroll. Det er vanskelig å vite hvor og hvor mye du bør avvike fra den nåværende prosessen din, men jeg vil oppfordre deg til å eksperimentere, mislykkes raskt og være åpen med teamet ditt om hva du trenger fra dem.
Ved enkelte anledninger fjernet vi en sentral del av prosessen og innførte den senere på nytt fordi det ble tydelig at jeg hadde problemer med å styre prosjektet uten den. På disse stadiene i prosjektet sørget jeg for at jeg tydelig kunne forklare resten av teamet mitt konsekvensene av å fjerne denne prosessen. Som team diskuterte vi om det fantes en alternativ måte for meg å få denne informasjonen på. Hvis vi ikke fant en bedre løsning, innførte vi prosessen på nytt. Det er i slike situasjoner man høster fordelene av å ha bygget et støttende miljø preget av gjensidig tillit og respekt. På hvert tidspunkt lærer vi, forbedrer oss trinnvis og går videre som ett samlet team.
Takk til Chris Thorpe for disse prinsippene – alt jeg vet, vet jeg takket være ham.
