Sådan gennemfører du et projekt med hurtig prototypeudvikling
Hurtig prototyping kan være et nyttigt værktøj for os som digitale projektledere til at hjælpe kunder, der stiller spørgsmålene: »Men vil det fungere?« og »Hvordan vil det fungere?« Ofte er det enkle, men frustrerende svar ganske enkelt: »Det ved vi ikke endnu – men lad os hjælpe jer med at finde ud af det.« En god måde at finde ud af det på, og en metode, der bliver stadig mere populær blandt bureauer og kunder, er hurtig prototyping – at investere en smule for at træffe en informeret beslutning om produktets levedygtighed, før man foretager større investeringer.
Vores branche bevæger sig med lynets hast, og som digital projektleder skal vi hurtigt kunne tilpasse os nye arbejdsmetoder. Et aktuelt eksempel på dette er hurtig prototyping. For ni måneder siden havde jeg aldrig arbejdet på et projekt med hurtig prototyping, og nu har jeg netop afsluttet mit fjerde projekt med hurtig prototyping for hurtigt at teste produktets levedygtighed. Så hvis du ikke allerede har arbejdet på et projekt med hurtig prototyping, er jeg ikke i tvivl om, at et sådant projekt snart dukker op for dig.
Dette indlæg forklarer forskellige måder at undersøge et produkts levedygtighed på og giver dig nogle vejledende principper, der kan hjælpe dig med at styre hurtigt bevægende digitale eller analoge projekter med selvtillid.
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: Hvad er hurtig prototyping?
Hurtig prototyping henviser til den proces, der anvendes til at udvikle et konceptbevis eller hurtige prototyper. En prototype er god til at teste gyldigheden af et koncept. Den gør det muligt for dig at udvikle flere funktioner hurtigere, men det sker normalt på bekostning af kvaliteten, og derfor vil produktet for det meste være til engangsbrug.
Prototyper findes i forskellige former og størrelser
Selvom der er forskellige måder, hvorpå du kan undersøge et produkts levedygtighed, er her tre tydeligt forskellige tilgange:
- Konceptbevis – Et konceptbevis er en meget enkel demonstrator af produktet, som er beregnet til at blive kasseret, og som har til formål at teste idéen bag produktet, før det bygges.
- Hurtig prototype – En hurtig prototype er den første enkle version af produktet, som kan testes med rigtige brugere for at skabe større tillid til produktet, før den fulde udvikling går i gang.
- Minimum levedygtigt produkt (MVP) – Et MVP er den første produktionsklare version af produktet, hvor der opbygges fuldt fungerende funktioner til brugerne.
Din tillid til produktet bør være den vigtigste faktor, når du beslutter, hvilken tilgang du skal vælge.
Jo mere risikabel idéen er = desto hurtigere bør du gå frem.
Nogle vil måske sige, at hvis en idé er risikabel, bør du bruge mere tid på at tænke over den, før du bygger den. På nogle måder har de ret. Du kan validere et behov næsten uden at bygge noget. Der findes talrige eksempler på valideringstest, som det er værd at undersøge.
Men når du først ved, at der er et behov, er den eneste måde at bevise dette behov på at bygge noget, udgive det så hurtigt som muligt i sin råeste form, få feedback og gentage processen. Vi har adskillige gange oplevet, at kunden, når man undersøger en idé, uundgåeligt siger »Det ville jeg købe«, og at salget derefter ikke ændrer sig, når produktet lanceres.
»Det ville jeg helt sikkert købe« – 100 personer
Personer, der rent faktisk vil købe det = 10
Jeff Sheldon (@ugmonk) 1. september 2016
Hurtig prototyping reducerer risikoen hver gang ved at forkorte feedbacksløjfen og sikre, at du bygger et produkt, der kan sælges.
Sådan ved du, hvilken der er den rigtige for dig
| Prototypingstil | Tillid | Hvor falsk | Hvor meget til engangsbrug |
|---|---|---|---|
| Konceptbevis | Lav | Helt | Helt |
| Hurtig prototype | Mellem | Delvist | Delvist |
| Minimum levedygtigt produkt | Høj | Meget lidt/ingen | Bygget til at holde |
For at kunne bygge ting hurtigt skal du være åben over for at udvikle nye processer og arbejdsmetoder.
Vejledende principper for styring af projekter med hurtig prototyping
At arbejde på de måder, der er beskrevet nedenfor, kræver en ny tankegang. Jeg vil anbefale, at du indleder dit projekt med et internt opstartsmøde for at gennemgå disse principper og forklare, hvorfor de er vigtige. Det vil hjælpe med at sikre, at hele teamet er afstemt fra starten, ved, hvad der forventes af dem, og er klar over, hvor og hvorfor projektet kan adskille sig fra det, de er vant til.
1. Vær forberedt på at gøre mindre
Det vil sandsynligvis betyde mindre indledende planlægning, end du er vant til, og at du skal være tryg ved at:
- Ingen eller minimale acceptkriterier
- Ingen underopgaver på historier
- Ingen estimater
Det, du mister i en rigid proces, vinder du i hastighed, tillid og kommunikation. Omfavn manglen på kontrol.
Dette princip vil minde hele teamet om, at det er okay at opgive velkendte processer på bekostning af at levere fungerende software tidligere. Det er godt regelmæssigt at spørge sig selv og teamet: “er dette den hurtigste måde at gøre x på?”.
2. Vis, fortæl ikke
Da du planlægger mindre på forhånd, kommer du til at tale og tegne mere under udviklingen. Du kan få brug for at udvide dine scrum-møder, så I kan tale lidt mere detaljeret om funktionen, før dit team begynder at bygge den den dag. Som man siger, siger et billede mere end tusind ord. Nogle gange er en skitse af siden, en indholdsmodel eller et diagram, der viser, hvordan systemet skal bygges, nok til at komme i gang med at bygge, hvorefter du kan iterere videre på det.
Dette princip vil skabe tillid hos dig og kunden. Alle nyder at se fremskridt, og når man regelmæssigt viser arbejdet, skabes der mulighed for rettidig feedback, hvilket derfor minimerer spild.
3. Bed om tilgivelse, ikke om tilladelse
I de fleste stringente softwareudviklingsprocesser er konsensus afgørende. Du ønsker, at produktejeren godkender acceptkriterierne, og som projektleder vil du vide, at dit team har forstået kravene, før der skrives en eneste linje kode.
Med hurtige prototyper er det vigtigt, at dit team føler sig bemyndiget til ganske enkelt at bygge det ud fra deres bedste forståelse, som den er på det tidspunkt, derefter vise deres arbejde så hurtigt som muligt, få feedback og iterere.
At opnå konsensus fra starten vil sænke tempoet, og arbejde går sjældent til spilde, hvis teamet viser, hvad de arbejder på, tidligt og ofte.
Dette princip er særligt nyttigt for udviklere. Det lægger ansvaret på dem for indledningsvist at arkitektere og bygge en funktion med begrænset ekstern indflydelse. Vi bygger ofte for meget og overkomplicerer tingene, fordi vi ikke altid ser den tekniske kompleksitet, der er involveret i vores anmodninger. Derfor er det en god tilgang at stole på, at udviklerne i teamet beslutter, hvad den mest basale implementering er, og bygge den først.
For at dette kan fungere, er det afgørende, at dine udviklere har en dyb forståelse af projektet, så de er i stand til at træffe de rigtige beslutninger for projektet og kun bygger lige det nødvendige.
4. Opmuntr altid teamet til at vise, hvad de arbejder på (selv hvis det er grimt)
Denne proces er inspireret af Government Digital Services' principper for prototyper.
Typisk viser vi kun kunder funktioner, når de er færdige. På projekter med hurtig prototyping er det vigtigt at vise dem, så snart de fungerer, så du kan minimere spild, iterere og ændre retning, hvis det er nødvendigt.
Få det til at fungere. Vis det.
Gør det flot. Vis det.
Få det til at skalere. Vis det.
Dette princip frigør teammedlemmer fra følelsen af, at de kun bør vise arbejde, når det er blevet gennemgået af en designer eller er blevet fuldt testet. Fejr arbejdet, mens det er undervejs.
5. Vælg fysiske processer frem for onlineprocesser
Med Brett Harneds ord styrer vi projekter med vores sind, ikke med vores værktøjer. Vær ikke bange for at opgive dine projektstyringsværktøjer. Visualiser arbejdet, brug en fysisk backlog, og hæng skitser, brugerflows og personaer op på væggen, så I kan holde scrum omkring den. Henvis ofte til den, og opmuntr folk til at tage ejerskab over at flytte kortene og fejre implementeringen af nye funktioner. Hvis din kunde ikke er placeret samme sted, så fotografér alt og del det hele på Slack, så de ikke bliver holdt udenfor.
Det kan være vanskeligt at afprøve en ny proces. Visualisering af arbejdet vil sandsynligvis fremkalde samtaler, som ikke ville finde sted, hvis I sad på Hangouts og kiggede på en digital tavle. Det vil hurtigt blive tydeligt, hvis et fysisk kort ikke er blevet flyttet i en dag, eller hvis der er for meget igangværende arbejde. Brug af fysiske processer giver et ekstra lag af gennemsigtighed, som du, tro mig, vil være evigt taknemmelig for, når alt føles uklart.
6. Vær fremragende over for hinanden
Det er naturligt at føle sig overvældet, når man forsøger at indarbejde en ny proces og arbejdsmetode, især når man også selv er ny i den. Gå dog forrest med selvtillid, og opmuntr teamet, når de har det svært. Lyt opmærksomt til deres bekymringer, og vær villig til at justere processen undervejs. Sørg for, at processen ikke lægger yderligere pres på dit team. Hurtig prototyping handler om at arbejde smartere, ikke hårdere.
Afhængigt af personlighederne på dit team vil nogle teammedlemmer tage imod denne nye arbejdsform, mens andre måske vil modsætte sig den. Vi lærer alle i forskelligt tempo, og hver fagdisciplin vil håndtere forskellige udfordringer, efterhånden som de vænner sig til at arbejde på en ny måde. Som PM skal du være opmærksom på dette og forsøge at skabe et støttende og trygt miljø for teamet – sæt jer sammen, drik te, og følg regelmæssigt op med alle for at se, hvordan det går.
7. Minimer forstyrrelser
Det kan nogle gange være svært som PM at vide, hvor du kan indgå kompromiser med en ny proces, og hvor du bør stå fast. Når det gælder accept af nye ændringer midt i et sprint, skal du fortsat sige fra og sige nej. Det er vigtigt, at dit team ikke bliver forstyrret, når et sprint begynder. At beskytte deres tid er det mest værdifulde, du kan gøre.
Dette princip giver teamet mulighed for at sige fra over for forespørgsler. Det er sandsynligt, at I kører sprint på én uge, og med så kort et tidsrum har I ikke råd til at spilde tid. Sørg for at få opbakning fra resten af virksomheden, så folk føler, at de kan udskyde interne møder eller yderligere ansvarsområder, så de kan koncentrere sig i den periode.
Få hurtig udvikling af prototyper til at fungere for dig
Jeg har oplevet, at denne nye tilgang til arbejdet er meget givende, selvom det til tider føltes kaotisk, rodet og ude af kontrol. Det er svært at vide, hvor og hvor meget du bør afvige fra din nuværende proces, men jeg vil opfordre dig til at eksperimentere, fejle hurtigt og være åben over for dit team om, hvad du har brug for fra dem.
Ved nogle lejligheder fjernede vi en central del af processen og genindførte den senere, fordi det blev tydeligt, at jeg havde svært ved at styre projektet uden den. På disse tidspunkter i projektet sørgede jeg for, at jeg tydeligt kunne forklare resten af teamet konsekvenserne af at fjerne denne proces. Som team diskuterede vi, om der var en anden måde, hvorpå jeg kunne få disse oplysninger. Hvis vi ikke kunne finde en bedre løsning, genindførte vi processen. Det er på tidspunkter som dette, at man høster fordelene ved at opbygge et støttende miljø præget af gensidig tillid og respekt. På hvert trin lærer vi, itererer og går videre som et samlet team.
Tak til Chris Thorpe for disse principper – alt, hvad jeg ved, skyldes ham.
