Heute stehen zwei Artikel im Fokus, die zeigen, daß das Innovationsmodell zur Firma und zu den Produkten passen muss.

Der eine Artikel bespricht die Gegensätze in den Innovationsstrategien von zwei erfolgreichen Unternehmen (Apple und Google), deren Vorgehensweise sich diametral voneinander unterscheidet.

Der andere Artikel behandelt die Rolle, die die offene Innovation heute und in Zukunft spielt, und plädiert dafür, daß sich Firmen öffnen.

Die Gegenpole der betrieblichen Innovation

Google und Apple stellen extreme Gegensätze in Bezug auf ihre Innovationsphilosophie dar, wie ein Artikel in der New York Times zeigt (siehe Weiterführende Informationen am Ende des Artikels).

Bottom-Up

Google’s Innovationsmodell basiert auf dem Prinzip der schnellen Iteration, bei dem das schnelles Ausprobieren von Ideen und die schnelle Rückmeldung der Kundenpräferenzen im Vordergrund stehen. In diesem Modell werden Kunden unmittelbar miteinbezogen, und werden so am Ende zu Partnern im Produktentwicklungsprozess (Bottom-up Ansatz).

Top-Down

Im Gegensatz dazu ist das Modell von Apple weitaus wissenschaftlicher und elitärer aufgebaut.

Hier entwirft eine kleine Gruppe von Mitarbeitern die neuen Produkte (Top-down Ansatz), und folgt hierbei der Grundidee, daß es nicht die Aufgabe der Kunden sei, zu wissen, was sie wollen.

Innovationsstrategien

Google’s Modell ist ein Beispiel für eine Innovationsstrategie, die getrieben wird von Technologien (Datenbasierte Entscheidungsfindung, Online Experimente und vernetzte Kommunikation).

Diese Strategie kommt in der Softwareindustrie oft vor, und wird durch den Entwicklungsansatz der agilen Softwareentwicklung gefördert:

The benefits, experts say, are most apparent in markets like Internet software, online commerce and mobile applications for smartphones and tablets. “The cost of creation, distribution and failure is low, so it takes relatively little time, money and effort to float trial balloons,” says Randy Komisar,…..

Das Apple-Modell trägt demgegenüber dem Umstand Rechnung, daß Kommunikation und Experimente zwar hilfreich sind, fundamental neue Idee aber oft von kongenialen Individuen und selten von Gruppen hervorgebracht werden:

“There is nothing democratic about innovation,” says Paul Saffo, a veteran technology forecaster in Silicon Valley. “It is always an elite activity, whether by a recognized or unrecognized elite.”

Erfolgreiche Entwickler

Firmen, die erfolgreich neue Produkte entwickeln, schaffen dies normalerweise über eine Verbindung von Bottom-Up und Top-Down Ansätzen:

Successful innovation, Mr. Saffo observes, requires “an odd blend of certainty and openness to new information.” In other words, it is a blend of top-down and bottom-up discovery.

Apple schafft den Ausgleich zwischen Bottom-Up und Top-Down dadurch, daß Steve Jobs handverlesene Manager eingestellt hat, die offen sind, gegenüber fremden Ideen. Die Firma schafft es zudem, diese Manager so vor äußeren Einflüssen abzuschirmen, daß es ihnen garnicht möglich ist mit einer Versuch-und-Irrtum-Methode vorzugehen.

Apple sammelt demnach ebenfalls externe Einflüsse, jedoch anders als es Google tut:

“It’s a lot of data crunched in a nonlinear way in the right brain,” says Erik Brynjolfsson, director of the M.I.T. Center for Digital Business.

Firmen verlassen ihr stilles Kämmerlein

Das Handelsblatt sagt vorher (siehe Weiterführende Informationen am Ende des Artikels), daß sich Firmen zunehmend öffnen werden, und daß die rein introvertierten Modelle ausgedient haben (Apple sei ein Sonderfall für eine Firma in einem hochrentierlichen Segment):

“Nach Ansicht von Experten wie Petrie sind die offenen Systeme notwendig, weil es den Firmen nur so gelingt, ständig neue Ideen in den Markt zu bringen. Denn wenn Zulieferer ständig um zusätzliche Abnehmer kämpfen müssen, steigert das die Innovationskraft.

Zudem ist es einfacher, die komplexer werdenden Liefersysteme zu managen. Hintergrund sind die immer schneller fließenden Informationen. Das setzt die Manager unter Druck. Im stillen Kämmerlein an der Strategie oder der nächsten Produktidee zu basteln, funktioniert nicht mehr.”

Fazit

Ich halte einige Punkte in den beiden Artikeln für wichtig.

Innovationsmodelle sind individuell

Das Innovationsmodell, das eine Firma verfolgt, muß zu der Firma und zu den Produkten passen. Vermutlich wird eine Softwarefirma, die Internetanwendungen erstellt, eher mit dem Google Ansatz zurechtkommen, und schnell inkrementelle Weiterentwicklungen ausliefern/ Kundenfeedback suchen.

Eine Firma, die sich z.B. mit (der wissenslastigen) Biotechnologie befaßt, wird sich alleine aus Know How Gründen vermutlich eher auf einen Ansatz wie Apple verlassen. Eine solche Firma wird Anregungen von Außen zwar aufnehmen, die innovativen Produkte aber selbst entwerfen.

Grundphilosophien

Eine Firma, die den Google Ansatz verfolgt, schnell zu reagieren, muß besonders gut sein in den Bereichen “Entwicklungsprozess”, und “Kundenbeziehungen”. Sie muss zudem in der Lage sei, datenbasierte Entscheidungen zu treffen, d.h. wird vermutlich selbst stark computerisiert sein.

Um zu funktionieren benötigen solche Firmen eine Kultur der “vielen Ideen” und der “vielen Projekte”.

Eine Firma, die eher den Apple Ansatz verfolgt, muß demgegenüber eher in der Lage sein, wichtige Anregungen von unwichtigen zu trennen, und sie muß in der Lage sein, sich fachlich von den anderen Marktteilnehmern abzuheben.

Damit dies gelingen kann, benötigt dieses Unternehmen eine Kultur der “Exzellenz”, und der “Konzentration auf das Wesentliche”.

Die Modelle stellen unterschiedliche Anforderungen an Arbeitsweise der Firma

Das Modell, das eine Firma verwendet, sollte sich auch in der internen Arbeitsweise wiederfinden. Eine Firma, die auf schnelles Kundenfeedback angewiesen ist, müßte sich demnach als eine Firma aufstellen, die nach den agile Methoden arbeitet, da nur so die schnellen Entwicklungen auch geliefert werden können.

Eine Firma deren Innovationsprozess zentralisierter abläuft, benötigt ein agiles Modell weitaus weniger, sondern diese Firma benötigt Kernmitarbeiter, die zu den besten ihres Faches gehören.

Die Firmen müssen sich öffnen

Viele Firmen stehen vor der Notwendigkeit, daß sie die Außenwelt in den Entwicklungsprozess miteinbeziehen müssen, um in Zukunft überhaupt noch mitreden zu können.

Damit stellt sich die Frage, wie sich die Firma so organisiert, daß sie in der Lage ist im Sinne von Open Innovation mit dem Markt in Kontakt zu kommen.

Wie die Artikel zeigen, reicht es nicht, daß man sich öffnen will. Man muß auch die notwendige firmenkulturelle Einstellung mitbringen, und zum Beispiel Offenheit als Chance und nicht als Bedrohung sehen.

Die Rolle des Produktmanagements unterscheidet sich

Auch unterscheiden sich die Aufgaben des Produktmanagements in beiden Modellen grundlegend voneinander. In einem System nach Google kommt es darauf an Trends wahrzunehmen, und umzusetzen. Der Schwerpunkt liegt hier eher auf dem Rollin.

In einem System a la Apple kommt es eher darauf an, die fachliche Kompetenz zu steigern, d.h der Schwerpunkt des Produktmanagements dürfte wesentlich dichter an der Produktentwicklung liegen.

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:

• →Firmen müssen ihr stilles Kämmerlein verlassen (Handelsblatt)
• →The Yin and the Yang of Corporate Innovation (The New York Times)

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
• →Techshops – Dort wo Erfinder Ideen ausprobieren
• →Business Communities
• →Open Innovation – Ergebnisse einer Konferenz in Berlin

