Die 5 Gründe, warum große IT-Projekte nicht zustande kommen

Große Projekte dauern ewig, werden nie fertig und verlieren an Relevanz, bevor jemand sie nutzt. Dinge zu bauen, die niemand nutzt, ist eine Verschwendung von Zeit und Geld, aber wir geben ein Vermögen dafür aus, immer und immer wieder. Es gibt einen besseren Weg.

Viele große IT-Projekte scheitern. Die Standish Group hat es recherchiert. Sie brauchen nicht den ganzen Artikel zu lesen hier zu dem Schluss, dass diese Tabelle alles sagt:

Dieser Artikel beschreibt die fünf Gründe, warum große IT-Projekte nicht zustande kommen, und was Sie dagegen tun können, einschließlich:

- Was Sie planen sollten und was nicht

- Wie Sie mit den Erkenntnissen umgehen, die Sie auf dem Weg gewonnen haben

- Wie Sie sicherstellen, dass die richtigen Dinge gebaut werden

- Wie Sie schmerzhafte, große Entlassungen vermeiden

Die 5 Gründe, warum große IT-Projekte nicht zustande kommen:

1- Sie können nicht schätzen

Bei großen Projekten gibt es viele Details, und es ist unmöglich, alle zu kennen. Sie stoßen immer auf Überraschungen. Sie können nicht abschätzen, Sie können nur raten und schon gar nicht das Unbekannte abschätzen.  Richtiges Schreiben von User Stories hilft, aber Sie können nicht an alles denken, bevor Sie beginnen. Je weiter Sie in das Projekt einsteigen, desto mehr User Stories tauchen auf, bis Sie gar nicht mehr wissen, was alles zu tun ist, um das Projekt fertigzustellen. Außerdem,  Versuchen Sie nicht, mehr als einen Monat Arbeit zu veranschlagen. So ziemlich jedes Projekt, an dem ich je gearbeitet habe und das länger als einen Monat gedauert hat, war überfällig. Der Teufel steckt im Detail.

2- Sie können nicht wissen, was Sie bauen sollen

Während der Entwicklung eines Projekts lernen sowohl das Unternehmen als auch die IT-Abteilung eine Menge. Wir lernen dabei und lassen uns dabei inspirieren. Die Ergebnisse führen zu neuen Möglichkeiten. Wir entdecken, was funktioniert und was nicht, sowohl in technischer als auch in geschäftlicher Hinsicht. Wir lassen uns hinreißen. Wir vergessen das minimal lebensfähige Produkt und fangen an, Dinge zu bauen, die wir nicht brauchen. Bevor wir es merken, sind wir wie Hunde, die ihren Schwanz jagen. Wir ertappen uns dabei, wie wir die Dinge zu sehr verbessern.  Wissen, wann man aufhören muss. Gut genug ist das neue perfekt!

Es ist schwer zu erkennen, wie groß der Umfang eines großen Projekts ist. Der Umfang explodiert, wenn der Kunde und das Team feststellen, dass es so viele weitere Randfälle gibt, die behandelt werden sollten. Oder wenn wir erkennen, dass viele weitere technische Aspekte, an die wir noch nicht gedacht haben, ebenfalls wichtig sind.  Das Schreiben von Geschichten reicht nicht aus, Sie müssen stattdessen Prototypen erstellen. Verwenden Sie Spikes, Design-Sprints oder sogar Skizzen anfertigen, um diese Erkenntnisse zu sammeln, bevor Sie mit dem Bau beginnen.

3 - Es ist zu spät, etwas zu ändern

Der Kunde beschreibt seine Wünsche. Das Team hört zu, versteht und antwortet mit einem Stück Software. Doch das Ergebnis ist immer eine Interpretation der Entwickler, die sich oft (leicht) von dem unterscheidet, was der Kunde eigentlich wollte. Nach einem Monat liefern Sie das Produkt aus und debattieren darüber, ob Sie das, was falsch ist, ändern oder akzeptieren sollen, weil es zu sehr im System verstrickt ist, um es zu beheben.

