Fra et uklart funktionsønske til en klar plan for gennemførelsen

Nogen siger: »Vi skal gøre onboarding nemmere.«

Alle er enige. Så kommer forslagene: Tilføj en tjekliste, forkort opsætningen, skriv bedre vejledninger, send en velkomstmail.

Snart er der nok idéer til at fylde en sprint. Det er mindre klart, hvilket problem teamet forsøger at løse.

Det er et godt tidspunkt at lave et mindmap. Det giver teamet et sted at undersøge ønsket, forbinde idéer og holde ubesvarede spørgsmål synlige, før det beslutter, hvad der skal bygges.

I denne guide følger vi et fiktivt team, der arbejder på et produkt med fælles arbejdsområder. Nye kunder opretter en konto, sætter et arbejdsområde op og inviterer deres teammedlemmer. Teamet er blevet bedt om at forbedre den oplevelse.

Vi fører ønsket fra en åben diskussion til en lille, tydeligt beskrevet opgave i Jira. Du kan følge den samme proces med ethvert mindmappingværktøj.

1. Begynd med ønsket uden at behandle det som svaret

»Gør onboarding nemmere« udtrykker en hensigt. Det fortæller endnu ikke, hvor folk støder på problemer, eller hvad der bør ændres.

Teamet placerer »Forbedr onboarding« i midten af sit mindmap og tilføjer fire grene:

• Opret en konto
• Sæt et arbejdsområde op
• Invitér teammedlemmer
• Tag det første nyttige skridt sammen

Det giver samtalen en struktur. I stedet for at diskutere »onboarding« som ét stort problem kan deltagerne pege på en bestemt del af oplevelsen.

Teamet tilføjer det, det allerede ved, ved de relevante grene. I vores fiktive eksempel har supporten fået spørgsmål om, hvor man inviterer kolleger. Under en gennemgang leder en ny ejer af et arbejdsområde efter en invitationsmulighed på arbejdsområdets startside. Muligheden findes, men ligger i arbejdsområdets indstillinger.

Disse observationer peger på noget, der er værd at undersøge. De beviser ikke, at hele onboardingforløbet skal bygges om.

Teamet lader de øvrige grene blive på mindmappet og retter opmærksomheden mod »Invitér teammedlemmer«.

2. Skeln mellem det, du ved, og det, du tror

En forklaring kan hurtigt komme til at lyde som et faktum, når nogen fremsætter den med overbevisning.

»Folk inviterer ikke deres kolleger, fordi invitationsprocessen er for kompliceret.«

Måske. Men har de svært ved at finde invitationsformularen, udfylde den eller forstå, hvorfor de allerede nu skulle invitere nogen? Det er forskellige problemer.

Under invitationsgrenen laver teamet tre grupper.

Observeret

• Supporten har fået spørgsmål om, hvor man inviterer teammedlemmer.
• En ejer af et arbejdsområde ledte efter invitationer på startsiden.
• Den nuværende invitationsmulighed ligger i arbejdsområdets indstillinger.

Antaget

• En mere synlig indgang ville gøre funktionen lettere at finde.
• Nogle ejere er måske ikke klar over, at det er et nyttigt næste skridt at invitere teammedlemmer.

Stadig uklart

• Kan ejerne udfylde den eksisterende formular, når de har fundet den?
• Forstår modtagerne af en invitation, hvad de skal gøre bagefter?

Betegnelserne er vigtigere end den visuelle udformning. Alle, der ser på mindmappet, bør kunne skelne en observation fra en mulig forklaring.

Før teamet vælger en løsning, beder det nogle nye ejere af arbejdsområder om at prøve at invitere en kollega. Det observerer, hvor de leder, og spørger, hvad de forventer vil ske, uden først at vise dem invitationsmuligheden.

I dette eksempel tyder gennemgangene på, at det umiddelbare problem er at finde formularen. Når ejerne bliver vist indgangen, kan de udfylde den. Modtagernes oplevelse skal stadig undersøges særskilt.

Teamet kan nu beskrive et mere afgrænset problem:

Det er konkret nok til at styre den næste diskussion. Det er også noget, teamet kan vende tilbage til efter en ændring.

