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

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

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

Im Rahmen der userzentrierten Entwicklung konzentriert man sich auf die Situation des Anwenders; schliesslich soll die neue Anwendung den Bedürfnissen dieses Anwenders dienen.

Da ja nicht jedes Teammitglied mit den Anwendern jedes Detail mündlich klären kann, ist es notwendig, die Situation des Nutzers nachvollziehbar zu dokumentieren. Heute haben wir einige Zeit über die begriffliche Abgrenzung der beiden Themenkreise “Use Case” und “User Story” gesprochen. Beide Konzepte leisten wertvolle, jedoch unterschiedliche Dienste in der Softwareentwicklung.

Da die präzise Abgrenzung von Begriffen manchmal sehr wichtig ist, wie die kleine Diskussion gezeigt hat, will ich heute kurz auf die Unterschiede eingehen.

User Stories

Unter User Stories versteht man Informationen, die den Nutzer im Rahmen seiner betrieblichen Aufgabenstellung beschreiben. Dabei streben User Stories an, möglichst kurz und knapp zu sein. Sie folgen der folgenden Syntax

In meiner Eigenschaft als <Rolle> will ich <folgendes Ziel erreichen>, um den <folgenden Gewinn daraus zu ziehen>

Einige typische User Stories für ein tragbares Musikabspielgerät wären:

• Als Musikliebhaber möchte ich, daß meine Musiksammlung eine möglichst hohe Qualität aufweist
• Als Jogger möchte ich viele unterschiedliche Musikstücke mit mir führen, um je nach Laune unterschiedliche Stücke wählen zu können.
• Als vielbeschäftigte Mutter soll das Speichern der Musik möglichst einfach gehen, damit ich nicht zu viel Zeit damit verliere.

Aus solchen User Stories kann man sich während der Entwicklungsphase ableiten, welche Features warum benötigt werden, und wie diese gestaltet werden sollten. Die User Stories werden auf der anderen Seite relativ feingrannular. Insofern fällt es gerade bei größeren Projekten schwer, den Überblick zu wahren.

Use Cases

Use Cases beschreiben was das Softwaresystem leisten soll, und wie die einzelnen Aktoren zusammenwirken, um die Anwendung zu realisieren.

Sie bewegen sich damit sowohl auf einem höheren Level, als auch beschreiben sie das System aus umfassender Sicht. Obwohl Use Cases in einer formalen Sprache geschrieben werden, enthalten Sie keine Sprachelemente, die sich aus der Implementation ergeben. Sie konzentrieren sich vielmehr auf die abstrakte Ebene.

Use Cases behandeln die funktionalen Aspekte der Anwendung, und beschreiben die Geschäftsvorfälle, die sie abdecken. Sie behandeln aber weder Informationen zum Aufbau des User Interfaces, noch sind sie zu speziell.

Normalerweise entwickelt man Use Cases im ersten Ansatz noch sehr grob, und verfeinert sie, je weiter man in seinem Entwicklungsprojekt voranschreitet. Diese Vorgehensweise wird über die formalisierte Sprache unterstützt, die man verwendet, um Use Cases zu erstellen (UML – Unified Modelling Language).

Sowohl Use Cases, als auch User Stories werden genutzt, um das System zu spezifizieren. Sie können aber auch weiterentwickelt werden, um im Rahmen der Qualitätssicherung damit zu prüfen, inwieweit die angestrebten Features entwickelt worden sind.

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 der Wikipedia finden Sie zwei weiterführende Artikel, in denen Sie mehr Informationen über die beiden Konzepte (Use Case und User Story) finden

• →User Story
• →Use Case
• →Unified Modelling Language

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

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

• →Definition of Done
• →Spezifikationen und Testing
• →User Centric Development
• →Creation Spaces

Im Manager Magazin gab es neulich einen ausführlichen, und sehr erhellenden Artikel über das Massachusetts Institute of Technology (MIT) zu lesen. Dieser Artikel passt sehr gut hier her, weil er letztendlich den Nutzen eines offenen Innovationsansatzes beschreibt (siehe → Die Innovationsfabrik).

