Über unsMediaKontaktImpressum
Jutta Eckstein 15. März 2016

Produktivitätserhöhung durch Aufdecken von Verzugskosten

Es gilt, herauszufinden wo die projekt- und teamspezifischen Verzugskosten liegen und diese durch konkrete Aktionen abzustellen. © aleksicze / Fotolia.com
© aleksicze / Fotolia.com

"Wie kommt ein Projekt ein Jahr in Verzug? … einen Tag nach dem anderen." Das hat Fred Brooks einmal so weise gesagt. Der Lean-Gedanke und die Warteschlangentheorie bieten das Wissen an, um dieses Problem zu vermeiden. Damit wird deutlich, wie selbst manche anerkannten Ansätze wie Definition of Ready, Clean Code oder auch Experten im Team zu den Verzugskosten (engl. cost of delay) beitragen können. In diesem Artikel präsentiere ich einfache Werkzeuge und Methoden, um die versteckten Verzugskosten aufzudecken.

Der Kontext

Um eine Aussage zur Produktivitätserhöhung treffen und um darüber hinaus Verzugskosten aufdecken zu können, kommt man nicht darum herum, zu messen. Und damit haben wir schon das erste Problem, denn wie Mihai Nadin einmal so treffend bemerkte: "Wer viel misst, misst Mist." Das liegt vorrangig daran, was mit dem Bonmot "Traue keiner Statistik, die du nicht selbst gefälscht hast" (über den Urheber dieses Zitats wird immer noch gestritten) ausgedrückt wird. Das heißt, alles was gemessen wird, kann so aufbereitet werden, dass das gewünschte Ergebnis vorliegt. Ein gängiges Beispiel in der agilen Entwicklung ist die Messung der Teamgeschwindigkeit (engl. velocity). Es gibt unterschiedliche Messmethoden dafür, die gängigste ist, die Storypunkte der Stories zu addieren, die in einer Iteration (Scrum-Terminologie: Sprint) zur Auslieferung fertiggestellt wurden. Die Storypunkte wiederum spiegeln die Schätzung des Teams wider. Misst man nun diese Teamgeschwindigkeit mit dem Ziel, diese zu erhöhen, so ist der übliche Effekt der, dass das Team zukünftig einfach höher schätzt. Das heißt, eine Story, die bisher mit beispielsweise drei Storypunkten eingeschätzt wurde, wird eben jetzt mit fünf geschätzt – und schon hat sich die Teamgeschwindigkeit um zwei Punkte erhöht.

Der Zweck untermauert die Mittel

Für jede Messung muss der Boden bereitet werden. Dafür muss allen voran der Zweck geklärt werden. Alle, die von der Messung betroffen sind, müssen verstehen, was der Zweck der Messung ist und wer hinter diesem Zweck steht. Ein negatives Beispiel aus einem meiner Projekte macht das deutlich:

Die Qualitätssicherung (QS) wollte sicherstellen, dass der Code auch wirklich mit Unit-Tests verifiziert wird. Dafür wurden in "üblicher" QS-Manier Checklisten erarbeitet, die dies entsprechend überprüften. Außerdem wurde mit entsprechenden Grafiken der Zuwachs der Unit-Tests protokolliert. Der Erfolg war phänomenal. Die Abdeckung lag nach kürzester Zeit bei nahezu 100 Prozent. Als ich dann die Implementierung einiger Unit-Tests anschaute, stellte ich fest, dass dort zwar einiges passierte, aber am Ende immer die Programmzeile auftauchte: "XXX.assertTrue(true)". Das heißt, die Tests überprüften gar nichts. Und sie liefen immer erfolgreich durch (true). Dem Team war ganz eindeutig nicht klar, weshalb die QS diese Daten sammelte – bzw. das Team erstellte diese Unit-Tests nur für die QS.

Transparenz benötigt Vertrauen

Abb.1: Burndown-Graph. © Jutta Eckstein
Abb.1: Burndown-Graph. © Jutta Eckstein

Weiterhin muss immer deutlich gemacht werden, was mit den Zahlen geschieht. Das ist vor allem dann wichtig, wenn die Transparenz, die durch jede Messung entsteht, plötzlich als Kontrollinstrument missbraucht wird. Auch das konnte ich bei einem Kunden beobachten:

