Når vi skriver krav og ønsker til software, bør vi tvinge os selv til at sætte farten ned, fokusere vores opmærksomhed og tænke dybere over, hvad det er, vi skriver om. Selvom det er dig selv, der skriver, skal det, du skriver, med stor sandsynlighed ikke kun læses af dig.
"Vi skal kunne tracke, hvilke lastbiler der nærmer sig et lager," kan et ønske f.eks. lyde.
Først når man tænker over, hvad det er, man skriver, opstår hullerne, og uoverensstemmelserne begynder at vise sig. Processen med at skrive viser sig at kræve potentielt mange minibeslutninger, og det er eksistensen af disse, der adskiller klare, mere nøjagtige krav fra uklare og mindre nøjagtige ønsker.
Det er de uklare krav og ønsker, vi må fokusere på enten at minimere eller lade helt være, så fokus netop kan være på de ting, vi ved med større sikkerhed, kan svare på.
Når vi skriver, begynder vi altså at tænke over, hvad ordene betyder i den sammenhæng, der er med de krav og ønsker, vi forsøger at formulere.
Hvad vil det sige at "tracke"? Er tracking en manuel handling udført af chaufføren? Er tracking en automatisk handling udført af f.eks. en gps-sender på lastbilen? Har alle lastbiler de samme egenskaber? Hvad er trackingfrekvensen? Skal en lastbil have plads til at tage noget med fra lageret? Hvordan finder vi ud af, om lastbilen er tom? Hvad vil det sige at nærme sig et lager?
Du kan godt se, at når vi begynder at tænke over det, vi forsøger at formulere som et krav eller ønske, så dukker potentielle huller op i form af spørgsmål til dig selv. Spørgsmål, som skal kunne svares på.
Et brugt udsagn, jeg er stødt på ofte, når vi har hjulpet software-organisationer med at få flere gode vaner, er, at der ofte eksisterer en manglende erkendelse af, at der skal bruges mere tid på at tænke over de krav og ønsker, der måtte være, og mantraet ender derfor ofte med at blive "vi arbejder agilt, så vi ved ikke alt nu, vi må arbejde med det, vi ved".
Det er ikke godt nok.
For det første er der ingen, der ved alt på noget som helst tidspunkt. Og det er forhåbentligt heller ikke forventningen. Men at kalde det agilt ikke kan formulere krav og ønsker, er direkte forkert. Hvis man ikke kan formulere sine krav og ønsker, kan ingen forvente et output, der rammer indenfor skiven. Vi skriver også for at minimere personlige fortolkninger.
Forstyrrelsen, det giver hos et team, når et krav eller ønske ikke er ordentligt nedfældet, er muligvis en af de største flaskehalse i kontinuerligt at kunne bevæge sig i et bæredygtigt og fremadgående tempo.
Det er først, når vi har tid til at lege med et problem, at vi kan håbe på at tænke væsentligt over det. At skrive kræver, at vi kan holde fast i det, vi ønsker at formulere, i ligeså lang tid, som det kræver, så læseren efterfølgende kan udvikle en dybere forståelse af det, som er skrevet.
Det er i den skrivende proces, hvor du muligvis indser, at du faktisk ikke forstår, hvad det er, du skal formulere. Når du nedfælder krav og ønsker til andre, uden selv at have forstået dem, er det så ikke meget at forlange, at læseren skal forstå det?
Du kan selvfølgelig sagtens lære meget om noget uden at skrive om det. Men at skrive om noget kompliceret og krævende fungerer altså som en test, der belyser, hvor godt du selv forstår grundlaget. Når vi kommunikerer vores arbejde for os selv, inde i hovedet, opdager vi ofte, hvordan noget, der virker så simpelt i vores hoveder, bliver forklaret helt forkert, når vi begynder at skrive om det. Det er, som skrevet længere oppe, at hullerne skal afdækkes.
Diagrammer og præsentationer er ikke skrevne ord. De kan selvsagt ikke beskrive ting på samme niveau som med det skrevne ord. Det er ikke at sige, at de er unødvendige. Så vi kan ikke skygge for vores fattige tankevirksomhed, når vi bruger tid på at skrive ting, andre skal forstå, med tegninger af den ene eller anden karakter.
Når du skriver, udvikler du også helt naturligt et forhold til den tekst, du har skrevet. Programmøren, forfatteren eller journalisten vil kunne nikke genkende til det udsagn. Forholdet opstår, fordi du har brugt tid på at tænke over, hvad du har skrevet. Der er også derfor, det kan være svært at slette igen.
I skriveprocessen vil du også opleve at blive klogere på, at det, du skrev, måske ikke var sandt. Eller at du blot tog fejl. Også kommer skrivning til at give dig en reflekterende indsigt, hvor du føler, du bliver klogere, samtidig med du skriver. Og det er ikke blot en god egenskab for, når du nedfælder krav og ønsker, men en ganske stor berigelse for ens egen udvikling.
Skrivning har andre egenskaber, når vi taler om nedfældelse af krav og ønsker til software. Man kan
f.eks. altid vende tilbage til det skrevne. Man kan reflektere over det. Stille spørgsmål til det og blive klogere af det. Også kan man tilføje eller slette i det skrevne, når noget ikke længere er korrekt eller interessant. Det minimere samtidigt den kognitive belastning ved ikke at skulle jonglere med det oppe i hovedet.
Til sidst vil jeg sige, at det er en rigtig ufornuftig løsning at lave verbale aftaler, når det handler om krav eller ønsker til software (eller andet arbejde). Det verbale har ingen af de samme karakteristika som det skrevne og værst af alt belaster det den kognitive evne, når informationerne skal videregives og forstås. Det verbale lægger i større grad op til personlig fortolkning, fordi vi ikke på samme måde kan kontrollere vores evne til at holde styr på, hvad det verbale fører til, når der opstår huller og misforståelser. Et fint eksempel er ovenstående krav og de efterfølgende spørgsmål - prøv du at huske på, hvad diskussionerne har været omkring det krav, når du ikke har nedfældet dem, men kun har dem oppe i hovedet.
Skriv alle jeres krav og ønsker ned. Stil spørgsmål med tekst. Hold krav og ønsker samlet et sted, samt spørgsmål til dem.