Warum die besten Entwickler oft die schlechtesten Schätzer sind

Ich war relativ schnell nach meinem Studienabschluss in der Situation, große Softwareprojekte mit hunderten oder sogar tausenden Entwicklungsstunden nicht nur umzusetzen, sondern auch zu schätzen. Seit meinem 18. Lebensjahr war ich stets parallel zu Studium und Ausbildung in die Entwicklung von Softwareprojekten eingebunden. Einige davon liefen sogar produktiv im 24/7-Betrieb in Anlagenparks. Dennoch handelte es sich dabei meist um kleinere Projekte mit überschaubarem Umfang. Nach meinem Information and Computer Science Studium hatte ich zwar das theoretische Rüstzeug, um auch komplexe Funktionalitäten zu entwickeln. Doch für präzise Schätzungen half mir das kaum. Im Gegenteil: Heute bin ich überzeugt, dass zu viel theoretisches Informatikwissen die Schätzungen sogar verschlechtern kann.

Dementsprechend haben wir in unserem zweiten größeren Projekt fast doppelt so viele Stunden investiert wie ursprünglich geplant – eine derartig fehlerhafte Einschätzung, die uns damals viel Zeit und Nerven gekostet hat. Aufgrund meines mechatronischem Backgrounds bin ich sicherlich nicht der allerbeste Softwareentwickler. Jedoch passiert genau das gleiche, oder noch viel schlimmer auch extrem guten Informatikern. Ich erinnere mich noch genau an eine Situation während einer Industrie 4.0-Schulung. Während der Schulung wurde erwähnt, dass Firma XY an einer Industrie 4.0-App arbeitet, die Anlagenstillstände automatisch erfasst und kritische Meldungen per SMS an Bereitschaftstechniker in der Nachtschicht oder am Wochenende weiterleitet. Neben mir saß ein äußerst talentierter Entwickler, der voller Überzeugung meinte, eine solche App sei in maximal einer Woche entwickelt und robust für den Einsatz in der Produktion. An dieser Einschätzung hielt er unbeirrt fest – was bei den erfahrenen Industrieprofis im Raum zu überraschten Blicken und einer spürbaren Skepsis führte.

Ersatzheuristik

Heute weiß ich, dass viele hier der Ersatzheuristik zum Opfer werden. Menschen ersetzen eine komplexe Frage gerne mit einer einfachen. Ein Beispiel: Statt die Frage „Ist diese Person kompetent?“ genau zu analysieren, könnten wir intuitiv eine Antwort finden, indem wir die Frage durch „Macht diese Person einen sympathischen oder vertrauenswürdigen Eindruck?“ ersetzen. Kahneman beschreibt dies ausführlich in seinem Buch Schnelles Denken, langsames Denken. Meiner Meinung nach eines der besten Bücher überhaupt und ich empfehle jedem, es zu lesen.

Für eine realistische Zeiteinschätzung der besagten Industrie 4.0-App hätte man zahlreiche Fragen beantworten müssen:

• Mit wie vielen verschiedenen Steuerungen und Datenprotokollen muss die App kommunizieren?
• Gibt es datenschutzrechtliche Hürden?
• Wie werden kritische von nichtkritischen Meldungen unterschieden und priorisiert?
• Wie sind die Maschinen im Anlagenpark angebunden, und welche Server dürfen mit ihnen kommunizieren?
• Gibt es eine Datenbankschnittstelle, um abzufragen, welche Techniker aktuell Bereitschaft haben?
• Wie sieht das User-Interface für die Anbindung aus?
• Und vieles mehr…

Die eigentliche Frage wurde jedoch wahrscheinlich durch eine viel einfachere ersetzt:
„Wie lange brauche ich für einen Prototyp, der im einfachsten Standardfall funktioniert und eine SMS an mein Handy sendet?“

Das Beispiel aus der Schulung war sicher ein Extremfall, aber es zeigt ein verbreitetes Problem: Die Prototyp-vs.-Produkt-Ersatzheuristik ist einer der häufigsten Gründe, warum Zeitschätzungen um Faktoren danebenliegen.

