Follow my new blog

Mittwoch, 8. Dezember 2010

Widerspruch gegen das Schätzen

Mir wird das Schätzen immer suspekter. Warum tun selbst agile Entwickler das? Mal ehrlich? Auf der einen Seite wissen wir – und ich meine wirklich “wissen” –, dass es unmöglich ist, den Aufwand von Softwareentwicklung zu schätzen. Denn da wo etwas Neu ist, seien es Tools, Techniken, Teammitglieder, Aufgaben, Kunden… da kann man einfach nicht sagen, wie lang es dauert, Anforderungen umzusetzen. Das geht nicht.

Und selbst, wo die Anforderungen und sonstigen Rahmenbedingungen scheinbar soviel präziser sind, haut es nicht hin. Die Hamburger Elbphilharmonie ist da nur eines von vielen aktuellen und weithin sichtbaren Beispielen in Deutschland. Auf anderen Kontinenten und in anderen Branchen ist es aber auch nicht besser: Wie ist es zu erklären, dass das US Militär “a long-standing track record of over-promising and under-delivering with virtual impunity” hat? Da geht es doch um handfeste “Maschinen” wie Flugzeuge und Schiffe. Schiffe kosten nicht 220 Millionen Dollar, sondern das doppelte; Flugzeuge kosten nicht 2,7 Milliarden Dollar, sondern 35% mehr, also knapp 3,6 Milliarden Dollar.

Merkt denn noch einer etwas? Schätzen haut außer in trivialen Fällen nicht hin. Schätzungen sind meistenteils Lügen – weil sie in Bewusstheit ihres Fehlers abgegeben werden – und wenn nicht, dann sind sie Fahrlässigkeiten.

Auf der einen Seite wissen wir also all das – und auf der anderen Seite tun Softwareentwickler es doch immer und immer und immer wieder. Warum? Weil es so schön weh tut? Ja, mir scheint, ein gewisser Hang zum Masochismus scheint da mitzuspielen. Der drückt sich auch immer wieder in der Sprache aus, die den Softwareentwickler bzw. seine Abteilung oder sein Unternehmen zu einem willenlosen Opfer des Kunden macht. Denn der Kunde will es so. Der will eine Schätzung. Entweder direkt, indem er fragt, “Wie lange dauert das? Wieviel kostet es?” Oder indirekt, indem er vorgibt, “Das darf nur soundsoviel kosten und soundsolange dauern!”

Und dann kuschen sie alle. Kopf und Schwanz einziehen und frisch geschätzt. Oder die Schätzungen von Inkompetenten einfach übernehmen. Wird schon hinhauen. Irgendwie. Denn wenn nicht… dann Gnade ihnen der Markt, der neue Gott. Dann wird abgestraft, weil die Softwareentwicklung sich nicht als wettbewerbsfähig erwiesen hat.

Ich kann das nicht mehr hören.

Die ganze Welt verschätzt sich allermeistens. Aber keiner will das wahrnehmen. Und das Wurzelproblem angehen will schon gar keiner. Das ist nämlich erstens eine Mentalität des “Ich will meinen Arsch retten” und zweitens eine Verkennung der Realität des 21. Jahrhunderts. Über Ersteres will ich mich hier nicht weiter auslassen. Ein andermal vielleicht. Und zu Letzterem sei nur gesagt: Das Charakteristikum des 21. Jahrhunderts ist die Komplexität. Bis ins 20. Jahrhundert mag die Welt kompliziert gewesen sein. Sie schien mit Zuckerbrot und Peitsche und Maschinen bewältigbar. Doch das ist vorbei. Autos, Fernseher, Gesundheit, Fußballmannschaften, Ehen, Märkte, nationale Sicherheit… das alles ist in der Komplexität angekommen – allemal die Software. Das heißt: Nachdenken, hartes Nachdenken und Rumrechnen führt zu keinem sicheren Ergebnis mehr.

Die Architekten und Bauunternehmer der Elbphilharmonie haben sicherlich hart über die Kosten des Bau nachgedacht und nicht leichtfertig den ursprünglichen Millionenbetrag genannt – und trotzdem haben sie meilenweit daneben gelegen. Ebenso die Ingenieure bei Flugzeug- und Schiffsbauern der US Streitkräfte.

Die schlichte Möglichkeit zu einer verantwortungsvollen, verlässlichen Schätzung ist überbewertet. Sie grenzt geradezu an Aberglauben, sage ich mal.

Und diesem Aberglauben will nun auch noch die Agilitätsbewegung dienen? Das ist doch Quatsch, oder?

Nein, man komme mir jetzt nicht wieder mit “Aber der Kunde will das und deshalb müssen wir.” Wenn wir so als Art immer gedacht hätten, dann säßen wir noch auf den Bäumen in der Afrikanischen Savanne. Nur weil irgendwo ein Widerstand ist, geben wir als Art nicht nach. Wir sind da anders gestrickt. Widerstand hat uns immer herausgefordert. Wie ist sonst zu erklären, dass der Mensch von der Savanne ins ewige Eis ausgewandert und dort geblieben ist? Eskimos trotzen jeden Tag Widerständen. Warum? Die könnten doch sagen, “Die Natur ist hier so unwirtlich, die will uns hier nicht. Also weichen wir besser…”

Achso, die armen Eskimos konnten nicht anders? Das ewige Eis war für sie das kleinere Übel. Deshalb mussten, nein, wollten sie dort bleiben. Da bin ich im Zweifel, aber lassen wir die Eskimos. Wenden wir uns ungezwungen extremen Zeitgenossen zu wie Rüdiger Nehberg, Reinhold Messner oder dem weniger erfolgreichen Samuel Koch, der während der Wetten-dass-Sendung verunfallte. Sie alle lieben den Widerstand. Sie leben für die Überwindung von Widerständen. Genauso Mutter Theresa oder Muhammad Yunus, die sich sozialer Probleme angenommen haben.

Also verstecke man sich nicht dahinter, dass der Kunde, der allmächtige, dumme, arrogante, naive, herrschsüchtige Kunde ein solches Problem sei, dass der menschliche Geist nicht überwinden könne. Die Vertriebler der Welt, die Einkäufer der Welt sind nicht zur Wirklichkeit zu erwecken? Das ist für die Art, die den Planeten verlassen hat, ein zu schwieriges Problem?

Ich würde sagen, hier wollen Menschen einfach nur nicht. Niemand will sich den Schuh anziehen, dieses Problem zu lösen. Keiner will den ersten Schritt machen. Noch nicht einmal – um wieder zur Softwareentwicklung zurückzukommen – die ach so innovativen Agilisten. Stattdessen schwenken sie den StoryPoint-Zauberstab, rufen “Aestimatus!” und glauben, mit relatiben Aufwänden und ein bisschen Beobachtung sei das Problem aus der Welt gewünscht. Bullshit!

Relative Aufwände sind nur das: relative Aufwände. Wenn Aufgaben A, B, C laut Schätzung im Verhältnis 1:2:3 stehen, dann weiß man am Ende nur genau das. Aber nicht, wie lange die Realisierung dauert. Nicht, wenn A oder B oder C dank der Marktes oder der Politik oder der Technik oder einer Unpässlichkeit etwas Unwägbares enthalten. Das ist aber beim Geschäft der Softwareentwicklung sehr wahrscheinlich. Sehr, sehr wahrscheinlich sogar. Sonst hieße die Softwareentwicklung auch nicht Software-Entwicklung, sondern Software-Bäckerei oder Software-Schusterei.

Entwicklung als Tätigkeit ist inhärent unwägbar aufwändig. Das liegt an ihrem Auftrag und an ihrem Stoff. Sie soll kreativ sein. Sie muss sich mit Materialien und Werkzeugen rumplagen, die sich in irrwitzigem Tempo ändern. Nicht zu reden vom wetterwendischen Kunden, der heute dies will und morgen jenes. Und egal, was er will, so ganz genau weiß er eh nicht, was das ist. “Machen Sie das mal, Sie als Softwareentwickler wissen das am besten.” – nur leider findet er es am Ende doch nicht so gut, was die Softwareentwicklung aus dieser Freiheit gemacht hat.

Ich widerspreche daher der immer noch gängigen Schätzpraxis. Schätzen zum Zwecke einer Aufwandsbestimmung zum Zwecke einer Preis- und/oder Dauerfestlegung funktioniert für die Softwareentwicklung nicht. Heute nicht und wahrscheinlich in Zukunft nicht. Da helfen keine StoryPoints und keine lustigen Pokerspiele darum und keine Geschwindigkeitskurven.

Man mag relative Aufwände schätzen, um danach zu priorisieren oder Ressourcen zu allozieren. Wenn Anforderung A weniger aufwändig ist als Anforderung B, dann sollte sie deshalb früher (oder später) angegangen werden. Oder wenn B ansteht, dann sollen noch zwei Entwickler mehr ins Team, um die “processing power” mit ihren “Kernen” zu erhöhen. (Dass dafür der Entwicklungsprozess und Entwurf passen müssen, ist selbstredend.)

Mehr als das lässt sich aus relativen Aufwänden aber nicht ablesen. Alles andere ist Illusion, Augenwischerei und Rumgezappelt vor dem drohenden Blick des allmächtigen Kunden - der Unmögliches will.

Deshalb: Widerspruch gegen das Schätzen.

Statt das Unmögliche zu wollen, sollten wir uns jeden Tag anstrengen, die Wirklichkeit den Blinden und Naiven und Ignoranten, die sie nicht sehen können oder wollen, nahezubringen. Lasst uns Licht anzünden und zu ihnen tragen. Dann mögen sie lesen und sehen, wie die Welt ist: unschätzbar, wenn es um Komplexes geht. Und wo sollte das nicht der Fall sein, wenn es interessant wird? Mit Komplexität lässt sich Geld verdienen. Aber ehrlicher und friedlicher und gesundheitsschonender als heute auf der Basis widernatürlicher Schätzungen.

78 Kommentare:

Hans hat gesagt…

Also lassen wir das Schätzen und fangen einfach mal mit dem Entwickeln an? Schaun mer mal, wo wir rauskommen.

Joachim Roppert hat gesagt…

@Hans: Ja, genau das. Am ersten Tag schaun mer mal wo wir rauskommen, nach einer Woche haben wir schon eine grobe Idee in welche Richtung die Reise geht, nach einer weiteren Woche [ZeirafferAn] sehen wird diese Idee ein wenig konkreter und das gilt auch für die folgenden Wochen [/Zeitraffer aus]. Mit der Zeit ergibt sich ein immer genaueres Bild des Gesamtaufwandes. Der große Unterschied: Die jeweils gültige Prognose für den Gesamtaufwand ergibt sich durch Erfahrung, nicht durch Kaffeesatzleserei.

Unknown hat gesagt…

Ok, d'accord. Aber nun ist es so, dass man Leute (und auch Kunden) zu besserem Handeln erziehen muss. Verständnis für die Situation der Leute-die-diese-Computer-verstehen kann man ja fast nicht erwarten. Es sei denn es liegt ein technischer Erfahrungshintergrund vor.

Welche Alternative zum bietet man dem Kunden nun damit er den zu erwartenden Preis und die zu erwartende Leistung abwägen kann?

Guido Zockoll hat gesagt…

Hallo Ralf,

erstmal Dank für die klaren und anregenden Worte.

Wenn man das weiterdenkt: Heißt das, dass alle Kosten/Nutzen Abschätzungen der Menschheit demnach falsch sind oder waren? Und dass der geschäftliche Erfolg eines Unternehmens letztendlich nur auf Zufall beruhen?

Oder ist es nicht eher so, dass Schätzen nach wie vor möglich ist, dass nur die Unsicherheit beim Schätzen (verursacht durch die Komplexität) stetig größer wird? Hat die Unsicherheit einen so großen Wert erreicht, des Schätzen keine höhere Trefferwahrscheinlichkeit mehr als Würfeln hat? Heißt das nicht auch, dass die Komplexität der von uns geschaffenen Welt schneller wächst als der menschliche Geist und somit der Zusammenbruch der Gesellschaft unausweichlich ist?

Unknown hat gesagt…

100% ack. Nur was sag ich dem Kunden, der wissen will wieviel es kostet?

Ralf Westphal - One Man Think Tank hat gesagt…

@Dani: Dem Kunden sagst du, dass er soviel Geld ausgeben kann, wie er mag. Er hat volle Budgethoheit.

Und du wirst nie nachverhandeln mit ihm. Er weiß vom ersten Tag an, was es kostet. Es wird nie teurer.

Und du sagst ihm, dass er jeden (!) Tag den Kurs ändern kann, wenn er will. Er ist somit maximal flexibel.

Und er kann jederzeit abbrechen und bekommt die vollen Rechte am Code.

Und du arbeitest die ersten 3 Wochen umsonst, wenn er sich bis dahin entschließt, abzubrechen, weil er unzufrieden ist. (No questions asked - aber es wäre natürlich schön, wenn er trotzdem sagen würde, warum er abbricht.)

Ralf Westphal - One Man Think Tank hat gesagt…

@Guido: Natürlich ist schätze möglich. Immer dort, wo du eine Sache beherrschst, wo etwas wiederkehrt, das Unbekannte minimal ist bzw. aus dem Weg geräumt werden kann.

Kompliziertes kann mit genügend Erfahrung geschätzt werden. Komplexes, Neues, Unbekanntes kann nicht geschätzt werden.

Wer schon 5 Weihnachtsbäume geschmückt hat, kann schätzen, wie lang es beim 6. dauern wird. Wer hingegen kaum mit WCF Erfahrung hat, 2 neue Teammitglieder einarbeiten muss, eine nur grob bekannte Problemdomäne beackern soll, ungenaue Vorgaben bekommt... der kann nicht sinnvoll schätzen.

Wächst die Komplexität schneller als unsere Schätzkompetenz? Hm... ich würd sagen, mit dem Schätzen kommen wir schon lange nicht mehr hinterher. Da entwickeln wir auch nicht mehr Kompetenz. Was man nicht kann, kann man halt nicht. Kreatives kann man nicht schätzen; das ist per definitionem so.

Interessant in dem Zusammenhang, dass die Preissteigerung von Kriegsschiffen der US Navy doppelt so hoch wie die Inflationsrate ist (seit dem 2. Weltkrieg). Da kommt man weder mit dem Schätzen noch mit dem Geld hinterher :-) Am Ende sorgt dann wahrscheinlich kein Abkommen für eine Rüstungsbremse, sondern schlicht die Ökonomie - und das ewige Verschätzen ;-)

Guido Zockoll hat gesagt…

@Ralf: Grundsätzlich stimme ich ja mit dir überein - komme aber zu einem anderen Schluss:

Anstatt vor dem Problem zu kapitulieren und Schätzen als unmöglich zum erklären, würde ich deine Aussagen gerne konstruktiv interpretieren.

Ich habe deine Argumentation so verstanden:
* Neue, unbekannte Tools und Technologie erhöhen den Grad der Unsicherheit
* Neue Teammitglieder erhöhen die Unsicherheit
* Unbekannte Fachlichkeit erhöhen die Unsicherheit
* Die Kombination von allem für zur Beliebigkeit der Schätzung.

Full Ack! Also, um Schätzungen wieder sinnvoll zu machen sollten wir auf bewährte Technologien, fest gewachsene Teams setzen und unsere Energie lieber darauf verwenden, die Fachlichkeit zu verstehen, als auf das neue geile Webframework 3.0.

Eine zusätzliche Massnahme könnte sein, Wege zu finden, auch mit großen Schätzfehlern umzugehen. Mir fällt dazu ein: agile Methoden uns konsequentes Risikomanagement (im Sinne von Handeln - und nicht von protokollieren).

Schätzen ist eine der Grundpfeiler unserer Gesellschaft - wenn alle Investitionsentscheidungen einer Firma mit dem Würfel getroffen werden, dann wäre wahrscheinlich keiner glücklich und der wirtschaftliche Erfolg wäre ebenfalls reines Glückspiel.

Apropos Glückspiel - es gibt Leute die selbst kleine Abweichungen vom reinen Zufall (z.B. beim BlackJack) für große Gewinne nutzen können.

Schätzen ist sinnvoll - auch wenn wir nur wenig besser Schätzen als zu würfeln.

Über das Thema "Komplex, oder doch nur kompliziert" habe ich 2009 auf der JAX auch einen Vortrag gehabt.

Insofern gebe ich dir auch in dieser Sache grundsätzlich recht. komplizierte Aufgaben sind mit genügend Rechenpower langfristig planbar - aber selbst vor komplexen Aufgaben müssen wir Menschen nicht kapitulieren - wir müssen nur unsere Strategie ändern und zum einem gegebenen Zeitpunkt t ein effizientes Handeln wählen - also iterativ vorgehen.

Aber auch die Effizienz des Handelns muss geschätzt werden - und sei die Schätzung auch noch so schlecht.

Ralf Westphal - One Man Think Tank hat gesagt…

@Guido: Nein, das ist für mich keine Lösung, die du da beschreibst mit

"Also, um Schätzungen wieder sinnvoll zu machen sollten wir auf bewährte Technologien, fest gewachsene Teams setzen und unsere Energie lieber darauf verwenden, die Fachlichkeit zu verstehen, als auf das neue geile Webframework 3.0."

In unserem Job können wir nicht darauf verzichten, neue Tools und Teamfluktuation und wechselnde Domänenanforderungen bewältigen zu können. Es ist quasi die Definition von Softwareentwicklung, so flexibel zu sein. Jede Form von Starrheit ist zu vermeiden. "Embrace change!" kann nur unser Motto lauten.

Dass Teams de facto Veränderung vermeiden, wo sie können, ist natürlich klar. Da wird Fortbildung verweigert, da werden Urlaubssperren verhängt, es werden Konventionen und Tools über Jahre eingefroren. Macht das irgendwas besser? Sind das dann die Helden der Schätzung, auf die wir neidisch blicken? Nein. Die kriegen es immer noch nicht hin.

