Ich arbeite in einem mittelständischen Unternehmen als CTO, die Geschäftsseite des Unternehmens sendet durchschnittlich 5 Angebote pro Tag, die in Bezug auf Arbeitszeit und Kosten für jedes Angebot geschätzt werden müssen.
In dieser Phase weiß ich noch nicht, welches Team für das Projekt eingesetzt wird, da die Unterzeichnung der Vertragsphase im Durchschnitt mehr als 5 Monate dauern kann.
Das Problem, das mich seit 1 Jahr bis jetzt beschäftigt, ist der Konflikt zwischen der Schätzung der mit dem Kunden unterzeichneten Frist und der vom Product Owner und dem Team geplanten Frist, die manchmal bis zu 2x variieren kann, was Zeit-, Kosten- und Vertrauensverlust bedeutet mit den Kunden.
Meine Frage ist, was ist die beste Vorgehensweise bei der Schätzung der Projekte, während das Projekt den Kunden vorgeschlagen wird, wenn man bedenkt, dass Kosten und Preise in dieser Phase verfügbar sein müssen, da dies die Faktoren sind, mit denen die Kunden die Vorschläge vergleichen?
Wir verfolgen im Unternehmen eine agile Methodik, daher muss dies ebenfalls berücksichtigt werden
Dies scheint in letzter Zeit ein häufiges Fragethema zu sein. Ähnliche Fragen habe ich kürzlich in diesem Thread und in diesem Thread beantwortet .
Es gibt drei Hauptprobleme, die um Sie herumwirbeln.
Schätzungen sind nur Vermutungen: In den 80er und 90er Jahren haben wir irgendwie das Konzept " [Cone of Uncertainty][3]" beim Schätzen vergessen. Wenn Sie ein Projekt zum ersten Mal schätzen, haben Sie Glück, wenn Sie sogar zu 50% genau sind. Und wenn nicht, dann wird es immer später sein. Sie werden die zu erledigende Arbeit fast nie überschätzen, dank Hofstadters Gesetz , das im Grunde besagt: „Wir unterschätzen immer, auch wenn wir wissen, dass wir es immer tun.“ Der einzig wahre Weg, um zu wissen, wann (umfangsgesteuert) oder was (zeitplangesteuert) Sie für ein Projekt liefern werden, besteht darin, damit anzufangen und dann mithilfe der Velocity entweder das Wann oder Was vorherzusagen.
Umfang vs. Zeitplan: Ich empfehle dazu meine kurze Slideshare-Präsentation . Ich habe vollständige Sprechernotizen eingebettet, um jede Folie zu erklären. Es ist eine großartige Möglichkeit, Scope vs. Schedule visuell zu erklären, damit Kunden und Teams es verstehen. Meine persönliche Empfehlung, die auf jahrelanger agiler Entwicklung basiert, ist, sich immer für ein zeitgesteuertes Release mit einem MVP zu entscheiden, das nicht mehr als 80 % dessen entspricht, was Sie für Ihre Release-Linie halten.
Release-Linien vs. MVP-Linien : Wir alle sind mit dem Begriff des minimal lebensfähigen (oder wertvollen) Produkts vertraut. Ich sehe jedoch eine Menge Unterschiede darin, was die Leute denken, was die Definition ist. Ich gehe normalerweise mit diesem „Wenn wir MVP nicht erreichen, würden wir den gesamten Code wegwerfen und das Produkt überhaupt nicht veröffentlichen“ und „MVP ist, was der Kunde braucht, damit das Produkt nützlich ist?“. Ich zitiere normalerweise das Original-iPhone. Es hat kein BlueTooth gemacht, es hat nicht ausgeschnitten und eingefügt, es hatte keine wirklichen Apps, von denen man sprechen könnte. Und doch hat es genau die Kundenanforderungen erfüllt (ein dreckig einfaches Telefon mit einer idiotensicheren Benutzeroberfläche, die Telefonanrufe, E-Mails und einfaches Surfen im Internet ermöglicht).
Release Line ist ein Begriff, von dem wir zu wenig hören und der dazu führt, dass wir auf so viele Probleme mit MVP-definierten Projekten stoßen. Wir werden sagen „das sind die MVP-Merkmale“ des Projekts und „Wir müssen bis August liefern“, aber wir schauen uns dann selten an, was unserer Meinung nach die Technik tatsächlich leisten kann. Im Abschnitt Zeitplan meiner Präsentation zeige ich das Worst-Case-Szenario, bei dem das Team weniger als das MVP liefert, weil der Product Owner das MVP als genau das definiert hat, was die Ingenieure für möglich hielten.
TU das niemals. Immer unter Commitment und Over Delivery. Wenn Sie glauben, dass Sie 10 Funktionen liefern können (technische Schätzung), verpflichten Sie sich im Zeitplan nicht zu mehr als 6. Dies ermöglicht zwei sehr reale Dinge. 1- Sie haben den Arbeitsaufwand unterschätzt. 2- Ihr Kunde/Product Owner ändert seine Meinung und fügt während der Entwicklung neue Funktionen hinzu.
Abschließend Geduld und agiler Wert 3 : Wir versuchen, dreißig Jahre schlechter Projektplanung und Erwartungen, dass ein Kostenvoranschlag eine Verpflichtung ist, umzukehren. Wir werden es nicht über Nacht ändern. Denken Sie also immer an Agile Value 3 – Customer Collaboration over Contract Negotiation. Bleiben Sie in ständiger Kommunikation mit Ihren Kunden und seien Sie absolut ehrlich und transparent. Wenn Sie glauben, dass es auch nur die Möglichkeit einer Verzögerung gibt, sagen Sie es ihnen sofort. In den letzten sieben Jahren habe ich dieses Modell verwendet. Meine Kunden (intern und extern) lieben die totale Transparenz und sind viel toleranter gegenüber Problemen, weil ich so oft wie täglich kommuniziere. Wenn Sie sehen können, wie die Wurst hergestellt wird, machen Sie sich weniger Gedanken darüber, das Endprodukt zu essen.
Jedes Softwareentwicklungsprojekt ist mit Ungewissheit verbunden. Die beiden Hauptgründe dafür sind Anforderungsänderungen und technische Risiken.
Diese Ungewissheit macht es sehr schwierig, im Voraus abzuschätzen, und je länger das Projekt dauert, desto schwieriger wird es. Dies wird durch den Unsicherheitskegel beschrieben .
Sie haben mehrere Möglichkeiten:
Der agile Ansatz legt nahe, dass die letzte Option die beste ist: „Kundenzusammenarbeit vor Vertragsverhandlung“.
Ein Ansatz besteht darin, Zeit- und Materialverträge auszuhandeln, bei denen die Kunden nach Bedarf bezahlen. Es erscheinen auch einige agile Verträge , die Sie vielleicht in Betracht ziehen möchten.
Die Lücke zwischen Verkauf und Lieferung existiert überall und wird nie verschwinden. Die Verkaufsseite Ihres Unternehmens muss die Arbeit verkaufen und wird, wie es bei vielen Verkäufen üblich ist, zu viel versprechen. Außerdem müssen sie die Arbeit wettbewerbsfähig bepreisen, da der Preis ein wichtiger Faktor für die Kaufentscheidung eines Kunden ist. Die Bereitstellungsseite Ihres Unternehmens möchte das Projekt mit den erforderlichen Ressourcen, der erforderlichen Zeit und mit einem guten Schuss Reserven für alle Fälle erfolgreich abschließen, was häufig zu unzureichenden Aussichten führt. Diese beiden Ziele zwischen Verkauf und Lieferung sind widersprüchlich.
Sie müssen die Lieferseite Ihres Hauses haben, um die Befugnis zu haben, das Projekt zu "nixen", wenn die Verkaufsseite zu vielversprechend ist. Sie brauchen einen Governance-Prozess, der einen Konsens anstrebt, bevor ein Angebot an den Kunden geliefert wird. Dieser Prozess soll/kann dazu beitragen, die zu vielversprechende Verkaufsseite abzukühlen und gleichzeitig die kostspielige Überallokation auf der Lieferseite abzukühlen und Ihnen zu einem Preis- und Kostenfall zu verhelfen, der näher an der Mitte liegt.
Das heißt, und selbst mit einem solchen Prozess gewinnt meiner Erfahrung nach normalerweise die Verkaufsseite (Sie müssen verkaufen, um Arbeit zu haben), und die Lieferseite bleibt mit der Tüte in der Hand. Eine gute Nachricht für Sie ist, dass Sie in diesem Kampf nicht allein sind.
Danny Schoemann
Ewan