Neulich habe ich über eine Designausstellung in Hamburg geschrieben, bei der es um designorientierte Firmen, wie Braun Elektrogeräte, Wega, oder Apple geht.

Kürzlich habe in einen Blogartikel gelesen, der für die Vereinfachung der Kommunikation und Präsentation wirbt, und sich im Grunde genommen die Frage stellt, warum einfache Präsentationen oft die Besten sind.

Da gute “designorientierte” Produkte sich ebenfalls durch diese Einfachheit auszeichnen, will ich heute beide Themen verbinden, und mich der Frage stellen, wie man einfache Produkte erschafft.

Progress and the intentional selection of less

Im Presentation Zen Blog ist kürzlich ein Artikel mit dem Titel →Progress and the intentional selection of less erschienen, der sich der Frage widmet, ob ein “Mehr” auch automatisch immer zu einem “Besser” führt. Der Autor bezieht sich hierbei auf sein eigentliches Kerngebiet, die Präsentationstechnik, und kommt hier zu dem Ergebnis, daß dort “Mehr” eben nicht automatisch “Besser” ist.

Er zitiert den folgenden Satz eines japanischen Filmemachers, der verdeutlicht, wie sinnvoll es ist, in Vorträgen an das Vereinfachen zu denken.

A blind march toward progress that’s based on distraction, temptation, and consumption may not bring happiness.” — Eiji Han Shimizu

Einfache Produkte

Ich denke, daß der Zusammenhang “je einfacher, desto besser” nicht nur in der Kommunikation gilt, sondern eben auch auf anderen Gebieten, wie zum Beispiel der Produktentwicklung. Daher habe ich mit Interesse gelesen, daß der Blogautor konkrete Vorschläge macht, wie man bei der Umsetzung vorgehen könnte:

Questions to consider

• How can you apply the “intentional selection of less” to your work?
• What elements or activities in your field serve more to distract than to engage?
• How can you remove the distractions?
• In what ways, in your field, is more actually less (and vice versa)?
• How can you increase clarity and impact by resisting the call to add more?

Meine Antworten aus Produktmanagement-Sicht, stammen aus der Praxis.

Anwendbarkeit

Der Ansatz des bewussten Verzichts läßt sich eigentlich immer gut anwenden, gerade, wenn man ein neues Produkt entwickelt. Oft wird man in der Praxis getrieben, immer mehr Features zu liefern und immer weitere Spezialfälle abzudecken. Am Ende ist das Releasedatum nah und die Software ist komplex, oder schwer zu bedienen.

Dies zeigt: Wenn man nicht aufpasst, denkt man leider nur zu spät daran, wie sinnvoll es sein kann, Features auch mal wegzunehmen, wenn man hierdurch andere Vorteile beibehält, wie die leichtere Bedienbarkeit, das konsistentere Konzept, etc.

Ich habe die besten Erfahrungen damit gemacht, daß ich jede Produktspezifikation vor der Fertigstellung noch einmal prüfe und vereinfache, solange bis ein weiteres Wegnehmen das Konzept zum Kippen bringt. Das ist dann genau der Punkt, an dem der funktionale Umfang “genau richtig” ist.

Fokusgebiete, und wie Fokussieren?

Im Softwarebereich führen “zuviel” Anforderungen quasi zwangsläufig zu Produkten, die sich kaum noch bedienen, oder durchschauen lassen. (Zu) Komplexe Produkte machen keinen Spass, und halten den Anwender erfahrungsgemäß von seiner eigentlichen Aufgabe ab.

Wenn man nicht aufpasst, entsteht das gleiche Problem auch dann, wenn man Produkte “nach und nach” erweitert, und am Ende “eiermilchlegende Wollmilchsäue” hat.

Um mit Komplexität umzugehen, sollte man sich als Produktowner nicht nur auf die Featuremenge konzentrieren, sondern man sollte vielmehr darauf achten, daß man die richtigen Features findet. Das setzt natürlich voraus, daß man genau versteht, welche Anwendungsszenarien den Kunden wichtig sind. Dies widerum bedingt, daß man seine Kunden kennt, und sie befragt.

Fortgeschrittene Backlogplanung

Unerfahrene Produktmanager(innen) tendieren dazu, sich beim Einsammeln von Kundenanforderungen zu sehr und zu eng an den Kunden zu orientieren.

Diese vermeintlich “kundenorientierte” Vorgehensweise hat den Nachteil, daß man u.U auch die Anforderungen erhebt, die dem Anwender eigentlich nur dazu dienen, kurzfristige Probleme zu lösen. Wenn man solche problemlösenden Anforderungen allzu willig aufnimmt, läuft man in die Gefahr, “zu komplexe” Produkte zu entwickeln. Dasselbe passiert, wenn man sich in einen Feuerwehrmodus drängen läßt, und Dringlichkeit vor Güte kommt.

Meiner Erfahrung nach ist es sinnvoller, Kundenanforderungen generell zu hinterfragen, und sich auch zu überlegen, ob wirklich jeder Featurewunsch Einzug in das Produkt halten muss. Auf jedem Fall ist es aus Entwicklungssicht sinnvoll, wenn sich der Productowner darauf konzentiert, einen durchdachten Backlog bereitzustellen.

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:

• →Progress and the intentional selection of less (Presentation Zen)
• → Was kennzeichnet ein gutes Product Backlog? (Blog “Produktmanagement und Vermarktung von Internetanwendungen”)

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

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

• →Die größten Fehler der Existenzgründer und das Requirementsengineering
• →Bewertung von Produktideen
• →Was tun wenn man mehr Anforderungen hat, als Zeit….?
• →Wer genau hat es verbockt? HP und die Rolle des Entwicklungs-Know-How

Es haben sich einmal wieder einige interessante Blogbeiträge, und Nachrichten in meiner Inbox gesammelt.

Heute möchte ich Ihnen diese Artikel kurz vorstellen, und – ihr und da – eigene Erfahrungen beisteuern.

Kapitalismus in der Reichtumsfalle

In dem Artikel →Kapitalismus in der Reichtumsfalle (Die Zeit) geht es um ein Thema, das gerade dann wichtig ist, wenn man über neue und innovative Produkte nachdenkt.

Die zentrale These des Autors ist, daß die Wirtschaft in den letzten Jahren zwar nominell gewachsen ist, jedoch nicht absolut, und, daß das Wachstum immer mehr zum Erliegen kommt. Insgesamt stellt er fest, daß der Wachstumsmotor der westlichen Volkswirtschaften nicht nur wegen der Wirtschaftskrise ins Stocken geraten ist, sondern eben auch aus strukturellen Gründen.

Offenbar nähern sich die meisten hoch entwickelten Industrieländer diesem Punkt. Die Geschäfte sind nicht leer, keineswegs, die Leute kaufen ein, aber sie kaufen nur ungefähr so viel wie im vergangenen Jahr oder im Jahr davor. Damit die Maschine läuft, damit die Wirtschaft wächst, müssen sie mehr kaufen und dann noch mehr, jedes Jahr.

Das aber ist schwierig. Die Märkte sind satt. Hier und da schlucken sie noch ein besonders kluges Smartphone, einen besonders schicken Laptop. Mehr geht nicht mehr hinein.

Seine Kapitalismuskritik führt zu der Frage, “ob es eine Alternative zum Kapitalismus gibt, in der sich die Menschen damit begnügen, Wohlstand zu bewahren statt ihn zu mehren”. Richtig beantworten tut er seine Frage nicht.

Ich denke, daß die Gedankengänge nicht abwegig sind. Eben gerade war in den Nachrichten zu hören, daß eine sichere Wasserversorgung weltweit immer mehr zum Problem wird. Auch wird vielen Menschen immer klarer, daß das Wirtschaften zunehmend Nachhaltigkeit erfordert. Bereits das zeigt ja, daß hier ein Bedeutungswandel einsetzt.

Darüberhinaus ist der Artikel sehr gut geschrieben. Daher: Lesen!

Crowdsourcing: Mein Burger, meine Prinzenrolle

Viele Firmen arbeiten mit Crowdsourcing-Techniken, die ja auch schon hier ein Thema waren. Mittels dieser Techniken versucht man, das Internet zu verwenden, um Kunden in den Entwicklungsprozess einzubeziehen. Ein Beispiel hierfür ist die Plattform der Firma Dell mit dem Namen Dell Ideastorm, die dazu dient, Anforderungen einzusammeln (siehe Weiterführende Informationen).

