Skal vi Doodle en feature?

Doodle.com, det lille geniale værktøj til at lave mødeftaler med, har medført en lille revolution i min og mange andres hverdag. Hvor mødeaftaler for en større gruppe mennesker tidligere kunne være et langt og frustrerende forløb, er det nu en nem og temmelig smertefri proces.

Men der er mere i Doodlen end problemfrie mødeaftaler. Den måde problemet løses på, bunder i nogle principper og en tankegang, der har videre perspektiver og stor relevans for bl.a. softwareudvikling.

Før vi havde Doodlen, så var processen med at koordinere og finde mødedatoer omtrent således:

En person bliver udpeget til finde et tidspunkt og indkalde mødet. Denne person vil så naturligt foreslå et tidspunkt, der er en kombination af egen præference og noget der sandsynligvis kan passe de andre deltagere. En mødeindkaldelse bliver udsendt. Kort efter ruller “Afvist” og “Måske” svarene ind i indbakken. Et nyt forsøg iværksættes, og processen fortsætte til det endelig, i bedste fald, er lykkedes at finde et tidspunkt hvor alle kan deltage.

Med Doodlen ser det nogenlunde således ud:

Den ansvarlige for mødet præsenterer et sæt alternativer for deltagerne. Alle melder tilbage i relation til alle alternativer. Det mest optimale tidspunkt udvælges og mødet indkaldes.

Det, der er forskellen på de to angrebsvinkler er, at den ene er punkt-baseret og den anden er sæt-baseret.

Den punktbaserede tilgang til løsning af et problem tager sit udgangspunkt i ét løsningsforsøg, og itererer ud fra dette indtil en tilfredsstillende løsning er fundet.

Den sæt-baserede, starter med at finde et sæt af alternativer, som evalueres samlet, hvorefter den bedste udvælges, eller to eller flere alternativer kombineres til en endnu bedre løsning - en teknik man ikke kan benytte når det handler om mødedatoer

Selvom den sæt-baserede metode, kan synes lidt mere tidskrævende til at begynde med - man skal jo finde alternativerne - er den bedre end den punkt-baserede på en række områder:

  • Det samlede tidsforbrug vil i gennemsnit være mindre
  • Løsningens kvalitet vil være bedre
  • Deltagernes motivation og medejerskab til løsningen vil være større

At det samlede tidsforbrug i de fleste tilfælde er mindre i doodle eksemplet, er der næppe nogen, der har haft den utaknemmelige opgave at samle en gruppe mennesker til et fælles mødetidspunkt, der vil være uenige i.

Anvender man samme princip i softwareudvikling, vil det samme gøre sig gældende. Tilbageløb, rettelser og bugs udgør normalt en meget stor del af den tid, der anvendes på udvikling. 20-30% og nogen gange helt op til 50%, er efter min erfaring ikke ualmindeligt. Tidsforbruget til dette vil helt naturligt blive mindre, hvis man på forhånd overvejer fordele og ulemper ved alternativer.

En bevidst undersøgelse af alternativer, vil bringe løsninger for dagen, der er mindre tidskrævende end andre. For eksempel kan et bruger-problem med at anvende en bestemt funktion af et softwareprodukt, nogen gange både løses ved at ændre på selve softwaren andre gange ved at ændre på noget i programmets kontekst: Dokumentation, hjælpetekster…. etc. Men den valgmulighed optræder sjældent, hvis ikke man bevidst arbejder med alternative løsningsmuligheder.

Kvaliteten øges fordi tilstedeværelsen af alternativer, betyder at rummet for mulige løsninger bliver større. Processen med at evaluere og udvælge, vil inkludere overvejelser vedrørende de forskellige løsningers kvalitet.

