Die 10 Todsünden der Aufwandsschätzung für Entwickler

Hartmut Schlosser

© shutterstock.com/trendywest

Als Dauerbrenner scheint sich derzeit das Thema zu etablieren, dass Software-Entwickler Schwierigkeiten haben, den zeitlichen Aufwand für eine bestimmte Aufgabe richtig einzuschätzen. Aus den anfänglichen „Dafür brauche ich höchstens ein paar Stunden“ werden schnell einmal Tage, wenn nicht Wochen. Der zugespitzte Beitrag „Programmierer sind nicht faul – sie sind nur die schlechtesten Schätzer der Welt“ hat einige interessante Kommentare dazu hervorgebracht.

Sind Entwickler schlechte Schätzer?

Sicherlich kommen bei falschen Aufwandsschätzungen sowohl unternehmenspolitische wie menschliche als auch psychologische Gründe zum Tragen. Kommentator Tom bringt vor allem die unternehmerische Konfliktsituation ins Spiel, dass die Firmenleitung oft Unmögliches von den Entwicklern fordert und die „realistischen“ Aufwandsschätzungen erst gar nicht akzeptiert.

Er schildert die folgende Situation aus seinem Alltag:

Aus der ersten Entwickler-Aufwandsschätzung von 40 Manntagen für den technischen Teil kommuniziert das Management 40 Zeittage für das Gesamtprojekt an den Kunden. Der Kunde selbst hat dann meist nur eine vage Vorstellung von seinen Wünschen, interessiert sich kaum für technische Qualität sondern für GUI-Details und erweitert das Projekt durch die Hintertür, denn er erinnert sich plötzlich daran, „dass Feature X und Feature Y, die nie Teil des Pflichtenhefts waren, ja irgendwie ’selbstverständlich‘ zum Projekt gehören.“

Die Krux:

Aus politischen Gründen ist es GEWOLLT, dass wir zu knapp projektieren. Weil es besser ist, sich hinterher zu entschuldigen und mehr Geld zu verlangen, als zuvor gar nicht erst den Auftrag zu bekommen. Tom

Die von Tom geschilderte Situation trifft sicherlich vor allem bei der Durchführung externer Kundenprojekte zu. Doch auch bei internen Projekten liegen viele Entwickler oft schwer daneben mit ihren Schätzungen. Kommentatorin Carmen erzählt aus ihrem Unternehmensalltag, dass dort bei internen Projekten auch zu lange Zeiträume für ein Projekt angegeben werden.

Toms Meinung stimme ich zum größten Teil zu. Die gängige Politik, lieber zu kurz zu schätzen, um niemanden abzuschrecken, ist mit Sicherheit ein wichtiger Faktor, warum Entwickler so oft falsche Angaben machen. Da ich das Glück habe, keine externen Kunden zu betreuen, kommt bei uns sogar manchmal ein zu lang geschätzter Zeitraum vor.

Wenn aber die Kunden mit den Wünschen erst rausrücken, wenn die Oberfläche schon steht, dann ist so etwas natürlich unmöglich. Carmen

Theorie der Selbstüberschätzung

Psychologischer geht der Beitrag „Warum Entwickler hoffnungslose Optimisten sind“ ans Werk und liefert einige Argumente aus der Theorie der Selbstüberschätzung: Typische Verhaltensmuster wie Selbstüberzeugung (Menschen tendieren dazu, das eigene Wissen zu überschätzen), die Illusion der Kontrolle (Menschen handeln oft so, als hätten sie über etwas Kontrolle), Wunschdenken (Wahrscheinlichkeit eines Ereignisses wird überschätzt, weil man es sich besonders stark wünscht) und Fehlplanung (Besonders bei schwierigen Aufgaben tendieren Menschen dazu, die benötigte Zeit zu unterschätzen) treffen womöglich gerade in der IT auf fruchtbaren Boden:

Entwickler haben es üblicherweise mit einem Wissensgebiet zu tun, das sie kaum voll überblicken, zudem sind die zu lösenden Aufgaben typischerweise komplex. Entwickler haben Vertrauen in die Technik, die sie „einigermaßen“ zu beherrschen glauben, und wünschen sich, ein Problem tatsächlich schnell bewältigen zu können.

