Servicestandard-Bericht

Selbstaudit des Teams über die Anwendung des Servicestandards, herausgegeben vom Bundesministerium des Innern und für Heimat

Der Online-Dienst „Steuerlotse für Rente und Pension“ erfüllt in 13 von 19 Punkten den Servicestandard. Drei Punkte wurden teilweise erfüllt, während nicht weitere nicht zutreffend waren und nur ein Punkt nicht erfüllt werden konnte. Die einzelnen Punkte werden weiter unten genauer erläutert.

Status: erfüllt

Zusammenfassung:

• Ab Projektstart: regelmäßige Einbeziehung der Nutzenden in den Gestaltungs- und Entwicklungsprozess
• Methoden u. a. qualitative Interviews, Workshops, Usability-Tests
• Insgesamt Befragung von über 70 Personen in Einzel- oder Gruppengesprächen
• Gesprächszeit von insgesamt mehr als 60 Stunden

Begründung:
Im Jahr 2020 hat sich ein interdisziplinäres Team bestehend aus den Disziplinen Produktmanagement, Design und Software-Entwicklung innerhalb des Fellowship-Programms Tech4Germany bereits mit dem Thema befasst und in einer initialen Discovery-Phase den Problembereich erforscht. Das Projekt baute auf dem Papiervordruck „Erklärung zur Veranlagung von Alterseinkünften“ (EZVA) auf, der durch die vier Bundesländer Brandenburg, Bremen, Mecklenburg-Vorpommern und Sachsen im Vorfeld erarbeitet worden war. Die grobe Zielgruppe für das Projekt – „Rentner:innen und Pensionär:innen ohne Zusatzeinkünfte“ – war somit schon vorgegeben.

Nachdem klar war, auf welche Nutzergruppe sich das Team zunächst konzentrieren wollte, wurde mit der Prototyp-Entwicklung begonnen und erste Usability-Tests geplant. Insgesamt gab es drei Runden mit Interviews, in denen der Prototyp des Steuerlotsen mit insgesamt 20 Senior:innen getestet wurde.

Weiterhin wurden relevante Studien ausgewertet sowie Expertengespräche geführt, u. a. mit Mitarbeitenden des Bundesministeriums der Finanzen und Mitarbeitenden eines lokalen Finanzamtes. Hieraus wurden Erkenntnisse gewonnen zu Themen wie der internen Arbeitsweise, Verarbeitung von eDaten und Papiervordrucken (siehe Research von Tech4Germany).

Aus all diesen Formaten konnten Anforderungen abgeleitet werden, die für ein mögliches digitales Produkt infrage kamen: Anforderungen, die zwingend benötigt wurden, sowie Wünsche, die über das unbedingt Notwendige hinausgingen.

Mit Hilfe der Erkenntnisse zu den Anforderungen wurde der Prototyp iteriert und weiterentwickelt. Er stellte zwar noch kein echtes Produkt im Live-Betrieb dar, vermittelte aber schon ein Gefühl dafür, wie ein solches Produkt funktionieren könnte.

Basierend auf allen Erkenntnissen aus der dreimonatigen Fellowship-Phase und dem bereits vorhandenen Prototypen konnte ein interdisziplinäres Team des DigitalService (Produktmanagement, Design und Software-Entwicklung) im Anschluss den Dienst nahtlos weiterentwickeln.

Das Team konnte ein MVP (Minimum Viable Product = eine minimal funktionsfähige Produktversion) definieren, das die wichtigsten Bedürfnisse der Zielgruppe erfüllen sollte und gleichzeitig Raum für Weiterentwicklung ließ.

Es wurden außerdem weiterhin Interviews und Usability-Tests mit potenziellen Nutzer:innen durchgeführt, um die Bedienbarkeit des Dienstes optimal an die Bedürfnisse, Kenntnisse und Fähigkeiten der Zielgruppe anzupassen. Im Verlauf des Projekts wurden so über 70 Personen in Einzel- oder Gruppengesprächen befragt, mit einer gesamten Gesprächszeit von mehr als 60 Stunden.

Um die benötigte Geschwindigkeit von Entwicklung und Iterationen zu gewährleisten, wurden bereits in Interviews die wichtigsten Erkenntnisse festgehalten, bzw. eine Synthese der Beobachtungen im Nachgang durchgeführt.

Auf Nutzerzentrierung legen sowohl der DigitalService als auch die Projektteams der Fellowship-Programme großen Wert.

Status: erfüllt

Zusammenfassung:

• Aufsetzen auf Vorarbeit aus vier Bundesländern (Brandenburg, Bremen, Mecklenburg-Vorpommern und Sachsen) in Form der EZVA
• Anschließende Gestaltung durch erfahrene Designer:innen, die Expert:innen für gängige Bedienmuster sind
• Überarbeitung der EZVA-Vorlage (z. B. andere Reihenfolge der Fragen, mehrfache Überarbeitung von Eingabemöglichkeiten), um digitale Nutzung noch einfacher zu gestalten
• Kommunikation der Nutzungsvoraussetzungen auf der Webseite sowie Bereitstellen eines Vorabfragebogens (wenige Fragen, direktes Ergebnis, ob Nutzung möglich ist)
• Regelmäßige Usability-Tests mit der Zielgruppe

