User Centric Development

Heute habe ich die folgende Aussage gelesen, die einige Fragezeichen für die Arbeit im Produktmanagement aufwirft.

„Hard- und Softwareanbieter überbieten sich gerne mit der Aufzählung von vielen tollen neuen Funktionen ihrer Produkte. Sie versprechen: Der Gebrauch modernster Technik spart Zeit und Nerven und gestaltet den Arbeitsalltag von Managern und Mitarbeitern sehr viel angenehmer.

Die Sache hat nur einen Haken: Einer Studie des Marktforschers Forrester zufolge nutzen nur wenige Mitarbeiter tatsächlich einen nennenswerten Teil dieser modernen Technik. Die meisten würden auch mit einem spartanisch ausgestatteten Rechner auskommen“ – in → Die meisten Programme sind überflüssig

Abweichungen

Meiner Erfahrung nach kann es aus folgenden Gründen zu einer Differenz zwischen der Leistungsfähigkeit der entwickelten Software und der Nutzung kommen:

• Adaption: Bestimmte Features erfordern einen Upgrade der Software, oder sie machen eine intensive Vorbereitungsphase notwendig, oder Ihre Installation ist mit großem Aufwand verbunden. In diesen Fällen ist eine lange Adaptionszeit erforderlich, damit Nutzer die erstellte Software überhaupt nutzen können. Hier hilft eigentlich nur, die Verkürzung von Auslieferungstakten, oder die Verbesserung der Erlernbarkeit. Auch muss man herstellerseitig manchmal einen langen Atem haben (können), da sich an den langen Adaptionszeiten nicht immer etwas ändern läßt
• Usability: Die Software ist komplex (d.h. sie erfordert eine lange Einarbeitungsphase), oder sie ist kompliziert (d.h. sie ist schwer zu erlernen/zu nutzen), oder sie ist überfrachtet. In diesen Fällen werden Barrieren aufgebaut, die die Nutzbarkeit herabsetzen. Nutzer weichen hier oft aus, d.h. arbeiten mit alternativen Mitteln, und verwenden die Software einfach nicht. Um diesen Effekt zu verhindern, sollte man nach den Methoden des User Centric Design arbeiten, und die Software so gestalten, dass die Nutzung möglichst einfach ist.
• Requirements: Die Software arbeitet nicht so, wie erwartet, und es liegen Probleme auf der Ebene der Anforderungen vor. In solchen Fällen weicht die Funktionsweise der Software davon ab, wie der Nutzer arbeiten würde. Es kann auch vorkommen, dass die Software Lücken aufweist, d.h. eine Nutzung nur eingeschränkt möglich ist. Solchen Fällen kann man gut begegnen, indem man ein ausgedehntes Requirementsengineering implementiert, oder indem man sich ausreichend Zeit nimmt, um die Anforderungen zu verstehen.
• Spezialisierung: Wenn sich eine umfangreiche Software an unterschiedliche Nutzergruppen richtet, kann es vorkommen, dass Teile der Software ungenutzt bleiben (genau die Teile für die es im speziellen Anwendungsfall nur wenige Nutzer gibt). hier helfen Ansätze, die Software rollenbasiert aufzuteilen, und alternative Nutzungen zu unterstützen.

Weiterführende Informationen

Das Original dieses Artikels ist auf →Der Produktmanager erschienen (©Andreas Rudolph). Regelmäßige Artikel gibt es über die (→Mailingliste), oder indem Sie →mir auf Twitter folgen. In der Online Version finden Sie hier die versprochenen weiterführenden Links:

This entry was posted on Dienstag, Dezember 15th, 2009 at 5:16 pm. It is filed under Innovation, Thema des Tages and tagged with Anforderungen, Beispiele, Concept Prototyping, Rolle des PM. You can follow any responses to this entry through the RSS 2.0 feed.