Warum es meiner Meinung nach keine gute Idee ist eine Fachabteilung die Spezifikation einer Software schreiben zu lassen.
Es hat sich heutzutage in vielen Unternehmen durchgesetzt die Spezifikation einer Software von der Fachabteilung schreiben zu lassen. Nach dem Motto: Die Spezialisten des Fachs wüssten ja schon was sie benötigen und könnten das Bestens beschreiben. Leider ist das ein fataler Irrtum den viele Firmen teuer bezahlen. Es ist korrekt, dass die Fachabteilungen ihr Geschäft am Besten kennen und wissen was sie benötigen. Jedoch gibt es mehrere übergeordnete Gründe, sie das nicht direkt in eine Spezifikation schreiben zu lassen.
Die Fachspezialisten sind nicht unbedingt die besten "Beschreiber", insbesondere der eigenen Themen für (fachfremde) Entwickler.
Softwareentwicklung unterliegt budgetären und technischen Rahmenbedingungen, die die Fachabteilungen nicht in Betracht ziehen.
Die Fachabteilungen besitzen i.A. nicht das Know-How im technischen Lösungsraum, um Ziele zu erreichen.
Diese Einschränkung ist kein "Fehler" oder mangelndes Wissen, sondern intrinsisches Problem aller Fachabteilungen. Sie beherrschen ihr Metier - und eben nicht ein anderes (z.B. das der Softwareentwicklung)
Fachabteilungen sind die Endverbraucher der entwickelten Software.
Und um den Vergleich mal zu wagen, kein Produkt für den Endverbraucher wird vom Endverbraucher spezifiziert. Keine Kaffeemaschine wird vom Barista entworfen, kein Smartphone vom Nutzer. Wenn Anwender die eigenen Anforderungen beschreiben, werden sehr oft für sie vermeintliche Selbstverständlichkeiten weggelassen. Typisch ist auch die Beschreibung des Best Case oder Standardwegs, ohne die Ausnahmen zu nennen. Wenn dann doch die Bearbeitung von Ausnahmen beschrieben werden, geschieht dies oft in hoher Detailforderung bei voller Automatisierung in der Software ohne Implementierungs- und Pflegeaufwand gegen evtl. Halbmanuelle Lösungen abzuwägen. Es gibt Ausnahmen wie die Formel 1, dort Entwickelt das Team die Ware selber. Mit immensen Kosten und Aufwand.
Auf meinem beruflichen Weg habe ich viele Fachabteilungen im übertragen Sinne Autos mit 3 Liter Verbrauch bei erreichbaren Spitzengeschwindigkeiten von 300 km/h und 40 Tonnen Zuladung spezifizieren sehen. Das solche Produkte am Ende scheitern oder zur Enttäuschungen führen ist nachvollziehbar. Solche Übertreibungen sind selten, doch könnten Sie den noch machbaren Rahmen abschätzen? Genauso wenig dürfen wir von den Fachabteilungen erwarten, dass sie es für Software könnten. Es ist legitim für Fachabteilungen Wünsche zu äußern und Notwendigkeiten zu kommunizieren. Die Beschreibung des zu liefernden Produkts müssen andere übernehmen.
Der Produt Owner als eine Lösung des Problems
Im Verbrauchermarkt sind Produktdesigner oder Produktingenieure eine übliche und anerkannte Rollen bei der Produktentwicklung. Genau diese Rolle braucht es auch in der Softwareentwicklung. Die Softwareentwicklungsmethode SCRUM hat diese Erkenntnis bereits umgesetzt und etabliert den Product Owner zwischen Fachabteilung (Endanwender) und SCRUM Team (Softwareentwickler). Er alleine hat die Entscheidungshoheit über die Umsetzung. Ihm obliegt es die Anforderungen zu sammeln, Erwartungshaltungen zu handhaben und ein wertiges Produkt zuliefern.
Mehr zur Rolle des Product Owner im meinem nächsten Beitrag. "SCRUM: Der Product Owner als zentrale Figur"