Aus der Idee wird ein konkreter Auftrag

Im letzten Beitrag habe ich beschrieben, wie aus einer ersten Idee für ein Incident-Management-System das Projekt FlowOps entstanden ist.

Zu diesem Zeitpunkt war FlowOps allerdings noch kein konkretes Produkt.

Ich hatte eine Vorstellung davon, welches Problem ich lösen möchte und in welche Richtung die Anwendung gehen könnte. Es gab aber noch keine klare Definition darüber, für wen FlowOps gedacht ist, welche Funktionen tatsächlich benötigt werden und wo die Grenzen des Projekts liegen.

Genau das wollte ich im nächsten Schritt ändern.

Denn bevor ich mit der eigentlichen Entwicklung beginne, muss zunächst klar sein:

Was soll überhaupt gebaut werden?

Und genauso wichtig:

Was soll bewusst nicht gebaut werden?

Deshalb habe ich mich entschieden, die ursprüngliche Idee wie einen echten Kundenauftrag zu behandeln.

Nicht im Sinne eines vollständig simulierten Unternehmens mit erfundenen Meetings und Stakeholdern, sondern indem ich mich selbst bewusst in die Rolle versetze, in der ich auch bei einem realen Auftrag arbeiten würde:

Eine Problemstellung kommt zu mir.

Ich muss sie verstehen.

Ich muss Rückfragen und Annahmen erkennen.

Ich muss Anforderungen daraus ableiten.

Ich muss Prioritäten setzen.

Und am Ende muss ein Umfang entstehen, der tatsächlich umgesetzt werden kann.

Genau daraus sind die ersten beiden Bereiche der FlowOps-Planung entstanden:

Requirements und Product.

---

Ich wollte nicht einfach anfangen zu programmieren

Bei einem persönlichen Projekt ist die Versuchung groß, direkt mit dem Programmieren anzufangen.

Die Idee ist da, also öffnet man den Editor und baut das erste Feature.

Vielleicht beginnt man mit einem Login.

Dann kommt eine Benutzerverwaltung dazu.

Danach ein Dashboard.

Dann Incidents.

Dann Kommentare.

Und plötzlich ist aus einer kleinen Idee ein deutlich größeres Projekt geworden.

Das Problem dabei ist nicht unbedingt, dass die einzelnen Funktionen schlecht sind.

Das Problem ist, dass irgendwann niemand mehr genau sagen kann, warum diese Funktionen eigentlich Teil des Projekts sind.

Genau das wollte ich bei FlowOps vermeiden.

Ich möchte mit diesem Projekt nicht nur zeigen, dass ich Software entwickeln kann.

Das lässt sich durch Code relativ einfach demonstrieren.

Viel interessanter finde ich die Frage:

Wie komme ich überhaupt zu dem Code, den ich anschließend schreibe?

Wie entscheide ich, welche Probleme relevant sind?

Wie zerlege ich eine unklare Idee in konkrete Anforderungen?

Wie gehe ich mit widersprüchlichen oder offenen Fragen um?

Wie entscheide ich, was Priorität hat?

Und wie verhindere ich, dass ein Projekt immer weiter wächst?

Diese Fragen waren für mich der eigentliche Grund, die Planung so ausführlich zu machen.

---

Die ursprüngliche Idee als Ausgangspunkt

Die Ausgangsidee von FlowOps was relativ einfach:

Unternehmen benötigen eine zentrale Möglichkeit, technische Vorfälle zu verwalten, deren Verlauf zu dokumentieren und die spätere Aufarbeitung zu unterstützen.

Das klingt zunächst nach einer ausreichenden Beschreibung.

Für eine tatsächliche Entwicklung ist es das aber noch lange nicht.

Aus diesem einen Satz entstehen sofort viele weitere Fragen.

Zum Beispiel:

• Wer verwendet das System?
• Arbeitet eine einzelne Person damit oder ein ganzes Team?
• Gibt es mehrere Unternehmen bzw. Organisationen?
• Welche Informationen müssen bei einem Incident gespeichert werden?
• Welche Zustände kann ein Incident besitzen?
• Wer darf einen Incident erstellen?
• Wer darf ihn verändern?
• Was passiert nach der Behebung?
• Wie wird die Aufarbeitung eines Incidents dokumentiert?
• Welche Informationen sind für ein Postmortem notwendig?
• Welche Funktionen gehören wirklich zum ersten Release?

Genau hier beginnt für mich der Unterschied zwischen einer Idee und einem Projekt.

Eine Idee beschreibt zunächst ein gewünschtes Ergebnis.

Ein Projekt benötigt dagegen klare Rahmenbedingungen.