Der Artikel bietet gleichzeitig einige Anknüpfungspunkte, wie man diesen Innovationsansatz in die innerbetriebliche Praxis übertragen kann. Dies ist meine heutige Fragestellung.

Wie Sie als regelmäßiger Leser meines Blogs bereits wissen, bietet das MIT zudem sehr gute Kursmaterialien online an. In ihrem obigen Artikel erwähnt Eva Müller einige weitere Quellen. Wenn Sie sich das dort erwähnte Onlineangebot des MIT näher ansehen, werden Sie sicher auch bald der Meinung sein: Kurse/ Lehrmaterialien sind nicht das Problem, sondern die Zeit, um sie zu konsumieren.

Open Innovation

In dem erwähnten Artikel finden Sie einige Daten, die belegen, daß das MIT eine sehr große Bedeutung für die Innovationskraft der USA hat, und für die Wirtschaftskraft des Landes. So beschäftigen MIT-Ausgründungen zum Beispiel mehr als 3 Millionen Mitarbeiter.

Die Prinzipien, die hinter diesem Erfolg stehen, muss man sich erst einmal auf der Zunge zergehen lassen (siehe den erwähnten Artikel):

“Interdisziplinarität: MIT-Wissenschaftler arbeiten fachübergreifend an komplexen Herausforderungen.

Offenheit: Sie geben ihre Erkenntnisse gern auch an ein breites Publikum weiter und kooperieren eng mit Industrie und öffentlichen Institutionen.

Unternehmergeist: Forschungsergebnisse für die Gründung einer Firma zu nutzen ist nicht nur erlaubt, sondern hocherwünscht.

Partnerschaft: Die Kommerzialisierung der Ergebnisse wird durch ein Umfeld aus Geldgebern und Beratern beschleunigt.”

Daß hinter der Offenheit des MIT Methode steht, läßt sich u.a. daran erkennen, daß Prof. Hippel erwähnt wird, der quasi als “Mr. Offenheit” gesehen werden kann. Wenn Sie sich erinnern: Ich habe an früherer Stelle über sein Werk “Democratizing Innovation (2005, MIT)” geschrieben – siehe Weiterführende Informationen. Darin geht es um die offene Innovation.

Übertragen in die innerbetriebliche Praxis?

Mit einiger Fantasie lassen sich die Erfolgsfaktoren des MIT gut in die innerbetriebliche Praxis umsetzen. Ich bin überzeugt: zum Nutzen des Unternehmens.

Interdisziplinarität

Gerade in der Softwarentwicklung bringen interdisziplinäre Teams sehr viel. Auf der einen Seite leben gute Entwicklungsprojekte davon, daß sich unterschiedliche Fakultäten gleichzeitig an der Entwicklung beteiligen. Mit den agilen Softwareentwicklungsmethoden ist dieses Prinzip sogar zum Mantra erhoben worden. Auf der anderen Seite bringt es auch viel, wenn das Team nicht zu homogen ist, d.h beispielsweise unterschiedliche Ausbildungsgänge, und Erwerbsbiografien vorliegen.

Das interdisziplinäre Scrumteam setzt sich wie folgt zusammen:

• Im Entwicklungsteam verkörpert der Productowner den Markt, bzw den Kunden. Seine wohl wichtigste Aufgabe ist die Vorklärung des Produktbacklogs. Die Vorklärung muss die Entwicklung möglich machen. Daher sollten “Requirements” gut ausgearbeitet werden, und marktnah sein.
• Innerhalb der Gruppe der Entwickler gibt es normalerweise ebenfalls unterschiedliche Fokussierungen. So arbeiten einige Entwickler eher an der Architektur. Andere haben ihre Stärken eher in der Umsetzung. Auch verwenden die einzelnen Personen unterschiedliche Arbeitsmethoden und Herangehensweisen. Einen besonderen Fokus nehmen die Entwickler für die Dokumentation ein, oder die Entwickler, die sich auf die Usability konzentrieren. Ebenfalls gibt es normalerweise spezialisierte Entwickler, die sich auf die Qualitätsaspekte konzentrieren.
• Scrummaster kümmern sich demgebenüber eher um den Teamzusammenhalt, und um die Organisation des Projektes, d.h. bringen meistens auch einen anderen Blickwinkel in das Team ein.