Begründung:
Einfache und intuitive Nutzung ist eines der obersten Ziele für alle Produkte des DigitalService, auf das von Beginn an hingearbeitet wird. Im Fall des Steuerlotsen wurde schon vorab von anderer Stelle eine tolle Vorarbeit gemacht, auf die das Team aufsetzen konnte: der Papiervordruck für die EZVA.

Dieser Vordruck ist bereits eine vereinfachte Steuererklärung für Renter:innen und Pensionär:innen ohne Zusatzeinkünfte, sodass sowohl das Team im Fellowship als auch das Team des DigitalService inhaltlich keine Vereinfachung mehr erarbeiten musste.

Das Team konnte sich also zunächst darauf konzentrieren, das vereinfachte Formular der Zielgruppe in digitaler Form gut nutzbar zur Verfügung zu stellen.

Die Designer:innen sind ausgebildet und sensibilisiert dafür, Dienste zu entwickeln, die für alle Bürger:innen nutzbar sind und sich an gängigen Bedienmustern orientieren. Die Zielgruppe der Renter:innen und Pensionär:innen ist jedoch noch einmal spezieller, da sich ihre digitalen Erfahrungen und Verhaltensmuster von denen anderer (bspw. jüngerer) Zielgruppen oft unterscheiden. Deshalb ist es umso wichtiger, die Zielgruppe kontinuierlich in den Gestaltungsprozess mit einzubeziehen, um den Dienst so einfach und intuitiv wie möglich zu gestalten.

Das bedeutet: Eingabemöglichkeiten wurden mehrfach überarbeitet, um die bestmögliche Nutzung zu ermöglichen. Anfangs hat sich das Team eng an den Papiervordruck gehalten, ist jedoch im Laufe der Entwicklung zugunsten der einfacheren Nutzbarkeit immer mehr davon abgewichen. Beispiel: Die Angaben zum Pauschbetrag bei Behinderung wurden letztlich anders aufgeteilt als im Papiervordruck, da die Reihenfolge der Fragen im digitalen Kontext wenig Sinn ergeben hat.

Ebenso wurde versucht, Frustration im Voraus zu vermeiden, indem die Voraussetzungen für die Nutzung des Steuerlotsen nicht nur kommuniziert, sondern auch mit einem Vorabfragebogen einfach zugänglich gemacht wurden. Nutzer:innen bekamen nach der Beantwortung weniger Fragen das Ergebnis, ob sie den Dienst nutzen können oder nicht. Dieses Vorgehen war für die Zielgruppe einfacher, als selbst anhand von Beschreibungen zu erkennen, ob der Dienst für sie nutzbar ist.

Erreichen konnten die Nutzenden den DigitalService über eine E-Mail-Adresse. Ein Kontaktformular oder einen Chat gab es nicht. Ein weiterer Kommunikationsweg wurde depriorisiert, da einerseits für ein MVP entschieden werden musste, wo der Umfang des Dienstes verkleinert werden konnte, um in kurzer Zeit den größten Mehrwert für die Nutzenden zu schaffen. Andererseits wäre beispielsweise für die Kommunikation über einen Chat auch immer eine Person nötig gewesen, die schnell auf Anfragen reagieren kann. Denn Nutzende erwarten bei diesem Kommunikationskanal kürzere Antwortzeiten. Diesen Umfang an Support-Ressourcen konnte das Team nicht bereitstellen.

Viele Nutzer:innen hatten zudem Fragen, die über die Nutzung des Dienstes hinausgehen, beispielsweise speziell zu fachlichen Steuer-Themen. Da der DigitalService genauso wie das Finanzamt keine Steuerberatung anbieten kann und darf, konnten diese Fragen leider nicht beantwortet werden. Eine Erkenntnis hieraus: In zukünftigen Projekten sollte ggf. dafür Sorge getragen werden, dass auch solche Anfragen durch entsprechende Personen beantwortet werden können.

Insgesamt wurde bei der Gestaltung und Entwicklung des Steuerlotsen sehr darauf geachtet (nicht zuletzt mit Hilfe von Nutzer:innen-Feedback), eine möglichst intuitive und einfache Nutzung zu gewährleisten.

Status: teilweise erfüllt

Zusammenfassung:

• Einfache, bürgernahe Sprache war zentraler Motivator für die Entwicklung des Steuerlotsen
• Berücksichtigung wichtiger Aspekte der Barrierefreiheit, z. B. Farbkontraste und kurze Seiten
• Technisch teilweise nicht optimal umgesetzte Aspekte sollten in der Weiterentwicklung jedoch berücksichtigt werden (wenn der Dienst nicht eingestellt werden würde)
• Evaluation und Beratung durch Expert:innen (Sozialhelden e.V.)
• Kein offizieller Test gemäß BITV 2.0
• Erklärung zur Barrierefreiheit auf der Webseite sowie Aufforderung an Nutzende, Feedback zu geben

