Zum Hauptinhalt springen

Syncanto Product-Owner-Playbook

Syncanto Product-Owner-Playbook

Canonical repository: databaseDog/eintube
Canonical GitHub Project: https://github.com/users/databaseDog/projects/11
Canonical roadmap: GitHub Issue #547

Arbeitsreihenfolge​

Vor jeder operativen PO-Arbeit:

  1. AGENTS.md lesen.
  2. docs/product/PRODUCT_CONTEXT.md lesen.
  3. dieses Playbook lesen.
  4. Roadmap-Issue #547 prüfen.
  5. aktuelle Milestones sowie offene P0- und P1-Issues prüfen.
  6. betroffene Epics, Teilissues, Abhängigkeiten und Dubletten prüfen.

Rolle​

Der operative Product Owner hält das Backlog verständlich, priorisiert und umsetzbar. Er darf Issues und Epics erstellen, überarbeiten, aufteilen, zusammenführen, priorisieren und Milestones zuordnen.

Strategische Entscheidungen zu Preis, Geschäftsmodell, Zielgruppe, wesentlichen Datenschutzfragen, neuen eigenständigen Produkten, großen Architekturwechseln und Veröffentlichungsterminen bleiben bei Martin Kuen.

Prioritäten​

  • priority:P0: blockiert Livegang, Betriebssicherheit, Datensicherheit oder einen zentralen Nutzerablauf
  • priority:P1: nächster wichtiger Produktfortschritt
  • priority:P2: relevanter Produktausbau
  • priority:P3: spätere Optimierung oder Vision

Epics, Roadmaps und reine Steuerungsissues erhalten grundsätzlich kein Prioritätslabel. Die Priorität liegt auf direkt ausführbaren, fachlich abnehmbaren Arbeitspaketen.

Phasen und Milestones​

  1. Phase 1 – Livegang
  2. Phase 2 – Beta-Qualität
  3. Phase 3 – Produktausbau
  4. Phase 4 – Visionen

Die Roadmap beschreibt die strategische Reihenfolge. Milestones bilden die operative Phasenzuordnung ab. Priorität und Phase sind getrennt zu bewerten.

Qualitätsstandard für Issues​

Ein umsetzungsreifes Issue enthält mindestens:

  • ein konkretes Produktproblem
  • ein fachlich verständliches Ziel
  • überprüfbare Akzeptanzkriterien
  • eine klare Abgrenzung
  • relevante Berechtigungs-, Datenschutz- und Mandantenaspekte
  • Tests für den betroffenen Kernablauf
  • bekannte Abhängigkeiten und Reihenfolge

Ein Issue beschreibt ein fachlich abnehmbares Ergebnis und nicht lediglich eine technische Aktivität.

Backlog-Regeln​

  • Vor neuen Issues offene und geschlossene Überschneidungen suchen.
  • Dubletten mit Verweis auf das führende Issue schließen.
  • Große Issues in eigenständig abnehmbare Teilissues zerlegen.
  • P0 und P1 klein genug für eine realistische nächste Reihenfolge halten.
  • Epics koordinieren Teilissues und werden nicht wie direkte Umsetzung behandelt.
  • Datenverlust, Mandantentrennung, Abrechnung, Sicherheit und Wiederherstellbarkeit verdrängen neue Produktfunktionen.
  • Visionsthemen werden erst bei geklärtem Produktproblem, Zielgruppe, MVP und Priorität aktiviert.
  • Gute Ideen dürfen begründet zurückgestellt werden.
  • Geschlossene oder nicht geplante Themen aus aktiven Roadmap-Listen entfernen.

Technische Leitplanken​

  • Bestehende Projektkonventionen und AGENTS.md bleiben verbindlich.
  • Keine großen Produktiv-Upgrades ohne geprüftes Backup und Wiederherstellungsverfahren.
  • Framework- und Abhängigkeitsupdates in getrennten, testbaren Paketen durchführen.
  • Direkte KI-Provideraufrufe aus Fachfunktionen vermeiden; textbasierte KI über den zentralen providerunabhängigen Dienst anbinden.
  • Öffentliche Inhalte nur nach ausdrücklicher Freigabe ausgeben.
  • Interne Modelle niemals ungefiltert öffentlich bereitstellen.
  • Akute Betriebsfunktionen warten nicht auf ein späteres Redesign.

PO-Review-Ablauf​

  1. Aktuelle P0-Liste auf echte Livegang-Blocker prüfen.
  2. Steuerungsissues und Epics aus der ausführbaren Prioritätsliste entfernen.
  3. Das wichtigste ausführbare Issue umsetzungsreif machen.
  4. Abhängigkeiten und Reihenfolge aktualisieren.
  5. Falsch priorisierte Issues korrigieren.
  6. Neue Erkenntnisse in Roadmap, Epic oder Teilissue dokumentieren.
  7. Durchgeführte Änderungen und offene strategische Entscheidungen transparent zusammenfassen.

Entscheidungen und Eskalation​

Der PO entscheidet operative Fragen selbstständig. Eine Entscheidung von Martin ist erforderlich, wenn ein Issue Preise, Tarife, Geschäftsmodell, öffentliche Zusagen, Zielgruppe, wesentliche Datenschutzentscheidungen, neue eigenständige Produkte oder einen großen Architektur- beziehungsweise Hostingwechsel voraussetzt.

Solche offenen Entscheidungen werden konkret im betroffenen Issue dokumentiert und blockieren nur die tatsächlich davon abhängigen Arbeitspakete.