Wie Digitalisierung funktioniert: Software-Produktentwicklung/-Produktmanagement (3/5)

Die Entwicklung einer digitalen Lösung/eines digitalen Produkts beginnt in der Regel, sobald ihr/sein Mehrwert geklärt ist/feststeht. Besonders bei nicht gebootstrappten Projekten kann es recht kapitalintensiv werden, etwas zu entwickeln, das sich am Ende als wertlos herausstellt.

Unter der Annahme, dass der Mehrwert Ihrer Softwarelösung/Ihres Produkts feststeht, lassen Sie uns einen kurzen Blick auf die tatsächlichen Softwareentwicklungsabläufe werfen und auf die Art und Weise, wie sie mit Ihrem Unternehmen harmonieren:

• Aufbau der Funktionen/Features festlegen
• Technologie auswählen
• Architektur definieren
• Aufgaben, To Dos, Planung
• Kapazitäten
• Entwicklung

1. Aufbau der Funktionen/Features festlegen

Ihre Software muss bestimmte Funktionen ausführen und besondere Features enthalten, damit sie den Benutzern/Kunden einen Mehrwert bietet. Diese Anforderungen mögen in Ihrem Business-Szenario durchaus deutlich sein, aber sie müssen dennoch in entsprechenden Requests an das Software-Entwicklungsteam/-unternehmen übersetzt werden.

Deshalb beginnen die Entwickler damit, Ihre Unternehmensziele sowie die angestrebten Funktionen und Features Ihrer Software zu besprechen und zu verstehen. Dies ist der erste Teil innerhalb eines sich wiederholenden Zyklus, der aus folgenden Schritten besteht:

[Funktionen/Features abklären]
↓
[die geeigneten Technologien auswählen]
↓
[die Architektur definieren]
↓
[Aufgaben ausführen]
↓
[wiederholen]

Das daraus resultierende Ergebnis ist ein Stufenplan/eine Roadmap (wie in diesem Beispiel für eine kommerzielle Lösung):

Der übliche Zeitrahmen für ein Release beträgt einige Monate, die meist in mehrere kurze Iterationen (je 1-2 Wochen) aufgeteilt werden.

Ein mögliches Risiko besteht darin, dass Sie zu viele Funktionen/Features spezifizieren, die alle gleich wichtig sind. Obwohl das Software-Entwicklungsteam kein Mitspracherecht bei Ihren Business-Zielen haben sollte, kann es Sie dennoch bei der Erstellung des Benutzer-Story-Mappings und bei der Priorisierung des Feature-Trees unterstützen. Auf diese Weise steigt die Wahrscheinlichkeit, dass Sie sich auf die wichtigsten Elemente konzentrieren können.

2. Technologie auswählen

Sobald die Funktionen und Features klarer sind, obliegt die Technologieauswahl in der Regel dem Softwareentwicklungsteam, es sei denn, Sie haben bestimmte Anforderungen. Zum Beispiel könnten Sie bereits ein Azure-Account/Abonnement haben. In diesem Fall ist es sinnvoller, innerhalb des Ökosystems zu bleiben, als zu AWS zu wechseln. Oder Ihr Wartungsteam verwendet bereits .NET, was die Nutzung von Java ausschließt.

Die gewählte Technologie sollte zukunftssicher sein, d. h. für einen absehbaren, angemessenen Zeitraum nutzbar sein. Dennoch wird es immer wieder Situationen geben, in denen weitere Iterationen/Änderungen erforderlich sind, obwohl die gewählte Technologie stabil sein sollte.

Nehmen wir zum Beispiel eines der jüngsten Projekte von Berg Software, das sich mit Big Data befasst: Unser erster Ansatz war SQL, aber die Anforderungen des Kunden stießen auf Hindernisse (Datenvolumen, Geschwindigkeit, Wartung). Daher haben wir uns zwei neuen Technologien zugewandt (ClickHouse, Elasticsearch) und schließlich jede davon für einen separaten Teil der maßgeschneiderten Software des Kunden verwendet.

3. Architektur definieren

Architektur und Technologie gehen Hand in Hand. Der einzige Grund, warum wir die Technologie zuerst genannt haben, ist, dass sie oft wichtige Aspekte der Architektur beeinflussen kann. Denken Sie zum Beispiel daran, wie die Entscheidung, in der Cloud zu arbeiten, Ihre architektonischen Entscheidungen prägt.

Unsere Arbeitsweise besteht darin, zunächst die „High-Level“-Architektur der großen Elemente zu definieren (z. B. Frontend, Backend, eventuell einige separate Dienste wie Authentifizierung, Reporting usw.). Dann teilen wir diese in Module mit jeweils detaillierten, lokalen Architekturen auf.

Indem wir eine modulare Architektur aufbauen, stellen wir sicher, dass sie an zukünftige Iterationen anpassbar ist. Genau wie die Technologie ist auch die Architektur nichts, was man alle paar Wochen ändert – aber es wird Situationen geben, in denen eine Änderung erforderlich sein wird.

Zum Beispiel könnte Ihre Software anfangs eine bestimmte Authentifizierung beinhalten, mit eigenen, klar definierten Benutzern und Rollen. Doch dann könnten Sie entscheiden, dass Benutzer, die bereits in Ihrem bestehenden ERP, OS usw. angemeldet sind, diese Authentifizierung auch für die neue Software verwenden sollen. In diesem Fall wird die lokale Authentifizierungsarchitektur zurückgesetzt, möglicherweise um eine API für Ihre anderen Software-Assets zu integrieren.

