Tala är silver, skriva är guld

När det agila manifestet ses som universallösning på systemutvecklingens utmaningar har vi en tendens att slänga ut barnet med badvattnet och övertolka principer som ”fungerande programvara framför omfattande dokumentation”.

Omfattande dokumentation vantolkas inte sällan som ”så gott som ingen dokumentation – i alla fall inte mer än vad jag behöver nu” och plötsligt har vi dragit undan mattan för möjligheten att kommunicera bakomliggande behov och krav i skriftlig form över lång tid. Allt ska lösas genom att individer pratar med varandra i samma rum. Om systemutveckling ändå alltid vore så enkelt (ibland är det, men långt ifrån alltid).

Att god kommunikation är en avgörande ingrediens för framgångsrik systemutveckling torde ingen behöva ifrågasätta. Men det blir naturligtvis inte god kommunikation av sig självt. Varken genom att bara sätta produktägare och utvecklare i samma rum eller genom att bara uttrycka systemkrav för stunden. Det förbättrar möjligen situationen från ett sämre läge men risken är besvikelser då resultaten inte blir enligt förväntningarna.

Tala är silver

Muntlig kommunikation har en mängd fördelar och jag är stark förespråkare för att samla intressenter i ett rum och låta dem samtala för att lösa specifika problem. Men det är inte det enda verktyget som ska användas för att lösa alla problem. Muntlig kommunikation har nämligen också en rad brister som påverkar både kortsiktig och långsiktig kvalité i systemutvecklingen.

(C) The New Yorker Collection, James Stevenson, 1976

1. Vi uttrycker oss inte så tydligt som vi tror.
   Det dunkelt sagda är det dunkelt tänkta (Esaias Tegnér). Det pratas och pratas men det blir inte tydligare för någon ändå.
2. Vi glömmer vad som sagts.
   Redan efter ett par timmar  kan vi ha glömt vad som sades eftersom vi har så mycket saker att tänka på.
3. Vi lyssnar dåligt.
   Bristande koncentration, förutfattade meningar, antaganden och förhastade slutsatser gör att vi lyssnar till hälften och bygger fel lösning.
4. Den som är mest tongivande styr.
   Den som anses vara viktigast, som har mest makt eller som pratar mest är inte nödvändigtvis den som har förstått behoven eller är den som ifrågasätter dem på rätt sätt. Med talets gåva går det att undvika vilka muntliga invändningar som helst och slå in på en väg som inte är den bästa för verksamheten.
5. Personen som visste försvinner.
   Personalomsättningar händer och då kan kunskap försvinna med personen. Den som endast pratar och aldrig skriver blir en riskfaktor för varje verksamhet. Personer kan tro att det är ett sätt att göra sig oumbärlig och behövd (maktfaktor). Det är måhända bekräftande i stunden men det är falskt. Vi är behövda men vi är inte oersättliga. Det bara kostar verksamheten mer när ett orakel försvinner. Och vi har tyvärr inte alltid råd att anställa två personer för samma roll för att kunskapsdela.

Skriva är guld

När vi uttrycker våra behov, förväntningar och krav i text eller bild öppnar sig en rad möjligheter att hantera bristerna i muntliga kommunikation:

1. När vi formulerar oss i text eller ritar en bild framgår det var de logiska luckorna är, var feltänket är eller vad som saknas. Tankar och idéer är fantastiska men att formulera dem och bearbeta dem är oslagbart. Att rafsa ner något på ett papper kan vem som helst. Att modellera är ett strukturerat sätt och mycket kraftfullare.
2. ”Det är självklart”, ”det kommer vi ihåg”, ”jag skriver ner det sedan”, ”vi dokumenterar det när vi är färdiga med implementationen”. Bedrägliga uttalandet som egentligen handlar om att vi i stunden hellre ägnar oss åt det som syns och som ger märkbara resultat nu. Det är roligare och premieras nu. Men om ett år är det verkligen guld att komma ihåg. Alla kan skriva på en post-it och sätta på skärmen. Ett strukturerat sätt gör det både enklare och mer tillförlitligt.
3. När någon berättar för oss får vi inte kartan helt klart för oss omedelbart. Det kopplar naturligtvis till #1 men nu är vi på mottagarsidan. Att skriva ner det vi hör i text och bild gör att vi kan se vad vi inte snappade upp. Vi täpper igen de där hålen och sparar tid senare i utvecklingen. Det gör det möjligt att bekräfta att det du hörde var rätt; att få bilden klar. Och det innan det skrivs en enda rad kod. Ad-hoc är att prata om det på möte efter möte och gå direkt till utvecklingsmiljön. Mer strukturerat är att formulera det i ord och bild och låta upphovspersonen bekräfta det först. Det är guld värt.
4. I demokratiska sammanhang är mötesprotokoll ett viktigt  instrument för att motverka (inte helt lösa) att tongivande personer styr. Man brukar skämta om att den som skriver protokollet har makten men justeringspersonerna är också där för att intyga att sekreteraren hörde rätt och korrekt fick med de viktiga besluten och diskussionerna i protokollet. Systemutveckling syftar inte till att vara en demokratisk process men kravhantering är en ständigt pågående beslutsprocess och genom att skriva ner och låta andra bekräfta (granska) så ökar du chansen att köpa eller bygga rätt system – om alls.
5. System både lever längre och växer sig större än de flesta tänkt från början. I många fall underskattades framtidens ekonomiska förutsättningar och det blir direkt eftersträvansvärt att förlänga livslängden av en IT-investering och att vidareutveckla det. Ju längre systemen lever desto större är risken att personer som var med från början och förstod inte är kvar (jag har varit med om situationer där det inte funnits en enda rad skriven om ett centralt system mer än att det existerar. Man vågade inte stänga ner det för man förstod inte vad det gjorde och hade inte tid att analysera koden.).

Det betyder inte att kommunikation i text och bild är lätt. Men det är inte lätt att lösa svåra problem och det gäller att förstå vilket problem som löses av vilken metod innan vi kastar ut verktyget som har använts för att kommunicera framgångsrikt i tusentals år. Dessutom är granskning av vad någon annan formulerat ett av de mest effektiva sätten att kvalitetssäkra komplicerade beskrivningar som kostar mycket tid och pengar att implementera och testa.

Om vi låter bli att vantolka det agila manifestet så kan vi komma fram till att det för många verksamheter är högst relevant att skriva och förvalta beskrivningar av behov och krav. Det blir exempelvis inte automatiskt vattenfallsutveckling och icke-agilt bara för att man modellerar verksamhetsprocessen innan man kodar. Istället ges verksamheten chansen att ta beslutet att sluta med ett antal aktiviteter och att inte utveckla systemstöd när det plötsligt blir tydligt hur mycket tid och energi som läggs i en verksamhetsprocess till otillräckligt nytta. Det är det vi kallar lean – ta bort slöseriet – och det är mycket svårt att se de dolda argument för att inte göra systemutveckling utan att först ha ett relevant beslutsunderlag.

Nytta för verksameten

Men steget för att komma fram till om det är relevant att arbeta mer strukturerat med sin kravdokumentation går genom att fråga sig om verksamheten kan behöva dra nytta av fördelarna. Då måste man börja med att titta på sin egen verksamhet.

Frågan du som chef bör ställa dig är vad de långsiktiga behoven är. Är det rimligt att kasta all den kunskap som så mödosamt samlats in? Är det rimligt att bara förvalta resultatet av verksamhetens behov i koden? Om behoven förändras – hur vet du då vilken kod eller vilket system som kan tas bort? Hur vet du vilken funktion du kan släcka ner? Och om det är viktigt att förstå och kommunicera behoven idag – är det då inte viktigt att förstå och kommunicera samma behov lika bra i morgon?