Begründung:
Im Hinblick auf Barrierefreiheit war vor allem eine einfache, bürgernahe Sprache ein zentraler Motivator für die Entwicklung des Steuerlotsen. Darauf wurde auch im Laufe der Weiterentwicklung großen Wert gelegt und immer wieder mit der Zielgruppe getestet, ob die Formulierungen im Dienst gut verständlich waren.

In der Gestaltung wurden weitere Punkte berücksichtigt, bspw. hat das Team Farbkontraste auf ausreichende Barrierefreiheit geprüft und bewusst kurze Seiten gestaltet, um den kognitiven Aufwand der Zielgruppe gering zu halten.

Technische Aspekte (z. B. eine klare Strukturierung der Überschriften) konnten im Code zunächst nicht ausreichend berücksichtigt werden, worüber sich das Team bewusst war. Zu diesen Punkten gab es auch öffentliche Kritik von Seiten der Zivilgesellschaft, die das Team sehr ernst genommen und entsprechende weitere Schritte geplant hatte.

Aus diesem Grund gab es etwa zwei Monate nach dem Launch eine Expertenprüfung und -beratung durch die Non-Profit-Organisation „Sozialhelden“. In der weiteren Entwicklung wurde versucht, das Feedback umzusetzen – gänzlich gelungen ist es nicht (z. B. fehlten Erläuterungen in Leichter Sprache und Gebärdensprache). Das Team war jedoch sensibilisiert und hat bis zuletzt versucht, im Rahmen der gegebenen Ressourcen und Prioritäten den Dienst möglichst barrierearm weiterzuentwickeln.

Nutzende konnten über die Seite „Erklärung zur Barrierefreiheit“ per E-Mail Feedback geben, das ebenfalls in der Weiterentwicklung des Dienstes berücksichtigt wurde.

Ein offizieller Test gemäß BITV 2.0 wurde nicht durchgeführt.

Status: erfüllt

Zusammenfassung:

• Informationen, die Finanzämtern vorliegen, wurden berücksichtigt, sodass Nutzende sie nicht selbst eingeben mussten (Ergebnis: sehr schlankes Formular für die Nutzenden)
• Keine Nutzung von standardisierten Datenfeldern

Begründung:
Für den Steuerlotsen wurden Daten von Nutzenden, die dem Finanzamt vorlagen, wiederverwendet. Informationen u. a. zu Renten, Pensionen, Kranken- und Pflegeversicherungen mussten von Nutzer:innen nicht selbst eingegeben werden, sondern wurden automatisch berücksichtigt. Das zugrunde liegende Ziel: ein sehr schlankes Formular für die Steuererklärung anbieten zu können. Die berücksichtigten Daten wurden den Nutzenden allerdings nicht noch mal angezeigt (wie es oft bei anderen Anbietern passiert) und es wurden basierend auf der SteuerID auch keine Felder automatisch ausgefüllt (wie z. B. Name, Adresse etc.).

Standardisierte Datenfelder wurden nicht genutzt, u. a. weil das Team sich anfangs eng am EZVA-Vordruck orientiert hat und deshalb Themen wie föderales Informationsmanagement (FIM) oder verwaltungsübergreifende digitale Austauschstandards (XÖV) zurückgestellt hat.

Status: erfüllt

Zusammenfassung:

• Datensparsame Entwicklung hatte oberste Priorität
• Überwiegend: Zwischenspeicherung, keine dauerhafte Speicherung von eingegebenen Daten
• Geringe Speicherzeit für notwendige personenbezogene Daten
• Regelung des Datenschutzes in einem Datenschutzkonzept mit Hilfe eines Datenschutzbeauftragten
• Beratung durch den Datenschutzbeauftragten des Bundesministeriums der Finanzen

Begründung:
Um allen Anforderungen der Datenschutz-Grundverordnung (DSGVO) und des Bundesdatenschutzgesetzes (BDSG) gerecht zu werden, hat sich das Team explizit dafür entschieden, so datensparsam wie möglich zu arbeiten und besonders umsichtig mit personenbezogenen Daten umzugehen. Das heißt: Nutzende haben sich im Dienst zwar registriert, um einen Freischaltcode beantragen und damit ihre Steuererklärung absenden zu können, die Daten wurden jedoch nicht dauerhaft, sondern lediglich temporär gespeichert. Die eingegebenen Formulardaten wurden im Cookie des Browsers für eine Session von drei Stunden bis zum Absenden der Steuererklärung zwischengespeichert. Die Daten zur Anmeldung (Steueridentifikationsnummer, Geburtsdatum und Informationen zum Freischaltcode) wurden temporär in einer Datenbank gespeichert. Hatte eine Person einen Freischaltcode beantragt, hatte sie 90 Tage Zeit, sich mit dem Code anzumelden, um dann die Steuererklärung zu machen. Passierte dies nicht, wurden die Anmeldedaten in der Datenbank gelöscht. Nach dieser ersten Anmeldung hatten Nutzer:innen 60 Tage Zeit, die Steuererklärung abzugeben. Erst dann wurden die Daten (ID + Freischaltcode) gelöscht. Hatte jemand erfolgreich seine Steuererklärung abgeschickt, wurden alle Daten nach zehn Minuten gelöscht.

