Es gibt Gewohnheiten, die nie in Frage gestellt werden. Und das zu Unrecht. Die Kostenschätzung zur Vorhersage der Kosten und die Terminschätzung mithilfe des "heiligen Plans" bilden die Grundlage des Projektmanagements.
Die Tradition geht so weit, dass wir dies als ein Gebot, eine Verpflichtung ansehen. Die Frage sollte jedoch gestellt werden.
Zweifel an der Angemessenheit der Schätzungen
Schätzungen sind überall zu finden:
- schon vor Beginn eines Projekts, um den Verkauf zu konkretisieren, verpflichtet sich jeder Anbieter, Kosten und Fristen einzuhalten ;
- in der Vertragsphase mit der Übung zur Festlegung von Verzugsstrafen ;
- und am Ende des Projekts bei der Überprüfung der Einhaltung der Verpflichtungen.
Dann stellt man fest, dass das Hauptkriterium für den Erfolg eines Projekts die Einhaltung der ursprünglichen Verpflichtungen ist. War man bei der ursprünglichen Schätzung gut?
Der Erfolg eines Projekts hängt also nicht davon ab, ob das Deliverable gut funktioniert? Oder daran, dass das Tool von den Nutzern in großen Mengen angenommen wird? Oder an den finanziellen Aspekt mit einer hohen und schnellen Investitionsrendite?
Wäre ein Projekt, das den Zeitplan und das Budget nicht einhält, von den Nutzern weitgehend angenommen wird und einen exponentiellen ROI aufweist, wirklich ein Misserfolg?
Es gibt eine Fülle von Methoden, um Schätzungen vorzunehmen.
Seit mehr als einem halben Jahrhundert hat jeder seine eigene Methode entwickelt, weil er die bisherigen Methoden für unzuverlässig hielt. Sie haben alle eines gemeinsam: Es sind Vorhersagen über die Zukunft... Irrationale Aktivitäten.
Zu den bekanntesten gehört die, bei der der Schätzer, nachdem er ein Lastenheft zur Kenntnis genommen hat, die beiden einzigen intellektuellen Prozesse einsetzt, die ihm in diesem Moment zur Verfügung stehen: den "nassen Finger" und das "Schnüffeln", um Ihnen eine Anzahl von Belastungstagen und einen genauen Zeitplan zu verkünden.
Einige Schätzmethoden sind sehr ausgefeilt, COCOMO zum Beispiel, das viele mathematische Formeln enthält, um höchst wissenschaftlich zu erscheinen. Dennoch setzt dies voraus, dass diese Informatiker vor Beginn der Entwicklung wissen, wie viele Zeilen Code es am Ende des Projekts geben wird... Eine Herausforderung, die weder von Kartenlegern noch von Orakeln verleugnet würde.
Die agilen Methoden haben ebenfalls ihre Prognosemethoden, wie z. B. Planungspoker, eingebracht, wodurch sie weniger risikoreich geworden sind:
- Die Schätzungen werden von den Entwicklern vorgenommen, die Experten für die Durchführung der zu erledigenden Arbeit sind;
- durch direkte Gespräche mit dem Kunden ;
- auf einen eng umgrenzten Funktionsbereich.
Dennoch bleibt der Planungspoker unbrauchbar, bevor das Projekt überhaupt begonnen hat. Er ist zeitaufwendig und damit teuer. Außerdem: Welchen Sinn macht es, zu erraten, was in zwei Wochen geliefert wird?
Die Nachteile von Schätzungen
Wenn die Deadline erreicht ist und die Arbeit nur teilweise erledigt wurde, haben die Entwickler zwei Möglichkeiten: Sie können ankündigen, dass sie mehr Zeit benötigen, oder dem Kunden das Produkt in unverändertem Zustand mit all seinen Fehlern liefern. Je höher die Deadline, desto geringer die Qualität.
Was die technische Schuld betrifft, so werden, wenn die Arbeit nicht richtig ausgeführt werden kann, viele Abkürzungen genommen. Ergebnisse :
- eine Verringerung der Softwareentwicklungen ;
- Verlust von technischem und funktionalem Wissen ;
- langwierigere, teurere und riskantere Entwicklungen ;
Das Beste kommt zum Schluss, wenn dem Kunden mitgeteilt wird, "dass es billiger ist, alles neu zu entwickeln, als eine Änderung an der Software vorzunehmen" - ein Symptom für den vollständigen Verlust der Kontrolle über das Projekt.
Das Umfeld, in dem sich Organisationen bewegen, ist schwankend.
Ein Konkurrent bringt ein neues Produkt auf den Markt, die Verordnungen zur Umsetzung von Gesetzen werden veröffentlicht, es ergibt sich eine Chance für externes Wachstum usw. All dies sind nicht planbare Ereignisse, die eine schnelle Anpassung der Anwendungen erforderlich machen können.
Gleichzeitig wird ein Kunde, der den Wunsch nach einer Software mit diesen oder jenen Funktionen geäußert hat, seine Meinung ändern, da er über seinen Bedarf nachdenken, sich mit ihm abstimmen und ihn reifen lassen muss.
Auch wenn die Schätzungen auf den ersten Blick beruhigend wirken und den Eindruck von Kontrolle vermitteln, sind sie eine Falle, die sich nach und nach um den Kunden schlingt. Schließlich lehnt der Anbieter jeden Vorschlag zur Weiterentwicklung der Software unter dem Vorwand ab, seine Verpflichtungen einhalten zu müssen.
Ist der Bedarf an Schätzungen weniger eine berufliche Notwendigkeit als vielmehr das Zeichen eines Misstrauens (des Kunden gegenüber seinem Dienstleister oder des Managers gegenüber seinen Teams)?
Wenn die "Deadline", die tödliche Grenze, nicht eingehalten wird, werden "Killermails" verschickt, weil die Leute "den Kopf auf dem Hackblock haben". Eine tödliche Kultur, in der Angst die Grundlage des Managements ist.
Im Gegensatz zu einer Kultur, die auf Eigeninitiative, Neid und positiver Verstärkung beruht, die Unternehmen in ihren Organisationen so dringend benötigen.
Die "No Estimate"-Bewegung
Die "No Estimate"-Bewegung ist keine Utopie, und diejenigen, die sie täglich praktizieren, wissen das.
Wichtig ist die Relevanz der Funktionen für die Nutzer und der Wert, der durch die Software für den Kunden geschaffen wird.
Dies erfordert jedoch Mut, um die etablierte Ordnung in Frage zu stellen, und viel Fantasie, um alles neu zu erfinden: den Verkauf, die Vertragsgestaltung, die Interaktion zwischen Kunden und Anbietern, aber auch das Management der Entwickler und das Projektmanagement.
Mit "no estimate" können die Kunden ihre Projekte sehr fein steuern, um die Funktionen zu erhalten, die sie wirklich brauchen. Sie werden während der gesamten Laufzeit des Projekts betreut, unabhängig davon, in welche Richtung das Projekt geht.
Geben wir dem Kunden die Macht zurück, die ihm zu lange genommen wurde: seine Meinung über sein Projekt zu ändern.
Autorin: Frédéric LeguédoisAgilist, Evangelist, Leiter der Abteilung Agile bei Cloud Temple Grand Ouest
Siehe den Artikel der Echos.fr zu diesem Thema