Markus Dubach - DIE ENTSCHEIDUNG - BEGEGNUNG MIT EINEM KANNIBALEN

Auf den ersten Blick hat man den Eindruck, das sei ein einfaches Projekt, und so wird es auch von allen Beteiligten außer mir eingeschätzt. Der Kunde wünscht eine Bereitstellung des Systems bis Ende Januar 2008. Ich habe also gut vier Monate Zeit. »Ich finde die Zeit knapp bemessen«, sage ich zu Powischer, dem Projektleiter, beim Verlassen des BFS. »Ach was, diese paar Daten zu laden ist doch keine Sache. Du bist eine Heulsuse!« Ich erwidere, dass ich aufgrund meiner langjährigen Erfahrung gerade auf diesem Gebiet sehr wohl den Aufwand richtig einschätzen kann. »Und dann ist da noch die Datenschutzproblematik. Ich würde das nicht unterschätzen«, gebe ich zu bedenken. Leider stoße ich auf taube Ohren.

Mit einem unguten Gefühl mache ich mich an die Arbeit. Leider bin ich dabei in den ersten Wochen sehr eingeschränkt. Ich erhalte erst gegen Ende Oktober einen einsatzfähigen Entwicklerarbeitsplatz. Die Grobspezifikation, die ich von Powischer (Name geändert) erhalte, lässt viele wichtige Fragen offen. Insbesondere die Integration in eine noch zu etablierende generische Architektur [3]löst bei mir Stirnrunzeln aus. Es ist nämlich geplant, die vielen Einzelapplikationen im BFS durch eine serviceorientierte Architektur [3]zu ersetzen. Man muss sich das so vorstellen, dass jeder Leistungsbezieher des BFS zukünftig in erster Linie Bausteine aus dieser Architektur in seine Applikationslandschaft integrieren wird und nur dann Teile einkauft oder selber entwickelt, wenn sie nicht von der Architektur bereitgestellt werden. Durch Zusammenfassen der IT-gestützten Prozesse in einer zentralen, unternehmensweiten Architektur, die in Form von Services den Abteilungen zur Verfügung gestellt werden, können Mehrspurigkeiten beseitigt und damit Kosten gespart werden. Schätzungen gehen davon aus, dass bis zu 80 Prozent der benötigten Leistungen in diese Architektur integriert werden könnten. Es handelt sich dabei um ein Großprojekt im zweistelligen Millionenbereich. [4]Eine Pilotphase mit ausgewählten Applikationen ist für den kommenden Frühling geplant. Eigentlich eine gute Sache, deshalb unterstütze ich das Vorhaben. Sorgen bereitet mir allerdings die fehlende Koordination in der Zeitplanung der beiden Projekte. Einerseits soll ich mein Projekt Ende Januar 2008 abschließen, andererseits werden ausgewählte Komponenten der generischen Architektur erst im März 2008 verfügbar sein. Wie soll das gehen? Auch fällt mir auf, dass die generische Architektur unsere Bedürfnisse nur mangelhaft abdeckt. Und nicht zuletzt fehlen mir funktionsfähige Prototypen, mit denen ich Erfahrungen sammeln könnte. Rückfragen beim Projektleiter und bei Mitarbeitern führen schließlich zu noch mehr Irritationen. »Ach, Castem soll in unsere Architektur integriert werden? Davon wissen wir nichts.« Das stehe so in der Spezifikation, entgegne ich.

Leider sind das nicht die einzigen Probleme. In zahlreichen Gesprächen mit den für das Register Verantwortlichen des BFS können viele meiner Fragen nicht beantwortet werden. Vieles bleibt diffus. Frage ich nach der Klärung offener Punkte, werde ich immer wieder auf später vertröstet. Und dann kommen noch Fragen zur Umsetzung: Mit welchen Tools sollen denn die Prozesse implementiert werden? Egal, wen ich von den technischen Leuten frage, ich bekomme von jedem eine andere Antwort. Ich werde auch hier alleine gelassen. Mit der Zeit ergeben sich Probleme bei der Berichterstattung. Da ich mit dem Projekt nicht vorwärtskomme, muss ich einen erheblichen Teil meiner Arbeitszeit unter der Kostenstelle Administration verbuchen. Das führt zu Konflikten mit der Buchhaltung. Ich solle nicht so viel Arbeitszeit auf die Administration verbuchen, herrscht mich die Sekretärin an.

