Wie man ein Software-Projekt vor die Wand fährt

🤷‍♂️ Warum müssen Software-Projekte eigentlich immer erfolgreich sein?

💡 Ein Projekt erfolgreich abschließen kann jeder, das ist maximal langweilig. Also warum nicht mit minimalem Aufwand und ein bisschen Geschick das Projekt komplett vor die Wand fahren?

❓ Wie schaffe ich es als Verantwortlicher mein Projekt zu verkacken?

☝️🧐 Dieser Frage möchte ich in diesem Artikel auf den Grund gehen.

Mindset

Der Kunde hat keine Ahnung - von nichts, kann nichts und liegt immer falsch - aber wird das niemals einsehen. Vermeide es gemeinsam mit ihm Lösungen zu erarbeiten, ihr könntet Gefahr laufen Missverständnisse aufzudecken.

Keine Enterprise-Patterns!

Das Sind nur alles nur leere buzz words! Es gibt keine wiederkehrende Arten von Problemen, oder gar Lösungsansätze die sich auf ähnliche Probleme adaptieren ließen. Jedes Problem muss von Grund auf als einzigartig von vorher nie dagewesen angesehen werden.

Vorbereitung

Sorge dafür, dass bei den Stakeholdern und dir selbst KEIN Konsens über das Projektziel besteht. Jeder Beteiligte sollte eine unterschiedliche Vorstellung von den Anforderungen haben. So legst du den Grundstein für Missverständnisse, auseinanderlaufende und widersprüchliche Anforderungen.
Starte so schnell wie möglich mit der Implementierung und Verschwende keine Zeit mit, zB:some text
- Machbarkeitsstudien
- Wireframes/Mockups/Klickdummy
- Prototypen
- Du könntest sonst Probleme vermeiden, die das Projekt später zuverlässig torpedieren können.

Fundament

Mach dir keine Mühe vor der Implementierung die Architektur der Anwendung zu gestalten. Das würde zu einer stabilen Basis führen, die spätere Fehler großzügig verzeiht und die Umsetzung beschleunigt.
Vergiss CI/CD-Pipelines!some text
1. Deine Tests und Deployments in einer robusten Pipeline zu automatisieren würde dir nicht enorm viel manuelle Arbeit ersparen. Was aber noch viel schlimmer ist, wertvolle Bugs würden es nicht mehr in die Produktiv-Umgebung schaffen.
2. Vermeide Automatisierungen ganz besonders beim Deployment. Wenn euer Code per FTP ins Prod-System geladen wird, und nur eine einzige Person die Zugänge dazu hat, spielt ihr in der Königsklasse.
Benutze niemals gut erprobte und dokumentierte externe Libraries! Es reicht nicht aus das Rad neu zu erfinden. Erfinde auch das Werkzeug neu um ein neues Rad zu Erfinden! Not invented here? No thanks!
Es ist viel zu einfach Linter und Prettifier zu benutzen. Lass diene Entwickler:innen ihren Code formatieren wie sie wollen. Umso länger und kompliziert die Zeile, umso besser! Methoden sollten möglichst nicht weniger als 200 Zeilen und 7 Einrückungsstufen haben.

Rahmenbedingungen

Erstelle KEINE User-Stories oder Tasks. Beschreibe das Ziel so wage und triff so viele Annahme wie möglich. Mach das unter der Prämisse, dass alle Entwickler den gleichen Wissensstand haben wie du selbst und ihr daher alle die gleichen Schlussfolgerungen trefft. So werden alle Feature garantiert falsch umgesetzt und du sorgst für ein Höchstmaß an Rückfragen und Missverständnissen.
Lass alle Entwickler selbst herauszufinden, welche Tasks, wie umzusetzen sind. Anderenfalls wüssten sie genau was, wann, wie zu tun ist und ihre Produktivität könnte sich vervielfältigen.
Lehne Komplexitäts-Schätzungen kategorisch ab. Zeit-basierte Schätzungen erhöhen den Druck auf die Entwickler, täuschen dem Kunden Sicherheit vor und können bei größeren Projekten garantiert nicht eingehalten werden.

Allgemeine Vorgehensweise

