Blog om agile metoder, udvikling og ledelse


erfaringer, proces, tidsregistrering, data

Tavs viden

Morten Ulrik Sørensen | 10.01.2021

Der er ideér, der er så logiske, at man er nødt til at lære af egen erfaring, at de ikke virker.

Har I hørt om "tavs viden"? At man har vidst noget så længe og så grundigt, at man ikke længere tænker over hvor man ved det fra, og hvordan man nu kan være så sikker på det?

Af og til hører jeg om projekter, hvor der bliver taget beslutninger, som åbenlyst er kontra-produktive. Altså åbenlyst for "os garvede", der har prøvet lidt af hvert inden for software-udvikling over en længere årrække, men øjensynligt ikke åbenlyst for alle.

Eksempler:

  • "Vi laver en komplet backlog og estimer alting, så vi ved, hvornår vi er færdige"
  • "Vores estimater rammer skævt, så nu måler vi omhyggeligt hvordan vi bruger vores tid, så vi kan lære at estimere bedre"
  • "Vi opdeler ansvaret, så hver udvikler har sine klare ansvarsområder"

Tavs viden

Jeg ved, at der ikke kommer noget godt ud af det, men det er faktisk nogle gange svært at forklare hvorfor. Hvorfor så det? Jo, jeg har selv været der; jeg har selv været med til at prøve at føre det ud i livet, og jeg fandt ud af, at det "selvfølgelig" ikke virker.

10 år og en slat senere ved jeg stadig, at det ikke virker, men jeg tænker ikke over hvorfor — jeg ved det bare. Og jeg har efterhånden glemt, at jeg selv engang syntes, at ideen var overbevisende.

Bedre tidsregistrering giver bedre estimater - or not

Lad os prøve at tage den med at timeregistrere grundigt, så vi kan få bedre forståelse hvor tiden bliver af, så vi kan lære at lave gode estimater.

Alle skal "bare" notere i timeregistreringssystemet hvilke opgaver og delaktiviteter, de bruger tiden på, så vi får erfaring for hvor lang tid de forskellige opgaver tager. Så kan vi sammenligne de oprindelige estimater, se hvor forskellen er stor, og blive bedre til at lave korrekte estimater. Man må måle, så man kan få noget at lære af, ikke?

Hvordan går det, når man prøver?

skakur med 10 urskiver

Det lyder nemt, men er det ikke i praksis.

Detaljeret timeregistrering er umanerligt bøvlet og frustrerende for dem, der prøver at føre det ud i livet. Ja, jeg skal "bare" huske at notere tiden hver gang jeg skifter opgave, men:

  • jeg har (forhåbentlig) hovedet fuldt af opgaven, ikke af at tidsregistrere.
  • jeg bliver afbrudt masser af gange i løbet af en dag for at hjælpe en kollega[^Her vil nogle så påpege, at jeg ville kunne arbejde bedre på min egen opgave, hvis jeg koncentrede mig om den. Det er rigtigt, men for mig er det forstyrrelsen værd hvis helheden bliver bedre. YMMV.]
  • hvor meget tid bruger jeg på at planlægge? kode? teste? Jeg skifter flydende mellem dem, så det bliver et klart tja...

Og hvis vi er flere på teamet, gør vi det så ens? Har vi forstået opdelingen på samme måde? I tvivlstilfælde, vælger vi så på samme måde? Det kan blive endog meget tvivlsomt, om data kan sammenlignes.

Det har nogle utilsigtede negative konsekvenser

Hvis vi forlanger at teamet tidsregistrerer med meget høj opløsning, så gør vi det "dyrere" at skifte mellem aktiviteterne.

En kollega, der spørger om hjælp? Det må lige vente, for så skal jeg se på uret og finde ud af hvilken opgave kollegaen arbejder på og skrive det ned. Så er det lettere at sige nej.

Eller hvis det lyder som et hurtigt spørgsmål, så svarer jeg lige. "Hurtige spørgsmål" har det dog med at føre noget mere med sig og komme et par spadestik dybere, i alles interesse, men hov — hvornår var det nu, vi startede?

Og som alle målinger af mennesker: hvis jeg tror at ledelsen sætter større pris på aktivitet A end aktivitet B, og jeg ikke helt kan huske hvordan min tid har fordelt sig, så kræver det meget rygrad at gætte så ærligt som muligt uden at skele til, hvad de højere magter nok helst vil se.