Neben den technischen und konzeptionellen Mängeln fallen mir Unklarheiten in den Zuständigkeiten im Projekt auf. Wer ist für welche Resultate verantwortlich? Muss ich das technische Konzept schreiben? Ich dachte, dafür hätten wir Architekten? Ich bin als Datenbankspezialist angestellt worden und es kann nicht sein, dass ich grundsätzliche Entscheidungen treffen muss, ich habe schließlich keine Führungsfunktion.

Trotz unklarer Verantwortlichkeiten, unvollständiger Spezifikation, einer generischen Architektur (die nicht zur Verfügung steht, an der ich mich aber orientieren soll) und nicht zuletzt dem Einsatz von Technologien, bei denen mir die Erfahrung fehlt, versuche ich mich im Projekt vorzuarbeiten. Mir ist klar, dass ich irgendwann Nägel mit Köpfen machen muss. Ich schiebe das aber vor mir her und warte das Ende der Probezeit ab. Erst die definitive Anstellung wird mir die nötige Sicherheit geben, um die unvermeidlichen und dringenden Entscheidungen zu treffen.

Am Ende der Probezeit habe ich ein Gespräch mit dem Vorgesetzten Kackebart, in dem er mir mitteilt, dass einer definitiven Anstellung nichts mehr im Wege stehe. Ich erhalte bestes Feedback. Kackebart teilt mir mit, er habe mit Projektleiter Powischer gesprochen und von diesem eine sehr gute Rückmeldung erhalten. Das wusste ich bereits, da mir Powischer sein Feedbackformular ausgehändigt hat. In diesem werde ich in den höchsten Tönen gelobt: Herr Dubach hat sich sehr schnell eingearbeitet … Die Zusammenarbeit mit Herrn Dubach ist stets konstruktiv steht da geschrieben. [5]Auch die Sicherheitsüberprüfung fällt positiv aus, es bestehen keine Vorstrafen oder andere sicherheitsrelevante Gründe, die gegen eine Anstellung sprechen. [6]Und schließlich gibt auch der Medical Service grünes Licht: [7]Es bestünde zur Zeit keine Einschränkung der Arbeitsfähigkeit. Langfristig sei das Risiko leicht erhöht, das spreche aber nicht gegen eine Ausübung der aktuellen Tätigkeit.

Ich erwähne im Gespräch mit Kackebart nichts von den Ungereimtheiten, die mir aufgefallen sind. Das wird mir später schwer angelastet werden. Aber wer traut sich schon, während der Probezeit schwere Mängel anzuprangern?

Nach Abschluss der Probezeit beginne ich unverzüglich mit den dringendsten Maßnahmen. Ich weiß zwar, dass ich als Spezialist ohne Führungsfunktion eingestellt wurde, aber ich kann nicht mehr weiter zusehen, wie das Projekt führungslos dahinschlittert. Da der Projektleiter offensichtlich überfordert ist und auch die Führung in der Linie nicht klappt, nehme ich das Zepter in die Hand.

Die erste und wichtigste Entscheidung, die ich fälle, ist die Trennung von Castem und der generischen Softwarearchitektur ( G-SOA ). Eine für Castem lebensrettende Maßnahme, wie sich später herausstellen wird. Ich habe während mehrerer Monate erfolglos versucht, Bausteine der generischen Architektur zu integrieren; entweder waren sie nicht verfügbar, machten nicht, was sie sollten, oder sie funktionierten überhaupt nicht. Das ist ein unhaltbarer Zustand. Meine Entscheidung wird von den Verantwortlichen des BFS mit großer Erleichterung aufgenommen. Mir fiel in den Monaten zuvor nämlich auf, dass die Herren jedes Mal die Nase rümpften, wenn das Projekt G-SOA zur Sprache kam. Ich erfahre erst jetzt, warum das so ist: Das Projekt sei für das BFS eine Bürde und verursache eine große Unzufriedenheit bei den Betroffenen. Vieles funktioniere überhaupt nicht oder wenn, dann nur mit großem Aufwand. Bei aller Freude über meine Entscheidung muss ich darauf hinweisen, dass wir in den vergangenen Monaten zum Teil für den Papierkorb gearbeitet haben und die Komponenten, die wir von G-SOA nutzen wollten, nun selber entwickeln müssen. Das wird Folgen für die Zeitplanung und Kosten haben.

Die zweite wichtige Maßnahme ist die Fertigstellung der dringend benötigten Spezifikation. Weil sie lückenhaft ist, konnte ich vieles nicht realisieren oder ich musste auf Annahmen abstellen. Ich organisiere ein Treffen mit einem Statistiker beim BFS, einem Doktor der Mathematik, mit dem ich die Materie vertieft analysiere. Ich habe das erste Mal das Gefühl, dass ich mich mit einem fachlich kompetenten Ansprechpartner unterhalte.