Offenheit

Offenheit läßt sich auf unterschiedlichen Wegen erreichen. U.a. bedeutet Offenheit zunächst einmal, daß die Mitarbeiter die Informationen erhalten, die sie zum Arbeiten brauchen. Dann kommt aber auch hinzu, daß das Betriebsklima offen gestaltet ist, und Mitarbeiter auf der einen Seite dem Management Feedback geben können, und, daß sie sich gegenseitig unterstützen.

Unabdingbar für Offenheit ist eine Vertrauenskultur, womit sich schon andeutet, daß das Thema Offenheit tief im Unternehmensselbstverständnis verankert sein sollte.

Unternehmergeist und Partnerschaft

Den Unternehmergeist aufrecht zu erhalten ist nicht einfach, insbesondere in großen Firmen. Zunächst einmal ist es hilfreich, wenn die Mitarbeiter ausreichend unspezifischen mit Marktinformationen versorgt werden, um nicht das Gefühl für das Geschäft zu verlieren. Dazu sollte gerade das Produktmanagement auf die kommerzielle Seite eines Entwicklungsprojektes achten.

Auch die Methode des Good Friday ist eine sinnvolle Einrichtung, die Ihre Wirkung beim Unternehmergeist und bei der partnerschaftlichen Vorgehensweise entfaltet. Diese Methode gestattet es den Mitarbeitern, einen gewissen Anteil der Arbeitszeit für “Pet-Projekte” zu verwenden. Da sich Mitarbeiter selbst organisieren, kommt hierbei ihr eigener Unternehmergeist zum Zuge.

Partnerschaft, insbesondere auch im Hinblick auf die finanzielle Beteiligung läßt sich ebenfalls firmenintern organisieren. Man kann zum Beispiel Mitarbeiter finanziell dabei unterstützen, daß sie eigene Geschäftsfelder aufbauen, oder man kann ihnen eine Beteiligung anbieten, sofern sie wichtige Geschäftsideen in die Firma einbringen.

Fazit

Das Beispiel des MIT zeigt, daß es Sinn macht, über eine grundlegende Parameter einer innovativen Firma nachzudenken. Wer noch die alte Schule kennt, die aus Geheimwissen, Kommandostruktur, und Mikromanagement besteht, wird sich wundern, wie weit diese Schule im 21ten Jahrhundert daneben liegt.

Innovation erfordert ein gewisses Klima. Dieses Klima muss tief im Unternehmen verankert sein. Die wichtigsten Parameter sind Offenheit, Unternehmergeist, Partnerschaft und Interdisziplinäre Teams. Diese können sich nur durch eine tiefe Verankerung in der Unternehmens-DNA entfalten.

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:

• →Hören Sie nicht einfach auf Kunden: Fragen Sie Lead Users
• →Open Innovation Plattform OpenIDEO.com
• →Open Innovation – Foren und Quellen

Neulich habe ich mich ein wenig in die Techniken zur Entwicklung von Apps für das iPad der Firma Apple eingelesen. Dabei habe ich mich insbesondere auf den Entwurf des User Interfaces konzentriert, und auf die Methoden, die hierbei zum Einsatz kommen.

Die bei der App-Entwicklung eingesetzten Methoden eignen sich hervorragend, um generell Software zu spezifizieren und zu entwickeln. Daher gehe ich hier auf einige ausgewählte Aspekte meiner kleinen Nachforschung ein.

Use Case

Wer ein Smartphone besitzt, oder ein iPad, der weiß, daß die Bedienung dieser Geräte ganz anders abläuft, als die Bedienung eines PCs. Während man beim PC die Tastatur benutzt, um Eingaben zu machen, oder Programme über Menues steuert, bedient man die obigen Geräte mit dem Finger/der Hand, und macht Eingaben über eine virtuelle Tastatur (so sie unbedingt notwendig sind).

