Inzwischen ist die Frage nach dem Schwerpunkt ja schon fast eine Serie – Features oder Qualität?

Ich erlebe es immer wieder, daß man so genau und ausgefeilt an Spezifikationen arbeiten kann, wie man will. Oft lernt man die wahren Anforderungen erst dann kennen, wenn der Nutzer die Software in den Händen hält, und sie ausprobieren kann.

Wie wichtig ist Qualität?

Um die Weihnachtszeit ging eine Meldung durch das Netz, die sehr gut zeigt, wie wichtig, die Qualität einer Softwareanwendung sein kann, gerade, wenn es sich um geschäftskritische Anwendungen handelt (→Barneys Forced to Cancel Several Online Orders Three Days Before Christmas Due to Unfortunate IT Glitch):

The luxury retailer emailed customers four days before Christmas, informing them that due to technical problems with their system, their Holiday orders will not be filled this year, Racked is reporting. Here’s the email customers received:

Die erwähnte e-Mail, die dort im Wortlaut abgedruckt wird, sagt im Grundsatz aus, daß es aufgrund eines Softwarefehlers zu Datenverlusten gekommen ist, und daher einige Aufträge nicht ausgeführt werden können.

Um die Kunden nicht zu verprellen, war der betroffene Hersteller gezwungen, jeden betroffenen Kunden aufzusuchen, und weitere Schritte zu besprechen.

Der Softwarefehler hat somit mindestens den entgangen Umsatz gekostet, und die Kosten für die Kundenpflege. Er war also vermutlich alles andere als billig, und zeigt, daß Qualität auch einen Wert hat.

Beta Tests

Im Entwicklungsprozess macht man diverse Tests, oder prüft die Qualität der Software mit anderen Methoden. Manche dieser Tests finden sogar mit Kunden statt.

Viele Hersteller liefern jedoch die eigentliche Software nicht sofort dann aus, wenn diese fertig entwickelt und intern getestet ist. Sie geben die Software vielmehr in zwei Schritten frei, die man oft als “Betatestphase”, und als “Golden Master” bezeichnet.

Der Beta Test wird genau zwischen Fertigstellung und endgültiger Freigabe durchgeführt, und dient dazu, die Nutzungserfahrungen von realen Nutzern einzusammeln, bevor man die generelle Auslieferung riskiert. Gegenwärtig macht zum Beispiel die Firma Adobe einen Beta Test zu einer neuen Version eines Bildbearbeitungsprogrammes (siehe →Lightroom 4 beta now available).

Wie in dem verlinkten Artikel dargestellt, unterliegen Beta Tests eigenen Regeln, um auf der einen Seite sicherzustellen, daß sich Nutzer beteiligen. Auf der anderen Seite soll sichergestellt bleiben, daß diesen Kunden keine (finanziellen) Nachteile entstehen, insbesondere, wenn sich herausstellt, daß die Software noch fehlerhaft ist. Adobe macht dazu diese Tests auf der Grundlage von kostenlosen Beta Versionen, die eigentlich bereits fehlerfrei arbeitet. Es gibt jedoch auch andere Ansätze.

Vorteile und Nachteile

Beta Tests haben viele Vorteile:

• Sicher der größte Vorteil ist der, daß man das Feedback von echten Nutzern erhält, auf der anderen Seite jederzeit die finale Version zurückhalten könnte (falls sie sich als zu fehlerhaft herausstellt)
• Weiterhin kann man so oft weitaus mehr Hard- und Softwarekombinationen prüfen, als man dies jemals Inhouse machen könnte (alleine schon, weil man den erforderlichen Maschinenpark garnicht vorhalten kann).
• Man erhält bereits frühzeitig mediale Aufmerksamkeit, und kann so den Markt vorbereiten.
• Diese Tests erlauben einem auch, die Teile der Software zu prüfen, die sonst nur schwer zu testen wären, wie zum Beispiel die Bedienbarkeit, oder die Gebrauchsfähigkeit.

• Der Betatest kann negative Auswirkungen auf den Umsatz haben, da ja nun jeder weiß, daß eine neue Softwareversion bevorsteht, und sich ggfs zurückhält mit dem Einstieg in die alte Version
• Wenn die Software sehr weit neben den Anforderungen liegt, oder, wenn sie sehr viele Fehler enthält, hilft einem auch kein Beta Status. Die Version kann in Verruf geraten.
• Das Verfahren ist relativ aufwendig und teuer
• Der Wettbewerb erhält sehr frühzeitig Informationen über das neue Produkt

Weiterführende Informationen

Wenn Ihnen der Artikel gefallen hat, warum nicht meinen Blog abonnieren →Mailingliste, oder →mir auf Twitter folgen?

Weiterführende Informationen im Internet

Hier finden Sie weiterführende Informationen zum heutigen Thema im Internet:

• →Barneys Forced to Cancel Several Online Orders Three Days Before Christmas Due to Unfortunate IT Glitch
• →Lightroom 4 beta now available
• →International Software Testing Qualifications Board

Weiterführende Informationen auf www.Produkt-Manager.net

In meinen älteren Artikeln finden Sie weiterführende Informationen zum heutigen Thema:

• →Feature versus Qualität
• →Final Cut Pro – Produktmanagement- Perspektive
• →Exploratory Testing – Scrum Teams testen wie Touristen

Der Spiegel hat neulich in seinem Artikel → Wer hat’s verbockt? HP! mehr über die Hintergründe geschrieben, die hinter Hewlett Packard’s jüngster Entscheidung stehen, das Segment der mobilen Geräte einzustellen.

Der Vorgang, und der Artikel sind ein gutes Beispiel für die Frage, wie man erfolgreiche Produkte gestaltet.

Blick zurück

Vor einigen Monaten hatte sich HP aufgemacht, mit einem eigenen iPad-artigen Gerät gegen Apple anzutreten. Das Gerät war nicht sonderlich erfolgreich, um nicht zu sagen: Es war ein Desaster.

HP hat daraufhin urplötzlich umgesteuert, und die Geräte vom Markt genommen. Die Produktion wurde eingestellt, und man hat den Restbestand der Geräte verramscht. Auch wollte man die ganze Sparte loswerden und hat in dem Zusammenhang auch seinen CEO entlassen.

Wie der Spiegel sagt, war dieses Desaster nicht billig für HP:

“Das Tablet-Abenteuer ist Hewlett-Packard (HP) teuer zu stehen gekommen. Insgesamt 3,3 Milliarden Dollar musste das Unternehmen im vergangenen Jahr abschreiben”

Der Artikel erklärt kurz, was im Vorfeld abgelaufen war:

• HP hatte eine Software von Palm übernommen.
• Um Apple schnell etwas entgegensetzen zu können, erhöhte man die Entwicklungsbudgets drastisch, und stellte viel Personal ein.
• Um starten zu können, mußte die WebOS Software signifikant umgeschrieben werden (was einem beim Kauf von Palm nicht aufgefallen war).
• Man nahm sich (nur) neun Monate Zeit, und hat am Ende ein Gerät veröffentlicht, daß der ersten iPad Generation sehr ähnlich war, jedoch längst nicht so leistungsfähig.
• Im Nachhinein wurde klar, daß die Software sogar Design- und Qualitätsprobleme hatte.

Der Strategische Aspekt

Im Artikel stehen einige Hinweise darauf, wie man eben keine Software entwickelt. Die aus meiner Sicht wichtigsten Fehler sind:

• Man dachte, das zeitliche Dilemma, in dem man gesteckt hat, über die Anzahl der Entwicklerköpfe zu lösen, die man diesem Projekt zuwies.
• Man hat sich kaum Gedanken darüber gemacht, wie das Produkt begeistern soll, sondern man hat das Thema genau falsch herum angefasst, indem man den Liefertermin vor Durchlaufen der Requirementsphase festgesetzt hat.

HP ist demnach in eine Falle gelaufen, die letztendlich zeigt, wie wichtig es ist, wenn das Management einer IT Firma entwicklungserfahren ist.

Aus meiner Erfahrung halte ich bereits die Grundannahmen für irreal, die zu diesem Desaster geführt haben, und nicht nur das Agieren der Beteiligten.

Fehlannahme: Mangelnde Entwicklerkapazität ist ein Mengenproblem

Ein solches System, wie einen iPad inclusive Betriebssystem in neun Monaten entwickeln zu wollen, nur durch Kapazitätserhöhung, ist aus meiner Sicht irreal (um nicht zu sagen, es ist eine grundfalsche Annahme).

• Einmal sollte man den Know How Bedarf der Softwareentwicklung nicht unterschätzen, und der Aufbau von Know How braucht Zeit, und Freiraum. Um vernünftige Arbeit abzuliefern, brauchen neue Entwickler selbst mit viel Unterstützung durch erfahrene Kollegen diese 9 Monate vermutlich erst einmal, um das Design zu entwerfen, die Prozesse/Arbeitsweisen aufeinander abzustimmen, und um Prototypen zu erstellen. In dieser Zeit ein getestetes Produkt der Güte eines iPad zu entwickeln, halte ich für “ambitioniert”.
• Ab einer gewissen Projektgröße fangen die Entwickler eher an sich gegenseitig zu stören. Es bringt also nichts, die Projekte endlos zu vergrößern – das mag in einer Fertigung gehen. In einem IT Projekt kommt nicht umhin, daß man den Lieferumfang überdenkt, oder, daß man den Projekten mehr Vorbereitungszeit gibt, wenn es ansonsten zu ambitioniert wird.

Wesentlich sinnvoller ist es, wenn man die Entwicklermannschaft permanent schult, und wenn man sich als Manager im übrigen darauf beschränkt, die Mitarbeiter eng an das Unternehmen zu binden (geringe Fluktuation). Wer nun einwendet “Time to Market”, und “Personalkosten” würden die Bilanz negativ beeinflussen, und man kann es sich daher nicht leisten, möge sich nochmal die Gesamtabschreibung ansehen, die HP machen mußte. Dafür kann man viel schulen…..

Fehlannahme: Es geht ohne Produktmanagement

Im Spiegel steht recht deutlich, daß das gleichteure HP iPad wesentlich weniger konnte, als das Original, und, daß deshalb niemand die Geräte kaufen wollte.

Das zeigt, daß das Produkt zu sehr aus einer inside-out Perspektive entwickelt wurde. Vermutlich hat man sich ungefähr angesehen, was Apple anbietet, und hat sich letztendlich so die Anforderungen abgeleitet. Statt sich intensiv mit den Nutzern und deren Vorstellungen zu befassen, hat man zudem auf ein Nachahmerprodukt gesetzt.

Das kann nicht funktionieren. Um ein Produkt, wie den iPad anzugreifen, nachdem man diese Gerätekategorie bereits “verschlafen” hatte, kann man im Prinzip nur zwei Wege gehen

• Niedriger Preis (wie Amazon, und andere Hersteller dies inzwischen machen)
• Relevante Schwachstellen so ausnutzen, daß der Angreifer nicht als Bedrohung wahrgenommen wird.

So ist zum Beispiel eine Schwachstelle des iPad für viele Nutzer sicher die fehlende Nutzbarkeit als Zeichengerät, bzw die Nutzbarkeit als Notizblock mit Stiftbedienung. Jobs hat explizit gesagt, daß “niemand Stifte will”, d.h man kann daher davon ausgehen, daß die reine Fingerbedienung “Feature, not a Bug” ist, und damit gewollt.

Inzwischen bildet sich ein Zubehörmarkt. Trotzdem ist aufgrund der Bauart des iPad die Stiftbedienung nur eingeschränkt möglich (z.B. kann man kaum filigran zeichnen). Ein disruptives Gerät könnte erst einmal ganz bescheiden anfangen, indem es sich als Notizblock positioniert, um dann in einem zweiteren Schritt in andere Anwendungen hineinzuwandern. Dabei könnte man ausnutzen, daß Apple die Stiftbedienung ja explizit nicht will.

Erst wenn dieses Gerät angenommen würde, könnte man beginnen mehr anzustreben.

Weiterführende Informationen

Wenn Ihnen der Artikel gefallen hat, warum nicht meinen Blog abonnieren →Mailingliste, oder →mir auf Twitter folgen?

Weiterführende Informationen im Internet

Im Internet finden Sie weiterführende Artikel:

• →Wer hat’s verbockt? HP! (Spiegel)
• →H.P.’s TouchPad, Some Say, Was Built on Flawed Software - NYTimes.com

Weiterführende Informationen auf www.Produkt-Manager.net

In meinen älteren Artikeln finden Sie weiterführende Informationen zum heutigen Thema:

• →Warum manche Unternehmen neue Technologien Verschlafen
• →Innovation – The Innovator’s Dilemma
• →Disruptive Innovation: Wieso übersehen Marktführer Trends
• →Disruptive Innovation – Eine praktische Anwendung

Ein Artikel im heutigen Manager Magazin (online) handelt von der Kreativität und stellt die Stufen des kreativen Denkens vor.

Demnach besteht das menschliche Hirn aus zwei Hirnhälften, die unterschiedliche Rollen einnehmen, und die innerhalb des kreativen Prozesses unterschiedliche Aufgaben erledigen (linke Hirnhälfte „analytisches Denken“, rechte Hirnhälfte „laterales Denken“).

Heute will ich auf zwei Faktoren eingehen, die unmittelbar mit der Kreativität zusammenhängen, aber oft vernachlässigt werden. Dabei handelt es sich einmal um die Rolle der Aus-, Fort- und Weiterbildung, und dann handelt es sich um die Rolle der eigenen Ressourcen.

Kreativität, und wie sie funktioniert

Wie in dem erwähnten Artikel →Selbstmanagement - Wie Kreativität funktioniert zu lesen ist, ergibt sich Kreativität aus dem geordneten Zusammenspiel von rechter und linker Gehirnhälfte. Diese beiden Gehirnhälften spielen auf eine definierte Art zusammen, wenn der jeweilige Besitzer kreativ tätig ist.

Der Artikel beschreibt die folgenden Phasen in der die kreative Arbeit und Problemlösung abläuft:

• Durchdringung, d.h. das Verstehen von Problem und Stand des Wissens
• Reifung, d.h. (unterbewußtes) Befassen mit der Aufgabenstellung
• Erleuchtung, die dann meistens im Zustand der Ruhe stattfindet, wie die berühmte Idee unter der Dusche, oder beim Spazieren
• Überprüfung, d.h. Einordnen der Idee