Mit Schätzfehlern besser umgehen? Klar. Am besten dadurch, sie zu vermeiden, indem wir nicht mehr schätzen. Die übliche Kompensation besteht darin, Puffer hinzuzufügen. Aber erstens reicht das ja nicht. Auch die eigentliche Schätzung plus Puffer unterschätzt den wahren Aufwand. Und dann ist ein solcher Puffer eine Form von Unehrlichkeit; das sieht man daran, dass ihn niemand explizit einem Kunden gegenüber kommuniziert.

Wenn du beim Golfen immer und immer wieder nicht ins Loch triffst, dann korrigierst du. Und wenn die Korrektur dich nicht besser macht, dann korrigierst du weiter. Und wenn du nach 50 Jahren der Korrektur immer noch nicht besser geworden bist, was dann? Dann magst du beim Golfen sagen, es ginge dir nicht ums Einlochen; du hast einfach Spaß am Schwingen des Schlägers. Aber eher wirst du zugeben, dass Golfen nix für dich ist und du es besser zugunsten von Schwimmen oder Häkeln aufgibst. Wenn die Korrektur der Korrektur der Korrektur nicht hilft, dann hört man einfach auf mit dem, was man tut - oder wählt einen komplett anderen Ansatz.

Die Agilität hat das versucht mit ihren kurzen Iterationen. Feine Sache. Ich bin dafür. Aber sie hat deshalb nicht das Schätzen aufgegeben. Das (!) ist meine Kritik. Sie ist nicht wirklich ehrlich geworden. Vielmehr versucht sie, durch die Hintertür doch wieder das zu schätzen, was unschätzbar ist. Denn wenn am Ende ein Team sich bei Velocity X für Periode T einpendelt, dann bedeutet das nicht, dass es die nächsten mit X geschätzten Anforderungen auch in T umsetzt. Die Wahrscheinlichkeit mag besser sein als beim üblichen Schätzen. Aber erstens ist es eben nicht wirklich "ingenieursmäßig sicher" und zweitens bezieht sich die Velocity nur auf eine konstante Konstellation. Ändert sich das Team (und sei es durch Urlaub), ändern sich die Technologien oder sonstwas, ist es vorbei mit der erreichten Velocity. Dann muss wieder neu gemessen werden über ein paar Iterationen.

Velocity taugt einfach nicht zur Vorhersage! Allemal nicht vor einem Projekt, wenn der Kunde Zahlen für einen Vertragsabschluss haben will. Weder kennt man da die Velocity des Teams in Bezug auf den Auftrag, noch kennt man überhaupt die SP für Anforderungen in dem Auftrag.

StoryPoints lösen das Schätzproblem für die Angebotsabgabe nicht. Können sie auch nicht. Denn das Problem ist unlösbar. Ganz prinzipiell. Denn es geht um Entwicklung von Neuem und nicht Produktion von Bekanntem. Get real, baby :-) Es hilft kein Winden und Jammern. Wir müssen uns und unsere Kunden desillusionieren: Softwareprojekte zu schätzen, um auf einen Preis/Aufwand zu kommen, der nur im 5% Rahmen unter/überschritten wird, ist illusorisch. Gand prinzipiell, fundamental, grundlegend.

Ralf Westphal - One Man Think Tank hat gesagt…

@Guido: Noch ein Wort zum Schätzen in Scrum. Scrum hat keinen Anspruch, das allgemeine Schätzproblem, um das es mir geht, zu lösen. Scrum und Velocity helfen nicht, ein Projekt vor Beginn zu schätzen. Darum geht es da nicht.

Scrum versucht lediglich, relativ verlässlich zu bestimmen, was im nächsten Sprint geschafft werden kann.

Das hilft einem Verkäufer vor Projektbeginn aber nicht. Und soll es auch nicht.

Wenn dann irgendwer die Velocity hernimmt und damit versucht, das nächste Projekt abzuschätzen, dann ist das ein Missbrauch der Velocity.

(Inwiefern Velocity ihr Ziel erreicht und eine ehrliche Metrik ist, lasse ich hier mal dahingestellt. Das Commitment, das ein Team auf der Basis der Velocity abgibt, kann sich auch als Druck erweisen, der dazu führt, dass Schätzungen mit Puffern versehen werden, weil man ja immer noch unsicher ist, aber in jedem Fall sein Commitment erfüllen will. Das halte ich für die falsche Basis einer vertrauensvollen Zusammenarbeit. Beim Schätzen gilt also auch: Garbage in, garbage out. Wer das Unmögliche will (Schätzung), der bekommt Müll.)

Guido Zpckoll hat gesagt…

@Ralf:

Sehr anregende Diskussion :)

"Wir müssen uns und unsere Kunden desillusionieren: Softwareprojekte zu schätzen, um auf einen Preis/Aufwand zu kommen, der nur im 5% Rahmen unter/überschritten wird, ist illusorisch. Gand prinzipiell, fundamental, grundlegend."

100% ACK

Ich sage doch auch, die Unsicherheit steigt. Ich glaube auch, dass ein Projekt, dass seine Schätzung nur um 100% überzieht ein riesen Erfolg ist. Vielleicht haben andere Industriezweige das bereits erkannt und akzeptieren solche Ungenauigkeiten - auch auf die Gefahr dafür in der Bildzeitung zu landen.

Trotzdem halte ich die Kapitulation vor dem Thema Schätzen auch nicht für die Lösung. Ein wesentliches Merkmal von Intelligenz ist es, das eigene Handeln in die Zukunft zu projezieren und die Auswirkungen abzuschätzen. Bei erhöhter Unsicherheit wird nur der Vorhersagehorizont kürzer. Schätzungen über diese Woche können wir vielleicht wirklich mit dem von dir angegebenen Konfidenzlevel von +/-5% machen - Schätzungen über den nächsten Sprint vielleicht nur mit +/-20% und Schätzungen übers ganze Projekt vieleicht nur mit -50%/+200% Aber deshalb aufs Schätzen zu verzichten?

Tom DeMarco hat mal gefordert, das Kosten und Nutzen für ein Projekt in der selben Genauigkeit vorliegen müssen. Lautet der Business Value: "Das müssen wir haben", das ist die Schätzung "Das wird aber teuer" adäquat.

Im übrigen hat natürlich der ProductOwner die gleichen Probleme beim Schätzen.

Trotzdem ist eine Schätzung sinnvoll um unser Handeln in der Zukunft zu bestimmen.

Nutzen 5Mio +/- 2Mio
Kosten 2Mio +/- 1Mio
=> Super Projekt, völlig Risikofrei, trotz großer Schätzungenauigkeit

Nutzen 3Mio +/- 2Mio
Kosten 2Mio +/- 1Mio
=> riskant, aber vielleicht trotzdem sinnvoll

Auch ein kleiner Vorteil gegenüber dem reinen Zufall ist es wert trotzdem zu schätzen - und die Unsicherheit offenzulegen.

"Wir müssen uns und unsere Kunden desillusionieren" - aber nicht, in dem wir uns weigern zu schätzen, sondern in dem wir dem Kunden die Unsicherheit der Schätzung bewusst machen und ihm helfen, damit zu leben.

Anonym hat gesagt…

Eine besondere Unart ist das Ad-Hoc-Schätzen. Der Kunde ruft an, schildert in ein paar kurzen Sätzen grob den Auftrag und fragt dann nach dem Preis? Ich verweigere da grundsätzlich die Aussage mit der Begründung keine seriöse Schätzung machen zu können und nenne nur meinen Stundensatz.

Solche Fragen kommen oft auch gerne, wenn jemand einen Fehler entdeckt hat. "Hallo, Feature XY funktioniert nicht. Können Sie das reparieren? Wie lange dauert das?" Mal unabhängig davon, dass "funktioniert nicht" ohnehin keine gültige Fehlerbeschreibung ist, fragt man sich dann immer wieder, ob die Leute glauben, man sei Hellseher. Wenn man dann sagt, "weiß ich nicht" sind die Leute teilweise richtig empört. Meist hört man dann: "wieso wissen Sie das nicht? Sie haben die Anwendung doch geschrieben".

Ralf Westphal - One Man Think Tank hat gesagt…

@Anonym: Ich find gut, dass du die Schätzung in dem Fall verweigerst.

Leider suggerierst du jedoch, dass unter anderen Umständen (die du nicht näher beschreibst), eine Schätzung möglich sei. Das halte ich - wie du dir denken kannst - für falsch. Selbst wenn der Kunde alles minutiös beschreiben würde und nie Änderungswünsche hätte bis zur Fertigstellung könntest du ihm nicht mit einer Fehlermarge von vielleicht 5% sagen, wie lange es dauert. (Zumindest nicht, wenn das Projekt mehr als ein paar Tage dauert.)

Dieses "Schlupfloch" müssen wir stopfen. Dadurch kommt nämlich immer wieder der Wunsch nach einer Schätzung in unsere Welt. Kunden glauben, sie könnten durch mehr Aufwand up-front etwas liefern, worauf wir dann vernünftig, verantwortungsvoll und verlässlich schätzen könnten. Aber genau das ist Quatsch. Das geht nicht für alles Nichttriviale.

Sag ihm beim nächsten Mal also: "Ich kann das nicht schätzen. Und ich kann auch nicht schätzen, wenn Sie mir mehr Informationen liefern. Ich kann mir höchstens Ihre Anforderungen anschauen und daraus etwas schneiden, das ich bis morgen realisiere. Aber mehr geht nicht. Wollen Sie das haben? Dafür zahlen Sie X EUR. Und wenn es Ihnen gefällt, dann schneide ich ein nächstes Stück für übermorgen heraus. Und so weiter. Bis es Ihnen reicht."

guybrush hat gesagt…

Danke Ralph für die klaren Worte. Endlich mal jemand der mir aus der Seele spricht. Bisher dachte ich immer, ich seie nur so ein Irrer und Träumer.

Also frei nach Marx "Wider die Schätzer vereinigt euch".

Anonym hat gesagt…

Wahre Worte gut geschrieben und einfach auf den Punkt gebracht.

Die Frage die wir uns stellen müssen lautet: Warum spielen wir, die die Fäden in der Hand haben, dieses Spiel mit?

Zumal es von Beginn an verloren ist.

Frei nach dem Motto - Jeder ist seines Glückes Schmied - sollte man sich der Tatsachen nicht verwehren sondern gemeinsam wehren Schätzungen jeglicher Art auf einer wackeligen Basis abzugeben.

Der Vergleich mit dem Weihnachtsbäumen war sehr treffend. Wenn ich eine Aufgabe immer und immer wiederhole, dann kann ich sehr wohl eine konkrete Schätzung abgeben, da sich die entscheidenen Faktoren nicht verändern. Dann aber befinde ich mich auch in der Serienfertigung und nicht in der "Entwicklung".

Am liebsten sind mir (wenn auch sehr sehr selten) Aufträge mit Abrechnung nach Aufwand (mit einer großzügigne Obergrenze), die leider nur in sehr seltenen Fällen noch eintrudeln.

In diesem Sinne
phpfluesterer

Unknown hat gesagt…

@Ralf W.:
Ich stimme dir auch voll und ganz zu!

Meine "Lieblingsfrage" auf Arbeit ist auch immer: "Was schätzd'n, wie lange du dafür ungefähr brauchst?"

Da fühle ich mich jedes mal wie vor den Kopf gestoßen.

@Guido Zockoll:
Also, um Schätzungen wieder sinnvoll zu machen sollten wir auf bewährte Technologien, fest gewachsene Teams setzen und unsere Energie lieber darauf verwenden, die Fachlichkeit zu verstehen, als auf das neue geile Webframework 3.0.

Das halte ich für das Schlimmste, was man tun kann.
Nirgendwo ändern sich die Dinge mMn. schneller, als in der Software-Branche. Wenn man da nicht mit dem Strom schwimmt, hat man bald verloren.

Ralf Westphal - One Man Think Tank hat gesagt…

@phpfluesterer: Abrechnung nach Aufwand ist der einzige Weg - aber der Aufwand muss vom Kunden kontrolliert werden. Sonst wird es das gefürchtete Fass ohne Boden.

Und genau diese Kontrolle stellt die tägliche Abnahme dar, die ich in meinem Traum beschrieben habe.

Festpreis durch "nach Aufwand" allein zu ersetzen, ist inakzeptabel. Das wäre nur ein Vorteil für den Entwickler.

Aber Festpreis durch tägliche Auslieferung von sich täglich ändernden Wünschen zu ersetzen, die solange läuft, wie man will, das ist ein Deal, der beiden Seiten Vorteile bringt.

Markus hat gesagt…

Wir soll der Kunde ohne Schätzung wissen, ob er sich die angestrebte Lösung überhaupt leisten kann? Eine halbe Lösung (die Basisdaten werden erfasst, aber wichtige Reports fehlen noch) hilft ihm doch nichts. Zumindest eine ungefähre Größenordnung muss bekannt sein. Und die muss man schätzen.

Guido Zockoll hat gesagt…

@ChinaFan

***
"@Guido Zockoll:
Also, um Schätzungen wieder sinnvoll zu machen sollten wir auf bewährte Technologien, fest gewachsene Teams setzen und unsere Energie lieber darauf verwenden, die Fachlichkeit zu verstehen, als auf das neue geile Webframework 3.0.

Das halte ich für das Schlimmste, was man tun kann.
Nirgendwo ändern sich die Dinge mMn. schneller, als in der Software-Branche. Wenn man da nicht mit dem Strom schwimmt, hat man bald verloren."
***


Mir ist klar, dass die Deutung unbequem ist, wir Informatiker sehen unserer Aufgabe ja darin, Fortschritt zu erzielen durch besser Programmiersprachen, besser Frameworks, bessere Tools.

Aber wenn Ralf argumentiert:

Denn da wo etwas Neu ist, seien es Tools, Techniken, Teammitglieder, Aufgaben, Kunden… da kann man einfach nicht sagen, wie lang es dauert, Anforderungen umzusetzen. Das geht nicht.

ist es da nicht die bessere Variante, das Neue in Frage zu stellen? Ich arbeite auch gerne mit RubyOnRails, Groovy, Wicket, REST und wie sie alle heißen. Aber sind die paar Prozent Steigerung der Entwicklungsperformance (Fredick P. Brooks Jr,: No Silver Bullets) es wirklich wert, unsere Fähigkeit zu schätzen zu opfern?

DJ München hat gesagt…

Ist doch leider gängige Praxis, da meist zuerst geredet wird bevor alle Fakten und Kosten auf dem Tisch sind und selbst detailierte Angebote sind Schätzungen wenn dann bekannt wird das mehr rauszuholen ist... Leider...
Guter Post, weiter so... :)

Anonym hat gesagt…

Blödsinn, man kann immer schätzen, auch sinnvoll. Der Umstand, dass die Schätzungen oft stark vom Ergebnis abweichen, macht das Schätzen noch längst nicht überflüssig.

Ralf Westphal - One Man Think Tank hat gesagt…

@Markus: Von mir aus liefere eine ungefähre Größenordnung. "Können Sie mir eine Warenwirtschaft für 500 EUR programmieren?" "Nein, das wird mindestens 50.000 EUR kosten."

So sei es denn. Ob das was und wieviel bringt, weiß ich nicht. Am Ende macht es aber eher kaputt, weil der Kunde den Unterschied zwischen einen "groben Hausnummer" und einem Fixpreis nicht versteht.

Außerdem bringt eine grobe Hausnummer nichts, wenn ich nicht weiß, ob ich mit Formel1-Fahrern verhandle oder mit Seifenkistenfahrern. Die Kompetenz/Produktivitätsunterschiede bei Entwicklern/Teams sind im Bereich von Faktor 10 und mehr. Wenn einer sagt, "Kostet ca. 100.000 EUR", ist das dann ein Rennfahrer und ich kriege richtig viel für mein Geld? Oder sitzt der in einer Seifenkiste und ich werde im Grunde ausgenommen?

Wenn ich als Kunde als eine Schätzung von jmd haben will, dann sollte ich gleich fragen, in welche Liga er spielt. Tja... und damit mache ich ein ganz neues Fass auf. Wer ist bereit, seine Kompetenz/Produktivität bewerten zu lassen, bevor er sich mit Schätzungen in die Welt traut?

@Anonym: Was soll gut sein an Schätzungen, wenn sie - wie du selbst sagst - "oft" vom Ergebnis abweichen? Erkläre uns das doch kurz mal. Du schätzt also, die Software ist mit 200 Personentagen zu schreiben, du kalkulierst so, der Kunde bezahlt die Tage - und dann brauchst du aber leider 300 Personentage.

Supi. Wer hat da jetzt etwas gewonnen außer Frust? Der Kunde, weil er lange gewartet hat? Du, weil du Kohle verbrannt hast, die du eigentlich als Gewinn einstreichen wolltest? Ganz zu schweigen von dem schleichenden oder ganz deutlich explodierenden Frust auf allen Seiten.

Markus hat gesagt…

@Ralf: In jeder Branche gibt es Renn- und Seifenkistenfahrer. Aber unabhängig davon: Würdest Du ein Haus von einer Firma bauen lassen, die Dir sagt "Die Stunde kostet X Euro. Wir wissen nicht wie lange es dauert."? Sicher nicht, weil nicht klar ist, ob hinterher nur ein halbes Dach und ein viertel Esszimmer fertig sind, wenn Dein Budget zur Neige geht. Warum soll das bei Softwareentwicklung anders laufen (können)?

Olaf hat gesagt…

Wieder mal vielen Dank für einen großartigen Artikel - allein die Thematisierung verdient Applaus.

