allan ebdrup bloghoved ny

11 år med softwareudvikling uden at snakke med en eneste slut-bruger

Der er noget helt galt!

Det er gået op for mig, at jeg har haft en sammenhængende periode på 11 år, hvor jeg ikke har talt med et eneste menneske, der rent faktisk bruger de systemer, jeg har været med til at udvikle. Det er desværre ikke en unik situation. Sådan er der mange udviklere, der arbejder.

De fleste udviklingsafdelinger har bygget et beskyttende skjold af funktioner, som product owners, support, UX og andet, der alle sørger for, at udvikleren aldrig forstyrres af slutbrugeren.

Skjoldet er for så vidt godt. Du kan ikke være effektiv, hvis du bliver forstyrret hele tiden. Men når du ikke møder en slutbruger i 11 år, har det taget overhånd.

Du er som udvikler ofte både intelligent, kreativ og innovativ. Men når du ikke forstår, hvordan hverdagen ser ud for de mennesker, der skal bruge det, du udvikler, bliver din opfinder-kraft brugt på rent tekniske udfordringer. Der er et stort uforløst potentiale i at du, gennem din personlige forståelse af slutbrugeren, kan opfinde teknisk smarte løsninger til dem.

At forstå slutbrugeren er et fælles ansvar

Vi har hos Debitoor sat os det mål, at vores udviklere skal forstå nogle af de mennesker, der bruger vores løsning og deres hverdag.

Det at mødes med slutbrugeren og få noget værdifuldt ud af det, er et komplekst felt. Jeg har talt med designere, UX’ere og innovations-eksperter. Det kan hurtigt blive så akademisk, at det bliver uoverskueligt.

Vi har valgt at starte simpelt. Et par udviklere sætter sig sammen med en bruger, der fortæller om sin hverdag og hvordan vores produkt passer ind i den. En almindelig snak, over et par kopper kaffe. Planen er at eksperimentere med mødeformen, øve os, lære og blive bedre. Men nu er vi i gang.

Mødet mellem udviklere og slutbrugere er et supplement til alt det, vi allerede gør for at forstå slutbrugerne, markedet osv. Vi har stadig vores skjold af product owners, support, bruger-feedback-system, UX, A/B-splittests og andet. Vi lukker bare en lille smule fokuseret sollys ind gennem skjoldet, direkte ind til udvikleren.

Der har allerede vist sig gode resultater, selvom vi er kun lige er gået i gang.

Er du udvikler? Kunne du tænke dig at sidde sammen med en slutbruger, for at forstå hendes eller hans hverdag og hvordan det, du udvikler, passer ind i den?

Kommentarer (17)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Bjarne Nielsen

Ja, det er godt nok sjældent, at man får lov til at møde en rigtig bruger. Vores kunder er ikke meget for at give os lov. Og det sådan set uanset, om man er "rigtig" udvikler eller en del af "skjoldet".

Da jeg startede ud som helt grøn udvikler for mange år siden, var der specielt to møder med virkeligheden, som var veritable øjenåbnere:

  1. Det feedback jeg fik var mest fra 2nd level support, men en dag fik jeg lov til at være med til at holde et brugerkursus. Der opdagede jeg, hvor glade brugerne i virkeligheden var for programmet, og hvor stor en forskel det gjorde i deres hverdag. Jeg havde ellers fået at vide, at det var noget ustabilt ragelse, som ikke kunne bruges til noget.

  2. Efter en kedelig fejl måtte jeg ringe til en af vores pilotbrugere, og fortælle, at de blev nødt til at taste deres kundekartotek ind igen. Hun kunne så fortælle mig, at hun stadig have infiltrationer fra sidst det var sket. Der lærte jeg noget om omhyggelighed.

Så det er bare at komme igang. Jeg kan ikke komme i tanke om et eneste tilfælde, hvor det ikke har været lærerigt.

  • 10
  • 0
Allan Ebdrup

Jeg synes godt om idéen at udviklere bidrager til kundesupport og ad den vej får noget kundekontakt samtidig med der bidrages til at løse en opgave.


Ja det er der også flere der gør. Vi har også overvejet grundigt om vores udviklere skulle bidrage til kundesupport fx fast en time om ugen. I vores tilfælde er det ikke det vi har brug for. Gevinsten ville, efter vores vurdering, ikke stå mål med udbyttet.

For det første har udviklerne ikke lyst til det. Selv efter vi havde forsøgt af flere omgange at sælge ideen. Det er for stor en afbrydelse i deres hverdag, og det kræver også specielle evner at give god support. (de meste af vores support er desuden på tysk og spansk som vores udviklere ikke taler)

