1. Projektkontext
Meety ist eine App, die zwei Probleme von Gruppen gleichzeitig löst:
- Wann? Automatische Ermittlung gemeinsamer Termine aus den Verfügbarkeiten aller Gruppenmitglieder.
- Was? Aktivitätsvorschläge werden per Swipen (Tinder-Prinzip) bewertet und Gruppen-Matches werden identifiziert.
Zielgruppen sind Freundesgruppen, Vereine und Arbeitsgruppen. Event-Locations kommen als potenzielle Werbe- und Monetarisierungspartner hinzu.
2. Stakeholder-Liste
Bewertungsskala jeweils 1 (niedrig) bis 5 (hoch).
2.1 Interne Stakeholder
| ID | Stakeholder | Rolle im Projekt | Einfluss | Interesse | Quadrant |
|---|---|---|---|---|---|
| S1 | Gründer / Product Owner / Entwickler (ich) | Idee, Vision, Priorisierung, Umsetzung | 5 | 5 | Eng einbinden |
| S2 | Dozent / Prüfer | Bewertet Artefakte und Review-Video | 5 | 4 | Eng einbinden |
2.2 Externe Stakeholder
| ID | Stakeholder | Rolle im Projekt | Einfluss | Interesse | Quadrant |
|---|---|---|---|---|---|
| S3 | Gruppen-Organisator (“Power-User”) | Erstellt Gruppen, treibt Terminfindung an | 4 | 5 | Eng einbinden |
| S4 | Passives Gruppenmitglied | Trägt nur Verfügbarkeiten ein, swipt gelegentlich | 2 | 3 | Informieren |
| S5 | Vereinsvorstand / Übungsleiter | Koordiniert wiederkehrende Termine größerer Gruppen | 3 | 4 | Informieren |
| S6 | Team-Lead / Arbeitsgruppe | Nutzt App für informelle Team-Events | 3 | 3 | Informieren |
| S7 | Event-Locations & Gastronomie | Wollen Sichtbarkeit, zahlen ggf. für Platzierung | 2 | 4 | Informieren |
| S8 | Datenschutzbehörden / DSGVO | Regulieren Umgang mit Kalender- und Standortdaten | 5 | 2 | Zufriedenstellen |
| S9 | Hosting-Provider | Verfügbarkeit, Kosten, Datenstandort | 4 | 2 | |
| S10 | Drittanbieter-APIs (Wetter, AI) | Liefern Daten für Could-have Features | 2 | 2 | Beobachten |
3. Einfluss-Interesse-Matrix (Power/Interest Grid)
quadrantChart title Einfluss-Interesse-Matrix x-axis "Niedriges Interesse" --> "Hohes Interesse" y-axis "Geringer Einfluss" --> "Hoher Einfluss" %%quadrant-1 "Eng einbinden (manage closely)" %%quadrant-2 "Zufriedenstellen (keep satisfied)" %%quadrant-3 "Beobachten (monitor)" %%quadrant-4 "Informieren (keep informed)" "S1 PO/Dev": [0.92, 0.96] "S2 Dozent/Pruefer": [0.87, 0.6] "S3 Organisator": [0.9, 0.8] "S4 Passives Mitglied": [0.62, 0.32] "S5 Verein": [0.72, 0.56] "S6 Team-Lead": [0.60, 0.52] "S7 Event-Locations": [0.76, 0.40] "S8 Datenschutz": [0.3, 0.90] "S9 Hosting": [0.25, 0.75] "S10 Drittanbieter-APIs": [0.2, 0.3]
4. Erwartungen und Bedürfnisse je Stakeholder
Quadrant: Eng einbinden
S1 als Product Owner
Erwartet ein Produkt, das das Kernproblem (Termin und Aktivität) in einem Flow löst, statt es wie bestehende Tools zu trennen.
Bedürfnis: klare Priorisierung, ein demonstrierbarer MVP, eine tragfähige Produktvision.
S1 als Entwickler: Erwartet Stories, die klein genug für einen Sprint sind, und eine technisch beherrschbare Architektur. Bedürfnis: eindeutige Akzeptanzkriterien, stabile Schnittstellen (Kalender, Karten), kein Scope Creep durch Could-haves.
S2: Dozent / Prüfer:in
Erwartet die vollständige, methodisch saubere Anwendung des agilen Produktdenkens:
- nachvollziehbare Stakeholderanalyse
- realistische Personas
- korrekt formatierte User Stories mit Akzeptanzkriterien
- konsequenter MoSCoW-Priorisierung
- ein Review-Video von max. 5 Minuten.
Bedürfnis: Erkennbarer Lernfortschritt, nicht Feature-Vollständigkeit.
S3: Gruppen-Organisator:in (Power-User)
Die kritischste Nutzergruppe. Erwartet:
- Gruppe in unter einer Minute erstellen
- Einladung per Link teilen
- Überblick über offene Rückmeldungen
- automatischer Terminvorschlag ohne manuelles Auszählen
Bedürfnis: Entlastung von Koordinationsarbeit und weniger Nachfassen in Chatgruppen.
Frust heute: Termine werden „wild reingeschrieben“, niemand hat den Überblick.
S5: Vereinsvorstand
Koordiniert größere, wiederkehrende Termine. Erwartet Rollenrechte, wiederholbare Umfragen und Übersicht über viele Teilnehmende.
S6: Team-Lead / Arbeitsgruppe
Nutzt die App im Graubereich zwischen privat und beruflich (Teamevent, Mittagessen). Erwartet, dass keine privaten Kalenderdetails sichtbar werden – nur „frei/belegt“.
Quadrant: Zufriedenstellen
S8: Datenschutzbehörden / DSGVO
Die App verarbeitet Kalenderdaten, Standort und soziale Graphen – durchweg sensible Daten. Erwartet werden Rechtsgrundlage, Datenminimierung, Löschkonzept, Auftragsverarbeitungsverträge. Bedürfnis des Projekts: Privacy by Design von Anfang an, nicht als Nachrüstung.
S9: Hosting- / Cloud-Provider
Erwartet ggf Bezahlung und regelkonforme Nutzung.
Relevanz: Serverstandort EU, Verfügbarkeit, möglichst keine Kosten.
Quadrant: Informieren
S4: Passives Gruppenmitglied
Will mit minimalem Aufwand teilnehmen: Link öffnen, Zeiten antippen, ein paar Aktivitäten swipen, fertig. Bedürfnis: keine Registrierungshürde vor dem ersten Mehrwert, Push-Erinnerung statt Nachfragen im Chat.
S7: Event-Locations & Gastronomie
Wollen als passende Aktivität ausgespielt werden. Erwarten Reichweite und Buchungsimpulse. Für das Produkt der wichtigste Hebel zur Monetarisierung – gleichzeitig ein Risiko für die Neutralität der Vorschläge.
Quadrant: Beobachten
S10: Wetter- und AI-APIs – liefern Daten für Could-have-Vorschläge; Ausfall ist unkritisch.
5. Ableitung: Wer prägt die Anforderungen?
Für das Product Backlog sind vier Stakeholder anforderungsbestimmend:
| Priorität | Stakeholder | Warum anforderungsbestimmend | Prägt vor allem |
|---|---|---|---|
| 1 | S3 Gruppen-Organisator | Trägt die Koordinationslast und entscheidet, ob die App überhaupt in der Gruppe eingeführt wird. Ohne ihn gibt es keine Gruppe. | Gruppe erstellen, Verfügbarkeiten sammeln, automatischer Terminvorschlag, Termin bestätigen |
| 2 | S6 Passives Gruppenmitglied | Der Engpass für Netzwerkeffekte: Steigt die Abbruchrate, scheitert die Terminfindung trotz perfekter Organisator-UX. | Reibungsloses Onboarding, Verfügbarkeiten eintragen, Swipe-Flow, Push-Erinnerungen |
| 3 | S2 Dozent / Prüfer | Definiert Umfang und Bewertungsmaßstab des Abgabeartefakts. Bestimmt die Sprint-Ziele dieses Projekts. | MVP-Umfang, Nachvollziehbarkeit der Priorisierung, Review-Video |
| 4 | S8 Datenschutz (DSGVO) | Nicht-verhandelbare Rahmenbedingung. Kalender- und Standortdaten sind besonders sensibel; Verstöße sind existenzbedrohend. | Berechtigungskonzept, Sichtbarkeit „frei/belegt“ statt Termindetails, Löschfunktion |
Sekundär anforderungsbeeinflussend: S12 Google APIs (technische Machbarkeit der Should-haves) und S10 Event-Locations (Monetarisierung, Could-haves).
Konsequenz für die Priorisierung (MoSCoW)
| Stakeholder | Must have | Should have | Could have |
|---|---|---|---|
| S6 Organisator | Gruppe erstellen/beitreten, gemeinsame Termine ermitteln, Termin bestätigen | Kalender-Übernahme, Push-Erinnerung | Kostenaufteilung, Fahrgemeinschaften |
| S7 Passives Mitglied | Benutzerkonto, Verfügbarkeiten eintragen, Aktivitäten swipen | Push-Erinnerung | Wetter-Info |
| S8 / S9 Verein & Team | Gruppenvorschläge aus Matches | Orte zur Aktivität, Entfernung | – |
| S10 Event-Locations | – | Passende Orte anzeigen, Google-Maps-Link | KI-Vorschläge |
| S14 Datenschutz | Benutzerkonto mit Löschfunktion, Sichtbarkeit „frei/belegt“ | Explizite Einwilligung für Kalender-Sync | – |