Ich steige mal mit ein und trenne die Concerns und picke mir einen interessanten raus - worum geht es in vielen der Kommentare?

Um die Psyche des Kunden. Der will eine Zahl sehen, seinem Management "verkaufen" und sich sicher fühlen.

Offenbar sind hier weder ein verbindliches Angebot noch ein Schätzwert noch ein "nach Aufwand" eine angenehme Lösung.

Drum teile ich eine Erfahrung:
Womit wir in letzter Zeit außerordentlich gut fahren, sind von uns sog. "Deckelangebote". Sie funktionieren bislang prima, allerdings nur mit nicht "knallharten" Kunden (die man allerdings sowieso nach und nach auswechseln sollte, wenn man es sich erlauben kann).

Und zwar wie folgt:
Der Kunde erhält ein für den Auftragnehmer sehr großzügig kalkuliertes Angebot (Faustformel: MINDESTENS Bauchgefühl/Hausnummer mal zwei) mit der (ehrlichen) Zusicherung, man werde 1. nur die wirklich benötigten Stunden berechnen und 2. alle verbratenen Stunden detailliert nachweisen. Erstaunlicher Weise können wir die meisten Kunden davon leichter überzeugen als von einem deutlich niedrigeren Festpreis.

Das hat folgende Effekte:

1. Der Kunde hat seine "Zahl" und damit seine Sicherheit. Er kann intern vermitteln, dass sich diese Zahl nicht ohne weiteres mit den fixen Zahlen der Konkurrenz vergleichen lässt.
2. Er weiß: vielleicht wird es sogar billiger (und freut sich über diese Möglichkeit - anstatt sich vor Nachforderungen oder Auseinandersetzungen zu fürchten).
3. Er weiß: je mehr er kooperiert, je sauberer er seine Anforderungen schreibt, je genauer er mitdenkt, je besser er testet, desto billiger wird es (Schwupps: sein projektbegleitender Arbeitseinsatz lohnt sich plötzlich!!!).
4. Kleine Nachforderungen werden mal eben stressfrei ohne Extraangebot mit erledigt (Kunde freut sich!), wenn sie in den Budgettopf passen. Details stehen dann in der Rechnung.
5. Die Tatsache, dass es sich um ein "Deckelangebot", also ein Maximalangebot, handelt, wird irgendwie halb "vergessen" vom Kundenmanagement - die Zahl wirkt stärker als die Erklärung, sie ist einkalkuliert. Das entspannt (auch wenn wir natürlich ehrlich bleiben!).
6. Es muss nicht "gefeilscht" werden um "schlechte" Spezifikationen (natürlich immer solange der Topf groß genug ist). Der Ansatz unterstützt Agilität.
7. Kulanz wird plötzlich bezahlt (die Stundenuhr läuft ja weiter) - Kunde freut sich (über die Kulanz)!
8. Last not least wirkt ein solcher Ansatz auch irgendwie seriöser auf viele Kunden als der Festpreis (oder "nach Aufwand"). Sie haben mehr das Gefühl von Kontrolle. Beim Festpreis wissen sie nicht, ob er vielleicht doch zu hoch ist (insb. wenn noch ein lächerliches Konkurrenzangebot vorliegt), "nach Aufwand" fühlt sich wie ein Lizenz zum Geld Drucken an.

Was haltet Ihr von dem Ansatz? Gibt es ähnliche Erfahrungen/Konzepte bei Euch?

Carsten hat gesagt…

Ich verstehe das Problem nicht so ganz. Ich stelle mir folgende Situation im Hause Westphal vor:

Ralf: „Du weißt, dass wir um 19.00h zum Essen eingeladen sind. Wir müssen dann gleich los.“

Sie: „Super. Ich mach mir nur rasch die Haare“

Ralf: „Wie lange dauert den das?“

Sie: „So ca. 10 Minuten“

Ralf: „Bullshit. Ich weiß, dass Du Haare fönen definitiv nicht schätzen kannst. Ich erwarte minütliches Feedback!“

Hans hat gesagt…

@Ralf,

ich weiß ehrlich gesagt nicht, was Du mit Deinem Aufsatz erreichen willst. Sicher Schätzen ist problematisch, das wussten schon die Steinzeit-Menschen. Wenn meine 10- Köpfe-Sippe von einer anderen Sippe mit 10 Köpfen angegriffen wird, muss ich schätzen, ob ich kämpfe oder wegrenne, weil ich nicht weiß, wie stark die anderen sind.

Bei einem Softwareprojekt, dass über ein "Brot und Butter"-Projekt hinausgeht, bei dem des Projektumfeld, die Technolgie und/oder das Team-Knowhow unbekannt ist, kann ich ebenfalls nur schätzen. Und ich und/oder der Kunde müssen abwägen, ob man das Risko eingehen will.

Welche Alternative habe ich denn zum Schätzen? Es ist doch keine Lösung einfach mal anzufangen, wie @Joachim meinte. Ich sehe keinen Unterschied, ob ein Projekt in die Hose geht, weil der "Schätzrahmen" überschritten wurde, oder weil das Budget einfach so aus dem Ruder läuft. Die Ressourcen sind so und so verbrannt.

Übrigens, ich glaube nicht, dass man vor dem Bau des A380, A40oM, LKW-Maut-System etc die Kosten geschätzt hat. Man hat da sicherlich ganz "seriös" gerechnet. Die Kostenrechnung ging halt daneben aber nicht weil geschätzt wurde. Übrigens, hätte man die Projekte auf halber Strecke einstampfen sollen?

Oft wird deshalb zu kurz gerechnet, weil man den Auftrag unbedingt haben möchte, weil man den Kunden unbedingt haben möchte, (selbst wenn man weiß das das Angebot zu gering ist) oder weil man sonst gar nix zu tun hat und die Kinder oder Mitarbeiter irgendwie füttern muss. Das sind nunmal Sachzwänge, an denen man nicht vorbei kommt. Oft will einer auch einfach sein Spielzeug haben, koste es was es wolle (Die anderen würden das Projekt nicht akzeptieren, wenn man im vorhinein die genauen Kosten angeben würde). Interessanterweise liegen die Kostenschätzungen fast immer unter den tasächlich entstehenden Kosten. Woran das nur liegt?

Bei komplexen Sachlagen hilft nur schätzen, um zu entscheiden, ob ein Projekt überhaupt in Angriff genommen wird. Man muss aber, sich und anderen gegenüber ehrlich sein und dabei auch eine ehrliche Risikoabschätzung machen. Es hilft nix. Aber ich stimme Deinem letzten Satz vorbehaltlos zu:

"Aber ehrlicher und friedlicher und gesundheitsschonender als heute auf der Basis _widernatürlicher_ Schätzungen."

@Olaf, ja so ähnlich mach wir das auch. Das geht aber nur dann, Wenn man in der glücklichen Lage ist, nicht jedem Auftrag hinterher rennen zu müssen und sich sich die Kunden "aussuchen" kann.

Ralf Westphal - One Man Think Tank hat gesagt…

@Carsten: Ein lustiger Dialog - aber ein irrealer und unnötiger. Denn "Haare föhnen" ist definitiv eine Sache, die meine Frau aus dem Effeff beherrscht. Sie weiß, wie lange das dauert. Da muss sie nicht mal schätzen.

Anders mag es bei dem neuen Bratengericht sein, dass sie mal ausprobieren will. Sie kann zwar kochen, aber ist sich vielleicht unsicher bei dem neuen Gericht. Fehlendes Wissen wird durch Schätzung aufgrund ähnlicher Erfahrung ersetzt. Dann sagt sie, "Hm... wird ungefähr 2 Stunden dauern bis zum Essen."

Und solches Schätzen ist völlig ok. Denn erstens ist ein neues Gericht viel ähnlicher zu einem Bekannten als eine Software der anderen. Und zweitens reden wir hier über Tätigkeiten, die Stunden und nicht Monate oder Jahre dauern.

Softwareentwicklung zu schätzen bei Anforderungen, deren Umsetzung mehr als wenige Stunden oder höchstens Tage dauert, das ist Quatsch. Mehr sage ich nicht.

Und nochmal: Dieses Problem ist nicht einmal auf die Softwarebranche beschränkt. Das unselige Schätzen kostet uns alle Milliarden!

Ralf Westphal - One Man Think Tank hat gesagt…

@Hans: Ich verstehe nicht, dass du nicht verstehst, was ich mit meinem Beitrag erreichen will. Dabei stimmst du mir doch am Ende im Wesentlichen zu.

Mir geht es darum, Gesundheit und Ressourcen zu schonen. Denn die werden verheizt durchs Schätzen, wo das Schätzen nix bringt.

Dass das Schätzen nur ein Schätzen ist und niemand sich darauf verlassen sollte, ist Wortklauberei. Wenn der Chef fragt, "Wie lange dauert das? Schätze mal." und du sagst, "Hm... ich schätze, das dauert 3 Wochen." und dann dauert es am Ende 6 Wochen - dann ist der Chef sehr, sehr sauer. Da hilft es dann gar nix, wenn du sagst, "Aber Chef, ist habe nur geschätzt und nicht berechnet."

Schätzungen werden pauschal als Berechnungen und damit Wahrheiten empfangen, selbst wenn sie differenziert nur als Schätzungen versandt wurden. Da helfen auch keine Risikobetrachtungen. In welchem Vertrag steht drin, "Der Auftragnehmer liefert den im Lastenheft definierten Funktionsumfang mit einer Wahrscheinlichkeit von 87,5% zum Termin X ab und erhält dafür die Summe Y"?

Da stehen fixe Termine ohne Wahrscheinlichkeiten drin. Und wer die Termine überschreitet, der muss Strafe zahlen.

Also muss einer vorher schätzen, ob die Termine einhaltbar sind. An die Schätzung klebt er vielleicht einen Prozentsatz - aber, bitteschön, woher soll der denn kommen? Das ist doch (in den alllllermeisten Fällen) Augenwischerei.

Ob ein Team die Warenwirtschaft in 2 Jahren realisieren kann? Zu 99% ja, zu 85% dauert es 1,8 Jahre, zu 60% dauert es 1 Jahr usw. Wo liest du das?

Wenn ich das als Kunde sehen würde, dann würde ich mir doch an den Kopf fassen. Und ich wäre mir sicher, dass es immer 2 Jahre dauert. Budgets werden immer ausgeschöpft. Lernt man das nicht schon im ersten Semester BWL?

Die Kombination aus Fixpreis+Fixscope+Fixzeit ist fatal. Die kann niemand von Softwareentwicklung verlangen, der auch nur einen Funken davon versteht.

Und deshalb müssen wir von den dreien eines aufgeben: den Fixscope. Preis und Zeit können fixiert werden. Wunderbar. Nur die Schätzung, ob wir den Fixscope mit den Budgets schaffen, müssen wir sein lassen. Stattdessen muss ein anderer Arbeitsmodus her. Und das geht auch im Gegensatz zum Maschinenbau, weil Software etwas anderes ist. Aber dazu schreibe ich noch einen Blogartikel.

Hans hat gesagt…

@Ralf,

Zeige mir doch bitte einen Kunden der ein Warenwirtschaftssytem in Auftrag gibt, dabei Preis und Zeit vorgibt, der aber nicht böse ist, wenn das Budget erschöpt ist, aber mit dem Erreichten nichts anzufangen ist, das Fixscope ist verfehlt - ach so das gibt es ja nicht mehr. Man könnte dann sagen, schade war wohl nix, aber wir haben wenigstens nicht geschätzt. Sorry wegen der Polemik.

Bevor ich ein Projekt beginne, muss ich doch versuchen, die Kosten zu bestimmen. Oder ist das in Deinen Augen schon falsch?

Und bitte lass die BWL aus dem Spiel. Die Entwicklung der A380 wurde nach betriebswirtschaftlichen Gesichtspunkten betrieben. Du siehst ja, was dabei herauskam. Du hast in Deinem Blog schon weitere Projekte benannt, die preismäßig und zeitlich aus dem Ruder gelaufen sind, und primär nichts mit Software zu tun haben. Ich möchte kein neues Fass aufmachen, aber BWL ist noch dringender reformbedüftig als Softwareentwicklung - Firmenpleiten, Bankenkrise, Ressourcenvernichtung, Umweltprobleme..

Übrigens bei uns werden bei Budgets nicht ausgeschöpft, bloß weil irgendein Betrag auf dem Papier steht. Wir berechnen das, was wir implementieren. Und wenn wir zuwenig veranschlagt haben, wird nicht hinten herum noch was drauf geschlagen. Das ist dann unser Problem. Du hast doch selbst gefordert, dass man fair miteinander umgeht, oder?

Du schreibst: Stattdessen muss ein anderer Arbeitsmodus her. Gut, Zustimmung, aber solange wir den nicht haben, müssen wir die Requirements, die wir nicht komplett überblicken, weiter schätzen. Da geht es uns genauso wie einem Flugzeugbauer, der einen neuen noch zu entwickelnden Werkstoff einsetzen muss, leichter und stabiler, weil sonst das Ding nicht fliegt. Oder einem Handwerker, der einen Altbau renoviert und bei der Abgabe des Kostenvoranschlags nicht 100%ig weiss, welche Probleme im Mauerwerk, Dachkonstruktion etc. auf ihn warten. Ein Handwerker, der seinen Job versteht, wird die meisten Risiken schon kennen. Das sollte auch für Softwareentwickler zutreffen.

Übrigens hat ein Handwerker das gleiche Problem, wie wir Softwareentwickler. Wenn er fertig ist, sagt der Auftraggeber oft: Das habe ich mir aber anders vorgestellt. Dieses Problem wirst Du aber mit der Abschaffung des Schätzens auch nicht beseitigen.

Ich hoffe, dass Du bald eine Lösung des Schätzproblems anbietest. Ein Kunde wartet nämlich noch auf ein Angebot. Das sollte morgen noch raus. :-)

Ralf Westphal - One Man Think Tank hat gesagt…

@Hans: Vor Beginn eines Projektes die Kosten bestimmen? Wer? Der Auftraggeber? Nein. Der kann nicht die Kosten bestimmen, sondern nur sein Budget. Der kann nur bestimmen, was ihm das Projekt maximal wert ist. Und das kann er ganz allein.

Wenn du einen neuen Mixer brauchst oder ein neues Auto, dann weißt du ganz allein, wieviel du dafür ausgeben kannst. Der Media Markt kann dir nicht helfen und der Autohändler deiner Wahl auch nicht.

Wenn du ohne eine solche Zahl losziehst, dann ist das unverantwortlich. Denn dann wirst du leichte Beute der Werbung.

Du wirst dann natürlich fragen, "Was bekomme ich für mein Geld?" Media Markt und Autohändler zeigen dir dann die Optionen. Wenn die es für dich nicht bringen... nun, dann hilft es nix. Du hast eben nicht mehr Geld. Das hast du vorher schon festgestellt. Das wird nicht mehr, wenn es dafür nix Gescheites gibt.

Wenn der selbstverschuldet unaufgeklärte Konsument heute anders handelt, nun dann ist das sein persönliches Problem. Wenn Regierungen so handeln, ist das unser aller Problem.

Ich verstehe auch nicht, dass du unzufrieden mit meiner Position bist. In der BWL findest du keinen Trost. Schätzungen sind auch nach deinen Worten nicht verlässlich. Noch schlimmer: Deine Firma selbst leidet unter schlechten Schätzungen und buttert rein, weil sie fair sein will. Aber fair in was? In einem Spiel, das sie letztlich entweder nicht gewinnen kann (weil Schätzungen für Software im besten Fall zufällig mal stimmen) - oder das sie unehrlich spielt, weil sie viel Marge reinrechnet, ohne es dem Kunden zu sagen.

Was ist das denn für eine Welt?

Softwareentwickler sollten die meisten Risiken kennen? Ja, das wäre schön. Die grundsätzlichen Risiken mag ein SWentwickler auch kennen - aber er kann sie deshalb immer noch nicht für ein konkretes Projekt zu dem Zeitpunkt und in dem Umfang einschätzen, wie es für eine Angebotsabgabe für ein Fixpreis+Fixscope+Fixzeitprojekt nötig wäre.

Eine Lösung des Schätzproblems kann ich mit Schätzen nicht anbieten. Ich kann dir ja auch keine Flügel wachsen lassen.

Wunder gehen sofort - aber Unmögliches... nun, daran beiße ich mir die Zähne aus ;-)

Tut mir leid, letztlich höre ich bei dir nur heraus: "Ralf, in welcher Welt lebst du eigentlich? Die Kunden wollen eine Schätzung zum Angebotszeitpunkt und vor Beginn jeder Arbeit. So ist das halt. Die Welt will Fix-Projekte. So ist das. Get real. Dagegen können wir Softwareentwicklerwürstchen nix machen."

Danke, das "Argument" kenne ich. Meine Antwort darauf habe ich im Blogartikel schon genannt. Wiederholung überflüssig. Wenn wir die Opferbranche mimen wollen, dann können wir das tun - aber man erzähle mir nicht, dass deshalb Schätzungen funktionieren.

Dann sag doch offen: "Wir spielen alle ein Spiel. Das ist wie Poker. Es gewinnt, wer besser blufft." Nur sollte man dann die Softwareabteilung in Ruhe lassen. Die sollte sich mit Wichtigerem beschäftigen als mit für das Spiel unnötigen Schätzungen. Die Einkaufs- und Verkaufsabteilungen können dann allein spielen. Es ist ja eh egal.

Wer ewig in Zuzwang ist, wer abhängig ist vom Auftrag, der muss keine Schätzung abwarten, sondern der muss unterschreiben. Warum also noch irgendjemanden damit behelligen. Besser die Hand heben und zugeben, "Ich habe keine andere Wahl." Das (!) wäre ehrlich. Damit ließe sich sogar noch Motivation aus der Entwicklungsabteilung herauskitzeln.