Ein Prototyp funktioniert oft unter Idealbedingungen: mit simplen Schnittstellen, ohne Sicherheitsaspekte und ohne Berücksichtigung der realen Systemkomplexität. Ein marktreifes Produkt hingegen muss in einem vielschichtigen Umfeld bestehen – und genau diese Diskrepanz wird in der Schätzung oft nicht bedacht. Das Ergebnis sind Projekte, die nicht nur ein paar Stunden, sondern oft das Zigfache der ursprünglich geplanten Zeit benötigen.

Junges Team, schlechte Schätzung

Wer sehr jung etwas gründet, hat oftmals auch kleine, junge Teams. Dementsprechend gibt es oft niemanden im Team mit der Projekterfahrung, die notwendig wäre, um gute Schätzungen abzuliefern. Fehleinschätzungen können jedoch schnell zum Scheitern der gesamten Firma führen. Bevor ich zu Lösungsansätzen komme, möchte ich noch ein weiteres Beispiel nennen, das eindeutig aufzeigt, wie derartig falsche Schätzwerte von jungen Entwicklern sein können.

Für ein Projekt planten wir ursprünglich etwa 800 Stunden. Im Zuge dieses Projekts ergab sich dann die Gelegenheit, einen kleinen Teil davon – die Entwicklung einer umfangreicheren Motionsteuerung – in eine berufsbegleitende Bachelorarbeit zu integrieren. Für die Umsetzung mussten wir der Studierenden moderne Softwareentwicklung, Unit Testing und generell die Grundlagen von Motion-Applikationen beibringen.

Ein erfahrener Entwickler aus unserem Team hätte für die vollständige Entwicklung der Motionsteuerung, inklusive aller Tests und Optimierungen, wahrscheinlich etwa 200 Stunden benötigt. Da es sich aber um die erstmalige Umsetzung durch eine unerfahrene Bachelor-Studentin handelte, schätzten wir den Aufwand auf 800 bis 1000 Stunden. Die Studentin selbst war jedoch überzeugt, dass sie nicht nur die Motionsteuerung, sondern die gesamte Anlage – inklusive weiterer Dutzender Geräte und Hardware, HMI, Fehlermeldungen, Datenschnittstellen und Unit Tests – in wenigen hundert Stunden bewältigen könnte. Eine krasse Fehleinschätzung. Die Kernaufgabe der Bachelorarbeit war am Ende des Tages nach hunderten Stunden zwar erfüllt, musste jedoch erheblich erweitert werden, um tatsächlich produktiv eingesetzt werden zu können. Für die vollständige Gesamtumsetzung der gesamten Anlage wären vermutlich Jahre nötig gewesen. Und das ist für ein erstes Projekt auch völlig normal – nur hat man in der Praxis eben selten diesen Luxus an Zeit.

Diese Art von Fehl- und Überschätzung tritt besonders häufig bei Personen auf, die in kurzer Zeit viel dazugelernt haben. Auch in diesem Fall wurde neben der praktischen Arbeit fleißig berufsbegleitend weitergelernt. Leider führt genau das oft zu einer massiven Selbstüberschätzung. Man hat das Gefühl, komplexe Projekte könnten problemlos nebenbei in wenigen Stunden abgeschlossen werden. Dabei wird jedoch übersehen, dass die Aufgabenstellung in Lehr- oder Übungsprojekten meist klar, eindeutig und stark begrenzt ist. Die Ersatzheuristik „Welche Projekte habe ich im letzten Jahr zusätzlich geschafft?“ führt oft zu massiven Fehleinschätzungen. Man übersieht dabei, wie viele Side-Quests reale Projekte enthalten: unklare Anforderungen, Feedbackschleifen, technische Hürden oder unerwartete Probleme. Zudem hat man in der Praxis nicht immer das passende Lehrbuch oder die perfekte Schritt-für-Schritt-Anleitung direkt neben sich liegen.

