20 gründe, warum Softwareprojekte scheitern
Jedes Softwareprojekt beginnt mit großen Träumen und großen Visionen. Irgendwo in einem alternativen Universum gibt es ein Projekt, das jeden Traum erfüllt, aber allzu oft stolpern Softwareprojekte in unserem Universum auf die Ziellinie zu und überqueren sie manchmal.
Natürlich ist das Scheitern von Softwareprojekten per Definition keine binäre Sache. Sie können mit Code enden, der gut läuft, aber niemand verwendet. Oder Sie können mit Code enden, der nicht einmal kompiliert wird. Manchmal kann man etwas Nützliches aus dem brennenden Wrack retten und manchmal ist es am besten, wegzulaufen, bevor es explodiert.
Wenn das schwelende Durcheinander abkühlt, beginnen die Autopsien, da die Leute wissen wollen, was schief gelaufen ist. Hier sind die häufigsten Schuldigen.
Zu wenige Teammitglieder
Der Versuch, mit zu wenigen Programmierern zu viel zu tun, ist ein häufiges Problem. Entwickler können nur so viel Code schleifen, bevor sie ausbrennen. Ich habe einmal in einem Team gearbeitet, in dem der Manager der Meinung war, dass der richtige Weg, um mehr Arbeit aus agilen Teams herauszuholen, darin besteht, jeden „Sprint“ so zu planen, dass er unmittelbar nach dem vorherigen beginnt. Keine nachdenklichen Pausen, um herauszufinden, was funktionierte und was nicht. Sprint 42 endete am Mittwoch um 1:59pm und Sprint 43 begann am Mittwoch um 2:00pm. Retrospektive Analyse-Meetings wurden geplant, nachdem der nächste Sprint bereits begonnen hatte. Ein kluger Kerl schlug vor, sie in „Marathons“ umzubenennen, und fand bald einen anderen Job.
Natürlich ist es schwer zu wissen, wie viele Programmierer genug sind. Manchmal stehen Straßensperren und Probleme im Weg. Es ist vielleicht nicht die Schuld des Managers, dass sich der Job verdoppelt, aber wenn Sie nicht genug Leute im Job haben, ist Ihr Projekt wahrscheinlich zum Scheitern verurteilt.
Zu viele Teammitglieder
Wenn zu wenige Programmierer schlecht sein können, könnten zu viele möglicherweise schlimmer sein, da Netzwerkeffekte ein Softwareprojekt zum Scheitern bringen können. Mehr Leute bedeuten mehr Koordination und das bedeutet mehr Meetings, die sich Zeit nehmen, Code zu schreiben. Wenn Sie jedoch nicht genügend Besprechungen abhalten, werden Sie bald feststellen, dass die API von Team A keine Schnittstelle zu den Microservices von Team B bietet.
Es wäre schön, wenn wir einfach Geld auf ein Problem werfen könnten, indem wir ein Projekt überbesetzen, aber das geht nicht.
Zu viel Kommunikation
Software schreiben ist eine einsame Kunst. Menschen können zusammenarbeiten, aber nur in begrenzten Kämpfen. Viele Entwickler hassen Meetings, weil sie ihre mentalen Gänge vom tiefen, immersiven logischen Denken in den offeneren, sozialen Modus verschieben müssen. Das braucht Zeit. Einige Teamleiter versuchen, Misserfolge zu bekämpfen, indem sie mehr Meetings abhalten, um alle synchron zu halten. Es ist eine edle Anstrengung, aber Sie können die Zahnräder schleifen hören. Das Team muss genügend Informationen austauschen, um synchron zu bleiben, aber mehr verschwendet nur Gehirnzyklen.
Grundlegende Funktionsänderungen
Theoretisch betrachten sich Entwickler gerne als agil. Deshalb umarmen sie das Wort. Aber manchmal kann Agilität jeden aus dem Gleichgewicht bringen. Es hängt alles davon ab, ob die Verschiebung grundlegende Änderungen am zugrunde liegenden Rahmen erfordert. Es ist einfach, agil zu sein, wenn Sie eine Taste bewegen oder eine Farbe ändern. Aber wenn es darum geht, das Datenbankschema zu überarbeiten oder mit Sharding und Replikation herumzuspielen, gibt es keine einfache Möglichkeit, anmutig zu schwenken.
Die falsche Technologie für den Job auswählen
Selbst wenn Sie sorgfältig planen und die richtige Liste von Funktionen erstellen, können Dinge fehlschlagen, wenn Sie die falsche Technologie verwenden. Datenbanken sind beispielsweise allgemein und flexibel konzipiert, weisen jedoch architektonische Einschränkungen auf. Schieben Sie sie dazu, etwas zu liefern, für das sie nicht ausgelegt sind, und sie werden praktisch zum Stillstand kommen, wenn sie zur Skalierung aufgefordert werden. Oder Sie beginnen mit einer NoSQL-Datenbank, weil sie cool klingen, nur um später festzustellen, dass Sie wirklich ACID-Grade-Transaktionen benötigen, um die Dinge konsistent zu halten, und die Datenbank bietet sie nicht an. Hoppla.
Schlechte Priorisierung
Gute Planer erstellen eine Liste von Features und priorisieren diese. Aber manchmal stimmen Prioritäten nicht mit der Realität ihrer Umsetzung überein. Im schlimmsten Fall sind die wichtigsten Funktionen am schwierigsten zu erstellen.
Was sollen Ihre Entwickler tun? Wenn sie sich auf das wichtigste Feature konzentrieren, machen sie keine Fortschritte und liefern möglicherweise keine der Funktionen. Aber wenn sie anfangen, die einfachen abzuschlagen, können sie mit etwas Wertlosem enden.
Gute Planung erfordert mehr als eine Checkliste. Die architektonische Vision muss die Bedürfnisse und Kosten ihrer Bereitstellung berücksichtigen.
Das Marktfenster wird geschlossen
Manchmal ist es nicht die Schuld des Programmierers. Eines meiner Projekte war es, ein Bestseller-Nachschlagewerk in eine App zu verwandeln. Das Buch verkaufte sich wie warme Semmeln in den Jahren vor dem Internet. Der Plan war, diese Nachfrage zu nutzen und eine interaktive Version zu erstellen, mit der die Daten sortiert und durchsucht werden können. Das Programmierteam lieferte Software, die alles im Buch enthielt, aber schneller, hübscher und viel leichter war als das Buch selbst. Aber niemand wollte es mehr. Es gab genug andere Quellen und niemand brauchte eine andere App, die das Gleiche tat wie Nachrichtenseiten überall.
Manchmal scheint eine Idee großartig, aber der Markt hat sich weiterentwickelt.
Schlechte Architekturentscheidungen
Bei einem Projekt wurde mir die Aufgabe übertragen, eine Nummer in einer Zeile in der Datenbank zu ändern. Als der Benutzer mit der Registrierung fertig war, sollte ich die ID-Nummer des Benutzers zur letzten Bestellung hinzufügen. Klingt einfach, oder? Das System basierte jedoch auf einer Microservices-Architektur, und ich konnte dies nicht lösen, indem ich eine Codezeile schrieb, in der die Datenbank angewiesen wurde, diese Spalte zu aktualisieren. Nein. Der architektonische Plan bestand darin, dem vorhandenen Stack einen neuen Microservice-Aufruf hinzuzufügen, und selbst dies war schwierig, da mein erster Microservice-Aufruf einen weiteren Microservice-Aufruf usw. auslösen musste.
Am Ende sagte mir der Architekturfan, der dieses Netzwerk von Microservices erstellt hatte, dass alles sehr einfach sei und skizzierte einen Serpentinenpfad durch fünf Schichten der Architektur. Meine Aufgabe war es, fünf neue API-Aufrufe zu fünf verschiedenen Microservices hinzuzufügen, was auch bedeutete, fünf Sätze automatisierter Tests für jede Schicht hinzuzufügen. Und jede API wurde im Laufe der Jahre von einem anderen Team entwickelt, sodass ich fünf verschiedene Codierungsstile verstehen und emulieren musste. Alles, um eine Nummer zu ändern.
Architektonische Entscheidungen können ein Leben lang halten – besonders wenn dein Ego gründlich in sie investiert ist und du sie nicht ändern kannst. Projektmanager müssen bereit sein zu bemerken, wenn der Hauptarchitekturplan nicht funktioniert, damit große Entscheidungen getroffen werden können.
Politische Konflikte
Politische Faktoren für ein technisches Versagen verantwortlich zu machen, mag unsinnig erscheinen, trifft aber zunehmend zu. Wenn Projekte größer werden und sich über mehrere Organisationen erstrecken, sollte es nicht überraschen, dass Fraktionen auftauchen und Gruppen um Kontrolle, Ressourcen und letztendlich Macht kämpfen.
Politische Fraktionen unterscheiden sich von realen technischen Unterschieden. Es gibt oft technische Standards oder Codebasen, die auf unterschiedliche Weise dasselbe tun. Nehmen Sie XML und JSON. Jetzt, wo ich das getippt habe, kann ich fühlen, wie die Fans von beiden hetzen, um zu erklären, warum sie nicht gleich sind und ihre Lieblingswahl die richtige ist. Aber wenn ein Teil eines Teams eine Wahl liebt und ein anderer die konkurrierende Fraktion in höchstem Maße respektiert, wird Reibung sie auseinanderreißen.
Dies ist noch häufiger geworden, da Architekten Anwendungen in mehrere kleinere Dienste und APIs aufteilen. Verschiedene Gruppen werden diese am Ende kontrollieren und sie werden nicht immer miteinander auskommen. Wenn Gruppe A JSON mag und Gruppe B sich an XML klammert, muss Ihr Team entweder beide implementieren oder eine davon ändern. Alle drei sind ein Schmerz für jedes Team, das sowohl mit Gruppe A als auch mit Gruppe B arbeiten muss.
Wetten auf Technologie, die nicht produktionsreif ist
Programmierer lieben die neuesten Tools und Frameworks. Sie wollen glauben, dass der neue Ansatz alle Cruft wegfegen wird, die die vorherige Generation nach unten mooren.
Aber oft ist die nächste Generation noch nicht serienreif. Die neuen Funktionen mögen perfekt erscheinen, aber es gibt oft Lücken, die nicht sofort offensichtlich sind. Manchmal unterstützt der Code nur wenige Dateitypen oder Schnittstellen mit nur wenigen Datenbanken. Die anderen kommen bald, versichern sie Ihnen, aber Ihr Projekt muss diesen Monat ausgeliefert werden und „bald“ könnte sechs oder mehr Monate bedeuten, bevor die Funktionen, die Sie benötigen, abgeschlossen sind.
Wetten auf Technologie, die bald veraltet sein wird
Meiner Erfahrung nach ist das alte Zeug normalerweise zuverlässiger und kampferprobter, aber das bedeutet nicht, dass alte Technologie perfekt ist. Es können Funktionen fehlen, die für Ihr Softwareprojekt von entscheidender Bedeutung sind, sobald es live geht. Schlimmer noch, Wetten auf alte Technologie können dazu führen, dass Sie zukünftige Chancen verpassen, die auf Änderungen auf der ganzen Linie basieren. Neue Ideen, Protokolle und Dateiformate tauchen auf und können nicht implementiert werden. Und wenn jemand aus einem konkurrierenden Team darauf besteht, dass Sie ein neues Protokoll unterstützen, wird die alte Technologie weh tun.
Unrealistische Fristen
Fristen sind schwierig. Viele Projekte müssen es zu einer bestimmten Jahreszeit oder einem bestimmten Ereignis auf den Markt bringen. Doch wenn Fristen zuerst aufgeschrieben werden, haben Ihre Entwickler noch nicht begonnen, die Straßensperren und Hürden auf ihrem Weg zu entdecken. Wenn dann das Projekt ausrutscht und das Ereignis vergeht, ohne dass die Software gestartet wird, wird das gesamte Projekt als Fehler angesehen, selbst wenn der Code gerade reibungslos ausgeführt wird. Fristen helfen allen, sich zu konzentrieren und an einem Strang zu ziehen, aber sie schaffen auch Erwartungen, die unrealistisch sein können.
Unvorhergesehene Konkurrenz
Ein guter Produktmanager überblickt die Konkurrenz, bevor er eintaucht, aber niemand kann vorhersagen, welche Konkurrenz aus dem Nichts erscheint. Wenn neue Wettbewerber neue Funktionen einführen, die Sie duplizieren müssen, lesen Sie die obigen Abschnitte zu Funktionsänderungen und Prioritätskonflikten.
Den Prozess beschleunigen
Viele Softwareprojekte beginnen als Vision einer Person oder eines Teams, die etwas reparieren möchte. Sie kommen mit einem Satz wie „Snapchat für Y“ oder „Uber für Y“ und erwarten dann, dass das Produktteam so reaktionsschnell ist wie Snapchat oder Uber. Das Problem ist, dass das Herausfinden des Projektumfangs, das Skizzieren der Datenflüsse und das Vorstellen der Benutzeroberfläche oft zehnmal so viel Arbeit erfordern wie das Schreiben des Codes. Aber die Imagineers wollen sofort von der Idee zum Code gehen.
Die Wireframes, das Datenbankschema und die User Stories sind nicht nur Handarbeit, sondern ein wesentlicher Bestandteil der Arbeit. Aber die meisten Leute wollen glauben, dass ein Softwareprojekt nur Code schreibt, um eine Idee umzusetzen.
Falscher Glaube an die Macht der Software
Träumer glauben oft unrealistisch an die Macht der Software, die Welt zu verändern. Viele stellten sich vor, dass soziale Medien uns vereinen würden, aber irgendwie sind es nur freigelegte Bruchlinien, die immer offensichtlich waren. Softwareprojekte beginnen oft mit Foliendecks, die versprechen, einen Teil der Welt zu revolutionieren. Wenn das Verschieben von Bits in eine Datenbank niemanden transformiert, werden die Leute wütend, gelangweilt, verwirrt oder schlimmer. Sie sagen, die Software ist kaputt, weil sie nicht die magische Transformation liefert, die jeder erwartet hat.
Viele Softwareprojekte können kompilieren, QS bestehen, versenden und sogar anständige Bewertungen erhalten, aber letztendlich keines der Versprechen auf dem Foliendeck erreichen, weil diese Versprechen, die Welt zu verändern, unmöglich sind.
Böse Subunternehmer
Wir lieben die Anbieter, die die Bibliotheken und Tools herstellen, mit denen wir mit nur wenigen Codezeilen Magie erzeugen können. Gelegentlich bekommen sie Wind von ihrer Macht und nutzen sie, um ein Projekt zu zerstören. Das Budgetblatt für Version 1.0 war so gut, dass das Management nicht zögerte, Version 2.0 zu genehmigen. Dann beschließt der Verkäufer, uns zu quetschen, indem er den Preis verdreifacht oder verfünffacht.
Dieser Effekt ist auch dann zu spüren, wenn die Anbieter dies nicht absichtlich tun. Kostenlose Ebenen können ein Projekt sehr billig aussehen lassen. Wenn dann die Nachfrage steigt und die zweite Version die Nachfrage erweitert, treten die realen Preise ein.
Klimawandel
In einem Jahr mit Pandemien und Protesten hat sich nichts schneller geändert als der Zeitgeist. Hat das Projekt einen starken Datenschutz zu einem zentralen Merkmal gemacht? Whoop. Die Pandemie hat alle an der Kontaktverfolgung interessiert. Wollte sich jemand auf Geschäftsreisen konzentrieren? Whoop. Die Hotellerie ist zusammengebrochen. Größere Softwareprojekte, die ein Jahr oder länger dauern können, laufen Gefahr, durch katastrophale Ereignisse auf den Kopf gestellt zu werden. Was am Anfang wie eine wunderbare Idee schien, mag hoffnungslos verloren und getrennt erscheinen, wenn es Zeit ist, live zu gehen.
Technische Veränderungen
Es sind nicht nur Veränderungen in der Welt insgesamt. Gezeitenwechsel in der Tech-Community können den gleichen Effekt haben. NoSQL war einst eine geniale Idee, die uns vom relationalen Schema befreien würde. Dann erkannte jemand, dass die Dateien aufgebläht waren, weil jeder Datensatz ein lokales Schema enthielt. Ein gutes agiles Entwicklungsteam kann sich verändern, wenn technologische Veränderungen die Einstellungen der Führung und der Kunden verändern. Aber selbst die agilsten Teams können nicht mit großen Verschiebungen umgehen, die die Luft aus ihren Architekturplänen saugen. Das System wurde unter der Annahme gebaut, dass X eine großartige Idee war und plötzlich X Schmutz ist. Manchmal ist es am besten, es in die Luft zu jagen und wieder zu spielen.
Zu viele Ergänzungen
Einige Softwareprojekte starten gut und werden sogar erfolgreich ausgeliefert. Dann fügt jemand ein oder drei zusätzliche Funktionen hinzu und fügt der vorhandenen Version neuen Code hinzu, sodass der Code weiterhin hinkt. Heroische Entwickler können dies mehrmals durchführen, insbesondere wenn der ursprüngliche Architekt gut geplant hat. Aber irgendwann bröckelt das Fundament. Möglicherweise kann die Datenbank die Last nicht bewältigen. Möglicherweise sind zu viele JOINs erforderlich, um die verschiedenen Abfragen zu erfüllen. Gute Software kann zu fett werden, manchmal dank kleiner Verbesserungen, die sie über den Rand gedrängt haben.
Verschieben von Torpfosten
Die ursprünglichen Pläne erforderten eine Datenbank, um die Kundenausgaben zu verfolgen und bei Marketingplänen zu helfen. Dann fügte ein Genie eine Funktion hinzu, die künstliche Intelligenz verwendet, um Ausgaben mit der Wettervorhersage zu korrelieren. Oder jemand anderes wollte, dass die Software automatisch für Suchmaschinenanzeigen bietet. Das Ändern des Ziels kann ein Projekt auf den Kopf stellen.
Es ist selten, dass die Änderungen die Dinge von selbst ruinieren. Aber neue Ziele können Schwächen aufdecken und Fehlermodi auslösen. Vielleicht ist das Team jetzt zu klein, um das Projekt erfolgreich abzuschließen. Vielleicht sind die technischen Grundlagen für den neuen Ansatz äußerst ineffizient. Es ist schwer für alle, die ärgerliche Kombinatorik zu antizipieren, wenn die Entscheidung getroffen wird, die Ziele zu ändern.