Auch sind die Bildschirme, die zum Einsatz kommen – zumindest bei Smartphones – sehr viel kleiner, als auf dem PC üblich, und die Benutzeroberfläche sehr viel grafischer orientiert.

Die besonderen Eigenschaften der Hardware sorgen für geänderte Nutzungsszenarien, und sie erfordern andere Paradigmen beim Entwurf der Applikation. Generell sind solche Apps sehr viel spezieller und einfacher aufgebaut, als die üblichen Softwareprogramme. Auch ist die grafische Orientierung sehr viel stärker ausgeprägt, und sind die Usability Anforderungen, die die Software bedienen muss, wesentlich ausgeprägter.

Ein weiterer Unterschied ergibt sich aus der Technologie. Apps laufen in einer gegebenen Laufzeitumgebung auf dem mobilen Gerät ab, und sie können aus einer zentralen Bibliothek heruntergeladen und installiert werden. Daher müssen Apps in sehr viel stärkerem Umfang gegebenen Standards entsprechen, als dies bei konventioneller Software der Fall ist.

Um eine App zu entwickeln, benötigt man daher einen Einblick in die Anforderungen, die sich aus der Laufzeitumgebung ergeben. Und man benötigt für die App-Entwicklung Hilfestellungen, um zu einer möglichst einfachen, leicht zu bedienenden Oberfläche zu gelangen.

Guidelines und Tools

Generell gibt die Firma Apple umfangreiche Guidelines und Programmierguides heraus. Ein Beispiel ist die → iOS Developer Library. Darin enthalten ist die Human Interface Guideline, die man unbedingt lesen sollte, bevor man überhaupt mit der Entwicklung im iPad Umfeld anfängt.

In dem Buch → Beginning iPad Development for iPhone Developers: Mastering the iPad SDK (Books for Professionals by Professionals) von Jack Nutting, Dave Woolridge and David , Apress © 2010, habe ich einige weiterführende Quellen zu verschiedenen Teilbereichen gefunden, wie zum Beispiel dem Paper Prototyping, den Digital Mockups, User Interface Icons, oder Design Considerations and Inspirations. Auf einige dieser Referenzen gehe ich nun ein.

Mockups

Mit Mockups bezeichnet man Entwürfe einer Software, die erstellt werden, um die Bedienung zu prüfen. Mockups beinhalten normalerweise keine Ablauflogik, d.h. sind dementsprechend nicht funktionsfähig.

Solche Mockups kann man manuell erstellen, ganz einfach auf Papier. Oder man benutzt eine Software, die dann oft auch eine einfache Ablauflogik unterstützt. In dem obigen Buch findet man u.a. folgende Toolempfehlungen für die Erstellungvon papierbasierten iPad-Mockups:

• → Kapsoft’s iPad Stencil
• → iPad Application Sketch Book by Dean Kaplan

Das Buch empfielt u.a. folgende Softwaretools zur Erstellung von Screenmockups:

• → Endloop’s iMockups
• → Balsamiq Mockups
• → Briefs, a Cocoa Touch framework for live wireframes

Wenn Sie sich auf den Herstellerseiten einmal umsehen, werden Sie schnell erkennen, wie Ihnen Mockups im Entwurfsprozess helfen können, und, wie Sie diese umsetzen. Generell sind sie gut in der Entwurfsphase geeignet, und sie sind besonders sinnvoll einzusetzen, wenn man frühes Kundenfeedback einsammeln möchte.

Den folgenden Artikel aus dem Smashing Magazine kann ich Ihnen empfehlen, wenn für Sie auch kostenfreie → Wire-Frame-Kits, wie man Software zur Erstellung von Mockups auch nennt, in Betracht kommen. In dem Artikel erhalten Sie auch einen Eindruck von papierbasierten Systemen.

iPad UI Design

Ebenfalls aus dem Smashing Magazine stammt der folgende Artikel zum → Entwurf von Apps für das iPad. Dort können Sie sich einen ersten Eindruck über die Designpattern für das iPad verschaffen, oder den Einsatz der einzelnen Screenelemente kennenlernen. Beispiele hierfür sind Kontextmenues, oder die Verwendung von Methaphern aus der realen Welt (Über eine Wischgeste zum Beispiel auf die nächste Seite gelangen).

