Guider9 minuters läsning

Från ett vagt funktionsönskemål till en tydlig leveransplan

Följ ett exempel på introduktion från en öppen fråga till en liten, testbar förbättring, med en tankekarta som växer när besluten blir tydligare.

Någon säger: ”Vi behöver göra introduktionen enklare.”

Alla håller med. Sedan kommer förslagen: lägg till en checklista, korta ner konfigurationen, skriv bättre instruktioner, skicka ett välkomstmejl.

Snart finns det tillräckligt med idéer för att fylla en sprint. Mindre tydligt är vilket problem teamet försöker lösa.

Det här är ett bra tillfälle att göra en tankekarta. Den ger teamet en plats att utforska önskemålet, koppla ihop idéer och hålla obesvarade frågor synliga innan ni bestämmer vad som ska byggas.

I den här guiden följer vi ett fiktivt team som arbetar med en produkt för delade arbetsytor. Nya kunder skapar ett konto, konfigurerar en arbetsyta och bjuder in sina kollegor. Teamet har fått i uppdrag att förbättra den upplevelsen.

Vi tar önskemålet från en öppen diskussion till en liten, tydligt beskriven arbetsuppgift i Jira. Ni kan följa samma process med vilket verktyg för tankekartor som helst.

1. Börja med önskemålet, utan att behandla det som svaret

”Gör introduktionen enklare” uttrycker en avsikt. Det säger ännu inte var människor får problem eller vad som bör ändras.

Teamet placerar Förbättra introduktionen i mitten av kartan och lägger till fyra grenar:

  • Skapa ett konto
  • Konfigurera en arbetsyta
  • Bjud in kollegor
  • Gör något användbart tillsammans för första gången

Det ger samtalet en form. I stället för att diskutera ”introduktion” som ett enda stort problem kan deltagarna peka på en viss del av upplevelsen.

Teamet lägger in vad det vet i nuläget vid relevanta grenar. I vårt fiktiva exempel har supporten fått frågor om var man bjuder in kollegor. Under en genomgång letar en ny ägare av en arbetsyta efter en inbjudningsfunktion på arbetsytans startsida. Funktionen finns, men ligger i arbetsytans inställningar.

Observationerna pekar ut något att undersöka. De bevisar inte att hela introduktionsflödet behöver byggas om.

Teamet låter de andra grenarna stå kvar och riktar uppmärksamheten mot Bjud in kollegor.

2. Skilj det ni vet från det ni tror

En förklaring kan lätt börja låta som ett faktum när någon framför den med övertygelse.

”Folk bjuder inte in sina kollegor eftersom inbjudningsprocessen är för komplicerad.”

Kanske. Men har de svårt att hitta formuläret, fylla i det eller förstå varför de ska bjuda in någon redan nu? Det är olika problem.

Under inbjudningsgrenen skapar teamet tre grupper.

Observerat

  • Supporten har fått frågor om var man bjuder in kollegor.
  • En ägare av en arbetsyta letade efter inbjudningar på startsidan.
  • Den nuvarande inbjudningsfunktionen finns i arbetsytans inställningar.

Antaganden

  • En synligare ingång skulle hjälpa användarna att hitta funktionen.
  • Vissa ägare kanske inte inser att det är ett användbart nästa steg att bjuda in kollegor.

Fortfarande oklart

  • Kan ägarna fylla i det befintliga formuläret när de väl hittar det?
  • Förstår de som får en inbjudan vad de ska göra härnäst?

Etiketterna är viktigare än den visuella utformningen. Alla som tittar på kartan ska kunna skilja en observation från en möjlig förklaring.

Innan teamet väljer en lösning ber det några nya ägare av arbetsytor att visa hur de bjuder in en kollega. Teamet ser var de letar och frågar vad de förväntar sig ska hända, utan att först visa inbjudningsfunktionen.

I det här exemplet tyder genomgångarna på att det omedelbara hindret är att hitta formuläret. När ägarna får se ingången kan de fylla i det. Mottagarens upplevelse behöver fortfarande undersökas separat.

Teamet kan nu beskriva ett mer avgränsat problem:

“Nya ägare av arbetsytor har svårt att hitta var de bjuder in sina kollegor.”

Det är tillräckligt konkret för att vägleda nästa diskussion. Det är också något teamet kan återkomma till efter en ändring.

Börja med att skilja det ni har observerat från det ni fortfarande behöver ta reda på.