Zunächst ist es wichtig, die Aufgabenstellung (analytisch) zu durchdringen, um genau zu verstehen, um was es genau geht. Hierbei hilft laut der Forschung, wenn man den Stand der Technik kennt. In der zweiten Phase der kreativen Problemlösung befasst sich das Gehirn unterbewusst mit der Lösung des Problems. Die eigentliche kreative Leistung entsteht normalerweise in einem Zustand der Ruhe. In Ruhe fällt einem die Lösung auf eine Fragestellung häufig schlagartig ein. In der abschliessenden Phase geht es um die Bewertung und Einordnung der Idee.

Warum ist nun regelmäßiges Training und das auf-dem-Stand-der-Technik-bleiben wichtig? Die Antwort lautet, weil aktuelles Wissen eine notwendige Voraussetzung für die erste Phase der Problemlösung ist:

„Wenn ein Mensch erst einmal das Problem oder die kreative Herausforderung definiert hat, ist die erste Stufe der Kreativität eine Tätigkeit der linken Gehirnhälfte. Sie setzt paradoxerweise voraus, zunächst das aufzunehmen, was bereits bekannt ist. Jeder kreative Durchbruch basiert auf dem, was zuvor existierte.

Dies bedeutet, daß es sowohl für das Produktmanagement, als auch für den Rest der Organisation sehr wichtig ist, auf der Höhe der Zeit zu bleiben, und konstant zu lernen. Dies zeigt: Trainings, an denen ja gerade in einer Rezession gerne gespart wird, haben damit eine hohe Bedeutung für die Zukunftsfähigkeit der Firma, und stellen nicht nur ein notwendiges Übel dar.

Dies zeigt auch: Das Produktmanagement leistet einen wichtigen Beitrag, weil sich die Mitarbeiter auch damit befassen, festzustellen “was bereits bekannt ist” (z.B. welche Trends rund um das eigene Produkt es aktuell gibt).

Rolle der Work-Life Balance

Die Aussagen in dem oben erwähnen Artikel zeigen übrigens auch eine wenig beachtetete Bedeutung eines zweiten Themenbereiches auf, das derzeit unter der Überschrift „Burnout“ überall in der Presse diskutiert wird, jedoch mit anderem Fokus.

Grob gesprochen arbeiten viele Menschen so lange und intensiv, und finden wegen der gestiegenen Anforderungen und der permanenten Erreichbarkeit immer weniger Freiraum, sich zu entspannen. Eine wachsende Zahl von Menschen wird hiervon ernsthaft krank. Der folgende Artikel, der heute ebenfalls im Manager Magazin veröffentlicht wurde zeigt diese Problematik auf, und bleibt dabei nur ein Beispiel aus einer Flut von Nachrichten aus diesem Bereich:→Burn-out-Kliniken – Mit der Ruhe kommt die Kraft.

Gegenwärtig läuft die Diskussion um das Thema Work-Life Balance in eben diese gesundheitlich motivierte Richtung. Dabei ist offensichtlich, daß das fehlende Haushalten mit den Kapazitäten neben den individuellen Schicksalen, und den höheren Krankheitskosten aber offensichtlich auch negative Auswirkungen auf die kreativen Prozesse einer Firma hat (siehe das Zitat weiter oben).

Genau diese Kreativität ist aber für eine Wissensgesellschaft wie die unsere eminent wichtig. Daher ist die Work-Life-Problematik aus mehrfacher Hinsicht ein Problem.

Dies zeigt; Für Firmen ist es nicht nur wichtig, daß die Mitarbeiter „auf dem Stand des Wissens“ bleiben, sondern eben auch, daß der Arbeitsdruck (z.B. im Produktmanagement) erträglich bleibt.

Für mich persönlich erklärt dies, warum in einem Produktbacklog Functions und Features oft die gleiche Bedeutung haben, wie eine hohe Qualität. Während Functions and Features festlegen, was ein Produkt kann, definiert die Qualität eben, inwiefern man dasProdukt stressfrei verwenden, oder herstellen kann.

Im Spiegel werden die größten Fehler besprochen, die Existenzgründer machen können. Mindestens zwei dieser Fehler haben mit dem Aufgabengebiet des klassischen Produktmanagements zu tun. Darum geht’s heute.

Klassische Fehler

In dem Artikel → Die sieben Todsünden von Existenzgründern (Spiegel) geht es um mehrere potentielle Fehler. Aus der Sicht meines Blogs sind die Themen “Fokus” und “Anforderungsmanagement” wichtig.

Sich als eierlegende Wollmilchsau präsentieren

Der erste Fehler hat mit der Fokussierung der eigenen Leistungen zu tun. Viele junge Unternehmen machen den Fehler, daß sie “zuviel” anbieten, wie der Spiegel sagt:

“Erstens: Sich als eierlegende Wollmilchsau präsentieren ”Ich erlebe immer wieder, dass Unternehmer anfangs zu viele Leistungen anbieten”, sagt Bianca Poppke, 38, die für das Stuttgarter “Kompetenzzentrum Kultur- und Kreativwirtschaft” Gründer berät. “Sie tun das in der Hoffnung, irgendwie an Aufträge zu kommen, aber der Schuss geht nach hinten los.”"

Technisch betrachtet, ergibt sich dieses Problem oft dann, wenn die Fokussierung nicht stimmt, und mit der liegt es normalerweise im Argen, wenn man seinen eigenen Markt nicht ausreichend studiert hat, und deshalb nicht genau weiß, worauf es ankommt/ was wichtig ist.

Gute Unternehmen und Produktmanager legen ihren Fokus darauf, genau zu verstehen, welche Produktmerkmale für Kunden wichtig sind, und warum die Kunden die eigenen Leistungen kaufen wollen.

Ein Beispiel, das viele Leute kennen, ist der iPod. Diese Gerät ist aus mehreren Gründen erfolgreich geworden, die allesamt mit Fokussierung zu tun haben. Beispiele sind:

• Nutzer wollen Geräte bei denen das Laden uns Speichern der Musik einfach funktioniert (vor dem iPod war die Verwaltung von Musikdateien aufwendig). Daher wurde zusammen mit dem iPod die Musikverwaltung iTunes entwickelt.
• Nutzer wollten Geräte mit dem gewissen WoW Faktor, die schön sind und einfach zu bedienen (die Geräte vorher waren relativ wenig gestyled). Einfachheit bedeutet aber auch Verzicht auf die überflüssigen Features

Man hätte das Produkt damals auch anders schneiden können, und viel komplizierter machen. Letztendlich war den Machern aber klar, was wichtig ist, und was nicht.

Als Existenzgründer sollte man viel Zeit darin investieren, zu verstehen, was Kunden wirklich benötigen, und weswegen. Hierbei sollte man den ersten (natürlichen) Tendenzen widerstehen, alles anbieten zu wollen. Vielmehr sollte man beim Produktentwurf wie ein Designer vorgehen: Ein Konzept entwickeln, und dann so viel wieder wegnehmen, daß das Konzept gerade noch gut bleibt.

Diese Fokussieren sollte man dann auch noch in die Kommunikation mit dem Markt übernehmen, aber das steht auf einem anderen Blatt – auch bekannt unter dem Schlagwort “Positioning”.

Kein offenes Ohr für den Markt haben

Laut Spiegel ist ein weiter Fehler einiger Gründer, daß man zuwenig Marktinformationen erhebt, d.h. nicht mit Kunden spricht.

“Drittens: Kein offenes Ohr für den Markt haben

