Freiheit und Vorgaben in der Entwicklung – wie uns Delivery-Prinzipien leiten

Unser erstes Prinzip ist so simpel, dass es fast trivial ist: jedes Projekt hat ein Team, das sich gemeinsam auf dieses konkrete Projekt fokussiert. In der Privatwirtschaft ist das häufig Standard, da bekannt ist, dass Menschen, die sich mit Fokus und psychologischer Sicherheit einem Thema widmen, schneller zu hochwertigeren Lösungen kommen.

Anfangs war das bei uns zuweilen noch anders. So gab es in den beiden Projekten, die wir im Bereich „Zugang zum Recht“ hatten, noch vor zwei Jahren ein geteiltes Entwicklerteam. Das führte zu vielen Abstimmungsschleifen, Reibungen und auch Unklarheiten. In der Folge beschlossen wir, auch die Entwickler:innen – so wie bereits die Produktmanager:innen, Transformationsmanager:innen und Designer:innen – fest einem der beiden Projekte zuzuordnen. Hierdurch wurde ihr Fokus geschärft und die Arbeit produktiver. Seitdem hat jedes Projekt ein fest zugeordnetes Team.

Auch unser zweites Prinzip ist recht schlicht: Jedes Team muss ganz klar wissen, was seine Aufgabe ist und welches Problem gelöst werden soll. Die Problem- und Aufgabenstellung muss nicht nur intern, sondern vor allem mit unseren Auftraggebern abgestimmt sein. Um Projekte erfolgreich abschließen und gute Produkte initiieren zu können, muss klar sein, was gemacht werden soll und was zugleich ausgeschlossen werden kann oder muss.

Bereits im Anbahnungsprozess stimmen wir uns eng mit potenziellen Projektpartner:innen über Erwartungen und Kommunikationsweisen ab. So stellen wir vor der Vertrags­zeichnung sicher, dass wir der geeignete Partner für das Projekt sind.

Dieser Austausch endet nicht mit dem Vertragsschluss. Die Entwicklung digitaler Services ist ein dynamischer Lernprozess, bei dem neue Erkenntnisse – etwa aus der Erforschung des Problemraums – fortlaufend Entscheidungen erfordern. Ein kontinuierlicher Abgleich der Ziele und Erwartungen auf Leitungs- und Arbeitsebene ist dafür essenziell.

Im Projekt Servicestandard startete das Projektteam direkt nach Vertragsunterzeichnung mit der Referatsleiterin und dem Referenten in einen Workshop. Darin wurden alle Punkte des zuvor geschlossenen Vertrags hinsichtlich ihrer Priorität und Reihenfolge bearbeitet. Danach starteten wöchentliche Termine mit dem Referenten, monatliche mit der Referatsleiterin und einer pro Quartal mit der Abteilungsleitung.

Unser Team besteht größtenteils aus Menschen, die zuvor in der Privatwirtschaft tätig waren. Wir verstehen uns zwar als Teil der Verwaltung, arbeiten jedoch nicht in einer Behörde. Daher kennen wir behördenspezifische Abläufe und die damit einhergehenden Prozesse häufig nur aus zweiter Hand. Umso wichtiger ist es für uns, zu verstehen, weshalb ein bestimmtes Problem für unsere Projektpartner:innen relevant ist. Häufig sind diese Gründe vielschichtig. Nicht alle von ihnen sind auf den ersten Blick sichtbar.

Es ist für uns daher grundlegend, zu verstehen, was unsere Projektpartner bewegt und motiviert. Nur so können wir mit ihnen zusammen gute Lösungen erarbeiten, die abgelöst von der angewandten Methode eine Wirkung entfalten.

Zu verstehen, wer die Nutzenden eines Angebots sind und welche Umstände und Bedürfnisse sie haben, ist zentral für den Erfolg eines jeden Projekts. Wir müssen diese Dinge frühzeitig in Erfahrung bringen, um nützliche und nutzbare Angebote entwickeln zu können.

Wer die Nutzenden sind und wie wir mehr über ihre Kontexte erfahren, variiert jedoch von Projekt zu Projekt. Daher führen wir stets qualitative und quantitative Daten zusammen. Qualitative Erkenntnisse ergeben sich zum Beispiel aus Vor-Ort-Beobachtungen, Interviews oder Tests mit Nutzenden. Quantitative Datenpunkte erhalten wir aus Webanalyse-Tools oder Feedback von Nutzenden.

In unserer Arbeit an Justiz-Services verbringen die Teams regelmäßig Zeit an Gerichten. Wir beobachten dort Prozesse und Abläufe von Rechtspfleger:innen und testen mit Bürger:innen vor Ort oder bei uns im Büro. Im Rahmen unserer Arbeit an digitalen Identitäten führten wir zusätzlich zu Interviews und Usability-Tests eine quantitative Studie durch. Entsprechend ihrem Themenfeld und der jeweiligen Nutzergruppe finden Teams die passenden Herangehensweisen, um Nutzende und deren Kontexte zu verstehen.

Bevor wir ein Projekt starten, sprechen wir darüber, woran wir erkennen, dass es erfolgreich ist. Wir legen Ziele fest und definieren Erfolgsmetriken. Zu unseren Standardmetriken gehören die Zufriedenheit der Nutzenden, die Konvertierungsrate sowie die Reichweite des Angebots. Diese sind in Punkt 12 des Servicestandards verbindlich gemacht. Darüber hinaus definieren wir vorab spezifische Metriken für das konkret zu lösende Problem. Hierdurch können wir später erkennen, ob es tatsächlich gelöst oder zumindest vereinfacht wurde.

