Dette indlæg er alene udtryk for skribentens egen holdning.

Djævlen er i detaljen - men kan du huske detaljen?

27. oktober 2016 kl. 18:169
Artiklen er ældre end 30 dage

En mandag morgen for et par uger siden var jeg på vej på arbejde efter en afslappet weekend.

Jeg tjekkede, kort inden jeg nåede til TICRA, min e-mail på telefonen, og en ny e-mail fra en kunde, vi er ved at løse en opgave for, tikkede ind.

Ugen forinden havde jeg sendt kunden en opdatering på opgaven, og jeg havde påpeget, hvad der måske - troede jeg - kunne være en mindre knast. Jeg var dog ikke bekymret for, at det skulle være et stort problem.

E-mailen blev en brat opvågning: Der var i sandhed tale om et problem, som vi var nødt til relativt hurtigt at finde en løsning på.

Artiklen fortsætter efter annoncen

Det småregnede og føltes med ét som mandag morgen.

Opgaven handler om at designe en såkaldt hornantenne - som jeg før har skrevet om - der skal opfylde en række lovbestemte krav. Når vi har leveret designet, får kunden dette og kan fremstille antennen, f.eks. til brug på en satellit eller ved kommunikation med satellitter. Antennen skal fungere i to frekvensbånd, idet den typisk skal sende og modtage på forskellige frekvenser.

Problemet bestod i, at antennens opførsel ikke mødte alle kravene i det ene af disse frekvensbånd - og desværre det mest kritiske af de to.

Min chef og jeg kiggede straks på problemet. Vi besluttede at træde nogle skridt tilbage i designprocessen og forsøge at nå et andet design derfra. Udgangspunktet, dvs. hvor langt vi skulle gå tilbage, diskuterede vi, og i blandt et par kandidater valgte vi ét tidligere design, som vi ville gå videre fra.

Artiklen fortsætter efter annoncen

Jeg fortsatte derpå designprocessen - som i praksis foregår med avancerede matematiske optimeringsalgoritmer - og i denne uge gjorde vi status over designet.

Hornantennen var på visse parametre blevet bedre og på andre værre, men globalt set var vi ikke nået til et bedre design. Vi var, følte vi, havnet i en blindgyde.

Vi overvejede derfor påny at gå nogle skridt tilbage og prøve en anden fremgangsmåde. Vi blev enige om at tage et andet udgangspunkt end to uger tidligere, og vi forstod i første omgang ikke, hvorfor vi havde prioriteret, som vi havde to uger tidligere - og altså ikke taget det udgangspunkt, vi nu ville prøve.

Det var to uger siden, men jeg kunne ærligt ikke huske argumenterne. Jeg kiggede derfor tilbage i min arbejdsjournal, hvor jeg i detalje havde forklaret vores grunde til at vælge, som vi gjorde. Og forklaringen gav mening med de informationer, vi for to uger siden havde haft. Siden var vi blevet klogere, og det var derfor nu mere oplagt at tage et nyt startpunkt.

I den her proces slog det mig - igen - hvor vigtigt det at skrive arbejdsjournal er. Det var to uger siden, og jeg kunne ikke huske detaljerne. Ikke fordi min hukommelse fejler noget, men fordi der undervejs havde været mange andre detaljer igennem hovedet.

Detaljerne, jeg har arbejdet med i dag, husker jeg givetvis uden problemer om en halv time. Og i aften. Men hvad med i morgen? Og i næste uge? Jeg husker dem nok ikke, men det gør min arbejdsjournal - hvis jeg husker (!) at skrive den.

Nogle gange trækker det tænder ud at journalisere dagens arbejde, når klokken er mange, og man er træt i hovedet. Men jeg har lært, at det kommer tifold igen - dels for at tømme hovedet, før man går hjem, dels for at kunne vende tilbage til detaljerne, argumenterne og resultaterne på et senere tidspunkt.

Så lad mig høre: Kan du huske detaljerne, du arbejdede med for to uger siden?

Hvis ikke var det måske på tide at begynde at skrive en arbejdsjournal.

9 kommentarer.  Hop til debatten
Debatten
Log ind eller opret en bruger for at deltage i debatten.
settingsDebatindstillinger
9
5. november 2016 kl. 19:37

Jakob, dit indlæg rammer 100% plet i forhold hvordan jeg bruger min spiralblok. Godt formuleret.

Bent.

8
5. november 2016 kl. 19:27

Generelt er der i kommentarerne ovenfor meget fokus på at skrive fælles beslutninger og procedurer ned, således at alle medarbejdere/kolleger/projektmedlemmer kan tilgå dem. Og det giver god mening.

