Stetige Produkt Modernisierung ist die größte Herausforderung in heutigen Software-Projekten. Der wichtigste Teil dieses Prozesses sollte dabei immer vor den eigentlichen Maßnahmen stattfinden: Kenne dein Produkt und verstehe es.

Unerlässlich: Der Blick über den Tellerrand

“Kenne dein Produkt”: Das klingt simpel und wird gerne sehr schnell abgehakt in unseren Software-Engineering Köpfen: “Wir arbeiten tagtäglich in unserer Code-Base, wir kennen unser Produkt in und auswendig!”. Auf den ersten Blick: “Richtig”. Auf den zweiten Blick jedoch: “Zu kurz gedacht!”. Sich gut in der eigenen Code-Basis auszukennen ist definitiv hilfreich und ist zugleich nur ein kleiner Teil des Big-Pictures.

Sind wir erst seit kurzem in diesem Projekt tätig ist dies eine gute Gelegenheit uns mit den zugrunde liegenden Business Use Cases und damit verbundenen Rahmenbedingungen vertraut zu machen. Gute Software-Engineers kennen immer mehr als nur die Code-Basis seines aktuellen Projekten kennen. Ein Blick über den eigenen Tellerrand hinaus ist hierbei Pflicht!

Business Use Cases kennen und VERSTEHEN

Ein großer und nicht zu vernachlässigender Aspekt sind die wichtigsten Business Use Cases unseres Produktes: “Wie verdienen wir mit unserem Produkt eigentlich Geld?”. Oder für Open-Source-Projekte: “Mit welcher Intention verwenden Andere unsere Library/Produkt?”. Es ist essentiell zumindest die fünf wichtigsten Business Use Cases unseres Produktes zu kennen und zu verstehen. Diese müssen wir jederzeit im weiteren Verlauf unseres Modernisierungsvorhabens immer Hinterkopf behalten.

Modernisierungen, wie neue Frameworks, Libraries oder andere neue Technologien müssen immer dazu dienen unsere wichtigsten Business Use Cases zu stärken oder sie im schlechtesten Falle nicht zu mindern. Eine großflächige Modernisierung, oder auch “Refactoring”, der Code-Basis sollte auf keinen Fall einzig und allein dazu dienen den Drang nach “etwas Neuem” zu befriedigen.

Um unser Modernisierungsvorhaben im weiteren Verlauf zu legitimieren brauchen wir immer einen direkten und nachvollziehbaren Bezug zu eben jenen Business Use Cases. Ohne diesen Bezug laufen wir Gefahr, dass unser Vorhaben nicht ernst genommen wird.

In der langen Liste der zu bearbeitenden Themen, fallen eben jene als erstes “hinten runter” die keinen klar erkennbaren Benefit für wichtige Business Use Cases darstellen. Zwingend notwendige Modernisierungsvorhaben werden so oftmals bis in alle Ewigkeit verschleppt. Im schlimmsten Falle bis es “zu spät” ist und entweder keine andere Möglichkeit mehr besteht, oder negative Auswirkungen auf unsere Business Use Cases spürbar sind, weil die verwendeten Technologien oder Frameworks nicht mehr wartbar sind.

Wichtige Requirements ALLER Stakeholder VOR der Produkt Modernisierung kennen

Einen ebenso wichtigen Stellenwert neben den Business Use Cases unseres Produktes stellen technische Requirements dar, die an unser Produkt gestellt werden. Diese beinhalten sowohl Team-interne, als auch externe Anforderungen an unsere Software. Ein weiterer Punkt der von uns Software-Engineers aus “Bequemlichkeit” oder “Angst” vor ungeliebten Themen nur allzu gerne übergangen wird.

Es ist unumgänglich die wichtigsten Requirements aller beteiligten Stakeholder zu kennen, damit im späteren Verlauf unserer Modernisierung möglichst viele davon mit einbezogen werden können. Anders ausgedrückt: “Damit alle abgeholt sind” bei unserem Vorhaben. Schnell kann sich hier Unmut oder mindestens Unverständnis bei “Übergangenen” einstellen.

