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 dager med venting spurte jeg om status. Han sa vi hadde problemer med dataimport. Da han scriptet ut dataene var det nesten en gigabyte. En gigabyte var litt mye å sjekke inn i subversion. Han lette etter en alternativ metode.
Enda en dag går. Jeg spurte ham hvordan det gikk. Han sier det er nesten ferdig. Ok kult, jeg er tre dager bak, 192 timer med tapt utviklingstid. Jeg brenner etter å komme i gang. Teamet mitt blør timer.
På den fjerde dagen er han klar. Endelig! Han sender meg databaseprosjektet og import-databasescriptene. Han bruker PowerShell og BCP til å importere dataene. Jeg sender dem videre til teamet med detaljerte instruksjoner.
Teamet er 12 timer foran meg, i India. Tilbakemeldingsløkka er 12 timer. Det tar 24 timer å få noe som helst i gang.
Som Murphys lov sier: “Alt som kan gå galt, vil gå galt”. Teamet kjørte dataimport-scriptene og møtte fiasko. Powershell-scriptene feilet, et sikkerhetsproblem forhindret import av data.
Jeg er fem dager bak. 320 timer har gått tapt. Fristen nærmer seg, vi må komme i gang.
På dette punktet må jeg få databasen opp og kjøre for teamet. På maskinen min kobler jeg fra databasen, zipper den og sender den til teamet. Alle utviklere vet hvordan man kobler til en database igjen. Innen en time etter å ha fått databasen har alle åtte utviklerne en fungerende database. Suksess!
Å lage en smart prosess er bra, men noen ganger er det viktigere å bare få jobben gjort enn å være smart.
Forfatter: Chuck Conway spesialiserer seg på programvareutvikling og Generativ AI. Koble til ham på sosiale medier: X (@chuckconway) eller besøk ham på YouTube.