In dem Artikel →Crowdsourcing: Mein Burger, meine Prinzenrolle werden diverse Projekte beschrieben, die mit der Crowdsourcing Technik arbeiten. Es werden aber auch die Gefahren angesprochen, die hiermit verbunden sind.

Insgesamt sieht der Artikel das Thema aus Marketingsicht  und da kann viel falsch laufen. Das Cowdsourcing ist aber auch eine Technik, um die Allgemeinheit in den Innovationsprozess einzubinden.

Die dort relevanten Problembereiche werden nicht näher behandelt, wie zum Beispiel, daß es vielen Initiatoren zunehmend schwerer und schwerer fällt, echte Experten zu finden, die kostenlos und unbezahlt in einem Innovationsprojekt mitwirken.

Productivity Future Vision (2011)

In dem folgenden Video wird die Vision der zukünftigen mobilen Arbeitswelt gezeigt. Das Video ist ist aber auch deshalb interessant, weil die dort gezeigte Benutzeroberfläche sehr innovativ ist:

Obwohl das Video sehr interessant ist. Mir persönlich fehlt allerdings etwas die “Innovation”, um hier von einer “Vision” sprechen zu können. So sind viele der gezeigten Elemente schon mit heutigen Techniken möglich, und verfügbar. Zum Beispiel ist die Idee eines Kühlschrankes, der sich selbst füllt genauso alt, wie der TablettPC, der die Nutzer dabei unterstützt, ihre Arbeitstage zu organisieren.

Zukunftslabore

Das Handelsblatt hat neulich folgenden Aufruf gestartet:

Zukunft passiert nicht, sie wird gemacht. Handelsblatt-Reporter haben daher die Zukunftslabore der zehn innovationsfreudigsten Unternehmen der Welt besucht. Ab heute berichten sie unter dem Titel “Wo die Zukunft entsteht” in einer neuen Serie von Dingen, die wir eigentlich für undenkbar halten. Flugzeuge, die ohne Sprit auskommen, Autos, die fliegen, Smartphones, die Telefongespräche simultan übersetzen und damit die Sprachbarrieren der Welt aufheben, Nahrung, die wie Medizin wirkt. Ich habe jede Zeile dieser Serie mit geradezu kindlicher Faszination gelesen.

Was mich jetzt interessieren würde: Was erwarten Sie selbst von der Zukunft? Da Sie mit Ihrer Firma, Ihrem Institut, Ihrer Partei, vor allem aber mit Ihrer Kreativität direkt am Projekt Zukunft beteiligt sind, lassen Sie mich und die anderen Leser an Ihrer persönlichen Vorstellung für das Jahr 2020 teilhaben, wenn Sie mögen. Die interessantesten Beiträge – am besten nicht länger als 300 Worte – werden wir im Anschluss an die Serie in der Zeitung veröffentlichen. Sie erreichen mich unter: steingart@handelsblatt.com

Ich finde zwei Dinge recht spannend. Einmal die deutliche Hinwendung zum Thema Innovation, die in dieser Deutlichkeit vor einigen Jahren noch undenkbar war. Dann finde ich aber auch interessant, daß das Handelsblatt plant, die Zukunftsvisionen seiner Leser abzudrucken.

Wie der Artikel zum Thema Crowdsourcing zeigt, kann ein solcher Aufruf auch nach hinten losgehen. Es kann aber auch sehr spannend werden, wenn erstzunehmende Experten mitmachen. Weil ich auf den letzten Fall setze, mache ich heute etwas Werbung für diesen Aufruf.

Weiterführende Informationen

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

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

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

• →Dell Ideastorm
• →Markets or Communities? The Best Ways to Manage Outside Innovation
• →Focussing is about saying No 

Oft denkt man im Hinblick auf den Kundennutzen daran, neue Features zu liefern, und ist darauf aus, die Featurewünsche möglichst agil und auf Kundenzuruf zu implementieren.

Dabei wird nur zu gerne vergessen, daß der Produkterfolg auf unterster Ebene des Entwicklungszyklus vordefiniert wird. Dort bestimmen die Produktarchitektur zusammen mit der Strategie, mit der die Anforderungen umgesetzt werden, was Kunden später langfristig überhaupt nutzen können.

Michael Degusta hat für seinen Artikel →Android Orphans: Visualizing a Sad History of Support eine sehr interessante Grafik zusammengestellt, die sehr gut zeigt, welche Vorteile eine Plattformstrategie in der Softwareentwicklung bringt, bzw welche Nachteile eine zu große Fragmentierung hat.

Fragmentierung

Degusta zeigt in seiner Grafik (siehe unten) die Updatehistorie aller Smartphones, die in einem bestimmten Zeitraum in den USA verkauft worden sind.

Man kann sehr gut erkennen, daß die Geräte von Apple regelmäßig auf den neuesten Softwarestand gebracht werden. Vielen Geräte, die das Android-Betriebssystem verwenden, werden demgegenüber nicht mit der neuesten Softwareversion versorgt, und veralten so nach und nach.

Wenn Updates stattfinden, finden sie häufig erst mit einer großen zeitlichen Verzögerung statt, oder die Weiterentwicklung wird gleich ganz eingestellt.

Konsequenzen der Fragmentierung

In seinem Artikel zeigt Degusta einige Konsequenzen auf, so zum Beispiel die Konsequenz, daß nur sehr wenige Android Kunden überhaupt die neue Version des Betriebssystems nutzen werden, das derzeit so euphorisch diskutiert wird (Ice Cream Sandwich).

Er erwähnt aber auch einige Nachteile, wie zum Beispiel, daß es Entwicklern schwer gemacht wird, zu entwickeln, oder, daß die Sicherheitsrisiken zunehmen.

Zunächst aber zu der Frage, woher die Fragmentierung kommt.

Falsche Strategie kann zur Fragmentierung führen

Die Fragmentierung kommt, wenn man nicht aufpasst, leicht zustande. Zum Beispiel, wenn man aus extern gegebenen Gründen dazu gezwungen wird, mehrere Releases zu unterhalten und zu pflegen, fällt es zusehends schwerer, die Anforderungen gleichmäßig in jedem Release zu implementieren. Am Ende sieht die Situation dann ähnlich aus wie bei dem Android Betriebssystem.

Fragmentierung kann aber auch entstehen, wenn man “zu” agil entwickelt. So bauen viele Smartphonehersteller eigene Erweiterungen in das Betriebssystem ein, um den Kunden eine einzigartige Funktionalität bieten zu können. Spätestens beim nächsten Update des Betriebssystems müssen diese Erweiterungen angepasst werden, was im günstigen Fall zu einer Zeitverzögerung führt, und im Extremfall dazu, daß die Neuerungen nicht übernommen werden, und das Telefon veraltet.

Aus meiner Erfahrung führen aber auch kommerzielle Entscheidungen zu einer solchen Fragmentierung. Apple liefert zum Beispiel die Updates kostenfrei (oder zu geringen Kosten) an alle Kunden aus. Andere Firmen lassen sich die Gelegenheit nicht entgehen, und verlangen viel Geld für eine neue Softwareversion. Im Zweifel machen Kunden den Upgrade dann eher nicht, und schon sind die Kunden über die Releases verteilt.

Ich empfehle Ihnen, die Entscheidung wohlinformiert zu machen. Auf der einen Seite stehen die Umsätze, die sie mit den kostenpflichtigen Upgrades machen. Auf der anderen Seite hat Fragmentierung auch eigene Kosten, die man nicht unterschätzen sollte.

Kosten der Fragmentierung

Einige Kosten hat Degusta bereits erwähnt. Doch gibt es noch mehr verborgene Aufwendungen. Ich will hier nur ganz wenige Aspekte nennen, da die hohen Kosten auf der Hand liegen sollten.

Denken Sie zum Beispiel an die Kosten der Qualität i.w.S. So wird es einer Firma, die eine Releasepolitik wie Apple verfolgt, leichter fallen die Software zu testen, als dies eine Firma kann, die unterschiedliche Releases unterstützen muss (z.B. HTC oder Motorola).