Thomas hat gesagt…

Gut gebrüllt. Aber bietest du auch eine Lösung für das richtig erkannte Problem? Habe die Kommentare nur überflogen und keine gefunden.

Drehen wir mal die Perspektive. Ich gründe eine Firma und habe zur Entwicklung einer Software, die ich benötige, und von der ich eine grobe Vorstellung in meinem Kopf habe, ein Budget von 20.000 EUR.

Jetzt suche ich mir jemanden, der die Software für mich umsetzt.

Selbst wenn der mir persönlich empfohlen wurde und 20 MVP-Urkunden über seinem Schreibtisch hängen hat, zählt doch für mich nur eines: kann derjenige den Auftrag für das Geld, was ich zur Verfügung habe, am besten für weniger, erfüllen?

Davon hängt schließlich der Erfolg meiner neuen Firma ab. Vielleicht habe ich sogar noch behördliche Auflagen oder sonstige Zwänge, die auch ein Zeitfenster setzen, z.B. einen bestimmten Messetermin, zu dem alles fertig sein muss.

Da gebe ich mich garantiert nicht mit einem "schau mer mal" ab, sondern ich will klipp und klar wissen, ob und zu welchem Preis ich meine Software zum Termin bekomme.

Und nun?

Guido Zockoll hat gesagt…

Hallo allerseits,

eigentlich wollte ich nichts mehr schreiben, da die Argumente sich langsam wiederholen. Aber zu These und Antithese gehört zum Abschluss auch die Synthese. Daran möchte ich mich gerne versuchen. Wegen der Länge in zwei Teilen.

Prämisse: Schätzen macht keinen Spass. Daher ist natürlich die Forderung es komplett sein zu lassen, die radikalste Lösung, die sicherlich sehr populär ist. Ähnlich wie die Forderung, seine Steuererklärung auf einem Bierdeckel machen zu können.

Aber ein Zahnarztbesuch macht auch keinen Spass - trotzdem tun die meisten Menschen das mehr oder weniger regelmässig. Wahrscheinlich um eine noch ungenehmere Situation in der Zukunft abzuwenden.

Synthese: Schätzen macht keinen Spass und dient dazu, eine unangenehme Situation in der Zukunft abzuwenden.

Warum macht Schätzen eigentlich keinen Spass? Vielleicht liegt es daran, dass die Trefferquote so schlecht ist und damit das Erfolgserlebnis fehlt (Golf Vergleich von Ralf). Aber viele Leute schätzen regelmässig die Lottozahlen - mit einer echt beschissenen Trefferwahrscheinlichkeit.

Synthese: bei einen attraktiven Gewinn/Verlust Verhältnis könnte Schätzen Spass machen.

Kommen wir also zum Gewinn/Verlust Verhältnis beim Schätzen:


Die Kombination aus Fixpreis+Fixscope+Fixzeit ist fatal. Die kann niemand von Softwareentwicklung verlangen, der auch nur einen Funken davon versteht.


Ok, hier ist der Gewinn minimal, das Verlustrisiko aber maximal. Das ist wie ein Lottospiel, wo man 1 Millionen einsetzen kann und beim Gewinn 5€ ausgezahlt bekommt. Davon sollte man die Fingerlassen.

Wenn also die Weigerung zu Schätzen ein Mittel ist, um diesen Vertrag nicht unterschreiben zu müssen, dann könnte man das dem Kunden auch direkt sagen. Also ist nicht das Schätzen das Problem, sonderen die Vertragsinhalte.

Guido Zockoll hat gesagt…


In welchem Vertrag steht drin, "Der Auftragnehmer liefert den im Lastenheft definierten Funktionsumfang mit einer Wahrscheinlichkeit von 87,5% zum Termin X ab und erhält dafür die Summe Y"?

Da stehen fixe Termine ohne Wahrscheinlichkeiten drin. Und wer die Termine überschreitet, der muss Strafe zahlen.

Ok, Vertragsstrafe potenziert das Pronblem von oben noch mal - ändert aber an der Argumentation nichts. Der Punkt ist, dass sehr früh im Prozess die Schätzbandbreite verschwindet und aus einer Schätzung eine Vorhersage wird.

Aber auch das wäre kein Problem, je nachdem, wie dann beim Verfehlen der Vorhersage umgegangen wird (Verlustrisiko). Mögliche Handlungsalternativen:
1. Der Schätzer wird entlassen. -> Zu hohes Risiko, nicht schätzen, genau wie Ralf es fordert
2. Der Kunde grummelt und zahlt knurrend den Mehrpreis -> kein Problem
3. Der Kunde grummelt und zahlt knurrend den Mehrpreis und man landet in der Bildzeitung (LKW Maut, Elbphilharmonie) -> langfristig auch kein Problem
4. Alle sind sich einig, dass nächste Mal die Wahrscheinlichkeiten mit im Vertrag auszuweisen -> die Utopie

Nur im ersten Fall ist das Schätzen das Problem.

Kommen wir nun zum Problem, warum aus einer Wahrscheinlichkeit irgendwann eine Vorhersage wird. Mir fallen auch hier mehrere Möglich Erklärungen ein:

1. Die Exceltabellen sehen dann immer so komisch aus.
2. Die meisten Menschen - selbst die, die gute waren in Mathe - haben in der Schule die Wahrscheinlichkeitsrechnung nicht verstanden.
3. Die Wahrscheinlichkeiten werden implizit mit bedacht.

Wahrscheinlich werde ich für Punkt 3 Widerspruch ernten, aber die Diskussion oben zeigt, dass das so ist. Niemand rechnet tatsächlich mit einer Punktlandung - vielmehr dreht sich die Diskussion doch darum, ob 5%, 20% oder 100% Überschreitung noch implizit ok sind. Verbunden mit einer vernünftigen Fehlerkultur (s.o.) halte ich eine Kombination aus 2. und 3. für den wahrscheinlichen Grund.

Guido Zockoll hat gesagt…


Dann sag doch offen: "Wir spielen alle ein Spiel. Das ist wie Poker. Es gewinnt, wer besser blufft."


Ahh, der Vergleich gefällt mir. Golf spiele ich nicht, aber Poker. Allerdings stimmt dein Vergleich nicht. Wenn wir uns weigern zu schätzen, dann zwingen wir den Kunden dazu "AllIn in the blind" zu gehen. Er muss alles setzen ohne sich seine Karten ansehen zu dürfen. Das ist beim Poker ein Move, der sehr selten gespielt wird. Meisten von Spielern, die eh schon praktisch alles Verloren haben.

Tatsächlich besteht Pokern aus einer Menge Schätzen. Am Anfang schätze ich mein Blatt ab, ob es sich überhaupt lohnt zu spielen ("7" "2" schmeiß ich weg). Dann wird die erste Iteraton gespielt, und ich schätze erneut, muss aber nun auch die möglichen Blätter der Gegener in Betracht ziehen (und muss meinen Gewinn mit höherer Trefferwahrscheinlichkeit abschätzen). Und so geht das dann über ein paar Iterationen.

Übertragen auf Softwareprojekte heißt das: Ansteigende Festpreise für einzelne Phasen.

Bleibt noch das Problem mit dem Bluffen. Poker ist kein kooperatives Spiel, es geht letztendlich darum, um sich auf Kosten des anderen zu bereichern. Für ein Kooperatives Spiel müssen wir das Element des Bluffs entfernen - das heißt mit offenen Karten spielen.

Zum Abschluss noch etwas Selbstkritik: Vielleicht ist es für uns Softwareentwickler ja auch ganz gut, wenn die Wahrscheinlichkeiten irgendwann verschwinden.

Beispiel: Der Kunde/Manager möchte eine Schätzung für XY. Softwareentwickler:

Wenn wir es so wie immer machen: 100PT, -20/+40
Wenn wir es mit dem neuen SOA/ESB Gedöns machen: 90PT, -10/+200

Was wird der Kunde wählen? Womit wir bei meiner These sind, das neue Tool, Techniken immer Chance und Risiko zugleich sind.

Halten wir also fest: Der Kunde hat ein Recht darauf, sein Blatt zu sehen, und dann sollte man sich phasenweise bis zum Ziel arbeiten, dabei neu schätzen und der Kunde darf auch irgendwann sein Blatt wegwerfen.

Thomas T. hat gesagt…

Also mir spricht der der Post ebenfalls aus der der Seele. Mein Hauptproblem mit Schätzungungen (die von eigentlich allen Kunden als seriöse Berechnung interpretiert werden) ist der verschobene Fokus der Entwickler:
Wenn sich der Aufwand dem geschätzten Maximum nähert, geht es plötzlich nicht mehr primär darum dem Kunden Mehrwert zu liefern, sondern darum das - mehr oder weniger zufällig bestimmte - Maximum nicht zu überschreiten.
Denn selbst wenn der Kunde das Budget hat, besteht er meistens auf die Einhaltung des (zufällig)geschätzten Maximums (weil bereits damit gerechnet wurde).
Weil alle versuchen innerhalb des geschätzten Rahmens zu bleiben erhält der Kunde also nur eine suboptimiale Lösung.

Hans hat gesagt…

@Ralf: Sorry jetzt wirst Du teilweise unsachlich und drehst meine Argumente so wie sie Dir gerade in den Kram passen. Ich suche weder in der BWL Trost, noch leidet meine Firma unter schlechten Schätzungen. Und was hat der Media Markt mit Softwareentwicklung zu tun.

Dass der Auftraggeber nicht die Kosten sondern nur sein Budget bestimmen kann, liegt so klar auf der Hand, dass man es nicht erwähnen muss. Genau deshalb sucht er sich einen Fachmann, der das kann.

Du behauptest aber, so einen gibt es nicht, da man im Vorraus den Kosten-/Zeitrahmen einfach nicht bestimmen kann. Wie soll man aber bitte schön abschätzen, ob es überhaupt Sinn macht ein Projekt anzugehen? Bei Deinen Ausführungen sehe ich nur eine Lösung. Eine Münze werfen: Aber wir Softwareentwickler wählen Kopf oder Zahl, um den Prozess selbst zu bestimmen.

Ach so Deiner Aussage: Besser die Hand heben und zugeben, "Ich habe keine andere Wahl." Das (!) wäre ehrlich.
Genau das habe ich in einem meiner Kommentar geschrieben. Viele sind in dieser Situation. Nicht nur Softwareentwickler. Sie nehmen jede Arbeit zu jedem Preis an. Da wird halt eine Situation widernatürlich "schön geschätzt". Viele sind weiter als Du. Sie schätzen nämlich nicht mehr, weil sie es sich nicht leisten können. Der Auftrag/die Arbeit muss her, koste es was es wolle. Das ist kein Problem des Schätzens sondern ein Problem der Sachzwänge. Schöne Worte gegen das Schätzen machen nicht satt.

JakeJBlues hat gesagt…

Hallo Ralf,

wenn ich den von Carsten vorgestellten Dialog als Basis nehme ->
Ralf: Du weißt, dass wir um 19.00h zum Essen eingeladen sind. Wir müssen dann gleich los.

Sie: Super. Ich mach mir nur rasch die Haare

Ralf: Wie lange dauert den das?

Sie: So ca. 10 Minuten

Ralf: Bullshit. Ich weiß, dass Du Haare fönen definitiv nicht schätzen kannst. Ich erwarte minütliches Feedback!


und Deine Antwort aufmerksam lese ->

Ein lustiger Dialog - aber ein irrealer und unnötiger. Denn "Haare föhnen" ist definitiv eine Sache, die meine Frau aus dem Effeff beherrscht. Sie weiß, wie lange das dauert. Da muss sie nicht mal schätzen.

Könnte man zu folgendem Schluß kommen ->
Software-Entwickler mögen dass Schätzen nicht, weil Sie "Ihre Sache" nicht aus dem Effeff beherrschen und daher nicht wissen, wie lange es dauert!

Gruß JJR

Golo Roden hat gesagt…

Irgendwie verstehe ich das Problem nicht so ganz: Schätzen ist doch - wie auch irgendwo in dem Blogeintrag oder einem der vielen Kommentare schon erwähnt - nur dann ungenau und unsicher, wenn man keine Erfahrung hat, wenn man das Thema eben nicht aus dem Eff-Eff beherrscht.

Angenommen, ich habe bislang mittelgroße Webanwendungen auf Basis von C#, ASP.NET und SQL Server gebaut, und nun kommt ein Kunde und will eine ganz große verteilte Desktop-Lösung mit VB, WPF, WCF und Oracle und braucht dafür eine Schätzung.

Natürlich kann ich das nicht vernünftig schätzen, weil das für mich alles unbekannte Technologien sind.

Aber die Frage, wie ich das dann besser schätzen oder sonstwie bewerten kann, ist doch eigentlich falsch gestellt. Zuerst sollte man sich doch fragen: Will man ein Projekt mit dermaßen vielen Unbekannten überhaupt haben?

Wenn in jedem Projekt immer nur ein bisschen Unbekanntes drinsteckt, lässt es sich ganz passabel schätzen. Und wenn eine unbekannte Technologie drin ist - solange ich die anderen sieben beherrsche, who cares?

Dann habe ich aber auch kein Problem, mit einer einigermaßen vernünftigen Schätzung.

Und wenn das Unbekannte überwiegt?

Dann sollte ich mir erst mal überlegen, ob ich das Projekt überhaupt haben will.

"Schuster bleib bei Deinem Leisten", heißt es so schön ... man kann nun mal nicht auf allen Hochzeiten tanzen, und wirklich ehrlich wäre es dem Kunden gegenüber, ihm in einem solchen Fall zu sagen: "Das können wir nicht schätzen, weil wir mit XYZ keine Erfahrung haben", als das Schätzen zu verdammen.

Oder?

gernstl hat gesagt…

Könnte man zu folgendem Schluß kommen ->
Software-Entwickler mögen dass Schätzen nicht, weil Sie "Ihre Sache" nicht aus dem Effeff beherrschen und daher nicht wissen, wie lange es dauert


Ja, das kann man wenn man so eine trivial Sache wie Haareföhnen 1:1 mit so komplexen Dingen wie einem mehrmonatigem Softwareprojekt vergleicht. Bei wem die Welt aber nur aus schwarz und weiß besteht hat noch mehr nicht verstanden

Hans hat gesagt…

@Golo,

den Nagel auf den Kopf getroffen. Danke.

Ralf Westphal - One Man Think Tank hat gesagt…

@JakeJBlues: Du sagst: "Könnte man zu folgendem Schluß kommen ->
Software-Entwickler mögen dass Schätzen nicht, weil Sie "Ihre Sache" nicht aus dem Effeff beherrschen und daher nicht wissen, wie lange es dauert!"

Damit triffst du den Nagel auf den Kopf.

Wir Softwareentwickler beherrschen unsere Sache nicht. Aber nicht, weil wir zu dumm sind, sondern weil sich "die Sache" nicht beherrschen lässt. "Die Sache" ist Kreativität.

Kreativität ist unbeherrschbar und unbefehlbar.

Einen Picasso zu reproduzieren, ist beherrschbar. Wie lange das dauert und wie teuer das ist, muss ich nicht mal schätzen, wenn ich vom Fach bin. Dann weiß ich, wieviel eine gute Fotografie davon kostet und wieviel ein guter Druck.

Einen Picasso aber zu malen, ihn zu entwickeln - denn einem Gemälde in seiner Endform gehen meistens viele Skizzen und Versuche voraus -, das (!) ist unabschätzbar. "Wie lange brauchen Sie für das nächste Gemälde, Herr Picasso?" Die Frage ist Picasso nie gestellt worden. Garantiert. Oder wenn, dann hat er laut gelacht.

Softwareentwicklung ist Entwicklung. Und zur Definition von Entwicklung gehört Unabschätzbarkeit. Das und nicht mehr ist mein Punkt.

Wer von einer Entwicklungsabteilung einen neuen Mixer haben will, der fragt nicht, "Wann habt ihr den neuen Mixer entwickelt?"

Möglich ist es jedoch, der Entwicklungsabteilung einen Zeitrahmen zu geben: "In 3 Monaten will ich einen neuen Mixer!" Dann ist allen jedoch klar, dass der neue Mixer keine vorher bestimmbaren neuen Features enthalten wird, sondern nur das an ihm neu sein wird, was in 3 Monaten machbar ist, was in 3 Monaten "erfunden" werden konnte.

Warum ist Softwareentwicklung so ein unabschätzbarer Prozess? Das liegt an der Kreativität zum einen. Zum anderen aber auch an den ewigen Neuerungen und vor allem an der Ungenauigkeit der Anforderungen.

Ralf Westphal - One Man Think Tank hat gesagt…

@Golo: Schön gesagt: "Schuster, bleib bei deinen Leisten"

So wahr das ist, hilft es aber kaum.

1. Wie in den Kommentaren schon gesagt, fühlen sich viele Entwickler/Teams gezwungen, sich mit anderen Leisten zu beschäftigen. Sie müssen ja Geld verdienen und können nicht immer ihre ASP.NET+IIS+SQL Server Schiene fahren. Sie müssen dann einfach, um zu überleben, den WinForms+WCF+Oracle Auftrag versuchen zu bekommen.

Ob das wirklich nötig ist oder wie dieses Gefühl von Zwang verändert werden könnte, darüber können wir ein andermal plaudern. Ich meine, die Branche könnte sich insgesamt anders organisieren, so dass die Schuster mehr bei ihren Leisten bleiben könnten - aber das ist für viele eben de facto nicht der Fall.

