Tidsregistrering for udviklere: din egen log

Tidsregistrering for udviklere kan være en personlig log over dine egne timer. Du behøver hverken et editorplugin eller en agent, der tager skærmbilleder, for at føre den.

Loggen kan vise, hvorfor en kort opgave opslugte ugen. Den kan også beskrive arbejdet bedre end »lidt af hvert« og lægge mødetiden sammen.

Hvad registreringen skal bruges til

En personlig tidslog kan besvare fire praktiske spørgsmål:

1. Hvad lavede jeg faktisk denne uge? Ved medarbejdersamtalen er det en liste over arbejde med datoer, ikke »arbejdede på platformen«.
2. Hvad koster en opgave reelt? Sammenlign overslag med registrerede timer for at finde de dele, du overså.
3. Hvor blev ugen af? Hold funktioner, fejlfinding, gennemgang, møder og nødvendige afstikkere adskilt i loggen. En mødesum giver noget konkret at tale om, når prioriteter konkurrerer. Medregn forberedelse, hvis du vil se den fulde tid, møderne krævede.
4. Hvad fakturerer jeg? Fakturerer du kunder direkte, kræver loggen timer med noter, en kunde kan genkende.

Før en enkel log til dig selv: hvad du arbejdede på, for hvem og hvor længe.

Brug manuel tidsregistrering med nogle få tilpasninger til udviklerarbejdet.

Den mindste nyttige post for en udvikler

Hold hver post lille nok til, at du faktisk skriver den:

»PROJ-142: rettede race condition ved betaling« giver stadig mening ved samtalen eller faktureringen. »Kodning« gør ikke.

Kan posten nå en kunde eller leder, så beskriv resultatet med deres ord: hvad der blev rettet, leveret eller gennemgået. Kampen med webpack bliver i en privat note.

Du behøver ikke et opgavetræ, der spejler sagsstyringen.

Saml projekt- eller kundearbejde, og markér fejlfinding, gennemgang eller møder for at sammenligne timerne på tværs af projekter.

På en almindelig dag er en note alene nok.

En dag, der stadig giver mening næste måned

Her er en tænkt dag:

Den sidste række er et skøn ud fra udviklerens noter og kalender. En senere commit hjælper med at identificere opgaven, men fastslår ikke sessionens varighed.

Registrer sessioner, ikke editoraktivitet

En IDE-aktivitetslog efterlader to huller at overveje i din personlige registrering.

For det første er en åben editor ikke bevis på arbejde, og en lukket er ikke bevis på hvile. At læse biblioteksdokumentation, skitsere en datamodel på papir og kigge i loftet, indtil fejlens årsag går op for dig, er alt sammen en del af opgaven. Et værktøj begrænset til editoraktivitet kan overse det arbejde.

For det andet kan projektet eller formålet mangle. Et repositorynavn eller en vinduestitel kan identificere projektet. En delt dokumentationsside fortæller ikke nødvendigvis, hvilken kunde der havde brug for undersøgelsen.

Mangler betegnelserne, skal du fortolke aktivitetsloggen bagefter. Her kræver automatisk tidsregistrering din vurdering.

En aktivitetslog i baggrunden kan være et sikkerhedsnet, du sorterer senere. Brug den til at udfylde huller i sessionsloggen.

Brug arbejdssessionen som enhed. Start et stopur, når du sætter dig til en opgave. Stop, når du skifter opgave, møde eller kunde, og hold pause ved pauser. En kort note ved de grænser giver sammenhæng til gennemgangen senere.

Loggen besvarer dine spørgsmål. Du kan holde den adskilt fra den overvågning, din arbejdsgiver bruger. Hold noterne inden for det, din arbejdsgiver eller kunde tillader dig at skrive ned uden for deres systemer.

Genskab en glemt session, mens den er frisk

En commit eller pull request kan minde dig om arbejdet. Kalenderen og beskeder kan udfylde resten.

