Føler du noen ganger at rollen din som utvikler kun handler om å levere kodelinjer? Kanskje har du vært i en situasjon der oppgavene fra backlog bare dumpes i fanget ditt, klare til implementering, uten rom for dine innspill? Denne måten å utvikle på kan være lite motiverende, og din tekniske innsikt blir heller ikke utnyttet til det fulle.
Som utvikler har du en teknisk forståelse som kan tilføre stor verdi når løsninger skal utformes, prioriteres og videreutvikles. Kombinert med at du trolig jobber tettest på produktet daglig, gjør denne innsikten deg til en viktig ressurs i produktutviklingen. Å bidra med kompetansen din gjennom hele prosessen – ikke bare under kodingen – vil gagne både teamet og produktet. Jeg kan også love at du vil få mer motivasjon og eierskap til det som bygges.
Er du usikker på hvordan du kan komme i gang? Her er tre konkrete tips på hvordan du kan ta en større rolle i produktutviklingen – og bidra med mer enn bare kodelinjer.
Tips 1: Gjør utviklingsløypa mer effektiv♻️
Jo raskere og tryggere dere kan rulle ut endringer i produktet, desto bedre kan teamet tilpasse seg brukernes behov, svare på endringer i markedet og sikre at endringene dere gjør alltid har ønsket effekt. Å gjøre utviklingsløypa mer effektiv – og dermed redusere tiden fra idé til verdi, eller time to value – er derfor et av våre viktigste bidrag som utviklere.
Når målet er å tilrettelegge for at teamet får levert verdi raskere, er det naturlig å fokusere på å redusere friksjon og minimere risiko i utviklingsløpet. Kan du starte med å kartlegge hvor i utviklingsløypa det går mye tid?
Går det mye tid til manuell testing?🧪
Automatiser så mye som mulig av testingen! Å forsikre seg manuelt om at endringer i koden ikke har introdusert bugs eller ødelagt kjernefunksjonalitet andre steder i produktet, er både vanskelig og tidkrevende. For å kunne rulle ut endringer kontinuerlig og hyppig, uten å bekymre seg for skjulte feil, kan automatiserte tester være til stor nytte.
Ved å automatisere testing av kjernefunksjonalitet, kan du sikre at de viktigste delene av produktet fortsatt fungerer sømløst. Dette muliggjør raskere og hyppigere utrullinger med lavere risiko. Sjekk ut verktøy som for eksempel Cypress eller Playwright for å komme i gang.
Må du ofte vente lenge på PR-gjennomgang?⏳
Prøv å minimere PR-ene dine for å gjøre dem enklere å gjennomgå. Spør deg selv: Må alt løses i én PR, eller kan oppgavene brytes ned i mindre, mer håndterbare deler?
Mindre og mer fokuserte kodeendringer er lettere for de andre utviklerne å forstå og vurdere. Og fordi hver endring har et tydeligere formål, blir det også lettere å teste og feilsøke. Dette reduserer risikoen ved utrulling, siden færre ting kan gå galt samtidig. På denne måten tilrettelegger det for hyppigere iterasjoner i produktutviklingen, da endringene kan leveres raskere og kontinuerlig bygges videre på basert på tilbakemeldinger fra brukerne.
Hender det ofte at du sitter lenge med samme oppgave? 👯♀️
Prøv parprogrammering for å øke både kvalitet og hastighet! Selv om det virker kontraintuitivt, kan parprogrammering bidra til hyppigere utrullinger. Når to utviklere jobber sammen om en oppgave, kan de raskt identifisere og rette feil som ellers kunne blitt oppdaget først i PR eller til og med produksjon. Parprogrammering gir også kontinuerlig feedback, som forbedrer kodekvaliteten og fremmer raskere kunnskapsoverføring mellom utviklere. Kanskje eliminerer det til og med behovet for tradisjonelle PR-er.
💡 Mer nysgjerrig på hvordan du kan effektivisere utviklingsløypa?
Ta en titt på boka Accelerate! Den gir enda mer innsikt i hvordan du kan rigge utviklingsløypa for hyppige, trygge leveranser – som er grunnlaget for effektiv produktutvikling.
Tips 2: Skap felles eierskap til brukerne med produktdashboards 📈
Som Ida Aalen skriver i Bedre Produkter, er antagelser om brukerne blant de mest risikable vi gjør. Den beste måten å redusere denne risikoen på er gjennom konkrete data og målinger. Her kan du som utvikler bidra ved å sette opp produktdashboards som gir teamet verdifull innsikt.
Med verktøy som PostHog eller Google Analytics kan du lage visuelle dashboards som for eksempel viser:
- Hvor mange som bruker produktet
- Hvordan brukerne navigerer gjennom funksjonaliteten
- Når på dagen produktet ditt er mest populært
- Hvilke enheter brukerne logger inn med
Denne typen dashboards flytter fokus fra hypotetiske antagelser til faktiske brukerdata. Dette handler ikke bare om å ha denne dataen tilgjengelig, men også om å forankre produktutviklingen i reelle behov. Innsikten må være tilgjengelig for hele teamet, og må være sentral i prioriteringsdiskusjoner.
I vårt team setter vi av en halvtime ukentlig til å gjennomgå produktinnsikten. Her diskuterer vi blant annet:
- Hvilke deler av produktet får mest trafikk?
- Hva viser dataene om hvordan brukerne logger inn og hva de gjør?
- Hvordan kan vi bruke denne innsikten til å forbedre produktet?
Å visualisere og diskutere innsikt på denne måten gir en sterkere følelse av eierskap til brukerne og produktene vi lager. Det flytter dermed fokuset til hvilken effekten av det man prodsetter.
💡 Et konkret eksempel på hvordan innsikt fører til effekt
Teamet mitt jobber med innsynsløsninger for eiendommer. Vi oppdaget at langt færre mobilbrukere enn desktop-brukere gikk videre fra landingssiden vår til detaljsiden for eiendommen sin. Vi antok at problemet var at mobilbrukerne ikke skjønte at eiendomskortene var klikkbare.
For å teste hypotesen la vi til teksten “Se flere opplysninger” på eiendomskortene for mobil. Dette enkle grepet førte til at 15 % flere mobilbrukere klikket seg videre til detaljsiden!
Denne typen innsikter viser hvor viktig det er med enkle dashboards for å forstå brukeratferd og effekten av endringene vi gjør.
Tips 3: Involver deg utenfor koden! 🎙️
Det holder ikke å bare utføre oppgaver som kommer ferdig prioritert. Ved å være med på å forme prioriteringene fra begynnelsen, får du muligheten til å utfordre antakelser og bidra med innsikt som kan endre hvordan en oppgave vurderes. Kanskje produktleder i teamet antar at noe er teknisk utfordrende, men du vet at det kan løses enkelt. Eller omvendt, at noe som virker ukomplisert faktisk vil kreve mye tid. Med bedre innsikt i hvor oppgavene i backlogen kommer fra, kan du foreslå enklere tekniske løsninger, avdekke potensielle problemer tidlig og prioritere det som gir mest verdi.
Her er et par tips til hvordan du kan ta større del i produktutviklingen fra start, fremfor å få oppgaver i fanget:
Vær med å forme prioriteringene i teamet ✋
Som utvikler kan du spille en aktiv rolle i hvordan oppgavene prioriteres. Ved å forstå målene og brukerproblemene en oppgave adresserer, får du bedre kontekst for arbeidet ditt, og kan bidra til å forme hvordan teamet vurderer hva som er viktigst. Dette gir deg innsikt til å stille relevante spørsmål og utfordre produktbeslutninger.
Still spørsmål som:
- Hvorfor er denne oppgaven viktig akkurat nå?
- Hva prøver vi egentlig å oppnå?
- Hvordan vet vi at dette er et reelt problem?
- Hvor mange brukere påvirkes, og hvordan?
Ved å delta i prioriteringsdiskusjonene kan du bidra med tekniske perspektiver som påvirker hva som bør løses først. Kanskje en løsning virker teknisk enkel, men har liten påvirkning på brukerne, eller omvendt. Med data fra analyseverktøy kan du hjelpe til med å justere prioriteringene, slik at teamet fokuserer på de løsningene som gir mest verdi.
I tillegg kan du styrke beslutningsgrunnlaget med data fra analyseverktøy eller databaser. Er det data som tyder på at et problem faktisk er mer begrenset enn antatt? Eller kanskje det er en enkel teknisk løsning som vil løse et stort brukerproblem?
Sørg for at du har forstått problemet før du begynner å kode💭
En stor tidstyv for utviklere er misforståelser rundt hva som egentlig skal løses- og ofte er det rett og slett forståelsen av problemet, ikke selve kodingen, som tar mest tid. Før du begynner å kode, vær sikker på at du virkelig forstår hva du prøver å løse. Hva er behovet, og hvordan kan løsningen møte det på best mulig måte? Unngå å hoppe rett til koding før du har avklart disse spørsmålene.
Bruk tid på å diskutere med fagressurser, skissere ideer eller bruke pseudokode for å avklare løsningen. Når du har en tydelig forståelse av problemet, kan du kode mer målrettet og effektivt.
Delta i produktutforskningen 🗺️
I produktutvikling er målet å bygge det minste som trengs for å teste et konsept eller løse et problem, og deretter iterere videre basert på tilbakemeldinger og læring. Ved å delta direkte i brukerintervjuer, observasjoner og andre produktutforskende aktiviteter, får du en dypere forståelse av hvorfor et problem eksisterer og hvem det påvirker. Denne innsikten gjør det lettere for deg å vurdere hvilke løsninger som er nødvendige, og hvilke som kan utsettes. Som utvikler kan du dermed hjelpe teamet med å bygge det minste funksjonelle produktet som raskt tester hypotesene og gir verdifull tilbakemelding.
Samtidig gir denne forståelsen deg muligheten til å vurdere flere alternative løsninger og velge den som best dekker behovet, fremfor blindt å implementere et allerede definert løsningsforslag. Ved å flagge hva som er teknisk mulig – eller utfordrende – tidlig i prosessen, kan du bidra til at teamet tilpasser løsningene før de blir for detaljerte eller låst.
...
Nå håper jeg du har fått noen ideer og tanker rundt hvordan du som utvikler kan ta større del i produktutviklingen 🙌
Lykke til!