Weiterhin ist die Komplexität nicht zu unterschätzen, die eine fragmentierte Lösung besitzt. Im Fall Apple müssen alle Projektbeteiligten (Entwicklung, Produktmanagement, …) die Lösung kennen, die sie optimieren können und pflegen müssen. Im Android-Fall muß weitaus mehr Versionen kennen, und unterhalten. Während man sich im ersten Fall voll auf die Optimierung konzentrieren kann, muß man im zweiten Fall viel Aufwand in den Abgleich stecken.

Daß auch die Kunden große Nachteile haben (was auch dazu führen kann, daß die Kunden unzufrieden werden), liegt auf der Hand. Schliesslich arbeiten viele dieser Kunden mit alten Funktionen, und es fehlen ihnen die neuen Features, die es erst in höheren Releases gibt.

Gegenmaßnahmen

Wenn die Fragmentierung gewollt ist, muß man sich keine weiteren Gedanken machen. Oft kommt Fragmentierung aber auch zufällig zustande. Hier sollte man mit Verbesserungen ansetzen. Hierzu einige Ideen:

• Der Arbeit an der Architektur einen großen Raum geben: Oft kommen releasespezifische Besonderheiten dadurch zustande, daß es zu aufwendig ist, ein Feature in alle Releases einzubauen. Die Schwierigkeiten wiederum ergeben sich oft daraus, daß die Produktarchitektur nicht durchdacht ist, und zu hohem Änderungsaufwand führt.
• Engen Terminen eine Absage erteilen: Viele Softwareprojekte stehen unter Zeitdruck. Aber, je höher der Druck, desto höher die Wahrscheinlichkeit, daß man sich auf einzelne Versionen kümmert. Oft kommt der Zeitdruck durch schlechte Planung zustande. Hier sollte man nachjustieren.
• Die Kosten richtig berechnen: Viele Manager unterschätzen den Aufwand der durch Fragmentierung entsteht,und treffen so falsche Releaseentscheidungen. Es ist daher sinnvoll, an den Methoden zu arbeiten, und sicherzustellen, daß die Transparenz entsteht, und, daß die Entscheidungen auf der richtigen Ebene gefällt werden.
• Synchonisierungspunkte vorsehen: Um zu verhindern, daß Versionen auseinanderlaufen, sollte man regelmäßig Synchronisierungsphasen vorsehen, die nur dazu dienen, die Versionen technisch anzugleichen.
• Test Driven Development implementieren: Mit dieser Methode entwickelt man zuerst den Testfall, und dann das Produktivcoding. Der Vorteil hierbei ist, daß man so über Testfälle verfügt, die man verwenden kann, wenn man die Software umbauen will. Ohne Testfälle wird es schnell ein riskantes Vorhaben, wenn man eine Funktionalität umbauen möchte.

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:

• →Android Orphans: Visualizing a Sad History of Support  (Degusta)

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….?
• →Living Specification und Qualität der Software
• →Focussing is about saying No 

Apple hat neulich ein neues iPhone präsentiert, das von der Fachwelt zerrissen wurde. Im Gegensatz dazu ist das Smartphone jedoch von den Konsumenten sehr gut aufgenommen worden. Fragt sich, welche Rückschlüsse aus dieser Fehleinschätzung abgeleitet werden können.

Gerade heute war die übliche Frage mal wieder ein Thema, die da lautet “Was sollen Anforderungen, Spezifikationen, und Design-Dokumente leisten, und wer liefert sie?”. Heute will ich kurz auf die Rolle von Kundenwünschen, und auf die Rolle der Entwicklungsabteilung und damit auf das Thema “Spezifikationen” eingehen.

Kunden müssen das Produkt mögen

Zum iPhone-Launch habe ich im →Handelsblatt – MorningBriefing ein interessantes Zitat gefunden. Daraus geht hervor, daß letztendlich die Binsenweisheit doch gilt – die Kunden müssen ein Produkt mögen, und nicht die Analysten:

“Apple hat all seine Kritiker widerlegt. Der Konzern zeigt mit seinem iPhone 4S, das Sprache erkennt und selber spricht, worauf es wirklich ankommt: Die Kunden, nicht die Gemeinschaft der professionellen Technologie-Experten müssen ein Produkt mögen. Unsere Experten spüren in ihrer heutigen Geschichte dem Kundengeschmack nach – und dem eigenen Fehlurteil der vergangenen Wochen.”

In einem Entwicklungsprojekt spielen die sogenannten Requirements die Rolle der Kunden. Requirements beschreiben und quantifizieren die Marktprobleme, und stellen damit dar, welche Bedürfnisse die Kunden haben, und wie diese aussehen sollen. Im folgenden Kapitel geht es um die Frage wie Requirements umgesetzt werden.

Requirements, Spezifikationen, und Designs

Requirements alleine reichen nicht. Bevor eine Entwicklung stattfinden kann, ist es erforderlich die Requirements in eine funktionale Spezifikation umzusetzen. Diese Spezifikation hat die Aufgabe, genau zu beschreiben, wie die Anforderungen abgedeckt werden sollen. Sie behandelt damit das Lösungsdesign aus Kundensicht.

Um den Schritt gehen zu können, die Requirements in eine Spezifikation zu überführen, ist es oft erforderlich, die Anforderungen näher zu klären. Dies liegt daran, daß  die befragten Kunden ja die Lösung bereits kennen müßten, während sie ihre Anforderungen formulieren.

In diesem Schritt ist es daher auch wichtig darauf zu achten, daß man Requirements auf Herz und Nieren prüft. Anforderungen sind erfahrungsgemäß oft inkomplett, und sie können auch Anforderungen beinhalten, die sich so wie gefordert nicht umsetzen lassen. Diese Probleme sollte man erkennen, bevor eine Entwicklung überhaupt beginnt.

Nachdem bekannt ist, was ein Produkt aus Kundensicht leisten soll, muss man dem die technische Ausführung gegenüberzustellen, um zum Produkt zu kommen. Eine technische Spezifikation (manchmal auch “Design” genannt) behandelt die Frage, wie die funktionelle Spezifikation in eine konkrete Entwicklung umgesetzt wird, und in welcher Technologie. In diesem Schritt sollten die Kundenanforderungen bereits genau geprüft und verstanden worden sein. Daher stehen hier eher die Umsetzungsaspekte im Vordergrund der Betrachtung.

Lebende Spezifikation

Neulich habe ich über das Thema “lebende Spezifikation” geschrieben. Dieses Dokument wird zwischen den Schritten “Requirements” und “Spezifikation” verwendet.

Während eine Spezifikation normalerweise in Form eines Dokuments geschrieben wird, besteht eine lebende Spezifikation eher aus einer Datenbank, o.ä. in der konkrete Beispiele abgelegt werden, welche die Lösung behandeln.

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:

• →Pragmatic Marketing’s On Reqs and Specs
• →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….?
• →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

Die Frage taucht ja gerne mal wieder auf, und beschäftigt dann den oder die Product Owner: Soll das Scrumteam lieber ein Feature mehr entwickeln, oder sollte man die Zeit in einen Test stecken, der dazu dient, die Qualität zu verbessern.

Heute geht es um die Frage, wie wichtig ein neuer Ansatz für viele IT Unternehmen ist. Oft drückt der Markt, und fordert “Feature, Feature, Feature”. Sie werden aber sehen, daß es durchaus sinnvoll sein kann, auch mal nicht auf den Markt zu hören, und statt ein Feature zu entwickeln, einen Test zu machen. Es ist zwar ungewohnt, aber es stimmt – Kunden haben doch nicht immer recht….

Windows Vista, Windows 7, und die Komplexität

Sie werden es sicher noch errinnern, daß das Softwarepaket Microsoft Vista nicht sehr gut im Markt aufgenommen worden ist. Insbesondere wurde die mangelhafte Qualität bemängelt, und das Produkt ist nie richtig beliebt gewesen, weil es als nicht sonderlich benutzerfreundlich bekannt war. Vista ist nicht wirklich erfolgreich gewesen – ein Problem für eine Firma, die quasi von diesem Betriebssystem lebt.

Mit Windows 7 hat Microsoft nicht nur am Produkt gearbeitet, sondern hat eben auch den gesamten Entwicklungsprozess verändert (mehr hierzu in meinem älteren Artikel →Pair Programming). Der Grund für diese Änderung war, daß man eingesehen hatte, daß die Software so groß geworden war, daß es nicht mehr anders sicherzustellen war, Qualität zu liefern. Letztendlich hat Microsoft sich den agilen Methoden verschrieben, und hat die dort entwickelten Qualitätsmethoden aktiv übernommen.

