5 Kategorien: Ein pragmatischer Leitfaden zur Klassifizierung von Entwicklungsprojekten

Menschen entwickeln Produkte unterschiedlichster Art: Von der Gaming-App bis zum Betriebssystem, vom Hörgerät zum MRT-Scanner, Spielzeugdrohne bis Rakete, von einer einzelnen Industrieanlage bis zum Smartphone in Millionenauflage, und alles mögliche dazwischen. Um den richtigen Entwicklungsansatz zu finden, müssen wir unser Produkt erst einmal verstehen. In diesem Artikel stelle ich eine Klassifizierung vor, das diese anhand von fünf Dimensionen klassifiziert.

Diese Klassifizierung ist eher für Teams gedacht, die erst eine moderate Kompetenz in der Produktentwicklung haben, diese aber verbessern wollen. Sie kann aber auch nützlich sein für Unternehmen, die schon lange im Markt sind und feststellen, dass sie ihr Produkt und ihre Entwicklungsprozesse neu überdenken müssen.

Dieses Thema werde ich in meinem für nächstes Jahr geplantem Buch Product Velocity ausführlich behandeln.

Warum Produkte klassifizieren?

Eine große Herausforderung in der heutigen Produktentwicklung ist Geschwindigkeit. Zum Beispiel ist die Automobilindustrie unter enormen Druck durch BYD, die Fahrzeuge inzwischen in 18 Monaten entwickeln, während der Rest der Welt mehr als doppelt so lange benötigt.

Geschwindigkeit erreichen wir unter anderem dadurch, dass wir alles weglassen, was wir nicht brauchen. Zum Beispiel:

• Wenn ein Produkt keine Complianceanforderungen erfüllen muss, dann brauchen wir in unserem Entwicklungsprozess nicht den entsprechenden Overhead mitzuschleppen, wie eine entsprechende Dokumentengenerierung oder feingranulare Versionierung.
• Je nach Hardwarelastigkeit wird es unumgänglich sein, in Simulationsumgebungen zu investieren, möglicherweise auch in Hardware-in-the-Loop. Das ist extrem Aufwändig, aber für die SpaceX-Raptor-Entwicklung hat sich dieser Aufwand gelohnt.
• Schnittstellen formal zu spezifizieren ist aufwändig, kann aber in bestimmten Szenarien die Entwicklungsgeschwindigkeit drastisch erhöhen.

Wenn wir Systeme wie Autos, Flugzeuge oder auch Software herstellen, dann verstehen wir in der Regel, was wir brauchen. Doch ein Großteil der Produkte fallen in andere Kategorien: Industrielle Datenlogger, Registrierkassen, Türschließsysteme, Drucksysteme, Sortieranlagen und vieles mehr. In diesem Interview berichtet zum Beispiel Andreas Willert, wie der Hersteller von Brandschutzanlagen die Zertifizierungszeit drastisch reduzieren konnte.

Wenig Prior Art

Ich möchte das Rad nicht neu erfinden und hatte mich auf die Suche nach einer passenden Klassifizierung oder Taxonomie gemacht.

In Kapitel 5 der ISO 15288 Systems concepts werden einige Aspekte angesprochen, die für die Entwicklung wichtig sind, aber keine Klassifizierung. Zum Beispiel erwähnt Kapitel 5.4.3, dass die ISO/IEC/IEEE 21841 eine normalisierte Taxonomie für Systems of Systems (SoS) bereitstellt. Auf diese Zuzugreifen würde ich auch empfehlen. Aber dazu müssen wir uns erst sicher sein, dass wir ein SoS entwickeln.

Das SEBok hat ein Kapitel zu Types of Systems, welches durchaus nützliche Informationen enthält, die auch in diese Kategorisierung eingeflossen sind, aber nicht geeignet sind, eins zu eins übernommen zu werden.

Ich habe weitere Literatur gefunden, die sich dann aber immer nur auf eine Produktklasse beschränkt, wie Eingebettete Systeme oder reine Softwaresysteme. Ein griffiges allgemeineres Klassifizierungsschema fand ich nicht.

Liebe/r Leser/in: Gibt es bereits ein Klassifizierungsschema für Produkte, habe ich etwas übersehen? Wenn ja, dann gib mir bitte einen kurzen Hinweis. Vielen Dank!

Die Klassifizierung

Ein einzelnes Produkt kann mit diesem Schema schnell kategorisiert werden. Dazu gehen wir die fünf Kategorien durch und wählen für jeden den passenden Punkt aus.

1. Systemaufbau und Komplexität

• Eigenständige Systeme: Ein einzelnes Produkt, das als unabhängige Einheit mit klar abgegrenzten Funktionen entworfen und bereitgestellt wird.
• Deterministisch integrierte Systeme: Mehrere Teilsysteme arbeiten in einer eng gekoppelten Architektur zusammen, ohne emergentes Verhalten.
• Emergent integrierte Systeme: Integrierte Systeme, deren Verhalten aufgrund adaptiver oder autonomer Entscheidungsfindung nicht vollständig vorhersagbar ist.
• Systeme von Systemen: Zusammengesetzt aus unabhängigen Systemen, die eigenständig funktionieren, aber gemeinsam höhere Ziele erreichen.