Menschen missverstehen sich im Allgemeinen gegenseitig. Akzeptieren Sie diese Tatsache und gehen Sie damit um. Machen Sie Annahmen sichtbar, damit Sie sie überprüfen können.  Schreiben Sie kleine User Stories, die zu kleinen, sichtbaren Änderungen führen. Überprüfen Sie die erstellten User Stories kontinuierlich während des Sprints. Beziehen Sie die Geschäftswelt mit ein; laden Sie sie zum Sprint-Review ein. Ja, all dies braucht Zeit, aber zum Tango gehören immer zwei.

4 - Wenn es endlich fertig ist, interessiert es niemanden mehr

Betrachten Sie Ihr Entwicklungsteam als ein Einzelhandelsgeschäft für den Kauf von Software - unverkaufte (nicht ausgelieferte) Produkte im Regal zu haben, ist Verschwendung. Ein nicht ausgeliefertes Produkt zahlt die Rechnungen nicht. Verspätete Lieferungen sind wie das Anvisieren eines beweglichen Ziels. Der Kunde brauchte gestern eine Lösung, nicht erst nächstes Jahr.  Wenn das Entwicklungsteam ein Problem nicht rechtzeitig behebt, wird der Kunde eine andere Lösung finden. Die Menschen finden verschiedene Wege, um Probleme zu lösen, die sie verlangsamen, die sie ärgern oder die Geld kosten. Vielleicht tut es eine coole neue App, und bevor Sie sich versehen, sind Sie aus dem Geschäft.

Entwickeln Sie kleine Lösungen und liefern Sie sie so schnell wie möglich.

5 - Freigeben ist ein Alptraum

Eine Veröffentlichung ist schwieriger, wenn sie nicht regelmäßig erfolgt. Große Veröffentlichungen sind komplexer. Konfigurationsänderungen, Infrastruktur, SSL-Zertifikate und andere Dinge müssen alle installiert werden. Es entstehen umfangreiche Checklisten, die in einer genauen Reihenfolge abgearbeitet werden müssen.

Das Produkt wird vielleicht regelmäßig an eine Testumgebung und gelegentlich an eine Abnahmeumgebung geliefert, so dass die Installationsroutine für jede dieser Umgebungen anders ist. Was ist mit der Zusammenführung all dieser Zweige - ganz zu schweigen von der Migration.  Arbeiten Sie stammbasiert und verwenden Sie Feature-Flags, um Funktionen auszublenden, die noch nicht verfügbar sein sollten.

Liefern Sie das Produkt kontinuierlich aus. Die Veröffentlichung sollte eine Routine sein. Kleine Versionen können leicht korrigiert werden, da der Umfang der Änderung (und auch der Korrektur) nicht zu groß sein darf. Automatisieren Sie die Freigabe und das Testen.  Machen Sie das Loslassen zum Kinderspiel.

-

Die Quintessenz? Arbeiten Sie nicht an großen IT-Projekten. Die werden nie fertig. Arbeiten Sie stattdessen an kleinen Projekten, damit Sie vom ersten Tag an brauchbare Dinge herausbringen können. Weniger ist mehr! Lösungen, die gestern noch geplant waren, sind morgen vielleicht schon nicht mehr aktuell. Planen Sie auch nicht mehr als einen Monat Arbeit ein. Stellen Sie sicher, dass das Team und der Kunde einander verstehen. Holen Sie so schnell wie möglich und kontinuierlich Feedback ein. Fügen Sie dem Produkt immer wieder kleine Verbesserungen hinzu und geben Sie es in die Produktion, sobald es gut genug ist. Machen Sie das Freigeben und Testen zur Routine.

-

Haben Sie trotz all Ihrer Bemühungen immer noch Schwierigkeiten, hochwertige Software in Produktion zu bringen, wann immer Sie wollen? Fehlt Ihnen das Vertrauen in Ihr bestehendes System, um es nicht vollständig zu automatisieren?
Finden Sie alle Ihre Antworten hier

Es geht nicht nur darum, DevOps-Teams zu bilden, agil zu arbeiten und Pipelines für kontinuierliche Integration und kontinuierliche Lieferung (CI/CD) einzurichten. Machen Sie sich bereit für die letzten Schritte. Xebia hilft Ihnen, das nötige Vertrauen in Ihren gesamten Softwareentwicklungsprozess zu gewinnen.