Versuche auf keinen Fall einen Überblick des Projekts, dessen Stand oder den Stand der Entwickler zu behalten, sonst läufst du Gefahr frühzeitig Engpässe zu erkennen und könntest diese dem Kunden gegenüber kommunizieren oder gar auflösen.Bonus: dadurch kannst du ganz leicht allen (neuen) Beteiligten eine falsche Auskunft über den Fortschritt des Projekts geben. So hast du es auch sehr leicht Externe, die das Projekt retten sollen, unter der Angabe falscher Voraussetzungen mit rein zu holen.
Setze ausschließlich unerfahrene Entwickler auf die grundlegenden Teile des Systems an - sprich System- und Software-Architektur. So garantierst du maximale Instabilität, sowie komplizierten, redundanten und unstrukturierten Code, der genauso schwer zu lesen, wie zu warten oder zu erweitern ist.
Dein Prozess und deine Vorgehensweise sind perfekt. Schuld an Problemen hat entweder der Entwickler, weil er anders denkt als du (siehe Punkt 3.a) oder der Kunde, weil er unsinnige Anforderungen hat (siehe Punkt 1.a).

Umsetzung/Durchführung

Benutze KEINE Standard-Bibliotheken oder Frameworks bei der Umsetzung. Das würde die Produktivität nur unnötig steigern.
Sorge dafür dass Wissens-Inseln entstehen. Alle Entwickler sollten nur ihren eigenen kleinen Teil der Software kennen und keine Zeit in den Wissenstransfer verschwenden. Das würde zu unerwünschten Synergie-Effekten führen oder Entwickler sogar austauschbar machen, für den Fall dass sie mal ausfallen.
Eine verlässliche Methode um Punkt 2) zu erreichen ist das Verbot von Reviews.
Lass nicht zu, dass APIs geplant oder gar dokumentiert werden. So können nette Pläusche zwischen den Front- und Backend-Entwicklern entstehen und du kannst sie davon abhalten produktiv zu sein. Im Optimalfall können APIs und Calls zu diesen sogar stark auseinander laufen.
Alle Beteiligten (Entwickler, Stakeholder, Domänenexperten, Kunden, ...) sollten so viel und unabhängig voneinander wie möglich kommunizieren. Das garantiert Missverständnisse und generiert ein Höchstmaß an unproduktiver Zeit.
Die Ergebnisse aus 5) sollten auf keinen Fall dokumentiert werden. Anderenfalls könnten mehrfache Absprachen oder gar auseinander laufende Ergebnisse verhindert werden.
Verbiete Dailies und Absprachen jeglicher Art zwischen mehreren Entwicklern. In Kombination mit dem Verbot von Ticket-Systemen schaffst du ideale Voraussetzungen für doppelte parallele Arbeit.
Delegieren/Beauftragen: Hat dein Kunde Sonderwünsche, lass diese nur soweit implementieren, wie deine Entwickler sagen können: “Works on my machine... 🤷‍♂️”
Tests führen nur unnötigerweise dazu, dass Fehler frühzeitig erkannt werden.
Verbiete, wie in 2.4) erwähnt, den Einsatz von Lintern, Prettifiern oder sonstigen Tools, die mit einfachen Mitteln helfen Konventionen einzuhalten. So schaffst du ausreichend Streitpotenzial über Code-Style und beugst zusätzlich Reviews vor, weil niemand Lust hat das Kauderwelsch der anderen zu lesen.
Kaum etwas sorgt so zuverlässig für einen Misserfolg im Projekt wie das tägliche umwerfen des Projektplans und reinschieben neuer Aufgaben, während noch an Features gearbeitet wird. Erziehe auch deinen Kunden dahingehend, dass er unentwegt neue Anforderungen mit oberster Priorität generiert. So wird dir/euch die Arbeit nie ausgehen.
Keine der obigen Anstrengungen werden jedoch von Misserfolg gekrönt sein, wenn deine Entwickler durchgängig konzentriert arbeiten können. Es dauert im Schnitt ca. 20 Minuten bis man sich gut in ein Problem eingedacht hat und produktiv programmieren kann. Erzeuge für deine Entwickler mindestens alle 30 Minuten eine größere Ablenkung, so dass sie aus ihrer Konzentration rausgerissen werden.

Vielen Dank für die Aufmerksamkeit. Kritik, Ergänzungen und Anregungen sind erwünscht.

Dieser Artikel könnte Spuren von Sarkasmus hinerlassen haben - folgen Sie diesen. Sie könnten ins Licht führen.