Insgesamt hatte das Team sowohl zu Beginn als auch stetig während der Weiterentwicklung hinterfragt, welche Daten es wirklich braucht, wie lange sie gespeichert werden müssen oder eben nicht, und bewertete, ob es ggf. sinnvoll wäre, mehr Daten zu speichern, um es den Nutzer:innen noch einfacher zu machen. Das Credo war jedoch mit Blick auf die Sicherheit der Daten der Nutzer:innen immer: „So viel wie nötig, so wenig wie möglich“.

Die Rahmenbedingungen für diesen Umgang mit den Daten der Nutzenden wurden in Zusammenarbeit mit dem Datenschutzbeauftragten des DigitalService in einem Datenschutzkonzept festgehalten. Auch der Datenschutzbeauftragte des BMF wurde zu Rate gezogen.

Im Hinblick darauf reifte im Live-Betrieb und in Usability-Tests die Erkenntnis, dass bspw. ein Nutzerkonto, in dem eingegebene Daten hätten gespeichert werden und Nutzer:innen ihre Daten noch einmal hätten einsehen und weiterbearbeiten können, viele Vorteile für die Nutzenden des Steuerlotsen geboten hätte. Vorteile, die auch viele Anbieter von Steuerprogrammen ihren Kund:innen bieten. Das bedeutete für das Team: Wäre der Steuerlotse weiterentwickelt worden, wäre ggf. ein umfassenderes Nutzerkonto eingeführt worden und es wären entsprechend doch mehr Daten gespeichert worden.

Status: erfüllt

Zusammenfassung:

• Kommunikation der Vorteile des Steuerlotsen auf der Webseite und der Nutzungsvoraussetzungen
• Zusätzlich: Bereitstellung eines Kurzfragebogens, der Nutzer:innen vorab und sofort mitteilt, ob sie den Dienst nutzen können oder nicht
• Bürgernahe Formulierungen, die regelmäßig mit Zielgruppe getestet wurden
• Förderung der digitalen Nutzung auch auf analogem Wege, z. B. Verteilen von Broschüren, die über den Dienst informieren
• Einbindung in Bundes- oder Länderportale war in Vorbereitung
• Alternative zum Online-Dienst war in vier Bundesländern durch den EZVA-Vordruck gegeben

Begründung:
Das Team hat im Laufe des Projekts gelernt, dass die Förderung digitaler Nutzung viele Ebenen umfasst: Einerseits muss man der Zielgruppe erst einmal bekannt machen, dass es einen einfachen und gut nutzbaren Dienst wie den Steuerlotsen gibt. Gleichzeitig ist es auch dann, wenn der Dienst bereits bekannt ist, eine Herausforderung, der Zielgruppe ihre Unsicherheiten im Umgang mit digitalen Medien zu nehmen. Viele hatten Angst, Fehler zu machen. Ein großer Teil der Arbeit bestand entsprechend darin, die Nutzer:innen zu ermutigen, sie bestmöglich zu begleiten und zu unterstützen.

Zu diesem Zweck wurden auf der Webseite des Steuerlotsen zielgruppengerecht die Vorteile des Dienstes aufgezeigt, z. B. dass der Dienst speziell auf Rentner:innen und Pensionär:innen zugeschnitten ist, dass es eine Schritt-für-Schritt-Anleitung gibt, und dass der Dienst kostenlos und ohne ELSTER-Konto nutzbar ist.

Die Formulierungen wurden vom Team seriös, aber bürgernah getextet. Beispielsweise wurden leicht verständliche und möglichst kurze Sätze formuliert und komplizierte Fachbegriffe aus der Behördensprache vermieden.

Um den Steuerlotsen für potenzielle Nutzende einfacher auffindbar zu machen, hatte u. a. das BMF auf seiner Webseite auf den Dienst hingewiesen. Suchte man bspw. nach dem Begriff „Steuererklärung Rentner“ über eine Suchmaschine, tauchte zwar der Steuerlotse nicht auf der ersten Ergebnisseite auf, jedoch die Seite des BMF mit dem Hinweis auf den Steuerlotsen. So profitierte der Dienst von der externen Verlinkung durch das BMF.

Eine Einbindung in Bundes- oder Länderportale konnte bis zuletzt nicht erreicht werden, war jedoch in Vorbereitung.

Eine umfangreiche Optimierung für Suchmaschinen wurde aus finanziellen Gründen nicht als externe Expertise eingekauft. Stattdessen wurde mit „Bordmitteln“ versucht, die Webseite suchmaschinenkonform und gut auffindbar zu gestalten. Ein Beispiel: Mit Content-Artikeln zu Steuerthemen wurde versucht, mehr Traffic auf die Webseite des Steuerlotsen zu leiten. Außerdem wurde mit einer Querverlinkung von der Webseite der „Grundsteuererklärung für Privateigentum“ (ein anderer Online-Dienst des DigitalService) auf die Webseite des Steuerlotsen Traffic generiert.