4. Aufgaben, To Dos, Planung

Jetzt, wo Funktionen, Features, Technologie und Architektur geklärt sind, können wir auf der Grundlage eines Release- und eines Iterationsplans mit der Entwicklung beginnen. Im Folgenden sehen Sie, was in jedem dieser Pläne enthalten ist:

Die aktive Planung sollte sowohl für die Releases als auch für die Iterationen durchgeführt werden.

Sobald eine Iteration abgeschlossen ist, kann sie sich auf den Release-Plan auswirken. Elemente wie die Business-Logik oder rechtliche Anforderungen oder technische Probleme können die Entwicklung verlangsamen – daher kann der Release-Plan auch geändert werden, um einen gekürzten/neu geordneten Feature-Satz aufzunehmen. Der Release-Plan bleibt unabhängig von der Funktionsliste meist unverändert.

Auf der Grundlage der Agile-Prinzipien sind Zeit und Kosten die Haupteinschränkungsfaktoren (/die stabilen Elemente), während Features die variablen Elemente sind. Dies unterscheidet sich vom traditionellen Projektmanagement, bei dem Features vorgegeben und Zeit und Kosten variabel sind (d. h. in der Regel steigen).

5. Kapazitäten

Um den Plan auszuführen, braucht man Zeit und Ressourcen – in diesem Fall personelle Kapazitäten. Insbesondere im Falle von Software können die Dinge ziemlich herausfordernd werden.

Erstens besteht die Möglichkeit, dass Ihr internes Team eine Partnerschaft mit einem externen Dienstleister eingeht, und zwar im Rahmen eines Software-Outsourcings, das einen flexiblen Zugriff auf Kompetenzen ermöglicht.

Sie haben einen Product Owner und/oder ein Team, das das interne Know-How bereitstellt und in ständigem Kontakt mit dem Entwicklungsteam/der Entwicklungsfirma steht. Ihr Team sollte das Softwareprodukt/die Lösung, das/die entwickelt wird, in- und auswendig kennen, auch wenn Sie es nicht selbst bauen/entwickeln.

Anschließend sollte das eigentliche Entwicklungsteam mit einer minimalen Anzahl von Schlüsselpersonen beginnen, die über signifikante Erfahrung mit den Technologien verfügen, die von Ihrem Softwareprodukt bzw. Ihrer Lösung verwendet werden. Die Skalierung des Entwicklungsteams kann auf die gleiche iterative Art und Weise erfolgen, d. h. Sie können Ressourcen erhöhen/zuweisen, sobald das Gesamtbild klarer ist (Technologien, Architektur, Plan) und die Umsetzung vorangetrieben werden muss. Es mag eine Frage der persönlichen Einschätzung sein, aber wir haben herausgefunden, dass ein Kernteam von Leuten, die bereits vorher zusammengearbeitet haben, dabei hilft, die Dinge reibungsloser zu gestalten.

6. Entwicklung

Das Arbeiten in kleinen, häufigen Iterationen hat seine eigenen Vorteile, ist aber nur ein Teil eines größeren Bildes. Bei Berg Software betreiben wir Software-Entwicklung auf der Basis von Agile/Lean-Prinzipien und Continuous Delivery/Continuous Integration-Flows.

Was ist damit gemeint?

Zunächst bauen wir Qualität ein. Unsere Kultur, unsere Mitarbeiter und unsere Tools ermöglichen es uns, Probleme sofort zu erkennen, wenn es einfacher und kostengünstiger ist, sie zu beheben.

Dies ist durch kontinuierliches Testen möglich: Automatisierte Tests werden gegen jeden Commit ausgeführt, um schnelles Feedback zu allen Änderungen zu erhalten. Die Arbeit wird erst dann beendet, wenn alle relevanten automatisierten Tests bestanden sind.

Wenn wir dann die Arbeit in kleinere Einheiten aufteilen, sind wir in der Lage, schnell Ergebnisse zu liefern. Gleichzeitig hilft es uns, häufig Feedback zu bekommen, um den Kurs zu korrigieren.

Unsere Mitarbeiter widmen sich den höherwertigen Problemlösungen, während die Computer die sich wiederholenden Aufgaben übernehmen. Repetitive Aufgaben werden automatisiert, damit die Softwareentwickler frei für kreative Arbeit sind, idealerweise an einem wachsenden Tech-Stack.

Und nicht zuletzt streben wir nach kontinuierlicher Verbesserung. Jeder ist für die immer höhere Leistung der Software-Lösungen/Produkte, die wir liefern, verantwortlich und arbeitet daran mit.

—
Fazit

Vergewissern Sie sich noch vor dem Programmieren, dass das Software-Entwicklungsteam Ihre Business-Ziele und die gewünschten Funktionen/Features versteht und diese dann in einzelne Module wie Technologien, Architektur, iterative Pläne und regelmäßige Ergebnisse umsetzt. Auf diese Weise behalten Sie die volle Kontrolle über den Zeitplan, die Qualität und die Möglichkeit, bei Bedarf Dinge zu ändern.

＿

Sie würden gerne Ihre Erfahrungen im Bereich Digitalisierung mit uns teilen? Wir freuen uns auf Ihre Kontaktaufnahme!