Prototyping ist Discovery-Arbeit

Agile Methoden haben unsere Arbeit revolutioniert — in der Softwareentwicklung und weit darüber hinaus.

Auffällig ist, dass diese Verbesserungen sich stark auf Delivery-Tätigkeiten konzentrieren, zumindest in großen Unternehmen und solchen Unternehmen, die auf lange Erfahrung in Softwareentwicklung und Systemintegration zurückblicken.

Obwohl durch die Bank zunehmend über die Wichtigkeit von Design und Design Thinking gesprochen wird sind hinsichtlich Discovery-Tätigkeiten weniger greifbare Fortschritte zu beobachten.

Zu oft kommen noch (ausschließlich) klassisches Anforderungsmanagement und traditionelle Business-Analysis-Ansätze zum Einsatz. De facto glauben viele Kunden und Dienstleister immer noch, Projektergebnisse und Produkte früh im Prozess zumindest auf konzeptioneller Ebene belastbar — und abschließend — definieren zu können.

Für Initiativen mit hohem Innovationscharakter ist dies jedoch eine Fehleinschätzung. Innovation erfordert regelmäßig ein exploratives Vorgehen nicht nur bezüglich des Lösungsentwurfs und der anschließenden Umsetzung (d.h. Delivery), sondern insbesondere auch für die Situationsanalyse, Problemidentifikation und Problemauswahl (d.h. Discovery).

Prototyping kann ein essenziell wichtiges Discovery-Werkzeug sein. Die Entwicklung von Prototypen zur Evaluierung der technischen Machbarkeit einer bestimmten Lösung (Proof-of-Concept) ist bekannt, wird in meiner Erfahrung jedoch in der Softwareentwicklung weniger oft eingesetzt als es sinnvoll erscheint. Dies mag damit zusammenhängen, dass die hierfür notwendige Softwareentwicklung oft als Delivery-Arbeit angesehen wird und die damit konkurrierende Entwicklung neuer Features regelmäßig höher priorisiert wird.

Eine hohe Umsetzungsgeschwindigkeit kommt vor allem daher, das richtige Produkt zu entwickeln. Wir wollen also nur die Elemente tatsächlich entwickeln, die mit hoher Wahrscheinlichkeit erfolgreich sein werden. Entsprechende Tests müssen dann also in der Discovery erfolgen.

Erinnern wir uns daran, dass erfolgreiche Produkte nicht nur technisch machbar (technical feasibility) sondern auch kommerziell tragfähig (business viability) und für Menschen wünschenswert (desirability to humans) sein müssen (siehe z.B. https://www.google.com/search?tbm=isch&q=desirable+feasible+viable).

Es liegt auf der Hand, dass Prototyping auch für diese beiden anderen Dimensionen sinnvoll und notwendig ist. Unterschiedliche Aspekte von Desirability können im Rahmen der Product Discovery gut mit Hilfe von Prototypen evaluiert werden: Ist das Problem, das wir erkannt haben, real? (Gibt es genügend Menschen, die die Situation auch als Problem wahrnehmen?) Löst die von uns anvisierte Lösung das Problem effektiv?

Auch die kommerzielle Tragfähigkeit können wir über Prototypen im Rahmen unserer Discovery-Tätigkeiten evaluieren: Können wir aus der anvisierten Lösung ein tragfähiges Produkt machen? Gibt es einen Markt für dieses Produkt (bzw. können wir einen Markt schaffen), d.h. würden genug Kunden für dieses Produkt genug Geld ausgeben?

(Siehe hierzu auch The Lean Startup.)

Wichtig ist, dass diese Prototyping-Tätigkeiten klar dem Bereich Discovery zuzuordnen sind. Dies ist insbesondere wichtig, falls Software-Prototypen entwickelt werden. Die entsprechenden Aktivitäten konkurrieren also ggf. mit anderen Discovery-Tätigkeiten — sie sollten jedoch niemals mit Delivery-Tätigkeiten in Konkurrenz stehen, da letztere sonst oft (mit negativen Folgen für die gesamte Initiative) höher priorisiert werden.

Selbstverständlich wollen wir auch im Rahmen der Discovery-Tätigkeiten die Kompetenz des gesamten Teams zum Einsatz bringen. Das heisst, das auch eher ‚delivery-orientierte‘ Teammitglieder in die Discovery einbezogen werden — und dies schließt Softwareentwickler ausdrücklich mit ein und zwar nicht nur für die Entwicklung von Software-Prototypen.

Kurz: Ein stärkerer Fokus auf Discovery-Arbeit kann die Produktentwicklung erheblich verbessern und beschleunigen. Die Entwicklung von Prototypen ist Discovery-Arbeit. Das gilt insbesondere für die Entwicklung von Software-Prototypen.

2 Gedanken zu „Prototyping ist Discovery-Arbeit

  1. Pingback: Discovery & Delivery: erst das Problem, dann die Lösung | Oliver Baier

  2. Pingback: Digitalisierung in mittleren Unternehmen und dem Mittelstand | Oliver Baier

Die Kommentarfunktion ist geschlossen.