In den ersten drei Teilen dieser Serie ging es um klassische Projekte: Wir lernen eine Herausforderung kennen, entwickeln eine Strategie und ein Team übernimmt langfristig Verantwortung. Die Zusammenarbeit mit unseren Spezialist:innen fühlt sich anders an. Das Projekt läuft meistens schon. Ein internes Team oder eine andere Agentur verantwortet es.
An einer Stelle fehlt jedoch Erfahrung:
In dieser Situation möchte niemand das ganze Vorhaben noch einmal erklären. Und niemand braucht eine zweite Agentur, die zunächst alles infrage stellt.
Unsere Spezialist:innenprojekte, intern kurz SPZ, beginnen deshalb bewusst klein:
Meist steigen ein oder zwei Mitarbeiter:innen von punkt.de an genau der Stelle ein, an der sie gebraucht werden.
SPZ-Anfragen kommen häufig direkt von den Menschen, die bereits am Problem arbeiten. Sie kennen das System, haben erste Ursachen ausgeschlossen und können sehr konkret beschreiben, wo es hakt. Die ersten Gespräche werden deshalb oft schnell technisch.
Das erspart allen Beteiligten die klassische stille Post. Das Problem wird nicht vom Vertrieb an die Beratung und von dort an die Entwicklung weitererzählt. Fachleute sprechen direkt mit Fachleuten. Rückfragen, Hypothesen und auch erste Zweifel können sofort besprochen werden.
So bleibt die Zusammenarbeit auch später: direkt per Ticket, E-Mail oder Chat. Wenig Überbau. Kurze Wege.
„Direkt ins Problem“ bedeutet nicht, dass wir nur die genannte Probleme oder Fehlermeldung betrachten. Wir fragen nach angrenzenden Systemen, bisherigen Entscheidungen und dem Ziel hinter der gewünschten Lösung. Manchmal liegt die Ursache schließlich eine Ebene weiter links als das sichtbare Symptom.
Gleichzeitig kommen wir nicht mit dem Anspruch, das gesamte Projekt neu zu denken. Das bestehende Team hat Wissen aufgebaut, Entscheidungen getroffen und trägt die Verantwortung. Wir verschaffen uns nur so viel Kontext, dass unsere Lösung in diese Realität passt.
Für Kund:innen bedeutet das: Sie müssen sich nicht zwischen zwei schlechten Extremen entscheiden. Weder bearbeiten wir blind ein isoliertes Ticket, noch eröffnen wir für jedes Problem eine lange Strategiephase.
Unsere Spezialgebiete sind nicht am Vertriebsschreibtisch entstanden. Häufig beginnt es damit, dass eine Mitarbeiter: in bei punkt.de an einem Thema besonderes Interesse entwickelt – und in einem großen Projekt auf eine Herausforderung trifft, die noch niemand fertig gelöst hat.
Bei Keycloak fragte uns ein Kunde beispielsweise, ob wir eine Identitäts- und Zugriffsverwaltung für 50.000 bis 100.000 Accounts aufbauen können. Solche Fragen mögen wir. Jemand gräbt sich tief ein, probiert aus, löst das konkrete Problem und teilt das Wissen mit Kolleg:innen.
Erst später haben wir begonnen, diese Erfahrung auch unabhängig von großen punkt.de-Projekten anzubieten. Heute reicht sie von Elastic, Matomo und Keycloak über DevOps und Sylius bis zu KI und RAG, Accessibility, n8n sowie BPMN und CIB Seven.
Für die Zusammenarbeit ist aber weniger die Länge dieser Liste entscheidend. Wichtiger ist, dass unsere Spezialist:innen viele Probleme schon in echten Systemlandschaften erlebt haben – einschließlich Migration, Infrastruktur, Betrieb und der unvermeidlichen Altlasten.
Wer als Spezialist:in in ein fremdes Projekt kommt, betritt auch das fachliche Revier anderer Menschen. Das braucht Respekt.
Ein gutes Beispiel ist unsere Zusammenarbeit im Netzwerk 1_FORGE. Unsere Kolleg:innen von sitegeist haben bereits mehrfach unser Keycloak-Wissen genutzt. Das Projekt blieb vollständig bei ihnen: Verantwortung, Steuerung und Kundenbeziehung wechselten nicht. Wir steuerten lediglich den Baustein für Authentifizierung und Autorisierung bei.
Wir versuchen in solchen Situationen nicht, unseren Anteil am Projekt zu vergrößern. Wir müssen auch nicht beweisen, dass wir alles anders gebaut hätten. Unsere Aufgabe ist erfüllt, wenn der fehlende Baustein funktioniert und das verantwortliche Team gut damit weiterarbeiten kann.
Ähnlich ist es bei ChurchTools. Für das bestehende System entwickeln wir individuelle Erweiterungen. Zwei oder drei Mitarbeiter:innen bei punkt.de kennen diese Arbeit gut. Es braucht dafür kein neues Projektteam und keine zusätzliche Managementebene. Kund:innen sprechen direkt mit den Menschen, die beraten und entwickeln.
Eine klare Aufgabe darf ein klares Ende haben.
Wenn wir eine Softwareerweiterung fertiggestellt haben, dokumentieren und übergeben wir sie. Das bestehende Team arbeitet weiter. Wir erwarten nicht, dass der Kunde anschließend fortlaufend Aufgaben für uns findet. Vielleicht hören wir ein Jahr nichts voneinander – und helfen dann beim nächsten Problem.
Braucht ein Baustein dauerhafte Pflege, bleiben wir in einem kleinen Umfang an Bord. Ein Keycloak-Server muss beispielsweise aktualisiert, überwacht und bei Veränderungen angepasst werden. Dafür setzen wir meist eine schlanke Wartungsvereinbarung auf, keinen künstlich großen Projektvertrag.
Diese Freiheit macht die Beziehung nicht schwächer. Sie macht sie unkompliziert. Ein Ansprechpartner hat nach einem Unternehmenswechsel sogar beim neuen Arbeitgeber wieder unsere Spezialist:innen beauftragt. Für mich zeigt das ziemlich gut, welches Gefühl wir mit SPZ erreichen wollen: Man kann uns hinzuholen, wenn es schwierig wird, ohne sich gleich auf ein Großprojekt festzulegen.
Manchmal stellt sich während des Einstiegs heraus, dass nicht ein einzelnes Thema, sondern mehrere miteinander verknüpfte Bereiche gelöst werden müssen. Dann wechseln wir den Modus und stellen ein klassisches Projektteam zusammen.
Das ist kein Scheitern des SPZ-Ansatzes. Im Gegenteil: Die Spezialist:innen, das erste Wissen und die Beziehung zum Kunden sind bereits da. Ergänzt werden Product Owner:in, weitere Kompetenzen und die Strukturen, die ein größeres Vorhaben braucht.
Genauso wichtig ist die andere Richtung: Wir sagen, wenn wir etwas nicht können. Wir graben uns in viele Themen tief ein, aber nicht in alle. Dann vermitteln wir Kolleg:innen aus unseren Netzwerken, etwa von sulit.digital oder aus 1_FORGE. Kund:innen sollen die passende Hilfe bekommen – nicht zwingend eine Rechnung von punkt.de.
Bei vielen Open-Source-Systemen gibt es keinen klassischen Hersteller-Support. Spezialisierte Dienstleister übernehmen diese Rolle. Wir sind beispielsweise offizieller Matomo Implementation Partner und Sylius-Partner. Für Elastic und Keycloak haben wir über viele Projekte Erfahrung aufgebaut.
Im Alltag sprechen Kund:innen trotzdem nicht mit einer anonymen Organisation. Sie kennen ihre ein oder zwei Ansprechpartner:innen direkt. Der Unterschied zu einem einzelnen Freelancer zeigt sich erst, wenn ein Problem über das ursprüngliche Fachgebiet hinausgeht oder mehr Kapazität gebraucht wird.
Dann können unsere Spezialist:innen intern Kolleg:innen aus Entwicklung, Infrastruktur oder einem anderen SPZ-Bereich hinzuziehen. Die direkte Beziehung bleibt klein. Das Netz dahinter ist größer.
SPZ fühlt sich anders an als ein klassisches punkt.de-Projekt. Es gibt weniger Anlauf, weniger Rollen und meistens auch weniger langfristige Bindung. Die Haltung bleibt dieselbe: zuhören, Zusammenhänge verstehen und ehrlich sagen, was wir beitragen können.
Im besten Fall erlebt der Kunde uns nicht als neue Partei, die erst ihren Platz im Projekt sucht. Sondern als Kolleg:innen auf Zeit: Wir steigen ein, arbeiten mit den Menschen vor Ort an ihrem Problem und übergeben eine Lösung, mit der sie selbstständig weiterkommen.
Wie groß unser Anteil wird, ist nicht das Ziel. Entscheidend ist, dass die Zusammenarbeit leicht bleibt und das bestehende Projekt danach stärker ist als vorher.