Ein großer Konzern hat bei einigen seiner Projekte agile Entwicklung eingeführt. Diese Teams führten die "üblichen" Messungen durch. Dazu gehörte auch der sogenannte Burndown-Graph (s. Abb.1). In diesem wird zu Beginn einer bspw. zweiwöchigen Iteration aufgezeigt, wie viel sich ein Team für die zwei Wochen vorgenommen hat und nach jedem Tag wird aufgetragen, wie viel das Team jetzt noch – d. h. nach einem Tag Arbeit – bis zum Ende der Iteration zu tun hat. Dies kann auf verschiedene Arten erfolgen, eine Möglichkeit ist, zu Beginn alle Aufgaben zu zählen, die das Team fertigstellen muss. D. h. das Team hat sich z. B. 100 Aufgaben für die zwei Wochen vorgenommen. Nachdem ein Tag um ist, sind es vielleicht nur noch 90 Aufgaben. Dadurch ergibt sich ein Graph, der abwärts verläuft (daher der Begriff Burndown) und hoffentlich am Iterationsende, wenn alle Aufgaben erledigt sind, bei Null steht. Diese Messung, sowie diverse andere, wurden in diesem Konzern über einen großen Monitor transparent gemacht. Und zwar nicht nur bei dem entsprechenden Team, sondern konzernweit. Auf den ersten Blick schien dies offene Kommunikation und große Transparenz zu bedeuten. Als ich aber mit einem der betroffenen Teams sprach, wurde gleich erkennbar, dass das von dem Team nicht als hilfreich erachtet wurde. Denn sobald die Kurve nicht wie geplant verlief, stand "irgendein" Manager bei dem Team und fragte, was denn hier los sei. D. h. diese Transparenz wurde als Kontrolle und auch als Druckmittel eingesetzt. Dazu muss noch gesagt werden, dass speziell der Burndown-Graph als teaminternes Mittel gilt, damit das Team nachverfolgen kann, ob es das zugesagte Ziel am Iterationsende erreicht bzw. was es evtentuell verändern muss, um dieses zu erreichen. D. h. diese Messung ist vom Ursprungsgedanken her nicht als externes Reporting gedacht.

Zusammengefasst sollte für jede Messung folgendes sichergestellt werden:

  • Sowohl das Ziel als auch der Zweck der Messung sollte deutlich werden.
  • Die von der Messung betroffenen Personen sollten selbst die Messkriterien definieren.
  • Die Messung muss auf Vertrauen und nicht auf Kontrolle basieren.
  • Jeder, der in die Messung involviert ist, muss verstehen, was mit den Zahlen geschieht.

Metriken

Abb.2: Story-Board. © Jutta Eckstein
Abb.2: Story-Board. © Jutta Eckstein

Nun stellt sich die Frage, was denn genau gemessen werden soll, um die Produktivität zu erfassen. Der Burndown-Graph ist, da er wie oben angeführt eine team-interne Metrik ist, nicht dazu geeignet. Die Teamgeschwindigkeit ist auch nicht wirklich aussagekräftig, da es sich hierbei nicht um eine Produktivitätsmessung handelt, sondern um eine Kapazitätsmessung, die dann zur weiteren Planung hergenommen wird. Hilfreicher für die Produktivitätsmessung ist das Messen der durchschnittlichen Durchlaufzeit auf Basis der Wertschöpfung. Dafür muss erst einmal für jede Story vorab auch der Wert definiert werden, den man sich von ihr verspricht. Und dann wird gemessen, wie lange es dauert, von dem Zeitpunkt, an welchem diese Wertschöpfung eingeplant wurde, bis zu dem Zeitpunkt, zu dem der Wert dann tatsächlich an den Kunden geliefert wurde. In agilen Teams wird das oft durch ein Story-Board (s. Abb.2) deutlich, an welchem die Zustände von Eingeplant über in Arbeit und zur Verifizierung bis zu Fertig (engl. Todo, in Progress, to Review, Done) dargestellt werden und die Stories und Aufgaben entsprechend ihres Zustands eingeordnet werden.

Um einen Trend ausmachen zu können, wird dafür meist der Durchschnittswert ermittelt, welcher den über verschiedene Zeiträume bspw. verschiedene Release-Zyklen verglichen wird. Mit dem Fokus auf den erstellten Wert bleibt der Markt im Blick. D. h. es geht nicht darum, so viele Stories wie möglich fertig zu stellen, was gleichbedeutend ist mit der Lieferung von "irgendetwas". Im englischen betont man den Fokus auf den Wert durch "Outcome versus Output" – ein findiger Kollege bezeichnete das im deutschen treffend mit "Erlebnis versus Ergebnis", vereinfacht wird das auch über das Idiom "Qualität über Quantität" dargestellt. Das heißt, es geht nicht darum, so viel wie möglich fertig zu stellen, sondern tatsächlich für uns und den Kunden einen Wert zu erschaffen. Am besten verifiziert man das noch zusätzlich dadurch, dass man Tests erstellt, die Daten darüber liefern, welche Funktionalitäten vom Kunden tatsächlich verwendet werden. Damit kann auch die Hypothese über die Wertschöpfung verifiziert werden.

