Priorisieren und Auswählen von Ideen
Als ProduktownerIn oder ProduktmanagerIn ist man normalerweise für eine lange Liste von Ideen und Anforderungen verantwortlich. Um damit sinnvoll umzugehen, und gute Produkte zu entwickeln, muß man wissen, wie man gute Ideen nach Prioritäten ordnet.
Big Data Visualisierung – Ein offener Framework von Uber
Die Firma Uber wird zwar in Europa als Taxiunternehmen, und nicht als die Visualisierungsfirma eingestuft, die sie gerne sein würde, trotzdem hat sie eine Visualisierungslösung veröffentlicht, die sehr gut aussieht.
Diese Bibliothek schaue ich mir heute kurz an.
Big Data und Daten Journalismus
Daten werden nicht nur in den Unternehmen immer wichtiger, sondern auch im Bereich des Journalismus. Ein Google Newsletter gibt einen guten Überblick – und zeigt auch die Sorgen und Nöte der Journalisten mit der Digitalisierung auf.
Diese sind übrigens ganz ähnlich wie die in den Betrieben.
Big Data Rollen und Teams
Universalgenies sind selten, auch im Bereich der Analytics. Die Entwicklung von Big Data Anwendungen, oder auch Machine Learning Projekte erfordern Mitarbeiterteams, die unterschiedliche Rollen ausfüllen.
Big Data Anwendungen entwickeln und testen
Intelligente Software und Big Data Anwendungen folgen anderen Paradigmen als „normale“ Softwareanwendungen. Daher erfordert ihre Entwicklung eine besondere Vorgehensweise insbesondere im Bereich der Qualitätssicherung.
Qualität – Codequalität, Debuggingfähigkeit und Infrastruktur
Parameter wie die Codequalität, Debuggingfähigkeit oder die Build-Infrastruktur entscheiden bei großen Projekten letztendlich, wie einfach es ist, die Software zu warten und zu erweitern. Aber auch die Analytics spielt eine wichtige Rolle.
Qualität – Ein entscheidender Wettbewerbsfaktor
Neben den Features einer Software und dem Design der Benutzeroberfläche hat die Qualität aus der Nutzersicht eine besonders hohe Bedeutung.
Eigentlich galt ein hoher Qualitätsanspruch schon immer. Aber heutzutage ist die Qualität vielleicht noch wichtiger geworden, da viele Nutzer über ihre mobilen Devices eigenes technisches Know How besitzen, und damit einen eigenen Anspruch an ihre Software.
Enterprise 2.0: Cloud-Kollaboration in der Praxis
Der heutige Artikel stammt aus der Feder von Claudia Ketzer, und handelt von den Möglichkeiten und dem Nutzen, Arbeits- und Geschäftsprozesse kollaborativ zu gestalten.
Frau Ketzer verantwortet das Marketing bei der Firma →Comindware GmbH, die sich mit Themen wie der adaptiven Geschäftsprozessverwaltung oder Workflow-Automatisierung beschäftigt
Agile Entwicklungsmodelle zur Abwicklung komplexer Projekte
In ihrem Artikel „Achieving success in large, complex software projects“ schreiben McKinsey über die Besonderheiten komplexer Entwicklungsprojekte. In einem der Schaubilder kann man sehr gut erkennen, welchen eigentlichen Vorteil die agile Entwicklungsmethode bietet.
Usability und Komplexität – Tipps zur Fortbildung
Zwei Online-Schulungen der Stanford University befassen sich mit verwandten Themen, die dabei helfen, gebrauchsfähige Software zu entwickeln.
In der einen Vorlesung geht es um das Thema „Wahrnehmungspsychologie“, also die Frage, wie die Biologie des Wahrnehmens beim Menschen funktioniert, und welche Anforderungen sich daraus an Software ableiten lassen.
Der zweite Vortrag befasst sich mit der Komplexität von technischen Systemen, und räumt u.a. mit dem Mythos auf, dass Nutzer immer die einfache Lösung suchen.
Entwurfsmethodiken – Minimum Viable Scope
Die Akzeptanz einer Software lebt unter anderem davon, daß sie sich agil weiterentwickelt, und, daß sie die Aufgaben erledigt, die sie erledigen soll.
Konzepte wie der „Minimum Viable Scope“ helfen dem Entwicklungsteam dabei, genau die Anforderungen zu finden, die dem späteren Anwender der Software wichtig sind. Und man kann mit diesem Konzept auch entscheiden, welches Feature man nicht entwickelt – um so ggfs schneller am Markt sein zu können.
Entwurfsmethodiken zum „Rapid Prototyping“ – Der Designsprint
„Google Ventures“ haben eine längere Artikelserie zu einer sehr flexiblen Entwicklungsmethodik herausgebracht, die wie die agile Entwurfsmethodik in der Softwareentwicklung funktioniert – angewandt auf ein Projekt.
Bekanntermaßen sind lange, unflexible Entwicklungszyklen hier ja eher nachteilig, alleine schon, weil man am Anfang der Entwurfsarbeit oft nicht weiß, was am Ende herauskommen soll, und man daher auf Iterationen angewiesen ist. Der Autor bespricht relativ detailliert eine Vorgehensweise, die man anwenden kann, um relativ schnell und iterativ gute Produkte zu entwickeln.
Management-Knowhow für (zukünftige) Produktmanager
Neulich hat mich die Fachhochschule Schmalkalden angesprochen, und mich gefragt, ob ich nicht ihren Studiengang „Produktmanagement“ hier vorstellen könnte. Da gelegentlich auch Schüler hier vorbeikommen, die gerade vor der Berufswahl stehen, halte ich einen solchen Artikel für keine schlechte Idee.
Teile des Artikels hier stammen aus der Lehrgangsbeschreibung, die mir die FH gegeben hat. Am Ende des Artikels gehe ich kurz auf meine eigenen Erfahrungen ein, die ich vor einigen Jahren hierzu schon einmal in einer Artikelserie zum Thema „Aus-, Fort- und Weiterbildung“ zusammengefasst hatte.
Walking Skeleton – Das laufende Skelett
IJetzt wird es gruselig – könnte man meinen. Stimmt aber nicht, wie Sie gleich sehen werden.
In der Praxis können Produktbacklogs schnell sehr groß werden. Hinzu kommt, daß sich Wünsche an das Produkt häufig ändern. Um mit den Anforderungen umzugehen, die sich daraus ergeben, benötigen sowohl das Entwicklungsteam als auch der Produktowner Methoden, die ihnen dabei helfen, den Produktbacklog zu strukturieren, und die Software iterativ zu erweitern.
Das Konzept des „Walking Skeleton“ zusammen mit den Ansätzen rund um das Thema „Specification by Example“ helfen hierbei.
Weniger Features sind oft mehr
In einem typischen Softwareprodukt werden viele Funktionen kaum benutzt. Ein Produkt mit weniger Features zu haben, wäre hier von Vorteil, sowohl was die Komplexität betrifft, als auch die Wartung der Software, und die Kosten.
Heute geht’s um des „minimal viable scope“ eines Produktes, als eine Möglichkeit, genau das zu entwickeln, was für den Markterfolg notwendig ist (und nicht mehr).
Specification by Example
In marktorientierten Entwicklungsprojekten ist es notwendig, daß das Entwicklungsteam und die einzelnen Stakeholder eine gemeinsame Sprache sprechen.
Nur diese gemeinsame Sprache gewährleistet, daß man auch sicher sein kann, daß alle Beteiligten von den gleichen Anforderungen sprechen, und, daß man allerseits dieselbe Auffassung vom funktionalen Umfang der späteren Software hat.
Die Methode der Specification by Example, die zum Beispiel von Gojko Adzic vertreten wird, leistet genau das.
Unterschiedliche Innovationsmodelle und die Tendenz zur offenen Innovation
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.
Qualität, Features und Termindruck
Wahrscheinlich ist die Entscheidung für jeden Produktowner ein Klassiker: Worauf den Schwerpunkt legen – Features oder Qualität? Oft steckt hinter der Frage jedoch mehr.
Termindruck kommt in der Praxis oft durch Faktoren zustande, die ein einzelner Produktowner nur schwer beeinflussen kann, wie zum Beispiel das Ziel der gesamten Firma, möglichst oft ein komplettes Release abzuliefern, das dann noch möglichst viele neue Funktionen enthalten soll.
Requirement versus Specification
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.
Fokussieren eines Scrum Teams
Ich denke mal, daß es häufiger vorkommt, daß ein Scrum Team nicht für ein komplettes Produkt verantwortlich ist, sondern Teilbereiche der gesamten Funktionalität verantwortet. Auch ist es sicherlich nicht unnormal, daß ein Team mehr als einen Stakeholder unterstützen muss oder komplexe Technologien verwendet, oder Funktionalitäten in unterschiedlichen Releases unterstützt.
Unter solchen Rahmenbedingungen stellt sich die Frage, was der Produktowner tun kann, damit ein Team nicht in mehrere Teilgruppen zerfällt die dann auch noch unterschiedlich spezialisiert sind.
Feature versus Qualität
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….
User Stories und Use Cases
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.
Die Produktvision und die Rolle des Produktowners
Wie Roman Pichler von der Scrum Alliance in seinem Artikel The Product Vision sagt, benötigt jedes Scrum Team eine Produktvision, die dem Team das Ziel vorgibt und die Richtung, um dorthin zu gelangen. Die Produktvision hilft zudem, das Scrum Team inhaltlich zu lenken.
Die Produktversion beschäftigt viele Produktowner. Daher geht es heute um die Frage, wie Sie zu Ihrer Produktvision kommen.
Exploratory Testing – Weitere Testtouren
Da letztendlich der Productowner zusammen mit dem Entwicklungsteam für die Qualität verantwortlich ist, gehören ja auch qualitätsbezogene Aktivitäten zum Scope der Aktivitäten. In dem ersten Artikel zur Serie über die Methode des exploratorativen Testens bin ich bereits auf die Testmethode selbst, und die Anwendungsgebiete eingegangen.
Heute geht es um die Testtouren, für die im ersten Artikel zu dieser Serie der Raum nicht mehr gereicht hat.
Ich arbeite seit vielen Jahren in der Softwareentwicklung für Unternehmensanwendungen bei der SAP SE. Dieser Blog ist privat, und die Meinungen sind meine eigenen. Sie sind hier richtig, wenn sie sich für Praxiserfahrungen im Produktmanagement für Investitionsgüter interessieren. 