Abgesehen von der Auffindbarkeit hat das Team nicht nur versucht, auf digitalem Wege die Nutzung zu fördern, sondern auch auf analoge Art und Weise: Auf Events, deren Teilnehmer:innen der Zielgruppe des Steuerlotsen entsprachen oder von entsprechenden Steuervereinen, wurde der Dienst vorgestellt. Zuletzt hat das Team Papier-Broschüren gestaltet und gedruckt, um über den Dienst zu informieren (zunächst in einer kleinen Stückzahl als Testlauf, der sehr gut angenommen wurde).

Zudem hatte das Team schon in der Discovery-Phase des Tech4Germany Fellowships angeregt, auch eine Alternative zum Online-Dienst anzubieten, denn: Dies wäre zumindest dem Teil der Zielgruppe entgegengekommen, der sich in der digitalen Welt nicht gut auskennt. Im Prototypen und auch dem späteren MVP wurde diese Idee jedoch depriorisiert, da eine digitale Nutzung auch den Verwaltungsmitarbeitenden ihre Arbeit erleichtert und zumindest in vier Bundesländern ja ohnehin der EZVA-Papiervordruck verfügbar war. Deshalb war es aus Sicht des Teams vertretbar, (noch) keine Alternative zur digitalen Nutzung anzubieten.

Im Laufe der Weiterentwicklung wurde jedoch im Team wiederholt darüber gesprochen, ob gegebenenfalls eine Variante des Dienstes, in der die digitale und analoge Welt verknüpft werden, umgesetzt werden könnte: eine Variante, in der online das Formular ausgefüllt und dann ausgedruckt wird. Dies hätte den Vorteil gehabt, dass auch Personen mit ELSTER-Konto, die den Dienst aus technischen Gründen sonst nicht nutzen konnten, auch die Vorteile des einfachen Ausfüllens hätten nutzen können. Wäre der Dienst weiterentwickelt worden, hätte diese Idee wahrscheinlich ihren Weg ins Produkt gefunden.

Status: nicht zutreffend

Begründung:
Die Anforderung „Rechtliche Änderungsbedarfe“ war im Fall des Steuerlotsen nicht zutreffend, da bereits eine Self-Service-Schnittstelle vorhanden und im Gesetz verankert war (und nach wie vor ist). Auch abseits davon gab es keine rechtlichen Hindernisse.

Status: erfüllt

Zusammenfassung:

• Anwendung und Adaption agiler Methoden, z.B. Scrum-Framework und iterative Produktentwicklung
• Anwendung von Design-Thinking-Methoden
• Interdisziplinäres Team, das in Projekt- und Produktentscheidungen einbezogen wurde

Begründung:
Zur Umsetzung des Projektvorhabens hat zunächst das Tech4Germany Team und später auch das Team des DigitalService mit etablierten agilen Methoden gearbeitet.

Das bedeutete in diesem Fall auch: Es gab kein Lastenheft oder vorgegebene Lösungen, sondern es wurden kontinuierlich die am höchsten priorisierten Probleme der Nutzer:innen bearbeitet, sodass schnell ein Prototyp für Lösungsideen getestet und dieser iteriert/weiterentwickelt werden konnte.

So entstand im dreimonatigen Fellowship mit Hilfe von Design-Thinking-Methoden und einer agilen Vorgehensweise (z. B. Iterationen basierend auf neuen Erkenntnissen) ein Prototyp, der vom DigitalService übernommen und iterativ zu einem MVP weiterentwickelt werden konnte.

Basierend auf dem Scrum-Framework gab es kurze Entwicklungszyklen von zwei Wochen inklusive aller sinnvollen Regeltermine, die das Framework mit sich bringt. So konnte das gesamte Team in den Standups, Plannings, Refinements, Reviews und Retros mit in den Prozess einbezogen werden. Auch die Stakeholder:innen wurden, wenn es sinnvoll oder notwendig war, in Rituale einbezogen.

Das Team hat sich also gängiger Methoden bedient, aber: Es hat sie für sich adaptiert und nicht strikt „wie aus dem Lehrbuch“ verfolgt, wenn es nicht sinnvoll erschien. Ein Beispiel: In der letzten großen Entwicklungsphase (Vorbereitung der Einstellung des Steuerlotsen) wurde von einem zweiwöchentlichen auf einen wöchentlichen Rhythmus umgestellt. Es gab ab diesem Zeitpunkt u. a. wöchentliche, aber zeitlich kürzere Retrospektiven und dafür wurde auf Refinement-Termine verzichtet, weil diese nicht mehr benötigt wurden.

Hervorzuheben ist, dass das Team die regelmäßigen Retrospektiven sehr ernst genommen hat und stets jede und jeder Einzelne Bedenken, aber auch Positives vorbringen konnte, sodass das Team daraus Aufgaben ableiten konnte, wie die Zusammenarbeit besser funktionieren kann (oder auch: Was unbedingt beibehalten werden sollte). Dementsprechend war auch das gesamte Team sowohl im Fellowship als auch im DigitalService von Beginn an gleichberechtigt an Entscheidungsprozessen beteiligt. Mitarbeitende aus den Bereichen Produktmanagement, Design und Software-Entwicklung waren an jedem Schritt der Entwicklung beteiligt und konnten ihre Sichtweisen und Ideen einbringen.

Status: nicht erfüllt

