Nur wenige finden einen Ausweg, manche sehen ihn nicht, selbst wenn sie ihn finden, und viele suchen nicht einmal danach.
Von Alice im Wunderland
Der Artikel wirft die folgenden Fragen auf.
- Zur Inkonsistenz der Komponenten der Outsourcing-Formel 'Scrum + Fixed Price'.
- Ein möglicher Fehler (Grundursache) vor der falschen Auswahl des Scrum-Tools.
- In einer Situation, in der es wirklich darum geht, Scrum und Festpreis zu kombinieren, was eine gründliche Analyse und Kompromisse erfordert, um das Problem zu lösen.
Der Artikel geht auf einen sehr kontroversen Punkt ein, der keinen eindeutigen Standpunkt hat und Gegenstand endloser Diskussionen ist. Denken Sie daher beim Lesen bitte daran, dass Ihre Meinung möglicherweise nicht mit der vorgestellten übereinstimmt. Dies bedeutet jedoch keineswegs, dass einer von uns absolut Recht hat und dass jemand absolut falsch liegt.
Wie im Artikel „So starten Sie Pseudo-Scrum beim Outsourcing“ angegeben , wird bei einer Vielzahl von Outsourcing-Projekten, deren Teams Scrum und Festpreis kombinieren (oder möglicherweise Wunschdenken), der Projektlebenszyklus (LC) nicht korrekt identifiziert. Jene. Bei der Wahl zwischen einem iterativen inkrementellen oder einem flexiblen Lebenszyklus wurde ein Fehler gemacht. Infolgedessen wurde das falsche Management-Tool ausgewählt - das Scrum-Framework. Und bereits eine Folge dieser Wahl ist das Auftauchen einer Reihe von Problemen, falschen Schlussfolgerungen über Agile, Scrum und Versuchen (aus dem Wort "Folter"?), Diese beiden sich gegenseitig ausschließenden Konzepte zu kombinieren.
Sich gegenseitig ausschließen ?!
Jetzt streite ich.
Es wird davon ausgegangen, dass der Leser mit den Materialien des obigen Artikels besser vertraut ist.
Scrum + Fixed Price – , ?
, , .Beim Abschluss eines Vertrags über die Erbringung von Outsourcing-Dienstleistungen besteht der Kunde fast immer auf einem Festpreis (schlüsselfertiges System). Sein Wunsch ist es, den Produktumfang (oder den Arbeitsaufwand) festzulegen, das Budget und die Fristen zu sehen. Er will sehen, was er "kauft". Kunden stimmen Zeit und Material selten zu.
“ ”
Daher ist der entscheidende Punkt: Der Bedarf des Kunden muss im Vertrag festgelegt werden, und der Dienstleister muss die vertraglichen Verpflichtungen erfüllen und sicherstellen, dass die Parameter nach Beginn der Entwicklung mit einem vorhersehbaren Fehler (aufgrund eines gewissen Maßes an Unsicherheit und Risiken in den Phasen des Verkaufs und des Vertragsabschlusses) unverändert bleiben. Das Problem der Verringerung des Maßes an Unsicherheit und Risiken ist das Problem der Durchführbarkeit und Qualität der Discovery-Phase (Vorverkauf, Diagnose) in Bezug auf den Produktumfang.
Es liegt auf der Hand, dass wir, wenn wir etwas reparieren (wir garantieren es dem Kunden im Rahmen des Vertrags), es so planen und verwalten müssen, dass die Erfüllung unserer Verpflichtungen gewährleistet ist. Jene. Verwalten Sie den Plan (oder die festen Merkmale des Projektdreiecks).
Der Festpreis verpflichtet uns lediglich, das Planmanagement zu priorisieren. Warum sollten wir sonst etwas reparieren, im Voraus wissen, dass es sich ändern wird, und wir planen nicht wirklich, es zu verwalten? Um einfach einen Vertrag zu unterschreiben? Ein kritischer Fehler in etablierten Verkaufsprozessen: Wir beheben ihn, da wir im Voraus wissen, dass wir ihn ändern werden, nur um einen Vertrag zu unterschreiben!
Warum werden wir uns ändern? Denn bei Scrum geht es immer um Unsicherheit und deren Ergebnis - Veränderung. Hier geht es um die Priorität des Änderungsmanagements. Und es ist möglich, dass sie nach dem ersten Sprint erscheinen. Warum?
Ein Exkurs über mögliche Gründe für die Änderung
Was könnte der Grund für die Änderung sein? Zum Beispiel kann es sich in einer schlecht durchgeführten Discovery-Phase (Vorverkauf, Diagnose) befinden, in einer Situation, in der der Produktumfang bis zu einem gewissen Grad definiert werden kann (ein Beispiel finden Sie in Abschnitt 3 der Fallstudie im Artikel ), aber wofür Aus irgendeinem Grund wurde dies nicht getan. In diesem Fall ist dies ein Problem der Phasen- und internen Prozesse und nicht der Grund für die Wahl von Scrum für einen Festpreisvertrag, einen flexiblen Lebenszyklus anstelle eines iterativen, um den gemachten Fehler zu kompensieren.
Obwohl ich fairerweise feststelle, dass beim Verkauf (Vorverkaufsaktivitäten von Geschäftsanalysten) beim Outsourcing (eine der problematischsten Phasen aus Sicht des Produktumfangs!) Nicht alles so einfach ist wie in einem Geschäft, wenn ein fertiges Produkt mit bestimmten Eigenschaften gekauft wird (Funktionalität). Und die Discovery-Phase ist eine schwer zu verkaufende Aktivität von Geschäftsanalysten und -teams. Die Minimierung der Unsicherheit auf die eine oder andere Weise und die Bewertung von Risiken ist jedoch eine der Hauptaufgaben eines gut aufgebauten Verkaufsprozesses. Sowie die Bildung eines Verständnisses im Klienten über die Notwendigkeit und Wichtigkeit dieser Aktivitäten (es kann sehr schwierig sein!). Dafür gibt es jedoch eine ausreichende Anzahl von Techniken und Werkzeugen. Und es kommt auf die Qualität der erbrachten Dienstleistungen an und nicht auf den Verkauf eines "Schweins im Sack".
Ein weiterer Grund kann die Unfähigkeit sein, den Produktumfang und die Vision zum aktuellen Zeitpunkt zu bestimmen (ein Beispiel finden Sie auf Seite 2 aus der Fallstudie im Artikel ). Und dies ist in der Tat eine sehr schwierige und ungünstige Situation für beide Parteien, wenn ein ernsthafter Widerspruch auftritt und die Frage der Kombination von Scrum und Festpreis bei der Erbringung von Outsourcing-Dienstleistungen aufgeworfen wird. Es erfordert eine sorgfältige Analyse, zusätzliche Maßnahmen, um ein umfassendes Verständnis des Kunden (oft technisch und ideologisch weit entfernt von den Realitäten von Entwicklungsprozessen) über mögliche Schwierigkeiten und Risiken zu entwickeln, sowie die Suche nach Kompromisslösungen.
Warum wird Scrum gewählt? Um Änderungen zu verwalten, die beispielsweise aufgrund einer falsch durchgeführten Ermittlungsphase (Vorverkauf, Diagnose) auftreten oder wenn der Produktumfang in dieser Phase nicht bestimmt werden kann? Im ersten Fall ist dies meiner Meinung nach falsch. Im zweiten Fall ist die Implementierung mit Festpreis schwierig.
Die dritte mögliche Option für die Auswahl von Scrum als agiles Tool, ein flexibler Lebenszyklus anstelle eines iterativen inkrementellen, in einer Situation, in der der Produktumfang in der Discovery-Phase (Vorverkauf, Diagnose) und im Vertrag festgelegt und festgelegt wird - Festpreis -, ist meiner Meinung nach ebenfalls nicht rational: Warum wählen? ein Instrument zur Bewältigung von Veränderungen (Unschärfe ist eindeutig eine vorrangige Sache - ein Plan), wann wird ihre Wahrscheinlichkeit minimiert?
Kehren Sie zur Hauptidee des Artikels zurück.
Angenommen, Scrum wird ausgewählt. Auch hier ist Scrum ein Tool für das Änderungsmanagement, bei dem der Grad der Unsicherheit nur im Prozess und nur bei Verwendung geeigneter Ansätze verringert werden kann. Und dieser Rückgang ist das Ergebnis dieses Prozesses.
Der Festpreisvertrag hat jedoch Vorrang vor der Verwaltung des Plans!
Somit wird die 'Formel' 'Scrum + Festpreis' in 'Änderungsmanagement + Planmanagement gleichzeitig' umgewandelt. Die Aufgabe des Managers besteht darin, sowohl den Plan als auch die Änderungen in unterschiedlichem Maße zu verwalten. Es kann jedoch nur eine Priorität geben: entweder den Plan oder die Änderungen.
Entweder das Planmanagement oder das Änderungsmanagement ist eine Art Axiom, das in die Grundlagen des Managements und der Geschäftsanalyse eingebettet ist. Dies spiegelt sich in den grundlegenden (und nicht nur) Handbüchern für Manager (PMBOK) und Geschäftsanalysten (BABOK) wider. Und die Klassifizierung des Lebenszyklus (und ihre Identifizierung in Bezug auf bestimmte Projekte) hängt davon ab: Es gibt Lebenszyklen, die für die Verwaltung des Plans (z. B. Wasserfall, iteratives Inkremental (IID)) und flexibel, Agil für das Änderungsmanagement konzipiert sind. Die Wahl des Lebenszyklus (und anschließend der Werkzeuge) basiert auf der Priorität des Managements.
Der flexible Lebenszyklus ist eine Art iterativer inkrementeller Lebenszyklus für Projekte mit bestimmten dominanten Merkmalen / Merkmalen (eine Liste der Überprüfungsfragen finden Sie im obigen Artikel), sodass Sie es als separaten Lebenszyklus identifizieren und "alle Anstrengungen lenken" können, um das Management zu ändern. Diese Merkmale können zugeschrieben werden: die Unmöglichkeit des "Hier und Jetzt", ein gewisses Maß an Sicherheit für den Produktumfang zu erreichen (das Wichtigste!), Die Suche nach einer Geschäftslösung (oder deren schnelle Lieferung an das Unternehmen, um Feedback zu generieren), die "schießen" wird, die Bildung einer Liste von Schlüsselfunktionen Produkt (Hauptmerkmale), kurze Iterationen, Variabilität, Experiment, schrittweiser Aufbau von Funktionen, Rückblicke, Verbesserung nicht nur des Produkts, sondern auch der Prozesse, um die beste Version des Produkts zu erhalten. Ist es unter solchen Bedingungen möglich, angemessene Schätzungen des Budgets und der Bedingungen zu erhalten?
Der Teufel steckt in nur einem Detail, oder ... es geht nur um den Produktumfang
Alles hat seine eigene Moral, man muss es nur finden können!
Von Alice im Wunderland
Was können Sie über die Sicherheit (die Fähigkeit, sie zu etablieren) in Bezug auf Product Scope & Vision in der Verkaufsphase, der Discovery-Phase, zu Beginn des Outsourcing-Projekts sagen?
Wenn der Produktumfang aufgrund der Gründe für die Einzigartigkeit des Produkts, der Idee eines Start-ups, der Unsicherheit hinsichtlich der Wirksamkeit der getroffenen Geschäftsentscheidungen (der Notwendigkeit, sie zu finden) und der Schwierigkeit, die Schlüsselfunktionen des Produkts zu bestimmen, des Vorhandenseins von Hypothesen, die überprüft werden müssen, usw. nicht definiert, bewertet, festgelegt werden kann usw. ... (siehe noch einmal Punkt 2 der Fallstudie hier ), dann ist natürlich das Scrum-Framework das am besten geeignete Werkzeug.
Beim Outsourcing wird diese Situation jedoch durch den Wunsch des Kunden, bei Abschluss eines Vertrags das Festpreissystem zu verwenden, erheblich erschwert und erscheint für beide Parteien in einem ungünstigen Licht. Mit einigen Annahmen kann bis zu einem gewissen Grad ein Kompromiss bei der Auftragsvergabe und Verwaltung eines solchen Projekts erzielt werden. Es ist wichtig, das richtige Verständnis und die richtigen Erwartungen des Kunden (Investors) zu entwickeln, die Risiken zu bewerten, wenn möglich andere Systeme der finanziellen Interaktion zu berücksichtigen und bei der Projektumsetzung ständig mit der Kundenbindung usw. zu arbeiten. Ich werde mich nicht mit der Frage befassen, da sie den Rahmen des Artikels sprengt.
Beim Outsourcing liegt die Frage meist in erster Linie in der kompetenten Durchführung der Discovery-Phase (Vorverkauf, Diagnose) in Bezug auf den Produktumfang und der Wahl des richtigen Lebenszyklus. Und wenn Agile und Scrum in einer Situation ausgewählt werden, in der der Produktumfang festgelegt werden kann (und dies umso mehr, wenn dies aus irgendeinem Grund nicht rechtzeitig mit der Erwartung / Annahme seiner zukünftigen Entwicklung geschehen ist) und gleichzeitig im Vertrag - Festpreis, Meiner Meinung nach wird ein Fehler gemacht, der das positive Ergebnis des Projekts in Frage stellt.
Vielen Dank für Ihre Aufmerksamkeit!