Nur was geliefert ist, erzeugt keine Verzugskosten.

Misst man die Werterstellung von Anfang an, d. h. vom Zeitpunkt, an dem die Anforderung das Unternehmen erreicht, über die Zeit, bis sie in einem Projekt bei einem Team in einem Backlog landet und bis zur tatsächlichen Auslieferung, dann hat man meist schon die ersten Anhaltspunkte, wo die Zeit tatsächlich bleibt. Das heißt, damit wirft man einen ganzheitlichen Blick auf die Verzugskosten im Unternehmen und nicht nur in einem Entwicklungsteam.

Analyse der Verzugskosten

Meine Kollegin Johanna Rothman hat Verzugskosten treffenderweise folgendermaßen definiert: "Verzugskosten sind das Nachdenken über den Gewinn, den man nicht macht und die Kosten der andauernden Entwicklung." Damit liegen einige Ursprungsquellen für den Verzug bereits auf der Hand: Allen voran summieren sich all die Dinge zu Verzugskosten, an denen wir arbeiten, die wir aber nicht fertig stellen. Denn nur was geliefert ist, erzeugt keine Verzugskosten. Daraus folgt, dass man als allererstes sicherstellen sollte, so wenig wie möglich parallel anzufangen und stattdessen so viel wie möglich gemeinsam fertig zu stellen. Dazu gehört, dass ein Team besser an wenigen Stories gemeinsam arbeiten sollte, um diese dann auch tatsächlich zeitnah fertigzustellen, anstatt, dass zum Beispiel jeder Mitarbeiter an einer anderen Story arbeitet und sich dadurch die Fertigstellung aller Stories in die Länge zieht.

Multi-Projekte und Multi-Tasking

Abb.3: Multi-Projekte. © Jutta Eckstein
Abb.3: Multi-Projekte. © Jutta Eckstein

Das gleiche gilt auch für Projekte. Nämlich anstatt mittels Multi-Projekte parallel an vielen Projekten zu arbeiten, sollte man sich besser auf wenige fokussieren und diese schnell zu Ende bringen. Angenommen wir haben drei anstehende Projekte, die (um die Berechnung einfacher zu machen) alle einen Monat für die Fertigstellung brauchen. Arbeiten wir nun an allen Projekten gleichzeitig, so machen wir zum ersten Mal nach drei Monaten Gewinn. Arbeiten wir im Gegensatz dazu sequentiell an den Projekten, so erzielen wir bereits nach einem Monat einen Gewinn – nämlich nach der Fertigstellung des ersten Projekts. Entsprechend können wir den nächsten Gewinn nach Fertigstellung des zweiten Projekts nach zwei Monaten erwarten usw.

Das Problem an Multi-Projekten ist nicht nur der nicht gemachte Gewinn, sondern auch die Kosten der andauernden Entwicklung. Die Arbeit an mehreren Projekten erfordert auch vom einzelnen Mitarbeiter einen ständigen Wechsel der Konzentration auf unterschiedliche Aufgaben (engl. Task switching). Mehrere Untersuchungen haben gezeigt, dass durch solche Task-Switches schnell 30 Prozent der Produktivität verloren gehen.

Experten

Selbstverständlich braucht es in jedem Team Experten. Teilt man sich jedoch die Arbeit anhand der Expertise auf, kann nicht gemeinsam an einer Story gearbeitet werden. Das habe ich oben bereits erwähnt. Ich möchte hier den Effekt nochmals deutlich machen. Wird die Arbeit einzelnen Experten zugewiesen, so hat man den gleichen Effekt wie an der Supermarktkasse. Als Einkäufer muss ich mich vorab entscheiden, an welche Kasse ich mich anstelle. "Natürlich" stellt sich im Nachhinein heraus, dass ich mich ausgerechnet an der Kasse angestellt habe, an der es irgendein Problem gibt – es wurde vergessen, die Ware vorher zu wiegen, eine Verpackung ist aufgebrochen, irgendjemand findet das Kleingeld nicht, usw. Daraus folgt, dass es in meiner Schlange nicht voran geht und ich kann beobachten wie an den anderen Kassen Einkäufer, die sich lange nach mir zur Kasse begeben haben, längst den Laden verlassen. D. h. die eigentlich vorab priorisierte Abarbeitung – im Supermarkt ist das "first come, first serve"– wird hinfällig. Das gleiche gilt bei der Zuordnung der Arbeit an Experten. Angenommen wir haben zehn Stories, die alle priorisiert sind und von unterschiedlichen Experten abgearbeitet werden. Stellt sich nun heraus, dass bspw. der Experte, der die zweite Story bearbeitet, auf ein großes Problem gestoßen ist, so dass sich die Implementierung verzögert, wird automatisch die Priorisierung ignoriert. Denn die Experten, die an den Stories mit der Priorität drei, vier, fünf etc. arbeiten, machen diese einfach fertig, während die Story zwei – so wie andere Stories, die diesem Experten zugeordnet wurden – immer noch in der Schlange hängen. Das heißt, die Schlange des zweiten Experten wird immer länger, während niedriger priorisierte Stories fertig werden und bereits den "Laden" verlassen.

