feat(i2s-problem-statement): extract from monolith
Step 5 of i2s-skill-split refactor. Second atomic sub-skill. Contents: - SKILL.md: 5 numbered phases (load context, 7 TAs, consistency, 3 variants, export). description with explicit HMW/Problem-Statement triggers, anti-triggers naming klarheit-mit-idea2self (router), i2s-discovery, i2s-persona. Precondition check formalized. - workflows/problem-statement.md: full workflow (git mv from monolith, rename detection preserved, required_reading paths updated to local curated refs). - references/kommunikationsregeln.md: curated (PS-specific dialog heuristics: loesung-vs-problem, "alle als zielgruppe", widerspruch zu idee). - references/problem-statement-format.md: curated extract from plugin-shared/export-formate.md, problem_statement_format block. Includes versions header rules and a filled example. - references/artefakt-pipeline.md: curated (pipeline position + rueckwaerts-updates rules for PS -> ## Idee back-propagation). Tools: Read, Write, Edit, Glob, Grep, AskUserQuestion, TodoRead, TodoWrite. (No WebFetch/WebSearch — recherche lives in i2s-recherche.)
This commit is contained in:
Philipp Sieder
@@ -0,0 +1,123 @@
|
||||
---
|
||||
name: i2s-problem-statement
|
||||
description: "Idea2Self Problem-Statement-Workflow. Formuliert das HMW-Statement (How Might We) ueber 7 gefuehrte Teilaspekte (WAS / WER / WARUM / WO / WANN / BISHERIGE ANSAETZE / WIE) und erzeugt 3 Varianten (wortgetreu / geschaerft / zugespitzt) zur Auswahl. Loest aus bei 'Problem-Statement erstellen', 'HMW formulieren', 'Wie koennen wir', 'Problem formulieren', 'Problem fuer meine Idee schaerfen', 'PS erstellen'. NICHT aktivieren bei: 'Idea2Self starten' (Router), 'Persona erstellen' (i2s-persona), 'vage Idee strukturieren' ohne bestehende ## Idee Sektion (dafuer i2s-discovery zuerst). Vorbedingung: idea2self-Datei mit ausgefuellter ## Idee Sektion. Output: ## Problem-Statement Sektion in derselben Datei. Sprache: Deutsch."
|
||||
allowed-tools: Read Write Edit Glob Grep AskUserQuestion TodoRead TodoWrite
|
||||
---
|
||||
|
||||
# i2s-problem-statement — Problem-Statement (HMW)
|
||||
|
||||
Schritt 2 im Idea2Self-Prozess. Formuliert aus der vagen `## Idee` ein scharfes Problem-Statement im **How Might We**-Format. Erzeugt 3 Varianten zur Auswahl und schreibt die finale Version in die idea2self-Datei.
|
||||
|
||||
## Essential Principles
|
||||
|
||||
1. **Aus Sicht der Zielgruppe, nicht der Loesung.** Problem-Statement beschreibt das Beduerfnis, nicht den geplanten Ansatz. "Wie koennen wir [Kontext] fuer [Zielgruppe] neu gestalten, damit [Beduerfnis] befriedigt wird — unter Beruecksichtigung von [Einschraenkungen]."
|
||||
2. **7 Teilaspekte sind Pflicht, aber Tiefe ist adaptiv.** Pro Teilaspekt 1 Leitfrage + max 1 Vertiefung. Wenn Nutzer schon klar geantwortet hat -> weiter. Wenn vage -> Vertiefung.
|
||||
3. **Drei Varianten, dann eine.** Wortgetreu / geschaerft / zugespitzt sind Sparring-Tool, nicht Output. Der Nutzer waehlt, kombiniert, der Skill iteriert max. 1× nach.
|
||||
4. **Konsistenz gegen ## Idee.** Wenn Problem-Statement der Idee widerspricht (andere Zielgruppe / anderes Problem): explizit benennen, Update auf `## Idee` vorschlagen (Changelog-Eintrag).
|
||||
5. **"Alle als Zielgruppe" ist nicht akzeptabel.** Im PS-Workflow muss die Zielgruppe konkreter werden als in `## Idee`. Wenn Nutzer ausweicht: Sub-Frage "Wer hat das Problem am DRINGENDSTEN?" einsetzen.
|
||||
|
||||
## When to Use
|
||||
|
||||
- `## Idee` existiert in der idea2self-Datei, `## Problem-Statement` fehlt oder soll iteriert werden.
|
||||
- Aus Router-Hand-off (Pfad 2) oder direkter Trigger ("Problem-Statement erstellen", "HMW").
|
||||
- Iteration nach Recherche: Nutzer hat neue Daten und will PS v0.2 schreiben.
|
||||
|
||||
## When NOT to Use
|
||||
|
||||
- `## Idee` fehlt oder ist nur eine Ueberschrift -> erst `i2s-discovery`.
|
||||
- Nutzer will direkt zur Persona -> `i2s-persona` (PS bleibt erstmal vage).
|
||||
- Nutzer will den Loesungs-Ansatz schaerfen -> `i2s-prototyp-konzept` oder `i2s-experiment-card`.
|
||||
|
||||
## Precondition Check
|
||||
|
||||
**Vor Phase 1:**
|
||||
1. idea2self-Datei laden (Pfad aus Nutzer-Prompt oder Standardort).
|
||||
2. Auf `^## Idee` matchen + Sektion-Inhalt > 50 Zeichen.
|
||||
3. Fehlt -> abbrechen mit Hinweis: "`## Idee` fehlt in `<datei>`. Trigger zuerst `i2s-discovery`."
|
||||
|
||||
## Phases
|
||||
|
||||
### Phase 1 — Kontext laden + Voranalyse
|
||||
|
||||
**Entry:** Vorbedingung erfuellt.
|
||||
|
||||
**Aktionen:**
|
||||
1. Aus `## Idee` extrahieren: Kern, Zielgruppen-Vermutung, Problem-Vermutung, Kontext, Einschraenkungen.
|
||||
2. Nutzer Voranalyse zeigen: "Aus deiner Idee lese ich: Problem = [X], Zielgruppe = [Y], Kontext = [Z]. Ich gehe jetzt 7 Teilaspekte mit dir durch. [1] von 7."
|
||||
3. Wenn `## Problem-Statement` bereits existiert: Aenderungsmodus aktivieren — nur abweichende Aspekte durchgehen, Status mit Checkmarks zeigen.
|
||||
|
||||
**Exit:** Nutzer hat Voranalyse bestaetigt oder korrigiert.
|
||||
|
||||
### Phase 2 — 7 Teilaspekte (gefuehrte Fragen)
|
||||
|
||||
**Entry:** Phase 1 abgeschlossen.
|
||||
|
||||
**Aktionen:**
|
||||
1. Pro Teilaspekt (siehe `workflows/problem-statement.md` Schritt 2): 1 Leitfrage stellen.
|
||||
2. Bei vager Antwort: 1 Vertiefungs-Frage.
|
||||
3. Anti-Pattern-Detection (Loesung statt Problem, Zielgruppe "alle", zu abstrakt, Beduerfnis unklar) — bei Match: Korrektur-Frage.
|
||||
4. Antworten als `_(Vorschlag)_` oder `_(Annahme)_` markieren, je nach Quelle.
|
||||
|
||||
**Exit:** Alle 7 TAs sind beruehrt (mit Antwort, "Ich weiss nicht", oder explizitem Ueberspringen).
|
||||
|
||||
### Phase 3 — Konsistenzpruefung
|
||||
|
||||
**Entry:** 7 TAs durch.
|
||||
|
||||
**Aktionen:**
|
||||
1. Intern pruefen: Passt Zielgruppe zum Problem? Ist Beduerfnis aus Zielgruppen-Perspektive? Widerspricht etwas der `## Idee`?
|
||||
2. Bei Inkonsistenz: explizit benennen, Anpassung vorschlagen.
|
||||
3. Bei Inkonsistenz zu `## Idee`: Rueckwaerts-Update anbieten (siehe `references/artefakt-pipeline.md`).
|
||||
|
||||
**Exit:** Keine offenen Konsistenz-Konflikte, oder offene Konflikte sind als `## Offene Punkte` in der Datei vermerkt.
|
||||
|
||||
### Phase 4 — Drei Varianten erzeugen
|
||||
|
||||
**Entry:** Phase 3 abgeschlossen.
|
||||
|
||||
**Aktionen:**
|
||||
1. Variante A (wortgetreu): nah an Nutzer-Formulierungen, minimal verdichtet.
|
||||
2. Variante B (geschaerft): sprachlich praeziser, KI-Ergaenzungen als `_(Vorschlag)_`.
|
||||
3. Variante C (zugespitzt): schaerfster Fokus, Mentor-Ziele Loesbarkeit / Wichtigkeit / Erreichbarkeit.
|
||||
4. Drei Varianten zeigen, Nutzer waehlt oder kombiniert.
|
||||
5. Max. 1 Iteration nach Auswahl.
|
||||
|
||||
**Exit:** Eine finale PS-Variante ist gewaehlt.
|
||||
|
||||
### Phase 5 — Export
|
||||
|
||||
**Entry:** Phase 4 abgeschlossen.
|
||||
|
||||
**Aktionen:**
|
||||
1. `## Problem-Statement` Sektion in idea2self-Datei schreiben (Schema: `references/problem-statement-format.md`).
|
||||
2. Versions-Header (V1 fuer erste Erstellung, sonst V[prev+1]).
|
||||
3. Changelog-Eintrag: `[Datum] PS V<n> formuliert / iteriert.`
|
||||
4. Hand-off: "Dein Problem-Statement ist in der Datei. Naechster Schritt: Persona. Trigger: 'Persona erstellen' fuer `i2s-persona`. Oder 'Weiter'."
|
||||
|
||||
**Exit:** Datei aktualisiert, Hand-off ausgesprochen.
|
||||
|
||||
## Quick Reference
|
||||
|
||||
Kommunikation: `references/kommunikationsregeln.md`.
|
||||
Pipeline + Rueckwaerts-Update-Regeln: `references/artefakt-pipeline.md`.
|
||||
Format-Schema: `references/problem-statement-format.md`.
|
||||
Workflow-Detail (alle 5 Schritte, alle 7 TAs, alle Anti-Patterns): `workflows/problem-statement.md`.
|
||||
|
||||
## Reference Index
|
||||
|
||||
| File | Purpose |
|
||||
|------|---------|
|
||||
| `workflows/problem-statement.md` | Vollstaendiger 5-Schritt-Ablauf mit den 7 Teilaspekten + Anti-Patterns |
|
||||
| `references/kommunikationsregeln.md` | Tonalitaet, Marker, Steuerbefehle (curated) |
|
||||
| `references/problem-statement-format.md` | Markdown-Schema fuer `## Problem-Statement` (HMW-Satz + 6 Sub-Sektionen) |
|
||||
| `references/artefakt-pipeline.md` | Pipeline-Position + Rueckwaerts-Update-Regeln (curated) |
|
||||
|
||||
## Success Criteria
|
||||
|
||||
- [ ] Alle 7 Teilaspekte sind bearbeitet oder bewusst markiert.
|
||||
- [ ] HMW-Satz ist formuliert (`Wie koennen wir [Kontext] fuer [Zielgruppe]...`).
|
||||
- [ ] Zielgruppe ist konkreter als in `## Idee`.
|
||||
- [ ] Problem ist aus Zielgruppen-Sicht formuliert, nicht aus Loesungs-Sicht.
|
||||
- [ ] Scope-Ausschluss ist explizit benannt (in `## Idee` oder `## Problem-Statement`).
|
||||
- [ ] idea2self-Datei enthaelt `## Problem-Statement` mit Versions-Header + Changelog-Eintrag.
|
||||
- [ ] Hand-off zu `i2s-persona` ist ausgesprochen.
|
||||
@@ -0,0 +1,40 @@
|
||||
# Artefakt-Pipeline — i2s-problem-statement (curated extract)
|
||||
|
||||
Curated from `plugin-shared/artefakt-pipeline.md`. Nur PS-relevante Pipeline-Mechanik.
|
||||
|
||||
## Position in der Pipeline
|
||||
|
||||
```
|
||||
Discovery -> [Problem-Statement v0.1] -> Persona v0.1 -> Recherche (v0.2) -> Experiment -> Prototyp -> Action-Plan
|
||||
```
|
||||
|
||||
PS ist Schritt 2. Vorbedingung: `## Idee`. Nachfolge-Schritt: Persona (i2s-persona).
|
||||
|
||||
## Kontextweitergabe
|
||||
|
||||
- Vor PS-Workflow: idea2self-Datei lesen, `## Idee` extrahieren.
|
||||
- Nach PS-Workflow: `## Problem-Statement` als neue Sektion in derselben Datei schreiben.
|
||||
- Kein Copy-Paste durch Nutzer noetig — die Datei IST der Kontext.
|
||||
|
||||
## Versionierung
|
||||
|
||||
- **v0.1** = Erstversion aus PS-Workflow-Durchlauf direkt nach Discovery.
|
||||
- **v0.2** = Ueberarbeitete Version nach Recherche-Erkenntnissen (Schritt 4) oder Feedback.
|
||||
- Versions-Header im PS-Abschnitt: `_Version V[n] vom [Datum]_` + `_Vorgaengerversion: V[n-1] vom [Datum]_`.
|
||||
- Bei Iteration: Alte Inhalte beibehalten, nur geaenderte Stellen ersetzen, Aenderungen mit Datum markieren.
|
||||
|
||||
## Rueckwaerts-Updates
|
||||
|
||||
Wenn der PS-Workflow Erkenntnisse liefert, die `## Idee` widersprechen:
|
||||
|
||||
1. Betroffene Sub-Sektion in `## Idee` identifizieren.
|
||||
2. Nutzer informieren: "Aus dem PS-Dialog lese ich [X], in `## Idee` steht [Y]. Soll `## Idee` aktualisiert werden?"
|
||||
3. Bei Bestaetigung: Aenderung in `## Idee` als `_(Update aus PS-Workflow, [Datum])_` markieren.
|
||||
4. Im `## Changelog` der Datei dokumentieren: `[Datum] ## Idee Update aus PS-Workflow: [kurzbeschreibung].`
|
||||
5. Versions-Header von `## Idee` bumpen (V1 -> V2).
|
||||
|
||||
Diese Mechanik gilt fuer PS gegenueber `## Idee`. Andere Rueckwaerts-Updates (Recherche -> PS, Experiment -> Persona, etc.) leben in den jeweiligen Sub-Skills.
|
||||
|
||||
---
|
||||
|
||||
**Master version:** `plugin-shared/artefakt-pipeline.md`. Drift-check via `plugin-shared/drift-check.sh`.
|
||||
@@ -0,0 +1,48 @@
|
||||
# Kommunikationsregeln — i2s-problem-statement (curated extract)
|
||||
|
||||
Curated from `plugin-shared/kommunikationsregeln.md`. PS-Workflow-relevante Regeln.
|
||||
|
||||
<tonality>
|
||||
Nuechtern, sachlich, ruhig. Keine motivierenden Formulierungen, keine Emojis, keine Superlative. Alltagssprache statt Fachbegriffe. Sprache des Nutzers beibehalten. Kurze Saetze.
|
||||
</tonality>
|
||||
|
||||
<message_format>
|
||||
- Max. 3-4 Saetze pro Nachricht im Dialog.
|
||||
- Fortschrittsanzeige: "[X] von 7" bei jeder TA-Frage.
|
||||
- Bei Varianten-Phase: 3 Bloecke (A/B/C) klar abgegrenzt zeigen.
|
||||
</message_format>
|
||||
|
||||
<kennzeichnung>
|
||||
| Marker | Bedeutung |
|
||||
|--------|-----------|
|
||||
| _(Vorschlag)_ | KI-generiert, nicht bestaetigt — z.B. geschaerfte Variante B/C |
|
||||
| _(Annahme)_ | Vom Nutzer geaeussert ohne Datengrundlage |
|
||||
| _(Aus ## Idee uebernommen)_ | Import aus frueherer Sektion |
|
||||
</kennzeichnung>
|
||||
|
||||
<steuerbefehle>
|
||||
| Befehl | Aktion |
|
||||
|--------|--------|
|
||||
| Zurueck | Vorheriger Teilaspekt |
|
||||
| Ich weiss es nicht | Plausibler Vorschlag, kein Drang |
|
||||
| Ueberspringen | TA als "Nicht erarbeitet" markieren |
|
||||
| Weiter | Naechster TA oder Phase |
|
||||
| Variante A/B/C | In Phase 4: Auswahl der Variante |
|
||||
</steuerbefehle>
|
||||
|
||||
<dialog_heuristiken_problem_statement>
|
||||
- **Loesung statt Problem:** "Du beschreibst gerade eine Loesung ([X]). Welches Problem dahinter willst du loesen?"
|
||||
- **"Alle als Zielgruppe":** "Wer hat das Problem am DRINGENDSTEN? Welche Untergruppe leidet zuerst?"
|
||||
- **Zu abstrakt:** Konkretes Beispiel einfordern. "Erzaehl von einer konkreten Person, die das vergangene Woche erlebt hat."
|
||||
- **Beduerfnis aus Loesungs-Sicht formuliert:** "Was wuerde sich fuer die Zielgruppe konkret aendern, ohne dass du etwas vorgibst?"
|
||||
- **Widerspruch zu ## Idee:** explizit benennen. "In `## Idee` steht [A], jetzt sagst du [B]. Was gilt? Soll `## Idee` aktualisiert werden?"
|
||||
- **Perfektionismus / endlose Iteration:** Cut nach 1 Variante-Iteration. "Das ist v0.1. Wir koennen spaeter ueberarbeiten."
|
||||
</dialog_heuristiken_problem_statement>
|
||||
|
||||
<export_rule>
|
||||
Phase 5 schreibt `## Problem-Statement` Sektion + Versions-Header + Changelog-Eintrag. Schema: `references/problem-statement-format.md`. Nicht behandelte TAs erscheinen als "Nicht erarbeitet". Vorschlaege als `_(Vorschlag)_` belassen, bis Nutzer bestaetigt.
|
||||
</export_rule>
|
||||
|
||||
---
|
||||
|
||||
**Master version:** `plugin-shared/kommunikationsregeln.md`. Drift-check via `plugin-shared/drift-check.sh`.
|
||||
@@ -0,0 +1,82 @@
|
||||
# Problem-Statement-Format — i2s-problem-statement (curated extract)
|
||||
|
||||
Curated from `plugin-shared/export-formate.md` — `<problem_statement_format>` block.
|
||||
|
||||
## Schema fuer `## Problem-Statement` Sektion
|
||||
|
||||
```markdown
|
||||
## Problem-Statement
|
||||
|
||||
> **„Wie koennen wir [Kontext] fuer [Zielgruppe] neu gestalten, damit [Beduerfnis] befriedigt wird – unter Beruecksichtigung von [Einschraenkungen]."**
|
||||
|
||||
_Version [V1/V2/...] vom [Datum]_
|
||||
_Vorgaengerversion: [V<n-1> vom <Datum>] / Keine - Neuerstellung_
|
||||
|
||||
### Kontext – Was wird neu gestaltet?
|
||||
[Zusammenfassung aus TA1 (WAS), TA4 (WO), TA5 (WANN), TA6 (BISHERIGE ANSAETZE).]
|
||||
|
||||
### Zielgruppe – Fuer wen?
|
||||
[Zusammenfassung aus TA2. Konkretes Segment, nicht "alle". Konkrete Anker-Person erlaubt.]
|
||||
|
||||
### Beduerfnis – Was soll erreicht werden?
|
||||
[Zusammenfassung aus TA3. Aus Zielgruppen-Sicht formuliert, nicht aus Loesungs-Sicht.]
|
||||
|
||||
### Einschraenkungen – Was muss beruecksichtigt werden?
|
||||
[Zusammenfassung aus TA4, TA5, TA6 — Constraints, Ressourcen, was bisherige Loesungen NICHT koennen.]
|
||||
|
||||
### Loesungsrichtung _(Hintergrund)_
|
||||
[Zusammenfassung aus TA7. Wird als Hintergrund markiert, NICHT Teil des HMW-Statements.]
|
||||
|
||||
### Offene Punkte
|
||||
- [ ] [Nur wenn geparkte Gedanken aus dem PS-Workflow vorhanden]
|
||||
```
|
||||
|
||||
## Schreibregeln
|
||||
|
||||
1. **HMW-Satz** als Markdown-Blockquote (`>`) — visuell hervorgehoben.
|
||||
2. **Versions-Header:** V1 fuer Erstellung, V[n+1] fuer Iteration. Vorgaengerversion mit Datum referenzieren.
|
||||
3. **TAs mit "Nicht erarbeitet":** Sub-Sektion bleibt mit dem Text `Nicht erarbeitet` (nicht weglassen).
|
||||
4. **Vorschlag-Marker:** KI-Ergaenzungen (z.B. wenn TA-Antwort verdichtet wurde) mit `_(Vorschlag)_`.
|
||||
5. **Annahme-Marker:** Nutzer-Aussagen ohne Datengrundlage mit `_(Annahme)_`.
|
||||
6. **Aus-Idee-Marker:** Imports aus `## Idee` mit `_(Aus Idee uebernommen)_`.
|
||||
7. **Loesungsrichtung:** explizit als `_(Hintergrund)_` markieren, damit klar ist dass dies NICHT Teil des HMW-Statements ist.
|
||||
|
||||
## Beispiel (gefuellt, V1)
|
||||
|
||||
```markdown
|
||||
## Problem-Statement
|
||||
|
||||
> **„Wie koennen wir die geringe Nutzung lokaler Tauschmoeglichkeiten fuer Mieter in mittelgrossen Mehrfamilienhaeusern (8-30 Parteien) neu gestalten, damit das Beduerfnis nach niedrigschwelligem Geben/Nehmen ohne App-Pflicht befriedigt wird – unter Beruecksichtigung von Print-only-Distribution und 4-6h/Woche Founder-Zeitbudget."**
|
||||
|
||||
_Version V1 vom 2026-05-19_
|
||||
_Vorgaengerversion: Keine - Neuerstellung_
|
||||
|
||||
### Kontext – Was wird neu gestaltet?
|
||||
Die alltaegliche Frage "Wer hat eine Bohrmaschine kurz fuer mich?". Heute via
|
||||
Whatsapp-Gruppe (wenn vorhanden) oder gar nicht. Karten-basiert _(Annahme)_
|
||||
senkt die Schwelle fuer App-averse Nachbarn.
|
||||
|
||||
### Zielgruppe – Fuer wen?
|
||||
Mieter in Mehrfamilienhaeusern mit 8-30 Parteien in deutschen Staedten.
|
||||
Anker-Person: Anna, 38, 6 Jahre im Haus, kennt 4 Nachbarn mit Namen.
|
||||
|
||||
### Beduerfnis – Was soll erreicht werden?
|
||||
Spontane, niedrigschwellige Verfuegbarkeit von Werkzeugen/Gegenstaenden
|
||||
zwischen Nachbarn — ohne App, ohne Account, ohne Marketplace-Friction.
|
||||
|
||||
### Einschraenkungen – Was muss beruecksichtigt werden?
|
||||
- Kein Smartphone-Zwang (existierende Whatsapp-Loesungen scheitern hier).
|
||||
- Print-Distribution muss skalieren ohne Founder-Zeitexplosion.
|
||||
- Hausverwaltung als Distributions-Hebel ist offen _(Annahme)_.
|
||||
|
||||
### Loesungsrichtung _(Hintergrund)_
|
||||
Karten-Set + Hausflur-Aushaengetafel, ggf. spaeter web-Liste fuer Hausverwaltung.
|
||||
|
||||
### Offene Punkte
|
||||
- [ ] Druckkosten fuer ein Karten-Set pruefen.
|
||||
- [ ] Hausverwaltungs-Hypothese in Recherche validieren.
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
**Master version:** `plugin-shared/export-formate.md`. Drift-check via `plugin-shared/drift-check.sh`.
|
||||
@@ -0,0 +1,99 @@
|
||||
# Workflow: Problem-Statement erstellen
|
||||
|
||||
<required_reading>
|
||||
1. references/kommunikationsregeln.md
|
||||
2. references/export-formate.md (Abschnitt problem_statement_format)
|
||||
3. references/artefakt-pipeline.md
|
||||
</required_reading>
|
||||
|
||||
<process>
|
||||
|
||||
## Schritt 1: Kontext laden
|
||||
|
||||
Lies die idea2self-Datei. Extrahiere aus ## Idee:
|
||||
- Kern der Idee
|
||||
- Erste Zielgruppen-Vermutung
|
||||
- Problem-Vermutung
|
||||
- Kontext und Einschraenkungen
|
||||
|
||||
Zeige dem Nutzer eine Voranalyse:
|
||||
"Aus deiner Idee lese ich: Problem = [X], Zielgruppe = [Y], Kontext = [Z].
|
||||
Ich gehe jetzt 7 Teilaspekte mit dir durch. [1] von 7."
|
||||
|
||||
Wenn Ueberarbeitung (bestehender PS-Export als Input):
|
||||
- Aenderungsmodus: Nur abweichende Aspekte durchgehen.
|
||||
- Status anzeigen mit Checkmarks/Pfeilen.
|
||||
|
||||
## Schritt 2: Gefuehrte Fragen (7 Teilaspekte)
|
||||
|
||||
Pro Teilaspekt: 1 Leitfrage + ggf. 1 Vertiefung. Max. 1 Rueckfrage.
|
||||
|
||||
**TA1 - WAS? (Kontext)**
|
||||
"Was genau soll anders werden? Beschreib die Situation, die du veraendern willst."
|
||||
Vertiefung: "Woran wuerde jemand merken, dass sich etwas verbessert hat?"
|
||||
|
||||
**TA2 - WER? (Zielgruppe)**
|
||||
"Wer hat dieses Problem am staerksten? Beschreib eine konkrete Situation."
|
||||
Vertiefung: "Gibt es Untergruppen? Wer hat das Problem am dringendsten?"
|
||||
|
||||
**TA3 - WARUM? (Beduerfnis)**
|
||||
"Warum ist das ein Problem? Was passiert, wenn nichts passiert?"
|
||||
Vertiefung: "Welches tiefere Beduerfnis steckt dahinter?"
|
||||
|
||||
**TA4 - WO? (Umfeld)**
|
||||
"In welchem Kontext tritt das Problem auf? (Ort, Situation, Zeitpunkt)"
|
||||
|
||||
**TA5 - WANN? (Zeitliche Dimension)**
|
||||
"Wie dringend ist das? Gibt es einen Zeitdruck oder Saisonalitaet?"
|
||||
|
||||
**TA6 - BISHERIGE ANSAETZE?**
|
||||
"Wie loesen betroffene Menschen das Problem heute? Was funktioniert nicht?"
|
||||
|
||||
**TA7 - WIE? (Loesungsrichtung, Hintergrund)**
|
||||
"Hast du schon eine Vorstellung, wie eine Loesung aussehen koennte?"
|
||||
Hinweis: Wird als Hintergrund markiert, nicht Teil des Problem Statements.
|
||||
|
||||
Anti-Patterns (Vertiefungsausloeser):
|
||||
1. Loesung statt Problem beschrieben -> Zurueck auf Problem lenken
|
||||
2. Zielgruppe = "alle" -> Einschraenken auf konkretestes Segment
|
||||
3. Problem zu abstrakt -> Konkretes Beispiel einfordern
|
||||
4. Beduerfnis unklar -> "Was wuerde sich fuer [Zielgruppe] aendern?"
|
||||
|
||||
## Schritt 3: Konsistenzpruefung
|
||||
|
||||
Intern pruefen:
|
||||
- Passt Zielgruppe zum Problem?
|
||||
- Ist das Beduerfnis aus Sicht der Zielgruppe formuliert (nicht aus Sicht des Nutzers)?
|
||||
- Widerspricht etwas der ## Idee?
|
||||
|
||||
Bei Inkonsistenz: Benennen und Anpassung vorschlagen.
|
||||
|
||||
## Schritt 4: Varianten-Entwurf
|
||||
|
||||
Erzeuge 3 Varianten des Problem-Statements:
|
||||
1. **Wortgetreu:** Moeglichst nah an den Formulierungen des Nutzers.
|
||||
2. **Geschaerft:** Sprachlich verdichtet. Ergaenzungen mit _(Vorschlag)_.
|
||||
3. **Zugespitzt:** Fokussiert auf den schaerfsten Aspekt. Mentor-Ziele: Loesbarkeit, Wichtigkeit, Erreichbarkeit.
|
||||
|
||||
"Welche Variante passt am besten? Du kannst auch Elemente kombinieren."
|
||||
|
||||
Max. 1 Iteration nach der Auswahl.
|
||||
|
||||
## Schritt 5: Export in idea2self-Datei
|
||||
|
||||
Schreibe ## Problem-Statement in die idea2self-Datei (nach export-formate.md).
|
||||
Changelog-Eintrag hinzufuegen.
|
||||
|
||||
Uebergabe:
|
||||
"Dein Problem-Statement ist in der Datei. Der naechste Schritt ist die Persona. Sage 'Weiter' oder 'Zurueck'."
|
||||
|
||||
</process>
|
||||
|
||||
<success_criteria>
|
||||
- [ ] Alle 7 Teilaspekte bearbeitet oder bewusst uebersprungen
|
||||
- [ ] HMW-Satz formuliert (Wie koennen wir...)
|
||||
- [ ] Zielgruppe ist konkreter als in ## Idee
|
||||
- [ ] Problem ist aus Sicht der Zielgruppe formuliert
|
||||
- [ ] Scope-Ausschluss ist klar
|
||||
- [ ] idea2self-Datei aktualisiert mit ## Problem-Statement
|
||||
</success_criteria>
|
||||
Reference in New Issue
Block a user