Veröffentlicht am

Ist die Verwendung von Persona das Gegenteil von Mass Customization?

Gerade im Agilen Projektmanagement werden Anforderungen häufig für Persona formuliert. Diese sind nach dem IREB (International Requirements Engineering Board) fiktive Charaktere, mit deren Hilfe Werte für die User geschaffen werden sollen. Dieses Vorgehen erinnert an eine Art Segmentierung aus dem traditionellen Marketing.

Mass Customization auf der anderen Seite ist eine hybride Wettbewerbsstrategie, die individuelle Produkte und Dienstleistungen für jeden Abnehmer – also massenhaft – anbietet, bei Preisen, die denen der massenhaft produzierten Standardprodukten ähneln. Dabei ist der Konfigurator ein wichtiges Element, das passende Produkt in einem Fixed Solution Space (Definierter Lösungsraum) zu erstellen. Die dahinterliegende Idee eines “Market of One” passt nicht so recht mit der Persona-Idee zusammen. Dazu habe ich folgendes gefunden:

“In many ways, a persona is the opposite of mass customization. It’s more traditional marketing thinking about how to deal with a larger number of segments. A “persona of one” is turning the persona idea to its opposite” Piller, Frank T. and Euchner, James, Mass Customization in the Age of AI (June 07, 2024). Research-Technology Management, volume 67, issue 4, 2024 [10.1080/08956308.2024.2350919], Available at SSRN: https://ssrn.com/abstract=4887846.

In Zeiten von Künstlicher Intelligenz wird es immer mehr Möglichkeiten geben, Produkte und Dienstleistungen massenhaft zu individualisieren und zu personalisieren. Ob die Verwendung von Persona in solchen eher agil durchzuführenden Projekten dann noch angemessen ist, scheint fraglich zu sein. Siehe dazu auch 

Society 5.0 und Mass Customization

Freund, R. (2009): Kundenindividuelle Massenproduktion (Mass Customization). RKW Kompetenzzentrum, Faktenblatt 5/2009.

Wir sind dabei: 20 Jahre MCP-CE vom 24.-27.09.2024

Veröffentlicht am

Agiles Projektmanagement: Die Falle bei den Anforderungen

Gerade im agilen Umfeld geht es oft um den Begriff “Value”. Beim Agilen Projektmanagement, beispielsweise nach Scrum, werden die Anforderungen oft als User Stories aus der Perspektive fiktiver Charaktere (Persona) formuliert. Dabei kann es vorkommen, dass dabei nicht nur User, sondern auch weitere Stakeholder beachtet werden sollen. Das kann wiederum dazu führen, dass das Projekt mehr in Richtung des Wertes für interne Stakeholder “abdriftet”.

“Bei der agilen Herangehensweise an die Softwareentwicklung liegt das Hauptaugenmerk auf der Werthaltigkeit, welche die Lösung den Benutzern bieten soll („User Story“). Daher wird der Benutzer eines interaktiven Systems als primärer Stakeholder betrachtet. Dennoch besteht, vor allem in großen Organisationen, das Risiko, dass agile Teams oder Product Owner nicht mit den echten Nutzern in Kontakt sind. Die Personas werden hier möglicherweise von jemandem erdacht, der nur vorgibt, die Benutzer zu kennen! In einem solchen Kontext sind die Stakeholder der Organisation (Manager, Fachbereiche, Rechtsabteilungen, Marketing usw.) wesentlich präsenter und dominanter als der externe Endbenutzer. Seien Sie sich über diese Falle im Klaren: Bestehen Sie darauf, dass ein direkter Zugang zu Endbenutzern besteht, um eine angemessene Nutzerforschung durchführen und nach der Sprint-Lieferung direktes Feedback einholen zu können. Nur so können Sie Ihre Benutzer und deren Bedürfnisse wirklich kennenlernen” (Brand et al. 2024).

Siehe dazu auch

Agiles Projektmanagement: Anforderungen auf verschiedenen Granularitätsebenen

Agiles Projektmanagement: Was zeichnet ein gutes Product Backlog aus, und wie kann man es steuern?

Solche Zusammenhänge thematisieren wir auch in den von uns entwickelten Blended Learning Lehrgängen Projektmanager/in (IHK) und Projektmanager/in AGIL (IHK). Informationen dazu, und zu aktuellen Terminen, finden Sie auf unserer Lernplattform.

Veröffentlicht am

Planning Poker beim relativen Schätzen nutzen – analog oder auch online

In dem von uns entwickelten Blended Learning Lehrgang Projektmanager/in Agil (IHK) geht es selbstverständlich auch um das Scrum-Framework. Um dabei ein priorisiertes Backlog mit den Anforderungen zu erhalten, werden u.a. aus der Perspektive von fiktiven Charakteren (Personas) User Stories formuliert.

Diese werden dann relativ (nicht absolut) geschätzt. Relativ bedeutet hier, dass eine User Story als Referenz festgelegt wird.

Mit Hilfe der modifizierten Fibonacci-Reihe schätzen die Developer den jeweiligen Aufwand der verschiedenen User Stories ab, die für den nächsten Sprint vorgesehen sind – das geschieht im Sprint Planning in Abstimmung mit dem Product Owner und dem Scrum Master, bzw. auch mit anderen Stakeholdern.

Dieses Schätzen kann mit Planning Poker unterstützt werden. Wir haben uns dazu ein Kartenspiel mit unserem Logo herstellen lassen (siehe Abbildung). Der Aufwand der einzelnen User Stories kann dann mit Hilfe des Kartenspiels ermittelt werden. Darüber hinaus kann Planning Poker auf dieser Seite auch online gespielt werden.

Solche Zusammenhänge thematisieren wir auch in den von uns entwickelten Blended Learning Lehrgängen, die wir an verschiedenen Standorten anbieten. Informationen zu unseren Blended Learning Lehrgängen und zu aktuellen Terminen finden Sie auf unserer Lernplattform.