Field Note: Die ersten 60 Minuten bei einem komplexen Digitalprojekt

Ich beginne nicht im Code

In den ersten 60 Minuten eines komplexen Digitalprojekts versuche ich, die Systemgrenzen zu verstehen, bevor ich mich in die technische Umsetzung vertiefe. Mich interessiert zunächst nicht, welches Plugin fehlt oder welcher Endpoint gebaut werden soll. Ich will wissen, was das System eigentlich leisten soll und wo die relevanten Entscheidungen, Daten und Zuständigkeiten liegen.

Das klingt selbstverständlich. In der Praxis ist es aber leicht, sich von einer konkreten technischen Anfrage direkt in eine konkrete Lösung ziehen zu lassen. Ein Formular soll ergänzt werden, eine Schnittstelle fehlt, ein bestehender Ablauf soll automatisiert werden. Die Aufgabenstellung ist greifbar, also beginnt man schnell damit, sie abzuarbeiten.

Ich habe gelernt, dass die technische Aufgabenstellung erstaunlich oft nicht das eigentliche Problem beschreibt. Die erste Stunde ist deshalb für mich keine verkürzte Planungsphase und auch keine Code-Inspektion mit Stoppuhr. Sie ist eine Gelegenheit, die Frage hinter der Frage zu finden.

Die Anfrage ist nicht immer das Problem

„Wir brauchen ein neues Formular“ kann bedeuten: Unsere Daten landen an drei Stellen und niemand weiß, welche davon stimmt. Dann ist das Formular nicht der Kern des Problems. Es ist nur der sichtbare Punkt, an dem ein unklarer Prozess auffällt.

Wenn ich sofort ein Formular plane, kann ich die Oberfläche verbessern und gleichzeitig die Unklarheit darunter fortschreiben. Welche Daten werden erfasst? Wer prüft sie? Wohin gehen sie danach? Gibt es eine führende Quelle, oder werden Werte mehrfach gepflegt? Was passiert automatisch und wo übernimmt noch jemand manuell?

Diese Fragen verändern den Blick auf die Aufgabe. Vielleicht geht es tatsächlich um ein Formular. Vielleicht geht es aber um Zuständigkeiten, Datenmodell oder Übergaben zwischen Systemen. In der ersten Stunde muss ich das noch nicht abschließend lösen. Ich muss nur erkennen, ob die ursprüngliche Formulierung den tatsächlichen Arbeitsbedarf trifft.

Was ich zuerst prüfe: Was ist das eigentliche Ziel? Wo liegen die Daten? Wer bearbeitet sie? Was geschieht automatisch, was manuell? Und welches System ist wirklich führend?

Ich suche nach Grenzen und Übergaben

Bei einem komplexen Projekt interessieren mich nicht nur die Systeme selbst, sondern vor allem die Stellen zwischen ihnen. Dort werden Daten übergeben, Entscheidungen getroffen und Aufgaben von einer Person oder einem System an ein anderes weitergereicht. Wenn diese Übergänge unklar sind, hilft es wenig, nur die Oberfläche eines einzelnen Tools zu betrachten.

Ich versuche deshalb, das Projekt zunächst in einfachen Worten zu beschreiben: Welche Systeme sind beteiligt? Welche Daten bewegen sich zwischen ihnen? Wer darf sie anlegen, ändern oder freigeben? Was löst den nächsten Schritt aus? Und woran lässt sich erkennen, dass dieser Schritt erfolgreich war?

Dabei geht es nicht darum, schon in der ersten Stunde ein vollständiges Architekturdiagramm zu zeichnen. Eine grobe Karte reicht oft, um offene Stellen sichtbar zu machen. Ein System kann für die Bearbeitung zuständig sein, ein anderes für die Veröffentlichung. Ein Ablauf kann teilweise automatisiert sein und trotzdem an einer Stelle eine manuelle Prüfung brauchen. Solche Unterschiede sind wichtig, bevor aus einer groben Anfrage eine technische Lösung wird.