---

Die Anforderungen wie einen echten Auftrag behandeln

Ich wollte deshalb nicht einfach meine eigene Wunschliste aufschreiben.

Stattdessen habe ich versucht, aus der ursprünglichen Idee ein möglichst realistisches Anforderungsdokument zu entwickeln.

Dabei habe ich mir bewusst vorgestellt, dass die ursprüngliche Beschreibung von einem Kunden stammen könnte.

Ein Kunde würde mir vermutlich nicht sagen:

"Erstelle mir genau diese 17 Tabellen und diese 23 API-Endpunkte."

Er würde eher ein Problem beschreiben.

Meine Aufgabe als Entwickler wäre es dann, dieses Problem zu verstehen und gemeinsam daraus ein konkretes Produkt zu machen.

Natürlich kann ich bei einem persönlichen Projekt keine echten Stakeholder ersetzen.

Aber ich kann zumindest versuchen, die gleiche Denkweise anzuwenden.

Das bedeutet auch, dass ich nicht jede meiner eigenen Ideen automatisch als Anforderung akzeptiere.

Wenn mir während der Planung ein neues Feature einfällt, muss ich mich fragen:

Ist das wirklich eine Anforderung des Produkts – oder möchte ich es einfach nur gerne programmieren?

Diese Unterscheidung war für mich überraschend wichtig.

---

Von "Was kann die Anwendung?" zu "Welches Problem lösen wir?"

Eine reine Feature-Liste wäre schnell geschrieben.

Zum Beispiel:

Login
Dashboard
Incidents
Kommentare
Postmortems
Benutzerverwaltung
Services

Damit weiß man aber noch nicht, ob das Produkt sinnvoll definiert ist.

Deshalb habe ich versucht, die Anforderungen stärker aus den eigentlichen Problemen abzuleiten.

Ein Incident-Management-System soll beispielsweise nicht einfach nur ermöglichen, einen Datensatz namens "Incident" anzulegen.

Der eigentliche Zweck ist, einen technischen Vorfall strukturiert zu bearbeiten und seinen Verlauf nachvollziehbar zu dokumentieren.

Daraus ergeben sich dann konkrete Anforderungen.

Ein Incident benötigt beispielsweise Informationen wie:

• einen Titel
• eine Beschreibung
• eine Severity
• einen Status
• einen zeitlichen Kontext
• eine Historie

Und es muss möglich sein, den Verlauf eines Incidents zu dokumentieren.

Damit wird aus einer abstrakten Idee eine konkrete Produktanforderung.

Wer verwendet FlowOps?

Eine der ersten Fragen, die ich klären musste, war die nach den Benutzern.

"Benutzer" ist für mich dabei keine ausreichende Beschreibung.

Denn unterschiedliche Personen haben unterschiedliche Aufgaben und damit auch unterschiedliche Anforderungen.

Für FlowOps habe ich deshalb ein organisationsbasiertes Modell vorgesehen.

Ein Unternehmen bzw. eine Organisation verwendet FlowOps gemeinsam.

Innerhalb dieser Organisation gibt es verschiedene Benutzer mit unterschiedlichen Rängen beziehungsweise Rollen.

Damit entstand eine erste fachliche Struktur:

Organization
     |
     +-- User
     |
     +-- User
     |
     +-- User

Das ist zunächst noch sehr einfach.

Aber bereits hier entstehen weitere Anforderungen.

Beispielsweise:

• Benutzer müssen einer Organisation zugeordnet werden können.
• Eine Organisation benötigt Mitglieder.
• Mitglieder benötigen unterschiedliche Berechtigungen.
• Nicht jeder Benutzer darf jede Aktion durchführen.
• Ein deaktiviertes Mitglied soll nicht einfach weiterhin Zugriff besitzen.

Diese Punkte sind für mich ein gutes Beispiel dafür, wie sich Anforderungen entwickeln.

Ich habe nicht einfach irgendwann entschieden:

"Ich brauche jetzt noch Rollen."

Die Rollen ergeben sich aus der Frage:

Welche unterschiedlichen Aufgaben müssen Benutzer innerhalb des Produkts erfüllen können?

---

Rollen und Berechtigungen im Detail

Aus diesen Überlegungen sind schließlich drei konkrete Benutzerrollen entstanden, die ich für den MVP definiert habe:

1. Owner (Eigentümer): Besitzt alle Rechte innerhalb einer Organisation. Kann Abonnements verwalten, die Organisation löschen und Mitglieder verwalten.
2. Admin (Administrator): Kann Mitglieder einladen und verwalten, Services erstellen und bearbeiten, sowie alle operativen Incident-Funktionen nutzen.
3. Member (Mitglied): Kann Incidents erstellen, bearbeiten und lösen, Kommentare schreiben und Postmortems verfassen – jedoch keine administrativen Einstellungen der Organisation ändern.

Diese Rollen sind direkt an die Mitgliedschaft in einer Organisation gebunden.

Das bedeutet technisch: Ein Benutzer besitzt keine globale Rolle in FlowOps, sondern eine spezifische Rolle innerhalb einer bestimmten Organisation.

---

Welche Daten gehören zu einem Incident?

Nachdem die Benutzer geklärt waren, ging es an die zentrale Ressource des Systems: den Incident.

Auch hier ging es mir darum, nicht einfach "Felder" in einer Datenbank anzulegen, sondern die fachlichen Anforderungen abzubilden.

Ein Incident in FlowOps soll folgende Kerninformationen enthalten:

• Titel: Eine prägnante Zusammenfassung des Vorfalls.
• Beschreibung: Eine ausführliche Dokumentation des Problems und der Auswirkungen.
• Severity (Schweregrad): Ein Maß für die Dringlichkeit (z.B. SEV-1 für kritische Ausfälle, SEV-3 für kleinere Probleme).
• Status: Der aktuelle Zustand im Lebenszyklus (OPEN, INVESTIGATING, MITIGATED, RESOLVED).
• Services: Welche technischen Dienste oder Systemkomponenten sind betroffen?
• Timeline: Ein automatisches Protokoll aller wichtigen Ereignisse während des Incidents.

Gerade das Thema Timeline ist ein gutes Beispiel für den Unterschied zwischen einer einfachen Datenbanktabelle und einer echten Anforderung.

Ich wollte nicht nur den aktuellen Zustand speichern.

Für die spätere Analyse ist es entscheidend zu wissen, wann sich ein Status geändert hat, wer eine Severity angepasst hat oder wann der erste Kommentar geschrieben wurde.

Deshalb wurde eine automatische Timeline-Generierung zu einer Kernanforderung des MVP.

Kommentare vs. Postmortem

Ein weiteres Detail der Anforderungsanalyse war die Unterscheidung zwischen Kommentaren und dem Postmortem.

Ich habe Kommentare nicht einfach als "Zusatzfeature" betrachtet.

Während eines aktiven Vorfalls müssen Teammitglieder Informationen austauschen können, die nicht in die strukturierten Felder eines Incidents passen.

Zum Beispiel:

"Ich sehe gerade eine erhöhte Fehlerrate auf der Datenbank."

Oder:

"Ich habe den Service neu gestartet."

Diese Informationen müssen direkt am Incident dokumentiert werden. Sie gehören zum operativen Workflow.

Das Postmortem dagegen entsteht erst nach der Behebung eines Vorfalls.

Es dient einem anderen Zweck:

Während der Incident die operative Bewältigung beschreibt, dient das Postmortem der strukturierten Analyse im Nachhinein.

Es soll dem Team helfen zu verstehen:

• Warum ist das Problem aufgetreten?
• Wie wurde es behoben?
• Wie können wir es in Zukunft verhindern?

Daraus entstand eine klare fachliche Trennung:

Incident
   |
   |-- Operative Bewältigung
   |
   v
Behebung (Resolution)
   |
   v
Postmortem
   |
   |-- Retrospektive Analyse
   |
   v
Lessons Learned

Diese Unterscheidung war mir wichtig, weil sie verdeutlicht, warum beide Bereiche im System existieren und wie sie zusammenhängen.

---

User Stories als Brücke vom Problem zum Produkt

Nachdem die groben Anforderungen klar waren, habe ich begonnen, sie in sogenannte User Stories zu übersetzen.

Das hilft dabei, Anforderungen immer aus Sicht des Benutzers zu formulieren.

Anstatt zu schreiben:

"Das System benötigt eine Incident-Tabelle."

schreibe ich:

Als Mitglied einer Organisation möchte ich einen Incident erstellen können, damit ein technisches Problem zentral dokumentiert wird.

Das verändert den Blickwinkel auf die Anforderung.

Plötzlich muss ich mich fragen:

• Wer führt diese Aktion aus?
• Warum benötigt er das?
• Was muss vorher gegeben sein?
• Was passiert genau beim Erstellen?
• Welche Informationen muss der Benutzer eingeben?
• Wann ist diese Funktion wirklich fertig?

Aus einer abstrakten Anforderung wird so ein konkreter Anwendungsfall.

Von der User Story zur umsetzbaren Anforderung