Wie ein älterer Blogbeitrag eines Microsoft Mitarbeiters zeigt, ist der Entwicklungsprozess bereits seit vielen Jahren durchaus komplex gewesen. Dort geht es darum, daß eine kleine Softwareänderung eine ganze Kette weitere Aktivitäten hinter sich herzog. Hier ein kleiner Ausschnitt von diesen Folgeaktivitäten:

“One dev to spend five minutes implementing ChangeLightBulbWindowHandleEx.

One program manager to write the specification.

One localization expert to review the specification for localizability issues.

One usability expert to review the specification for accessibility and usability issues.

At least one dev, tester and PM to brainstorm security vulnerabilities.

One PM to add the security model to the specification……”

Grundsätzlich glaube ich, daß die Darstellung etwas übertrieben ist, schon alleine, wenn man daran denkt, daß Microsoft diesen Aufwand sicher nicht für jede Korrektur einzeln gemacht hat, sondern wohl eher für ein Bündel von Änderungen. Allerdings zeigt die Darstellung, daß Microsoft die “Wasserfallmethode” verwendet hat, d.h einen großen Entwicklungsprozess, in dem die einzelnen Aufgaben bei einzelnen Funktionen zentralisiert waren.

Agile Methoden

Agile Methoden setzen stark auf befähigte Teams (Teams of Ten). In der neuen Entwicklungswelt ist das Team für die meisten Aufgaben selbst verantwortlich. Mit der seit Windows 7 bei Microsoft verwendeten agilen Methode sind daher viele Aufgaben in einem einzelnen Scrum Team angeordnet, und werden sogar vom selben Entwickler erledigt werden, wie zum Beispiel das Schreiben und das Reviewen der Spezifikation.

Auch in Bezug auf die Qualität ergibt sich eine andere Sicht: Sie ist nicht mehr die Aufgabe einer zentralen Testabteilung, sondern liegt eben in der Verantwortung des Teams. Eine dieser Methoden ist das Pair Programming. Zum Beispiel berichtet die Wissenschaft für diese Methode über einen sehr großen Nutzen (siehe →Pair Programming, what researchers say),

Auf den →Agile testing days wird es um die einzelnen Methoden gehen. Bereits der Agenda kann man entnehmen, daß es bei den agilen Methoden darum geht, die einzelnen Teammitglieder zu befähigen.

Feature oder Test

Das Microsoft-Beispiel hat aber auch noch einen anderen wahren Kern: selbst wenn Anforderungen klein aussehen, können sie eine große Menge von Änderungen herbeiführen. Diese Änderungen müssen ha alle irgendwie koordiniert werden. Auch arbeiten Menschen an der Umsetzung der Anforderungen. Dies bedeutet, daß Fehler nicht nur möglich sind, sondern Realität. Daher läßt sich die Eingangsfrage vielleicht so beantworten:

Das Testen/die Qualität ist genauso wichtig wie das Entwickeln von Features, d.h beiden Teile sollten in einem ausgewogenen Verhältnis zueinander stehen.

Wenn man sich dann noch vergegenwärtigt, daß selbst die große Firma Microsoft in Probleme läuft, wenn Qualitätsprobleme auftreten, kann man sich vorstellen, was mit einem StartUp passiert, daß sich nur um das Umsetzen von Anforderungen kümmert – vermutlich wird es nicht lange leben.

Das Explorative Testen zeigt sich immer mehr als eine Methode, die hierbei eine herausragende Bedeutung einnimmt, da gerade diese Methode den Entwicklern die Möglichkeit gibt, die Software einmal richtig durchzuprüfen.

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:

• →Agile testing days
• →Blogging Quality
• →Pair Programming, what researchers say

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

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

• →Final Cut Pro – Produktmanagement-Perspektive
• →Wie Google Software testet – die Rolle des Entwicklungsteams
• →Exploratory Testing – Weitere Touren
• →Pair Programming

In seinem Artikel → The Design Pyramid schreibt Philip Haine über die Frage, wie Forschung, Vision und Design zusammenpassen müssen, damit fundamental neue Produkte entstehen:

“How research, vision and design fit together to make breakthrough products”

Haine’s Designpyramide, die ebenfalls Gegenstand des Artikels ist, besteht aus mehreren aufeinander aufbauenden Phasen, beginnend bei der Phase “Understanding”, über die Phasen “Vision” und “Requirements” zum “Design”, wobei jede Vorgängerphase die Grundlage für die nächste Phase bildet.

In seinem Artikel geht er auch auf die Entwurfsmuster ein, die hinter jedem guten, und erfolgreichen Produkt stehen. Darum geht es mir heute.

Breakthrough product ideas come from from breakthrough understanding

Der Idee folgend ,daß “Understanding” vor “Design” kommt, liegt Haine’s Behauptung nicht fern, daß tolle, und bahnbrechende Produktideen (nur) aus dem tiefgreifenden Verständnis der Kundenanforderungen entstehen. Er bringt hierfür das Beispiel des – wie er selbst sagt – überstrapazierten iPod von Apple, und erzählt hierzu die Entstehungsgeschichte.

Da die Aussage recht interessant ist, gebe ich sie vollständig wieder, obwohl es dadurch ein langes Zitat wird:

Take, for example, the overused example of the iPod.  Apple noticed that early batch of MP3 players played music well enough, but getting songs on the device was excruciatingly slow over the USB 1.0 interfaces common at the time.  Plus, the quirky, proprietary music transfer software was hard to manage.  This was a real problem.  The solid-state devices of the day had such small capacity that unless you liked listening to the same three albums over and over again, you had to spend a lot of time transferring new music onto the device.  Because of this cost, MP3 players often ended up gathering dust in a drawer.  These were Apple’s core insights, at the Understanding level of the Pyramid.

The iPod vision was sculpted to address these problems: make music management easy with great desktop software (iTunes); make transfers fast (using Firewire) and make transfers rarely necessary (with a high-capacity, hard-drive based player). Beyondthis, Apple understood that the that gadgets you are seen with in public are a reflection of your image, and that an MP3 player should look and feel cool.

Their easy, fast, high-capacity, cool looking iPod was a breakthrough product that virtually owned the digital music market through its entire arc (until smartphones and pocketable computers like the iPod Touch relegated the single-purpose music player to niche product).

Man sollte vielleicht ergänzend erwähnen, daß die Ursprungsidee zu iTunes und iPod nicht von Apple selbst stammt, sondern von einem Mitarbeiter, der von einer anderen Firma dahin gewechselt hat. Er hatte sich in dieser Firma bereits mit dem Thema befasst, und Steve Jobs war kreativ genug, den guten Kern der Idee zu erkennen, als sie ihm vorgestellt wurde.

Was zeigt dies? Nun, es ist wichtig, daß

• …man sich vor der eigentlichen Entwicklung ein umfassendes Bild von den eigentlichen Kundenbedürfnissen macht – “eigentlich” heißt in diesem Zusammenhang, daß es um die echten Anforderungen geht, und nicht nur um die Featurewünsche, die die Kunden äußern.
• … man während der Entwicklung Mechanismen verwendet, die das Team auf Kurs halten.
• … man nach der Entwicklung ausgiebig testet und prüft, ob das Produkt auch in jeder Dimension das leistet, was es leisten soll.

Modifizierte Designpyramide

Die Haine’sche Designpyramide geht auf die Schritte zwischen Kundenbedarf und Design ein, und umfaßt die Phasen “Vision” und “Requirement”, wie bereits weiter oben gesagt. Diese Pyramide behandelt daher im Grunde genommen die Frage, wie man sich ordentliche Produktanforderungen erarbeitet, und wie man zu einer guten Spezifikation kommt. Damit fehlt aber noch ein gutes Stück Anstrengung auf dem Weg zu einem guten Produkt.

An dieser Stelle fehlt meiner Meinung nach zwei Phasen, die man vielleicht “Prototyping” und “SpecReview” nennen könnte. Auch sollte man die Pyramide eher als einen Regelkreis verstehen, als eine Pyramide, die man von unten nach oben durchläuft.