2. Die Schuster leiden oft an ungenügender Selbstwahrnehmung oder Einschätzungsfähigkeit. Du schreibst "Wenn in jedem Projekt immer nur ein bisschen Unbekanntes drinsteckt, lässt es sich ganz passabel schätzen. Und wenn eine unbekannte Technologie drin ist - solange ich die anderen sieben beherrsche, who cares?" und eigentlich könnte ich da nicken - wenn es nicht so schwer wäre einzuschätzen (ha! schon wieder schätzen), ob nur "ein bisschen Unbekanntes drinsteckt."

Aus meiner Sicht leidet die Branche an chronischer Selbstüberschätzung. Das hat u.a. mit ihrer Ausbildung zu tun.

3. Wir leben in einer Kultur, in der Unwissenheit keine gute Figur macht. Sich bzw dem Vorgesetzten eingestehen, dass man etwas nicht weiß (also mehr als ein bisschen Unbekanntes dabei ist), kommt nicht gut.

Und wenn man das tut... dann sagt der Chef, "Ach, was, das kriegst du hin. Schätze mal, schlag was drauf."

4. Das größte Problem ist aber, dass die Schätzung ja nicht nur von den beteiligten Technologien abhängt. Sie hängt von den Anforderungen ab. Und die (!) sind schwammig, unvollständig.

Golo, du als Scrum-Verfechter musst das doch mit der Muttermilch eingesogen haben: Ein Commitment über einen Sprint hinaus ist unseriös. Und selbst den Sprint kriegt man nicht immer hin, selbst bei tollster Velocity-Kenntnis.

Scrum hat Sprints ja nicht zum Spaß. Die sind nicht da drin, weil man dem Kunden mal öfter einfach ein kleines "Geschenk" machen will. Sondern sie sind drin, weil man anders nicht weiß, ob man das Richtige macht. Und damit weiß man anders nicht, ob überhaupt das rauskommt, was der Kunde mit seinem fixen Budget bezahlen will.

Eine Garantie, dass nach 17 Sprints die Anforderungen abgearbeitet sind, gibt Scrum selbstverständlich und ganz bewusst nicht.

So verstehe ich denn nicht, dass du noch daran glauben kannst, dass Schätzungen machbar oder auch nur wünschenswert seien, wenn denn irgendwie das Unbekannte minimal ist.

Hans hat gesagt…

@Ralf,

Du bist also ernsthaft der Meinung, weil es bei der Softwareentwicklung soviele Unwägbarkeiten gibt (vier hast Du in Deiner Antwort auf Golos Beitrag genannt), lassen wir in Zukunft eine Projektplanung mit einer Bestimmung des zu erwartenden Kosten- und Zeitaufwandes gehört weg? Es macht ja sowieso keinen Sinn allzu weit in die Zukunft zu planen. Es ändert sich sowieso alles, die Anforderungen, die Technologie, die Mitarbeiter...

Wenn Du Softwareentwicklung dann noch mit dem Erzeugen moderner Kunst vergleichst, sind wir schon ziemlich weit auseinander. Ich dachte bisher, Softwareentwicklung wäre ein zielgerichter Prozess.

Naja. Wir können in Zukunft dann gemeinsam vor einer Applikation stehen, die Stirn in Falten legen und und uns fragen: Was will uns der Entwickler damit sagen. Und es werden wieder einige von ihren Elfenbeintürmen steigen und werden es uns erkären.

Ralf Westphal - One Man Think Tank hat gesagt…

@Hans: "Was will uns der Entwickler damit sagen?" ist eine Frage, die ich mir in meiner Berater- und Trainerpraxis ständig stelle. Klassen mit 100.000 Zeilen, Methoden mit 18.000 Zeilen... sag du mir, was Entwickler damit sagen wollen.

Deine Frage ist richtig gestellt. Die Frage muss gestellt werden. Und wir müssen dann auf die Antwort lauschen. Lauschen, weil sie so leise sein wird. Der Entwickler wird nämlich kaum je etwas Substanzielles dazu sagen - außer, dass er sich redlich bemüht hat und es doch auch irgendwie läuft.

Ist das genug? Hätte er uns dafür vorher sagen können, wie lange er für das Ergebnis brauchen wird? Kaum. Jedenfalls nicht, wenn die Aufgabe nicht trivial ist.

Bisher bist du leider schuldig geblieben, wenn ich es recht überblicke, meiner Kritik etwas an Alternative entgegen zu setzen. Du bist mit einem Weglassen von Aufwandsschätzungen unzufrieden. Das verstehe ich. Eine liebgewonnene Praxis gibt man ungern auf. Da unterscheidet sich die Softwareentwicklung nicht von den Ärzten des Mittelalters, die ungern den Aderlass aufgegeben haben.

Gab es für Aderlass nachweisbare, vorhersehbar wiederholbare Vorteile in der Größenordnung, wie er betrieben wurde? Nein.

Gibt es für Schätzungen nicht trivialer Software nachweisbare, vorhersehbar wiederholbare Fälle des Erfolges (eine Marge von 10% finde ich ok)? Nein.

Oder wenn doch, dann bitte ich um Auskunft. Zeig mir die Firma, die Software regelmäßig zum Festpreis abliefert, ohne dass es zu Nachverhandlungen oder Nachtschichten oder Einbußen kommt.

Denn sonst sage ich auf deine Frage, "lassen wir in Zukunft eine Projektplanung mit einer Bestimmung des zu erwartenden Kosten- und Zeitaufwandes gehört weg?" ganz einfach: Ja. Lassen wir sie weg.

Nichts steht natürlich einer ganz groben Größenordnungseinschätzung im Wege. Dauert es eher wenige Monate, ein Jahr oder mehrere Jahre, um die Anforderungen zu erfüllen? Dazu kann man natürlich etwas sagen. Auf dem Niveau sind Anwendungen noch vergleichbar.

Aber eine Schätzmarge von 10% halte ich für nicht systematisch erreichbar. Und die meisten Kommentare zu meinem Posting unterstützen mich darin.

(Ich habe die Softwareentwicklung übrigens nicht nur mit Picasso verglichen, sondern auch mit der Entwicklung von consumer products. Dazu hast du keinen Einwand gebracht.)

Wenn der Mensch nicht fliegen kann (s. Ikarus), wenn Eiter die Wundheilung nicht befördert und man ihn daher nicht verstärken sollte, wenn Aderlass nicht hilft, wenn Bonuszahlungen (außer in wenigen, klar umrissenen Fällen) nichts bringen... dann muss man es nicht länger versuchen auf Biegen und Brechen. Dann muss die Realität anerkennen und etwas anderes versuchen, um das Resultat zu erhalten (Fliegen, Gesundheit, mehr Kreativität).

Heiko Dietz hat gesagt…

Allein die Aussage "Das kann ich nicht abschätzen" dokumentiert doch nur die Unkenntnis über die zu bewältigende Aufgabe. Nun kann man sich fragen, wo kommt das her? Ist die Aufgabe nicht hinreichend beschrieben oder sind Anforderungen unklar oder beherrschst derjenige der Schätzen soll einfach sein Handwerk nicht?

Bei unklaren Anforderungen kann ich aber Annahmen treffen und diese neben der Schätzung dokumentieren um zu einem Ergebnis zu kommen. Für den Fall das der Auftragnehmer sein Handwerk nicht beherrscht gibt es doch noch die Variante, den Auftragnehmer gegen jemanden auszutauschen, der in der Lage ist robuste Aussagen über Termine und Kosten zu machen.

Wenn ich deinen Post lese schreibst du, du kann nicht schätzen weil:

- du Technologien einsetzen muss weil die du nicht ausreichend kennt.

-du das Team nicht ausreichend kennst.

- du den Kunden und die Fachlichkeit nicht verstehst.

Meiner Meinung nach trennt sich gerade in der Frage des Schätzens einfach die Spreu vom Weizen. Die Weigerung zu Schätzen ist nichts weiter als die Kapitulation vor messbaren Erfolgskriterien für ein Projekt. Wenn ich schätze und das dokumentiere mache ich mich und meine Skills natürlich bewertbar. Das viele Dienstleister dies vermeiden wollen, ist aus vielen Gründen klar.

Nebenbei sind die Beispiele, die du nennst, wo Schätzungen schief gelaufen sind in keinster Weise nachvollziehbar. Weder du noch ich kennt die wirklichen Hintergründe der Schätzung der Elbphilharmonie. Hast du schon mal den Begriff des "strategischen" bzw. "politischen" Preises gehört? Ich denke schon.

Meiner Meinung nach sollte man einfach den Dienstleister oder das Team wechseln, wen dieses nicht in der Lage ist die gestellte Aufgabe abzuschätzen. Warum soll ich Amateure beauftragen, wenn ich auch Profis kriegen kann?

Hans hat gesagt…

@Ralf,

>> Klassen mit 100.000 Zeilen, Methoden mit 18.000 Zeilen... sag du mir, was Entwickler damit sagen wollen.
Ich sage es nocheinmal: Dies ist keine Schwäche der Projektplanung. Das hat mit schlechten Entwicklern zu tun. Mit solchen Entwicklern fängt man kein Projekt an. Punkt.

>> meiner Kritik etwas an Alternative entgegen zu setzen.
Welche Alternative denn. Es gibt keine Alternative zur Projektplanung mit Kostenbestimmung. (Ich verwende bewusst das Wort Schätzen nicht mehr, weil man schätzen soweit wie möglich vermeiden sollte. Damit hast Du schon recht. Für Dich ist aber leider Planen gleich Schätzen)

>> Zeig mir die Firma, die Software regelmäßig zum Festpreis abliefert, ohne dass es zu Nachverhandlungen oder Nachtschichten oder Einbußen kommt.
Sagen wirs mal anders herum: Eine Firma, die Software zum Festpreis abliefert, wobei es regelmäßig zu Nachverhandlungen oder Nachtschichten oder Einbußen kommt, sollte die Branche oder den Berater wechseln.

Da sitzen wahrscheinlich Leute die ihr Handwerk (ich schreibe Handwerk und nicht Kunst) nicht beherrschen, sich überschätzen oder den Hals nicht voll genug bekommen. Lass uns doch die abschaffen.

>> "lassen wir in Zukunft eine Projektplanung mit einer Bestimmung des zu erwartenden Kosten- und Zeitaufwandes gehört weg?"
Welches ist die Alternative, die gewährleistet, dass hinten das rauskommt, was der Kunde will oder (noch besser) braucht, was ihm hilft? Nur weil vorheriges Nachdenken manchmal nicht zum Ziel führt, muss man doch nicht gleich die Anarchie herbeirufen.

>> Aber eine Schätzmarge von 10% halte ich für nicht systematisch erreichbar. Und die meisten Kommentare zu meinem Posting unterstützen mich darin.
Bitte? Hast Du die Kommentare gelesen? Vielleicht meint das die Hälfte, aber die meisten sagen, dass es ohne Planung mit einem Betrag am Ende nicht geht.

>> Wenn der Mensch nicht fliegen kann (s. Ikarus), wenn Eiter die Wundheilung nicht befördert und man ihn daher nicht verstärken sollte, ... dann muss man es nicht länger versuchen auf Biegen und Brechen.
Deshalb haben wir Flugzeuge und Penicillin erfunden ohne dabei das Fliegen und die Wundheilung abzuschaffen. Und gerade bei der Fliegerei verwenden alle Wettervorhersagen, die alles andere als zuverlässig sind. Trotzdem ohne geht es nicht, das wäre grob fahrlässig darauf zu verzichten.

Sorry, dass Du jetzt keine Antwort auf Deinen Vergleich mit den consumer products bekommst. Ich habe nicht die Stelle parat, wo Du ihn gemacht hast und möchte jetzt auch nicht nochmal alle Kommentare lesen.

@Heiko: Absolute Zustimmung, es wäre aberschön, wenn Du das Wort Schätzen durch Planung ersetzen würdst. Denn das meinst Du wohl auch.

Golo Roden hat gesagt…

Hallo Ralf,

zu Deinen Argumenten:

1) ist für mich keins. Denn das Problem ist hier ein anderes als die Schätzung. Statt zu sagen, wir lassen das Schätzen sein, weil Teams es sich halt nicht leisten können, "Schuster bleib bei Deinem Leisten" zu sagen, greift zu kurz. Das bekämpft ein Symptom, aber nicht die Ursache. Denn könnten sie es sagen, könnten sie auch vernünftig schätzen. Dass sie es nicht sagen können - nun das hat wohl andere Ursachen, die primär zu bekämpfen wären.

2) fällt für mich in den gleichen Topf. Auch Selbstüberschätzung ist eher ein Problem bezüglich dessen, was man als Auftrag annimmt, als ein grundlegendes Problem der Schätzung. Denn: Wer sich richtig einschätzen kann, der weiß auch, was er annehmen kann und was nicht.

3) teile ich nur bedingt. Ja, vordergründig hört sich das plausibel an, dass wir in einer Kultur leben, in der Unwissenheit keine gute Figur macht. Mal abgesehen davon, dass ich das so pauschal nicht bestätigen würde (es gibt so dermaßen viele Leute, die einem mit Verständnis begegnen, wenn man offen und ehrlich Unwissen oder einen Fehler zugibt) ist auch das kein Argument per se gegen das Schätzen. Denn auch hier geht es um anderes als um das Schätzen an sich.

4) stimmt: Die Schätzung hängt nicht nur von den Technologien ab, sondern auch von vielem anderem. Wie Du schon selbst schreibst, gibt Scrum keine Garantie, dass nach so und so viel Sprints die und die Funktionalität umgesetzt ist. Scrum gibt höchstens eine zu 99,9% zutreffende Einschätzung, dass in soundsoviel Sprints soundsoviele Storypoints umgesetzt werden - was sich hinter diesen Storypoints verbirgt, steht auf einem anderen Blatt.

Aber dieses Nahezu-Versprechen kann ich in Scrum guten Gewissens abgeben, wenn ich ein stetiges Team habe, das schon eine gewisse Historie mit sich bringt. Menschen verschätzen sich nämlich in der Regel nicht mal um das fünffache nach oben und mal um das dreifache nach unten - sondern die Tendenz ist immer die gleiche. Vielleicht geht es mal um den Faktor 3,7 daneben und mal um 4,1 - aber irgendwo um 4,0 wird es sich einpendeln. Das ist natürlich von Individuum zu Individuum verschieden - aber die Tendenz gilt: Menschen verschätzen sich ungefähr immer gleich stark. Nehme ich also diese Fehlerquoten von bisherigen Schätzungen als Basis für zukünftige, kann ich eine ganz gute Voraussage treffen - unbekannte Technologien hin oder her.

Was ich übrigens für griffiger als die Storypoints von Scrum halte, ist Evidence Based Scheduling, siehe http://www.joelonsoftware.com/items/2007/10/26.html

Das macht nämlich genau das - und im Lauf der Zeit hast Du da auch Unwägbarkeiten wie Krankheit, Urlaub, unerwartete Fehlersuche & Co abgedeckt ... mein Punkt an der Stelle ist: Die Anforderungen weichen von der idealen Anforderung auch nicht mal so, mal so stark ab - auch das bewegt sich in einem gewissen Rahmen. Misst man also lang genug, wird sich das auch in zukünftigen Prognosen wiederspiegeln.

Was hältst Du von dem System?

Ralf Westphal - One Man Think Tank hat gesagt…

@Heiko: Ich kann dir nur zustimmen:

"Bei unklaren Anforderungen kann ich aber Annahmen treffen und diese neben der Schätzung dokumentieren um zu einem Ergebnis zu kommen. Für den Fall das der Auftragnehmer sein Handwerk nicht beherrscht gibt es doch noch die Variante, den Auftragnehmer gegen jemanden auszutauschen, der in der Lage ist robuste Aussagen über Termine und Kosten zu machen."

So ist das. Aber in all den Jahrzehnten hat es den Kunden keiner beigebracht, sie wesentlich klarer über ihre Anforderungen zu werden. Das höre ich jeden Tag bei Beratungen und Trainings. "Keine Ahnung, wie das genau aussehen soll. Fangt doch schonmal an." So schallt es den Entwicklern entgegen. Da hilft auch kein Austauschen der Entwickler. Der Kunde bleibt derselbe.

Und die Entwickler... eine ganze Branche dumm? Schade. Wir müssen leider mit denen leben, die wir haben.

Aber ich bezweifle ja, dass man wirklich ein unmögliches Handwerk beherrschen kann, das der Schätzung.

Planung soll es nun heißen... auch gut. Natürlich bin ich für Planung. Meine Message in diesem Blog und anderswo ist: "Leute, denkt mehr nach, plant mehr. Schluss mit dem Cowboy-Programmieren."

Aber nicht nur will Planen gelernt sein. Es muss auch der Kontext hergeben, dass das Nachdenken einen Sinn hat. Wenn sich James Bond ohne Fallschirm aus einem Flugzeug stürzt, hat er keine Zeit zum Nachdenken. Wenn Giuliani das Chaos nach 9/11 in den Griff kriegt, dann nicht durch Nachdenken.

In komplexen oder "schnellen" Situationen nützt Nachdenken nix. Und Softwareentwicklung ist eine komplexe Situation, die sich ständig wandelt an vielen Fronten.

Deshalb muss man schauen, wo Planung etwas bringt. Bei der "Berechnung" des Gesamtaufwands für eine neue Warenwirtschaft jedenfalls nix. Wie lang es dauert, einen bestimmten Scope zu realisieren, ist schlicht nicht berechenbar.

Bottom line: Man zeige mir die funktionierende, systematisch vermittelbare Methode zur Planung des Aufwands für nicht triviale Software vor Beginn der Entwicklungsarbeit. Ich bin ganz gespannt.

Golo Roden hat gesagt…

PS: Das größte Problem sehe ich aber darin, dass man dem Kunden wohlgemerkt vor Projektbeginn eine Hausnummer nennen muss, wie teuer das Projekt wird, wie lange es dauern wird, ob es mit dem vorhandenen Budget umsetzbar ist, ... und dazu muss ich nun mal schätzen, schlichtweg, weil ich kein anderes Werkzeug habe.