Weiter oben gibt es einige Hinweise aus dem Produktmanagement zu lesen, insbesondere zum Thema “Personas”:

Defining a target audience is only half of the equation. Now you have to put your audience into action! What do they do in their daily life? How will their daily life intersect with your product? Get into their minds. Try this, and I guarantee it will lead you down some expected and unexpected paths.

Dieses Zitat macht deutlich, daß der Entwurf einer iPad Application natürlich auch Kundenfeedback erfordert, und ein Design, da sich an der Aufgabenstellung des Nutzers orientiert.

Weiterführende Informationen

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

• → Design Thinking Recap
• → User Centric Development
• → Tu es für Marlene – Personas in der Produktentwicklung

Hier können Sie meinen Blog abonnieren, um regelmäßig über neue Artikel benachrichtig zu werden → Mailingliste. Oder, → folgen Sie mir einfach auf Twitter, oder gehen sie auf → meine Facebook-Seite, um regelmäßig Nachrichten zu erhalten.

Heute haben wir über 30 Grad, und die Pflanzen wollen Wasser haben. Daher hier heute nur ein kurzer Hinweis. Und zwar hat Forrester Research eine neue Studie über den Markt für Softwaretools herausgebracht, mit denen man Anforderungen erhebt, verwaltet, und bewertet.

Sie kennen das Problem ganz besonders, wenn Sie Software anbieten, die besonders umfangreich ist. Dann erreichen Sie – getreu dem Motto “der Appetit kommt beim Essen” – relativ schnell viele Verbesserungsvorschläge, Bugbeschreibungen, oder Erweiterungswünsche. Um Ihre (agilen) Teams richtig versorgen zu können, benötigen Sie einige Informationen über die Requirements, und den jeweiligen Use Case.

Hierbei helfen Ihnen solche Requirementstools. In seienm Artikel → The Unrecognized Success Of The Requirements Tool Market bespricht Tom Grant einige davon, und er führt die (kostenpflichtige) Studie ein. Interessant auch, dass er in zukünftigen Blogposts das Gebiet noch weiter ausleuchten will.

Weitere Informationen

In meinem Artikel→ Requirementsmanagement finden Sie weitere Informationen zum Thema.

Hey! Ist der Artikel etwa schon wieder zuende, und Sie wollen noch mehr lesen? Sie sollten meinen Blog abonnieren! → hier können Sie sich in die Mailingliste zu meinem Blog eintragen, oder → folgen Sie mir einfach auf Twitter, oder gehen sie auf → meine neue Facebook-Seite.

Dem aufmerksamen Leser wird nicht entgangen sein, daß sie (ganz neu) auf der rechten Seite der Homepage analoge feststehende Links finden, die diese Linkmöglichkeiten ebenfalls anzeigen.

Heute geht es mir um das Requirements Management, da ich gesehen habe, dass dieses Thema viele Leser interessiert. Zunächst befasse ich mich kurz mit der Frage, was Requirements sind, wie man sie formuliert, und wie man den Requirementsprozess verbessert. Dann werde ich einige Tools einführen, die Unterstützung für den Requirementsprozess bieten.

Requirements

Wie es Wikipedia ausdrückt, versteht man in der Informatik unter dem Begriff der Anforderung, eine Aussage über die zu erfüllende Leistung oder Funktion eines Softwaresystems (siehe Wikipedia → Anforderung (Informatik)). Es gibt mehrere Arten von Anforderungen, wie zum Beispiel die Kann- und die Mußanforderungen (im erstgenannten Fall sollte die Software ein bestimmtes Feature bieten, während es essentiell ist, daß es die Mußanforderungen abdeckt).

Weiterhin lassen sich funktionale Anforderungen von den nicht-funktionalen Anforderungen unterscheiden, wie die folgenden Beispiel zeigen:

• Der Report muss die gespeicherten Datensätze in Form einer Tabelle und einer Grafik ausgeben (Funktional)
• Die Antwortzeit sollte unter 1 Sekunde liegen (Nicht Funktional)