Begründung:
Dem Team war bewusst: Um ein erfolgreiches Produkt entwickeln und viele Menschen erreichen zu können, musste es einer breiten Masse bekannt gemacht werden – und dafür brauchte es Unterstützung durch Bund und Länder.

Deshalb hatte das Team sich darum bemüht, eine Einbindung in Bundes- und Länderportale zu erreichen. Die Vorbereitungen dazu liefen bereits, konnten jedoch noch nicht zum Abschluss gebracht werden, da es sich um einen längeren Vorgang mit vielen involvierten Interessengruppen handelt. Insbesondere bei schnellen und zeitlich begrenzten Entwicklungszyklen ist dieser Punkt nur schwer bis gar nicht zu erfüllen. Wir empfehlen eine Überprüfung des aktuell zugrunde liegenden Prozesses, um eine leichtere Integration in einen Portalverbund zu ermöglichen.

Status: erfüllt

Zusammenfassung:

• Sowohl Tech4Germany Team als auch DigitalService Team: interdisziplinär aus Produktmanger:innen, Designer:innen und Entwickler:innen zusammengesetzt
• Einbeziehung von Fach-/Steuerexpertise, wenn notwendig (sowohl durch das BMF als auch durch unabhängige Steuerexpert:innen)
• Regelmäßige und transparente Abstimmungen mit Stakeholder:innen
• Unterstützung durch Abteilungsleitung

Begründung:
Das Projektteam im Fellowship Tech4Germany und auch das Team des DigitalService waren von Beginn an interdisziplinär aufgestellt. Teammitglieder aus den Disziplinen Produktmanagement, Design und Software-Entwicklung waren gleichberechtigt am Prozess beteiligt, jeder und jede konnte Wissen und Erfahrungen einbringen. Außerdem wurden Expert:innen immer dann zu Rate gezogen, wenn es notwendig war. Einen fachlichen „Blindflug“ gab es dementsprechend nicht, sodass keine falschen Annahmen getroffen und entsprechend keine Zeit vergeudet wurde.

Des Weiteren stand dem DigitalService ein externes Steuerberatungsbüro als unabhängige Expertenberatung für fachliche Fragen zur Verfügung.

Und: Relevante Stakeholder:innen wurden in jeden Schritt des Projekts einbezogen und weitere Expert:innen (z. B. Mitarbeiter:innen aus einem Finanzamt in Brandenburg) zu Rate gezogen, wenn fachliches Wissen notwendig war.

Die Abstimmung mit den Stakeholder:innen erfolgte regelmäßig (z. B. durch zweiwöchentliche Jour fixes) und transparent. Unterstützung erhielten die Teams zu jeder Zeit durch die Abteilungsleitung im Bundesministerium der Finanzen.

Darüber hinaus gab es Kommunikation zwischen Bund und Ländern, die für zukünftige Projekte dieser Art noch intensiver gestaltet werden soll.

Status: nicht zutreffend

Begründung:
Im Fall des Steuerlotsen war eine Entwicklungsgemeinschaft nicht zutreffend, da es unter Umständen die Entwicklung sogar verlangsamt hätte. Ein kleines Team konnte so unabhängig schnell etwas entwickeln, da finanzielle Mittel und der Zugang zu relevantem Wissen bereits vorhanden waren.

Status: erfüllt

Zusammenfassung:

• Arbeit mit offenen Standards in Anwendungsentwicklung und Betrieb
• Keine proprietären Formate eingesetzt

Begründung:
Das Team hat von Beginn an auf Offenheit gesetzt und immer das Credo verfolgt, entsprechend der verfügbaren Ressourcen möglichst offen zu arbeiten – in jeglicher Hinsicht. Die Teammitglieder haben immer bewusste Entscheidungen zugunsten offener Standards getroffen, nicht zuletzt, um möglichst effizient Software entwickeln zu können.

In der Anwendungsentwicklung wurde mit Web-Standards (HTML, CSS, JavaScript) gearbeitet, die interne Kommunikation zwischen Diensten fand ausschließlich über offene Protokolle und Datenformate wie REST, HTTP(s), JSON, SQL statt. Für die Kommunikation mit der Finanzverwaltung wurde auf ERiC gesetzt. Proprietäre Formate kamen nicht zum Einsatz.

Im Betrieb wurde mit einer Infrastruktur gearbeitet, die auf offenen Standards wie Kubernetes und OpenStack basiert und die, soweit möglich, über den de facto Standard Terraform (HCL) konfiguriert wurde.

Status: erfüllt

Zusammenfassung:

• Veröffentlichung und Open-Source-Lizenzierung aller Eigenentwicklungen
• Quellcode verfügbar unter github.com/digitalservicebund/steuerlotse und github.com/digitalservicebund/ericaMIT-lizensiert
• Multiparadigmatische Entwicklung mit Objektorientierung als Standard
• Dokumentation vor allem durch „sprechende Namen“ und umfangreiche Test-Suite

Begründung:
Das Team hatte von Beginn an die Veröffentlichung des Quellcodes aller Eigenentwicklungen geplant und kurz nach dem ersten Livegang umgesetzt. Ab diesem Zeitpunkt fand die Entwicklung komplett „in the open“ statt.