Ein weiteres Thema, das die Designpyramide nicht abdeckt, ist die Frage der eigentlichen Umsetzung, die oft wieder einen Einfluß z.B. auf das Design hat. Hierfür sind Schritte notwendig, die sich an die Designphase anschliessen. Beispiele hierfür wären z.B. die anschiessende Qualitätsicherung, beginnend beim Review der Anforderung, bis zu entwicklungsbegleitenden Tests und Aktivitäten.

Prototyping

Normalerweise haben “Produktanforderungen” das Problem, daß Kunden zwar etwas sagen, und die Entwicklung etwas anderes versteht. Sie entstehen daher zunächst als Featurewünsche.

Im Normalfall sind aber genau die Anforderungen interessant, die der Kunde zwar hat, die er aber nicht artikulieren kann, weil er die Lösungsmöglichkeiten nicht kennt. Dabei handelt es sich um die Anforderungen, die sich nicht aus konkreten Featurewünschen herleiten lassen.

Um mit diesem Problem umzugehen, sollte bereits sehr früh damit begonnen werden, sich Prototypen und Muster zu erstellen. Solche Prototypen helfen zum Beispiel im Kundengespräch dabei, um gemeinsam festzustellen, ob die Anforderungen, die man verstanden hat, auch diejenigen sind, die der Kunde hat. Man würde hiermit also zwischen dem oberen Punkt in der Pyramide (Design), und der unteren Phase (Anforderungen) hin und herspringen.

An anderer Stelle in meinem Blog habe ich über die Design-Thinking-Methode geschrieben, die genau diesen Ansatz auch methodisch kultiviert.

Spec Review

Zwei Fragen haben meiner Erfahrung nach immer wieder Einfluß auf ein Produktdesign, das oft unterschätzt wird:

• Stimmen die Anforderungen, auf die sich das Produkt bezieht?
• Sind die Anforderungen angemessen spezifiziert?

Um diese Fragen beurteilen zu können, sollte man unbedingt ein Review von Anforderungen und Spezifikation durchführen. In diesem Review sollte man (auch) die Frage stellen, ob die “Anforderungen” auch in einem größeren Zusammenhang überhaupt Sinn machen. Gut, bei der Entwicklung eines iPod hat man an dieser Stelle vielleicht wenig Spielraum. Bei geschäftskritischer Software ist diese Frage jedoch ungleich wichtiger.

Qualität

Gerade bei größeren Entwicklungen sollte man dafür Sorge tragen, daß man den einmal angepeilten Weg auch konsequent verfolgt. Dieser Schritt kann aber beliebig komplex werden, insbesondere, wenn man sich auf Entwicklungen konzentriert, bei denen sich das Design im Projektverlauf ändern kann, z.B. weil man auf unerwartete Schwierigkeiten trifft.

Um hiermit umzugehen benötigt man Verfahren, die die Gesamtentwicklung in kleine Pakete einteilen, wie zum Beispiel die Scrum Methode. Man benötigt zudem Methoden, anhand derer man entscheiden kann, ob ein einzelnes Backlog Item erledigt ist, und inwieweit Änderungen im Gesamtkonzept notwendig sind. Üblicherweise benötigt man hierfür Done Kriterien, die man sowohl anwendet während man das Design entwickelt, als auch, während man das Design umsetzt.

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 Haine’s Blog mit dem Titel →Steal This Idea finden Sie eine Fortsetzungsreihe zu der hier angerissenen Methode, und Themen im Umfeld.

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

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

• →Spezifikationen und Testing
• →User Centric Development
• →Wie Sie Marktführer bleiben

Gerade in der Entwurfsphase einer Software hat man auf der einen Seite die Wünsche der “Kunden”. Auf der anderen Seite stehen die einzelnen Realisierungen. Die Analysemethode, um die es heute geht, hilft dabei die Produktanforderungen, und die Featureentwicklung zusammenzubringen.

Die Stakeholder-Stituation-Need-Feature Analyse kann dabei auf verschiedenen Leveln angewendet werden, und sie hilft sowohl bei der Strukturierung, als auch bei der Qualitätsprüfung der Produktanforderungen.

Überblick über die Methode

In der Anforderungsphase lautet die Aufgabenstellung, die Situation des späteren Anwenders so aufzunehmen, daß es möglich ist das gesamte Softwareprojekt in einem Design zu beschreiben. In der darauf folgenden Designphase werden den einzelnen Anforderungen die einzelnen Realisierungsmöglichkeiten, bzw Features gegenübergestellt.

Da die Anforderungen letztendlich festlegen, wie das Design aussehen wird, sollten Anforderungen komplett sein. Auf der anderen Seite ist es wichtig, daß sie die Nutzererwartungen adäquat abdecken. Um hierbei nichts zu vergessen, ist eine konsistente Methode notwendig, um die es im folgenden Absatz geht.

Elemente der Methode

In einem Softwareentwicklungsprojekt stellt die Stakeholder-Situation-Need-Feature-Analysemethode folgende Informationen gegenüber:

• Stakeholder (auch Nutzer oder Kunde) – Wer ist der Abnehmer/ Adressat des zu entwickelnden Features?
• Situation – Wie stellt sich die Situation für den Stakeholder dar/ wie lautet seine Aufgabenstellung?
• Need/ Bedürfnis – Welche Bedürfnisse hat der Abnehmer in der konkreten Situation?
• Feature/ Funktionalität – Welche Funktionalität hilft dem Stakeholder in der konkreten Situation bei der Deckung der Bedürfnisse?

Normalerweise fängt man dabei auf einem höheren Level an, und beschreibt das Gesamtsystem auf einer relativ hohen Abstraktionsebene. Auf diesem Level geht es um den Überblick, und um die Komplettheit der Anforderungen. Bei der Prüfung auf Komplettheit hilft das hohe Abstraktionslevel.

In der späteren Designphase steht die einzelne Funktionalität im Vordergrund, und die Zuordnung von Anforderung und Feature. In dieser Phase benutzt man dieselbe Analysemethode auf einem wesentlich feingrannulareren Abstraktionslevel.

Beispiel – Phase “Überblick”

Das folgende Beispiel zeigt das System Urlaubsreise auf einem hohen Niveau:

• Der Autofahrer (Stakeholder) fährt seit mehreren Stunden auf der Autobahn, und möchte eine Pause machen, da er müde ist (Situation). Er hat das Bedürfnis, sich die Beine zu vertreten, und etwas zu essen (Bedürfnis). Er fährt hierfür die nächste Raststätte an (Feature).
• Die Raststätte (Stakeholder) steht in einem harten Wettbewerb mit anderen Raststätten, und ist darauf angewiesen, um seine Kunden zu werben (Situation). Sie benötigt daher eine Küche, die schmackhafte Gerichte zu einem guten Preis anbieten kann, und ein ansprechendes Ambiente (Bedürfnis). Er sucht daher einen gut ausgebildeten Koch (Feature).

Auf diesem Level ist es möglich, die großen “funktionalen” Bereiche zu identifizieren, und man kann den Überblick über die Gesamtaufgabenstellung behalten, vor der der Stakeholder steht. Gleichzeitig erkennt man die wesentlichsten Informationen, die einen in die Lage versetzen zu verstehen, wer, was warum benötigt, und wie man sein Bedürfnis befriedigen kann.

Jedoch wären die gezeigten Anforderungen noch wesentlich zu abstrakt, um konkrete Produktentwicklungsschritte einzuleiten.

Beispiel – Detail-Phase

Die folgenden Beispiele zeigen “Low-Level-” Anforderungen, die bereits so detailliert sind, daß man damit konkrete Features entwickeln könnte. Es ist allerdings auch gut zu sehen, daß auf diesem Abstraktionslevel der Überblick verloren geht, und gesondert sichergestellt werden muss.

• Der Raststättenbesucher (Stakeholder) stellt sein Auto auf einem Parkplatz ab, den er auch im dunklen finden können sollte (Situation). Er benötigt daher Leitstreifen oder ähnlich, die die Parkfläche markieren (Bedürfnisse). Der Parkplatz wird deshalb beleuchtet (Feature).
• Der Restaurantkunde (Stakeholder), der viele Stunden gefahren ist (Situation) will sich nach dem Parken erst einmal frisch machen, ohne dabei die Restaurantgäste zu stören (Bedürfnis). Das Bad sollte noch vor der Eingangstür zum Restaurant angeordnet sein (Feature).
• Auch die Vegetarier unter den Autofahrern (Stakeholder) haben keine Ausweichmöglichkeit (Situation) und wollen fleischlos, aber geschmackvoll essen (Bedürfnis). Es wird daher jeden Tag mindestens ein vegetarisches Essen angeboten (Feature).