Anforderungen definieren sehr entscheidende Dinge, wie zum Beispiel die Kosten einer Software und deren Leistungsfähigkeit aus Kundensicht. In der betrieblichen Praxis ist es daher wichtig, daß Anforderungen bestimmten Ansprüchen genügen. So sollte sich eine Anforderung auf ein gegebenes (Geschäfts-)problem beziehen, und einen möglichst detaillierten betriebswirtschaftlichen Lösungsweg angeben. Weiterhin sollte eine Anforderung ein konkretes Abnahmekriterium enthalten, das angibt, ab wann eine Anforderung als so implementiert anzusehen ist, dass die die Erwartungen erfüllt.

Gut formulierte Anforderungen genügen daher den folgenden Kriterien:

• Korrektheit (technisch, rechtlich, ethisch,.. möglich und umsetzbar)
• Komplettheit, d.h lückenlos formuliert
• Klarheit (einfach und verständlich, sowie widerspruchsfrei)
• Konsistent (ohne Konflikte zu anderen Anforderungen)
• Nachprüfbar (Messkriterien vorhanden, anhand derer die Systemleistung geprüft werden kann)
• Nachvollziehbar (Verstehbar/ Anforderungsquelle ist definiert)
• Realistisch (und umsetzbar)
• Abgeschlossenheit (Abgegrenzt, und ohne Einfluss auf andere Anforderungen)
• Unabhängigkeit von der Architektur

Letztendlich bilden Anforderungen die Kundenwünsche möglichst präzise ab, d.h sie erfassen die Erwartungen, die Kunden an eine Software stellen. Es ist daher entscheidend, wie man zu den notwendigen Kundeninformationen gelangt, und wie transparent man diese Anforderungen in Endprodukt abbilden kann. Dies ist eine wichtige Aufgabe des Produktmanagements.

Um den Anforderungsprozess möglichst effizient zu gestalten, sollte man als Produktmanager den Prozess in zwei Richtungen professionell gestalten:

• Rollin (d.h die Aufnahme von Kundenwünschen und -problemen)
• Rollout (d.h die Formulierung inclusive der Priorisierung und der Einlastung der Entwicklungen in das Entwicklerteam)

In der folgenden Beschreibung der Firma IBM finden Sie hierzu einige weitere Informationen → Ten steps to better requirements management (IBM)

Tools

Verschiedene Tools helfen im weitesten Sinne beim Requirements Management:

• IBM → Rational DOORS Tool
• Atlassian → JIRA – Issue and Project Tracking
• Ravenflow → Visual Requirements Engineering
• Micro Focus → Caliber – Requirements Definition and Management

Ich persönlich kenne das JIRA Tool, das insbesondere die Agile Softwareentwicklung (siehe → hier) unterstützt. Daneben bietet das Tool auch Funktionen für verwandte Themen, wie für das Bug Tracking (d.h. Nachverfolgung von Fehlern), die Projektverwaltung oder die kollaborative Entwicklung von Software.

In einem der nächsten Artikel werde ich mich genauer mit den Features dieser Tools befassen.

Weitere Informationen

Weitere Informationen zum Thema finden Sie in folgenden Beiträgen

• → Anforderungen müssen konkret formuliert werden
• → Markets or Communities? The Best Ways to Manage Outside Innovation
• → Bewertung von Produktideen
• → Concept Prototyping (Teil 2) Konzepterstellung und -bewertung
• → Concept Prototyping

Hey! Sie haben den Artikel ganz bis zum Ende gelesen. Sie sollten meinen Blog abonnieren! Tragen Sie sich → hier in den Mailverteiler ein, oder bookmarken Sie diesen Artikel über die unten angegebenen Links.

Wie in der Fachliteratur zu lesen ist, gehört das richtige Anforderungsmanagement zu einem der wichtigsten Einflussgrößen für den Projekterfolg. So gehen konservative Schätzungen davon aus, dass circa 30 – 50% des Entwicklungsaufwandes für Fehlerbehebung, Nacharbeiten, oder andere Aktivitäten aufgewendet wird, die nicht wertschöpfend sind.

