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

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.

Helt enig Jacob. Når du snakker med brugere og de siger at de vil have en hurtigere hest, kan du bruge det til at forstå at de gerne vil transporteres. Og opfinde en bil, eller et fly eller en teleporter.

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.

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.

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.

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).

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.

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.

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.

Vi havde en glimrende dialog omkring Muscula, da du stadig havde det ;-)

Vi havde en glimrende dialog omkring Muscula, da du stadig havde det ;-)

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 :)

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.

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.

https://www.computerworld.dk/art/234053/har-du-nogensinde-moedt-brugerne-af-dine-it-loesninger

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.

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.

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.

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.

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 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.