Als Lösung bietet sich an, Aufwandsschätzungen regelmäßig zu üben und sie in einem agilen Kontext zur Routine zu machen. Dazu gehört es auch, retrospektiv zu hinterfragen, warum die zurückliegenden Schätzungen daneben gelegen haben. Alle unternehmenspolitischen Hindernisse für korrekte Schätzungen lassen sich so wohl nicht aus dem Weg räumen. Verbessern könnte sich die Situation aber dann, wenn das Management sich an diesen agilen Meetings beteiligt.

Einen Tipp haben wir im Netz noch in Form eines Webinarmitschnitts gefunden: Im Video „10 Deadly Sins of Software Estimation“ zitiert Steven McConnell 10 Punkte aus seinem Buch „Software Estimation – Demystifying the Black Art„, die beschreiben, wie man es garantiert nicht machen sollte!

Aufmacherbild: Temptation – Eden garden von Shutterstock / Urheberrecht: trendywest

Verwandte Themen:

Geschrieben von
Hartmut Schlosser
Hartmut Schlosser
Content-Stratege, IT-Redakteur, Storyteller – als Online-Teamlead bei S&S Media ist Hartmut Schlosser immer auf der Suche nach der Geschichte hinter der News. SEO und KPIs isst er zum Frühstück. Satt machen ihn kreative Aktionen, die den Leser bewegen. @hschlosser
Kommentare
  1. Der Baron2017-09-28 11:48:29

    Es ist doch so, die meisten PM's haben doch gar nicht die Eier in der Hose um dem Kunden von vornherein zu sagen "Du bekommst ne fette GUI, Best Practice Backeend und Frontend, zahlst bei uns 30% mehr als bei X, denn X wird dir später 70% mehr aus der Tasche leiern". Es gehört nun mal zum Geschäft in der IT solch einen Scheiss zu treiben. Bei Tagessätzen um 800-1300 EUR ist es alles kalkuliert. Mittendrin wechselt der PM, der Junior macht Architektur, am Schluss hat man ein weiteres Jahr überstanden und ein andere Dienstleister übernimmt den Schwachsinn des Vorherigen. Ich liebe diese Branche.

  2. Aufwandsschätzung in der Softwareentwicklung: Worauf man achten sollte2018-02-13 08:12:39

    […] auch ein paar interessante Beiträge: Ein paar Tipps für Entwickler im Bereich Aufwandsschätzung Warum sich Softwareentwicklung nicht bestimmen […]

  3. Sascha Thattil2018-02-13 09:19:07

    Spannende Analys unterschiedlicher Artikel.

    Viele der Aussagen treffen es auf den Punkt.

    Man kann eben einem Nicht-IT'ler oftmals schwer erklären, warum denn jetzt eine bestimmte, einfach aussehende Funktionalität, denn jetzt mehrere Mannmonate braucht.

    Es ist dann oftmals einfacher im Projekt selbst eine genauere Abschätzung vorzunehmen, in welcher die genauen Gründe dafür nahegelegt werden. Das führt zwar dann zu etwas Frust, aber zumindest geht das Projekt weiter (dass heisst nicht, dass ich das befürworte. Die Realität sieht derzeit immer noch so aus).

    Ich denke, es muss im Generellen ein Verständnis dafür entstehen, dass Softwareentwicklung nun mal relativ komplex ist und man gar nicht so einfach eine Einschätzung abgeben kann (Stichwort: Agiler Ansatz). Oder aber: Es bräuchte eine tiefergehende Analysephase in welcher der Kunde und der Dienstleister gemeinsam (Projektleiter, Programmierer, IT Leiter, Enduser, etc.) zusammen die Anforderungen bestimmen. Das kann jedoch einige Tage dauern und muss auch vergütet werden (wer ist jedoch vor einem Projekt dazu bereit?)

    Hier auch ein paar generelle Herausforderungen bei Aufwandsschätzungen: http://www.yuhiro.de/aufwandsschaetzung-in-der-softwareentwicklung-worauf-man-achten-sollte/

    Danke nochmal für Eure tolle Zusammenfassung/ Übersicht. Sehr hilfreich.

    Viele Grüsse
    Sascha Thattil

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.