Die eigene Begeisterung ist wichtig, aber sind auch die potentiellen Kunden begeistert? “Es ist gefährlich, wenn man mit einer Idee die Welt beglücken will, aber vorher nicht mit der Welt spricht”, sagt Professor Klaus Nathusius (67), der an mehreren Hochschulen als freier Dozent lehrt. An deutschen Unis werde zu wenig praktisch gearbeitet, findet er und schickt seine Studenten regelmäßig auf Feldforschung.

Hier würde ich sagen “jein”. Es ist auf der einen Seite zweifellos notwendig, Kundeninformationen zu erheben, um letztendlich genau zu verstehen, welche Bedarfe Kunden haben (siehe auch das Kapitel weiter oben).

Allerdings geht es meiner Erfahrung nach weniger um die Frage, ob man mit Kunden spricht. Viel interessanter ist die Frage, wie man zu qualitativ hochwertigen Anforderungen kommt, die es einem gestatten, ein Produkt zu entwickeln, das Kunden auch kaufen wollen.

Hierzu sollte man als Gründer zunächst einmal genauer verstehen, was eine Anforderung überhaupt ist, nämlich die Beschreibung eines Produktmerkmales in einer Art und Weise, die die Realisierung erlaubt.

Im Anforderungsprozess sind zwei Fragen wichtig, um zu guten Anforderungen zu kommen:

• Was soll das Produkt leisten, wie und warum?
• Ist die Anforderung wichtig, und richtig?

Als Gründer sollte man sich deshalb davor hüten, genau das zu entwickeln, was Kunden (lautstark) verlangen (außer man ist im Service tätig und lebt von kundenindividuellen Wünschen). Vielmehr sollte man Anforderungen genau abklopfen.  Dies bedeutet auch, daß man auch andere Quellen verwendet, als das reine Kundengespräch.

Der iPod ist übrigens ein Sonderfall, und fast ein schlechtes Beispiel für die normale und sinnvolle Vorgehensweise. Hierfür wurden fast keine Kunden befragt, sondern das Produkt wurde aus einer Inside-Out Sicht entwickelt.

Weiterführende Informationen

Wenn Ihnen der Artikel gefallen hat, warum nicht meinen Blog abonnieren →Mailingliste, oder →mir auf Twitter folgen?

Weiterführende Informationen im Internet

In den folgenden Artikeln im Internet finden Sie weiterführende Informationen zum heutigen Thema:

• → Die sieben Todsünden von Existenzgründern (Spiegel)

Weiterführende Informationen auf www.Produkt-Manager.net

In meinen älteren Artikeln finden Sie weiterführende Informationen zum heutigen Thema:

• →SSNiF (Stakeholder, Situation, Need, Feature) Analyse
• →Living Specification und Qualität der Software
• →Focussing is about saying No 

Die Volkswirtschaftslehre weiß es schon lange – nun spricht es sich auf in der Betriebswirtschaftslehre rum. Der Schlüssel zum Erfolg, und damit die Frage, ob Unternehmen und Wirtschaft wachsen, liegt in ihrer Innovationskraft begründet.

Heute geht es um diverse Studien und Presseberichte, die helfen, diesen Zusammenhang empirisch zu belegen.

Der Daniel Düsentriebeffekt

Im Handelsblatt wird eine neue Studie besprochen, die darauf abzielt, den Nutzen des Internet zu quantifizieren (siehe Weiterführende Informationen). Hierzu vergleicht der Autor der Studie die Effekte des Internet mit den Effekten, die die Erfindung des Buchdrucks hatte.

Er kommt zu eindeutigen Aussagen über die Rolle der Innovationen, wie die folgenden Zitate zeigen:

Eine neue Studie zeigt: Innovationen beflügeln den Wohlstand. Mit der Erfindung des Buchdrucks durch Johannes Gutenberg hat alles angefangen und auch heute fördern Erfindungen die Produktivität von Firmen…

Dabei herrscht in der Wachstumstheorie schon lange Konsens, dass technischer Fortschritt eine der zentralen Triebfedern für höheren Wohlstand ist…

Aus ökonomischer Perspektive betrachtet hatte die Erfindung des Buchdrucks ähnliche Folgen wie heute das Internet, argumentiert Dittmar: Es wurde billiger und einfacher, Wissen zu speichern und auszutauschen.

Die erwähnte Studie zeigt recht deutlich, daß diejenigen Regionen in Europa Wachstumsvorteile hatten, die in der Lage waren, den Buchdruck einzusetzen. Da die Diffusionsgeschwindigkeit des technische Wissens damals sehr gering war, konnte man nämlich Wachstumsunterschiede zwischen Regionen erkennen, die die neue Technologie eingesetzt haben, und solchen, die dies nicht taten. Dies belegt den wirtschaftlichen Nutzen dieser Technologie.

Diese Betrachtung ist nur ein Beispiel aus der volkswirtschaftlichen Wachstumstheorie, das den direkten Zusammenhang zwischen Innovation und Wachstum belegt. Der Zusammenhang gilt jedoch nicht nur auf volkswirtschaftlicher Ebene, sondern auch auf Unternehmensebene, wie die folgenden Artikel zeigen.

SAP Wachstumsschub basiert auf Innovationen

Es ist ein Beispiel unter vielen. Erst neulich hat die Softwarefirma SAP über ein hohes Wachstum, und von dem stärksten dritten Quartal in der Unternehmensgeschichte berichtet.

Ein Artikel in der britischen Computer Weekly (siehe Weiterführende Informationen) vermeldet, daß dieses überraschend große Wachstum der SAP auf die Innovationsstrategie zurückzuführen ist, die das Unternehmen verfolgt.

Im einzelnen werden Innovationen bei der Lieferfrequenz eines Kernproduktes (d.h u.a. Prozessinnovationen) erwähnt, sowie ein neues Produkt im Datenbankumfeld, das sehr gut angenommen wird (Produktinnovationen):

” SAP reported record third quarter software revenue and notched up the seventh consecutive quarter of double-digit growth in software and software-related services.But if ERP is no longer the big push for the German enterprise software house, what are its customers actually buying?

The answer lies in the business software’s company’s strategy laid out by co-chief executives Jim Hagemann Snabe and Bill McDermott since taking over the helm at SAP in early 2010 and their emphasis on non-disruptive innovation. – Computer Weekly

Auch dieses Ergebnis deutet darauf hin, daß innovative Produkte und Unternehmenserfolg eng zusammenhängen. Noch drastischer kommt dieser Zusammenhang in dem folgenden Beispiel zur Geltung.

Apple wäre fast Pleite gegangen wegen mangelnder Innovation

Apple ist ein interessantes Beispiel, da die Firma einmal fast bankrott war, und heute zu den wertvollsten Unternehmen der Welt gehört. Innovative Produkte haben dabei einen sehr großen Anteil am turn-around gehabt.

In einem Interview, das Steve Jobs 1996 geführt hat, ist er auf die Rolle eingegangen, die die Innovation bei der Gesundung und dem späteren Erfolg von Apple gespielt hat  (siehe Weiterführende Informationen).

Gefragt, was bei Apple damals in der schlechten Phase schief gegangen ist, hat er relativ klar geantwortet, daß die Firma damals den Fehler gemacht hat, zu wenig Innovationen herzubringen. Hierbei war interessanterweise nicht eine zu geringe Investition das Problem, sondern sie war die mangelnde Fähigkeit der Firma, wettbewerbsfähige Produkte zu entwickeln.