Man muss dafür sorgen, dass die Teammitglieder voneinander lernen, so dass sie sich gegenseitig unterstützen können.

Das heißt, die Zuordnung von Aufgaben an Experten sind Verzugskosten. Um diese zu vermeiden, muss man dafür sorgen, dass die Teammitglieder voneinander lernen, so dass sie sich gegenseitig unterstützen können. In meinen Projekten habe ich nicht den Anspruch, dass jedes Teammitglied alles kann – das ist auch aufgrund der hohen Komplexität üblicherweise utopisch – aber wir haben meist das Ziel, dass jedes Teammitglied sich mindestens in zwei-drei Themen auskennt. Das reicht bereits aus, um diese Verzugskosten zu minimieren.

Qualität

Natürlich wollen wir alle ein System von hoher Qualität liefern. Das fordert allein schon die Berufsehre. Das heißt, im Team wird darauf geachtet, dass man sich keine technische Schuld auflädt, man achtet vielleicht sogar die Prinzipien von Clean Code, programmiert die Stories so, dass sie zu 100 Prozent fehlertolerant sind und bedenkt für die zukünftige Flexibilität alle Eventualitäten bei der Implementierung. Das ist oft genau der richtige Weg. Aber eben nicht immer. Manchmal wird auf mehr Qualität geachtet, als der Kunde bereit ist zu bezahlen und es die eigene Strategie vorgibt. Man spricht dann von der sogenannten Goldrahmenerstellung.

Konsequenterweise muss man sich damit auseinandersetzen, welche Qualität überhaupt gefordert ist. Dazu stellt man am besten folgende Fragen:

  • Ist 100 prozentige Fehlerfreiheit gefordert bzw. notwendig?
  • Ist in dem Budget Clean Code eingepreist?
  • Bei der Abwägung zwischen Lieferung und Qualität – was ist in unserem Marktsegment wichtiger? Zum Beispiel ist es in einem neuen Markt üblicherweise wichtiger, erst einmal tatsächlich am Markt zu sein, während die Geschäftsstrategie für ein Produkt, das schon länger auf dem Markt ist, meist v. a. über Qualität Kunden be- und erhält.

Kurzum, man muss sich im Klaren darüber sein, für wie viel Qualität der Kunde/Markt bezahlen wird und auch, welche Rolle die Qualität in unserer Geschäftsstrategie spielt. Diese muss dann gegenüber einer schnelleren bzw. verzögerten Lieferung abgewogen werden. Es geht also darum, eine bewusste Entscheidung zu treffen. Dies geht am besten, wenn man sich bereits vorab Gedanken über das Investitionsvolumen für eine Story macht. D. h. oftmals ist die Schätzung der Entwicklung weniger wichtig, als die Schätzung des zu erwartenden Werts zusammen mit der Definition des maximalen Investitionsvolumens. Denn diese beiden Werte können sehr stark die Art der Entwicklung – v. a. hinsichtlich erzielter Qualität – beeinflussen.

Vorklärung

Eine gute Vorarbeit ist die halbe Miete. Manchmal. Immer wieder wird die Produktivität rein dadurch verzögert, dass überhaupt nur sehr verspätet gestartet wird. Zum Beispiel ist in Scrum der Sprint Zero recht verbreitet. In diesem Sprint werden alle möglichen Vorarbeiten gemacht, so dass man nach Abschluss dieses Sprints in der Lage ist, wirklich zu beginnen. Oftmals drückt der Sprint Zero aber auch das Zögern der Projektbeteiligten aus, Zusagen zur Entwicklung zu treffen. Denn selbst wenn es diverse Vorarbeiten gibt, können auch diese gemessen werden – so kann man beispielsweise die Zusage leisten, im ersten Sprint die Umgebung aufzusetzen und mit einem "Hello World", das auch mittels des Test-Frameworks überprüft wird, diese Umgebung zu verifizieren. Meist führt bereits die Benennung dieses Sprints mit "Sprint Zero" dazu, dass Ziele nicht ernst genommen werden.