2. Abhängigkeit der Software von Hardware

• Reine Software: Läuft vollständig softwarebasiert ohne Abhängigkeit von spezieller Hardware.
• Generisch hardwareabhängig: Benötigt Standardhardware, aber keine Spezialhardware.
• Hardwareabhängig: Software, die spezifisch mit Hardwarekomponenten interagiert, die für die Funktion essenziell sind.
• Eingebettete Systeme: Software ist Teil der Firmware auf dedizierter Hardware, ohne Trennung für den Endnutzer.

3. Grad der Compliance und Sicherheitskritikalität

• Keine oder minimale Compliance: Produkte ohne oder mit minimalen gesetzlichen Vorgaben, abgesehen von allgemeinem Verbraucher- und Handelsrecht.
• Moderate Compliance-Anforderungen: Produkte mit spezifischen Vorgaben, Standards oder Zertifizierungen, bei denen Fehler jedoch nicht direkt Gesundheit oder Sicherheit gefährden.
• Sicherheitskritisch: Produkte, bei deren Versagen Menschen oder Umwelt erheblich geschädigt werden können.

4. Update- und Lebenszyklus-Supportmodell

• Continuous Delivery (Software): Software wird sehr häufig aktualisiert, teilweise mehrmals täglich, wobei automatisierte Deployment-Pipelines neue Versionen nahtlos an die Nutzer ausliefern. Dies ist in der Regel nur bei serverbasierter Software möglich.
• App Store- / Marketplace-Verteilung (Software): Software wird über App Stores oder Marktplätze bereitgestellt; Updates werden vom Nutzer manuell oder halbautomatisch installiert.
• Feld-aktualisierbare Firmware: Eingebettete Software, die nach dem Deployment per Over-the-Air-Update, USB oder Servicetools aktualisiert werden kann.
• Verbrauchsmaterialien: Physische Komponenten, die vom Nutzer oder Servicepersonal regelmäßig ersetzt werden müssen, um Betrieb oder Qualität sicherzustellen.
• Physische Ersatzteile: Physische Baugruppen, die im Produktlebenszyklus bei Ausfall, Verschleiß oder für Upgrades ersetzt werden müssen.

5. Anpassung und Konfigurierbarkeit

• Standardprodukt „von der Stange“: Ein einheitliches Produkt, das für alle Kunden identisch ist.
• Konfigurierbares Produkt: Ein Standardprodukt, das durch vordefinierte Einstellungen, Optionen oder Hardwarevarianten an unterschiedliche Einsatzszenarien angepasst werden kann.
• Plattform-Lösung: Eine Kernarchitektur, die bewusst als Basis für spezialisierte Lösungen konzipiert wurde. Unterstützt Konfiguration und kontrollierte Anpassung durch Integratoren, Partner oder fortgeschrittene Nutzer.
• Kundenspezifisch pro Implementierung: Ein Produkt, das für jeden Kunden durch projektspezifische Entwicklung oder Montage angepasst wird und auf einem gemeinsamen Kern basiert.
• Vollständig maßgeschneiderte Lösung: Jede Implementierung ist ein Einzelprojekt, das von Grund auf für spezifische Kundenanforderungen entworfen und gebaut wird.

Warum gerade diese Kategorien?

Vorweg: Das Schema ist aktuell in der Reviewphase und wird sich möglicherweise noch weiter verändern.

Die Auswahl dieser Kategorien basiert auf der praktischen Beobachtung, dass sie in der Mehrheit der Entwicklungsprojekte besonders starken Einfluss auf die Gestaltung des Vorgehensmodells, der Teamstrukturen und der Werkzeuge haben. Sie dienen also weniger einer theoretischen Vollständigkeit als einer pragmatischen Orientierungshilfe.

Dabei sind sie zumindest in dieser Form nicht vollständig orthogonal: Zum Beispiel hängen Systemaufbau und Konfigurierbarkeit zusammen. In diesem Fall habe ich sie in zwei Kategorien aufteilt, da das erste die Entwicklersicht ist, das zweite die Kundensicht. Das kann sich unterschiedlich auf die Entwicklungsprozesse auswirken.

Mir ist bewusst, dass es weitere mögliche Dimensionen gibt, etwa Markt- oder Geschäftsmodell-Aspekte oder Teamgröße. Diese können in einem erweiterten Modell durchaus berücksichtigt werden, erscheinen mir aber im Moment eher zweitrangig.

Und wie geht es weiter?

Allein schon die Übung, das zu entwickelnde Produkt zu bewerten, hilft, das Verständnis zu schärfen. Die Stakeholder werden gezwungen, sich frühzeitig Gedanken über die Entwicklung zu machen.

Doch mein Ziel ist es, basierend auf der Klassifizierung Empfehlungen und Hinweise für die Wahl und Konfiguration des Entwicklungsprozesses (einschließlich Werkzeuge) geben zu können. Das wird Thema eines zukünftigen Artikels sein.