Kategorien
90% Syndrom
Gestern habe ich ja schon mal ein wenig aus dem Nähkästchen geplaudert, was meine Erfahrungen in der Webentwicklung angeht. Da möchte ich heute fortfahren. Es geht um das 90% Syndrom. Ich habe den Namen vor kurzem irgendwo gelesen und fand ihn ganz einprägsam, ob es eine offizielle Bezeichnung ist, weiß ich nicht und wahrscheinlich können das andere viel besser erklären aber ich versuche mich trotzdem mal dran. Auf jeden Fall geht es darum, dass man, wenn man ein Projekt startet oft den Fehler macht und mit allen Features, die keine Abhängigkeiten besitzen auf einmal startet.
Klingt ja eigentlich nicht so verkehrt. Denn so kann sich jeder um seine Sachen kümmern und die bis zum Ende fertig stellen. Nur leider ist hier das Problem, dass kurz vor dem Abschluss des Projektes alle Features die 90% erreicht haben, aber keines fertig ist. Das ist ein Phänomen, dass mir schon des öfteren selbst passiert ist. Warum fällt man aber immer wieder auf die selbe Sache rein? Das Problem ist bekannt und, wie fast alle bekannten Probleme, auch schon gelöst.
Wir fangen einfach mit einem Feature an und befassen uns so lange mit, bis es fertig ist. Fertig wäre für mich ein dokumentiertes, mit Tests unterlegtes, funktionierendes und abgenommenes Feature. Erst wenn dieses abgeschlossen ist, kann mit dem nächsten angefangen werden. So stellen wir sicher, dass am Ende maximal ein Feature auf 90% steht. Sind diese Features jetzt noch nach ihrem Businesswert sortiert, so kommen wir dem Scrum Ansatz schon sehr nahe. Zumindest einem der Grundsätze, die dort gelten. Googelt also mal ein wenig Scrum und 90% Syndrom, bevor ihr ein neues Projekt startet. Vielleicht helfen euch ja die genannten Buzzwords.
Wo genau siehst du den Grund, warum die Features nur zu 90% fertiggestellt werden? Weil die restlichen 10% eine Abhängigkeit haben? Also bswp. eine Abhängigkeit zu einer Lib oä, die noch gar nicht implementiert ist? Oder verliert der Entwickler einfach die Lust? ^^
Ich glaube, dass wir Programmierer echt schlechte Schätzer sind und außerdem greift wohl auch hier das Paretoprinzip (80% der Ergebnisse in 20% der Gesamtzeit eines Projekts erreicht werden. Die verbleibenden 20% verursachen die meiste Arbeit).
Du glaubst garnicht wie du mir da grade aus der Seele sprichst…
Wie Nils schon sagte: 80% gehen uns leicht von der Hand – Für die restlichen 20% müssen wird arbeiten. 90% halte ich für einen guten Wert. Er sagt m.E. aus, dass wir mit den 20% schon angefangen aber die Arbeit in diesem Segment noch nicht fertiggestellt haben.
Ich arbeite seit Monaten an den 10%… wie gut, dass es nicht nur mir so geht. 🙁
Wenn man doch von vornherein wüsste, was genau die 20% sind, die soviel Arbeit machen? Dann könnte man diese aus den Anforderungen streichen und gleich die 80% als 100% verkaufen, die man nur in 20% der Zeit entwickelt hat… 🙂
Aber sehr interessanter Ansatz zum Paretoprinzip. Genau das verfolgt mich auch gerade wieder.
Das Hauptproblem ist doch das das Schreiben von Software zu einem großen Teil aus dem lösen von alltäglichen und auch nicht alltäglichen Problemen besteht.
Wie will man denn genau wissen wann man eine Lösung für ein Problem gefunden hat?
Von daher ist es eigentlich völlig unmöglich wirklich genau abzuschätzen wie lange ein Projekt dauert.
@Bartek: „wirklich genau“ und „abschätzen“ sind ein Widerspruch in sich. Das ist in der Tat unmöglich.
Aber „so genau wie möglich abschätzen“ wie lange ein Projekt dauert, ist eben immer möglich.
@Bartek: Probleme löst du nicht beim Entwickeln sondern vorher. Insofern kann ich das nicht ganz nachvollziehen. Ein sauber geplantes Projekt ist durchaus exakt und realistisch einzuschätzend. Problematisch wird es an der Stelle, an der unvorhergesehenes passiert – und das sind eigentlich immer menschliche Fehler: Diese Klasse oder Bibliothek kann das doch nicht, was man erwartet hat, dieses Feature wurde fälschlicherweise als bereits implementiert markiert, diese Funktionalität ist buggy, ein oder mehrere Entwickler fallen aus, der Kunde liefert Daten nicht im vereinbarten Format … man könnte die Liste ewig weiterführen. Und wenn dann zwei solcher Events gleichzeitig eintreten und sich gar ergänzen, dann sind wir an dem Punkt, der nicht mehr planbar ist.
@Cem: Das halte ich aber für ein Gerücht, dass man exakt schätzen kann. In der Theorie vielleicht, aber in der Praxis? Ich glaube, dass die meisten Projekte nie da ankommen, wo sie am Anfang hin wollten. Anforderungen ändern sich! Das ist im Web besonders extrem und ist nicht unvorhersehbar 🙂
Wichtig ist eigentlich, dass man seine Schätzungen immer wieder anpasst, was ja meistens nicht passiert. Einmal einen Termin genannt und dieser steht dann für die Produkt Manager felsenfest, was immer wieder zu Problemen führt.
Ja klar, Schätzen ist kein Prozess am Projektanfang sondern ein stetiger Prozess während des gesamten Projekts.
Und was die Fehler angeht: Dazu gibts Risikomanagement. Was schreibt Mr. Tompinks in sein Tagebuch? „Projektmanagement ist Risikomanagement“ (frei nach „Tom de Marco“, „Der Termin“, „Ein Roman über Projektmanagement“. Solltet ihr unbedingt mal lesen wenn ihrs nicht schon getan habt).
@Nils: Wo habe ich was anderes behauptet?
@Cem: „Ein sauber geplantes Projekt ist durchaus exakt und realistisch einzuschätzen“. Ich wollte ja nur sagen, dass es so eon Projekt wohl nur in der Theorie gibt. Unvorhersehbar ist also vorhersehbar 🙂
Das habe ich doch einen Satz später gesagt!?
Und man darf auch nicht vergessen, dass oft genug Projekte eben auch nicht gut durchgeplant und durchgedacht sind und somit eine realistische Schätzung generell unmöglich. Oft genug ist es mir jetzt schon passiert, dass man eine „Anwendung“ so flexibel wie möglich halten soll, da der Auftraggeber erstmal „schauen“ will. Oft scheitert die Zeitschätzung nicht nur an IT-Fachkenntnis (denn das ist auch oft der Fall) sondern auch an BWL-Grundlagen (Planung, Pflichtenheft etc. pp.).
Ein Pflichtenheft ist kein Bestandteil der BWL.
Aber grundsätzlich ist der Gedanke richtig. Stichwort „Domänenkenntnis“. Mein Professor formulierte das damals ganz nett. Die Frage war „Wie lange brauchen Sie, um ein Kalkulationsprogramm für eine Versicherung zu schreiben?“. Die Antworten waren relativ gering, weil immer die Basis da war „Es gibt ja Rechengrundlagen“. Die nächste Frage des Professors war „Wie viele Versicherungsgesetze kennen sie eigentlich?“. Da wars dann vorbei 😉
@Christopher K.
Vielleicht sollte man das auch einmal manchen Banken bzw. Großunternehmen sagen? Ich finde es immer wieder lustig, wie sehr mir damals in meinem BWL-Studium eingetrichert wurde, wie wichtig ein geregeltes Risikomanagment generell sei. Jetzt arbeite ich in so einem Großunternehmen, welches eben jenes Risikomanagement offensichtlich nicht richtig geführt hat, sodass uns die Finanzkrise mit voller Wucht getroffen hat. Erst jetzt bemüht sich die Firma um externe Berater Namens Proquest, welche erstmalig die ganze Unternehmensstruktur zur Gänze durchleuchtet. Eigentlich ein beängstigender Gedanke!
Wenn ich ehrlich bin, kenne ich das 90% Syndrom anders.
Du sagt, das 90% Syndrom beschreibt, dass viele Komponenten oder Teile einer Software nur 90% Vollständigkeit erreicht haben, aber keines wirklich vollständig ist.
Nach meinen Quellen (siehe unten) ist das 90% Syndrom, dass man DENKT, man habe bereits 90% der Software fertig gestellt, in Wahrheit sind es aber erst 50-70%. Das liegt daran, dass zum Ende hin noch unvorhersehbare Probleme auftreten usw.
Das hat eigentlicht nichts damit zu tun, dass alle Features nur 90% fertig sind, sondern eher mit der (optimistischen) falschen Einschätzung, dass ein Projekt kurz vor dem Abschluss steht.
http://pm-evm.blogspot.com/2009/02/das-90-syndrom.html
http://www.siegfried-seibert.de/Wissensspeicher/PMGlossar
http://www.projektmagazin.de/glossar/gl-0157.html