Nutzen

Die ist nur ein kleiner Ausschnitt aus den Charakteristika der Methode. Alles in Allem halte ich sie für sehr empfehlenswert.

• Die vorgestellte Methode hat aus meiner Sicht einen sehr hohen Nutzwert insbesondere, weil es mit derselben Methode gelingt High-, und Low-Level-Anforderungen zu beschreiben, ohne die Methode zu wechseln. Dies unterstützt sehr gut die Realitäten in einem Projekt, wo man ja auch zunächst auf hohem Niveau startet, und sich dann auf die Detailebene vorarbeitet.
• Es ist mit dieser Methode möglich, auch Nicht-Experten einzubinden, sei es nun im Scrumteam, oder sei es im Gespräch mit Kunden. Letztendlich ist sie selbsterklärend, und in sich geschlossen. Sie geht zudem von der Situation der Nutzer aus, und ist deshalb bereits im Grundsatz kundenzentriert. Besonders vorteilhaft ist hierbei, daß die Analysemethode einen eingebauten Reality Check besitzt. Schliesslich werden keine Features ohne konkreten Bedarf entwickelt.
• Die Methode ist zudem schnell und unkompliziert. Dies ist dann wichtig, wenn man zum Beispiel einen konkreten, beobachteten Arbeitsablauf aufnimmt, und darauf angewiesen ist, möglichst nicht zu stören. Dort würde man ggfs mit den Situationen und Bedürfnissen anfangen, um dann später auf die Features zu kommen.
• Dadurch daß man sich durch Situation und Bedürfnis arbeitet, erhält man zudem ein gutes Gefühl zu dem “Warum-Will-der-User-das-Feature”. Dies ist deshalb wichtig, wie ich finde, da es eigentlich am einfachsten ist, wenn man versucht, wie der User zu denken. Dafür muss man aus der Situation verstehen, warum er bestimmte Bedürfnisse hat, und man muss sicher sein, daß diese Bedürfnis sinnvoll ist. Gerade die Überprüfung der Sinnhaftigkeit einer Anforderung hilft einem konkret zu verstehen, ob man es mit einer allgemeingültigen Arbeitsweise zu tun hat, und nicht etwa um einen fehlerhaften Prozess, den man sonst unkritisch nachbauen würde.

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 →Steal This Idea finden Sie eine Fortsetzungsreihe zu der hier angerissenen Methode, die aus vier Teile besteht, und das Thema im Detail darstellt →SSNiF Analysis ….. Der Blogautor Philip Haine arbeitet generell in den Bereichen Requirements, Entwicklung, Produktkonzept, Product Vision, Design, etc. Seine Site lohnt einen weiteren Blick, wie ich finde.

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

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

• →Die Güte der Nutzungserfahrung entscheidet über den Erfolg
• →Design Thinking – Hauptphasen
• →Role of the Product Vision when Development goes Agile

Ich bin mir nicht sicher, ob Sie den kleinen Product-Launch-Krimi mitbekommen haben, der sich neulich um ein neues Apple Produkt herum abgespielt hat. Da der Krimi einige lehrreiche Facetten enthält, will ich heute darauf eingehen.

Konkret hat Apple die alte Videoschnitt-Software Final Cut ersetzt durch eine runderneuerte Version. Diese ist so zwiespältig im Markt aufgenommen worden, daß einige kreative Reaktionen notwendig waren. Insgesamt scheint das Produkt durchgefallen zu sein. Nun ist guter Rat teuer, und man kann viel lernen.

Der Sachverhalt – Ein eskallierter Product Launch

Cut Pro Product Launch

Apple hat vor einiger Zeit die neue Software zur Filmproduktion (Final Cut Pro X) angekündigt mit dem Slogan →Final Cut Pro X – Das verändert alles in der Post. Final Cut Pro X ersetzt die Vorgängerversion vollständig, und wurde von Grund auf neu geschrieben. Die zentrale Aussage lautet, daß man die wichtigsten Features der Vorgängersoftware übernommen hat:

“Final Cut Pro X enthält die wichtigsten Funktionen für Audiobearbeitung und Farbkorrektur aus Final Cut Studio – so lässt sich jetzt die gesamte Postproduktion mit einem einzigen Programm erledigen. Und mit Motion und Compressor – ebenfalls im Mac App Store erhältlich – ist sogar noch mehr möglich.”

Final Cut Pro X: Bewertungen im Mac App Store waren vorübergehend deaktiviert, Updates bereits verfügbar

Wie MacNotes.de schreibt, ist die Software nicht von allen Käufern gut aufgenommen worden. Aufgrund der großen negativen Resonanz war kurzzeitig sogar die Kommentarfunktion im App-Store deaktiviert worden (siehe →Final Cut Pro X: Bewertungen im Mac App Store waren vorübergehend deaktiviert, Updates bereits verfügbar), oder war es ein Bug? Apple hat nach einer kurzen Gedenkpause allerdings schon damit begonnen fehlende Funktionen nachzuliefern.

“Vorgestern erst kam Final Cut Pro X in denMac App Store und hat bereits große Wellen geschlagen. Die Bewertungen waren jedoch eher mäßig: Zum Zeitpunkt des Beitrags vergeben 682 Bewertungen insgesamt 2,5 von 5 Sternen. Apple hatte daraufhin die Kommentarfunktion vorübergehend gesperrt. Außerdem sind bereits die ersten Updates verfügbar.

Final Cut Pro X ist als Anwendung für den professionellen Einsatz ausgelegt, scheint dafür aber nicht wirklich zu taugen. Viele Anwender beklagen sich, nicht nur im Mac App Store, über fehlende Features, die gerade für eine Pro-Anwendung wichtig wären. Apple hatte daraufhin heute Morgen die Kommentare deaktiviert, einzig sichtbar blieben nur die Bewertungen. Inzwischen sind die geschriebenen Bewertungen aber wieder freigeschaltet

Final Cut Pro X: Apple-Produktmanager nehmen Stellung

Nach einigem Hin- und Her, begann das Problem sichtlich hochzukochen. Wie die MacNews melden (siehe →Final Cut Pro X: Apple-Produktmanager nehmen Stellung), hat sich im weiteren Verlauf das verantwortliche Produktmanagement mit einer Stellungnahme beteiligt. Interessanterweise hat Apple hierzu einen Mediator hinzugezogen, der vermittelnd tätig wurde.

David Pogue, dieser Mediator, schreibt bei der New York Times über Tech Themen, und ist so vielen Leuten bekannt:. Hier zunächst das Statement der MacNews:

“Die Vorstellung des komplett überarbeiteten Final Cut Pro X Anfang der Woche ging, aus Apples Perspektive betrachtet, ganz schön in die Hose. Nachdem Fachpresse und Anwender in ihren diversen Foren Stimmung machten, stellten sich jetzt Apples Produktmanager selbst den diversen Problemen und Kritikpunkten. Als Mediator suchte sich Cupertino den bekannten Apple-Blogger David Pogue von der New York Times, der in Frage und Antwort zusammenfasste….

Mit einer durchschnittlichen Benutzerwertung von nur 2,5 Sternen im MacApp Store steht Final Cut Pro einsam unter den schlechtesten und zugleich teuersten Programmen der Software-Sammlung. Vor allem Profi-Anwender, die mit dem Programm einst ihr Geld verdienten, sehen sich von Apple im Stich gelassen, mit dem Verbraucher betrogen und verraten. Pogue sammelte die Kritikpunkte und ließ Produktmanager Stellung nehmen. Die Antworten sorgen zumindest teilweise für Aufatmen. Immerhin lassen sich die Probleme nun aufteilen in solche, die bleiben, solche die sich über Umwege lösen lassen und solche, die Apple selbst noch beheben wird.”

Apple’s Final Cut Is Dead. Long Live Final Cut