Forstør

3. Undersøg nogle få løsninger på det samme problem

Med et tydeligere problem vender teamet tilbage til mulige forbedringer. Det tilføjer tre muligheder på mindmappet:

• Placér en handling med teksten »Invitér teammedlemmer« på arbejdsområdets startside.
• Tilføj et invitationstrin i den indledende opsætning.
• Send en opfølgende mail, der forklarer, hvordan man inviterer kolleger.

Alle mulighederne kan hjælpe, men de når ejeren på forskellige tidspunkter.

Handlingen på startsiden ville være tilgængelig, når nogen vender tilbage til deres arbejdsområde. Et opsætningstrin ville introducere invitationer tidligt, men nogle ejere er måske endnu ikke klar til at invitere andre. En mail kunne fungere som en påmindelse, men ejeren ville stadig skulle vende tilbage til produktet.

Teamet skriver en kort note ved hver mulighed om, hvad den skal hjælpe med. Det holder diskussionen knyttet til problemet, så den ikke bliver en afstemning om alles yndlingsfunktion.

Det er ikke nødvendigt at kortlægge enhver tænkelig løsning. Begynd med nogle få plausible forslag, og spørg:

• Adresserer det den vanskelighed, vi observerede?
• Hjælper det på det tidspunkt, hvor ejeren har brug for det?
• Hvad skal vi lære eller ændre for at få det til at fungere?

Et nyttigt mindmap gør det lettere at diskutere disse valg. Flere grene er ikke automatisk bedre.

Forstør

4. Vælg ét nyttigt første skridt

Teamet vælger at afprøve en synlig invitationshandling på arbejdsområdets startside.

Hvorfor denne mulighed? Den tager direkte udgangspunkt i det sted, hvor ejerne ledte, og teamet kan bruge den eksisterende invitationsformular. Handlingen er også tilgængelig for ejere, der beslutter at invitere kolleger senere.

Det er et udgangspunkt, ikke en påstand om, at alle problemer med onboarding er løst.

Teamet udvider den valgte gren med det aftalte omfang og noterer de udskudte idéer og den åbne undersøgelse ved siden af planen:

Med i denne forbedring

• Tilføj en tydeligt navngivet invitationshandling på arbejdsområdets startside.
• Åbn den eksisterende invitationsformular fra handlingen.
• Bevar de eksisterende invitationstilladelser og måden, invitationer sendes på.

Senere

• Overvej, om et invitationstrin hører hjemme i den indledende opsætning.
• Overvej, om en opfølgende påmindelse ville være nyttig.

Skal undersøges

• Undersøg oplevelsen af at modtage og acceptere en invitation.

Når disse grupper er synlige, undgår man lettere at genåbne de samme beslutninger igen og igen. Idéen om en mail er ikke forsvundet. Modtagernes oplevelse er ikke glemt. De er blot ikke en del af denne første forbedring.

På dette tidspunkt taler teamet også med dem, der skal implementere ændringen. Det lyder enkelt at genbruge en eksisterende formular, men der kan være begrænsninger, som påvirker fremgangsmåden. Dem er det bedre at kende, før omfanget betragtes som endeligt.

Forstør

5. Beskriv, hvad en person skal kunne gøre

»Tilføj en invitationsknap« beskriver en ændring af brugerfladen. Det siger mindre om den oplevelse, teamet ønsker at skabe.

Et mere nyttigt spørgsmål er:

Teamet bliver enige om en kort liste af kontrolpunkter:

• En ejer med tilladelse til at invitere teammedlemmer kan finde handlingen »Invitér teammedlemmer« på arbejdsområdets startside.
• Når handlingen vælges, åbnes den eksisterende invitationsformular for det aktuelle arbejdsområde.
• Ejeren kan gennemføre invitationen via det eksisterende forløb.
• En person uden invitationstilladelse får ikke adgang via den nye handling.
• Handlingen kan bruges på de skærmstørrelser, produktet understøtter, og kan nås med tastaturet.

Det er acceptkriterier: observerbare betingelser, som teamet kan bruge til at kontrollere sit arbejde. De behøver ikke at være skrevet som en teknisk specifikation.