Og ud over at jeg kan rapportere forkert, så kan det jo også påvirke mig så jeg bruger mere tid på det, jeg tror sætter mig i det bedste lys. Er det ikke bedre at jeg arbejder på det, jeg mener er bedst, end på det, jeg menere ser bedst ud?

Samtidig kan jeg jo også bruge min timeregistrering til at påvirke målingerne derhen, hvor jeg synes. Medarbejdere, der synes vi holder for mange møder, vil helt sikkert huske at få dem med i timeregistreringen. Rundet op.

Og én ting er at tidsregistrere sin egen tid detaljereret, fordi man selv synes det er en god idé. Hvis man beder sine medarbejdere om det, så beder man dem om at bruge tid på noget, de måske ikke kan se meningen med; noget, som de opfatter som overvågning og mistillid.

Vi kan ikke måle uden at påvirke systemet — ikke i kvantemekanikken, og heller ikke med mennesker.

Man får "data", men kvaliteten er elendig

Så det er svært at tidsregistrere meget detaljeret, og incitamenterne er også til ikke at stille sig selv i et for dårligt lys.

Så får vi tal, men kan de bruges til noget?

Selv gode data om sidste opgave siger ikke så meget om den næste

Hvad siger tidsforbruget om de sidste opgaver egentlig om tidsforbruget på den næste opgave? Den handler jo om noget andet, den er mere/mindre kompleks, den har mere/mindre brugerinteraktion og flere/færre lettere/sværere integrationer med andre systemer, og så har den faldgruber, vi i sagens natur ikke kender på forhånd.

I bedste fald indser man, at datakvaliteten er dårlig

Hvis man selv har været med i eksperimentet med at tidsregistrere, så har man forhåbentlig indset, at data ikke er helt til at stole på. Så kan man stoppe igen, og glæde sig over sin nye forståelse. Måske kigge på de indsamlede data og prøve at drage nogle slutninger, men ikke tage dem for alvorligt. Og så forhåbentlig finde et mere passende niveau at timeregistrere på fremover — lige tilpas, eller Quantum Satis.

I værste fald tager man data alvorligt

Hvis man ikke opdager, at datakvaliteten er ringe, og i stedet tror at man har "sandheden", så risikerer man at tage beslutninger på et misforstået grundlag.

  • "De opgaver hvor vi har holdt møder i mere end 30% af tiden har givet anledning til dobbelt så mange fejl, så lad os holde færre møder". Eller også var det de svære opgaver, vi holdt møde om?
  • "Vi har jo skrevet en user story — så skal udviklerne jo ikke snakke med brugerne for at forstå behovet". Jo.

Hvad så med...

"Hvad så med at installere et program på medarbejdernes computere som automatisk registrerer hvad de bruger tid på?".

Nej. Bare nej.

Hvordan laver man bedre estimater?

My 2 cents? Man skal sørge for at estimaterne er billige at lave, og at det ikke er supervigtigt, hvor præcise de er.

Præcise nok til at planlægge en måned frem; det er let nok. Specielt hvis alle er klar over, at vi nok når det vi aftaler plus cirka lige så meget, som ingen har tænkt på endnu.

Præcise nok til at vide hvordan produktet ser ud om et år? Jeg vil hellere spå om vejret et år ud i fremtiden, og det har jeg ikke engang nogen indflydelse på.

Det er meget vigtigere at prioritere mellem opgaverne end at kunne forudse præcis hvor lang tid hver opgave tager.

Lær af andres erfaringer?

Når viden sådan er blevet tavs kan det godt være svært at forstå (eller huske), at andre ikke har den samme forståelse (endnu).

De burde kunne se det.

Eller de burde kunne forstå det, når man nu forklarer det.

Men det er svært at forklare, at noget der ser logisk og rationelt ud ikke virker, og det er svært at forstå, hvis man ikke selv har prøvet det.

Måske kan en forklaring og andres erfaring hjælpe til, så man kommer hurtigere igennem eksperimentet, men jeg har indset, at der er nogle erfaringer, man nok er nødt til at gøre selv.

Det er der sikkert også andre forældre end mig, der har tænkt — at der er nogle ting, som ens børn nok først forstår, når de selv har prøvet, uanset hvor meget vi prøver at forberede dem.