Eine Liste möglicher Stakeholder deren wichtigsten Requirements wir kennen sollten:

• Kunden oder Anwender
• Entwickler (Intern und Extern)
• Testing und Qualitätssicherung
• Product Owners & Project Leads
• (Team-)Manager

Sind wir erst seit kurzem Teil jenes Projektes ist dies eine exzellente Gelegenheit für uns, um neben dem eigentlichen Produkt die daran beteiligten Menschen kennenzulernen. Dieser erste Kontakt – und mag er auch noch so oberflächlich erfolgen – wird uns im weiteren Verlauf unserer geplanten Modernisierung noch von großem Nutzen sein!

Kenne Schwächen der heutigen technischen Lösung

Für jeden bekannten Business Use Case oder technisches Requirement existiert heute bereits eine technische Lösung. Um unsere geplante Software Modernisierung mit möglichst gewichtigen Argumenten zu untermauern, ist es von großem strategischen Vorteil jene heutige Lösung zu kennen. Hat diese Schwächen oder bereitet heute regelmäßig Probleme im Entwicklungsablauf sollten wir diese UNBEDINGT kennen.

Schwächen bieten nicht nur in Video-Spielen hoch-effektive “Angriffspunkte”. Auch in der Software-Entwicklung können wir sie “ausnutzen”, um unsere angestrebte Modernisierung als neue “Wunderwaffe” zu verkaufen. Immer vorausgesetzt natürlich unsere neue technische Lösung stellt eine klare und belegbare Verbesserung für heute bekannte und wiederkehrende Schwächen dar.

Kandidaten für “Schwachpunkte” in heutigen technischen Lösungen, die für uns besonders interessant sind, beinhalten unter anderem:

• Häufig betroffen von Regressionen (= viele Tickets)
• Schwer zu erweitern für neue Features
• Schwer zu testen durch automatisierte Tests
• Komplexe Code-Base
• Verwendung von veralteten/Deprecated/Legacy APIs
• …

Diese Schwachpunkte gilt es mit unserer zukünftigen Lösung zu verbessern und im Idealfall vollständig “auszumerzen”.

Fragen Fragen Fragen und nochmals Fragen

Im Idealfall sind unsere wichtigsten Business Use Cases, technischen Anforderungen und bekannte Schwächen oder Risiken in einer gut gepflegten Dokumentation hinterlegt und jederzeit und für Jedermann nachvollziehbar.

…

Nun, in der Realität ist dies leider allzu oft nicht der Fall. Häufig bestehen diese hauptsächlich in den Köpfen unserer Kollegen. Meist jene Kollegen, die bereits seit langer Zeit in unserem Projekt-Umfeld tätig sind.

Um dieses Wissens anzuzapfen gibt es für uns nur eine Möglichkeit: “Fragen, Fragen, Fragen und nochmals: Fragen”. Hier gilt es keine falsche Scheu zu zeigen und Eigeninitiative zu zeigen! Unsere Kollegen werden uns mit Freude alle für uns wichtigen Information und ihr eigenes Hintergrund-Wissen über das Projekt offenbaren. Schließlich sind sie zurecht besonders Stolz auf ihren dazu geleisteten Beitrag!

Wichtig hierbei ist es die eigene Erwartungshaltung nicht zu hoch anzusetzen. Oftmals werden wir es erleben, dass hierbei Anforderungen unterschiedlicher Stakeholder miteinander kollidieren oder sich gar widersprechen. Dies ist nicht weiter tragisch. Eben jene Requirements können uns im weiteren Verlauf von Nutzen sein, wenn es darum geht alle Stakeholder an Bord zu bekommen für unser großes Modernisierungs-Vorhaben.

Nächste Schritte: Ausgiebige Explorationen

Kennen wir die wichtigsten Business Use Cases und technischen Requirements all unserer Stakeholder sind wir bestens vorbereitet, um mit der eigentlichen Modernisierung unseres Produktes zu beginnen, indem wir damit beginnen neue Technologien zu erforschen.