Formale Prozesse – Hinderungsgrund in der Entwicklung?

Im Systems Engineering haben sich seit vielen Jahren phasenorientierte Vorgehensmodelle etabliert, um Entwicklungsprojekte zu strukturieren. In der Praxis findet man häufig, dass der Entwicklungsprozess formalisiert wird und sich strikt an diesen Prozess gehalten wird. In diesem Blog wollen wir anhand eines Beispiels diskutieren, welche Probleme entstehen können, wenn sich zu stark an den formalen Prozess gehalten wird.

Formaler Prozess

Ein Entwicklungsunternehmen für Produktionsstraßen hat den phasenorientierten Entwicklungsprozess aus der oberen Abbildung definiert. In jeder dieser Phasen sind verschiedene Abteilungen verantwortlich für die Anforderungsdefinition. Erst nach Abschluss einer Phase werden die Dokumente an die Abteilung(en) der nächsten Phase übergeben und die nächste Phase beginnt. In dem Beispielprojekt werden in der ersten Phase die Kundenanforderungen durch das Produktmarketing definiert. In der zweiten Phase entwickelt und bewertet die Vorentwicklung neue Konzepte. In der dritten Phase werden die Architektur und das Gesamtsystem spezifiziert. In der vierten Phase werden die Subsysteme durch die jeweiligen Fachabteilungen spezifiziert und in der fünften Phase werden die Funktionen implementiert und in Betrieb genommen.

Problem

Im letzten Entwicklungsprojekt hat man jedoch festgestellt, dass das phasenorientierte Vorgehen dazu führt, dass nicht alle Kundenanforderungen abgedeckt sind. Die Ursache der Nicht-Implementierung von Kundenanforderungen lag darin, dass die Fachexperten und Softwareentwickler erst sehr spät im Projekt involviert wurden, da sich sehr streng an den Prozess gehalten wurde. Dieses hatte zur Folge, dass Fehlannahmen durch die Vorentwicklung, Einfluss auf die Architektur des Gesamtsystems hatte, diese Fehlannahmen jedoch erst in der fünften und letzten Phase entdeckt wurden. Um jedoch das Projektende nicht zu gefährden, wurden einige Kundenanforderungen nicht implementiert.

Lösung

Um frühzeitig mögliche Fehlannahmen zu vermeiden, liegt eine mögliche Lösung in sogenannten cross-funktionalen Teams, wie auch meine Kollegin in ihrem Blog zum agilen PEP schreibt. In jeder Phase werden Experten aus allen beteiligten Fachabteilungen involviert: Produktmanager, Experten aus der Vorentwicklung, Architekten, Fachexperten der Subsysteme und Softwareentwickler. Dadurch, dass bereits in frühen Phasen Experten aus verschiedenen Disziplinen / Fachabteilungen vertreten sind, können die Probleme aus verschiedenen Blickwinkeln beleuchtet werden und die jeweilige Expertise frühzeitig in die Lösung einfließen.

Diesen Beitrag hat Björn Czybik für HOOD geschrieben.