For det andet, så er det meget bevidst at jeg taler om at opfinde i blogindlæget. Det er en helt anden samtale du har, med en slut-bruger der har meldt sig frivilligt til at sidde og tale med dig, i længere tid, fysisk samme sted, om hvordan du kan hjælpe personen i hverdagen, end en person der bare vil have hjælp til at løse et specifikt problem.

Når det er sagt, så er jeg enig i at supporterne har en stor viden om hvad der foregår ude hos brugerne. Den viden bringer vi blandt andet tættere på udviklerne, ved at supporten har en person med på vores udvikleres daglige standup.

  • 0
  • 0
Martin Skøtt

Jeg havde stor glæde af at undervise kunder i brugen af vores produkt i et tidligere job. Ikke alene gav det god indsigt i brugernes hverdag, men det udmyntede sig også i en side eller to med noter og kommentarer med ting der kunne forbedes.

  • 1
  • 0
Allan Ebdrup
  • 0
  • 0
Allan Ebdrup

Meld jer som frivillige for ældresagen. Det er meget lærerigt at se hvordan den mest IT-udfordrede del af befolkningen interagerer med frontends, og så er det superhyggeligt at møde en masse forskellige mennesker.


Super god idé. Vores brugere er dog alle erhvervsaktive freelancere og små virksomhedsejere. Men jeg bruger selv min fritid på at undervise børn i programmering hos coding pirates, en gang om ugen. Det kan jeg også anbefale :-)

  • 1
  • 0
Ulrik Suhr

Lad nu ikke brugeren tro han kan få en Ferrari.

Har prøvet at sidde som supporter en dag om ugen og ellers udvikle resten af tiden.
Dette gav et godt indblik i systemet men ikke noget i dybden og de ideer der kom kunne man som ny ikke 100% bruge.

Har også fået 100% adgang til de brugere som skulle bruge systemet. Her lærte jeg rigtig meget og der var et væld af nye ideer. Så det kan betale sig som du beskriver.
Dog skulle jeg passe på ikke at tage for mange ideer med.
Eller hvilken type bruger man benytter!

Når man som udvikler (mig) får mulighed for at hjælpe en bruger og forstå deres arbejdsgange er det vigtigt at skabe fokus på 1 ting af gangen :). Men tror det beror på den udvikler som skal være sammen med brugeren.
Tror ikke alle udviklere er lige gode til at forstå brugeren så ved ikke om det altid vil være frugtbart.
En hurtig ROI (tid eller penge) for brugren er ofte meget god indikator på hvilke problemer man skal løse først :)

  • 1
  • 0
Henrik K. Jensen

Jeg har en ny programmør startende snart, noget af det første han skal er ud og besøge kunder (på service sammen med en tekniker). Ikke så meget for at snakke med dem, men for at se hvordan de bruger vores produkter. Jeg håber at det vil hjælpe ham til at forstå hvad kunderne og dermed vores firma har brug for.
Når han ved noget mere om det hele vil han nok få nogle flere kundebesøg, men det vil også afhænge af hvad han selv ønsker.

  • 1
  • 0
Allan Ebdrup

Jeg har en ny programmør startende snart, noget af det første han skal er ud og besøge kunder (på service sammen med en tekniker). Ikke så meget for at snakke med dem, men for at se hvordan de bruger vores produkter. Jeg håber at det vil hjælpe ham til at forstå hvad kunderne og dermed vores firma har brug for.

At lære om brug er helt klart vigtigt også. Det er ret nemt, at finde metoder til at gøre det indenfor UX. Der er endda online services du kan bruge, med kunder der er med på den, hvor du kan optage hvad de laver mens de tænker højt. Jeg ser det lidt som et løst problem, hvor du bare skal finde en form der passer til din situation, ved at plukke fra hylderne med metoder.

Jeg er dog ude i et lidt andet ærinde her. Mit indtryk er at brugsobservering er begrænset i forhold til at finde ud af hvad der reelt er brug for at opfinde. Det er som den gode gamle traver af et Henry Ford citat:

If I had asked people what they wanted, they would have said faster horses.

I de fleste virksomheder er det en Product Owner eller lignende der har hele ansvaret for at undersøge reelle behov bag hvad folk umiddelbart siger at de har brug for. For at give dem bilen i stedet for den hurtigere hest.

