säuberung repo
This commit is contained in:
parent
93b9576bc6
commit
9788e273ed
80 changed files with 47758 additions and 48172 deletions
|
|
@ -1,20 +1,20 @@
|
|||
# ========================================
|
||||
# Funktionsbeschreibung Stakeholder-Management (SHM)
|
||||
# ========================================
|
||||
# Version: 0.1 (Platzhalter)
|
||||
# Datum: 2024-12-03
|
||||
# Status: Ausstehend
|
||||
# Entwicklungsphase: 0, 10
|
||||
# ========================================
|
||||
|
||||
# ITIL4-Referenz (falls zutreffend):
|
||||
# itil4_referenz:
|
||||
# practice: ""
|
||||
# relevante_elemente: []
|
||||
# adaption_fuer_digitom: ""
|
||||
|
||||
# ========================================
|
||||
# INHALT
|
||||
# ========================================
|
||||
|
||||
# [Inhalt folgt in Phase 0 und 10]
|
||||
# ========================================
|
||||
# Funktionsbeschreibung Stakeholder-Management (SHM)
|
||||
# ========================================
|
||||
# Version: 0.1 (Platzhalter)
|
||||
# Datum: 2024-12-03
|
||||
# Status: Ausstehend
|
||||
# Entwicklungsphase: 0, 10
|
||||
# ========================================
|
||||
|
||||
# ITIL4-Referenz (falls zutreffend):
|
||||
# itil4_referenz:
|
||||
# practice: ""
|
||||
# relevante_elemente: []
|
||||
# adaption_fuer_digitom: ""
|
||||
|
||||
# ========================================
|
||||
# INHALT
|
||||
# ========================================
|
||||
|
||||
# [Inhalt folgt in Phase 0 und 10]
|
||||
|
|
|
|||
File diff suppressed because it is too large
Load diff
File diff suppressed because it is too large
Load diff
File diff suppressed because it is too large
Load diff
File diff suppressed because it is too large
Load diff
|
|
@ -1,20 +1,20 @@
|
|||
# ========================================
|
||||
# SHM Lifecycle Blueprint
|
||||
# ========================================
|
||||
# Version: 0.1 (Platzhalter)
|
||||
# Datum: 2024-12-03
|
||||
# Status: Ausstehend
|
||||
# Entwicklungsphase: 3
|
||||
# ========================================
|
||||
|
||||
# ITIL4-Referenz (falls zutreffend):
|
||||
# itil4_referenz:
|
||||
# practice: "Customer Journey (DSV)"
|
||||
# relevante_elemente: []
|
||||
# adaption_fuer_digitom: ""
|
||||
|
||||
# ========================================
|
||||
# INHALT
|
||||
# ========================================
|
||||
|
||||
# [Inhalt folgt in Phase 3]
|
||||
# ========================================
|
||||
# SHM Lifecycle Blueprint
|
||||
# ========================================
|
||||
# Version: 0.1 (Platzhalter)
|
||||
# Datum: 2024-12-03
|
||||
# Status: Ausstehend
|
||||
# Entwicklungsphase: 3
|
||||
# ========================================
|
||||
|
||||
# ITIL4-Referenz (falls zutreffend):
|
||||
# itil4_referenz:
|
||||
# practice: "Customer Journey (DSV)"
|
||||
# relevante_elemente: []
|
||||
# adaption_fuer_digitom: ""
|
||||
|
||||
# ========================================
|
||||
# INHALT
|
||||
# ========================================
|
||||
|
||||
# [Inhalt folgt in Phase 3]
|
||||
|
|
|
|||
File diff suppressed because it is too large
Load diff
File diff suppressed because it is too large
Load diff
File diff suppressed because it is too large
Load diff
File diff suppressed because it is too large
Load diff
File diff suppressed because it is too large
Load diff
|
|
@ -1,66 +0,0 @@
|
|||
# =============================================================================
|
||||
# SHM VOICE-OF-CUSTOMER (VoC) KONZEPT
|
||||
# =============================================================================
|
||||
#
|
||||
# Voice-of-Customer Methodik im Stakeholder-Management.
|
||||
# Status: Placeholder mit SPM-Schnittstelle
|
||||
# =============================================================================
|
||||
|
||||
metadata:
|
||||
name: "Voice-of-Customer (VoC) Konzept"
|
||||
version: "0.1"
|
||||
status: "placeholder"
|
||||
erstellt: "2025-12-17"
|
||||
projekt: "DIGITOM"
|
||||
organisation: "Stadt Freiburg / DIGIT"
|
||||
|
||||
beschreibung: >
|
||||
Voice-of-Customer Methodik zur systematischen Erfassung und
|
||||
Aufbereitung von Kundenrueckmeldungen. Dieses Dokument ist ein
|
||||
Placeholder und enthaelt vorerst nur die SPM-Schnittstelle.
|
||||
|
||||
referenzen:
|
||||
service_review_konzept: "02_service-portfolio-management/02.1_spm_konzepte/02a_lifecycle-konzepte/spm_konzept_service-review.yaml"
|
||||
governance_entscheidungen: "GOV-SR-001"
|
||||
|
||||
# =============================================================================
|
||||
# SCHNITTSTELLE ZU SPM SERVICE-REVIEW
|
||||
# =============================================================================
|
||||
|
||||
spm_schnittstelle:
|
||||
|
||||
beschreibung: |
|
||||
Der VoC-Cluster D2 (Service-Qualitaet) liefert Input fuer die
|
||||
Service-Review-Dimension "Nutzerzufriedenheit" (SR-D3).
|
||||
|
||||
referenz: "spm_konzept_service-review.yaml -> bewertungsschema.dimensionen.SR-D3"
|
||||
governance_referenz: "GOV-SR-001"
|
||||
|
||||
nutzung_im_service_review:
|
||||
input_fuer_dimension: "SR-D3 Nutzerzufriedenheit"
|
||||
datenquelle: "VoC-Erkenntnisse aus SHM E2-Reports (Cluster D2)"
|
||||
verantwortlich: "SO bezieht SHM-Erkenntnisse in Review ein"
|
||||
|
||||
indikatoren_aus_shm:
|
||||
- "Support-Feedback (Zufriedenheit nach Ticket-Abschluss)"
|
||||
- "Beschwerden und Eskalationen"
|
||||
- "VoC-Signale aus Stakeholder-Gespraechen"
|
||||
- "Informelle Rueckmeldungen via SM"
|
||||
|
||||
synchronisation:
|
||||
beschreibung: |
|
||||
SHM E2-Review liefert VoC-Erkenntnisse als Input fuer den
|
||||
quartalsweisen Service-Review.
|
||||
sequenz: "SHM E2-Review -> VoC-Erkenntnisse -> Service-Review nutzt D2-Cluster"
|
||||
|
||||
# =============================================================================
|
||||
# AENDERUNGSHISTORIE
|
||||
# =============================================================================
|
||||
|
||||
aenderungshistorie:
|
||||
- version: "0.1"
|
||||
datum: "2025-12-17"
|
||||
aenderung: |
|
||||
- Placeholder erstellt mit SPM-Schnittstelle fuer Service-Review (GOV-SR-001)
|
||||
autor: "DIGITOM-Projekt"
|
||||
referenz: "spm_konzept_service-review.yaml"
|
||||
|
|
@ -1,20 +1,20 @@
|
|||
# ========================================
|
||||
# SHM-Integration in der Service-Operation-Runde
|
||||
# ========================================
|
||||
# Version: 0.1 (Platzhalter)
|
||||
# Datum: 2024-12-03
|
||||
# Status: Ausstehend
|
||||
# Entwicklungsphase: 6
|
||||
# ========================================
|
||||
|
||||
# ITIL4-Referenz (falls zutreffend):
|
||||
# itil4_referenz:
|
||||
# practice: ""
|
||||
# relevante_elemente: []
|
||||
# adaption_fuer_digitom: ""
|
||||
|
||||
# ========================================
|
||||
# INHALT
|
||||
# ========================================
|
||||
|
||||
# [Inhalt folgt in Phase 6]
|
||||
# ========================================
|
||||
# SHM-Integration in der Service-Operation-Runde
|
||||
# ========================================
|
||||
# Version: 0.1 (Platzhalter)
|
||||
# Datum: 2024-12-03
|
||||
# Status: Ausstehend
|
||||
# Entwicklungsphase: 6
|
||||
# ========================================
|
||||
|
||||
# ITIL4-Referenz (falls zutreffend):
|
||||
# itil4_referenz:
|
||||
# practice: ""
|
||||
# relevante_elemente: []
|
||||
# adaption_fuer_digitom: ""
|
||||
|
||||
# ========================================
|
||||
# INHALT
|
||||
# ========================================
|
||||
|
||||
# [Inhalt folgt in Phase 6]
|
||||
|
|
|
|||
File diff suppressed because it is too large
Load diff
File diff suppressed because it is too large
Load diff
|
|
@ -1,470 +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"
|
||||
# =============================================================================
|
||||
# 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"
|
||||
|
|
@ -1,20 +0,0 @@
|
|||
# ========================================
|
||||
# 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]
|
||||
File diff suppressed because it is too large
Load diff
Loading…
Add table
Add a link
Reference in a new issue