Eine User Story allein reicht allerdings noch nicht aus, um sie zu implementieren.

Beispiel:

Als Mitglied möchte ich einen Incident erstellen.

Das ist immer noch sehr vage.

Deshalb habe ich versucht, die Anforderungen unterhalb dieser Stories präzise zu beschreiben.

Für das Erstellen eines Incidents bedeutet das konkret:

• Wer ist berechtigt? (Owner, Admin, Member)
• Welche Felder sind Pflichtfelder? (Titel, Severity, betroffener Service)
• Welche Severity-Werte sind erlaubt? (SEV-1 bis SEV-3)
• Welchen Status erhält ein neuer Incident standardmäßig? (OPEN)
• Was passiert nach dem erfolgreichen Erstellen? (Umleitung auf die Detailseite, Erstellen des ersten Timeline-Events)

Diese Detaillierung war für mich einer der wichtigsten Schritte in dieser Phase.

---

Priorisieren statt alles auf einmal wollen

Ein weiterer entscheidender Teil des Prozesses war die Priorisierung.

Nicht jede Anforderung ist gleich wichtig.

Ich habe deshalb versucht, die Anforderungen anhand ihres Beitrags zum eigentlichen MVP zu bewerten.

Vereinfacht ausgedrückt habe ich mich an folgende Kategorien gehalten:

Must Have
    |
    +-- Kernfunktionalität
    |
Should Have
    |
    +-- Wichtige Ergänzungen
    |
Could Have
    |
    +-- Nützlich für später
    |
Out of Scope
    |
    +-- Bewusst nicht Teil des MVP

Besonders die letzte Kategorie war mir wichtig.

Out of Scope ist eine aktive Entscheidung.

Wenn ich eine Funktion nicht in den MVP aufnehme, bedeutet das nicht, dass ich sie vergessen habe.

Es bedeutet:

Ich habe darüber nachgedacht und mich bewusst dagegen entschieden, sie zum jetzigen Zeitpunkt umzusetzen.

Das ist für mich ein wichtiger Reifegrad bei der Entwicklung.

---

Was FlowOps bewusst nicht können soll (MVP-Grenzen)

Das war vermutlich eine der interessantesten Fragen in der gesamten Planungsphase.

Bei einem eigenen Projekt neigt man dazu, immer noch ein Feature hinzufügen zu wollen.

Ich wollte bewusst die entgegengesetzte Frage stellen:

Was soll FlowOps explizit nicht tun?

Für den MVP habe ich deshalb mehrere Bereiche bewusst ausgeschlossen:

• Echtzeit-Kollaboration (wie in Google Docs): Mehrere Benutzer können gleichzeitig an einem Postmortem arbeiten – für den MVP reicht es völlig aus, wenn ein Benutzer Änderungen speichert und diese für andere sichtbar werden.
• Komplexe Benachrichtigungen (Slack, Email, PagerDuty): Eine Benachrichtigung direkt in der App oder über einfache Webhooks reicht für den Anfang. Umfangreiche Integrationen gehören nicht in den Kern des MVP.
• Automatische Incident-Erkennung: FlowOps reagiert auf manuell erstellte Vorfälle. Die Integration von automatischen Monitoring-Systemen ist ein klassisches Post-MVP-Feature.
• Erweitertes Berechtigungsmanagement (custom roles): Drei vordefinierte Rollen reichen völlig aus. Custom-Rollen würden die Datenbank- und Autorisierungsstruktur im ersten Schritt unnötig kompliziert machen.

Diese Abgrenzung schützt das Projekt vor der größten Gefahr privater Softwareprojekte:

Scope Creep.

Schutz vor Scope Creep

Ein privates Projekt kann theoretisch unendlich wachsen.

Bei jeder neuen Idee denkt man:

"Das wäre auch noch cool."

Und genau so entstehen Projekte, die nie fertig werden.

Deshalb habe ich mir für FlowOps eine einfache Regel gesetzt:

Jedes neue Feature muss einen klaren Beitrag zum definierten Core-Workflow leisten. Tut es das nicht, wird es nicht implementiert.

Das schont nicht nur die Motivation, sondern ist auch eine realistische Simulation der Praxis.

Auch in Unternehmen sind Ressourcen und Zeit begrenzt.

Dinge nicht zu tun, ist oft eine der wichtigsten Architekturentscheidungen überhaupt.

---

Die Anforderungen veränderten meine eigene Idee

Ein interessanter Nebeneffekt dieser Phase war, dass sich mein eigenes Verständnis von FlowOps verändert hat.

Am Anfang dachte ich eher:

"Ich baue eine Incident-Management-App."