Der er også to forskellige spørgsmål, som skal holdes adskilt. »Har vi leveret den aftalte ændring?« besvares ved at kontrollere disse betingelser. »Har ændringen gjort invitationer nemmere at finde?« kræver, at man observerer, hvordan folk bruger den.

En knap kan fungere præcis som specificeret og stadig blive overset.

6. Flyt det aftalte arbejde til Jira

Mindmappet har hjulpet teamet med at undersøge ønsket og træffe en beslutning. Nu er den valgte forbedring klar til at blive en opgave, som nogen kan tage på sig.

Teamet opretter én Jira-opgave for det aftalte resultat. Det opretter ikke en opgave for hver gren på mindmappet.

Opgaven kunne indeholde følgende:

Titel: Gør invitationer til teammedlemmer tilgængelige fra arbejdsområdets startside

Hvorfor det er vigtigt: Nye ejere af arbejdsområder har haft svært ved at finde invitationsmuligheden i indstillingerne. Vi ønsker, at de kan starte en invitation fra startsiden, hvor de allerede leder efter den.

Omfang: Tilføj handlingen »Invitér teammedlemmer«, som åbner den eksisterende invitationsformular for det aktuelle arbejdsområde. Bevar de eksisterende regler for tilladelser og den måde, invitationer fungerer på.

Ikke omfattet: Et nyt opsætningsforløb, påmindelsesmails eller ændringer af oplevelsen, når man accepterer en invitation.

Acceptkriterier: Medtag kontrolpunkterne fra det foregående afsnit.

Planlægningskontekst: Link til mindmappet, så alle, der arbejder på opgaven, kan se observationerne, alternativerne og beslutningen om omfanget.

Afhængigt af teamets arbejdsform kan design og implementering blive til separate opgaver. Del arbejdet op, når det gør ansvar eller gennemførelse tydeligere, frem for automatisk at kopiere mindmappets struktur til Jira.

En gren organiserer tanker. En opgave beskriver arbejde. Der behøver ikke at være et en-til-en-forhold mellem dem.

Hvis dit mindmappingværktøj er forbundet med Jira, kan du muligvis oprette opgaven fra den valgte node og bevare forbindelsen synlig på mindmappet. Hvis ikke, kan du oprette opgaven separat og tilføje et link. Uanset metoden skal du gennemgå opgaven før overdragelsen: En kort nodetekst indeholder sjældent al den kontekst, der er brug for.

Når gennemførelsen begynder, skal status og ansvar holdes i Jira. Brug mindmappet til det overordnede problem, begrundelsen for beslutningen og de spørgsmål, der stadig er åbne. Det giver hvert sted et klart formål og mindsker fristelsen til at vedligeholde to separate opgavelister.

Forstør

7. Undersøg, om det oprindelige problem er blevet mindre

Når ændringen er udgivet, vender teamet tilbage til den sætning, det skrev tidligere:

Kan nye ejere nu finde invitationshandlingen uden at få vist, hvor den er? Kan de fortsætte gennem den eksisterende formular? Tyder samtaler med supporten på, at den samme forvirring stadig opstår?

Hvis teamet har relevante produktmålinger, kan det også se på, hvor mange nye ejere af arbejdsområder der starter og gennemfører en invitation. Tallene kræver kontekst: Nogle ejere ønsker måske bevidst at arbejde alene, og andre ændringer kan påvirke resultaterne.

Vi behøver ikke at opfinde et vellykket resultat for denne fiktive historie. Det nyttige næste skridt er at observere, hvad der sker, og tilføje den nye viden til mindmappet.

Hvis ejerne finder handlingen, men går i stå senere, har teamet et mere konkret problem at undersøge. Hvis ændringen hjælper, kan det beslutte, om endnu en forbedring er værd at arbejde videre med.

Det oprindelige ønske var bredt. Den færdige plan er fokuseret: et klart problem, en valgt løsning, et overskueligt omfang og en måde at kontrollere, om det hjalp.

Det er det, der gør mindmappet nyttigt. Det fører samtalen fra »det bør vi forbedre« til et aftalt næste skridt og holder samtidig begrundelserne og de ubesvarede spørgsmål synlige.