Det er det ansvar jeg vil sprede lidt ud og måske endda demokratisere. Vores PO'ere er mega dygtige, men de har ikke den dybe tekniske forståelse for hvad der er teknisk muligt som udviklerene har. Der er et uforløst potentiale for gode opfindelser, som frigøres i den direkte kontakt mellem slutbrugere og udviklere.

Det nytter ikke noget at du udvikler med 100 i timen, hvis du udvikler det forkerte. Og så er det ligemeget hvor brugervenligt det du udvikler er - hvis der er noget helt andet du kunne udvikle, som ville være fundamentalt mere værdifuldt.

Det er niveauet over brugervenlighed - værdiskabelse.

  • 2
  • 0
Henrik K. Jensen

Min generally holdning er at du ikke kan regne mad hvad folk siger de har brug for, netop som din Ford citat siger. Det er nødvendigt at observere hvordan folk arbejder, sammenholde det med deres ønsker og så forhåbentlig finde den rigtige løsning.
For at kunne gøre det er kundebesøg en væsentlig ting, men at snakke med kunden er ikke nok, det er nødvendigt at observere og forstå hvad de laver. Først derefter har du en chance for at specificere/lave det rigtige. Som ny started programmør vil det selvfølgelig ikke lige være det du håndtere, men lidt forståelse for arbejdsgange og krav vil forhåbentlig hjælpe når der skal laves kode (Det er min teori).

  • 0
  • 0
Allan Ebdrup

Min generally holdning er at du ikke kan regne mad hvad folk siger de har brug for, netop som din Ford citat siger. Det er nødvendigt at observere hvordan folk arbejder, sammenholde det med deres ønsker og så forhåbentlig finde den rigtige løsning.


Ja man har helt sikkert brug for at observere og lære om arbejdsgange. Det at beslutte hvad man skal bygge som det næste er dog ikke et problem man kan løse med analyse alene. Du bliver nød til at bruge elementer fra fx design thinking og bruge synthesis.

Det er lidt som forskellen mellem et NP problem og et NP hårdt problem. Med et NP problem er det "svært" at finde en løsning (sudoku), med et NP hårdt problem er det også svært at finde ud af om løsningen nu også er god når du har analyseret dig frem til en mulig løsning (skak).

I udfordringen med at vælge hvad det næste du skal bygge skal være, er problemet endnu værre, for du har en-vejs naturen af tidsdimensionen. Du kan ikke gå tilbage og prøve et andet valg. Det som i Cynefin modellen hedder Complex.

Men heldigvis har design-thinking løsninger med synthesis og co-creation. Det er det du kender fra at brainstorme en løsning. Reglen for innovation er her at du skal have mange forskellige mennesker i samme rum og bruge synthesis til at komme med løsningsforslag. Jo flere forskellige folk jo bedre. Det gør det i min bog åbenlyst at også udviklere og slut-brugere skal mødes.

  • 0
  • 0
Jacob Christian Munch-Andersen

Min generally holdning er at du ikke kan regne mad hvad folk siger de har brug for, netop som din Ford citat siger. Det er nødvendigt at observere hvordan folk arbejder, sammenholde det med deres ønsker og så forhåbentlig finde den rigtige løsning.


Du skal finde ud af hvad deres problemer er, når først man snakker om det på den måde bliver man sjældent vildledt af brugere. Man skal selvfølgelig lytte når de efterspørger en feature, ikke for fluks at implementere den, men fordi det typisk er et hint om et underliggende problem.

  • 2
  • 0
Torsten Hagemann

Jeg vil også meget gerne have at udviklere og slutbrugere får talt sammen. Ikke for at finde på nye features, og ikke for at løse aktuelle problemer for slutbrugeren (det har vi PO'ere og support til at håndtere, og det fungerer udmærket), men fordi det er så vigtigt at udviklerne forstår den kontekst som produktet indgår i. Jeg vil gerne at vi som udviklerteam forstår arbejdsgangene, de daglige problemer, hvilke opgaver der er vigtige (dvs. ikke må fejle) og hvilke der laves ofte (dvs. skal være supereffektive). Så længe den forståelse/viden ikke er tilstede, så har PO'erne en meget stor opgave med at skulle redegøre for alt for mange detaljer i hver eneste feature-beskrivelse - kommunikation som kan blive meget mere effektiv hvis begge parter har samme forståelse for hvordan den nye feature skal anvendes. Og det giver også udviklerne meget bedre mulighed for konstruktivt at kommentere og forbedre de feature-beskrivelser som PO'erne leverer.

  • 1
  • 0
Log ind eller Opret konto for at kommentere