Gemensam karta med kontextdiagram

I början av min konsultkarriär fick jag ett uppdrag där jag skulle fånga in krav för ett ”byggsystem”. Det fanns två systemägare på olika nivåer i organisationen som var rörande överens när de skulle förklara ansvarsområden och systemavgränsningar. Åtminstone när de var på samma möte. När jag satt med dem var och en för sig så förstod jag dock att de egentligen bara verkade överens  till 90%. Jag upplevde att de resterande 10 procenten undveks för att de inte ville hamna i konflikt. Jag fick känslan att båda systemägare trodde att den andra eventuellt inkräktade på deras eget ansvarsområde.

Orsak till missförstånd

I området personlig kommunikation kan man bland annat lära sig att en anledning till att vi missförstår varandra är att vi har olika kartor som utgångspunkt. Dessa olika mentala kartor gör att vi filtrerar, tolkar och talar förbi varandra. Och därför uppstår missförstånd.

Utmaningen är att vi tror att det mesta är så självklart att vi inte bekymrar oss om att säkerställa att vi har samma karta. Inte ens människor som känt varandra och jobbat ihop med samma saker har alltid samma utgångspunkt och sammanhang.

I fallet med de två systemägarna noterade jag tidigt att de inte hade riktigt samma karta. Det fanns små motstridigheter och olikheter i deras beskrivningar – de sa byggsystem och byggverktyg om vartannat. Saken var den att deras beskrivningar endast var muntliga. I gemensamma möten kunde de lätt glida undan dessa motstridigheter. Jag var tvungen att hitta ett sätt att få dem 100% överens så att jag kunde lyckas med mitt uppdrag.

Skapa en gemensam karta och ett sammanhang

I ett tidigare inlägg skrev jag om vikten av att få ner saker i skrift eller bild. I det här fallet använde jag dokumentationsstilen kontextdiagram som skulle visa sig förlösande. Ett kontextdiagram är något så enkelt som ett diagram, en bild, över en produkt eller ett system och dess omgivning. Syftet är illustrera produktens omfattning och avgräsningar och visa omgivande användargrupper och system som produkten kommunicerar med.

Här är ett enkelt exempel som visar kontextdiagrammet för en mycket enkel webbplats:

De centrala delarna i ett kontextdiagram är:

1. Produkten/systemet som omfattas av systemkraven. Det (eller dem) brukar jag alltid rita med en riktigt fet ram.
2. Kringliggande system och användargrupper. Användargrupperna är mycket viktiga. I början använde jag neutrala figurer men jag har mer gått över till bilder som illustrerar typen av användare.
3. Pilar som anger informationsflöde.
4. Beskrivningar av system och information. Oh, så lätt at glömma! Men ingen bild är komplett utan en beskrivning av vad som visas i bilden. Beskrivningen ska förklara symbolerna du använder, varje system, varje användargrupp, varje informationsflöde.

I bilden ovan har jag också förtydligat delsystemen i Dropbox. Man ska dock inte gå för långt i denna nedbrytning så att den blir för detaljerad eller allt för IT-nära beskrivning.

Är inte detta ett _____-diagram?

Nu kanske du hävdar att detta är en applikationskarta, en systemkarta eller liknande men det är inte riktigt sant. Applikationskartor och systemkartor kan vara mycket snarlika men de är mer IT-nära artefakter och de är inte alltid avsedda att sätta ett enda system i fokus för att visa dess sammanhang (kontext).

Man kan säga att kontextdiagrammet är ett slags dataflödesdiagram – men bara nästan. Ett bättre namn är i så fall ”omfattningsdiagram” eftersom ett viktigt syfte är att identifiera avgränsningarna för ett specifikt system eller en produkt. Det handlar inte om att rita en komplett systemkarta och systemen på bilden är inte ”jämbördiga”.

Centralt är det system vi ska kravställa. Sedan ska endast de system vara med som direkt eller indirekt har en betydelse för systemet vi kravställer. Det är alltså en högsta nivå av översikt över ett system och dess omgivning. Samtidigt gäller det att vara tillräckligt tydlig för att inte abstrahera bort viktig information för ändamålet: att klargöra vad kraven avser och vad de inte avser.

En annan invändning kan vara att i kontextdiagrammet ovan så borde inte ”Dropbox” finnas med för det är för perifert. Kan vara riktigt men i det här fallet är det en övervägning och det visar faktiskt något väsentligt. Det är nämligen så att dokument lagras både i Webbplats och i Dropbox och det kan vara samma dokument. Varför finns det ingen pil mellan webbplats och Dropbox? Jo, därför det inte finns krav på det eller någon sådan integration. Jamen, vore inte det en bra idé? Aha!

Arbetssätt

Kontextdiagrammet är bland det första jag gör för att skapa en gemensam bild över arbetet. Första versionen brukar aldrig vara rätt. Inte andra eller tredje heller. Faktum är att justeringar kan behövas under rätt lång tid. När den har varit stabil ett tag så tittar jag på den igen eller låter någon intressent titta på den. I många fall krävs ytterligare justeringar.

Det räcker inte att rita bilden. Den textuella beskrivningen är en valideringshjälp till att få bilden rätt och komplett. Många tankefel och missar blir tydliga när man formulerar sig i text och inte bara nöjer sig med en bild som man antar att alla förstår och är överens om. Så jag vill understryka punkt 4 ovan: utan beskrivningen är kontextdiagrammet inte komplett. När det gäller informationsflöden är det inte alls olämpligt att hänvisa till objekt eller entitetstyper i en objekts- eller informationsmodell (konceptuell datamodell).

Beroende på form för arbetet så kan kontextdiagrammet tillhöra linjen eller projektet. Om det används i ett projekt är det alltid vettigt att leverera ett komplett kontextdiagram som en leverabel.

”Byggsystemets” kontextdiagram blev byggverktygets

Så här blev kontextdiagrammet i uppdraget jag skrev om i inledningen. Utmaningen – och det viktiga – är att ta med precis så mycket som är tillräckligt att visa sammanhanget. Varken mer eller mindre.

Det förlösande var att i bild visa hur ”byggsystem” (build system) och ”byggverktyg” (build tool) förhöll sig till varandra och de kringliggande systemen och användargrupperna. Det visade sig att det inte alls var ekosystemet ”byggsystem” som skulle kravställas och en viktig del av arbetet innebar alltså att definiera de två begreppen och sätta dem i ett sammanhang – dess kontext. Vad menade vi egentligen med byggsystem respektive byggverktyg? När detta var tydliggjort var de 10% som indikerade att de inte var överens som bortblåsta och min känsla av potentiell konflikt eliminerades.

I det här fallet visade det sig alltså att kraven som jag skulle fånga och specificera faktiskt gällde tre delsystem i kartan. Jepp, de är illustrerade som rutor med lite fetare ram och det är alltså dessa separata systems kontextdiagram vi ser (inte byggsystemets!). Med kartan blev det plötsligt väldigt enkelt att sortera bort krav som inte var relevant för uppdraget och att hänföra dem till rätt system.

Genom att tidigt skapa en gemensam karta så kan tid sparas och många onödiga missförstånd elimineras i sin linda. Förvånansvärt ofta finns det förbluffande olika uppfattning om vilka system som existerar och hur de interagerar med varandra. Fördelen med att levandegöra kartan med användare och användargrupper  – inte bara system – är att den bättre kan förstås av kunder, verksamhet och leverantörer.