Die vom Team selbst entwickelten Komponenten des Steuerlotsen wurden unter der freizügigen Open-Source-Lizenz „MIT“ bereitgestellt. Das bedeutet, dass diese Komponenten für alle kostenlos und ohne Einschränkungen nutzbar und modifizierbar waren und auch weiterhin sind.

Das Projekt stützt sich zudem stark auf von der Community entwickelte Open-Source-Bibliotheken wie z. B. Flask oder React, die alle quelloffen verfügbar sind. Lediglich die bereits bestehende, von der Finanzverwaltung bereitgestellte Software ERiC ist nicht quelloffen verfügbar.

Der Code wurde vorwiegend objektorientiert konzipiert und entwickelt und gründlich mit Unit-, Integrations- und Akzeptanztests abgedeckt, wobei punktuell auch Paradigmen verwendet wurden, die auf die jeweiligen Sprachen und Bibliotheken besser passen (z. B. funktionale Komponenten in React oder prozedurale Funktionen in Python).

Die Dokumentation wurde auf drei Ebenen umgesetzt:

• sprechende Namen im Sinne der „Clean Code“-Methode;
• stellenweise Methoden-, Klassen- und Codekommentare, falls sie zum Verständnis der Abläufe notwendig sind;
• eine umfangreiche Test-Suite, aus der das erwartete Verhalten hervorgeht.

Status: erfüllt

Zusammenfassung:

• Weiterentwicklung von Tech4Germany Projekt
• Nachnutzung ERiC/ELSTER
• Einsatz von Open-Source-Bibliotheken
• Cloud-Nutzung

Begründung:
Das Projekt ist eine Weiterentwicklung eines bestehenden Prototyps aus dem Fellowship-Programm Tech4Germany und stützt sich auf die von der Finanzverwaltung bereitgestellte ERiC-Bibliothek, die eine sichere und inhaltlich geprüfte Kommunikation mit ELSTER erlaubt. Dadurch konnte sich das Team vollends auf die eigene Anwendungsdomäne konzentrieren und seine Ressourcen effizient und wirtschaftlich einsetzen. Wo immer möglich wurden für Funktionalitäten, die nicht projektspezifisch sind, Open-Source-Bibliotheken eingesetzt, um den Umfang der Eigenentwicklung zu beschränken.

Dieses Prinzip wurde auch auf den Betrieb angewendet, wo möglichst standardisierte Verfahren eingesetzt wurden. Die Dienste eines Cloud-Anbieters – der SysEleven GmbH, ein 100 % Tochterunternehmen der secunet AG, welche u. a. die hochsicheren SINA-Arbeitsplätze der Bundesverwaltung bereitstellt – wurden in Anspruch genommen, um es dem Team zu ermöglichen, sich auf die Applikationsentwicklung zu konzentrieren konnten und die eigenen Aufwände in diesem Bereich niedrig zu halten.

Status: erfüllt

Zusammenfassung:

• Verschiedene Dokumente erstellt, u. a. Sicherheitskonzept inkl. Betrieb, Hosting, Software-Architektur
• Vertragliche Regelungen mit technischem Dienstleister, u. a. bzgl. Sicherheitsvorfällen
• Nach einem Ausfall: gründliche Analyse gemeinsam mit IT-Dienstleister, um zukünftige Vorfälle zu vermeiden
• Kein BSI-Grundschutzcheck, dafür alternative Maßnahmen: externe Prüfung durch einen Sicherheitsexperten sowie externer Penetrationstest

Begründung:
Zu Beginn des Projekts wurde ein Sicherheitskonzept aufgesetzt, das in Bezug auf Betrieb und Hosting u. a. die beteiligten Parteien, Rollen und Rechte, eine Schutzbedarfsanalyse, mögliche Schadensfälle, den Umgang mit Sicherheitsvorfällen und die Software-Architektur beinhaltete.

Auch vertraglich wurden Eventualitäten mit dem technischen Dienstleister geregelt, beispielsweise, was bei einem Ausfall oder einem Sicherheitsvorfall zu passieren hatte und welche Vertragspartei für welchen Schritt verantwortlich war.

Nach dem einzigen Ausfall, den es seitens des IT-Dienstleisters gab, wurde ein sogenanntes „Post Mortem“ durchgeführt. Eine Analyse, was genau passiert war und wie man es bei einem möglichen nächsten Ausfall hätte besser machen können. So wussten alle Beteiligten über die Ursachen Bescheid und waren vorbereitet auf eine mögliche nächste Ausfallsituation.

Ein offizieller BSI-Grundschutzcheck wurde nicht durchgeführt. Stattdessen wurde auf alternative Maßnahmen gesetzt: Ein externer Sicherheitsexperte hat den Dienst geprüft und es wurde ein externer Penetrationstest durchgeführt.

Status: erfüllt

Zusammenfassung:

• Übermittlung der Antragsdaten und Identifikation der Nutzenden über die standardisierte ERiC/ELSTER Schnittstelle.