3. Utforska några sätt att hantera samma problem

Med ett tydligare problem återvänder teamet till möjliga förbättringar. Det lägger till tre alternativ på kartan:

  • Placera en funktion för att Bjuda in kollegor på arbetsytans startsida.
  • Lägg till ett inbjudningssteg i den första konfigurationen.
  • Skicka ett uppföljningsmejl som förklarar hur man bjuder in kollegor.

Alla alternativ kan hjälpa, men de når ägaren vid olika tillfällen.

Funktionen på startsidan skulle finnas där när någon återvänder till sin arbetsyta. Ett konfigurationssteg skulle presentera inbjudningar tidigt, men vissa ägare kanske inte är redo att bjuda in andra ännu. Ett mejl kan fungera som påminnelse, även om ägaren fortfarande behöver återvända till produkten.

Teamet skriver en kort anteckning vid varje alternativ om vad det ska hjälpa till med. Det håller diskussionen kopplad till problemet, i stället för att den blir en omröstning om allas favoritfunktioner.

Det finns ingen anledning att kartlägga varje tänkbar lösning. Börja med några rimliga alternativ och fråga:

  • Angriper det svårigheten vi har observerat?
  • Hjälper det när ägaren behöver det?
  • Vad behöver vi lära oss eller ändra för att det ska fungera?

En användbar karta gör de här valen lättare att diskutera. Fler grenar är inte automatiskt bättre.

Jämför några sätt att hantera samma problem innan ni väljer ett.

4. Välj ett användbart första steg

Teamet väljer att testa en synlig inbjudningsfunktion på arbetsytans startsida.

Varför det alternativet? Det svarar direkt mot var ägarna letade, och teamet kan använda det befintliga inbjudningsformuläret. Funktionen finns dessutom kvar för ägare som väljer att bjuda in kollegor senare.

Det är en startpunkt, inte ett påstående om att alla problem med introduktionen är lösta.

Teamet utvecklar den valda grenen med den överenskomna omfattningen och dokumenterar uppskjutna idéer och kvarstående undersökningar intill planen:

Ingår i den här förbättringen

  • Lägg till en tydligt märkt inbjudningsfunktion på arbetsytans startsida.
  • Öppna det befintliga inbjudningsformuläret via funktionen.
  • Behåll befintliga behörigheter och samma sätt att skicka inbjudningar.

Senare

  • Överväg om ett inbjudningssteg hör hemma i den första konfigurationen.
  • Överväg om en uppföljande påminnelse skulle vara användbar.

Behöver undersökas

  • Granska upplevelsen av att ta emot och acceptera en inbjudan.

Att hålla grupperna synliga hjälper teamet att undvika att samma beslut tas upp om och om igen. Mejlidén har inte försvunnit. Mottagarens upplevelse är inte bortglömd. De ingår bara inte i den här första förbättringen.

Nu stämmer teamet också av med dem som ska genomföra ändringen. Att återanvända ett befintligt formulär låter enkelt, men det kan finnas begränsningar som påverkar tillvägagångssättet. Det är bättre att upptäcka dem innan omfattningen betraktas som fastställd.

Utveckla den valda förbättringen till en liten, uttrycklig omfattning.

5. Beskriv vad en person ska kunna göra

”Lägg till en inbjudningsknapp” beskriver en ändring i gränssnittet. Det säger mindre om upplevelsen som teamet vill skapa.

En mer användbar fråga är:

“Vad ska en ägare av en arbetsyta kunna göra när förbättringen är klar?”

Teamet enas om en kort uppsättning kontroller:

  • En ägare med behörighet att bjuda in kollegor kan hitta funktionen Bjud in kollegor på arbetsytans startsida.
  • När funktionen väljs öppnas det befintliga inbjudningsformuläret för den aktuella arbetsytan.
  • Ägaren kan slutföra inbjudan med det befintliga flödet.
  • En person utan inbjudningsbehörighet får inte tillgång genom den nya funktionen.
  • Funktionen går att använda på de skärmstorlekar som produkten stöder och kan nås med tangentbord.

Det här är acceptanskriterier: observerbara villkor som teamet kan använda för att kontrollera sitt arbete. De behöver inte vara skrivna som en teknisk specifikation.

Det finns också två olika frågor att hålla isär. Levererade vi den överenskomna ändringen? besvaras genom att kontrollera villkoren. Gjorde ändringen det lättare att hitta inbjudningar? kräver att ni ser hur människor använder den.