Wie würdest Du einem Kunden begegnen, der Dir sagt, ich brauche XYZ bis dann und dann und ich kann so und so viel ausgeben?

Was sagst Du ihm?

Wenn Du mir darauf eine Antwort geben kannst, die meine Kunden akzeptieren, dann bin ich gerne bereit, das Schätzen wegzulassen ;-).

So lange ich eine solche Antwort nicht als Alternative habe, muss ich notgedrungen schätzen, wenn ich Aufträge haben will.

Heiko Dietz hat gesagt…

@Ralf:
Was du schreibst deckt sich nicht unbedingt mit meiner Erfahrung im Umgang mit Kunden und Entwicklern. Man kann Kunden deutlich machen, das Sie ihre Anforderungen klar formulieren. Nur benötigt man dazu eben auch einen großen Satz an Fähigkeiten, die Entwickler üblicherweise nicht mitbringen. Hier sind im Team andere Leute gefragt und zwar die, die in der Lage sind ein entsprechendes Anforderungsmanagement zu machen. Du hast schon ein massives Problem in deinem Team, wenn jeder Entwickler mit dem Kunden redet. Gute Entwickler sind nicht unbedingt gut in Kommunikation, Kundenbeziehungsmanagement und Projektmanagement. Ich halte die Regelung "One face to the customer." für viel zielführender.

Ich kenne Entwickler, denen stelle ich eine Aufgabe vor und die machen recht schnell sehr genaue Aussagen, wie lange sie für die Aufgabe brauchen. Diese Kollegen liegen seltenst daneben. Dann kenn ich einen zweiten Teil von Entwicklern, die verhauen sich bei einfachen Aufgaben bei Schätzungen um mehrere 100%. Diese Leute liegen eigentlich immer falsch. Die sagen auch immer: "Kann ich nicht abschätzen, muss ich erstmal gemacht haben."

Natürlich ist es so, das bei echten Forschungs- und Entwicklungsprojekten eine Abschätzung unmöglich wird. Aber bei einem Großteil der Feld, Wald und Wiesenprojekte wo eh ein Großteil aus trivialen Anforderungen (z.B. simplen CRUDS) sollte man auch gut abschätzen können.

Es hindert dich ja auch erstmal keiner daran, bei deiner Abschätzung Ranges anzugeben und verschiedene Bereiche der Anforderungen auch mit unterschiedlichen Ranges zu versehen. Wenn du eine Anforderungsdokumentation vorliegen hast, kannst du doch gern an den Kunden kommunizieren welche Anforderungen klar abschätzbar sind und bei welchen Anforderungen du echte Probleme mit der Abschätzung hast. Hier wird dann plötzlich der Vorgang der Abschätzung zu einem Tool des Risikomanagements (Cool, oder?)

Nebenbei: Die Kunden, die Software in Auftrag geben müssen keine Experten sein um Anforderungen zu formulieren. Genau aus diesem Grund geben Sie eine Menge Geld für Dienstleister aus, um auch Unterstützung bei der Anforderungsanalyse zu bekommen. Und genau das muss als vorarbeit zur Planung auch gewissenhaft erfolgen. Eine saubere Anforderungsanalyse durch den Dienstleister! Ggf. startet ihr eine weitere gute Initiative neben "Clean Code", nämlich die des "Clean Requirement". Das würde sicher schon einige Probleme im Vorfeld ausräumen.

Noch eine Note am Rande: Das wirkliche Problem liegt doch ganz woanders. Die wirkliche Diskrepanz liegt z.B. bei IT Dienstleistern doch zwischen Vertrieb und Entwicklung. Der Vertriebler kriegt sein Geld und seine Erfolgsbeteiligung, wenn er das Projekt an den Kunden bringt. Das einfachste Argument im Vertriebsprozess ist ein niedriger Preis. Nachdem dann die Tinte unter dem Werkvertrag trocken ist, wird das ganze Thema in die Entwicklung gekippt, die dann versuchen müssen damit fertig zu werden. Wahrscheinlich sind bei dem Abstimmungsprozess zwischen Vertrieb und Entwicklung auch geschätzte Zahlen noch nach unten "korrigiert" worden. Die abschließende Projektbewertung zeigt dann, das die geschätzten Zahlen nicht gehalten wurden. Man muss halt nur genug Druck auf die Entwicklung machen, und die Zahlen gehen immer nach unten.

Heiko Dietz hat gesagt…
Dieser Kommentar wurde vom Autor entfernt.
Der Plapperkäfer von Traal hat gesagt…

Hallo,

ein Arbeitskollege hat mich auf den sehr interessanten Artikel aufmerksam gemacht, der auch mir als Entwickler in weiten teilen aus der Seele spricht. Ausgenommen die Schlussfolgerung!

Wenn der Kunde gesagt bekommt "keine Ahnung wie lange das dauert und wie viel das kostet", wird er sich im besten Fall für das Gespräch bedanken und nie wieder von sich hören lassen,
Oft besteht ja das Projekt nicht nur aus Software, sondern er werden mehrere Komponenten (Elektronik, Mechanik, Gehäuse, ...) von mehreren Herstellern gefertigt. Wenn jeder irgendwann mal liefert, und eine Rechnung in beliebiger Höhe stellt, wie soll der Auftraggeber damit bitte zurecht kommen?

Schätzen ist nicht immer möglich, grundsätzlich unpräzise (anhängig von den bereits genannten Einflussfaktoren wie neue Technologie, unklare Anforderungen etc.).
Eine Schätzung grundlegend zu verweigern ist aber schlichtweg dumm. Die Konkurrenz wird ein Angebot abgeben, und den Zuschlag erhalten.

Völlig unrealistisch ist es, das Projekt in der Mitte abzubrechen, wenn es aus dem Budget läuft. Während ich ein Haus zur Not von einem fähigeren Bautrupp fertigstellen lassen kann, ist das bei halbfertiger Software oft kaum sinnvoll machbar.

Mir ist bei jeder Schätzung bewusst, dass sie zu Beginn des Projekts typischerweise um -50/+100% daneben liegt. Dennoch ist diese ungenaue Zahl sinnvoll:

1. ich weiß, dass das auf 100 Personentage geschätzte Projekt zwischen 50 und 200 PT dauern und entsprechend Kosten verursachen wird. Das ist schon mal besser, als irgendwann festzustellen, dass es 1000 PT geworden sind!

Der Plapperkäfer von Traal hat gesagt…

Bei einem "richtigen" Unternehmen sieht das ganz anders aus. Hier gibt es eine Belegschaft, die konstant bezahlt werden muss, auch wenn sie nichts zu tun hat (bzw. hätte!) und nur sehr träge auf- und abgebaut werden kann. Um Gewinn zu erwirtschaften, muss diese Belegschaft mit Arbeit versorgt werden.

Im Gegensatz zum Einzelkämpfer werden mehrere Projekte parallel getrieben. Das bietet den Vorteil, dass sich Fehleinschätzungen ausmitteln, und Kapazitäten ggf. umverteilt werden kommen, um Termine zu halten. Die Entwicklungskosten sind hier nicht das Problem, da die Belegschaft ohnehin bezahlt werden muss, egal woran sie arbeitet.

Voraussetzung, dass das funktioniert, ist natürlich, dass der Vertrieb nicht so naiv ist, die Schätzungen der eigenen Entwickler regelmäßig zusammenzustreichen, und auf dieser Grundlage 1:1 anzubieten.

Sinn der Aufwandsschätzungen ist in meinen Augen hier in erster Linie die Möglichkeit der Kapazitätsplanung, und die ist für ein funktionierendes Unternehmen absolut unerlässlich.

@Ralf: sorry für die die vorherigen Doppelpotings. ich habe jedesmal eine Fehlermeldung erhalten, die Request sei zu groß, und nicht gesehen, dass die Texte dennoch angenommen wurden. Bitte einfach entfernen!

Ralf Westphal - One Man Think Tank hat gesagt…

@Golo: Wenn du schreibst, "Wie Du schon selbst schreibst, gibt Scrum keine Garantie, dass nach so und so viel Sprints die und die Funktionalität umgesetzt ist. Scrum gibt höchstens eine zu 99,9% zutreffende Einschätzung, dass in soundsoviel Sprints soundsoviele Storypoints umgesetzt werden - was sich hinter diesen Storypoints verbirgt, steht auf einem anderen Blatt." dann sagst du doch genau das, was ich auch sage.

Storypoints sind nicht up-front bekannt, wenn ein Auftrag unterzeichnet wird. Also kann Scrum überhaupt keine Aussage zum zeitlichen Gesamtaufwand sagen.

Storypoints helfen nur, eine angemessene Menge von Anforderungen für den nächsten (!) Sprint auszuwählen, damit sich das Team nicht übernimmt. That´s it.

Storypoints werden jedoch nicht auf Halde geschätzt. Also gibt es auch keine Voraussage über mehrere Sprints hinweg.

Evidence Based Scheduling ist in dieser Hinsicht nicht besser. Vor allem ist EBS kristallklar, dass Schätzungen nicht funktionieren, wenn Aufgaben größer als "Stundenhappen" sind. Da frage ich aber mal: Wenn du den Auftrag bekommst, eine Warenwirtschaft zu entwickeln oder einen online Shop, planst du dann soweit, dass du alles in Happen zerlegst, die ca. 16 Std groß sind, bevor du ein Angebot abgibst?

Nein, natürlich nicht. Das tut niemand. Das wäre auch BDUF. Denn dafür müsstest du die komplette Architektur und Modellierung gemacht haben.

Wo stehen wir also? Am Anfang. Meine Behauptung ist nicht widerlegt, sondern von dir sogar bestätigt. Danke.

Der zeitliche Aufwand für nicht triviale Softwareprojekte ist vor Arbeitsbeginn nicht berechenbar. Also müsste er geschätzt werden. Diese Schätzungen sind so unzuverlässig, dass man sie sein lassen kann.

Einziger Grund, warum man an den Schätzungen festhält: Irrationalität und Politik und Ratlosigkeit.

Ralf Westphal - One Man Think Tank hat gesagt…

@Golo: Was würde ich meinem Kunden sagen?

Die Rechte des Kunden
a. Du kannst das Budget festlegen, wie du magst.
b. Du kannst jederzeit aussteigen und hast volle Rechte am Code.
c. Du brauchst nichts zu bezahlen, wenn du in den ersten 3 Wochen aussteigst.
d. Du kannst jederzeit neue funktionale Anforderungen einbringen, ändern, streichen. Jeder Tag ist für dich Entscheidungstag.
e. Wenn die Entwicklung einige Zeit läuft, kannst du Fragen, ob wir auch mal ein Ablieferdatum für größere Anforderungshappen schätzen können. Vielleicht ist da was drin, weil das Team sich auf Problemdomäne, Technologien, Kollegen usw. eingeschwungen hat. In jedem Fall sind auch dann Schätzungen mit Vorsicht zu genießen. Sie befreien dich nicht davon, jeden Tag wieder zu bestimmen, was du am nächsten Tag haben willst.

Die Pflichten des Kunden
a. Du lieferst vorab die Anforderungen in solcher Form, dass ich vor allem die nicht-funktionalen Anforderungen herauslesen kann.
b. Du lieferst zu den Anforderungen eine Vorstellung von den Minimal Marketable Features der Anwendung, um die strategische Realisierungsreihenfolge grob planen zu können.
c. Du stellst einen ProductOwner zur Verfügung, der jeden Tag das aktuelle Release auf Anforderungskonformität prüft.
d. Du stellst einen ProductOwner zur Verfügung, der jeden Tag für Fragen des Teams da ist.
e. Der ProductOwner bespricht jede Woche seine aktuelle Anforderungsprioritätenliste vor allem der funktionalen Anforderungen mit dem Team. (Das obige Recht d. gilt weiterhin.)

Wieviel kostet dann die Entwicklung? Soviel wie der Kunde will.

Wie lange dauert die Entwicklung? Solange wie der Kunde will.

Was bekommt der Kunde für sein Geld? Soviel wie machbar ist.

Könnte er mehr bekommen, wenn er sich einen bestimmten Scope für einen fixen Zeitraum und ein fixes Budget wünschen würde? Nein.

Ralf Westphal - One Man Think Tank hat gesagt…

@Plapperkäfer: Ich verstehe den immer wieder geäußerten Wunsch nach verlässlicher Schätzung - was ja gleichzusetzen ist mit Berechnung.

Echt, ich verstehe das. Ich hege diesen Wunsch auch. Ach, die Welt wäre so schön, wäre Aufwandsberechnung vor Arbeitsbeginn möglich.

Leider ist die Welt nicht so. Da hilft auch kein Träumen. Da hilft auch Joel Spolsky nicht. Vor Beginn der Arbeit und ohne sehr detaillierte Vorstellung von den Tätigkeiten im Rahmen eines Entwicklungsprojektes, ist keine Berechnung möglich.

Nochmal: Wer Gegenteiliges weiß, der melde sich. Ich lerne gern die Methode, mit der ich 500 Seiten Anforderungsdokument nehmen und in eine Aufwandszahl transformieren kann.

Mit dem Function-Point-Verfahren hat man mal versucht, so eine Transformation hinzubekommen. In der Realität hat das letztlich sowenig zuverlässig funktioniert, dass es - wie wir alle sehen können in der täglichen Arbeit - keine Verbreitung gefunden hat.

Aus Anforderungen ohne Architektur und ohne Modell auf Imlpementierungsaufwand schließen zu wollen, halte ich auch für sehr gewagt. Wir reden ja nicht über Kochrezepte.

Bottom line: Ich verstehe allen Widerstand gegen die Aufgabe der Versuche zur Berechnung von Aufwand up-front.

Aber wenn mir denn hier keiner die Methode zeigen kann, mit der das geht (mit durchschnittlichen Teams), dann sollten wir vielleicht mal rauskommen aus der Trotzecke und versuchen, konstruktiv nach alternativen Verhaltensweisen zu suchen.

Am Ende ist es nämlich so: Unsere Kunden sind so, wie wir es zulassen. Und wenn wir aufstehen und uns unrealistischen Forderungen verweigern, dann werden sie sich anpassen.

Hans hat gesagt…

>> Glaubenssätze, auch wenn sie wieder und wieder zu Schmerzen führen, werden ungern aufgegeben. Davon weiß die Psychotherapie ein Lied zu singen.>>

Dieses Zitat aus einem Deiner neuesten Blogs macht ja eigentlich jede weitere Diskussion überflüssig: "Jeder der nicht an micht glaubt, ist ein Fall für den Psychotherapeuten."

>> Am Ende ist es nämlich so: Unsere Kunden sind so, wie wir es zulassen. Und wenn wir aufstehen und uns unrealistischen Forderungen verweigern, dann werden sie sich anpassen. >>

Ich antworte mit einem Deiner Sätze: "Leider ist die Welt nicht so. Da hilft auch kein Träumen." Es gibt nicht uns Softwareentwickler. Es gibt große und kleine, arme und reiche, gute und schlechte aber eines haben sie alle gemeinsam. Sie sind Konkurrenten. Was das heißt, wirst Du ja wohl wissen.

Was ich schon immer mal frage wollte: Was ist eigentlich für Dich ein triviales Projekt, das man noch planen kann? Faktura, Fibu, Warenwirtschaft, Steuerung eins AKW; 1 Mann-Monat, 1 Mann-Jahr, 5 Mann-Jahre; 1000, 10000, 100000, 1Mio. oder wie?

>> Wenn die Entwicklung einige Zeit läuft, kannst du Fragen, ob wir auch mal ein Ablieferdatum für größere Anforderungshappen schätzen können. Vielleicht ist da was drin, weil das Team sich auf Problemdomäne, Technologien, Kollegen usw. eingeschwungen hat. >>
Ah super, jetzt geht dann auf einmal schätzen. Um welche Happen geht es denn plötzlich? Was ist denn das für ein Blödsinn? Das heißt doch: Lieber Kunde, Du zahlst jetzt erstmal die Aufstellung und Ausbildung des Teams, danach darfst Du dann mal fragen, was das Projekt kostet. Ich glaube, ich sollte Dich mal einkaufen. Ich habe es bisher noch nicht hinbekommen, so einen Auftrag zu bekommen. Ich habe schon einmal gesagt: Mit einem neuen Team, neuer Technologie fange ich kein Projekt an. Aber man könnte ja die ersten 3 kostenlosen Wochen nutzen, damit sich das Team untereinander den ProductOwner, die Domäne und die Technolgien kennenlernt. So ein bisschen Kennenlern-Programmierung betreiben. Kostet den Entwickler(Unternehmer) ja nur so rund schlappe 100.000, wenn nur 10 Leute das Projekt beginnen. Allerdings kann doch Deiner Meinung nach 3 Wochen immer noch keiner wissen wo es lang geht. Soll der Auftraggeber dann würfeln, ob er weiter macht?

Übrigens: Deine Auflistung der Rechte und Pflichten ist ja nichts Neues oder? Fast alle diese Punkte kann ich unterschreiben. (Wenn b so zu verstehen ist, dass der Kunde den bis dahin entstandenen Aufwand auch bezahlt) Die Punkte haben aber alle nichts mit vorher planen oder nicht planen zu tun.

>> Wieviel kostet dann die Entwicklung? Soviel wie der Kunde will.
Wie lange dauert die Entwicklung? Solange wie der Kunde will.
Was bekommt der Kunde für sein Geld? Soviel wie machbar ist. >>
Stimmt. Nur als letzten Satz würde ich schreiben: Soviel wie bei all dem planlosen Herum-Geeiere machbar ist.