Noch extremer erlebe ich das in Scrum mit der sogenannten "Definition of Ready" (DoR). Darunter versteht man, ob die Story so aufbereitet ist, dass das Team mit der Entwicklung beginnen kann. Das macht natürlich einerseits Sinn. Andererseits führt diese DoR meist dazu, dass Ping-Pong gespielt wird. Das heißt, der Product Owner möchte eine Story einplanen und "wirft" diese dem Team zu. Das Team sagt: "Die Story entspricht aber nicht der DoR" und wirft sie wieder zurück. Natürlich wird dadurch an der Story nicht gearbeitet, ergo: Die Lieferung verzögert sich. Nun sind Stories eigentlich dazu gedacht, dass man diese gemeinsam – d. h. das Team zusammen mit dem Product Owner – klärt. Durch die DoR stiehlt sich das Team aus der Verantwortung der gemeinsamen Klärung und sagt damit mehr oder weniger, dass das nicht sein Bier sei. Das widerspricht jedoch einerseits der agilen Entwicklung und andererseits – und das halte ich für wesentlich bedenklicher – verzögert es die Lieferung.

Wir haben keine Zeit, die Säge zu schärfen, wir müssen sägen.

Ich empfehle aus diesem Grund, wenn der Wunsch nach einem Sprint Zero und/oder nach einer DoR auftaucht, genau zu überprüfen, welches Problem man damit lösen möchte und ob dieser Wunsch nicht vielmehr ein Hinweis darauf ist, dass ein ganz anderes Problem vorliegt (z. B. dass wir die Klärung der Story gar nicht als gemeinsame Verantwortung sehen). Weiterhin würde ich kritisch hinterfragen, ob wir als Team nicht auch ohne diese Verzögerungstaktik arbeiten können.

Konstantes Arbeiten

Manchmal erfolgt der Verzug auch dadurch, dass wir im Team einfach immer konstant weiter arbeiten, ohne uns die Zeit zu nehmen, innezuhalten und zu überprüfen, was uns eigentlich aufhält. Ganz nach dem Sprichwort: "Wir haben keine Zeit die Säge zu schärfen, wir müssen sägen." Retrospektiven sind ein hervorragendes Mittel um herauszufinden, welche Verzugskosten in unserem konkreten Fall vorliegen. Vielleicht sind die Buildzeiten oder der Testdurchlauf zu lang, oder durch die manuellen Tests dauert es immer fürchterlich lange bis das System geliefert werden kann oder wir müssten eigentlich dringend ein Refactoring durchführen, um wieder schneller zu werden. Es gibt viele Stellen, die ein Team in einer Retrospektive selbst erkennen und dann als Konsequenz auch abstellen kann. Dazu reicht es aber nicht aus, diese Punkte nur zu benennen, sondern es muss auch ganz konkret und v. a. realistisch geplant werden, wie die Verzögerung abgestellt werden kann. Das bedeutet, dass Aufgaben so geplant werden müssen, wie auch "normale" Aufgaben, die sich aus der Entwicklung der Stories ergeben. Und natürlich müssen auch diese Aufgaben mit einer Art Test überprüft werden, um die erwünschte Änderung feststellen zu können.

Schlussbetrachtung

Für aufschlussreiche Produktivitätsmessungen muss zunächst geklärt werden, wer diese messen möchte, wozu und wie. Für letzteres empfiehlt sich der Fokus auf die Wertschöpfung. Idealerweise betrachtet man dafür die gesamte Wertschöpfungskette, d. h. von dem Zeitpunkt, an welchem die Anforderung zum ersten Mal aufgetaucht ist, bis zur Lieferung. Falls dies als Start zu schwierig erscheint, dann sollte man zumindest die Wertschöpfung von der Einplanung bis zur Lieferung betrachten (To-do bis Done). Dabei sollte nicht nur die Dauer der Erstellung im Fokus liegen, sondern vor allem auch welchen Wertzuwachs diese Implementierung darstellt.

Letztlich kommt es darauf an zu liefern.