Wie kommt man zu besseren Schätzungen

Gute Zeitschätzungen abzugeben, ist eine Kunst und gleichzeitig eine Wissenschaft für sich. Für Unternehmen ist es jedoch essenziell, diese Fähigkeit zu meistern, denn falsche Schätzungen können nicht nur Projekte, sondern ganze Firmen gefährden.

In den kommenden Blogposts werde ich detailliert auf die häufigsten Fallstricke und konkrete Ansätze für bessere Schätzungen eingehen. Da eine umfassende Analyse hier den Rahmen sprengen würde, gibt es zum Abschluss schon einmal einige Quick-Tipps, die als erste Denkanstöße dienen sollen.

Zu allererst zwei Buchtipps:

Schnelles Denken, langsames Denken (Thinking, Fast and Slow) von Daniel Kahneman

Mein Lieblingsbuch schlechthin. Hat meine Ansicht auf viele Dinge stark verändert und hilft mir in allen erdenklichen Situationen. Es ist erstaunlich, wie schlecht wir Menschen bei Schätzungen sind und noch viel mehr, welche Belanglosigkeiten uns dabei beeinflussen können. Kleines Beispiel:

Die Studienteilnehmer wurden gebeten, die Höhe des höchsten Küstenmammutbaums zu schätzen, jedoch mit einem besonderen Twist. Zwei verschiedenen Gruppen wurden unterschiedliche „Anker“ gegeben, um ihre Wahrnehmung zu beeinflussen:

1. Die erste Gruppe wurde gefragt, ob der höchste Küstenmammutbaum höher oder niedriger als 366 Meter ist, bevor sie ihre Schätzung abgab.
2. Die zweite Gruppe erhielt die gleiche Frage, jedoch mit einem deutlich niedrigeren Anker von 55 Metern.

Die Ergebnisse waren bemerkenswert: Die Gruppe mit dem hohen Anker (366 m) schätzte die durchschnittliche Höhe auf 257 Meter, während die Gruppe mit dem niedrigen Anker (55 m) nur 86 Meter schätzte. Dieser Unterschied von beeindruckenden 171 Metern zeigt deutlich, wie stark anfängliche Informationen unsere Urteile beeinflussen können.

Noise Olivier Sibony, Daniel Kahneman und Cass Sunstein

Quasi die Fortsetzung von Schnelles Denken, langsames Denken, ebenfalls von Daniel Kahneman. Dieses Buch geht jedoch gezielt darauf ein, wie man Fehleinschätzungen minimieren und systematische Verzerrungen erkennen kann – nicht nur auf individueller Ebene, sondern auch im Unternehmenskontext. Meiner Meinung nach ein absolutes Must-Read für jeden, der Projektverantwortung trägt.

Daten für Basisschätzung

Noch wichtiger als das theoretische Wissen, das man aus diesen beiden Büchern mitnehmen kann, ist der Aufbau eines soliden Datenfundaments. Dafür benötigt man die richtigen Tools, um Projektstunden präzise zu buchen und zu tracken. Sobald ausreichend Daten vorhanden sind, lassen sich zukünftige Projekte realistischer einschätzen, indem man sie mit bereits abgeschlossenen Projekten vergleicht – Projekten, bei denen man genau weiß, wie viele Stunden tatsächlich für die Umsetzung benötigt wurden.

Bei der AutoLab haben wir neben JIRA auch Tempo eingeführt und erfassen jede einzelne Minute entweder projektspezifisch oder allgemein. Durch die historischen Daten wird es erheblich einfacher, zukünftige Schätzungen präzise zu erstellen. Darüber hinaus erhält man ein genaues Bild darüber, wie viel Prozent des Geschäfts durch sogenannten „Overhead“ gebunden werden.

Mehr dazu werde ich in einem weiteren Artikel erläutern. Für den Moment kann ich jedoch nur jedem dringend empfehlen, eine derart detailgetreue Zeiterfassung einzuführen. Sie verhindert Blindflug und setzt rein subjektiven Schätzungen klare Grenzen.