Rukeyser: …What went wrong at Apple?

Jobs: Oh gosh. You know I haven’t been there in a long time. My perception may not be complete. But from the way I see it, Apple was a company that was based on innovation. When I left Apple ten years ago, we were ten years ahead of anybody else. It took Microsoft ten years to copy Windows.

The problem was that Apple stood still. Even though it invested cumulatively billions in R&D, the output has not been there. People have caught up with it, and its differentiation has eroded, in particular with respect to Microsoft.

And so the way out for Apple — and I think Apple still has a future; there are some awfully good people there and there is tremendous brand loyalty to that company — I think the way out is not to slash and burn, it’s to innovate. That’s how Apple got to its glory, and that’s how Apple could return to it.

Fazit

Allen Beispielen und Studien ist eins gemein: Die Fähigkeit, innovative Produkte  zu entwickeln ist entscheidend für den Unternehmenserfolg. Dabei kommt es offensichtlich nicht so sehr auf die höhe der Investition in die Innovation an (z.B. Forschungsbudget), sondern es kommt vielmehr auf die Effektivität und Kreativität an.

Meiner Erfahrung nach sind mehrere Faktoren entscheidend, damit ein solches Klima entsteht. Dies sind unter anderem die Folgenden:

• Ist das Betriebsklima fehlertolerant, und ergebnisorientiert, und können daher Ideen frei geäußert werden?
• Haben die Mitarbeiter genügend Freiräume, um innovativ tätig zu sein, und die notwendige Loyalität, dies auch zu tun?
• Gibt es eine Kultur, die die Menschen zu Höchstleistungen anspornt (was auch eine gerechte Teilhabe an den Resultaten voraussetzt)?
• Ist die Firma in der Lage, sich auf wenige Innovationen zu konzentrieren, oder besteht etwa die Gefahr, daß man sich verzettelt?
• Spielen Kundenorientierung und Bescheidenheit eine große Rolle, und ist die Firma in der Lage, auf die Kunden zu hören?
• Kennt das Unternehmen die eigenen Stärken, Schwächen, Chancen und Risiken?

Der Nutzen liegt auf der Hand. Das Produktmanagement liefert einen wichtigen Beitrag bei der Umsetzung,

Weiterführende Informationen

Wenn Ihnen der Artikel gefallen hat, warum nicht meinen Blog abonnieren →Mailingliste, oder →mir auf Twitter folgen?

Weiterführende Informationen im Internet

In den folgenden Artikeln im Internet finden Sie weiterführende Informationen zum heutigen Thema:

• →Analysis: What Is the Secret Sauce in SAP’s Success? (Computer Weekly)
• →Der Daniel-Düsentrieb-Effekt (Handelsblatt)
• →What Steve Jobs said about Apple in the summer of ’96 (CNN Money)

Weiterführende Informationen auf www.Produkt-Manager.net

In meinen älteren Artikeln finden Sie weiterführende Informationen zum heutigen Thema:

• →Markets or Communities? The Best Ways to Manage Outside Innovation
• →Innovator Premium
• →Allheilmittel Innovation, auch wirksam zur Bekämpfung von Wirtschaftskrisen?

Eine wichtige Aufgabe des Produktowners ist es dafür zu sorgen, daß das Team eine angemessene Anzahl von Aufgaben erhält: Nicht zuviel, und nicht zuwenig.

Da der Aufwand eines Entwicklungsprojekts oft nicht einfach einzuschätzen ist, und einem vielfach die notwendigen (kompletten) Informationen fehlen, sind Verfahren notwendig, mit denen man den Backlog schnell abschätzen kann, obwohl die Genauigkeit fehlt.

Hierbei geht es auch darum, daß man sinnvoll mit typischen Fallstricken umgehen kann. Im Scrum-Entwicklungsmodus ist das Entwicklungsteam zusammen mit dem Produktowner für die Abschätzung verantwortlich.

Ein Fallstrick ist zum Beispiel, daß sich einzelne Mitarbeiter (ungewollt) durchsetzen, und so falsche Abschätzungen entstehen. Man benötigt daher Verfahren, bei denen sich die Teammitglieder nicht beeinflussen.

Ein anderer Fallstrick ist, daß die verschiedenen Teammitglieder eine unterschiedliche Auffassung von Messkriterien haben. Man benötigt daher ein Verfahren das zum Beispiel keine Absolutaufwände abfragt, sondern sich auf Relativangaben beschränkt (Menschen fällt es leichter, Größenverhältnisse abzuschätzen, als Absolutbeträge).

Der sogenannte “Planning Poker” hilft bei der Abschätzung einzelner Backlog Items. Ein Verfahren mit Namen “Magic Estimation” wird eher für größere Backlogs verwendet. Beide Verfahren adressieren die üblichen Fallstricke.

Planning Poker

In einem Planningpoker präsentiert der Produktowner jeweils ein Backlog Item/ User Story, und erklärt die Detailanforderungen. Sobald die Fragen beantwortet sind, schätzen die Teammitglieder den Aufwand ab, den die Umsetzung erfordern wird.

Hierfür schätzt jedes Teammitglied den Aufwand für sich selbst ein, und wählt eine Spielkarte, die den Aufwand repräsentiert. Normalerweise wird hierfür ein spezielles Kartenspiel verwendet, das Werte, wie 1/2, 0, 1, … 100, unendlich kennt. Man kann allerdings auch ein x-beliebiges anderes Kartenspiel verwenden, oder andere normbare Werte.

Sobald jedes Teammitglied die Karte gewählt hat, wird der Wert gezeigt. Normalerweise kommt es zu Abweichungen, die dann diskutiert werden. Sobald geklärt ist, wer, warum und wieviel schätzt, erfolgt eine weitere Abschätzrunde. Im Streitfall entscheidet der Scrum Master, z.B. den größten Wert zu nehmen.

Magic Estimation

Das Verfahren der Magic Estimation wird benutzt, um größere Backlogs einzuschätzen. Hierbei wird z.B. eine Wand gerastert (Flipboard,..), und jedem Raster ein Wert gegeben, der die unterschiedlichen Klassen von Story Points repräsentiert. Weiterhin wird das Verfahren geklärt. Wichtig ist, daß es während der Schätzung keine verbale/nonverbale Kommunikation zwischen den Teammitgliedern gibt, damit es zu keinen Absprachen kommt.

Der Produktowner präsentiert jedes Backlog Item, und verteilt die Items dann gleichmäßig an alle Teammitglieder. Jeder Teilnehmer schätzt seine Items, und ordnet sie dem entsprechenden Raster zu.

Anschliessend kann jedes Teammitglied die Items der anderen umsortieren, von denen er der Meinung ist, daß sie im flachen Raster liegen.

Stories, die vor- und zurückgeschoben werden, werden aus der Schätzung entfernt, und im Anschluss an die Schätzrunde gemeinsam geklärt.

Weiterführende Informationen

Wenn Ihnen der Artikel gefallen hat, warum nicht meinen Blog abonnieren →Mailingliste, oder →mir auf Twitter folgen?

In meinen älteren Artikeln finden Sie weiterführende Informationen zum heutigen Thema:

• →Was tun wenn man mehr Anforderungen hat, als Zeit….?
• →Anforderungen müssen konkret formuliert sein
• →SSNiF (Stakeholder, Situation, Need, Feature) Analyse

Bereits an anderer Stelle habe ich über die Rolle von “guten” Anforderungen im Softwareentwicklungsprozess geschrieben, und bin zu dem Ergebnis gekommen, daß es sich durchaus lohnt, Anforderungen so sauber und detailliert zu beschreiben, wir irgend möglich.

Auch ist es wichtig, professionelle Methoden zu verwenden, um zu prüfen, ob das entwickelte System die Anforderungen auch so abdeckt, wie von ihr verlangt.

Heute habe ich das Konzept der lebenden Spezifikation kennengelernt, das eine wichtige Rolle in der Schnittstelle zwischen Produkt-Owner, Entwicklung und Qualitätsicherung spielt. Dies will ich heute kurz skizzieren.

Warum wird eine lebende Spezifikation benötigt?

Die Mitarbeiter im Scrum Team entwickeln regelmäßig Software, die sie auf unterschiedlichen Ebenen testen. Die einzelnen Funktionen sind in den jeweiligen Backlog Items beschrieben, die der Produkt Owner zur Verfügung stellt. Im Sprintreview stellt man fest, inwieweit die Backlog Items fertig entwickelt wurden.

Die Anforderung, die der Kunde an die fertige Software stellt, taucht daher sehr häufig in verschiedenem Zusammenhang auf. So zum Beispiel taucht die Anforderung auf der Backlog Item Ebene auf, wenn der Produkt Owner dem Team den Kundenbedarf erklärt, oder sie taucht eben auch in den einzelnen Tests auf, die Entwickler durchführen, um die Entwicklungen durchzutesten. Schliesslich taucht sie aber auch in dem Coding selbst auf, das die Anforderung implementiert.

Je genauer diese Anforderungen beschrieben sind, und je genauer und zweifelsfreier die erwarteten Ergebnisse behandelt werden, desto besser. Früher haben wir papierbasierte Spezifikationen geschrieben. Diese haben zwei Nachteile:

• Es ist nahezu unmöglich, diese Dokumente up-to-date zu halten, wenn sich Änderungen einstellen, oder fehlende Angaben nachgeklärt werden.
• Man kann sie nur schlecht für Tests verwenden, da sie oft erst einmal aufwendig in eine maschinenlesbare Form gebracht werden müssen.

Hier die Definition des Begriffes “Lebende Spezifikation” (siehe →What is living specification)

“Set of flexible requirements that concentrate on form, fit, and function, and are designed to readily accommodate incorporation of new products, processes, and more advanced requirements. Through a sensitive feedbacksystem, living specifications promote continuous quality improvements without a major change.”

Eine lebende Spezifikation soll einfach zu erweitern sein, und man soll sie dynamisch ändern können. Es soll ferner möglich sein, die spezifizierten Anforderungen direkt in der Entwicklung zu verwenden, um zu prüfen, ob die Software arbeitet, wie erwartet.

Hierfür bietet es sich an, die wesentlichen Teile der Anforderungen in einem System abzubilden (z.B. einer Datenbank), das jedem Teammitglied zur Verfügung steht. Darüberhinaus sorgt man dafür, daß jeder, der von Änderungen erfährt, die Angaben in der Datenbank erweitert.

Testen

Auf einer eher unteren Ebene eines Entwicklungsprojektes verwendet man Unit Tests, mit denen sichergestellt wird, daß die Software, und jeder einzelne Baustein richtig entwickelt wurde. Hier benötigt man also Daten mit denen man beurteilen kann, ob einzelne Module richtig arbeiten (z.B. enthält die ausgegebene Tabelle richtige Werte? Stimmen die Ergebnisse insbesondere an den jeweiligen Grenzen? etc)

Auf einer höheren Ebene in der Softwarehierarchie laufen zum Beispiel die Acceptancetests, mit denen man feststellt, ob die entwickelte Software auch die Geschäftsanforderungen abdeckt, die von ihr erwartet werden. Hierbei konzentriert man sich auf die Integrationsaspekte, und damit die Objekte, die die einzelnen Tabellen, Fehler, etc zusammenfassen (z.B. Wird der Kundenauftrag richtig bearbeitet, der aus unterschiedlichen Rabattklassen, Einzelitems, Mengen, etc besteht?)

Allen diesen Tests gemein ist, daß sie Testdaten verwenden, die die Realität möglichst gut abdecken. Hier beginnt jedoch das eigentliche Problem:

• In der Entwicklung finden Tests statt, die der Endabnehmer oft nicht richtig versteht (da zum Beispiel Programmiererfahrung notwendig wäre).
• Der Kunde verwendet oft Angaben, die sich nicht einfach in Testfälle übersetzen lassen (z.B. da erwartete Ergebnisse oft “implizit” sind)

Dazwischen findet eine ausgiebige Kommunikation statt. Eine lebende Spezifikation besitzt daher neben der gemeinsamen Datenbasis zwei wichtige Schnittstellen:

• Eine Benutzerschnittstelle, die es Produktowner und Kunde erlauben, die einzelnen Angaben während des Anforderungsgesprächs in Tabellenform zu erfassen (z.B. zu erfassen, daß es 3 Rabattklassen gibt, die von dem Umsatz abhängen).
• EIne Schnittstelle, die es einem Test erlaubt, diese Daten automatisch zu lesen und mit dem berechneten Ergebnis zu vergleichen, um sicherzustellen, daß das System z.B. die Rabattklassen richtig zurückgibt.

Weiterführende Informationen

Wenn Ihnen der Artikel gefallen hat, warum nicht meinen Blog abonnieren →Mailingliste, oder →mir auf Twitter folgen?

Weiterführende Informationen im Internet

Im Internet finden Sie weiterführende Artikel:

• →What is living specification

Weiterführende Informationen auf www.Produkt-Manager.net

In meinen älteren Artikeln finden Sie weiterführende Informationen zum heutigen Thema:

• →Was tun wenn man mehr Anforderungen hat, als Zeit….?
• →Feature versus Qualität
• →SSNiF (Stakeholder, Situation, Need, Feature) Analyse

In den letzten Tagen ist viel über Steve Jobs geschrieben worden, und insbesondere auch die Frage, wo er seine Inspiration hergenommen hat. Hierzu hat die New York Times einen lesenswerten Artikel veröffentlicht, in dem klargestellt wird, das Edwin Land, der Erfinder der Polaroid Kameras eben diese Inspirationsquelle war.

Die Diskussion über den Nutzen und die Grenzen, die die Einbindung von Kunden in den Entwicklungsprozess hat, ist auch immer wieder ein Thema. Daher sind mir in dem Artikel mehrere Statements aufgefallen, die ich heute ebenfalls mit Ihnen teilen will.

The Man Who inspired Jobs

Der Artikel →The Man Who Inspired Jobs fasst sehr schön zusammen, daß Jobs und Land sich sehr ähnlich waren, und auch ähnlich gedacht haben. Letztendlich geht  der Artikel auf ein Buch zurück, das hierzu vor einigen Jahren erscheinen ist (siehe Weiterführende Informationen). Dies geht in dieselbe Richtung.

An einer Stelle wird beschrieben, daß beide Männer “Ihre” zentralen Produkte relativ klar vor Augen hatten, noch bevor sie diese entwickelt haben. Entgegen der landläufigen Vorgehensweise haben sie also nicht Kunden gefragt, was sie entwickeln sollen, sondern sie haben Ihre bahnbrechenden Produkte aus einer Inside-Out Sicht entwickelt:

Dr. Land was saying: ‘I could see what the Polaroid camera should be. It was just as real to me as if it was sitting in front of me, before I had ever built one.’ And Steve said: ‘Yeah, that’s exactly the way I saw the Macintosh.’ He said, If I asked someone who had only used a personal calculator what a Macintosh should be like, they couldn’t have told me. There was no way to do consumer research on it, so I had to go and create it and then show it to people and say, ‘Now what do you think?’”

Viele Produktmanager sind der Meinung, daß jede Produktinnovation auf Kundenfeedback basiert. Ich kann aus meiner Erfahrung bestätigen, daß Jobs und Land recht haben – manche Innovationen sind so neu, daß Kunden schlicht nicht wissen können, daß sie ein solches Produkt benötigen (Wenn Sie an das Problem der disruptiven Innovation denken, kann einen Kundenfeedback manchmal sogar in die falsche Richtung leiten).

Beide sagen genau dies unabhängig voneinander in ähnlichen Worten:

The worldview he was describing perfectly echoed Land’s: “Market research is what you do when your product isn’t any good.” And his sense of innovation: “Every significant invention,” Land once said, “must be startling, unexpected, and must come into a world that is not prepared for it. If the world were prepared for it, it would not be much of an invention.” Thirty years later, when a reporter asked Jobs how much market research Apple had done before introducing the iPad, he responded, “None. It isn’t the consumers’ job to know what they want.”

What it takes to be an Innovator

Innovationen, wie die Polaroid Kamera oder das iPod sind sehr häufig genau die interessanten, “bahnbrechenden” Innovationen, nach denen wir täglich suchen – sie sind oft ja auch mit einem großen ökonomischen Potential versehen. Daher sollten wir uns als Produktmanager und Product-Owner in die Lage versetzen, solche Innovationen auch entwickeln zu können.

Die erste Frage, die sich hierbei stellt, ist die Frage nach den Qualifikationen. Beide Männer haben hierzu ebenfalls etwas gesagt, nämlich, daß ein bestimmter Erfindergeist dazugehört, sowie der Fokus auf das Produkt (und nicht das Accounting).

In dem Beitrag →Polaroid and Apple: Innovation Through Mental Invention findet man noch einen weiteren Hinweis, was notwendig ist, nämlich den Hinweis, Dinge konzentriert zu tun:

Land once told a reporter, “If anything is worth doing, it’s worth doing to excess … My whole life has been spent trying to teach people that intense concentration for hour after hour can bring out in people resources they didn’t know they had.” Similarly, Jobs had once remarked, “We have a short period of time on this earth … My feeling is that I’ve got to accomplish a lot of things while I’m young.”

Ich denke mal, daß es häufiger vorkommt, daß ein Scrum Team nicht für ein komplettes Produkt verantwortlich ist, sondern Teilbereiche der gesamten Funktionalität verantwortet. Auch ist es sicherlich nicht unnormal, daß ein Team mehr als einen Stakeholder unterstützen muss oder komplexe Technologien verwendet, oder Funktionalitäten in unterschiedlichen Releases unterstützt.

In einem solchen Umfeld kommt es leicht vor, daß sich ein Team unterschiedlichen Anforderungen gegenübersieht, die dann vielleicht  auch noch zu Spezialisierungen bei den Teammitgliedern führen.

Unter solchen Rahmenbedingungen stellt sich die Frage, was der Produktowner tun kann, damit ein Team nicht in mehrere Teilgruppen zerfällt die dann auch noch unterschiedlich spezialisiert sind.

Mehr Anforderungen als Zeit

In einem früheren Beitrag habe ich über das Problem geschrieben, daß dann auftritt, wenn sich Ihr Team zu vielen Anforderungen gegenübersieht. Ich habe dort praxisorientierte Lösungen vorgeschlagen, um solche Situationen zu managen (siehe Weiterführende Informationen ganz unten). Die Situation, die heute im Fokus steht, ist vergleichbar damit. Nur ist es hier nicht unbedingt “das Zuviel” an Anforderungen, sondern es ist die fehlende Konsolidierung, und eigentliche Priorisierung.

Wie erkennt man das Problem?

Doch zunächst einmal zur Frage, wie man das eigentliche Problem erkennt, und wie der Normalzustand aussehen sollte.

Im Normalzustand sollte meiner Meinung nach das Team über einen angemessen großen Produktbacklog verfügen, der sich zudem nicht allzu dynamisch entwickelt. Dies erlaubt dem Team auf der einen Seite, den Backlog ohne Aufregung wegzuarbeiten. Auf der anderen Seite hat jedermann einen Überblick über die Anforderungen, Qualifikationsanforderungen, oder Entwicklungsbedarfe. Der Umstand, daß der Backlog sich nicht ändert, zeigt, daß die Anforderungen geklärt sind, die diesem Backlog zugrundeliegen.

Nach meiner Erfahrung sollte man dann als Produktowner hellhörig werden, wenn man folgende Merkmale an seinem Backlog entdeckt:

• Die Anforderungen ändern sich häufig, und es gibt viele Vordrängler: Wie oben gesagt; normalerweise würde man erwarten, daß ein Produktbacklog relativ stabil ist, und es daher möglich ist, auszusagen, welche Themen in den nächsten Monaten auf der Agenda stehen. Ist dem nicht so, und stehen mit jedem Sprint ganz neue Themen oben auf der Liste, ist zu vermuten, daß sich die Stakeholder in einem Panikmodus befinden, und versuchen, Ihren Anforderungen über die Priorität Gehör zu verschaffen. Dies kann daran liegen, daß die Stakeholder selbst noch nicht genau wissen, was sie benötigen, oder es kann daran liegen, daß das Team zu restriktiv vorgeht.
• Die Anforderungen sind relativ klein: In diesem Fall, wollen die Stakeholder mal hier, mal da Erweiterungen haben, dies aber so, daß kein roter Faden erkennbar ist. Hier ist zu vermuten, daß die Anforderungen nicht geklärt sind, und das Gesamtbild fehlt.
• Feedback von Team oder Stakeholdern zeigt, daß dem Team der Gesamtüberblick fehlt, etc

Was tun?

Meine Anregung in einem solchen negativen Fall ist es, zunächst einmal dafür zu sorgen, daß der Produktbacklog “strategisch” geklärt wird.

