Tekniker Och Deras Tidsplanering

Jag har en bok hemma som jag fick av utvecklingschefen på mitt förra jobb, jag har visserligen glömt titeln men det var något i stil med "time management for sysadmins". Det var en väldigt bra bok, och en av poängerna han gjorde var att förklara problemet i att vi säger "det är två dagars arbete - jag kan ha det gjort om två veckor". Det gäller för utecklare med.

Så här ser verkligheten ut: Man har ett planeringsmöte, det är ett riktigt bra planeringsmöte med tidsskattning och prioritering och det mynnar ut i en fin lista med planerade leveranser på planerade tidspunkter. Utvecklaren är nöjd och känner att "vecka X blir tuff men det här kommer vi fixa". Sedan kliver vekligheten in: sälj måste ha just det företagest annons skapad och publicerad precis nu för det har de lovat. Den ambitiösa nya medarbetaren har hitta ett antal irriterande, men ganska snabbfixade buggar, chefen har ett bra förslag att diskutera och servern äter upp alla inodes i en av cachemapparna. I teorin skall svaret på alla dessa frågor vara "återkom om två månader", men hur ska den som frågar, och har ett i deras yrkesroll akut problem, förstå varför det inte går att skjuta in en "så snabb fix" i planeringen? Och hur skall man förklara att en snabb fix betyder 5 minuter för att lokalisera var i kodträdet fixen skall in, 10 minuter för att fundera över oönskade konsekvenser av fixen, 10 minuter för att kolla så att ingen av de där läskiga sakerna hände, 5 minuter för att driftsätta och peta in i svn och 5 minuter för att faktiskt göra fixen. Dvs att det åtgår 35 minuter för den där feminutersfixen?

Så vad väljer du? Backlogg i planeringen eller besvikna och oförstående medarbetare, som känner att du inte bryr dig om deras problem? Lägg sedan till att det är trevligt att ibland vara social med sina kolleger....