Die Deadline rückt immer näher, zum dritten Mal musst du beim Chef um mehr Ressourcen bitten, die Software genügt den Ansprüchen nicht und dein Team streitet sich mit der beauftragten Firma: Ein ausser Kontrolle gelaufenes Projekt ist ein Albtraum.
Je nach Ausmass des Desasters kann so ein Projekt nachhaltigen Schaden anrichten: Wertvolle Mitarbeitenden kündigen aus Frust, das Geschäft erleidet finanzielle Einbussen oder – ganz persönlich – dein Ansehen leidet.
Anton Petrov, David Übelacker und Guillaume Feller haben zusammen über 60 Jahre Erfahrung in der Software-Entwicklung. Sie haben Dutzende Projekte begleitet und viele Hochs und Tiefs erlebt. Wir haben sie gefragt, was die grössten Stolpersteine in einem Softwareprojekt sind.
Wenn du ein IT-Projekt planst, solltest du diese fünf Fehler vermeiden, damit du leichter, schneller und günstiger zum Erfolg kommst. Und falls du schon in Problemen steckst, haben wir am Schluss einen Extra-Tipp für dich.
1. Die Architektur ist kein Wunschkonzert
Ein häufiger Fehler ist, dass Architekturentscheidungen auf Basis von Geschmack, Beliebtheit oder persönlicher Präferenz getroffen werden – statt aufgrund von Anforderungen und Fakten.
«Ich war mal in einem Projekt, wo jeder Entwickler seine eigene Lieblingslösung eingebaut hat – am Ende war das Ding kaum wartbar», sagt Anton.
Entwickelt das Team einfach drauflos, ohne sich vorher eingehend Gedanken über die Architektur zu machen, legt es sich auf etwas fest, was später nicht mehr korrigiert werden kann.
Hier sind Erfahrung und klare Vorgaben vom Unternehmen gefragt. Nur so können Architekturentscheidungen bewusst, nachvollziehbar und gemeinsam im Team getroffen werden. Die Architektur sollte von Anfang an klar sein und regelmässig überprüft werden. Und der Architekt sollte nicht nur von Beginn weg dabei sein, sondern das Projekt aktiv begleiten.
Wenn dir die Erfahrung im Team fehlt, kann es hilfreich sein, Hilfe von aussen beizuziehen. Unsere Entwickler sind bei Projekten aus der Versicherungs- und Bankenbranche gerne bereit, dir hierbei unter die Arme zu greifen.
2. Zu viel, zu früh, zu komplex: Over-Engineering
Eine Software soll zukunftssicher, für alle Eventualitäten vorbereitet, für alle möglichen Use-Cases einsetzbar sowie schnell und flexibel anpassbar sein. Mit diesen Ansprüchen läufst du Gefahr, in die Over-Engineering-Falle zu tappen.
«Entwickler neigen dazu – und ich schliesse mich da nicht aus – Lösungen möglichst elegant und generisch umzusetzen», sagt David und meint damit die genannten Ansprüche.
Anstatt dich auf die aktuellen Anforderungen zu konzentrieren, baust du Features und Strukturen ein, die nie wirklich genutzt werden. Du perfektionierst den Code, um technisch die eleganteste Lösung zu finden, und verbrauchst dabei kostbare Zeit und Ressourcen. Schlimmstenfalls verzettelt sich das Team so sehr, dass das Projekt unfertig abgeliefert wird – nur um für ein künftiges Szenario vorzuarbeiten.
Bei der nag wägen wir die oben genannten Ansprüche mit einer guten Kosten-Nutzen-Rechnung ab. Ein Extra muss sich lohnen und zu der gemeinsam mit unseren Kunden erarbeiteten Zukunftsvision passen. So vermeiden wir Over-Engineering in unseren Projekten.
3. Das Gegenteil: Scope-Creep
Umgekehrt können auch auf Kundenseite die Ansprüche durch die Decke schiessen. So kann ein Projekt als kleine simple App beginnen, die ein paar Wochen später alles können muss: Sie braucht KI, Schnittstellen zu fünf Systemen und ein separates Admin-Portal. Diese Ideen können sogar brillant sein, bringen aber – weil sie zum falschen Zeitpunkt entstehen – erhebliche Probleme mit sich.
Wie beim Over-Engineering driftet das Projekt so in Richtung Zeit- und Kostenüberschreitungen ab. Darunter leidet am Ende die Zufriedenheit bei allen und die Qualität der Arbeit ist gefährdet.
Der Prozess geschieht gerne «creepingly», also schleichend. Dem ursprünglichen Umfang des Projekts, dem Scope, werden immer mehr Erweiterungen zugefügt, die für sich genommen zwar nur einen kleinen, in der Summe aber einen erheblichen ungeplanten Aufwand generieren.
Vermeintlich kleine zusätzliche Funktionen können auch plötzlich zu grossen anwachsen, wenn sie lange Rattenschwänze nach sich ziehen: Bereits fertiggestellte Arbeiten müssen hier nochmals hervorgeholt werden, um dort ein neues Feature zum Laufen zu bringen.
Um Scope-Creep zu vermeiden, ist es wichtig, im Vorfeld alle Bedürfnisse sauber abzuklären. Wenn alle beteiligten Personen von Anfang an mitreden können, tauchen später weniger unerwarteten Ansprüche auf.
Du kannst Änderungswünsche durchaus zulassen. Schliesslich bringt dir das beim Kunden sicherlich Pluspunkte ein. Du solltest sie aber gut dokumentieren und strukturiert managen. Denn lieferst du wegen Scope-Creep am Ende schlechtere Qualität zu einem höheren Preis ab, nützen dir die zusätzlichen Funktionen wenig. Die gewonnenen Pluspunkte hast du dann wieder verloren.
4. Technische Schulden anhäufen
Software lebt. Sie entwickelt sich ständig weiter, um sich an neue Anforderungen, Technologien oder Umgebungen anzupassen. Wie ein Haus muss Software laufend in Stand gehalten und gepflegt werden. Wer immer nur neue Features hinzufügt, ohne den Quellcode regelmässig aufzuräumen, generiert technische Schulden.
Versteckte Fehler und gegenseitige Beeinflussungen von neuen Features führen zu Bugs. Verliert der Code zunehmend seine Struktur und Übersichtlichkeit, dauert es immer länger, die Ursachen zu finden und zu beheben. Ausserdem wird es dadurch schwieriger, neuen Anforderungen zeitnah gerecht zu werden.
Technische Schulden zu vermeiden, fordert wie bei der Hauswartung regelmässige Pflege. «Refactoring, das Überarbeiten und Restrukturieren des Quellcodes, gehört genauso in den Sprint wie neue Features», sagt David. Darum sprechen wir technische Schulden offen an und planen sie bei unseren Softwareprojekten aktiv ein.
5. Einmal planen, einmal umsetzen, Kunden ignorieren
Auch wenn Software wie ein physisches Haus laufend gepflegt werden muss, beim Aufbau hinkt dieser Vergleich: «Wir haben in den letzten Jahrzehnten gelernt, dass man Software nicht wie ein Gebäude planen und bauen kann», sagt David. Ein Architekt erstellt für sein Bauprojekt am Anfang eine Blaupause, die bis zur letzten Steckdose durchdacht und mit den Auftraggebern festgelegt ist. Anschliessend lässt sich daran kaum etwas ändern. Denn ist der Beton einmal hart, bedeutet eine zusätzliche Steckdose viel Mehraufwand.
Den Frust frischer Neubaubesitzer über falsch platzierte Steckdosen solltest du deinen Kunden ersparen. Das Gute: Da du keinen Mörtel und Backsteine verbaust, bleibst du bei Software-Projekten flexibel. Wenn du dir am Anfang einen soliden Rahmen gegeben (siehe Punkt 1) und den Scope klar definiert hast (siehe Punkt 3), kannst du später freier auf spontane Kundenwünsche eingehen. Dazu musst du deinen Kunden regelmässig auf den neusten Stand bringen und besprechen, wie es weitergeht.
Wir setzen dabei auf agile Vorgehensmodelle wie Scrum. In kurzen Zyklen erstellen wir so funktionsfähige Softwareversionen und holen für den jeweils aktuellen Stand beim Kunden ein Feedback ab. So wissen wir, was wir bei der nächsten Iteration ausbessern müssen. Da der Kunde laufend involviert ist, gibt es am Ende keine unangenehmen Überraschungen.
Extra-Tipp: Grössere Teams sind nicht schneller.
Das Malheur ist passiert und du bist bereits in eine der Stolperfallen getappt? Dann plagen dich jetzt wahrscheinlich Zeitprobleme. In diesem Fall haben unsere Experten einen Extra-Tipp für dich: Wenn du ein gut funktionierendes Team hast, lösen zusätzliche Mitarbeitende deine Zeitprobleme wahrscheinlich nicht. Auch wenn deine Intuition etwas anderes sagt.
«Ich habe erlebt, wie plötzlich fünf neue Leute ins Projekt kamen, und statt Tempo gab es erst mal Chaos», sagt Anton. «Das bestehende Team war gut eingespielt, die Neuen mussten sich erst orientieren, und die Abstimmung wurde deutlich schwieriger.»
Kurz gesagt: Eine neu entstandene, chaotische Teamdynamik zu beheben, kostet rasch mehr Zeit, als die zusätzlichen Kräfte am Ende tatsächlich einsparen. Im Worst Case entstehen selbst nach einer Reorganisation mehr Reibungsverluste und das nun grössere Team verliert an Effizienz.
Für Anton ist klar: «Die Beteiligten sollten lieber frühzeitig realistisch planen und das Team stabil halten. Wenn Verstärkung nötig ist, dann nur gezielt und mit geplanter Einarbeitungszeit – nicht als Feuerwehraktion.»
Frühzeitig planen, kommunizieren und Grenzen setzen
Sorgfältige Planung und Vorbereitung lohnen sich, denn steckt das Projekt einmal in der Krise, kommst du nur schwer wieder heraus. Es wird dich deutlich weniger Energie kosten, diese Fehler zu vermeiden, indem du dein Projekt regelmässig reflektierst, offen kommunizierst und unbequeme Tatsachen nicht ignorierst. Dazu gehört auch, im richtigen Moment «Nein» zu sagen.
Unsere Expertinnen und Experten sind auf IT-Lösungen, insbesondere in der Versicherungs- und Bankenbranche, spezialisiert. Wir helfen gerne, dein IT-Projekt umzusetzen und diese Fehler erfolgreich zu vermeiden.
Text: Samuel Rink, Fotos: Unsplash
