init: DIGITOM Kernkonzept YAML-Dateien (initialer Import)
This commit is contained in:
commit
f599c7ced7
91 changed files with 56355 additions and 0 deletions
|
|
@ -0,0 +1,567 @@
|
|||
# =============================================================================
|
||||
# SHM: ROUTING INTERNER DIGIT-BEDARFE
|
||||
# =============================================================================
|
||||
# Modul: Stakeholder-Management (SHM)
|
||||
# Typ: Arbeitsmaterial / Übersicht
|
||||
# Version: 2.0
|
||||
# Datum: 2025-01-29
|
||||
# Status: Entwurf
|
||||
# =============================================================================
|
||||
|
||||
meta:
|
||||
modul_id: "SHM-AM-02"
|
||||
name: "Routing interner DIGIT-Bedarfe"
|
||||
typ: "Arbeitsmaterial"
|
||||
|
||||
zweck: |
|
||||
Diese Übersicht klärt die drei unterschiedlichen Bedarfstypen und ihre
|
||||
jeweiligen Prozesswege. Sie dient als Entscheidungshilfe für SHM und
|
||||
als Orientierung für DIGIT-Mitarbeiter.
|
||||
|
||||
**Kernaussage:** Es gibt drei Bedarfstypen mit unterschiedlichen Wegen:
|
||||
1. Externe Stakeholder-Bedarfe → Regelweg (vollständige Bedarfsbewertung)
|
||||
2. Interne DIGIT-Mitarbeiter-Bedarfe → Fast Track (10-15 min)
|
||||
3. Service-Lifecycle-Bedarfe → Bypass (direkt in Demand-Lifecycle)
|
||||
|
||||
referenzen:
|
||||
- dokument: "shm_bedarfsbewertung.yaml"
|
||||
abschnitt: "funktionale_herleitung.geltungsbereich"
|
||||
- dokument: "shm_bedarfsbewertung.yaml"
|
||||
abschnitt: "prozessablauf.schritt_0a_fast_track_intern"
|
||||
- dokument: "shm_d2p-integration.yaml"
|
||||
abschnitt: "abgrenzung_bedarfsquellen"
|
||||
- dokument: "PATCH_NOTES_interne_bedarfe_v1.1.md"
|
||||
beschreibung: "Konzeptdokumentation Fast Track"
|
||||
|
||||
governance_referenz: "GOV-SHM-026"
|
||||
|
||||
# =============================================================================
|
||||
# ÜBERSICHT: DREI BEDARFSTYPEN
|
||||
# =============================================================================
|
||||
|
||||
bedarfstypen_uebersicht:
|
||||
|
||||
visualisierung: |
|
||||
|
||||
┌─────────────────────────────────────────────────────────────────────────┐
|
||||
│ BEDARFSTYPEN IM DIGIT │
|
||||
└─────────────────────────────────────────────────────────────────────────┘
|
||||
|
||||
┌─────────────────────┐ ┌─────────────────────┐ ┌─────────────────────┐
|
||||
│ TYP 1: EXTERN │ │ TYP 2: INTERN │ │ TYP 3: LIFECYCLE │
|
||||
│ (Regelweg) │ │ (Fast Track) │ │ (Bypass) │
|
||||
└──────────┬──────────┘ └──────────┬──────────┘ └──────────┬──────────┘
|
||||
│ │ │
|
||||
Bedarfsträger: Bedarfsträger: Bedarfsträger:
|
||||
Externe Ämter, DIGIT-Mitarbeiter Service Owner,
|
||||
Dienststellen als Nutzer ISB, SOR, Leitung
|
||||
│ │ │
|
||||
▼ ▼ ▼
|
||||
┌─────────────────────┐ ┌─────────────────────┐ ┌─────────────────────┐
|
||||
│ SHM Bedarfsbewertung│ │ SHM Fast Track │ │ Direkt DPM/SOR │
|
||||
│ - Schritt 0 │ │ - 3 Schritte │ │ - Kein SHM-Routing │
|
||||
│ - Prüfungen 1-3 │ │ - 10-15 Minuten │ │ - SHM informiert │
|
||||
│ - Vollständiger │ │ - Reduzierter │ │ bei Stakeholder- │
|
||||
│ Steckbrief │ │ Steckbrief │ │ Auswirkungen │
|
||||
└──────────┬──────────┘ └──────────┬──────────┘ └──────────┬──────────┘
|
||||
│ │ │
|
||||
└─────────────────────────┼─────────────────────────┘
|
||||
│
|
||||
▼
|
||||
┌─────────────────────┐
|
||||
│ DPM / DSR / MB │
|
||||
│ (einheitliche │
|
||||
│ Klassifizierung) │
|
||||
└─────────────────────┘
|
||||
|
||||
zusammenfassung_tabelle:
|
||||
|
||||
spalten:
|
||||
- "Bedarfstyp"
|
||||
- "Bedarfsträger"
|
||||
- "Eintrittskanal"
|
||||
- "Prozess"
|
||||
- "Aufwand SHM"
|
||||
- "Steckbrief"
|
||||
|
||||
zeilen:
|
||||
- bedarfstyp: "Extern (Regelweg)"
|
||||
bedarfstraeger: "Ämter, Dienststellen außerhalb DIGIT"
|
||||
eintrittskanal: "SHM"
|
||||
prozess: "Schritt 0 + Prüfungen 1-3"
|
||||
aufwand_shm: "2-4 Stunden"
|
||||
steckbrief: "Vollständig (ROUTE-DPM)"
|
||||
|
||||
- bedarfstyp: "Intern (Fast Track)"
|
||||
bedarfstraeger: "DIGIT-Mitarbeiter als Nutzer"
|
||||
eintrittskanal: "SHM (Self-Service-Portal)"
|
||||
prozess: "3-Schritte Fast Track"
|
||||
aufwand_shm: "10-15 Minuten"
|
||||
steckbrief: "Reduziert (ROUTE-DPM-INTERN)"
|
||||
|
||||
- bedarfstyp: "Service-Lifecycle (Bypass)"
|
||||
bedarfstraeger: "SO, ISB, SOR, DIGIT-Leitung"
|
||||
eintrittskanal: "Direkt SOR/DPM"
|
||||
prozess: "Kein SHM-Routing"
|
||||
aufwand_shm: "0 (nur Information)"
|
||||
steckbrief: "Vom Bedarfsträger erstellt"
|
||||
|
||||
# =============================================================================
|
||||
# TYP 1: EXTERNE STAKEHOLDER-BEDARFE (REGELWEG)
|
||||
# =============================================================================
|
||||
|
||||
typ_1_externe_bedarfe:
|
||||
|
||||
name: "Externe Stakeholder-Bedarfe"
|
||||
kurzbezeichnung: "Regelweg"
|
||||
|
||||
definition: |
|
||||
Bedarfe, die von Stakeholdern außerhalb von DIGIT an DIGIT herangetragen
|
||||
werden. Der Stakeholder ist Bedarfsträger und Auftraggeber.
|
||||
|
||||
bedarfstraeger:
|
||||
- "Städtische Ämter (z.B. Bauamt, Sozialamt, Ordnungsamt)"
|
||||
- "Städtische Dienststellen"
|
||||
- "Eigenbetriebe"
|
||||
- "Andere kommunale Einrichtungen"
|
||||
|
||||
eintrittskanal: "SHM (Stakeholder-Management)"
|
||||
|
||||
prozess:
|
||||
beschreibung: "Vollständige Bedarfsbewertung gemäß shm_bedarfsbewertung.yaml"
|
||||
schritte:
|
||||
- "Schritt 0: Bedarfserhebung (User Stories)"
|
||||
- "Prüfung 1: Service-Katalog-Check"
|
||||
- "Prüfung 2: Change-Qualifizierung"
|
||||
- "Prüfung 3: Demand-Indikation"
|
||||
aufwand: "2-4 Stunden"
|
||||
steckbrief: "Vollständig (Validierungsprofil ROUTE-DPM)"
|
||||
|
||||
routing_optionen:
|
||||
- "ROUTE-REQ → Service Desk / Request Fulfilment"
|
||||
- "ROUTE-SPM → Service Owner (Change)"
|
||||
- "ROUTE-DPM → Demand Portfolio Management"
|
||||
- "ROUTE-SO → Service-Owner-Klärung (bei Unklarheit)"
|
||||
|
||||
beispiele:
|
||||
|
||||
- titel: "Bauamt benötigt neue Funktion im Fachverfahren"
|
||||
situation: |
|
||||
Das Bauamt meldet, dass im Bauantragsverfahren eine Funktion zur
|
||||
automatischen Flurstücksvalidierung fehlt.
|
||||
prozess: |
|
||||
SHM führt vollständige Bedarfsbewertung durch:
|
||||
- Schritt 0: User Stories mit Sachbearbeitern erarbeiten
|
||||
- Prüfung 1: Service existiert (Bauantragsverfahren)
|
||||
- Prüfung 2: Change am bestehenden Service → ROUTE-SPM
|
||||
ergebnis: "Vollständiger Bedarfssteckbrief an Service Owner"
|
||||
|
||||
- titel: "Sozialamt möchte digitale Antragsstellung"
|
||||
situation: |
|
||||
Das Sozialamt möchte Bürgeranträge online entgegennehmen können.
|
||||
Aktuell existiert kein entsprechender Service.
|
||||
prozess: |
|
||||
SHM führt vollständige Bedarfsbewertung durch:
|
||||
- Schritt 0: User Stories und Anforderungen erheben
|
||||
- Prüfung 1: Kein passender Service im Katalog
|
||||
- Prüfung 3: Demand-Indikation positiv → ROUTE-DPM
|
||||
ergebnis: "Vollständiger Bedarfssteckbrief an DPM"
|
||||
|
||||
# =============================================================================
|
||||
# TYP 2: INTERNE DIGIT-MITARBEITER-BEDARFE (FAST TRACK)
|
||||
# =============================================================================
|
||||
|
||||
typ_2_interne_nutzer_bedarfe:
|
||||
|
||||
name: "Interne DIGIT-Mitarbeiter-Bedarfe"
|
||||
kurzbezeichnung: "Fast Track"
|
||||
|
||||
definition: |
|
||||
Bedarfe von DIGIT-Mitarbeitern, die als *Nutzer* von IT-Services
|
||||
auftreten – nicht in ihrer Funktion als Service Owner, ISB oder
|
||||
andere technische Rolle.
|
||||
|
||||
bedarfstraeger:
|
||||
- "DIGIT-Personalabteilung"
|
||||
- "DIGIT-Sekretariat"
|
||||
- "DIGIT-Sachbearbeiter (als Nutzer)"
|
||||
- "Andere DIGIT-interne Organisationseinheiten"
|
||||
- "Ggf. Stabsstelle Digital Freiburg (als Nutzer)"
|
||||
|
||||
abgrenzung_zu_service_lifecycle: |
|
||||
Der Fast Track gilt für DIGIT-Mitarbeiter als **Nutzer**.
|
||||
|
||||
Wenn ein Service Owner einen Bedarf für seinen **eigenen Service** hat,
|
||||
ist das ein Service-Lifecycle-Bedarf (Typ 3), kein Fast-Track-Fall.
|
||||
|
||||
Beispiel:
|
||||
- Personalabteilung braucht neue Zeiterfassung → Fast Track (Typ 2)
|
||||
- Service Owner DMS plant Redesign seines Service → Lifecycle (Typ 3)
|
||||
|
||||
eintrittskanal:
|
||||
primaer: "Self-Service-Portal (ITSM-Tool)"
|
||||
mvp: "E-Mail-Template an SHM"
|
||||
|
||||
prozess:
|
||||
beschreibung: "Vereinfachter 3-Schritte Fast Track (10-15 Minuten)"
|
||||
|
||||
schritt_1:
|
||||
name: "Basistriage"
|
||||
dauer: "3-5 Minuten"
|
||||
frage: "Ist es ein valider Bedarf?"
|
||||
|
||||
schritt_2:
|
||||
name: "Routing-Entscheidung"
|
||||
dauer: "5-7 Minuten"
|
||||
frage: "Wohin gehört der Bedarf?"
|
||||
optionen:
|
||||
- "Bestehender Service → Direkt an Service Owner"
|
||||
- "Neuer Service → ROUTE-DPM-INTERN"
|
||||
- "Unklar → ROUTE-SO"
|
||||
|
||||
schritt_3:
|
||||
name: "Minimaldokumentation"
|
||||
dauer: "3-5 Minuten"
|
||||
bedingung: "Nur bei ROUTE-DPM-INTERN"
|
||||
|
||||
aufwand: "10-15 Minuten"
|
||||
steckbrief: "Reduziert (Validierungsprofil ROUTE-DPM-INTERN)"
|
||||
|
||||
routing_optionen:
|
||||
- "Direkt an Service Owner (kein Steckbrief)"
|
||||
- "ROUTE-DPM-INTERN (reduzierter Steckbrief)"
|
||||
- "ROUTE-SO (bei Unklarheit)"
|
||||
|
||||
beispiele:
|
||||
|
||||
- titel: "Personalabteilung DIGIT möchte neue Personalsoftware"
|
||||
situation: |
|
||||
Die Personalabteilung des DIGIT (als Nutzer) benötigt eine neue
|
||||
Software zur Zeiterfassung, da das aktuelle System nicht mehr
|
||||
den Anforderungen entspricht.
|
||||
prozess:
|
||||
schritt_1: "Valide – Bedarf verständlich, im Scope"
|
||||
schritt_2: "Kein bestehender Service → ROUTE-DPM-INTERN"
|
||||
schritt_3: "Minimaldoku: Interner Bedarf, neuer Service, Größe M"
|
||||
ergebnis: "An DPM mit reduziertem Steckbrief"
|
||||
aufwand: "~12 Minuten"
|
||||
|
||||
- titel: "Stabsstelle Digital möchte Miro (obwohl Conceptboard existiert)"
|
||||
situation: |
|
||||
Die Stabsstelle Digital Freiburg fragt nach einem Miro-Zugang
|
||||
für kollaborative Workshops.
|
||||
prozess:
|
||||
schritt_1: "Valide – Bedarf verständlich"
|
||||
schritt_2: "Bestehender Service: Conceptboard → Direkt an SO"
|
||||
schritt_3: "Nicht erforderlich"
|
||||
ergebnis: |
|
||||
Direkt an Service Owner Conceptboard. SO klärt:
|
||||
- Reicht Conceptboard aus?
|
||||
- Fehlt eine Funktion? → Ggf. Change
|
||||
- Begründeter Mehrbedarf? → SO entscheidet
|
||||
aufwand: "~8 Minuten"
|
||||
|
||||
- titel: "DIGIT-Sekretariat benötigt Terminplanungstool"
|
||||
situation: |
|
||||
Das Sekretariat möchte ein Tool zur vereinfachten Terminplanung
|
||||
mit externen Besuchern (Buchungslink-Funktion).
|
||||
prozess:
|
||||
schritt_1: "Valide – Bedarf verständlich, im Scope"
|
||||
schritt_2: "Prüfung: Kalendertool mit Buchungsfunktion vorhanden?"
|
||||
schritt_3: "Falls nein: ROUTE-DPM-INTERN mit Minimaldoku"
|
||||
ergebnis: "Abhängig von Service-Katalog-Prüfung"
|
||||
aufwand: "~10 Minuten"
|
||||
|
||||
# =============================================================================
|
||||
# TYP 3: SERVICE-LIFECYCLE-BEDARFE (BYPASS)
|
||||
# =============================================================================
|
||||
|
||||
typ_3_service_lifecycle_bedarfe:
|
||||
|
||||
name: "Service-Lifecycle-Bedarfe"
|
||||
kurzbezeichnung: "Bypass"
|
||||
|
||||
definition: |
|
||||
Bedarfe, die aus dem Service-Lifecycle oder aus technisch-strategischen
|
||||
Rollen heraus entstehen. Der Bedarfsträger ist eine DIGIT-interne Rolle
|
||||
mit fachlicher Expertise (Service Owner, ISB, SOR, DIGIT-Leitung).
|
||||
|
||||
Diese Bedarfe durchlaufen die SHM-Triage NICHT, weil die fachliche
|
||||
Qualifizierung bereits durch den Bedarfsträger erfolgt ist.
|
||||
|
||||
bedarfstraeger:
|
||||
- "Service Owner (für eigenen Service)"
|
||||
- "ISB / Compliance"
|
||||
- "SOR (strategische Entscheidungen)"
|
||||
- "DIGIT-Leitung / Mission Board"
|
||||
- "Technische Architektur-Rollen"
|
||||
|
||||
eintrittskanal: "Direkt SOR / DPM (je nach Umfang)"
|
||||
|
||||
shm_rolle: |
|
||||
SHM ist bei Service-Lifecycle-Bedarfen **nicht Routing-Instanz**, aber:
|
||||
- SHM wird **informiert**, wenn externe Stakeholder betroffen sind
|
||||
- SHM übernimmt dann die **Stakeholder-Kommunikation**
|
||||
- SHM kann **Stakeholder-Perspektive** in DSR/MB einbringen
|
||||
|
||||
szenarien:
|
||||
|
||||
# -------------------------------------------------------------------------
|
||||
szenario_1_change_bedarf_so:
|
||||
name: "Service Owner identifiziert Change-Bedarf"
|
||||
|
||||
beschreibung: |
|
||||
Der Service Owner erkennt im Rahmen seiner laufenden Arbeit oder aus
|
||||
dem Service Review, dass sein Service angepasst werden muss.
|
||||
|
||||
ausloeser:
|
||||
- "Service Review (sr_02) zeigt Optimierungspotenzial"
|
||||
- "Technische Schulden müssen abgebaut werden"
|
||||
- "Performance-Verbesserung erforderlich"
|
||||
- "Nutzer-Feedback zeigt Verbesserungsbedarf"
|
||||
|
||||
routing: "SO führt Change selbst durch (Normal Change Authority)"
|
||||
shm_information: "Nur bei Stakeholder-Auswirkungen"
|
||||
|
||||
beispiel:
|
||||
titel: "Performance-Optimierung Ticketsystem"
|
||||
situation: "SO stellt fest, dass die Suche zu langsam ist."
|
||||
routing: "SO führt Datenbank-Tuning als Change durch"
|
||||
shm_information: "Nicht erforderlich (keine Nutzer-Auswirkung)"
|
||||
|
||||
# -------------------------------------------------------------------------
|
||||
szenario_2_redesign_bedarf_so:
|
||||
name: "Service Owner identifiziert Redesign-Bedarf"
|
||||
|
||||
beschreibung: |
|
||||
Der Service Owner erkennt, dass sein Service grundlegend überarbeitet
|
||||
werden muss – die Änderung hat Projektcharakter.
|
||||
|
||||
ausloeser:
|
||||
- "Service Review zeigt grundlegenden Modernisierungsbedarf"
|
||||
- "Technologie ist veraltet (End-of-Life)"
|
||||
- "Architektur-Änderung erforderlich"
|
||||
|
||||
routing: "SO → SOR (REDESIGN) → DPM (Demand)"
|
||||
shm_information: "Ja, da Stakeholder betroffen"
|
||||
|
||||
beispiel:
|
||||
titel: "Modernisierung Dokumentenmanagement"
|
||||
situation: "SO erkennt im Review: DMS technisch veraltet"
|
||||
routing: "SO → SOR bestätigt → DPM erhält Demand"
|
||||
shm_information: "SHM bereitet Stakeholder-Kommunikation vor"
|
||||
|
||||
# -------------------------------------------------------------------------
|
||||
szenario_3_service_abloesung:
|
||||
name: "Service-Ablösung / Retirement"
|
||||
|
||||
beschreibung: |
|
||||
Ein Service soll nicht mehr weitergeführt werden – entweder
|
||||
ersatzlos oder durch einen anderen Service ersetzt.
|
||||
|
||||
ausloeser:
|
||||
- "End-of-Life des Produkts/der Technologie"
|
||||
- "Strategische Konsolidierung"
|
||||
- "Service wird nicht mehr benötigt"
|
||||
|
||||
routing: "SO → SOR (RETIRE) → DPM (Retirement-Projekt)"
|
||||
shm_information: "Ja, zwingend"
|
||||
|
||||
beispiel:
|
||||
titel: "Ablösung Legacy-Mailsystem"
|
||||
situation: "DIGIT entscheidet strategisch: Mailsystem ersetzen"
|
||||
routing: "SO (alt) → SOR → DPM (Retirement + ggf. neues System)"
|
||||
shm_information: |
|
||||
SHM übernimmt komplette Stakeholder-Kommunikation:
|
||||
- Key-Stakeholder: Persönliche Gespräche
|
||||
- Aktiv-Stakeholder: Strukturierte Information
|
||||
- Standard/Basis: Schriftliche Ankündigung
|
||||
|
||||
# -------------------------------------------------------------------------
|
||||
szenario_4_sicherheit_compliance:
|
||||
name: "Sicherheits- oder Compliance-Anforderung"
|
||||
|
||||
beschreibung: |
|
||||
Eine Änderung wird durch Sicherheitsvorgaben, Regulatorik oder
|
||||
Compliance-Anforderungen notwendig.
|
||||
|
||||
ausloeser:
|
||||
- "Sicherheitsvorfall oder -erkenntnis"
|
||||
- "Neue gesetzliche Anforderung"
|
||||
- "Audit-Feststellung"
|
||||
- "BSI-Empfehlung"
|
||||
|
||||
routing: "ISB → SOR/SO (je nach Umfang)"
|
||||
shm_information: "Bei Stakeholder-Auswirkungen"
|
||||
|
||||
beispiel:
|
||||
titel: "Zwei-Faktor-Authentifizierung verpflichtend"
|
||||
situation: "Neue Sicherheitsrichtlinie erfordert 2FA"
|
||||
routing: "ISB → SOR → Umsetzung durch betroffene SOs"
|
||||
shm_information: |
|
||||
SHM übernimmt Stakeholder-Kommunikation:
|
||||
- Erklärung der Notwendigkeit
|
||||
- Zeitplan und Umstellungsprozess
|
||||
- Schulungs-/Support-Angebote
|
||||
|
||||
# -------------------------------------------------------------------------
|
||||
szenario_5_strategische_initiative:
|
||||
name: "Strategische DIGIT-Initiative"
|
||||
|
||||
beschreibung: |
|
||||
DIGIT startet eine übergreifende Initiative, die mehrere Services
|
||||
betrifft oder neue Infrastruktur schafft.
|
||||
|
||||
ausloeser:
|
||||
- "IT-Strategie-Umsetzung"
|
||||
- "Konsolidierungsprojekt"
|
||||
- "Infrastruktur-Modernisierung"
|
||||
- "Einführung neuer Basisdienste"
|
||||
|
||||
routing: "DIGIT-Leitung → MB → DPM"
|
||||
shm_information: "Ja, bei Stakeholder-Auswirkungen"
|
||||
|
||||
beispiel:
|
||||
titel: "Einführung zentrales Identity Management"
|
||||
situation: "DIGIT führt IAM-System ein (Single Sign-On)"
|
||||
routing: "DIGIT-Leitung → MB (Freigabe) → DPM (Programm)"
|
||||
shm_information: |
|
||||
SHM wird frühzeitig eingebunden:
|
||||
- Vorteile kommunizieren
|
||||
- Migrationsplanung je Amt
|
||||
- Schulungskonzept
|
||||
|
||||
# =============================================================================
|
||||
# ENTSCHEIDUNGSHILFE
|
||||
# =============================================================================
|
||||
|
||||
entscheidungshilfe:
|
||||
|
||||
kernfragen:
|
||||
- frage: "Wer ist Bedarfsträger?"
|
||||
typ_1: "Externes Amt / Dienststelle"
|
||||
typ_2: "DIGIT-Mitarbeiter als Nutzer"
|
||||
typ_3: "SO, ISB, SOR, DIGIT-Leitung"
|
||||
|
||||
- frage: "Woher kommt der Bedarf?"
|
||||
typ_1: "Stakeholder-Anfrage von außerhalb DIGIT"
|
||||
typ_2: "Interne Nutzer-Anforderung"
|
||||
typ_3: "Service-Lifecycle, Sicherheit, Strategie"
|
||||
|
||||
- frage: "Hat der Bedarfsträger fachliche IT-Expertise?"
|
||||
typ_1: "Nein (fachliche Übersetzung durch SHM nötig)"
|
||||
typ_2: "Begrenzt (vereinfachte Prüfung ausreichend)"
|
||||
typ_3: "Ja (Bedarfsträger qualifiziert selbst)"
|
||||
|
||||
grenzfaelle:
|
||||
|
||||
- fall: "Stakeholder beschwert sich, SO erkennt daraus Redesign-Bedarf"
|
||||
einschaetzung: |
|
||||
Der initiale Bedarf war extern (Beschwerde) → Typ 1.
|
||||
Die Schlussfolgerung "Redesign nötig" ist SO-Erkenntnis → Typ 3.
|
||||
|
||||
Routing: Beschwerde über SHM (Typ 1). Wenn SHM an SO routet und
|
||||
SO dann Redesign empfiehlt, geht der Demand direkt zu DPM (Typ 3).
|
||||
|
||||
- fall: "SO möchte Feature, das Stakeholder auch wünschen"
|
||||
einschaetzung: |
|
||||
Entscheidend ist, wer den Bedarf zuerst artikuliert hat:
|
||||
- Stakeholder zuerst → Typ 1 (SHM-Regelweg)
|
||||
- SO zuerst → Typ 3 (Service-Lifecycle)
|
||||
|
||||
In der Praxis: SO kann auf Stakeholder-Unterstützung verweisen.
|
||||
|
||||
- fall: "DIGIT-Personalabteilung vs. Personalamt der Stadt"
|
||||
einschaetzung: |
|
||||
- DIGIT-Personalabteilung → Typ 2 (Fast Track)
|
||||
- Personalamt der Stadt (anderes Amt) → Typ 1 (Regelweg)
|
||||
|
||||
Entscheidend ist die organisatorische Zugehörigkeit, nicht die
|
||||
funktionale Ähnlichkeit.
|
||||
|
||||
- fall: "ISB fordert Änderung, die Stakeholder nicht wollen"
|
||||
einschaetzung: |
|
||||
Sicherheits-/Compliance-Anforderungen sind Typ 3, auch wenn sie
|
||||
Stakeholder-Widerstand erzeugen.
|
||||
|
||||
SHM übernimmt die (ggf. schwierige) Stakeholder-Kommunikation,
|
||||
aber das Routing bleibt Typ 3 (ISB → SOR/SO).
|
||||
|
||||
# =============================================================================
|
||||
# ROUTING-MATRIX (KOMPAKT)
|
||||
# =============================================================================
|
||||
|
||||
routing_matrix_kompakt:
|
||||
|
||||
zeilen:
|
||||
- bedarfstyp: "Extern (Typ 1)"
|
||||
beispiel: "Bauamt braucht neue Funktion"
|
||||
eintritt: "SHM"
|
||||
prozess: "Regelweg"
|
||||
aufwand: "2-4h"
|
||||
steckbrief: "Vollständig"
|
||||
|
||||
- bedarfstyp: "Intern-Nutzer (Typ 2)"
|
||||
beispiel: "DIGIT-Personal braucht Zeiterfassung"
|
||||
eintritt: "SHM (Fast Track)"
|
||||
prozess: "3 Schritte"
|
||||
aufwand: "10-15min"
|
||||
steckbrief: "Reduziert"
|
||||
|
||||
- bedarfstyp: "Service-Lifecycle (Typ 3)"
|
||||
beispiel: "SO plant DMS-Modernisierung"
|
||||
eintritt: "Direkt SOR/DPM"
|
||||
prozess: "Kein SHM"
|
||||
aufwand: "0 (SHM)"
|
||||
steckbrief: "Vom SO"
|
||||
|
||||
# =============================================================================
|
||||
# SHM-AUFGABEN JE BEDARFSTYP
|
||||
# =============================================================================
|
||||
|
||||
shm_aufgaben_je_typ:
|
||||
|
||||
typ_1_extern:
|
||||
- "Vollständige Bedarfsbewertung (Schritt 0, Prüfungen 1-3)"
|
||||
- "User-Story-Erhebung mit Stakeholder"
|
||||
- "Bedarfssteckbrief erstellen und validieren"
|
||||
- "Routing-Entscheidung treffen"
|
||||
- "Stakeholder-Kommunikation im gesamten Prozess"
|
||||
|
||||
typ_2_intern_nutzer:
|
||||
- "Fast Track Basistriage (3-5 min)"
|
||||
- "Schnelle Routing-Entscheidung (5-7 min)"
|
||||
- "Minimaldokumentation bei ROUTE-DPM-INTERN (3-5 min)"
|
||||
- "Weiterleitung an SO oder DPM"
|
||||
|
||||
typ_3_service_lifecycle:
|
||||
- "Keine Routing-Aufgabe"
|
||||
- "Information bei Stakeholder-Auswirkungen entgegennehmen"
|
||||
- "Stakeholder-Kommunikation übernehmen (wenn informiert)"
|
||||
- "Stakeholder-Perspektive in DSR/MB einbringen"
|
||||
|
||||
# =============================================================================
|
||||
# ÄNDERUNGSHISTORIE
|
||||
# =============================================================================
|
||||
|
||||
aenderungshistorie:
|
||||
|
||||
- version: "1.0"
|
||||
datum: "2025-01-29"
|
||||
aenderung: "Initiale Erstellung (Fokus auf Service-Lifecycle-Bedarfe)"
|
||||
autor: "DIGITOM-Projekt"
|
||||
quelle: "Chat-Session Konzeptprüfung"
|
||||
|
||||
- version: "2.0"
|
||||
datum: "2025-01-29"
|
||||
aenderung: |
|
||||
Komplette Überarbeitung: Drei Bedarfstypen klar unterschieden
|
||||
- Typ 1: Externe Stakeholder-Bedarfe (Regelweg)
|
||||
- Typ 2: Interne DIGIT-Mitarbeiter-Bedarfe (Fast Track)
|
||||
- Typ 3: Service-Lifecycle-Bedarfe (Bypass)
|
||||
- Visualisierung und Routing-Matrix ergänzt
|
||||
- Entscheidungshilfe mit Grenzfällen
|
||||
- SHM-Aufgaben je Bedarfstyp
|
||||
- Synchronisierung mit shm_bedarfsbewertung.yaml v1.3
|
||||
autor: "DIGITOM-Projekt"
|
||||
quelle: "Chat-Session Konzeptprüfung"
|
||||
|
|
@ -0,0 +1,470 @@
|
|||
# =============================================================================
|
||||
# SHM LEITFADEN: USER STORIES IM DIGIT AUFNEHMEN
|
||||
# =============================================================================
|
||||
# Modul: Stakeholder-Management (SHM)
|
||||
# Typ: Arbeitsmaterial (Leitfaden)
|
||||
# Version: 1.0
|
||||
# Datum: 2025-12-09
|
||||
# Status: Final
|
||||
# Quelle: Konzept_DPM_Abnahme20230925, Seiten 125-131
|
||||
# =============================================================================
|
||||
|
||||
meta:
|
||||
dokument_id: "SHM-A-01"
|
||||
name: "Leitfaden User Stories"
|
||||
typ: "Arbeitsmaterial"
|
||||
|
||||
zweck: |
|
||||
Dieser Leitfaden unterstützt Stakeholder-Manager dabei, Anforderungen
|
||||
aus Sicht der Nutzenden zu erheben. User Stories übersetzen abstrakte
|
||||
Bedarfe in konkrete, nachvollziehbare Funktionswünsche.
|
||||
|
||||
zielgruppe: "Stakeholder-Manager:innen"
|
||||
|
||||
kontext: |
|
||||
Im DIGIT-Kontext helfen User Stories, die Perspektive der
|
||||
Verwaltungsmitarbeitenden und Bürger*innen in den Mittelpunkt zu stellen.
|
||||
Der Leitfaden ist Teil der Bedarfserhebung (Schritt 0 der Bedarfsbewertung).
|
||||
|
||||
geltungsbereich: "DIGITOM / Demand-to-Project-Prozess"
|
||||
|
||||
status_dokument:
|
||||
abgestimmt_zwischen: ["human", "DPM-Teammitglied"]
|
||||
inhaltlich_abgenommen_durch:
|
||||
- person: "DPM-Teammitglied"
|
||||
datum: "2025-09-17"
|
||||
- person: "DPM-Leitung"
|
||||
datum: null
|
||||
abgenommen_in_gesamtkonzept: false
|
||||
|
||||
referenzen:
|
||||
- dokument: "shm_bedarfsbewertung.yaml"
|
||||
abschnitt: "schritt_0"
|
||||
beschreibung: "Integration in Bedarfsbewertungs-Prozess"
|
||||
- dokument: "shm_schema_bedarfssteckbrief.yaml"
|
||||
abschnitt: "user_stories"
|
||||
beschreibung: "Dokumentation der erhobenen User Stories"
|
||||
|
||||
# =============================================================================
|
||||
# GRUNDLAGEN
|
||||
# =============================================================================
|
||||
|
||||
grundlagen:
|
||||
|
||||
definition: |
|
||||
User Stories beschreiben Anforderungen aus Sicht der Nutzenden.
|
||||
Sie übersetzen abstrakte Bedarfe in konkrete, nachvollziehbare
|
||||
Funktionswünsche.
|
||||
|
||||
grundformat:
|
||||
schema: "Als [Rolle/Bereich] möchte ich [Funktionalität/Lösung], um [Nutzen/Ziel zu erreichen]"
|
||||
|
||||
elemente:
|
||||
- element: "Rolle"
|
||||
beschreibung: "Wer hat den Bedarf? (spezifisch, nicht 'Nutzer')"
|
||||
beispiele:
|
||||
- "Sachbearbeiter*in Bauamt"
|
||||
- "Abteilungsleitung"
|
||||
- "Bürger*in"
|
||||
- "Antragsteller*in"
|
||||
|
||||
- element: "Funktionalität"
|
||||
beschreibung: "Was soll ermöglicht werden? (keine technische Lösung)"
|
||||
beispiele:
|
||||
- "Bauanträge nach Flurstücknummer durchsuchen"
|
||||
- "Urlaubsanträge digital genehmigen"
|
||||
- "Bearbeitungsstatus online einsehen"
|
||||
|
||||
- element: "Nutzen"
|
||||
beschreibung: "Warum ist das wichtig? (konkreter Mehrwert)"
|
||||
beispiele:
|
||||
- "zusammenhängende Anträge schnell identifizieren"
|
||||
- "Prozess auch im Homeoffice funktioniert"
|
||||
- "nicht telefonisch nachfragen müssen"
|
||||
|
||||
mehrwert:
|
||||
- aspekt: "Perspektivwechsel"
|
||||
beschreibung: "Weg von technischen Spezifikationen, hin zum tatsächlichen Bedarf"
|
||||
|
||||
- aspekt: "Verständlichkeit"
|
||||
beschreibung: "Fachbereiche und IT sprechen dieselbe Sprache"
|
||||
|
||||
- aspekt: "Priorisierung"
|
||||
beschreibung: "Nutzen wird explizit und bewertbar"
|
||||
|
||||
- aspekt: "Validierung"
|
||||
beschreibung: "Stakeholder können bestätigen: 'Ja, genau das brauche ich'"
|
||||
|
||||
# =============================================================================
|
||||
# SCHRITT-FÜR-SCHRITT-ANLEITUNG
|
||||
# =============================================================================
|
||||
|
||||
anleitung:
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# SCHRITT 1: VORBEREITUNG
|
||||
# ---------------------------------------------------------------------------
|
||||
|
||||
schritt_1:
|
||||
name: "Vorbereitung des Gesprächs"
|
||||
|
||||
vor_dem_termin_klaeren:
|
||||
- "Wer sind die Hauptnutzenden? (Sachbearbeiter*innen, Führungskräfte, Bürger*innen?)"
|
||||
- "Welcher Prozess ist betroffen?"
|
||||
- "Gibt es Vorarbeiten oder Dokumentationen?"
|
||||
|
||||
materialien_bereithalten:
|
||||
- "Bedarfs-Steckbrief"
|
||||
- "Ggf. Prozessvisualisierung"
|
||||
- "Beispiel-User-Stories zur Illustration"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# SCHRITT 2: EINSTIEG
|
||||
# ---------------------------------------------------------------------------
|
||||
|
||||
schritt_2:
|
||||
name: "Einstieg ins Gespräch"
|
||||
|
||||
grundprinzip:
|
||||
falsch: "Welche User Stories haben Sie?"
|
||||
richtig: "Erzählen Sie mir, was Sie in Ihrer täglichen Arbeit erreichen möchten."
|
||||
|
||||
leitfragen_einstieg:
|
||||
- "Beschreiben Sie einen typischen Arbeitsablauf, bei dem es hakt."
|
||||
- "Was würde Ihnen die Arbeit erleichtern?"
|
||||
- "Wobei verlieren Sie die meiste Zeit?"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# SCHRITT 3: ROLLEN IDENTIFIZIEREN
|
||||
# ---------------------------------------------------------------------------
|
||||
|
||||
schritt_3:
|
||||
name: "Die richtigen Rollen identifizieren"
|
||||
|
||||
typische_rollen:
|
||||
verwaltungsintern:
|
||||
- "Sachbearbeiter*in [Amt]"
|
||||
- "Abteilungsleitung"
|
||||
- "Verwaltungsmitarbeitende"
|
||||
- "Amtsleitung"
|
||||
- "Datenschutzbeauftragte*r"
|
||||
|
||||
verwaltungsextern:
|
||||
- "Bürger*in"
|
||||
- "Antragsteller*in"
|
||||
- "Unternehmen"
|
||||
- "Andere Institute"
|
||||
- "Dienstleister"
|
||||
|
||||
wichtiger_hinweis: |
|
||||
Spezifisch sein! Nicht "Nutzer", sondern "Sachbearbeiter*in Wohngeldstelle"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# SCHRITT 4: FUNKTIONALITÄTEN HERAUSARBEITEN
|
||||
# ---------------------------------------------------------------------------
|
||||
|
||||
schritt_4:
|
||||
name: "Funktionalitäten herausarbeiten"
|
||||
|
||||
prinzip: "Von der Lösung zum Bedarf"
|
||||
|
||||
uebersetzungen:
|
||||
- stakeholder_sagt: "Wir brauchen eine Datenbank"
|
||||
shm_fragt: "Was möchten Sie damit tun?"
|
||||
story_wird: "...möchte ich Anträge zentral verwalten..."
|
||||
|
||||
- stakeholder_sagt: "Das System ist zu langsam"
|
||||
shm_fragt: "Wobei genau verlieren Sie Zeit?"
|
||||
story_wird: "...möchte ich Suchergebnisse in unter 3 Sekunden..."
|
||||
|
||||
- stakeholder_sagt: "Wir wollen alles digitalisieren"
|
||||
shm_fragt: "Was genau soll digital werden?"
|
||||
story_wird: "...möchte ich Anträge online einreichen..."
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# SCHRITT 5: NUTZEN EXPLIZIT MACHEN
|
||||
# ---------------------------------------------------------------------------
|
||||
|
||||
schritt_5:
|
||||
name: "Den Nutzen explizit machen"
|
||||
|
||||
nachfragen:
|
||||
- "Warum ist das wichtig?"
|
||||
- "Was können Sie dann besser machen?"
|
||||
|
||||
nutzen_kategorien:
|
||||
- kategorie: "Effizienz"
|
||||
beispiel: "...damit ich mehr Anträge bearbeiten kann"
|
||||
|
||||
- kategorie: "Qualität"
|
||||
beispiel: "...damit weniger Fehler passieren"
|
||||
|
||||
- kategorie: "Service"
|
||||
beispiel: "...damit Bürger*innen schneller Antworten erhalten"
|
||||
|
||||
- kategorie: "Compliance"
|
||||
beispiel: "...damit wir gesetzeskonform arbeiten"
|
||||
|
||||
- kategorie: "Transparenz"
|
||||
beispiel: "...damit der Bearbeitungsstand nachvollziehbar ist"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# SCHRITT 6: FORMULIEREN
|
||||
# ---------------------------------------------------------------------------
|
||||
|
||||
schritt_6:
|
||||
name: "User Stories formulieren"
|
||||
|
||||
beispiel_gut:
|
||||
rolle: "Sachbearbeiterin im Bauamt"
|
||||
funktionalitaet: "Bauanträge nach Flurstücknummer durchsuchen können"
|
||||
nutzen: "zusammenhängende Anträge schnell identifiziere"
|
||||
vollstaendig: |
|
||||
Als Sachbearbeiterin im Bauamt
|
||||
möchte ich Bauanträge nach Flurstücknummer durchsuchen können
|
||||
damit ich zusammenhängende Anträge schnell identifiziere
|
||||
|
||||
beispiel_schlecht:
|
||||
rolle: "Nutzer"
|
||||
funktionalitaet: "eine bessere Suche"
|
||||
nutzen: "es schneller geht"
|
||||
vollstaendig: |
|
||||
Als Nutzer
|
||||
möchte ich eine bessere Suche
|
||||
damit es schneller geht
|
||||
probleme:
|
||||
- "Rolle zu unspezifisch"
|
||||
- "Funktionalität zu vage"
|
||||
- "Nutzen nicht konkret"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# SCHRITT 7: PRIORISIEREN UND VALIDIEREN
|
||||
# ---------------------------------------------------------------------------
|
||||
|
||||
schritt_7:
|
||||
name: "Stories priorisieren und validieren"
|
||||
|
||||
validierungsfragen:
|
||||
- "Habe ich Sie richtig verstanden?"
|
||||
- "Ist diese Reihenfolge nach Wichtigkeit korrekt?"
|
||||
- "Fehlt noch etwas Wesentliches?"
|
||||
|
||||
priorisierungsstufen:
|
||||
- stufe: "Kritisch"
|
||||
beschreibung: "Ohne geht es nicht"
|
||||
|
||||
- stufe: "Wichtig"
|
||||
beschreibung: "Deutliche Verbesserung"
|
||||
|
||||
- stufe: "Nützlich"
|
||||
beschreibung: "Wäre schön"
|
||||
|
||||
# =============================================================================
|
||||
# TYPISCHE HERAUSFORDERUNGEN
|
||||
# =============================================================================
|
||||
|
||||
herausforderungen:
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# HERAUSFORDERUNG 1: LÖSUNGSDENKEN
|
||||
# ---------------------------------------------------------------------------
|
||||
|
||||
loesungsdenken:
|
||||
name: "Der Stakeholder denkt nur in Lösungen"
|
||||
|
||||
technik: "Die 5-Warum-Methode"
|
||||
|
||||
beispiel_dialog:
|
||||
- sprecher: "Stakeholder"
|
||||
aussage: "Wir brauchen ein Dashboard"
|
||||
- sprecher: "SHM"
|
||||
aussage: "Warum brauchen Sie ein Dashboard?"
|
||||
- sprecher: "Stakeholder"
|
||||
aussage: "Um die Zahlen zu sehen"
|
||||
- sprecher: "SHM"
|
||||
aussage: "Warum müssen Sie die Zahlen sehen?"
|
||||
- sprecher: "Stakeholder"
|
||||
aussage: "Um zu erkennen, wo sich Anträge stauen"
|
||||
|
||||
resultierende_story: |
|
||||
Als Abteilungsleitung
|
||||
möchte ich Engpässe im Antragsprozess erkennen
|
||||
damit ich Ressourcen umverteilen kann
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# HERAUSFORDERUNG 2: ALLES DRINGEND
|
||||
# ---------------------------------------------------------------------------
|
||||
|
||||
alles_dringend:
|
||||
name: "Alles ist wichtig und dringend"
|
||||
|
||||
technik: "Relatives Priorisieren"
|
||||
|
||||
hilfreiche_fragen:
|
||||
- "Wenn Sie nur eine Sache bekommen könnten, welche wäre es?"
|
||||
- "Was würde am meisten wehtun, wenn es fehlt?"
|
||||
- "Was nutzen Sie täglich vs. was nur monatlich?"
|
||||
|
||||
# =============================================================================
|
||||
# QUALITÄTSKRITERIEN
|
||||
# =============================================================================
|
||||
|
||||
qualitaetskriterien:
|
||||
|
||||
invest:
|
||||
name: "INVEST-Kriterien"
|
||||
beschreibung: "Qualitätsstandard für gute User Stories"
|
||||
|
||||
kriterien:
|
||||
- buchstabe: "I"
|
||||
name: "Independent"
|
||||
beschreibung: "Unabhängig von anderen Stories"
|
||||
|
||||
- buchstabe: "N"
|
||||
name: "Negotiable"
|
||||
beschreibung: "Nicht in Stein gemeißelt"
|
||||
|
||||
- buchstabe: "V"
|
||||
name: "Valuable"
|
||||
beschreibung: "Klarer Nutzen erkennbar"
|
||||
|
||||
- buchstabe: "E"
|
||||
name: "Estimable"
|
||||
beschreibung: "Größe grob einschätzbar"
|
||||
|
||||
- buchstabe: "S"
|
||||
name: "Small"
|
||||
beschreibung: "In überschaubarer Zeit umsetzbar"
|
||||
|
||||
- buchstabe: "T"
|
||||
name: "Testable"
|
||||
beschreibung: "Überprüfbare Erfolgskriterien"
|
||||
|
||||
# =============================================================================
|
||||
# BEISPIEL-STORIES
|
||||
# =============================================================================
|
||||
|
||||
beispiel_stories:
|
||||
|
||||
- bereich: "Bürgerservice"
|
||||
story:
|
||||
rolle: "Bürger*in"
|
||||
funktionalitaet: "den Bearbeitungsstatus meines Antrags online einsehen"
|
||||
nutzen: "ich nicht telefonisch nachfragen muss"
|
||||
volltext: |
|
||||
Als Bürger*in
|
||||
möchte ich den Bearbeitungsstatus meines Antrags online einsehen
|
||||
damit ich nicht telefonisch nachfragen muss
|
||||
|
||||
- bereich: "Interne Verwaltung"
|
||||
story:
|
||||
rolle: "Personalverantwortliche"
|
||||
funktionalitaet: "Urlaubsanträge digital genehmigen können"
|
||||
nutzen: "der Prozess auch im Homeoffice funktioniert"
|
||||
volltext: |
|
||||
Als Personalverantwortliche
|
||||
möchte ich Urlaubsanträge digital genehmigen können
|
||||
damit der Prozess auch im Homeoffice funktioniert
|
||||
|
||||
- bereich: "Schnittstellen"
|
||||
story:
|
||||
rolle: "Mitarbeitende im Einwohnermeldeamt"
|
||||
funktionalitaet: "Meldedaten automatisch ans Finanzamt übertragen"
|
||||
nutzen: "Bürger*innen sich nicht doppelt melden müssen"
|
||||
volltext: |
|
||||
Als Mitarbeitende im Einwohnermeldeamt
|
||||
möchte ich Meldedaten automatisch ans Finanzamt übertragen
|
||||
damit Bürger*innen sich nicht doppelt melden müssen
|
||||
|
||||
# =============================================================================
|
||||
# CHECKLISTE FÜR SHM
|
||||
# =============================================================================
|
||||
|
||||
checkliste:
|
||||
|
||||
name: "Checkliste für Stakeholder-Manager"
|
||||
|
||||
pruefpunkte:
|
||||
- id: "CK-01"
|
||||
pruefpunkt: "Rollen spezifisch identifiziert"
|
||||
beispiel: "Nicht 'Nutzer', sondern 'Sachbearbeiter*in Wohngeldstelle'"
|
||||
|
||||
- id: "CK-02"
|
||||
pruefpunkt: "Funktionalitäten klar beschrieben (keine Lösungen)"
|
||||
beispiel: "Nicht 'Datenbank', sondern 'Anträge zentral verwalten'"
|
||||
|
||||
- id: "CK-03"
|
||||
pruefpunkt: "Nutzen explizit gemacht"
|
||||
beispiel: "Konkrete Verbesserung benannt, nicht 'damit es besser wird'"
|
||||
|
||||
- id: "CK-04"
|
||||
pruefpunkt: "Stories mit Stakeholder validiert"
|
||||
beispiel: "Stakeholder hat bestätigt: 'Ja, das ist mein Bedarf'"
|
||||
|
||||
- id: "CK-05"
|
||||
pruefpunkt: "Prioritäten geklärt"
|
||||
beispiel: "Kritisch / Wichtig / Nützlich zugeordnet"
|
||||
|
||||
- id: "CK-06"
|
||||
pruefpunkt: "Zusammenhang zum Problem hergestellt"
|
||||
beispiel: "Story adressiert dokumentiertes Problem aus Situationsanalyse"
|
||||
|
||||
- id: "CK-07"
|
||||
pruefpunkt: "In Bedarfs-Steckbrief übertragen"
|
||||
beispiel: "Stories im Schema-konformen Format dokumentiert"
|
||||
|
||||
# =============================================================================
|
||||
# DOKUMENTATION
|
||||
# =============================================================================
|
||||
|
||||
dokumentation:
|
||||
|
||||
nach_dem_gespraech:
|
||||
- schritt: 1
|
||||
aktion: "Stories im Steckbrief sauber dokumentieren"
|
||||
- schritt: 2
|
||||
aktion: "Priorisierung vermerken"
|
||||
- schritt: 3
|
||||
aktion: "Offene Punkte notieren"
|
||||
- schritt: 4
|
||||
aktion: "Validierungstermin vereinbaren"
|
||||
|
||||
ablage:
|
||||
ziel_dokument: "Bedarfs-Steckbrief"
|
||||
ziel_abschnitt: "user_stories"
|
||||
schema_referenz: "shm_schema_bedarfssteckbrief.yaml"
|
||||
|
||||
# =============================================================================
|
||||
# HINWEISE
|
||||
# =============================================================================
|
||||
|
||||
hinweise:
|
||||
|
||||
- typ: "Tipp"
|
||||
text: |
|
||||
Die erste User Story ist die schwerste. Mit etwas Übung entwickeln
|
||||
Sie ein Gefühl dafür, die richtigen Fragen zu stellen und Bedarfe
|
||||
strukturiert zu erfassen.
|
||||
|
||||
- typ: "Warnung"
|
||||
text: |
|
||||
Vermeiden Sie es, selbst Lösungen vorzuschlagen. Ihre Aufgabe ist
|
||||
es, den Bedarf zu verstehen – nicht, ihn zu lösen.
|
||||
|
||||
- typ: "Best Practice"
|
||||
text: |
|
||||
Beginnen Sie mit offenen Fragen zum Arbeitsalltag, bevor Sie
|
||||
konkrete User Stories formulieren. Der Kontext hilft, die
|
||||
richtigen Fragen zu stellen.
|
||||
|
||||
# =============================================================================
|
||||
# ÄNDERUNGSHISTORIE
|
||||
# =============================================================================
|
||||
|
||||
aenderungshistorie:
|
||||
|
||||
- version: "1.0"
|
||||
datum: "2025-12-09"
|
||||
aenderung: "Initiale Erstellung aus PDF-Vorlage"
|
||||
autor: "DIGITOM-Projekt"
|
||||
quelle: "Konzept_DPM_Abnahme20230925, Seiten 125-131"
|
||||
|
|
@ -0,0 +1,20 @@
|
|||
# ========================================
|
||||
# Stakeholder-Informations-Management-System (SIMS)
|
||||
# ========================================
|
||||
# Version: 0.1 (Platzhalter)
|
||||
# Datum: 2024-12-03
|
||||
# Status: Ausstehend
|
||||
# Entwicklungsphase: 11
|
||||
# ========================================
|
||||
|
||||
# ITIL4-Referenz (falls zutreffend):
|
||||
# itil4_referenz:
|
||||
# practice: ""
|
||||
# relevante_elemente: []
|
||||
# adaption_fuer_digitom: ""
|
||||
|
||||
# ========================================
|
||||
# INHALT
|
||||
# ========================================
|
||||
|
||||
# [Inhalt folgt in Phase 11]
|
||||
Loading…
Add table
Add a link
Reference in a new issue