Bei unserem Projekt „Beratungshilfe“ bewerteten 75 % der Nutzenden die Informations­seiten als hilfreich. Die Abschlussrate des Vorab-Checks liegt bei 90 %. Die wichtigere, produktspezifische Metrik ist jedoch die der sogenannten Zwischenverfügungen. Diese werden ausgestellt, wenn Unterlagen fehlen oder Anträge fehlerhaft ausgefüllt wurden. Bei Papieranträgen liegt die Anzahl der Zwischenverfügungen bei 70 % oder mehr. Bei digital ausgefüllten Anträgen konnte das Team die Rate bereits auf 52 % senken.

Unsere Projektpartner:innen aus der Bundesverwaltung sind Teil unserer Teams. Wir bezeichnen sie mit ihrer fachlichen Expertise als unsere fünfte Disziplin. Projektpartner:innen nehmen an agilen Formaten wie Daily Standups oder Sprint-Reviews teil. Wenn Workshops oder kollaborative Termine anstehen, arbeiten unsere Teams mit ihnen vor Ort in der jeweiligen Bundesbehörde, in den Räumlichkeiten des DigitalService oder per Videotelefonie. Über digitale Austauschplattformen haben unsere Projektpartner:innen stets Zugriff auf die Zwischenstände der jeweiligen Projekte. Weil sie sich über die Zeit hinweg so sehr als Teil des Teams fühlen, sind sie es zuweilen, die uns daran erinnern, mit einem Sticker einen erreichten Meilenstein festzuhalten.

In einigen Projekten gibt es jenseits der ministerialen Kolleg:innen weitere wichtige Stakeholder, mit denen wir eng zusammenarbeiten. So haben wir mit allen Pilotgerichten für die digitale Rechtsantragstelle eine Vereinbarung getroffen, wonach wir pro Monat 4 Stunden ihrer Zeit in Anspruch nehmen dürfen. Diese nutzen wir, um von Richter:innen neue Antragsstrecken prüfen zu lassen oder vor Ort mit Rechtspfleger:innen veränderte Abläufe zu testen.

Wir wollen keine singulären Lösungen entwickeln. Zugleich möchten wir sicherstellen, dass unsere Lösungen passgenau zum jeweiligen Problem sind. Daher ist es in unserer Arbeit wichtig, über den Tellerrand des konkreten Projekts hinauszublicken und zu antizipieren, wie sich ein Service im jeweiligen Kontext weiterentwickeln könnte.

Beispielsweise haben wir im Projekt „Digitale Rechtsantragstelle“ eine Servicestrecke konzipiert und gestaltet, die für den konkreten Dienst – die Beantragung von Gerichtskostenbeihilfe – genau passend war. Gleichzeitig sind die verwendeten Komponenten und Module so angelegt worden, dass wir sie für weitere Services wie die Prüfung und Beantragung eines Erbscheins weiterverwenden können. Indem das Team bereits zu Beginn mitgedacht hat, dass es sich hier um ein Puzzlestück eines großen Ganzen handelt, werden die Entwicklungen von Folge-Services auf service.justiz.de weniger aufwendig.

Oft existieren zahlreiche Teile eines digitalen Angebots bereits. Sie müssen daher nicht von Grund auf neu entwickelt, sondern lediglich angepasst werden. Entsprechend dem Servicestandard-Punkt 5 „Bestehendes wiederverwenden und Neues gemeinsam gestalten“ prüfen unsere Teams, was sie benötigen und was andernorts bereits vorhanden ist. In unseren Projekten verwenden wir, wo es möglich ist, zentral bereitgestellte Basiskomponenten.

Zur digitalen Feststellung der Identität von Nutzenden integrierte das Team, das an der digitalen Klageeinreichung arbeitet, die BundID sowie die Komponente Mein Justizpostfach. Zugleich setzen wir in immer mehr Projekten das KERN Designsystem ein. Zudem schließen wir identifizierte Lücken und entwickeln ergänzende Design-Patterns, die wiederum von anderen verwendet werden können.

Die Teams beim DigitalService arbeiten an höchst unterschiedlichen Fragestellungen und in verschiedenen Set-ups. Zugleich können die Teams viel voneinander lernen. Daher gibt es einen wöchentlichen Termin für alle Mitarbeitenden des DigitalService. Darin stellen die Teams den aktuellen Stand ihrer Arbeit vor. Wenn es nach dem „Show the thing“-Format weitere Rückfragen gibt, koordinieren sich die Teams untereinander oder recherchieren im Intranet. Dort werden Arbeitsstände dokumentiert; zudem sind die Slack-Kanäle aller Projekte für alle Mitarbeitenden offen.

Getreu den Organisationswerten „Trau Dich zu lernen“ und „Arbeite offen“ ist Neugierde erwünscht. Teams sind angehalten, ihre Arbeit auf diesem Blog festzuhalten und bei öffentlichen Veranstaltungen zu sprechen. Zudem haben die meisten unserer Projekte mittlerweile offene Roadmaps, sodass Außenstehende ohne viel Aufwand erfahren können, woran unsere Teams gerade arbeiten.

Unsere Projektteams sind für vieles selbst verantwortlich. Dazu gehört die Qualität ihrer Software. Das beinhaltet Sicherheit und Barrierefreiheit. Zugleich sind die Teams nicht auf sich allein gestellt. Durch übergreifend aufgebaute Expertise können sie um Unter­stützung bitten, wenn sie eine technische Risikobewertung benötigen oder einen Test auf Barrierefreiheit für einen Online-Service durchführen lassen möchten.

Alle Teams haben zudem die Aufgabe, zu klären, wie die als Projekte entwickelten Produkte und Services mittel- und langfristig tragfähig sein können. Dafür entwickeln sie entsprechende Betriebsmodelle, die der jeweiligen Bundesbehörde helfen, die notwendigen Strukturen aufzubauen.