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,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"
|
||||
Loading…
Add table
Add a link
Reference in a new issue