At skrive arbejdsjournal er dog, for mig, noget andet end sådanne møde- og beslutningsnotater. En arbejdsjournal er primært skrevet til mig selv, og den indeholder ganske meget tekst med detaljerede beskrivelser af, hvad jeg har gjort, og hvad jeg fremadrettet skal gøre. Den indeholder også idéer, formodninger, hypoteser og strøtanker, som muligvis kan have værdi for andre, men som også primært er skrevet til mig selv.

Sommetider deler jeg tekst, tabeller, billeder eller lignende fra min arbejdsjournal med kolleger, og der intet hemmeligt i den; det er ikke en personlig dagbog, men en journal formuleret i et nøgternt (men måske nok sommetider indforstået) sprog.

Arbejdsjournalen er således et ideelt sted til at læsse af for at tømme hovedet - og til senere at vende tilbage til.

7
3. november 2016 kl. 11:10

Nu har jeg prøvet både at lave versionsstyret SW udvikling og projektarbejde på automationsprojekter, og jeg kan fornemme at flere af kommentarerne ovenfor kommer fra SW verdenen.

Jeg tror faktisk at arbejsloggen har en fordel frem for blot at bruge versionsstyring og revisionsstyring til at logge beslutninger og efterfølgende rettelser i projektet.

Her ligger djævlen i detaljens mangfoldighed, hvor udfordingen er at mappe/matche en beslutning til hvilke designelementer der er ændret når flere typer af produkt med flere typer versionsstyring bliver ændret af flere deltagere.

Hvis arbejdsloggen og beslutningsreferatet ligger på plads og måske ovenikøbet er tilgængeligt i versionsstyringen og dokumenthåndteringen er det nemmere at få en unik reference alle kan bruge når arbejdet checkes ind (sendes til kunden, kompileres, sendes til CAD osv).

Problemet bliver jo ellers at alle har hver deres ide om hvordan ændringerne skal dokumenteres og logges.

6
30. oktober 2016 kl. 22:19

Under versions-styring af hvad?

SVN eller Git, alt afhængigt af hvilken versions-styringsteknologi projektet bruger. Det er mest for at kunne få en commit-log på en given fil, med datoer og tilhørende kommentarer. Princippet gælder vel for alle typer versionsstyring.

5
30. oktober 2016 kl. 11:56

Jeg skriver ned undervejs hvad der bliver gjort, beregnet, testet osv. i en A4-blok med spiralryg.
At skrive i hånden fastholder mentalt processen, ideerne, arbejdet osv., og skitser/diagrammer/beregninger kan man lave direkte.
Og at slå tilbage i hæftet giver et super overblik.
At fylde informationerne ind i firmaets system har vi en sekretær til.</p>
<p>Men jeg er nok mærkelig... mit yndlingsværktøj er stadig en HP-15C

For mig at se handler det ikke i første omgang om, hvilket værktøj man bruger - analogt eller digitalt. Derimod handler det om at man i det hele taget skriver procedurer, tanker, hypoteser, ideer mv. ned.

Når man har den rytme, skal man så finde ud af, hvilket værktøj som er det rigtige.

Jeg foretrækker personligt en digital løsning (Evernote), som jeg kan tilgå, uanset hvor jeg er - som det er nemt at dele med andre - og som det er relativt nemt at søge og flytte rundt i. Men når en spiralryg-blok fungerer, hvorfor så lave det om?

4
28. oktober 2016 kl. 23:41

Jeg skriver ned undervejs hvad der bliver gjort, beregnet, testet osv. i en A4-blok med spiralryg. At skrive i hånden fastholder mentalt processen, ideerne, arbejdet osv., og skitser/diagrammer/beregninger kan man lave direkte. Og at slå tilbage i hæftet giver et super overblik. At fylde informationerne ind i firmaets system har vi en sekretær til.

Men jeg er nok mærkelig... mit yndlingsværktøj er stadig en HP-15C

Bent.

3
28. oktober 2016 kl. 16:41

Bruger mest git. men nogen steder subversion.

Mange har bare den forfærdelige dårligdom at de kommer til at skrive i commit loggen HVAD de gjorde - og det er jo fuldtstændig meningsløst, for det kan man se i verionsstyringssystemat automatisk - og de GLEMMER at notere FORMÅLET med det commit.. altså hvad det evt. skulle løse etc.. Jeg foretrækker altid at putte sagsnr. på hvis jeg har sådan nogen f.ex. så man kan se mere om hvad jeg forsøgte at løse.

2
28. oktober 2016 kl. 13:07

Jeg smider al dokumentation under versions-styring med beskrivende kommentarerer.
Det gør det overskueligt at søge efter nøgle- eller stikord hvis man skal tilbage til en beslutning der er taget for længe siden.

Under versions-styring af hvad?

1
28. oktober 2016 kl. 11:32

Jeg smider al dokumentation under versions-styring med beskrivende kommentarerer. Det gør det overskueligt at søge efter nøgle- eller stikord hvis man skal tilbage til en beslutning der er taget for længe siden.