En slående forskel på Doodle arrangerede møder og de traditionelt indkaldte er af mere psykologisk karakter. Det er mere almindeligt, at folk ikke møder op til de traditionelle møder, end de Doodle har hjulpet med. Grunden er den simple, at alle har haft indflydelse på at finde datoen. Selvom det virker som en simpel operation at sætte nogle flueben ved et eller flere tidspunkter, så er det en aktiv handling. Der er derfor lidt større sandsynlighed for at deltagerne i Doodle mødet forsvarer mod andre møder og aktiviteter, end det ikke Doodle-indkaldte.

Det er i endnu højere grad tilfældet når man benytter en sæt-baseret tilgang til problemløsing i softwareudvikling. Det medejerskab der opstår, når man involveres i at udarbejde og evaluere alternativer, sikrer forståelse og ejerskab til den valgte løsning, som alt andet lige vil øge dedikationen til opgaven.

Ovenstående kan lyde besnærende men også højtflyvende. Hvad gør man i praksis for at gøre software- og anden udvikling mere sæt-baseret?

En ikke udtømmende liste er:

  • Lad være med at komme med løsninger tidligt i forløbet. Hold i stedet mulighederne åbne
  • Arbejd kollaborativt på tværs af roller og specialer
  • Træn metoder, der er egnede til frembringelse og evaluering af alternativer
  • Indbyg forventningen om at der er altid er en anden løsning i møder, templates og konversationer

Det sker ikke sjældent at kunden eller dennes talsmand i udviklingsorganisationen ikke alene har indkredset et behov eller et problem, men også mener at have lige præcis den rette løsning på det. I det tilfælde sker der en af to mulige ting: De der skal skrive koden tænker - “OK, det er der nogen der har tænkt over, så behøver jeg ikke selv at tænke”, eller de opponerer og påpeger at det ikke er en hensigtsmæssig løsning. I det ene tilfælde må man undvære det tekniske input, som kunne have været værdifuldt i udformningen af løsningen og i det andet er det en simpelthen en dårlig samtale, der starter med at påpege, hvorfor den påtænkte løsning ikke vil fungere, eller vil være uforholdsmæssigt dyr at udvikle. Hvis samtalen i stedet startede med at konstatere problemet eller behovet og man så i fællesskab udforskede mulige løsninger, ville det være en langt mere flydende proces.

Det tværfaglige samarbejde virker fordi for megen specialisering ikke er effektivt, selvom vi ofte tror det modsatte. Problemet med specialer er ikke, at folk dygtige til en bestemt disciplin. Det er, at der kan være en tendens til at forelske sig i sin egen løsning, når man har arbejdet med den i isolation i en længere periode. Så kan det være svært at se problemet fra andre vinkler. Det kan være svært for udvikleren, at forstå de forretningsmæssige implikationer og det kan være svært for UX’eren eller designeren at gennemskue de tekniske implikationer, af en ene eller den anden løsning. Derfor er det en stor fordel at man inddrager flere perspektiver, så snart man begynder at overveje alternativer.

En gruppes evne til at generere en række alternative løsninger og udvælge de mest lovende kræver træning og et mødeformat der understøtter det. F.eks er Design Studio teknikken er meget effektiv metode.

Papir prototyper er billige at fremstille og man kan nemt lave mere end en enkelt. og afprøve hvordan de virker.

En anden nyttig teknik er “ægte” brainstorming, som respekterer de grundlæggede regler for brainstorming: At starte med kvantitet uden hverken selv- eller anden censur og at man derefter zoomer ind på de bæredygtige løsninger, så man har et overskueligt sæt af alternativer at vælge imellem.

Det drejer sig ikke om at have de samme alternativer i luften hele vejen gennem processen. Man skal derimod rutinemæssigt kunne mobilisere flere alternativer, når man nærmer sig et tidspunkt, hvor en beslutning skal træffes.

Læs mere om brainstorming her:

https://challenges.openideo.com/blog/seven-tips-on-better-brainstorming

Et eksempel på en praktisk anvendelse af Design Studio

https://zapier.com/blog/run-a-design-studio/

 

Publiceret på Version2 d.  20. okt 2015