Pogue selbst veröffentlicht weitere Hintergrundinformationen unter dem Titel →Apple’s Final Cut Is Dead. Long Live Final Cut. Er behauptet, daß Apple hier einen typischen Schachzug unternimmt, nämlich, eine populäre Software auf dessen Höhepunkt zu ersetzen, und dabei so vorzugehen, daß die neue Version inkompatibel zur Vorgängerversion ist:

On Tuesday, Apple pulled a typical Apple move: it killed off the two-year-old Final Cut 7 at the peak of its popularity. In its place, Apple now offers something called Final Cut Pro X (pronounced “10”). But don’t be misled by the name. It’s a new program, written from scratch. Apple says a fresh start was required to accommodate huge changes in the technological landscape.
…

Some professional editors are already insisting that Apple has made exactly the same mistake with Final Cut X; they pointed out various flaws with the program after an earlier version of this column was posted online on Wednesday.

Apple admits that version X is a “foundational piece.” It says that it will restore some of these features over time, and that other companies are rapidly filling in the other holes.

Er kommt in seinem Beitrag zum Schluss, daß die neue Software preiswerter ist, und leichter zu bedienen. Dafür fehlen der ersten Version noch wichtige Features, die allerdings teilweise nachgeliefert werden – langfristig wird sich die neue Software daher wohl durchsetzen:

The bottom line: The rewritten Final Cut is much, much easier to use than the old one, and its immediacy keeps your creative flow going.
But not everyone will fall in love. Switching to the new Final Cut from the old one is like coming home from college to discover that your parents remodeled your bedroom. Longtime Final Cut jockeys, in particular, may grind their teeth for a few days — and not just because they have to pay $300 for the “upgrade,” same as newcomers.

Final Cut Pro X Info Update

In dem Artikel →Final Cut Pro X Info Update des SlashCam-Blogs hat daraufhin eine umfassende Zusammenfassung des gegenwärtigen Stands der Dinge zur Verfügung gestellt. dabei liegt der Fokus auf den Profis, an die sich der Blog hauptsächlich wendet.

Demnach scheint es so zu sein, daß die Software bei den Profis durchgefallen ist, und sich gerade im Netz eine Stelle herausbildet, wo man sich ganz einfach einen Überblick über die fehlenden Features machen kann. Diese werden nämlich von enttäuschten Kunden dort zusammengesammelt. Die Kunden haben sich dort ad-Hoc gefunden, und organisieren sich selbst:

Der in den Dialog mit dem NYT-Autoren David Pogue und dessen Apple-FAQ getretene Cutter Richard Harrington wertet Pogues abschließenden Artikel als Sieg: dort erklärt er die vielen Kommentare professioneller Cutter hätten ihn dazu bewogen einzusehen, dass Apple Mist gebaut hätte und FCPX nicht reif für den Profimarkt sei. Harringtons Version von Pogues FCPX FAQs selbst wird immer facettenreicher durch weitere Erkenntnisse, welche Funktionen doch gehen´oder wirklich fehlen und dürfte dadurch (u.a. für verzweifelte Broadcast-Editoren) eine immer interessantere Übersicht über den neuesten Stand der (fehlenden) Features werden.

Lessons learned

Ich war nicht dabei. Daher kann ich nur mutmaßen. Wenn ich mir allerdings die Information ansehe, erkenne ich dort einige typische Fallen, in die Apple (wissentlich oder unwissentlich) gelaufen ist.

Use Case und Persona

Angefangen hat das Problem damit, daß man offensichtlich nicht für jeden Use Case verstanden hatte, welche Produktmerkmale welchen Kunden besonders wichtig sind. Wäre es anders gewesen, hätte Apple sicher den Rollout anders akzentuiert, oder gleich das gesamte Entwicklungsprojekt. Man hätte dann sicher nicht erst gewartet, daß die Profis unter den Kunden den Aufstand proben, sondern hätte von Beginn an, das Produkt so positioniert, daß klar geworden wäre, daß funktionale Lücken bestehen, diese aber schnell geschlossen werden.

Fazit: Gerade, wenn man ein erfolgreiches Produkt redesigned, kann es vorkommen, daß Features wegfallen, die den Bestandskunden besonders wichtig sind. Auch sind fehlende Migrationspfade wahrscheinlich.

Hier ist es besonders wichtig, vorab mit Powerusern zu klären, welche Features wie wichtig für deren Arbeit sind. Bei einem Produkt, das man weiterentwickelt, sind die Features ja enthalten. Bei wegfallenden Features kommt man aber nicht umhin die fehlenden Informationen zu erforschen. Nur so kann ein angemessener Releaseplan aus Nutzersicht entstehen.

Sichtbarkeit

Apple hat das Produkt offenbar sofort einem breiten Publikum zur Verfügung gestellt, und hat es zudem in einen AppStore eingestellt, in dem sich jedermann ohne große Probleme einen Überblick über den Kundenfeedback verschaffen kann. Diese Strategie spielt auf volles Risiko. Eine Alternative wäre, wenn man die neue Software schrittweise in den Markt gibt, wie zum Beispiel, indem man ein Beta-Programm vorschaltet, bei denen klar wird, daß die Entwicklung nicht komplett ist.

Im konkreten Fall hat Apple nun auf Risiko gespielt, und verloren. Man ist daraufhin (wahrscheinlich) kurzzeitig der Versuchung erlegen, das Feedback zu unterdrücken, statt aktiv zu reagieren. Anderenfalls hätte man sicher nicht die Kommentarfunktion deaktiviert.

Fazit: Der Rollout sollte so geplant werden, daß es möglich ist, ohne großen Gesichtsverlust umzusteuern, oder indem man das Release gleich so aufbaut, daß Kunden einem gezielt mit Feedback helfen können. Wenn man negatives Feedback erhält, bleibt eigentlich nur noch über, daß man damit positiv umgeht. Jegliche Form der Unterdrückung führt generell nur zu Problemen.

Mediation

Der Mediator nimmt eine wichtige Rolle ein, da man nicht jede kritische Kundensituation selbst lösen kann. Im konkreten Fall hat Pogue quasi als Blitzableiter gearbeitet, und hat es möglich gemacht, daß Kunden und Apple sich auf die eigentlichen Inhalte konzentrieren konnten, bzw nicht in ihren eigenen Rollen verharrt sind.

Gleichzeitig hat der Mediatoransatz Apple gestattet, seine (natürliche) Verteidigungshaltung zu verlassen. Auch war es möglich, den Kunden zu kommunizieren, daß mancher Feedback auf falsche Bedienung zurückzuführen ist, oder auf Features, die nachgeliefert werden, weil sie sowieso geplant sind. Gerade das Problem, daß mancher Feedback auf Bedienungsfehler zurückzuführen ist, ist oft zu beobachten. Daher hat hier ein Mediator eine wichtige Funktion, denn nur über ihn kann ein Hersteller solche Punkte überhaupt adressieren.

Fazit: Um mit kritischen Kundensituationen umgehen zu können, ist es manchmal sinnvoll, Mediatoren einzuschalten. Dies können Blogger, wie Pogue sein, die Presse, oder zum Beispiel Vertreter von Kundenvereinigungen. Generell beobachtet man oft, daß eine Kundeneskallation aus mehreren Teilen besteht: Echten Defiziten, Fehlende Features und Workarounds, bzw Bedienungsfehlern. Die einzelnen Teile sollte man zunächst sorgfältig separieren, und schrittweise abarbeiten.

Kundenfeedback

Apple ist erst dann, als das Kind schon in den Brunnen gefallen war auf die Idee gekommen, den Kunden fehlende Features oder nachzuliefern, bzw die Lieferung zu avisieren. Gleichzeitig hat sich eine Sammlung im Web etabliert, die die Lücken auflistet. Solche Sammlungen nehmen generell eine wichtige Funktion ein, weshalb es unabdingbar ist, daß ein Hersteller darauf reagiert und eingeht.

Hier beginnt aber häufig auch ein Problem: Das Team, das an der Software arbeitet ist sicher nicht mit endloser Kapazität ausgestattet. Auf der anderen Seite ist fallweise eine schnelle Reaktion gefragt. Aus organisatorischer Sicht ist daher wichtig, daß das Entwicklungsmodell kurze Feedbackzyklen erlaubt, und inkrementelle Verbesserungen.

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:

• →Why some technical decisions are too important to leave to engineers
• →The Strategic Role of Product Management
• →Ideabits – Gute Ideen zu verschiedenen Produktmanagement-Themen