>> Könnte er mehr bekommen, wenn er sich einen bestimmten Scope für einen fixen Zeitraum und ein fixes Budget wünschen würde? Nein.
Vielleicht eine Software mit der er auch was anfangen kann.

Fortsetzung folgt gleich

Hans hat gesagt…

Fortsetzung

>> Aus Anforderungen ohne Architektur und ohne Modell auf Imlpementierungsaufwand schließen zu wollen, halte ich auch für sehr gewagt. >>
Stimmt, das gehört aber zur Planung. Erst dann geht Aufwandsabschätzung. Alles andere ist wirklich Kaffeesatz lesen. Und jetzt erzähle mir nicht, dass man sich um Architektur und Modell erst kümmert, wenn man schon so ein bisschen vor sich hinentwickelt hat.

>> dann sollten wir vielleicht mal rauskommen aus der Trotzecke
Gute Idee. Dabei hilft aber auch keine Polemik. Dein erstes Wort zu diesem Blog in Twitter. "Polemischer Angriff.."

>> Aber wenn mir denn hier keiner die Methode zeigen kann, mit der das geht (mit durchschnittlichen Teams),>>
Äh, heißt das, dass es mit guten Teams geht?

Morgen früh gehe ich zu meinem Therapeuten. Versprochen!

>> Ich verstehe allen Widerstand gegen die Aufgabe der Versuche zur Berechnung von Aufwand up-front.
Ich verstehe ja auch Deinen Frust mit Aufwandsabschätzungen. Kommst Du auch morgen früh?

Ralf Westphal - One Man Think Tank hat gesagt…

@Hans: Ich komme morgen früh nicht, weil ich nicht mehr schätze. Versprochen.

Triviales Projekt? Hm... Vielleicht eines, dass am Ende 5 Tage Aufwand hat. Aber vielleicht noch nicht mal das. Denn wenn du bei 5 Tagen zufällig nur einen Tag länger brauchst, dann hast du schon um 20% überzogen.

Ich wusste, dass mir einer das Abschätzen eines Anforderungshappens im Munde rumdrehen würde ;-) Ich habs trotzdem geschrieben, weil mitten im Projekt eine Reihe von Parametern fix sind. Und es geht ja auch nur um Anforderungen für wenige Tage. Da bewege ich mich im Rahmen dessen, was Scrum versucht. Das kann man dann auch mal probieren. Warum nicht? Der Horizont ist überschaubar. Aber das ist etwas ganz anderes, als ein Mehrmonatsprojekt vorab (!) und komplett (!) für eine Auftragsunterzeichnung mit einem Fixpreis/Fixzeit/Fixscope "berechnen zu wollen".

Bei Recht b. bezahlt der Kunde natürlich nach Woche 3.

Schön, dass du mit meiner Liste übereinstimmst. Warum willst du dann noch Fixpreis/Fixzeit für einen Fixscope schätzen?

Ja, es ist immer nur soviel machbar, wie mit dem "Herumgeeiere machbar ist". Darüber, wie ein Team entwickelt, habe ich keine Aussage gemacht. Es kann sehr professionell und systematisch arbeiten oder es kann rumeiern. Das weiß der Kunde eh nicht. Und ich kann dir sagen, die meisten Teams wissen es von sich selbst auch nicht.

Wenn du Gelegenheit hast, mach mal eine Teamstatuserhebung. Stelle eine Aufgabe, gibt dem Team 2,5 Std Zeit, beobachte, wie es sich verhält und was am Ende rauskommt. Das ist augenöffnend. (Mach das aber nicht im eigenen Team, da bist du nicht unbefangen. Wenn du willst, mach ich das aber gern bei euch. Mein Angebot: für Reisekostenerstattung komme ich zu euch für einen Nachmittag. Dann können wir ja sehen, was ihr auf die Straße bringt. Nimmst du das Angebot an?)

JakeJBlues hat gesagt…

@All,

vielleicht sollten wir erst mal klären, was wir schätzen wollen?

a) Zeit
b) Kosten

Fange ich mal mit b) an, wenn wir nur die Kosten eines Projektes schätzen wollen, dann kann ich das doch auf Basis eines "Modelles" oder Architektur machen, welche in sich valide ist. Zur Schätzung der Kosten, nehme ich an, dass die Entwickler richtige Profis sind und alle zu erledigende Tasks schon einmal implementiert haben ;-) Weiters Frage ich den Kunden, was ihm die Erledigung der "Aufgabe" wert ist. Dann muß ich mich doch nur in den Profi hinein denken und fragen würde er zu dieser Nachfrage das Angebot annehmen... Conclusio -> Kunde gibt Kosten vor und ich sage nur "ja oder nein"!

Jetzt zu a), da die Kosten mit dem Kunden nun abgesprochen sind, geht es doch nun vielmehr nur noch, um die Umsetzung. Da die meisten Entwickler ja immer dazulernen, brauche ich nur abzuschätzen, wie lange brauche ich um mir dass Know-How anzueignen. Ich schätze dies in Wochen ab. Kann ich es in einer Woche schaffen, ja oder nein? Wie sieht es mit zwei Wochen aus....? Kann die Aufgabe erledigt werden, wenn ich es in zwei Wochen nicht schaffe?

Also erst mal Kosten, dann Zeit....

Klar es gibt immer jemanden, der sagt ich kann es 1000 Euro billiger machen und brauche 2 Tage weniger, dann soll er den Job eben machen :-D Aber die Schätzung ist vorhanden und der Kunde hat einen Kosten und Zeitrahmen!

Gruß JJR

Hans hat gesagt…

Warum ich Kosten vorab bestimmen will, habe ich mehrfach geschrieben.

>> Mein Angebot: für Reisekostenerstattung komme ich zu euch für einen Nachmittag. Dann können wir ja sehen, was ihr auf die Straße bringt. Nimmst du das Angebot an?) <<
Nö. Wozu? Was soll ich jetzt mit einer Teamstatuserhebung. Es ging um Planung. Und ich wollte Dich für etwas anderes kaufen, nämlich sehen wie Du einem potentiellen Kunden Deine "Katze im Sack" verkaufst. Bei unseren bestehenden Kunden würde ich mich das nicht trauen. Naja, ehrlich gesagt, wäre es da auch nicht nötig. Für bestehende Kunden arbeiten wir fast immer nach Aufwand.

Ich bin aus der Dikussion raus. Macht für mich keinen Sinn mehr. Trotzdem Danke.

Ralf Westphal - One Man Think Tank hat gesagt…

@Hans: Wenn du nach Aufwand arbeitest, verstehe ich völlig, dass dich das Thema Schätzen nicht wirklich umtreiben muss. Da reicht es, wenn du ne grobe Hausnummer kennst. Gegen die hab ich auch nix. Habe grad mit einem Kunden gesprochen, der "errechnet" hat, dass sein Projekt 3000-6000 Personentage groß ist. Das reicht ihm. Und das reicht mir auch bzw. so einen gaaaanz grobe Größenordnungsschätzung finde ich nicht so schwer. Bei ganz allgemeinen Infos zu einem Projekt ist eine ganz allgemeine Größenordnungsschätzung machbar.

Schätzung/Berechnung geht eben immer nur auf dem Level der existierenden Unsicherheit. Hohe Unsicherheit korreliert mit grober Schätzung.

Und mein ganzer Punkt ist, dass für Software die Unsicherheit nur sehr begrenzt gesenkt werden kann. Daher sind keine wirklichen Berechnungen möglich.

Dem Kunden habe ich übrigens auch sofort gesagt, dass alles steht und fällt mit seinem PO. Da hat er nur gelacht. Der PO ist einer der Vorstände. Da hab ich auch gelacht. Das Projekt muss er gar nicht anfangen. Es läuft sicher aus dem Ruder, solange es keinen PO gibt, der bei solch einem Projekt den größten Teil seiner Aufmerksamkeit bei dem Projekt hat: als "Zugpferd" am Ende des Prozesses, das Releases sehen will; jeden Tag. Und als Quelle für Anforderungen und Informationen; auch jeden Tag.

Naja... viel Spaß mit dem stetigen Geldfluss nach Aufwand. Du hast es schon geschafft. Wer seinen Kunden bei Aufwandszahlungen hat, muss nicht weiter "baggern" :-)

Manuel hat gesagt…

Meiner Meinung nach liegt das Problem nicht nur bei der Schätzung an sich, sondern auch an der Interpretierung. Kunde und auch Projektleiter sehen die Schätzung vielfach in Stein gemeisselt und vergessen, dass eine Schätzung (wie das Wort schon sagt) eine Schätzung ist!

Unknown hat gesagt…

Hi Ralf

Der Mensch schätzt, weil er es so gewohnt ist.

- Wenn wir vor einer Pfütze stehen. Schätzen wir ob wir drüber springen können
- Wenn wir im Auto bremsen, schätzen wir, wie viel druck nötig ist, damit es zum Anhalten reicht
- Als wir vor tausend Jahren in der Savanne Abstand zu wilden Tieren gehalten haben, haben wir geschätzt, ob dieser reicht, um den rettenden Baum zu erreichen und einen entsprechenden Sicherheits-Bonus eingeplant

Die hier geschätzten Werte sind hierbei hauptsächlich für uns persönlich relevant.

In der Softwareentwicklung jedoch, leben wir in der Welt des Geldes und des 'ROI', und dieser lässt sich nun mal nicht berechnen, wenn man nicht weiß was es kostet.

Die hierfür zuständige "Kommission", das Controlling, kennt kein Vertrauen, sondern nur Kennzahlen.

Deshalb ist, und ich lasse hier mal absichtliches Kleinrechnen bewusst raus, alles was mir dabei hilft einen Preis mit weniger Risiko zu ermitteln, etwas Gutes.

Denn solange wir nicht alle Engel werden, und Geld keine Rolle mehr spielt, werden wir einen Preis angeben müssen ... und der lässt sich leider nur ... Schätzen. :)

Unknown hat gesagt…

Nicht mehr schätzen ? Mein innerstes neigt dazu "Ja gerne" zu sagen, aber wie das funktionieren soll erschließt sich mir nicht.

Sie schlagen in einem Kommentar hier vor dem Kunden gleich zu Beginn einen Preis zu nennen. Für welchen Zeitraum soll dieser dann gelten wenn wir hier nicht schätzen ? Soll der Kunde einfach mal die Entwicklergehälter für einen bestimmten Zeitraum bezahlen und wir schauen mal wie weit wir kommen ?

"It's done when it's done" können sich vermutlich die wenigsten Software-Häuser leisten. Geschweige denn kann es sich der Kunde leisten der zum nächsten Ersten mit der Software in Produktion gehen muss (bevor er selbst Pleite geht).

Und ohne Schätzung haben wir auch keinen ungefähren Fertigstellungstermin. Bedeutet das nun das sich jeder Entwickler so viel Zeit nehmen kann wie er möchte ? Es gibt ja nicht wirklich einen Termin bzw. einen daraus resultierenden Druck mit etwas feritg zu werden.

Fragen über fragen ...

Ralf Westphal - One Man Think Tank hat gesagt…

@asd: Dem Kunden soll kein Preis genannt werden, sondern der Kunde nennt sein Budget. Er kann eh nicht mehr zahlen, als er zahlen kann. Und er bekommt dafür, was man ihm dafür geben kann. Nie mehr. Und wenn man sein Vertrauen nicht missbraucht, auch nicht weniger.

Der Kunde soll natürlich Entwicklergehälter zahlen. Was denn sonst? Dafür sind Kunden da.

Und, ja, man kann für das Geld immer nur schauen, wie weit man kommt. Weiter kommt man nämlich nicht. Es sei denn... man zahlt drauf. Ist das dein Interesse?

Ein Kunde, der zum nächsten 1. in Produktion gehen muss, kann - wie jeder andere Kunde auch - keine Wunder verlangen. Auch er kriegt nur, was er kriegen kann, was machbar ist. Ich würde sagen: Voll reinhauen! Dann ist es wahrscheinlicher, dass genügend geschafft wird.

Ich bleibe dabei: Die Mentalität "Ich schmeiße mal (unvollständige und ungenaue) Anforderungen über den Zaun, wünsche mir einen Termin, nenne den Preis - und dann sollen sie zusehen, wie sie das schaffen." führt zu nichts - außer Kopfschmerzen und Schlimmerem.

Entwickler können sich eben nicht soviel Zeit nehmen, wie sie möchten. Sie sollen jeden Tag liefern. Der Kunde soll jeden Tag auf der Matte stehen und fordern "Wo ist meine neue Funktionalität?" Erst so kann überhaupt Vertrauen entstehen, wenn jeden Tag verlässlich geliefert wird.

Das Kunden dafür nicht aufgestellt sind, weil sie ja etwas über den Zaun werfen wollen, um später nur noch das Fertige einzusammeln, steht auf einem anderen Blatt.

nikosch hat gesagt…

Hmm, ich musste auf der Hälfte der Kommentare aussteigen. Der Artikel enthält in seiner unnötigen Länge und seinen Redundanten Aussagen sicher einige Wahrheiten, allerdings bin ich da eher auf der Seite einiger Kommentatoren: SW-Entwicklung ist ein Handwerk und ein Dienst am Kunden. Es abstrahiert eine Aufgabe auf Preis und Lösung und legt die Dienstleistung in Expertenhand. Meine Kunden sagen mir oft, sie haben vom Thema keine Ahnung und können da absolut nichts einschätzen. Aus Geschäftssicht ist es aber nunmal notwendig, eine Entscheidungsgrundlage über das Schätzen zu schaffen, ob Kunde a) den Auftrag vergeben b) um Features erweitern und verringern möchte. Das macht der Automechaniker nicht anders (und die haben auch mit kniffligen Problemen zu tun). Sicher gerade hier passt der Kostenvoranschlag meist auch nicht, trotzdem habe ich eine grobe Richtung, ob ich mich im 200€ oder 4000€ Bereich bewege. Mehr will der Kunde doch gar nicht. Jetzt noch Fehlzeiten mit einkalkulieren und den Vertrag einigermaßen flexibel für beide Seiten gestalten - das scheint mir noch die fairste Variante zu sein. Den Kunden, der sagt "ob 200 oder 2000 Euro, egal, machen sie mal", den habe ich noch nicht kennengelernt. Denn der Preis eines Projektes ist für ihn auch _nur ein_ Faktor in der unternehmerischen Kalkulation.

nikosch hat gesagt…

PS:
> Entwickler können sich eben nicht soviel Zeit nehmen, wie sie möchten. Sie sollen jeden Tag liefern.

Wie wahrscheinlich ist das denn? Gerade im Webbereich liegt die Hauptentwicklung im Hintergrund, wo es erstmal gar nichts zu sehen gibt oder Bestandteile eigenständig nicht lauffähig sind oder nur sehr unspektakulär. Die klassische 80/20 Regel gilt hier genauso wie das Interesse des Kunden, das man im Prinzip mit einem Mockup zu 80% gedeckt hat.

Zudem benötigt kurzperiodisches Feedback jede Menge zusätzlichem Aufwand - Abschluss des Teils, ggf. Kompilieren oder Zusammenstellen, Kommunikation, Upload o.ä.
Und falls sich die Aussage mehr auf die Information "wie weit sind wir" bezieht, beläuft sich jede Antwort darauf doch genauso auf eine Schätzung, die noch gefährlicher ist als die des Gesamtpreises. "Jeden Tag liefern" ist also IMHO der feuchte Traum eines Kunden.

pvblivs hat gesagt…

Wir haben mal vor 3 Jahren für ein recht großes (sehr gut definiertes) internes Projekt mit letztendlichem Umfang von 1.000 Manntagen die Schätzung ins Absurde getrieben und die halbe Entwicklungsorganisation 200 Manntage mit technischer Vorab-Grobkonzeption und Schätzung beschäftigt. Die initiale Bauchschätzung eines anerkannten Experten vorher war 300 Manntage. Die Schätzung der Entwickler kumuliert 700 Manntage. Aufwand war wie gesagt 1.000 - Aufwand für Schätzung nicht eingerechnet.

Die Teams waren erfahren, die Technologie war stabil, der Scope war erstaunlich stabil.

Da kann ich auch "einfach mal anfangen" nach einer groben Planung dieselben Leute daran arbeiten zu lassen und dann nach der Zeit entscheiden, ob ich das Projekt lieber abbreche, weil es alles so aufwändig ist.

Seit diesem Projekt machen wir im übrigen Scrum. Vom Management wird einmal im halben Jahr ein Commitment (eine Schätzung) für den ugf. Scope des nächsten halben Jahres erwartet.

Alle finden es unsinnig, von allen wird es erwartet, irgendwie machen es alle.

Nutzen hat all das Schätzen in verschiedenen Facetten selten gebracht. Der einzige Nutzen war, dass man ein Projekt "dann eben nicht" gemacht hat. Aber nur weil es noch nicht wichtig genug war. Dieses Jahr wird es dann doch gemacht.

Das alles in einer Firma mit ihren eigenen Produkten.

---

In der Auftragsarbeit Kunden so zu erziehen sehe ich als schwierig an. Bei Neukunden vermutlich fast unmöglich.

Für Bestandskunden war bei einem vergangenen Arbeitgeber eine Budget-orientierte Arbeit im übrigen sehr üblich. Und bei guter Arbeit (und guten Ideen) wurden die Budgets meist noch erhöht.

Grüße
Stefan

pvblivs hat gesagt…
Dieser Kommentar wurde vom Autor entfernt.
pvblivs hat gesagt…

