Rollenpakete fuer Daily Ops
Praxispakete fuer den Tagesbetrieb: Wer macht was bei Kunden- und Projektarbeit, welche Gates greifen, welche Belege sind Pflicht und wann ist sofort BLOCK.
1. Zielbild
Rollenpakete sind keine neuen Hierarchien, sondern wiederverwendbare Kombinationen aus Role + Skill + Boundary + Review Gate. Sie helfen dir, taegliche Admin- und Delivery-Arbeit konsistent auszufuehren.
P-ROLE-001..005
P-BOUND
P-TXN
P-REVW
fail-closed
2. Kern-Rollenpakete
Customer Owner
- Verantwortet Kundenkontext (public/private), Boundary-Entscheidungen und finale Freigaben.
- Darf Visibility-Aenderungen anstossen, aber nicht ohne Review durchfuehren.
- Muss Legal/Vertrags-Auswirkungen markieren.
Delivery Lead
- Steuert Projektfluss (Story, Plan, Milestones, Escalations).
- Koordiniert Contributor + Reviewer und haelt TX-Disziplin.
- Sichert evidenzbasierte Fortschritts-Entscheidungen.
Reviewer
- Unabhaengiger Qualitaets- und Risikocheck fuer Kunden/Projekt-Aenderungen.
- Keine Selbstfreigabe fuer eigene Artefakte.
- Kann BLOCK/ESCALATE aussprechen, muss rationale dokumentieren.
Billing / Legal
- Prueft Vertrags-, Abrechnungs- und Lizenzfolgen.
- Gate-Pflicht bei riskanten Vertrags- oder IP-relevanten Aenderungen.
- Sichert revisionsfeste Record-Qualitaet fuer Compliance.
3. Rechte und Grenzen je Rollenpaket
| Rollenpaket | Darf | Darf nicht | Pflicht-Gates |
|---|---|---|---|
| Customer Owner | Kunden-State aendern, Visibility beantragen, Priorisierung festlegen | Selbst Review-Gate fuer eigene kritische Aenderung abschliessen | RG-004 bei Go/No-Go, RG-003 bei Cross-Org-Federation |
| Delivery Lead | Plan/Milestones setzen, Work dispatchen, Escalations ausloesen | Boundary-Bypass und unlogged State-Spruenge | RG-005 (warn), RG-004 bei Produktivfreigaben |
| Reviewer | GO/BLOCK/ESCALATE mit Evidenzbezug | Eigene Artefakte final freigeben | Alle blocking gates als Pruefinstanz |
| Billing / Legal | Contract/IP/License Risikofaelle freigeben oder stoppen | Technische Umsetzung ohne Delivery-Kontextentscheidung | RG-007 bei Theme/IP, RG-001 bei Profilupgrade mit Vertragsfolgen |
4. Tagesablauf mit Rollenpaketen
1. Intake: Delivery Lead klassifiziert Aenderung (customer/project/contract/theme).
2. Boundary: Customer Owner bestaetigt public/private Scope.
3. Review: Reviewer prueft Premises, Skill-Coverage, Gate-Bedarf.
4. Spezialfall: Billing/Legal prueft Vertrags-/IP-Auswirkungen.
5. Entscheidung: GO/BLOCK/ESCALATE + Transaction + Evidence.
6. Abschluss: State wechseln, Revision/Audit aktualisieren.
5. Checklisten je Rollenpaket
Customer Owner
- Ist Kunde korrekt als
publicoderprivateklassifiziert? - Sind Boundary-Typ und Zugriffsregeln dokumentiert?
- Ist bei Sichtbarkeitswechsel ein Review geplant?
Delivery Lead
- Existieren Story, Plan und klare Milestones?
- Sind Rollen und Skills fuer alle aktiven Work Items zugeordnet?
- Wird jeder State-Wechsel als TX geloggt?
Reviewer
- Liegt ein Interessenkonflikt vor (Author=Reviewer)?
- Sind Pflicht-Gates korrekt angewandt?
- Ist die Evidenz reproduzierbar und frisch (TTL)?
Billing / Legal
- Gibt es Vertrags-, Lizenz- oder IP-Auswirkungen?
- Sind erforderliche Artefakte fuer RG-007/RG-001 vorhanden?
- Ist die Entscheidung als Record revisionsfest archiviert?
6. Fail-Closed Trigger
| Trigger | Reaktion | Zustaendig |
|---|---|---|
| Kein benannter Owner bei Kundenaenderung | BLOCK | Delivery Lead |
| Reviewer ist zugleich Autor des Artefakts | BLOCK + Re-Assign | Customer Owner |
| IP-relevante Theme-Nutzung ohne RG-007 Evidence | BLOCK | Billing/Legal |
| Cross-Org Federationschritt ohne RG-003 | BLOCK | Reviewer |
| State-Wechsel ohne TX | BLOCK + Nacherfassung | Delivery Lead |
7. Minimal-Template fuer Rollenpaket-Zuordnung
operation_id: op-customer-visibility-change
customer_ref: customer-acme
project_ref: project-acme-rollout
role_package:
customer_owner: human-owner-01
delivery_lead: human-delivery-02
reviewer: human-review-05
billing_legal: human-legal-03
required_gates:
- RG-004
- RG-007
state_transition:
from: private
to: public
transaction_required: true