(Zeit-)Schätzen Sie mal!

Es gibt kaum eine unsinnigere Frage als die nach Zeitschätzungen bei Software-Projekten. Doch in der wirren Hoffnung Kontrolle in chaotische Prozesse zu bringen wird sie gestellt, meist von Leuten mit Titeln wie “Projektmanager”.

Das dumme an der Idee: um zu wissen wie lange ich für die Lösung von Problemen brauchen werde, müsste ich die Lösung der Probleme kennen. Besser noch: zum Zeitpunkt an dem die Frage gestellt wird, kenne ich nicht mal die Probleme.

Aber zum Glück gibt’s ja viele Methoden und Vorgehensweisen um Zeitschätzungen genauer und “einfacher” zu gestalten. Am Ende kommt da sogar was mit Standardabweichung und so raus, so richtig mit Formeln und anderen Dingen die die Sache möglichst wissenschaftlich und belastbar aussehen lassen.

Meiner Meinung nach bleibt das Ganze aber natürlich trotzdem nur wildes Gerate. Man bekommt mehr Kommastellen wenn man mehrmals rät und den Durchschnitt berechnet, aber mehr Fakten erhält man nicht. Klar gibt es durchaus bei jedem Projekt große Teile die aus reiner Arbeit bestehen und bei denen ich Erfahrungswerte angeben kann. Auch kann ich natürlich sagen dass völlig andere Probleme, bei einem völlig anderem Projekt irgendwie Zeit X zur Lösung erfordert haben, also sollten die aktuellen X±Y benötigen.

Also weiterhin keine Fakten und nur Zeugs das mit dem nächsten, kniffligeren Problem umfällt.

So sagt das natürlich kaum jemand. Immerhin sagt die Erfahrung doch dass die meisten Zeitschätzungen “so ungefähr” passen. Ob sie genauer passen als wenn ich würfeln würde und irgendeine grobe Zahl Wochen nennen würde… die Frage bleibt wohl offen.

Vlt. sogar (und hier werden mir die ganzen Leute deren Job sowas ist, natürlich energisch widersprechen) verbrennt man mit diesem Blödsinn sogar mehr Zeit als man jemals Nutzen daraus ziehen könnte. Aber das wäre eine These die fast genauso unbelegt ist wie das Gegenteil.