Entwickler lieben es, Aufwände zu schätzen

28.1.2016

Leider ist die Welt nicht, wie sie uns gefällt. Leider gibt es nicht überall Wohlstand, Gesundheit und Frieden. Und leider erwarten Kunden eine Kostenschätzung, bevor sie einen Auftrag erteilen. Moderne Ansätze der Projektabwicklung haben gezeigt, dass man die Kosten drücken, die Termine besser halten und alle Seiten zufriedener machen könnte, wenn man darauf verzichten würde, Gesamtpreise und Abgabetermine für ein Projekt vorab zu verlangen.


Es wäre viel besser, wenn sich Kunden und Entwickler in enger Abstimmung von einem Prototyp zum nächsten Release-Candidate vorarbeiten würden. Die Kunden könnten neue Wünsche äußern oder nicht benötigte Features entfernen lassen. Denn erst bei der Arbeit mit dem Produkt, stellt sich oft heraus, was man wirklich will. Die Entwickler würden positives Feedback erhalten, sie würden Termine schaffen und ihr Stresslevel senken. Das wäre ein Gewinn für alle Seiten und das ist auch die Erklärung für die Popularität dieser sogenannten agilen Vorgehensweise bei Projektarbeitern.
 

Doch der Haken an der Sache bleibt: Es gibt vorab keine Schätzung für den Kunden. Und damit kein Preis, kein Auftrag. Auch wenn die Erfahrung in vielen vergangenen Projekten zeigt, dass der Kunde sogar Geld einspart und zufriedener ist, einen Blanko-Scheck gibt es nicht.
 

Also fügen wir uns in das Schicksal und geben möglichst pessimistische Schätzungen ab. Aber Entwicklungsarbeit ist kein Fliessbandjob. Nach längerer Wartezeit erhält der Kunde ein Produkt mit dem er sich nicht identifiziert, denn er hat nicht an der Entwicklung teilgenommen. Und dazu kommt dann meist noch, dass trotzdem auch die pessimistische Schätzung nicht eingehalten werden kann. Warum ist das so?
 

Es gibt die plausible Vermutung dafür, dass Software-Entwicklung von ihrer Arbeitscharakteristik mit Forschung vergleichbar ist. In der Regel hat man es mit neuen Problemen zu tun, deren Lösung man schwer abschätzen kann. Lesen Sie dazu mehr bei Scott Rosenberg "We don't need no stinking estimates." (englischer Blog).
 

Können wir also den Kollegen in Vertrieb und Controlling zu Recht eine Schätzung unserer zukünftigen Arbeit verweigern? Niemand wird schliesslich eine Wissenschaftlerin fragen, wann und mit welchen Kosten sie ein bestimmtes Problem gelöst haben wird.
 

Wir können die Schätzung nicht verweigern. Denn in der Praxis kann sich kaum jemand den wirtschaftlichen Gegebenheiten widersetzen. Eine Vertrauensbeziehung aufzubauen, die Aufträge ohne Kosten- und Terminvorgabe erlaubt, dauert sehr sehr lange und kann nicht immer mit jedem Kunden erreicht werden.
 

Was sollen wir also tun?
 

Es gibt einige Vorschläge dazu, das agile Vorgehen und die detaillierte Schätzung auf einem Mittelweg zu vereinen. Dazu versucht man mit geringen Mitteln und etwas finanziellem Risiko einen Prototypen zu schaffen, mit dem man einerseits die Anforderungen des Kunden genauer fassen kann, andererseits bereits ein Gefühl für den eigenen Aufwand gewinnt.
 

Aber letztendlich führt wohl doch nichts daran vorbei, dass wir uns der Aufgabe der Schätzung stellen. Wir unterteilen das Projekt in kleinere, überschaubare Pakete, deren Aufwände wir zu kennen glauben. Wir werden uns oft verschätzen, Termine unter- oder überschreiten und letztlich Erfahrung gewinnen. Es hilft nichts, Angst vor dieser Aufgabe zu haben, sie ist wie ein nicht endender Kampf, der uns schwächt und stärkt zu gleich.
 

Bis irgendwann jemand die perfekte Lösung für unser Problem findet.
 

* * *
 

Das Video zeigt, wie ein Projekt in Aufgaben geteilt wird, mit Schätzungen versehen und dann mit einer Ressourcenplanung in die Zukunft projiziert wird. Wenn da Tool das schnelle Vorwärtsrechnen mit Parallelprojekten und Urlaubszeiten erlaubt, kann man öfter an den Parametern „drehen“ um den Plan der Realität anzupassen.

 

 

 

 

Please reload

Empfohlene Einträge

Entwickler lieben es, Aufwände zu schätzen

January 28, 2016

1/5
Please reload

Aktuelle Einträge

December 21, 2015

Please reload

Archiv
Please reload

Schlagwörter
Please reload

Weitersagen...
  • Facebook Basic Square
  • Twitter Basic Square
  • Google+ Basic Square