Dies ist für Unternehmensmanager oder Berater, die planen, Software mit einem externen Team (also über eine Agentur) zu entwickeln.
Agile bedeutet nicht schnell!!
Oft ist es das, aber es gibt auch Fälle, in denen es nicht so ist (z.B. wenn du viele Änderungswünsche hast).
Dies ist jedoch ein häufiges Missverständnis bei Managern, die denken, sie wüssten, was es ist, aber es nicht tun.
In sehr kurzen Worten bezieht sich AGILE auf Methoden, bei denen es um Kommunikation, Flexibilität und die bestmögliche Qualität auf dem schnellsten Weg zu einem zufriedenen Kunden geht. Siehe das Agile Manifesto hier.
Denke auch daran, dass agile nicht unbedingt bedeutet, irgendeine Art von Scrum zu verwenden!
WASSERFALL hingegen bezieht sich auf den bekannten Prozess, bei dem der Kunde definiert, was er/sie will, das Entwicklungsteam dann viel Zeit damit verbringt, jedes Detail davon aufzuschreiben, dieser Vorschlag vom Kunden unterschrieben wird, die Software entwickelt und schließlich ausgeliefert wird.
Wenn jemand am Anfang etwas vergessen hat, wenn sich der Markt oder der Geschäftsfeld geändert hat oder etwas anderes passiert, wäre ein neues Projekt für eine neue Softwareversion erforderlich.
Jetzt, da dies klar ist, schauen wir uns AGILE vs. WASSERFALL bei der Arbeit mit externen Entwicklungsteams genauer an.
Internes Produktmanagement
Mit einem internen Produktmanager, der das Projekt steuert, solltest du immer versuchen, agil zu arbeiten, weil es die natürlichere Art ist, diese Dinge zu tun.
Softwareentwicklung kann nicht mit dem Kauf einer Maschine verglichen werden. Es muss mit einem F&E-Projekt verglichen werden.
Dennoch liegt das Risiko für Budget, Zeit und Qualität ganz auf deiner Seite.
In diesem Szenario hast du im Grunde nur ausgelagerte Entwickler. Wenn du kein internes Entwicklungsteam hast, ist dies vielleicht das beste Setup.
Externes Produktmanagement
Ohne einen internen Produktmanager sprechen wir davon, den gesamten Prozess von einem externen Team zu kaufen.
Das Risiko liegt jetzt auf deren Seite, aber beachte die Projekttypen (der „Kunde“ bist du):
Agile
Die Arbeit mit agilen Methoden ist oft (nicht immer!) schneller bei einer viel höheren Flexibilität.
Du erhältst auch oft eine höhere Qualität, weil das Team neue Erkenntnisse auf dem Weg umsetzen kann.
Normalerweise ist das Ergebnis auch näher an deinen Erwartungen, wegen dieser Flexibilität.
Das Timing kann kritisch sein, wenn etwas Neues auftaucht oder sich ändert.
Denke daran, hier große Puffer für Fristen einzuplanen.
Die Kosten sind niedriger, wenn man das gleiche Projekt mit einer Wasserfall-Methodik vergleicht.
Der Nachteil hier ist, dass es nicht möglich ist, das Budget fair und vollständig im Voraus zu berechnen. Ich weiß, das ist der Albtraum jedes Controllers, aber der Preis, den man für einen niedrigeren Preis bei höherer Qualität zahlen muss.
Prozess:
Denke daran, dass dies nur ein grober Überblick über einen Beispielprozess ist. Besonders bei agilen Ansätzen hast du viele Möglichkeiten, ihn an deine Bedürfnisse anzupassen.
- Research:
Mehr über die Benutzer und manchmal sogar den Markt und den Geschäftsfeld herausfinden. - Requirements Workshop:
Die allgemeinen Anforderungen definieren. - Konzept:
Prozesse, die allgemeine Architektur, die Arbeitsströme und Schritte definieren. Manchmal sogar das UI und Design. - MVP Entwicklung:
Schnell zu einer ersten Version kommen. Dies geschieht normalerweise ohne größere Anpassungen während der Entwicklung. - MVP Test:
Diese Version gegen den Markt oder zumindest die Erwartungen des Kunden testen. - Feinabstimmung der Anforderungen:
Anforderungen basierend auf neuen Erkenntnissen oder Änderungen anpassen. - Konzept-Update:
Das ursprüngliche Konzept und die Strategie aktualisieren, wo nötig. - Agile Entwicklung:
Das MVP mit mehr Funktionalität und Features bereichern, während man engen Kontakt zum Kunden hält, jeden Schritt hinterfragt und schnell auf Änderungen und Erkenntnisse reagiert. - Launch der Version 1 — normalerweise gefolgt von einer Art weiterer laufender Entwicklung oder zumindest Wartung. Manchmal wird das Projekt an ein anderes (internes) Entwicklungsteam übergeben.
Vergütung und Planung:
- Pay as you go.
- Pay as you go mit einem monatlichen und/oder wöchentlichen Limit.
- Eine feste monatliche oder wöchentliche Gebühr zahlen, aber ohne ein bestimmtes Projektende. Das Team würde arbeiten, bis das Geld aufgebraucht ist, dann warten.
Wasserfall
Ein gutes Wasserfall-Softwareprojekt erfordert mindestens zwei getrennte Projekte.
Ein Teil, bei dem du die Anforderungen bestimmst (oft kombiniert mit Marktforschung) und ein Konzept für den zweiten Teil entwickelst.
In diesem zweiten Teil wird das Konzept umgesetzt.
Wenn dies in einem Schritt zu einem Preis erfolgt, zahlst du entweder viel zu viel, hast Glück und findest eine unerfahrene Agentur (willst du das?), oder erhältst wirklich schlechte Qualität und Ergebnisse (das ist die häufigste Konsequenz).
Solche Projekte dauern normalerweise länger (zumindest für die erste Version).
Du erhältst oft nicht das, was du erwartet hast, und es gibt keine Flexibilität, etwas im Plan zu ändern, bis es fertig ist (es sei denn, du stoppst und startest das Projekt neu mit neuen Kosten, was im Grunde irgendwie agil ist, aber teurer). Das Budget wird immer eingehalten, solange du keine Änderungen benötigst — normalerweise tust du das. Das Gleiche gilt für Fristen.
Diese Projekte kommen jedoch oft mit schlechter Qualität, weil Kunden den Preis im Voraus senken, was dazu führt, dass das Entwicklungsteam einige wichtige Schritte im Hintergrund überspringt.
Du bekommst immer das, wofür du bezahlst!
Prozess:
- Erste Anforderungsbewertung:
Die grundlegenden Bedürfnisse des Kunden definieren. - Vorschlag:
Ein Preis für (hoffentlich) nur Teil 1. Wenn du danach gefragt hast, erhältst du einen Preis für alle Teile. - Vorschlagsanpassung:
Du möchtest einige Teile streichen und über den Preis verhandeln, bis er akzeptiert wird. - Teil 1:
Normalerweise viele Workshops, um alle Anforderungen abzuleiten. Erfordert viel Arbeit von beiden Seiten. Das Entwicklungsteam wird auch bereits alle technischen Details evaluieren und einige technische Tests an den komplizierteren Teilen durchführen.
Am Ende erhältst du ein Konzept. - Zusätzlicher Vorschlag für Teil 2:
Wenn du vorher keinen hattest, erhältst du ihn jetzt. Wenn du vorher einen hattest, könntest du hier einen neuen erhalten, wenn sich etwas geändert hat (außer die Änderungen sind zugunsten des Entwicklungsteams). - Teil 2: Es wird gebaut. Normalerweise ohne jede Möglichkeit für dich, einzugreifen.
Am Ende erhältst du das Endprodukt, oft kombiniert mit Dokumentation und Schulung. - Anpassungen:
In 90% aller Fälle bist du mit den Ergebnissen nicht zufrieden und musst zusätzliche Anpassungen zu zusätzlichen Kosten anfordern.
Vergütung und Planung:
Erster Teil:
Dies sollte mit vielen Workshops und Anpassungen geschehen. Du solltest eher einen Teil 1b hinzufügen, wenn du mehr Zeit benötigst, als zu schnell voranzugehen. Alle Projekte, die ich kenne, die zusätzliche Konzeptionierung hier übersprungen haben, hatten am Ende große Probleme (fehlende Funktionalität, falsche Strategie, schlechte Qualität).
Ein Festpreis ist also möglich, aber denke auch daran, pro Stunde zu bezahlen — vielleicht mit einem Limit.Zweiter Teil:
Wenn der erste Teil bis zu einem detaillierten Konzept ging, kannst du hier einen 100% fairen Festpreis erhalten.
Wenn der erste Teil fest war, solltest du hier einige Probleme erwarten (zu teuer oder schlechte Qualität).Denke an die zusätzlichen Kosten für Folgeanpassungen, da harte Schnitte (Budget und Zeit) fast immer dazu führen, dass deine Erwartungen hier nicht erfüllt werden.
Lustige Sache: Die meisten Controller sehen Wasserfall als die Option, die einfacher zu berechnen ist. Die Wahrheit ist, es ist einfacher für sie, aber in Bezug auf Zeit und Geld immer noch schlechter für das gesamte Geschäft.
Entscheidungshilfe
Die folgende Grafik kann dich durch deinen Entscheidungsprozess führen.
Profi-Tipp
Dies geht sogar an erfahrene Manager!
Sage immer allen, dass Technologieprojekte nie so funktionieren, wie sie es zuerst erwarten.
Auch wenn dies nicht wahr ist, in dem Sinne, dass du erfahren bist, weißt, was auf dich zukommt, und nur wenn es richtig geplant und ausgeführt wird, bietet dir diese Aussage etwas mehr Freiheit — und du wirst diese Freiheit brauchen, weil viele Leute immer noch glauben, dass die Erstellung einer Software von Grund auf das Gleiche ist wie der Kauf eines Druckers 😉.