Dann gilt es, die Verzugskosten zu analysieren und als Folge entsprechend zu beheben. Eine typische Quelle für den Verzug ist, zeitgleich an unterschiedlichen Dingen zu arbeiten (Stories, Projekte), anstatt sich gemeinsam auf eine Aufgabe nach der anderen zu konzentrieren und somit schneller liefern zu können. Auch die Zuordnung der Stories zu Experten kann eine Ursache für den Verzug sein, d. h. die Teammitarbeiter sollten – durch die Einarbeitung in andere technische Fachgebiete – in der Lage sein, gemeinsam an einer Story zu arbeiten. Auch der (übertriebene) Fokus auf Qualität, auf den sogenannten Goldrahmen, sorgt oftmals für eine Verzögerung. Deshalb sollte man sich immer im Klaren darüber sein, welche Qualität gefordert und auch bezahlt wird. Und manchmal liegt der Verzug auch darin begründet, dass erst gar nicht angefangen wird, das heißt man versteckt sich hinter einem Sprint Zero oder einer Definition of Ready. Deshalb sollte man bei dem Wunsch nach einem Sprint Zero oder einer Definition of Ready immer hellhörig werden und diese auf ihre tatsächliche Notwendigkeit überprüfen. Und schlussendlich gilt es, über Retrospektiven herauszufinden wo die projekt- und teamspezifischen Verzugskosten liegen und diese durch konkrete Aktionen abzustellen. Denn letztlich kommt es darauf an zu liefern, andernfalls kann das System nicht benutzt und auch kein Gewinn erzielt werden.

Diving For Hidden Treasures

Buchcoupon für Leser von Informatik Aktuell:

Johanna Rothman & Jutta Eckstein:

"Externer LinkDiving For Hidden Treasures – Finding The Real Value in Your Project Portfolio"

bis zum 15.04. erhältlich für 8,33 US$!

Literaturhinweise
  1. Frederick P. Brooks: The Mythical Man-Month: Essays on Software Engineering. Addison-Wesley anniv. Ed., 1995
  2. Donald G. Reinertsen: The Prinicples of Product Development Flow. Second Generation Lean Product Development, Celeritas Publishing, 2009
  3. Johanna Rothman, Jutta Eckstein: Diving for Hidden Treasures: Finding the Real Value in your Project Portfolio, Leanpub, 2015
  4. Johanna Rothman: Manage your Project Portfolio: Increase your Capacity and Finish more Projects, Pragmatic Bookshelf, 2012
nach Oben
Autorin

Jutta Eckstein

Jutta Eckstein arbeitet seit über zwanzig Jahren als Business-Coach, Change-Manager, Beraterin und Trainerin im In- und Ausland. Weltweit verfügt sie über eine einzigartige Erfahrung bei der erfolgreichen Umsetzung agiler Prozesse...
>> Weiterlesen
Bücher der Autorin:

YTo2OntzOjY6ImZldXNlciI7aTowO3M6MzoicGlkIjtpOjI1NDg7czozOiJjaWQiO3M6NToiMTU0MDEiO3M6NDoiY29uZiI7YTo4OntzOjEwOiJzdG9yYWdlUGlkIjtpOjgyMjtzOjEzOiJVc2VySW1hZ2VTaXplIjtpOjE4O3M6OToiYWR2YW5jZWQuIjthOjI6e3M6MTA6ImRhdGVGb3JtYXQiO3M6OToiZC1tLXkgSDppIjtzOjIxOiJzaG93Q291bnRDb21tZW50Vmlld3MiO2k6MDt9czo4OiJzaGFyaW5nLiI7YToxOntzOjEyOiJ1c2VTaGFyZUljb24iO047fXM6ODoicmF0aW5ncy4iO2E6Mjp7czoxNjoicmF0aW5nSW1hZ2VXaWR0aCI7aToxMTtzOjE2OiJyZXZpZXdJbWFnZVdpZHRoIjtpOjE2O31zOjY6InRoZW1lLiI7YToxMjp7czoyNjoiYm94bW9kZWxUZXh0YXJlYUxpbmVIZWlnaHQiO2k6MjA7czoyNDoiYm94bW9kZWxUZXh0YXJlYU5ickxpbmVzIjtpOjE7czoxNToiYm94bW9kZWxTcGFjaW5nIjtpOjQ7czoxODoiYm94bW9kZWxMaW5lSGVpZ2h0IjtpOjI1O3M6MTg6ImJveG1vZGVsTGFiZWxXaWR0aCI7aToxMzQ7czoyNjoiYm94bW9kZWxMYWJlbElucHV0UHJlc2VydmUiO2k6MDtzOjIyOiJib3htb2RlbElucHV0RmllbGRTaXplIjtpOjM1O3M6MTc6InNoYXJlYm9yZGVyQ29sb3IyIjtzOjY6ImNkZGVlYyI7czoxNzoic2hhcmVib3JkZXJDb2xvcjEiO3M6NjoiYWRhZWFmIjtzOjExOiJib3JkZXJDb2xvciI7czo2OiJkOGQ4ZDgiO3M6MjE6InNoYXJlQ291bnRib3JkZXJDb2xvciI7czo2OiJlM2UzZTMiO3M6MjA6InNoYXJlQmFja2dyb3VuZENvbG9yIjtzOjY6ImZmZmZmZiI7fXM6MTQ6ImRhdGVGb3JtYXRNb2RlIjtzOjQ6ImRhdGUiO3M6MTI6IlJlcXVpcmVkTWFyayI7czoxOiIqIjt9czo0OiJsYW5nIjtzOjI6ImRlIjtzOjM6InJlZiI7czoxNjoidHRfY29udGVudF8xNTQwMSI7fQ%3D%3DYTo0OntzOjQ6ImNvbmYiO2E6MzM6e3M6MTc6InVzZVdlYnBhZ2VQcmV2aWV3IjtzOjE6IjAiO3M6MjI6InVzZVdlYnBhZ2VWaWRlb1ByZXZpZXciO3M6MToiMCI7czoyMDoid2VicGFnZVByZXZpZXdIZWlnaHQiO3M6MjoiNzAiO3M6MjA6Im1heENoYXJzUHJldmlld1RpdGxlIjtzOjI6IjcwIjtzOjMxOiJ3ZWJwYWdlUHJldmlld0Rlc2NyaXB0aW9uTGVuZ3RoIjtzOjM6IjE2MCI7czozODoid2VicGFnZVByZXZpZXdEZXNjcmlwdGlvbk1pbmltYWxMZW5ndGgiO3M6MjoiNjAiO3M6Mjc6IndlYnBhZ2VQcmV2aWV3Q2FjaGVUaW1lUGFnZSI7czozOiIxODAiO3M6MzM6IndlYnBhZ2VQcmV2aWV3Q2FjaGVUaW1lVGVtcEltYWdlcyI7czoyOiI2MCI7czozMDoid2VicGFnZVByZXZpZXdDYWNoZUNsZWFyTWFudWFsIjtzOjE6IjAiO3M6Mjg6IndlYnBhZ2VQcmV2aWV3TnVtYmVyT2ZJbWFnZXMiO3M6MjoiMTAiO3M6Mzg6IndlYnBhZ2VQcmV2aWV3U2Nhbk1pbmltYWxJbWFnZUZpbGVTaXplIjtzOjQ6IjE1MDAiO3M6MzA6IndlYnBhZ2VQcmV2aWV3U2Nhbk1pbkltYWdlU2l6ZSI7czoyOiI0MCI7czozMDoid2VicGFnZVByZXZpZXdTY2FuTWF4SW1hZ2VTaXplIjtzOjM6IjQ1MCI7czoyOToid2VicGFnZVByZXZpZXdTY2FuTWluTG9nb1NpemUiO3M6MjoiMzAiO3M6MzE6IndlYnBhZ2VQcmV2aWV3U2Nhbk1heEltYWdlU2NhbnMiO3M6MjoiNDAiO3M6Mzg6IndlYnBhZ2VQcmV2aWV3U2Nhbk1heEltYWdlU2NhbnNGb3JMb2dvIjtzOjI6IjU1IjtzOjQwOiJ3ZWJwYWdlUHJldmlld1NjYW5NYXhIb3J6aXpvbnRhbFJlbGF0aW9uIjtzOjE6IjUiO3M6Mzc6IndlYnBhZ2VQcmV2aWV3U2Nhbm1heHZlcnRpY2FscmVsYXRpb24iO3M6MToiMyI7czozMDoid2VicGFnZVByZXZpZXdTY2FuTG9nb1BhdHRlcm5zIjtzOjEwOiJsb2dvLGNyZ2h0IjtzOjM4OiJ3ZWJwYWdlUHJldmlld1NjYW5FeGNsdWRlSW1hZ2VQYXR0ZXJucyI7czo1NzoicGl4ZWx0cmFucyxzcGFjZXIseW91dHViZSxyY2xvZ29zLHdoaXRlLHRyYW5zcGEsYmdfdGVhc2VyIjtzOjM4OiJ3ZWJwYWdlUHJldmlld0Rlc2NyaXB0aW9uUG9ydGlvbkxlbmd0aCI7czoyOiI0MCI7czoyNToid2VicGFnZVByZXZpZXdDdXJsVGltZW91dCI7czo0OiI3MDAwIjtzOjEyOiJ1c2VQaWNVcGxvYWQiO3M6MToiMCI7czoxMjoidXNlUGRmVXBsb2FkIjtzOjE6IjAiO3M6MTM6InBpY1VwbG9hZERpbXMiO3M6MzoiMTAwIjtzOjE2OiJwaWNVcGxvYWRNYXhEaW1YIjtzOjM6IjgwMCI7czoxNjoicGljVXBsb2FkTWF4RGltWSI7czozOiI5MDAiO3M6MjI6InBpY1VwbG9hZE1heERpbVdlYnBhZ2UiO3M6MzoiNDcwIjtzOjIzOiJwaWNVcGxvYWRNYXhEaW1ZV2VicGFnZSI7czozOiIzMDAiO3M6MjA6InBpY1VwbG9hZE1heGZpbGVzaXplIjtzOjQ6IjI1MDAiO3M6MjA6InBkZlVwbG9hZE1heGZpbGVzaXplIjtzOjQ6IjMwMDAiO3M6MjA6InVzZVRvcFdlYnBhZ2VQcmV2aWV3IjtzOjA6IiI7czoyNDoidG9wV2VicGFnZVByZXZpZXdQaWN0dXJlIjtpOjA7fXM6MTE6ImF3YWl0Z29vZ2xlIjtzOjI4OiJXYXJ0ZSBhdWYgQW50d29ydCB2b24gR29vZ2xlIjtzOjg6InR4dGltYWdlIjtzOjEzOiJCaWxkIGdlZnVuZGVuIjtzOjk6InR4dGltYWdlcyI7czoxNToiQmlsZGVyIGdlZnVuZGVuIjt9YTowOnt9YTowOnt9YTo3OntzOjE2OiJjb21tZW50TGlzdEluZGV4IjthOjE6e3M6MTk6ImNpZHR0X2NvbnRlbnRfMTU0MDEiO2E6MTp7czoxMDoic3RhcnRJbmRleCI7aTo1O319czoxNDoiY29tbWVudHNQYWdlSWQiO2k6MjU0ODtzOjE2OiJjb21tZW50TGlzdENvdW50IjtzOjU6IjE1NDAxIjtzOjEyOiJhY3RpdmVsYW5naWQiO2k6MDtzOjE3OiJjb21tZW50TGlzdFJlY29yZCI7czoxNjoidHRfY29udGVudF8xNTQwMSI7czoxMjoiZmluZGFuY2hvcm9rIjtzOjE6IjAiO3M6MTI6Im5ld2NvbW1lbnRpZCI7Tjt9 YTo1OntzOjExOiJleHRlcm5hbFVpZCI7aToyNTQ4O3M6MTI6InNob3dVaWRQYXJhbSI7czowOiIiO3M6MTY6ImZvcmVpZ25UYWJsZU5hbWUiO3M6NToicGFnZXMiO3M6NToid2hlcmUiO3M6MTYzOiJhcHByb3ZlZD0xIEFORCBwaWQ9ODIyIEFORCB0eF90b2N0b2NfY29tbWVudHNfY29tbWVudHMuZGVsZXRlZD0wIEFORCB0eF90b2N0b2NfY29tbWVudHNfY29tbWVudHMuaGlkZGVuPTAgQU5EIChleHRlcm5hbF9yZWZfdWlkPSJ0dF9jb250ZW50XzE1NDAxIikgQU5EIHBhcmVudHVpZD0wIjtzOjEwOiJ3aGVyZV9kcGNrIjtzOjkwOiJwaWQ9ODIyIEFORCB0eF90b2N0b2NfY29tbWVudHNfY29tbWVudHMuZGVsZXRlZD0wIEFORCB0eF90b2N0b2NfY29tbWVudHNfY29tbWVudHMuaGlkZGVuPTAiO30%3D YToyOntpOjA7czoxNDk6IjxpbWcgc3JjPSIvdHlwbzNjb25mL2V4dC90b2N0b2NfY29tbWVudHMvcmVzL2Nzcy90aGVtZXMvdGlzcXVzL2ltZy9wcm9maWxlLnBuZyIgY2xhc3M9InR4LXRjLXVzZXJwaWMgdHgtdGMtdWltZ3NpemUiIHRpdGxlPSIiICBpZD0idHgtdGMtY3RzLWltZy0iIC8%2BIjtpOjk5OTk5O3M6MTUxOiI8aW1nIHNyYz0iL3R5cG8zY29uZi9leHQvdG9jdG9jX2NvbW1lbnRzL3Jlcy9jc3MvdGhlbWVzL3Rpc3F1cy9pbWcvcHJvZmlsZWYucG5nIiBjbGFzcz0idHgtdGMtdXNlcnBpY2YgdHgtdGMtdWltZ3NpemUiIHRpdGxlPSIiICBpZD0idHgtdGMtY3RzLWltZy0iIC8%2BIjt9
Bitte bestätigen Sie
Nein
Ja
Information
Ok

Noch keine Kommentare vorhanden

Ihr Kommentar ist eine Antwort auf den folgenden Kommentar
Vorschau wird geladen ...
*: Pflichtfeld