• Im einfachsten Rollinmodell nennen die verschiedenen Stakeholder ihre Anforderungen, die dann auch priorisiert abgearbeitet werden. Auf Teamebene gibt es soviele Backlogs, wie Stakeholder, und damit eine große Gelegenheit zur Verzettelung. Hier hilft es bereits, wenn man die Anforderungen konsolidiert, gruppiert, und zusammen mit den Stakeholdern die übergeordneten Prioritäten klärt.
• Oft wollen Stakeholder ihre Themen durchsetzen, weil sie die Bedeutung des Wortes “Anforderung” nicht richtig verstehen. Wenn man es zusammen mit den Stakeholdern schafft eine Anforderung als Idee zu verstehen, ist die Lösung nicht weit. Oft ist es nämlich sinnvoll, die Anforderungen so zu generalisieren, daß man erkennen kann, daß man als Stakeholder im Prinzip dasselbe Problem hat, wie ein Kollege, und daß allen damit geholfen wäre, wenn die Lösung auch genereller wäre.
• Ganz häufig werden Anforderungen deshalb eingelastet, weil sich – aus falsch verstandener Kundenorientierung –  niemand getraut hat, die Barriere hoch zu hängen. Man sollte daher lieber jede Anforderung mehrfach hinterfragen, und auch mehrfach den Nutzen anzweifeln. Nur so stellt man sicher, daß die Anforderung auch wirklich durchdacht ist, und in ein Gesamtkonzept passt.
• Viele Anforderungen laufen deshalb chaotisch ein, weil die Organisation des Stakeholders selbst nicht funktioniert. In einem solchen Fall steht das abnehmende Team unter starkem Anforderungsdruck, und versucht, Anforderungen weiterzureichen. Hier kann es helfen, wenn man dem Stakeholder dabei hilft, seine Kundenbearbeitung besser zu organisieren.

Dies waren nur einige Ideen, um mit dem typischen Problem der fehlenden Fokussierung umzugehen. Bei näherem Hinsehen, findet sich sicher noch weiteres Optimierungspotential – genug Grund, um hierauf einmal mit einer Fortsetzung zurückzukommen.

Weiterführende Informationen

Wenn Ihnen der Artikel gefallen hat, warum nicht meinen Blog abonnieren →Mailingliste, oder →mir auf Twitter folgen?

In meinen älteren Artikeln finden Sie weiterführende Informationen zum heutigen Thema:

• →Was tun wenn man mehr Anforderungen hat, als Zeit….?
• →Feature versus Qualität
• →SSNiF (Stakeholder, Situation, Need, Feature) Analyse

Wie Roman Pichler von der Scrum Alliance in seinem Artikel →The Product Vision sagt, benötigt jedes Scrum Team eine Produktvision, die dem Team das Ziel vorgibt und die Richtung, um dorthin zu gelangen. Die Produktvision hilft zudem, das Scrum Team inhaltlich zu lenken.

“Every Scrum project needs a product vision that acts as the project’s true north, sets the direction and guides the Scrum team.”

Die Produktversion beschäftigt viele Produktowner. Daher geht es heute um die Frage, wie Sie zu Ihrer Produktvision kommen.

Produktvision

Spätestens seit Pichler’s Feststellung gehört zu der Rollenbeschreibung eines jeden Produktowners die Aufgabenstellung, dem Team einen Überblick über Produkt und Produktvision zu geben. Wie wir oben gesehen haben, dient diese Information dazu, dem Team die Richtung vorzugeben, und zwar so, daß es sich selbst daran langhangeln und ausrichten kann.

Wie ich finde, ist es am einfachsten, wenn man seine eigene Produktvision entwickelt, indem man sich an einigen grundlegenden Fragen orientiert, die eine jede Produktvision liefern sollte. Hierfür dient mit ein kleines Beispiel.

Beispiel: Wenn einer eine Reise tut

Zielgruppe

Zunächst einmal sollte man klären, an wen sich das Produkt richtet, d.h welche Kunden die Zielgruppe darstellen. Beim Thema Reisen könnten zum Beispiel ältere Personen, oder Jugendliche zwei unterschiedliche Zielgruppen darstellen.

Wenn man es genau machen will, sollte man unterscheiden zwischen dem Käufer des Produktes (Eltern), und den eigentlichen Kunden (Jugendliche).

Wertbeitrag

Die wohl wichtigste Frage richtet sich an den Wertbeitrag des Produktes, d.h. es geht konkret um die Frage: “Welchen Wert soll das Produkt dem Kunden liefern?”. Bei einer Reise wäre zum Beispiel der Wertbeitrag eines Produktes, daß sich der Gast erholt, und daß er möglichst wenig Arbeit damit hat, sich im Urlaubsort aufzuhalten.

Bedürfnisse

Ebenfalls wichtig sind die Bedürfnisse, die das Produkt befriedigen soll. Im Sinne einer Urlaubsreise sind unterschiedliche Bedürfnisse denkbar. Der eine Gast sucht Action und Abendteuer, der nächste will feiern. Wieder ein anderer Urlauber möchte baden und sich entspannen. Je nach Bedürfniss wird das optimale Urlaubsprogramm anders aussehen.

Produktattribute

Die nächste Frage dreht sich um das Produkt selbst, und könnte in etwa lauten “Welche Attribute des Produktes sind entscheidend, um die Bedürfnisse zu befriedigen”. Bei den Action-Urlaubern ist zum Beispiel die Höhe der Kletterfelsen interessant. Beim anderen Urlauber die Sauberkeit von Urlaub und Strand.

Wettbewerbsposition

Der Wettbewerbsbezug stellt sicher, daß sich das eigene Produkt in den relevanten Merkmalsausprägungen von den Wettbewerbsprodukten unterscheidet. Bei einer Reise ist zum Beispiel wichtig, daß sie preiswerter ist, als die entsprechende Reise beim Wettbewerb.

Eine alternative Herangehensweise ist, daß man sich fragt, wie sich das eigene Produkt von den anderen Produkten unterscheidet, und woraus der “unique selling point” besteht, d.h. das Alleinstellungsmerkmal.

Vision

Aus den einzelnen Elementen ergibt sich eine Vision, und damit letztendlich der Grund, warum Kunden das Produkt kaufen sollten, d.h die Nutzungserfahrung, die sich der Kunde von der Reise versprechen kann.

Ich persönlich habe gute Erfahrungen damit gemacht, wenn man die Vision auch in Form einer Persona darstellen kann, unter der sich die Scrum Mitglieder etwas vorstellen können. Die Personas erleichtern die Identifikation. Beispiel sind:

• Willi, der reisende Rentner, der die Ruhe sucht
• Alfons, der begeisterte Entdecker, der die Vielfalt zu guten Preisen benötigt
• Ivonne, die Action und Party unter Freunden, und Sonne am Strand benötigt

Weiterführende Informationen

Wenn Ihnen der Artikel gefallen hat, warum nicht meinen Blog abonnieren →Mailingliste, oder →mir auf Twitter folgen?

Weiterführende Informationen im Internet

In einem Blog mit dem Titel →Productvision finden Sie weitere Informationen zur Entwicklung der Produktvision. Unter anderem können Sie dort auf eine →Hall-of-Fame zugreifen. auch http://productvision.org/blog/hall-of-fame/

Die Firma ASPE SDLC befaßt sich mit Schulungen zu verschiedenen Themen im Bereich “Softwareentwicklung”. Dort finden Sie in Artikel →The Power of the Vision Statement in Scrum weitere Hintergrundinformationen. Dort wird auch eine Produktvision zu einem Produkt gezeigt (hier Apple iPad), aus der Sie ersehen können, wie Produktvisionen aufgebaut werden, und was sie aussagen.

“For the technology enthusiast who wants to carry a single light-weight device to meet all of their computing needs, the iPad is a portable tablet PC that does it all. Unlike traditional laptops the iPad is ultraportable and always on. Our product will revolutionize the computing industry.

Weiterführende Informationen auf www.Produkt-Manager.net

In meinen älteren Artikeln finden Sie weiterführende Informationen zum heutigen Thema:

• →Agile Product Management
• →SCRUM Product Owner: Role and Task
• →Role of the Product Vision when Development goes Agile