Hier ein 10 Punkteprogramm, das dazu dient, um diese Kostentreiber und Wertevernichter einzugrenzen:

1. Anforderungen klären und klar/eindeutig formulieren: Sorgen Sie dafür, dass Anforderungen schriftlich fixiert werden, und mit Kunden geklärt sind, bevor Sie sie verwenden. Nur so, kann man die notwendige verlässliche Basis und Eindeutigkeit der Anforderungen sicherstellen.
2. Änderungsmanagement: Es ist normal, dass sich Anforderungen im Laufe des Entwicklungsprojektes ändern. Um diese Änderungen sinnvoll verarbeiten zu können, ohne davon überrannt zu werden, ist es wichtig, die Änderungsdynamik zu managen.
3. Für eine stabile Basis sorgen: Viele Produkte werden nach ihrer Auslieferung für eine längere Zeit gewartet, und an neue Kundenanforderungen angepasst, bzw erweitert. Deshalb ist es entscheidend für die Produktstabilität in späteren Phasen des Produktlebenszyklus, dass bereits die Ursprungsentwicklung eine breite und stabile technologische Basis bildet.
4. Eindeutige Rollen schaffen: In der Praxis ist es häufig zu beobachten, dass verschiedenen Projektrollen nicht klar gegeneinander abgegrenzt sind. Zum Beispiel übernimmt der Projektmanager die Rolle des Produktmanagers, oder der Produktmanager nimmt auch Aufgaben im Vertrieb wahr. Ein dezidiertes Anforderungsmanagement benötigt viel Know How. Es ist entscheidend für den Projekterfolg, geschulte Produktmanager mit der Anforderungsanalyse zu betreuen.
5. Erwartungen managen: Jeder kennt sie, die unterschiedlichen Wahrnehmungen der Kunden, denen die Realitäten und Machbarkeiten gegenüberstehen. Dies kann schnell dazu führen, dass Kunden mehr oder anderer Projektergebnisse erwarten, als sie final geliefert werden. Um dies zu verhindern, sollten Sie durch eine geschickte Kommunikation und Einbeziehung sicherstellen, dass Kunden rechtzeitig die notwendigen Informationen erhalten, um die späteren Projektergebnisse abschätzen zu können. Neben den Erwartungen muss man übrigens auch oft die Kunden managen.
6. Zu aggressive Planungen vermeiden: In vielen Projekten werden die Kapazitäten überschätzt, bzw die Menge/Größe der Anforderungen unterschätzt. Dies führt dann oft zu Situationen, in denen das Projekt zu aggressive Meilensteine setzt. Da hierunter nicht nur die Qualität leidet, sondern die Zufriedenheit der Mitarbeiter, sollten zu aggressive Planungen vermieden werden.
7. Lieferanten einbeziehen und Aufträge kontrollieren: Oft werden Lieferanten und Dienstleister nicht eng genug in das Projekt, bzw in den Informationsfluss innerhalb des Projektes einbezogen. Dies kann dazu führen, dass sie an Themen arbeiten, die später nicht zum Gesamtprojekt passen. Daher ist es wichtig, mit Partnern ein gutes Vertrauensverhältnis aufzubauen.
8. Planen und Managen, aber sauber: Viele Projekte sind schlecht administriert. Dies kann dazu führen, dass Anforderungen untergehen, oder vergessen werden. Auch ist es möglich, dass mit Projektannahmen gearbeitet wird, die bereits überholt sind. Erfahrene Projektmanager prüfen daher regelmäßig Projektumfang, – prämissen und -status.
9. Aufwände sorgfältig planen: Die Einschätzung, welcher Arbeitsbedarf mit der Umsetzung einer Anforderung verbunden ist, ist nicht trivial. Daher lauert hier eine Quelle für die schon erwähnten aggressiven Planungen. Zum Einschätzen von Aufwänden stehen verschiedene Verfahren zur Verfügung, wie z.B. der Anforderungspoker, den ich an früherer Stelle schon einmal erwähnt habe. Um zu verlässlichen Zahlen zu gelangen ist zudem eine gewisse Sorgfalt in der Beschreibung der Anforderungen notwendig.
10. Kunden managen: Speziell wenn Kunden in Projekten mitarbeiten, kann es geschehen, dass unterschiedliche Welten aufeinanderprallen. Auch kommt es häufig vor, dass Kunden Anforderungen stellen, die bei näherem Hinsehen organisatorische Unzulänglichkeiten abbilden. In solchen Fällen sollten die Kunden gemanaged werden, um negative Einflüsse auf den Projektverlauf auszuschliessen.