Durch die Anforderungen wurde daraus:

"Ich baue eine Anwendung, die einen klar definierten Prozess der Vorbereitung, Behebung und Analyse von technischen Störungen innerhalb eines Unternehmens unterstützt."

Klingt nach einem kleinen sprachlichen Unterschied.

Fachlich bedeutet es aber etwas völlig anderes.

Die erste Formulierung beschreibt ein Produkt.

Die zweite Formulierung beschreibt das Problem und den Prozess, den das Produkt unterstützen soll.

Und genau das hat es mir viel einfacher gemacht, zu entscheiden, welche Funktionen notwendig sind und welche nicht.

---

Anforderungen als lebendes Dokument

Ein weiterer Punkt, den ich aus dieser Phase mitnehme:

Ein Anforderungsdokument ist für mich nicht etwas, das man einmal schreibt und dann im Repository verstauben lässt.

Es ist der rote Faden für das gesamte Projekt.

Wenn ich später im Code eine Entscheidung treffen muss, kann ich auf das Dokument zurückgreifen.

Wenn ich merke, dass sich eine Anforderung in der Praxis als unpraktisch erweist, kann ich sie bewusst im Dokument anpassen, anstatt am Dokument vorbei zu programmieren.

Es entsteht so eine Brücke:

Problem
   |
   v
Anforderung
   |
   v
Produktentscheidung
   |
   v
Implementierung

Keine dieser Ebenen sollte willkürlich entstehen.

---

Was ich bewusst offen gelassen habe (Open Questions)

Gute Planung bedeutet nicht, jede offene Frage künstlich vorab zu beantworten.

Manche Fragen kann man erst sinnvoll klären, wenn andere Entscheidungen getroffen wurden – oder wenn man die erste Version der Anwendung tatsächlich vor sich hat.

Deshalb habe ich offene Fragen bewusst als solche dokumentiert, anstatt sie klammheimlich durch Annahmen zu ersetzen.

Beispiele dafür sind:

• Wie genau läuft der Prozess ab, wenn ein Benutzer einer Organisation beitreten möchte? (Einladung vs. Request)
• Welche Dashboard-Kennzahlen sind für den Anwender im ersten Schritt wirklich relevant?
• Welche Felder im Postmortem müssen verpflichtend sein, bevor es veröffentlicht werden darf?

Diese Fragen verschwinden nicht.

Aber sie blockieren auch nicht die aktuelle Entwicklung. Sie sind markiert und werden zu einem definierten Zeitpunkt in der Zukunft gelöst.

---

Von der Anforderungen zum technischen Fundament

Damit steht das Produktmodell für FlowOps.

Wir haben uns von der groben Idee zu einem konkreten MVP vorgearbeitet:

Idee
 |
 v
Problem verstehen
 |
 v
Anforderungen
 |
 v
MVP definieren
 |
 v
Benutzer & Rollen
 |
 v
Daten & Beziehungen
 |
 v
Implementierung

Genau diese Kette war für mich das eigentliche Ziel dieses ersten Schritts.

Ich wollte nicht nur zeigen, dass ich programmieren kann.

Ich wollte zeigen, wie ich von einem Problem zu einer technischen Lösung komme.

---

Warum ich diesen Prozess so ausführlich dokumentiere

In einem Portfolio sieht man am Ende oft nur die fertigen Code-Zeilen und ein paar Screenshots.

Was man nicht sieht:

• Warum wurde diese Technologie gewählt?
• Welche Alternativen gab es?
• Welche Probleme sind aufgetreten?
• Welche Entscheidungen wurden getroffen?

Ich finde gerade diesen Weg extrem spannend.

Er zeigt, wie ein Entwickler denkt und arbeitet.

Denn Softwareentwicklung ist viel mehr als nur Code in einen Editor zu schreiben.

Es ist eine Aneinanderreihung von Entscheidungen unter bestimmten Rahmenbedingungen.

Und genau diesen Prozess möchte ich mit FlowOps transparent machen.

---

Fazit: Das Fundament für den Code steht

Mit dem Abschluss der Requirements- und Product-Phase hat FlowOps sein Fundament erhalten.

Ich habe jetzt nicht nur eine Idee, sondern einen klaren Plan, was gebaut werden soll und was erst einmal nicht.

Damit kann der nächste Schritt folgen: Die technische Architektur.

Bevor ich die erste Zeile Code schreibe, möchte ich festlegen, welche Technologien wir verwenden, wie das Datenmodell aussieht und wie die einzelnen Services miteinander interagieren sollen.

Aber das ist ein Thema für den nächsten Beitrag.