Brug de spor til at anslå en glemt session, og markér den som et skøn. To commits med en times mellemrum beviser ikke en times arbejde. Du kan have holdt pause eller skiftet opgave imellem dem.

Research og fejlfinding kan ske uden nogen commit. Medtag det arbejde, når du husker det, frem for at behandle kodeændringer som hele opgaven.

Kan du ikke genskabe et brugbart skøn, så lad varigheden stå som ukendt. Registrer næste session under arbejdet.

Brug timerne til at gennemgå dine overslag

Registrerer du opgavens fulde tid, viser loggen, hvordan den passer til overslaget.

Skriv overslaget på sagen, registrer opgaven, og sammenlign derefter. Se efter to ting på tværs af sammenlignelige opgaver:

• Plads til overset arbejde. Kræver lignende rettelser gentagne gange gennemgang og test ud over overslaget, så medregn de trin næste gang. Giv ukendt arbejde mere usikkerhed.
• Hvor overskridelsen ligger. Sammenlign tid til kodning, fejlfinding, integration, opsætning af miljø og gennemgang. Viser loggen et mønster, så anslå de dele separat.

Det virker også ved fastprisarbejde. Når opgaven er færdig, dividerer du honoraret med alle timerne for at se omsætning pr. time før udgifter. Brug timerne til at planlægge lignende arbejde. Du kunne holde næste honorar op mod dine udgifter og indtægtsmål frem for at gentage den pris.

Registrer fejlfinding og omarbejde på kundeprojekter

Spring afsnittet over, hvis du ikke arbejder for kunder. Fejlfinding og omarbejde kan forsvinde i en uklar udviklingspost.

Fejlfinding. Registrer sessionen, og beskriv resultatet: »Fandt og rettede dobbelt webhook i betalingsforløbet« er en linje, kunden kan forstå.

Hold test, fejlfinding og omarbejde som separate poster, når det hjælper gennemgangen. Loggen kan omfatte tid, du ikke fakturerer.

Markér omarbejde tydeligt, så du kan gennemgå timerne. Opdelingen i fakturerbare og ikke-fakturerbare timer kan hjælpe med at organisere loggen.

Afstikkere. En afhængighedskonflikt kan bruge fire timer trods en kort opgavebeskrivelse. Registrer den reelle varighed, og beskriv forhindringen.

Bruger fakturaen et lavere tal, så behold de fire timer i din egen log. Ændrer du kilderegistreringen til »måske to«, mister du information.

Hold også arbejde uden kunde synligt. Tilbud, fakturering og læring af et framework, ingen kunde bad om, kommer fra samme uge, du fakturerer fra. Udelader du dem, undervurderer du, hvor meget af ugen virksomheden kræver.

Hvor TimeRetain passer ind

En udviklers tidslog rummer systemerne, du arbejder med, sene aftener, den reelle mødebyrde og, hvis du fakturerer, kundenavne og priser. Du behøver ikke uploade loggen for at føre den.

TimeRetain er et manuelt stopur til den registrering på din enhed. Du kan se tiden til gennemgang, møder eller fejlfinding og resultatet af hver session. Intet overvåger din IDE.

Fakturerer du, så brug noterne til at forklare det leverede arbejde. Behold ikke-faktureret omarbejde i din egen log, så du kan se, hvad projektet reelt krævede.

Den primære registrering bliver på din enhed. Slår du synkronisering til, gemmer TimeRetain en krypteret kopi på sine servere.

Begynd med én uge

Byg ikke et system. Registrer i én uge kun reelle arbejdssessioner: projekt eller kunde, start, stop og en note på én linje med sagsnummeret. Brug git og noter til at anslå glemte sessioner, mens dagen er frisk. Behold huller, du ikke kan underbygge.

Læs det derefter igen. Sammenhold mødesummen med oplevelsen af ugen. Sammenlign en eller to opgaver med deres overslag. Hjælper loggen med gennemgang eller fakturering, og står udbyttet mål med besværet, så fortsæt.