Heute ist mir mal wieder klargeworden, wie wichtig klar formulierte Anforderungen sind, um eine passende Software entwickeln zu können. Was war passiert?  Jemand hat versucht mich zu kontaktieren, und hat meine private Mailaddresse verwendet, die im Impressum einer meiner Websites aufgeführt ist. Da ich einige Tage im Urlaub war, hat dies dazu geführt, dass ich diese Mail erst heute beantworten konnte. Für solche Fälle hatte ich aber extra einen generischen Mailuser eingerichtet. Die Mails, die dort ankommen, können von meinen Urlaubsvertretern gelesen werden. Meine Site war jedoch missverständlich aufgebaut.

Formulierungshinweise für griffige Anforderungen

Software Requirements Specifications sind im IEEE Standard 830 erstmalig definiert worden. In dieser Norm kann man die Anforderungen nachlesen, die an Anforderungen, bzw Spezifikationen generell zu stellen sind (siehe z.B. in Wikipedia → Software Requirements Specification). Dort werden Requirements, bzw Anforderungen wie folgt definiert:

“Mit Requirements (deutsch: Anforderungen) ist sowohl die qualitative als auch die quantitative Definition eines benötigten Programms aus der Sicht des Auftraggebers gemeint. Im Idealfall umfasst eine solche Spezifikation ausführliche Beschreibung von Zweck, geplantem Einsatz in der Praxis sowie dem geforderten Funktionsumfang einer Software. Hierbei sollte fachlichen – „Was soll die Software können?“ – wie auch technischen Aspekten – „In welchem Umfang und unter welchen Bedingungen wird die Software eingesetzt werden?“ – Rechnung getragen werden.” – siehe Wikipedia

Generell ist es wichtig, dass man die Anforderungen eindeutig und nachprüfbar formuliert. Eine zu vage Formulierung erkennt man oft dran, dass man bereits Schwierigkeiten damit hat, Testfälle zu formulieren. Hier ein Beispiel für eine zu vage Formulierung und den passenden Testfall: “Der Geldautomat soll nach Eingabe von Karte und Daten unverzüglich Geld ausgeben” (Anforderung) “Der Kunde führt eine Gesundheitskarte ein, und tippt 4 Ziffern. Geld wird ausgeworfen.” (Testfall).

Die folgenden Beispiel zeigen sinnvollere Formulierungen:

• Grundanforderungen an das Produkt formuliert man konkret wie “Bei clicken des Buttons “Hilfe” wird die Software ein Hilfefenster mit Informationen anzeigen”
• Funktionale Anforderungen mit Schnittstelle als beispielsweise “Die Software stellt synchron die Eingabedaten für den Folgeprozess zur Verfügung.”
• Funktionale Anforderungen mit Schnittstelle/Einschränkung als zum Beispiel “Die Software stellt synchron die Eingabedaten für den Folgeprozess zur Verfügung, nachdem der Nutzer “Ok” gedrückt hat”
• Nichtfunktionale Anforderungen mit Schnittstelle/Einschränkung: “Die Software soll innerhalb von 10 Sekunden auf die Eingabe des Nutzers reagieren”
• Nichtfunktionale Prozessanforderungen mit Einschränkung: “Der Administrator soll die fehlerfreie Datei innerhalb der nächsten Stunde transportieren”
• Nichtfunktionale Prozessanforderungen: “Die Dokumentation soll zum Projektende in Deutsch und Englisch vorliegen”
• Nichtfunktionale Prozessanforderungen mit Projektrandbedingungen: Das verantwortliche Scrum Team wird aus einem Produktowner, einem Scrum Owner, 7 Entwicklern, und einem Qualityexperten bestehen”