Begründung:
Jegliche produktinterne Datenübertragung basierte auf standardisierten Protokollen, welche unabhängig von den eingesetzten Programmiersprachen und Plattformen waren: von Nutzenden zum Anbieter über Web-Formulare und zwischen internen Diensten über REST/JSON.

Die Übermittlung an die Finanzverwaltung erfolgte über die standardisierte ERiC/ELSTER Schnittstelle, welche gewährleistete, dass die Daten korrekt und sicher übertragen wurden und zudem eine inhaltliche Prüfung übernahm.

Status: teilweise erfüllt

Zusammenfassung:

• Einmal jährlich: Update von ELSTER-Bibliotheken

Begründung:
Einmal im Jahr hatte das Team die ELSTER-Bibliotheken geupdatet. Dies entsprach nicht einer kompletten technologischen Evaluation, bedeutete aber, im Zuge dieses Updates dafür zu sorgen, dass der Dienst weiterhin ohne Störungen zur Verfügung stand.

Wäre der Dienst weiterentwickelt worden, hätte jährlich ggf. eine umfangreichere Bewertung stattgefunden.

Status: teilweise erfüllt

Zusammenfassung:

• Regelmäßige Usability-Tests
• Implementierung von Tracking, mit dessen Hilfe Basisdaten ermittelt wurden, die Rückschlüsse auf Usability und Nutzerzufriedenheit zuließen
• Analyse von Support-Anfragen
• Erhobene Daten größtenteils nur intern zugänglich; Erkenntnisse aus dem Fellowship-Programm Tech4Germany sind öffentlich zugänglich

Begründung:
Um die Nutzerzufriedenheit bzw. die Bedienbarkeit des Produkts zu überprüfen, wurden zum einen regelmäßig qualitative Interviews mit Nutzer:innen durchgeführt, zum anderen wurde im Produkt selbst ein erstes Basistracking implementiert, um Daten wie Unique Visitors, Bounce-Rate, Conversion-Rates, Time-on-Page oder Klickzahlen z. B. für die FAQs zu erheben. Daraus konnte das Team bereits Schlüsse ziehen und etwaige Probleme in der Nutzung erkennen (z. B., wenn die Verweildauer auf einer Seite besonders lang war im Durchschnitt, konnte das Team prüfen, ob eventuell eine Überarbeitung nötig war).

Außerdem konnte auch aus dem Support-Aufkommen und den verschiedenen Anfragen der Nutzer:innen abgeleitet werden, ob sie generell zufrieden mit der Nutzung des Steuerlotsen waren. Wäre der Dienst weiterentwickelt worden, wäre ggf. eine simple Zufriedenheitsabfrage (oder Abfrage, ob eine Seite hilfreich war) auf der Website implementiert worden.

Der Support und auch das Monitoring der Tracking-Daten wurden vom Team selbst betreut, sodass das Feedback, die Fragen der Nutzer:innen und Erkenntnisse aus dem Tracking immer ohne Umwege im Team ankamen und in die Produktentwicklung einfließen konnten. Wäre der Steuerlotse weiterentwickelt worden, hätte das Team gern den Support noch systematischer dokumentiert und analysiert (oder ggf. sogar ein dediziertes Support-Tool genutzt), um noch mehr über die Herausforderungen der Zielgruppe lernen zu können. Zudem hätte das Team dann ggf. andere Tracking-Dienste evaluiert, um zwar datenschutzkonform, aber erkenntnisreicher tracken zu können, da das eingesetzte Tracking-Tool nur ein grobes Bild geliefert hatte und detaillierte Daten, wie sich Nutzende durch die Webseite bewegten, fehlten.

Die erhobenen Daten wurden größtenteils nicht veröffentlicht, da das Team keine Ressourcen hatte, um über geeignete Formate oder Veröffentlichungskanäle zu entscheiden. Allerdings ist die Dokumentation von Erkenntnissen aus der ersten Projektphase (dem Fellowship-Programm Tech4Germany) öffentlich zugänglich: zur Dokumentation.

Status: erfüllt

Zusammenfassung:

• Weiterentwicklung des Dienstes auf Basis von Tracking-Daten, Usability-Tests, Feedback aus Support-Anfragen und Erkenntnissen aus direktem Kontakt zur Zielgruppe (z. B. über Steuervereine)
• Laufende Einbeziehung von Nutzerbedürfnissen in Produktentscheidungen
• Erkenntnisse sind teilweise intern, teilweise öffentlich zugänglich

Begründung:
Das Produkt wurde mit Hilfe der Auswertung von Tracking-Daten, regelmäßigen Usability-Tests, Feedback aus Support-Anfragen und Erkenntnissen aus direktem Kontakt zur Zielgruppe (z. B. bei Veranstaltungen von Steuervereinen) weiterentwickelt.

Die Bedürfnisse und Herausforderungen der Zielgruppe wurden in Produktentscheidungen einbezogen und im Team abgewägt. Auch die Priorisierung der Themen während der Weiterentwicklung wurde basierend auf Erkenntnissen über das Nutzungsverhalten der Zielgruppe vorgenommen.

Diese Erkenntnisse sind teilweise intern, teilweise öffentlich zugänglich. Die Dokumentation aus dem Fellowship-Programm ist bspw. öffentlich zugänglich.