En knapp kan fungera exakt enligt specifikationen och ändå förbises.

6. Flytta det överenskomna arbetet till Jira

Kartan har hjälpt teamet att utforska önskemålet och fatta ett beslut. Nu är den valda förbättringen redo att bli en uppgift som någon kan ta sig an.

Teamet skapar ett Jira-ärende för det överenskomna resultatet. Det skapar inte ett ärende för varje gren på kartan.

Så här kan innehållet i ärendet se ut:

Titel: Gör det möjligt att bjuda in kollegor från arbetsytans startsida

Varför det är viktigt: Nya ägare av arbetsytor har haft svårt att hitta inbjudningsfunktionen i inställningarna. Vi vill att ägarna ska kunna starta en inbjudan från startsidan, där de redan letar efter den.

Omfattning: Lägg till funktionen Bjud in kollegor som öppnar det befintliga inbjudningsformuläret för den aktuella arbetsytan. Behåll befintliga behörighetsregler och inbjudningsbeteende.

Ingår inte: Ett nytt konfigurationsflöde, påminnelsemejl eller ändringar i upplevelsen av att acceptera en inbjudan.

Acceptanskriterier: Ta med kontrollerna som överenskommits i föregående avsnitt.

Planeringsbakgrund: Länka till kartan så att alla som arbetar med ärendet kan se observationerna, alternativen och beslutet om omfattning.

Beroende på hur teamet arbetar kan design och implementation bli separata uppgifter. Dela upp arbetet när det förtydligar ansvar eller leverans, i stället för att automatiskt kopiera kartans struktur till Jira.

En gren organiserar tankar. Ett ärende beskriver arbete. De behöver inte motsvara varandra ett till ett.

Om ert verktyg för tankekartor kan ansluta till Jira kan ni kanske skapa ärendet från den valda noden och hålla kopplingen synlig på kartan. Annars kan ni skapa ärendet separat och lägga till en länk. Granska i båda fallen ärendet innan ni lämnar över det: en kort nodetikett innehåller sällan all bakgrund som någon behöver.

När genomförandet börjar håller ni status och ansvar i Jira. Använd kartan för det bredare problemet, resonemanget bakom beslutet och frågorna som fortfarande är öppna. Det ger varje plats ett tydligt syfte och minskar frestelsen att underhålla två separata uppgiftslistor.

Välj den överenskomna förbättringen, granska sammanfattningen och acceptanskriterierna och skapa sedan ärendet. Skärmbilden visar urvalet före skapandet.

7. Kontrollera om det ursprungliga problemet har blivit lättare att hantera

Efter lanseringen återvänder teamet till meningen det skrev tidigare:

“Nya ägare av arbetsytor har svårt att hitta var de bjuder in sina kollegor.”

Kan nya ägare nu hitta inbjudningsfunktionen utan att få platsen utpekad? Kan de gå vidare genom det befintliga formuläret? Tyder supportsamtalen på att samma förvirring fortfarande uppstår?

Om teamet har lämpliga produktmätningar kan det även titta på hur många nya ägare av arbetsytor som påbörjar och slutför en inbjudan. Siffrorna behöver sammanhang: vissa ägare kanske avsiktligt arbetar ensamma, och andra ändringar kan påverka resultaten.

I den här fiktiva berättelsen behöver vi inte hitta på ett lyckat resultat. Det användbara nästa steget är att observera vad som händer och lägga till lärdomarna på kartan.

Om ägarna hittar funktionen men fastnar senare har teamet ett mer specifikt problem att utforska. Om ändringen hjälper kan teamet avgöra om ytterligare en förbättring är värd att arbeta vidare med.

Det ursprungliga önskemålet var brett. Planen som kom ur det är fokuserad: ett tydligt problem, en vald åtgärd, en hanterbar omfattning och ett sätt att kontrollera om åtgärden hjälpte.

Det är det som gör kartan användbar. Den för samtalet från ”vi borde förbättra det här” till ett överenskommet nästa steg, samtidigt som resonemanget och de obesvarade frågorna finns kvar i blickfånget.

#Tankekartor#Produktledning#Jira#Produktutforskning

Relaterade artiklar

Kontakta Oss

Frågor om artikeln? Låt oss diskutera era tekniska mål.

Dina Uppgifter