Det er en fin balanse mellom å gjøre det riktig og å levere.
Jeg leder et team på 8 utviklere. Hver time teamet er blokkert er åtte tapte utviklingstimer.
En kollega fikk i oppgave å skaffe meg en database. Etter to dagers venting spurte jeg om status. Han sa at vi hadde problemer med dataimport. Da han skrev ut dataene, var det nesten en gigabyte. En gigabyte var litt mye å sjekke inn i Subversion. Han lette etter en alternativ metode.
En dag til går. Jeg spør ham hvordan det går. Han sier det er nesten ferdig. Ok, bra, jeg er tre dager bak, 192 tapte utviklingstimer. Jeg brenner av iver etter å komme i gang. Teamet mitt mister timer.
På den fjerde dagen er han klar. Endelig! Han sender meg databaseprosjektet og importskriptene for databasen. Han bruker PowerShell og BCP til å importere dataene. Jeg sender dem til teamet med detaljerte instruksjoner.
Teamet er 12 timer foran meg, i India. Tilbakemeldingssløyfen er 12 timer. Det tar 24 timer å komme i gang med noe som helst.
Som Murphys lov sier: “Alt som kan gå galt, vil gå galt”. Teamet kjørte dataimportskriptene og møtte feil. PowerShell-skriptene mislyktes, et sikkerhetsproblem forhindret dataimport.
Jeg er fem dager bak. 320 timer er tapt. Fristen nærmer seg, vi må komme i gang.
På dette punktet må jeg få databasen opp og kjørende for teamet. På maskinen min løsner jeg databasen, zipper den og sender den til teamet. Hver utvikler vet hvordan man gjenkobler en database. Innen en time etter å ha fått databasen har alle åtte utviklere en fungerende database. Suksess!
Å lage en clever prosess er bra, men noen ganger er det viktigere å bare få jobben gjort enn å være clever.
Forfatter: Chuck Conway er en AI-ingeniør med nesten 30 års erfaring innen programvareutvikling. Han bygger praktiske AI-systemer—innholdspipelines, infrastrukturagenter og verktøy som løser virkelige problemer—og deler det han lærer underveis. Koble til ham på sosiale medier: X (@chuckconway) eller besøk ham på YouTube og på SubStack.