@nikosch: Den Werkstatt-Vergleich finde ich gut:
- ich bringe meinen VW zur Durchsicht, 10 Jahre alt
- ich sage vorneweg was gemacht werden muss: Werkstatt sagt 500 Euro
- Werkstatt ruft an und sagt "ääh, das und das ist durchgerostet, die Batterie liefert nich mehr genug Volt für den Winter usw. usf. 1500 Euro"
- Wenn die Werkstatt aber einmal den exakt Scope vorhergesagt hat (Auspuff, Batterie, Blinkerbirne, Innenreinigung), dann ist die Schätzung meist exakt. Ist ja auch ein VW Lupo 1.4 TDI mit bekanntem Ersatzteillager

Die von Dir angesprochenen Websites sind nicht so. Da ist jede anders. Selbst in großen Webportalen, wie das in dem ich arbeite, sind zwar 30.000 Seiten weitgehend gleich (sog. redaktionelle oder statische Seiten).
Die 900 sogenannten dynamischen Seiten sind aber anders: Einige sind CRUD für hyperkomplexe Domänenmodelle, andere sind überfrachtet mit Funktionalität, andere wiederum haben umfangreiche Filterfunktionen (OLAP-Kram). Und nur eines haben alle gemein: Jede ist anders. Das will auch das Unternehmen. Denn das Design X z.B. muss ein Hingucker werden. Und die Software muss jedem individuellen Hingucker gerecht werden.

Und im Übrigen ist "Jeden Tag etwas live" für Websites natürlich (jenach Komplexität der Software) sehr anspruchsvoll. Aber sind 5 Tage ein machbares Ziel? Oder 3? Oder einfach so oft wie möglich? Ja.

Das gilt gerade für die von Dir angeführten Websites. Prototypen / Mockups mal dahingestellt geht es ja darum dem Kunden den Fortschritt zu zeigen.

Beispiel Volltextsuche:
- Heute ein neues Eingabefeld (damit der Kunde sich das vorstellen kann und was schickeres fordern kann)
- Dann brauche ich vielleicht ein paar wenige Tage Architekturarbeit (Server beschaffen, Lucene installieren, konfigurieren, Daten reinpumpen)
- eine Woche später können erste Suchergebnisse gesichtet werden, noch hässlich, aber der Kunde sieht schonmal was
- zwei Tage später sind die Änderungswünsche am Layout drin
- zwei Tage später eine erste, rudimentäre Autocompletion

Es gibt auch bei Websites Backendsysteme (wie ESBs, Replikations-Jobs, MapReduce-Jobs etc.) wo man häufig wirklich erst sehr spät was sieht. Man sollte aber seine Infrastruktur so planen, dass man auch da schnell Dinge zeigen kann. Denn auch aus dem MapReduce-Job fallen am Ende Reports aus, die jemanden interessieren (den Kunden) und der am besten bevor der Entwickler "fertig" ruft, einsehen können sollte ob das Ergebnis dem entspricht, was er haben will um nachsteuern zu können.

Grüße
Stefan

Ralf Westphal - One Man Think Tank hat gesagt…

@nikosch: Du sagst, "Gerade im Webbereich liegt die Hauptentwicklung im Hintergrund, wo es erstmal gar nichts zu sehen gibt oder Bestandteile eigenständig nicht lauffähig sind oder nur sehr unspektakulär." und beschreibst damit eines der Grundprobleme vieler Entwickler: in Längsschnitten, in Anforderungsscheiben denken zu können.

Ich behaupte, du kannst schon am 1. Tag immer irgendwas liefern, wozu ein Kunde Feedback geben kann. Immer. Und das ist wichtig, weil er dann die Gelegenheit zur Kurskorrektur hat.

Ist das dann auch immer etwas, das er schon produktiv einsetzen kann? Nein. Aber darum geht es auch nicht. Es geht um Feedback, Feedback, Feedback.

Wenn ein Team gut aufgestellt ist, kann es diesen "feuchten Traum" eines Kunden auch materialisieren. Schön, dass du wenigstens diesen Traum so angenehmn findest :-)

Robert hat gesagt…

Ich habe mit großem Interesse diesen Blog verfolgt. Es ist doch schon erstaunlich, wie sehr die Welt am Schätzen hängt. Jeder weiß eigentlich, dass sie nie genau ist und dennoch machen wir es. Immer und immer wieder. Und wenn wir es nicht machen, dann macht es der Konkurrent.

In der Kernaussage stimme ich dir vollkommen zu Ralf. Schätzen macht auf Grund ihrer immanenten Ungenauigkeit keinen Sinn. Jede Zahl die genannt wird, ist eh falsch. Und sollte sie wider erwarten richtig sein, dann hat das nichts mit der Professionalität des Auftragnehmers zu tun, sondern schlicht weg Glück. Denn beim nächsten Mal liegt er wieder daneben.

All die beschriebenen Beispiele hier beziehen sich mir zu sehr auf die techn. Fähigkeiten der Entwickler. An denen liegt es weit weniger, dass Projekte aus dem Ruder laufen. Wir entwickeln immer und immer wieder das gleiche: eine Warenwirtschaft hier, einen neuen Shop dort oder eine andere x-beliebige CRUD Anwendung. Und dennoch schaffen wir es nicht, im Angebot einen Preis und eine Entwicklungszeit zu nennen, die nach Abschluss der Arbeit zu 100% eingetroffen sind? Wenn es aber schon so viele Programme am Markt gibt, braucht der Kunde vielleicht nur eine Beratung, welche am besten zu ihm passt?

Eher ist es doch so, dass keine Software am Markt genau auf die Bedürfnisse des jeweiligen Kunden passt. Deshalb kommt er ja zu uns und will eine für seine Bedürfnisse entwickeln lassen. Ralf, hier gebe ich dir 100% Recht – hier fängt dann das Problem erst richtig an. Wir haben hier ein stark kommunikatives Problem mit unseren Kunden, kein programmiertechnisches. Und in diesem steckt der Keim für die gesamten Verzögerungen und Kostenexplosionen in den Projekten.

Heiko Dietz schrieb:
“[…]Nur benötigt man dazu eben auch einen großen Satz an Fähigkeiten, die Entwickler üblicherweise nicht mitbringen. Hier sind im Team andere Leute gefragt und zwar die, die in der Lage sind ein entsprechendes Anforderungsmanagement zu machen.[…]“

Ich teile Heikos Auffassung nicht. Nicht der Anforderungsanalytiker schreibt das Programm. Das sind immer noch die Programmierer. Und solange nicht bei ihnen dasselbe Bild im Kopf entsteht, wie es beim Kunden vorherrscht, werden sie die Bedürfnisse nicht kundengerecht umsetzen können. Meiner Ansicht nach ist es evident, dass Programmierer ein Gespür für ihre Kunden entwickeln. Dazu brauchen sie auch den Kontakt und das direkte Gespräch. Hieran krankt zumindest ein Teil unserer Branche. Und Sprache ist tückisch und selten eindeutig. Zudem muss er sein Bedürfnis (Prozess) beschreiben können.

Robert hat gesagt…

Hier mal eine kleine Denksportaufgabe: beschreibt einmal den gesamten Ablauf (Prozess) auf eurem Fahrweg zur Arbeit (für diejenigen, die zur Arbeit fahren müssen). Ihr macht ihn ja täglich, also sollte es ja kein Problem sein. Wenn ihr im ersten Anlauf auf 5% der Details kommt, dann seid ihr spitze.

Ich habe noch keinen Kunden oder noch besser PO erlebt, der beim einholen eines Angebots seine Bedürfnisse haarklein und ohne fehlende Details formuliert hat. Häufiger ist es doch so, dass er nur eine vage Vorstellung von dem hat, was er wirklich braucht. Und seine Prozesse kann er auch selten detailliert beschreiben. Und auf einer solchen Basis sollen wir dann eine Einschätzung zu Kosten und Zeit geben.

Wie Niels Bohr schon sagte:
“Prediction is difficult – especially of the future.”

So spielen wir alle das Spiel des Lebens, in einer Welt, die nicht fair ist und in der wir in einem harten, beständigen Wettbewerb stehen und unsere einzige und bei (fast) allen akzeptierte Antwort darauf heißt „Schätzen“ – nennen sie mir Zahlen und Fakten. Und da es jeder tut sind wir im Zugzwang. Aber wir sollten ehrlich bleiben – zumindest zu uns selber. Es ist nichts weiter als ein Spiel. Und egal, welche Methoden wir dazu anwenden, damit wir am Ende nicht der Verlierer sind, wir werden weder das Schätzen besser machen noch es los werden. Es ist wie eine Droge – jeder weiß, dass sie für ihn nicht gut ist, aber man kann einfach nicht davon lassen. So muss jeder für sich selber entscheiden, ob er dieses Spiel mitspielen will oder nicht.

Ralf hat für sich entschieden, dieses Spiel nicht mehr zu spielen und etwas anderes zu versuchen. Für ihn klappt das bestens. Und für seine Kunden auch. Und darüber nachzudenken lohnt sich. Ob es für jeden oder jede Situation passt? Keine Ahnung.

Womit wir beim eigentlichen Kern des Dilemmas angelangt sind. Es gibt eben kein Patentrezept zur Problemlösung. Jedes ist individuell angegangen und gelöst werden. Genau so wenig es die eine ultimative Software, die sämtliche Probleme des Kunden auf Knopfdruck löst. Jeder muss sehen, was am besten zu ihm passt. Nur sollte man dafür keine Scheuklappen aufhaben sondern offenen Auges und Gedankens durch die Welt gehen.

Anonym hat gesagt…

Dank Ralf! Guter Post!

Ich denke das wesentliche, was viele Kommentatoren vermischen, ist:

eine kurz Aufgabe kann man gut schätzen. Also alles was so eins, zwei Tage dauert.

Aber in ein neues Framework einarbeiten (weil man sein Produkt beim framework des Kunden einbetten muss/will) ist schwierig zu schätzen. Das entspricht eher "mehrere Tage" bis "Wochen". Aber wieviel genau??

Und da ist der Punkt den ich gut finde:

inkrementelles Präsentieren der Fortschritte. Einbinden des Kunden etc

Ein Kommentator spricht auch von Deckelangeboten. Das finde ich auch super. Nur muss da schon ein gewisses Vertrauen zum Kunden schon bestehen. So dass der Kunde nicht gleich beim Aussprechen dieses Angebots wegrennt :-)

Anonym hat gesagt…

Durchaus ernst gemeint:

Der Kaspar, der war kerngesund,
Ein dicker Bub und kugelrund,
Er hatte Backen rot und frisch;
Die Software schätzt' er hübsch bei Tisch.
Doch einmal fing er an zu schrei’n:
„Ich schätze keine Software! Nein!
Ich schätze meine Software nicht!
Nein, meine Software schätz ich nicht!“

Am nächsten Tag, — ja sieh nur her!
Hatt' er der Kunden weniger.
Da fing er wieder an zu schrei’n:
„Ich schätze keine Software! Nein!
Ich schätze meine Software nicht!
Nein, meine Software schätz ich nicht!“

Am dritten Tag, o weh und ach!
Wie ist der Kaspar dünn und schwach!
Doch als das Last'heft kam herein,
Gleich fing er wieder an zu schrei’n:
„Ich schätze keine Software! Nein!
Ich schätze meine Software nicht!
Nein, meine Software schätz ich nicht!“

Am vierten Tage endlich gar
Der Kaspar wie ein Fädchen war.
Er wog vielleicht ein halbes Lot —
Und war am fünften Tage tot.

Ralf Westphal - One Man Think Tank hat gesagt…

@Anonym: Ganz wunderbar! Danke für deine Mühe der Umdichtung.

Da will ich natürlich nicht nachstehen, das kannst du dir denken. Hier meine Adaption einer anderes Geschichte aus demselben Werk:

Wenn der Hans zum Kunden ging,
Stets er an dem Aufwand hing.
Auf den letzten Tagesfetzen
War dann alles fein zu schätzen.
Ob er's würde können richten
Ja, das sah der Bursch' mitnichten.
Also dass ein jeder ruft:
"Seht den Hans Nur-schätzen-bringts!"

Wurd ein neuer Wunsch genannt;
Hänslein blickte unverwandt
In die Luft.
Niemand ruft:
"Hans, gib acht, auch wenn´s pressiert!"
Was passiert?
Pauz! Perdauz! - Nachverhandlung beim Vertrag
Kund´ das Hänschen fast verklag'.

Einst entwickelte er gewandt
Mit dem Pflicht'heft in der Hand.
Nach dem Meilensteine nicht so bald
Sah er, wann der Kunde zahlt.
Also dass er kerzengrad
Sich zuerst an Infrastruktur wagt.
Und die User in der Reih'
Sind erstaunt sehr, alle drei.

Nach drei Monat! rumms! der Hans
in Details verschwunden ganz!
Die drei User, sehr erschreckt,
haben sich sogleich versteckt.

Doch zum Glück da kommen zwei
Agilisten aus der Näh´ herbei,
Und sie haben ihn mit I´rationen
Ausgelöst aus sein´ Passionen.

Seht! Nun ist er hinterm Plan zurück!
Ei! Das den Vorstand nicht entzück'!
Schweiß läuft dem armen Wicht
Aus den Haaren ins Gesicht,
Aus den Kleidern, von den Achseln;
Ob er´s wird nun können deichseln?

Und die User alle drei,
Laufen hurtig gleich herbei;
Strecken Köpfe durch die Türe,
Rufen, dass mans laut noch höre,
Hättest weniger du geschätzt
Und dich mehr in uns versetzt,
Hättest uns desöfteren 'fragt,
Nicht solang allein gewagt,
Wäre dem Vorstand wohler g´wesen.

Denn mit täglich Lieferung
Wir dir täten kund
Was wir alles mögen
Oder anderes vorzögen.
Uns wäre früher klarer was wir suchen,
Du müsst´ nicht übers planen auch noch fluchen.

Christian hat gesagt…

Mehr als drei Monate sind vergangen und keine Kommentare mehr? Ich persönlich finde diesen Thread unglaublich spannend. Was mir fehlt ist die Aussicht auf einen Weg, den man gehen könnte, um dieser Problematik Herr zu werden. Sicher wird es kein Allheilmittel geben und wir sind uns ja bereits darüber einig, dass es Trivialthemen gibt (sogar in der Softwareentwicklung), die hervorragend und an präzise grenzend geschätzt werden können.

Wichtig ist herauszufinden, wie man mit dem Rest umgeht. Blöd ist, dass Softwareentwicklung allgemein sehr teuer ist. Obwohl das in erster Instanz nur die Auftragsentwicklung betrifft.

Denn: Obwohl viele Mannjahre in Windows 7 stecken, habe ich es für knapp 100 Euro gekauft. Geschenkt. Das kommt daher, weil Microsoft halt ein paar Millionen davon verkauft.

Sitzen aber 100 Programmierer (+ Designer + Projektplaner + Tester + ...) an der Entwicklung einer Auftragssoftware für eine Firma, dann zahlt diese die vollen Entwicklungskosten.

Neben Bruttogehalt + Lohnnebenkosten + weitere Sozialkosten + Krankheitsausfall + Mieten + Firmenwagen + Handykosten + Infrastruktur + Strom + ... kommen sicher noch diverse weitere Kosten zusammen, die ein einzelner Entwickler eine Firma kosten kann. Das alles zusammengerechnet ergibt unglaubliche Kosten. Will die Firma auch noch zukunftsorientiert und sozial arbeiten (sprich: Arbeitsplätze auch in Krisenzeiten erhalten), dann muss sie auch noch ordentlichen Gewinn verzeichnen, um einen Buffer aufbauen zu können.

Und schon kostet mich das Produkt als Käufer vielleicht 200.000 Euro Euro statt 20 bei Mediamarkt.

Die 20 Euro... über die denke ich nicht nach. Aber die Firma, die eine Software in Auftrag gibt, hat ebenfalls Verpflichtungen ihren Mitarbeitern gegenüber. Da machen 200.000 gegenüber z.B. 500.000 Euro einen enormen Unterschied. Selbstverständlich will ich da wissen, worauf ich mich einlassen muss...

Und da wären wir wieder beim Schätzen. Als Kunde beruhigt mich diese Zahl in Hinsicht auf meine Entscheidung, sie vertreten zu können. Als Auftragnehmer bin ich daran gebunden, sie irgendwie real werden zu lassen. Und wie zahlreiche Beiträge gezeigt haben: Es klappt nicht.

Kann man bei der Entwicklung einer Software zur Verwertung einer CSV mit vorgegebenem Format in Form eines ASP.NET basierten Dashboards mit vorgegebenem Aussehen sagen, ob es eher 5.000 Euro oder eher 1.000.000 kostet? Sicherlich. Aber bringt einem das etwas? Fraglich...

Also: Ausgehend davon, dass es Systeme gibt, die derart komplex sind, dass eine Schätzung nicht machbar ist. Und ausgehend davon, dass daraus ein nicht kalkulierbarer Kostenfaktor entsteht. Dann muss die Lösung lauten einen Weg zu finden, die Kosten dennoch kalkulierbar zu machen.

Beispiel Zahnersatz:
Eine Person mit kaputten Zähnen geht zum Arzt und der erklärt ihm, dass drei Zähne gezogen werden und danach Implantate eingesetzt werden müssen. Kosten: Etwa 15.000 Euro (geschätzt). Während der Umsetzung fördert er andere Probleme zutage, weshalb sich die Summe aufeinmal verdoppelt hat. Trotzdem funktioniert es. Warum? Weil die Person a) eine Versicherung hat, die Teile übernimmt und in die er zuvor jahrelang eingezahlt hat und er b) den Rest abstottern kann.

Wie lässt sich das auf die Softwareentwicklung abbilden? Könnten Firmen, die mit an Sicherheit grenzender Wahrscheinlichkeit angepasste Software brauchen werden eine Versicherung abschließen, die Teile der Kosten übernimmt (und das kann, weil sie das viele Geld, das sie von den Kunden bekommt, anlegt und vermehrt)... und den Rest in moderaten Raten abzahlen?

Hmmm....