Zusammenarbeit

Arbeitsweise

Wie ich Projekte führe, warum ich Ihre Mitarbeit brauche und weshalb ich bei komplexen Vorhaben selten einen Festpreis nenne.

Die meisten Projekte scheitern nicht an der Technik. Sie scheitern daran, dass zu Beginn niemand aussprechen wollte, was noch unklar ist. Deshalb steht am Anfang keine Aufwandsschätzung, sondern eine Klärung.

Zwei Schritte, immer die gleichen

Unabhängig davon, ob es um eine neue Fachanwendung geht oder um die Modernisierung eines gewachsenen Systems – der Ablauf ist derselbe.

Klären & priorisieren

Was soll das System können, was davon zuerst, und was ist nur eine Gewohnheit aus dem alten System? Am Ende dieses Schritts steht eine Reihenfolge, keine Wunschliste.

Umsetzen & absichern

In kleinen, lauffähigen Schritten. Jeder Schritt geht live oder ist zumindest abnehmbar, und jeder wird durch automatisierte Tests abgesichert, bevor der nächste beginnt.

Warum agil und nicht Wasserfall

Ein Wasserfallprojekt verlangt, dass zu Beginn alles bekannt ist. Bei komplexen Systemen ist es das nie. Was dann passiert, kennt jeder: Es wird trotzdem alles spezifiziert, die Spezifikation wird teuer, und beim ersten Kontakt mit der Realität stimmt sie nicht mehr.

Agil zu arbeiten ist für mich keine Methodenfrage, sondern eine Kostenfrage. Wer in kurzen Zyklen liefert, merkt nach zwei Wochen, dass eine Annahme falsch war – und nicht nach sechs Monaten. Das macht die Zusammenarbeit in der Summe günstiger als ein Festpreis, der das Risiko einpreisen muss.

Warum ich Ihre Mitarbeit brauche

Ich kann TYPO3. Ihr Fachgebiet kennen Sie. Eine Fachanwendung entsteht nur dort, wo beides zusammenkommt – deshalb arbeite ich nach dem Ansatz des Domain-Driven Design: Die Begriffe im Code sind dieselben, die Sie im Gespräch benutzen.

Konkret heißt das: Ich brauche jemanden auf Ihrer Seite, der entscheiden darf, der Fragen beantwortet und der sich Zwischenstände ansieht. Ein Projekt, in dem der Ansprechpartner erst zur Abnahme wieder auftaucht, wird teuer – für beide.

Aufwandsschätzungen und Festpreise

Für abgegrenzte Aufgaben nenne ich einen Festpreis. Für ein Projekt mit offenen Fragen nicht – jedenfalls nicht, ohne einen Risikoaufschlag einzurechnen, den am Ende Sie bezahlen, auch wenn das Risiko nie eintritt.

Stattdessen schätze ich pro Arbeitspaket und sage dazu, wie sicher die Schätzung ist. Wenn ich mir bei etwas unsicher bin, sage ich das vorher und nicht in der Rechnung.

Technische Schulden

Technische Schulden sind kein moralisches Problem, sondern ein finanzielles. Jede Abkürzung, die heute Zeit spart, kostet später Zinsen – in Form von Updates, die nicht mehr durchlaufen, oder von Features, die plötzlich das Dreifache kosten.

Manchmal ist eine Abkürzung trotzdem richtig, etwa vor einem Messetermin. Dann schreibe ich auf, was wir aufgeschoben haben und was es kosten wird, es später aufzuräumen. Was nirgends steht, wird nicht zurückgezahlt.

Priorisierung und Notfälle

Nicht alles ist gleich dringend, und fast nichts ist so dringend, wie es sich anfühlt. Ich sortiere nach Wirkung: Was blockiert den Betrieb, was blockiert Ihre Redaktion, was ist ein Wunsch.

Störung im Betrieb

Die Seite ist nicht erreichbar oder ein Sicherheitsproblem ist bekannt. Das geht vor, immer.

Redaktion blockiert

Inhalte lassen sich nicht pflegen. Das kostet täglich Arbeitszeit und wird oft unterschätzt.

Terminierte Vorhaben

Kampagne, Messe, Gesetzesfrist. Planbar, wenn der Termin früh genug bekannt ist.

Verbesserungen

Sinnvoll, aber verschiebbar. Sie landen auf der Liste und werden regelmäßig neu sortiert.

Wie ich als Einzelner die Qualität eines Teams halte

Die berechtigte Frage an einen Freelancer lautet: Wie soll einer leisten, wofür sonst eine Agentur antritt? Meine Antwort ist KI-gestützte Arbeit – aber die Aussage allein ist wertlos. Das sagen inzwischen alle, und sie sagt nichts darüber, was am Ende herauskommt.

Entscheidend ist, was um die KI herum steht. Bei mir sind das drei Dinge, und alle drei können Sie nachsehen.

Schriftliche Regeln

Die KI bekommt keine freie Hand, sondern einen verbindlichen Regelsatz: Namenskonventionen, Architekturentscheidungen, welche TYPO3-API in welcher Version noch gilt. Was dort nicht geregelt ist, wird nachgeschlagen und nicht erfunden.

Gegenseitige Reviews

Verschiedene Modelle prüfen die Arbeit der jeweils anderen. Was ein Modell übersieht, fällt einem zweiten auf – das ist dieselbe Idee wie ein Vier-Augen-Prinzip im Team, nur ohne Terminabstimmung.

Automatisierte Prüfung

Statische Analyse und End-to-End-Tests entscheiden, ob eine Änderung fertig ist – nicht der Eindruck, dass sie richtig aussieht. Ein Paket-Update gilt als sicher, wenn die Tests grün sind, nicht wenn ich zwei Seiten angeklickt habe.

Woran Sie das prüfen können

Sprachmodelle machen eigene, wiederkehrende Fehler. In Fluid-Templates sind das zum Beispiel typografische Anführungszeichen als Attributbegrenzer – im Editor praktisch unsichtbar, im Ergebnis kaputt. Aus dieser Erfahrung ist ein eigener Linter entstanden, der genau diese Fehlerklasse findet, bevor sie irgendwo ankommt.

Das Werkzeug liegt offen auf GitHub, samt Begründung für jede einzelne Regel. Es ist der belastbarste Beleg, den ich anbieten kann: nicht die Behauptung, sorgfältig zu arbeiten, sondern das Werkzeug, das aus der Sorgfalt entstanden ist. Mehr dazu unter Open Source.

Und Ihre Daten?

Eine berechtigte Rückfrage. Wo Kundendaten im Spiel sind, läuft die KI lokal auf eigener Hardware – ein Spamfilter, der Formularanfragen bewertet, muss diese Anfragen nicht an einen fremden Dienst schicken. Wo etwas nicht das Haus verlassen darf, verlässt es das Haus nicht.

Die Verantwortung bleibt in jedem Fall bei mir. Ich liefere nichts aus, was ich nicht selbst verstanden habe und im Zweifel auch ohne KI hätte schreiben können. Was ich gewinne, ist Zeit – und die steckt in Tests und Absicherung, nicht in mehr Zeilen pro Tag.

Passt das zu Ihrem Vorhaben?

Am schnellsten finden wir das in einem Gespräch heraus. Schildern Sie mir kurz, worum es geht – ich sage Ihnen ehrlich, ob ich der Richtige dafür bin.