Auch Begriffe verdienen Aufmerksamkeit. „Datenbank“, „Backend“, „CRM“ oder „Website“ können für verschiedene Beteiligte unterschiedliche Dinge meinen. Ich frage lieber nach dem konkreten Arbeitsvorgang, statt anzunehmen, dass alle mit demselben Wort dasselbe System oder denselben Prozess bezeichnen.

Erst verstehen, dann verändern

Mein erster Impuls ist nicht mehr, möglichst schnell die passende technische Maßnahme zu benennen. Ich versuche zuerst zu trennen, was bekannt ist, was angenommen wird und was noch geprüft werden muss. Das schützt davor, eine Lösung auf eine Beschreibung zu bauen, die nur einen Ausschnitt des Problems zeigt.

Das bedeutet nicht, dass in der ersten Stunde alles offenbleibt. Eine gute erste Einschätzung darf durchaus eine Richtung haben. Aber ich möchte die Richtung an einem nachvollziehbaren Verständnis festmachen: am Ziel, an den Datenwegen und an den beteiligten Rollen. Wenn diese Grundlagen noch unscharf sind, benenne ich die Unsicherheit lieber, statt sie mit einer technischen Empfehlung zu überdecken.

Bei gewachsenen Systemen ist das besonders wichtig. Was auf den ersten Blick wie ein einzelnes Feature aussieht, kann an bestehende Inhalte, Berechtigungen, Schnittstellen oder manuelle Arbeitsschritte gekoppelt sein. Deshalb frage ich nicht nur, was neu dazukommen soll, sondern auch, was davon bereits abhängt und was sich durch die Änderung mitbewegen würde.

Eine Sache hat sich bei mir verändert: Ich betrachte die erste Stunde weniger als Startschuss für die Umsetzung und mehr als Prüfung des Problemraums. Die Entscheidung, noch nicht in den Code zu gehen, ist dabei keine Verzögerung. Sie ist eine bewusste Reihenfolge. Erst verstehen, was das System tut und wo seine Grenzen liegen; dann überlegen, was sich ändern soll; anschließend prüfen, ob die Änderung tatsächlich geholfen hat.

Was ich aus der ersten Stunde mitnehmen will

Am Ende dieser ersten Orientierung muss noch kein fertiger Lösungsplan stehen. Ich möchte aber besser unterscheiden können zwischen dem gewünschten Ergebnis und dem vorgeschlagenen Mittel. Außerdem sollte erkennbar sein, welche Systeme und Personen beteiligt sind und welche Fragen vor einer belastbaren technischen Entscheidung noch offenliegen.

Das Ergebnis kann eine engere Aufgabenstellung sein. Zum Beispiel nicht einfach „ein neues Formular“, sondern die Klärung, an welcher Stelle Daten entstehen, wer sie prüft und welche Quelle anschließend als verbindlich gilt. Die konkrete Umsetzung ergibt sich daraus später. Sie kann ein Formular umfassen, muss aber nicht bei einem Formular stehen bleiben.

Wenn die Grenzen und Übergaben verständlich sind, wird auch die nächste Arbeit konkreter: Welche Teile müssen untersucht werden? Welche Änderungen sind überhaupt sinnvoll? Wie lässt sich später belegen, dass der neue Ablauf funktioniert? Diese Fragen verbinden die erste Orientierung mit einer verantwortbaren Umsetzung. Sie helfen mir, nicht nur etwas zu bauen, sondern eine Änderung im Zusammenhang des Systems zu beurteilen.

Meine Faustregel: Bevor ich über die technische Lösung spreche, will ich verstehen, welches Ziel sie erfüllen soll, wo die Daten entlanglaufen und wer für den nächsten Schritt verantwortlich ist.

Weiterführend

• Field Note: Was eine gute Übergabe enthält
• Datenmodelle statt Plugin-Stapel
• Know → Change → Prove: Wie WordPress-Änderungen sicher werden