Ofta när man diskuterar kommunikation så handlar det om hur man ska förmedla något som ”avsändare” av information. Men eftersom kommunikation oftast handlar om en dialog så behöver vi erkänna att vi har två sändare och två mottagare. Det kan var en obalans av aktivitet mellan parterna men det är en dialog även om den ena pratar och den andra bara hummar jakande.
Det finns en term som jag tycker man kan använda sig av för att beskriva detta ”feedbackande” och det är att reflektera. Normal pratar man om att man reflekterar och summerar i samtal, men det är ett koncept som kan användas i mycket mer än samtal. Det belyser en otroligt viktig egenskap i kedjan att realisera ett krav. Det är inte en envägskommunikation som möjliggör att man träffar rätt – att behovet som kommunicerats initialt, faktiskt resulterar i just den ”feature” som faktiskt efterfrågades. Det kräver att man kontinuerligt återkopplar och säkerställer att det man hört faktiskt överensstämmer med det som var tanken hos avsändaren. Vi kan minimera risker genom att minska antalet led och överlämningar, men så länge inte idén föds och implementeras av samma person så behövs feedbackloopen (= reflektion). Det handlar ju inte bara om att bara putta information nedströms. Både avsändare och mottagare vill ha kvitto på förståelse, då information filtreras efter mottagarens hjärna och inte sändarens.
Vid det här laget börjar säkert några av er skruva på sig och tänka: ”men det är ju detta som t ex user stories adresserar och andra agila tankesätt som fokuserar på att facilitera konversation. Japp, helt rätt! Jag har inte hävdat att vi inte har verktygen. Men även där det faktiskt finns verktyg på plats så missbrukas de. Några exempel:
Det finns också många konstellationer där det inte finns tydligt utarbetade verktyg eller metoder, eller där personerna är "omogna" i sina roller. I dessa fall är det viktigt att lyfta fram just behovet av reflektion och att jobba sig fram till en gemensam sanning.
Jag har jobbat med mjukvaruprojekt i över 15 år och om jag ska fokusera på de roller som tar ett krav och översätter det från en idé till fungerande feature så har jag innehaft några: strateg, beställare / verksamhetsanalytiker, kravanalytiker, lösningsarkitekt, och utvecklare. Och jag kan konstatera följande: som mottagare av information blir man uppskattad om man kontinuerligt kan ge kvitton på att man förstår vad som förmedlats, samt att man möter upp med frågor och vidare utvecklingar.
Under en middag med min fru, som är psykiatriker, kom jag in på behovet och ibland bristen av "feedbackande" i min professionella vardag. Inom samtalsterapi pratar man om reflektion som en del av intervjutekniken som används vid motiverande samtal – reflektion och komplex reflektion.
Jag tycker båda dessa former är väldigt träffande och adresserar just det som jag som avsändare förväntar mig av mottagarna av mitt ”meddelande” (även om situationen inte är ett terapisamtal ;)).
I ett behovsrealiseringsflöde så är samtal inte det enda mediet av kommunikation. På samma sätt som man väljer verktyg att kommunicera ”nedströms” så bör man ha verktyg för att reflektera. Dvs hur ser jag som mottagare av information till att skapa säkerhet i att jag förstått vad som sagts och att vi inte pratar förbi varandra? Jag är inte ute efter att hitta nya verktyg, för det har vi som sagt tillräckligt många av. Dock är jag ute efter att lyfta fram behovet och göra oss medvetna om det. För som det ser ut idag så har olika roller olika tyngd och naturliga inslag av detta moment, trots att det skulle gagna alla att få detta till en naturlig del av sin verktygslåda och sätt att arbeta.
Målet borde vara att genom reflektion visa att man lyckats omvandla informationen man fått kommunicerat till sig till något med mening och att vi faktiskt kan skaka hand kring en gemensam sanning.
Tänk inte bara på hur ni gör er förstådda, utan även hur ni visar att ni förstår!
Vad använder ni er av för metoder, former och tricks för att få till denna handskakning?
Robert Wallerblad, Require AB
