Produktmanagement im Technologiesektor – Tipps zu den Themen Produktmanagement und Innovation. Von Andreas Rudolph
Einstein hat uns die folgenden zwei Zitate hinterlassen, auf die ich mich in diesem Artikel konzentrieren möchte (siehe → Zitatendatenbank):
- Das Problem zu erkennen ist wichtiger, als die Lösung zu erkennen, denn die genaue Darstellung des Problems führt zur Lösung – Einstein
- Probleme kann man niemals mit derselben Denkweise lösen, durch die sie entstanden sind – Einstein
Einstein’s Zitate verdeutlicht einige Punkte die man unbedingt beachten sollte, wenn man eine technische Lösung, oder ein technisches Produkt entwickelt:
Diese Punkte hören sich zunächst einmal selbstverständlich an. Jedoch wie oft kommt es in der Praxis vor, dass man sich mit vollem Eifer in die Problemlösung stützt, weil man davon ausgeht das man das Problem bereits verstanden hat, für das man seine Lösung entwickelt.
Leider stellt man oft erst im Laufe des Entwicklungsprozesses fest, dass man sich nicht ausreichend viele Gedanken gemacht hat. Oft ist die Spezifikation doch nicht so ausgereift, wie man eingangs gedacht hatte, zum Beispiel, weil man entscheidende Informationen zum Erstellungszeitpunkt nicht hatte.
Eine detaillierte Problemanalyse erleichtert nicht nur die spätere Entwicklung. Vielmehr ist sie auch aus ökonomischer Sicht wichtig. Denken Sie nur daran, dass die Gesamtkosten eines Entwicklungsprojektes im Zeitablauf zunehmen.
Dies bedeutet, dass jeder konzeptionelle Fehler, den man zu spät, oder gar nicht entdeckt, teuer werden kann. Oft übersteigen die Fehlerbehebungskosten sogar den Aufwand, den man für eine angemessene Problemanalyse und Spezifikation aufzuwenden gehabt hätte.
In diesem Artikel finden Sie eine Checkliste, die Ihnen dabei helfen soll, Kundenanforderungen zu verstehen. Beachten Sie, dass es die eine Problemlösungsmethodik nicht gibt, die auf jedes Problem passen würde. Ich konzentriere mich deshalb auf typische Ansatzpunkte.
Wenn Sie sich noch einmal die → Strategische Rolle des Produktmanagements vergegenwärtigen, werden Sie feststellen, dass die Checkliste nicht phasengebunden ist. Da in jedem Arbeitsgebiet des Produktmanagement Problemlösungsstrategien für bestimmte Fragestellungen notwendig sind, können Sie die Checkliste universell verwenden. Besondere Schwerpunkte liegen hierbei vielleicht auf der Market Analysis, Product Strategy Development und dem Product Planning.
In meiner eigenen Erfahrung helfen die folgenden 10 Problemanalyseschritte weiter (clicken, um zu vergrößern), um eine Aufgabenstellung zu strukturieren und zu verstehen.
Viele Aufgabenstellungen sind zunächst einmal abstrakt formuliert, oder sie bestehen aus unterschiedlichen Elementen. Oft ist es auch so, dass uns Kunden oder sonstige Auftraggeber die eigentlichen Aufgabenstellungen nicht direkt, sondern quasi verklausuliert darstellen.
Dies ist ein stückweit natürlich, weil Kunden die Lösung selbst noch nicht kennen, d.h. Ihnen selbst das notwendige Detailwissen fehlt, um Ihnen eine fertige Beschreibung geben zu können. Zunächst ist es deshalb hilfreich, dass Sie die Aufgabenstellung in eigenen Worten umformulieren.
Viele Teile der Problembeschreibung setzen ein bestimmtes Verständnis voraus, oder gründen sich auf einem bestimmten Weltbild. Es ist deshalb natürlich, dass Ihre umformulierte Problembeschreibung vom Verständnis Ihres Kunden abweicht, oder sogar unvollständig ist. Deshalb ist notwendig, dass Sie in einem späteren Analysezeitpunkt die umformulierte Aufgabenstellung mit Ihrem Auftraggeber klären, und Verständnisprobleme lösen, bzw offene Punkte nachklären.
Beispiel: Ihr Kunde fordert von Ihnen, dass die Software leicht zu bedienen sein soll. Umformuliert lautet die Aufgabenstellung: Ich muss viele Daten in Felder eingeben, und möchte möglichst mit einer Taste von Feld zu Feld wechseln können, ohne hinzusehen. Die Software sollte deshalb nicht mausbasiert, sondern tastenbasiert sein, und sie sollte umfangreiche Feldprüfungen durchführen, um Fehleingaben zu minimieren.
Jede Aufgabenstellung, egal wie simpel sie zunächst erscheint, basiert auf Annahmen, die Ihr Auftraggeber getroffen hat. Während einige dieser Annahmen ungenau oder falsch sein können, könnten andere Annahmen irreführend sein. Genau solche Annahmen stellen hinterher in der fertigen Lösung eine Sollbruchstelle dar.
Es ist deshalb sinnvoll, dass Sie die Annahmen explizit formulieren, und so das Weltbild Ihres Auftraggebers besser verstehen. Besonders wichtig sind hierbei die impliziten Annahmen. Wenn implizite Annahmen den Lösungsweg vorzeichnen, können sie genau deshalb den Blick auf alternative Lösungen verstellen.
Beispiel: Sie arbeiten in der Softwareentwicklung mit einem leistungsstarken Rechner. Ihr Zieluser verwendet Ihre Software in einem Kühlhaus. Dort herrschen schlechte Sichtbedingungen, und die User tragen Handschuhe. Ihre Zieluser werden deshalb implizit eine andere Auffassung von der Ergonomie Ihrer Software haben, als Sie selbst. Es wäre deshalb fatal für Ihr Produkt, wenn Sie nicht vorab klären würden wie die Nutzer Ihre einsetzen wollen. So könnten Ihre Nutzer erwarten, dass sich Ihre Software nicht nur über Tasten bedienen lässt, sondern darüberhinaus mit so wenigen Tasten auskommt, dass sie einhändig bedient werden kann.
Technische Aufgabenstellungen, oder Problembeschreibungen existieren normalerweise nie kontextfrei, d.h., dass sie eingeordnet sind in einen übergeordneten Zusammenhang. Oft sind Aufgabenstellungen initial sehr detailliert und detailorientiert formuliert. Deshalb ist es oft hilfreich, eine generellere Perspektive einzunehmen, d.h. sich aus dem eigentlichen unmittelbaren Aufgabenkontext zu lösen, und den Blick auf das große Ganzezu richten (siehe zum Beispiel Regeln für das Brainstorming). In diesem Abstraktionsprozess helfen Ihnen typische Fragen weiter, wie zum Beispiel:
Eine weitere Methode ist die Methode der verbalen Abstraktion. Hierbei verwenden Sie anstelle der eigentlichen Bezeichner die → Gattungsnamen.
Beispiel: Die Kunden möchten Ihre Lösung im Internet einsetzen. Bereits aus dem übergeordneten Kontext wissen Sie, dass Datensicherheit ein großes Thema im Internet ist, d.h. dass der Kunde Ihre Lösung sicherlich in einer → Demilitarized Zone verwenden wird, und damit abgeschirmt betreiben will.
Wenn Aufgabenstellungen einen übergeordneten Kontext haben, lassen sie sich oft auch noch weiter teilen und herunterbrechen. Wenn Sie den übergeordneten Kontext verstanden haben ist es deshalb hilfreich, wenn Sie die Aufgabenstellung verfeinern.
In dieser Phase verwenden Sie prinzipiell dieselben Methoden, wie im Abstraktionsschritt, nur zielen diesmal darauf ab, Details zu verstehen.
Beispiel: Damit Ihr Kunde das System im Internet verwenden, und in einer Demilitarized Zone einsetzen kann, kommen Sie zum Schluss dass Sie die Lösung teilen müssen. Sie benötigen eine Präsentationsschicht, die im Internet arbeitet, und einen Datenteil, der auf einem Server im Hintergrund angeordnet ist. Datenserver und Präsentationsschicht benötigen gesicherte Kommunikationskanäle über die sie Informationen austauschen können.
Technische Aufgabenstellungen können oft aus unterschiedlichen Blickwinkeln betrachtet werden. Um eine Lösung, bzw ein Produkt zu entwerfen, die diesen unterschiedlichen Betrachtungen gerecht wird, ist es sinnvoll, die Aufgabenstellung aus diversen Richtungen zu sehen.
Hierbei helfen Ihnen die Personas weiter, die ich bereits früher schon mehrfach erwähnt habe (siehe → Personas in der Produktentwicklung), oder die → Technik des morphologischen Kastens.
Beispiel: Die Kommunikation zwischen Frontend- und Backend-System kann auf unterschiedliche Art und Weise realisiert werden. Folgende Alternativen sind u.a. möglich:
Im späteren Enwicklungsprozess ist es sinnvoll, dass sie die Problembeschreibung vor Augen haben. Deshalb ist es notwendig, dass Sie die studierte Problematik dokumentieren. Hierbei sollten Sie darauf achten, keine unnötigen (verbalen) Vorgaben zu machen, wo nicht unbedingt sinnvoll.
Zum Beispiel sollten Sie sorgsam unterscheiden zwischen Muss-Anforderungen und Kann-Anforderungen.
Desweiteren sollten Sie die Problembeschreibung aktiv und positiv formulieren. Dies ist sinnvoll, weil passive und negative Formulierungen unnötige innere Widerstände provoziert, und selbst wieder ein Prägung vorgeben, d.h. das Lösungsspektrum einschränken.
Zum Beispiel: Anstatt zu formulieren, dass Ihre Software nicht ausfallen soll, sollten Sie konkreter angeben wann Sie wieviel Stillstand akzeptieren, z.B. indem Sie festlegen „Die Software wird nachts für 5 Minuten zu Wartungszwecken heruntergefahren“
Formulieren Sie so, dass klar wird Wer, Was, Wie, mit Welchem Resultat sicherstellen soll. Dies erleichert später zudem die Rollenverteilung.
Denken Sie bereits bei der Formulierung der Problembeschreibung daran, dass Sie sie später verwenden wollen, um eine Lösung zu entwerfen. Es ist deshalb sinnvoll, die Problembeschreibung nicht zu feingranular zu machen, und technische Lösungswege vorzudefinieren. Ihre internen Abnehmer müssen ein Stück weit hinter Ihrer Problembeschreibung stehen.
Dies fällt ihnen erfahrungsgemäß leichter, wenn die Teilaufgaben herausfordernden Charakter haben, und bereits so geschnitten sind.
Manchmal kommen Sie im Verständnis der Aufgabenstellung nicht richtig weiter. In diesen Augenblicken kann es hilfreich sein, eine gedankliche Gegenposition einzunehmen, und besonders kritisch auf die Szene zu schauen.
Diese Methode hilft ihnen ebenfalls, um die Problembeschreibung gedanklich abzugrenzen gegenüber anderen Problemen, die Ihre Lösung ggfs nicht adressieren soll.
Beispiel: Die Software erfüllt Anforderungen A,B,C. Anforderung D und E sind nicht vorgesehen als Teil der Problemlösung.
Viele Aufgabenstellungen sind vage formuliert, oder liegen nicht offensichtlich auf dem Tisch. Es ist deshalb sinnvoll, soviele nachvollziehbare Fakten zu sammeln, wie möglich. Hierfür stehen neben den Kundenaussagen, weitere externe Quellen zur Verfügung. Einige wenige Beispiele sind:
Um sich den Fakten zu nähern sollten Sie sich fragen, was sie über die Aufgabenstellung wissen, wie sie einen definierten Sachverhalt belegen können, oder wo genau die Defintionen nachzuvollziehen sind, von denen Sie ausgehen.
Eine angemessene Problembeschreibung hat viel mit der Perspektive zu tun, die Sie einnehmen. Es ist deshalb sinnvoll, Ihre Problemanalyse zu prüfen und zu verifizieren.
Hierfür stehen Ihnen unterschiedliche Kreativitätstechniken zur Verfügung.
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:
Ich arbeite seit vielen Jahren in der Softwareentwicklung für Unternehmensanwendungen bei der SAP SE. Dieser Blog ist privat, und die Meinungen sind meine eigenen. Sie sind hier richtig, wenn sie sich für Praxiserfahrungen im Produktmanagement für Investitionsgüter interessieren.
High Def WordPress Theme by Graph Paper Press
Subscribe to entries
Subscribe to comments
All content © 2024 by Der Produktmanager
