Die westlichen Auftraggeber in Offshoring-Projekten berichten oft über Schwierigkeiten mit den Auftragnehmern in Übersee wie beispielsweise mangelndes Qualitätsbewusstsein oder die angebliche Unfähigkeit, Probleme klar zu kommunizieren. Die Auftragnehmer werden dabei oft nicht nach ihrer Meinung gefragt, obwohl doch bekannt sein sollte, dass alles zwei Seiten hat - insbesondere Konflikte. Inzwischen gab es eine Umfrage unter Nearshoring-Anbietern, deren Ergebnisse - insbesondere was die Kommunikation mit den Auftraggebern betrifft - wir hier zusammenfassen. Nearshoring bedeutet im Gegensatz zu Offshoring, dass die Dienstleister nicht in Übersee sitzen, sondern weniger weit entfernt, insbesondere in Osteuropa.

Die Umfrage

Der Schwerpunkt der Umfrage bestand darin, Software-Architekten nach ihrem Umgang mit Qualitätsanforderungen an Software zu befragen. Die Antworten verdeutlichen, wie die Kommunikationsschnittstelle zwischen Auftraggeber und Nearshore-Partner funktioniert. Insgesamt standen 16 Software-Architekten aus zehn Unternehmen in Bulgarien (4 Unternehmen, 9 Interviews), Rumänien (1/1), Polen (3/4) und Estland (2/2) Rede und Antwort. Sie berichteten über ihr jeweils aktuelles Projekt, wobei die Dauer zwischen acht und 18 Monaten lag und die Teams zehn bis 53 Mitglieder umfassten. Alle Befragten brachten mindestens vier Jahre Berufserfahrung mit und arbeiteten seit zwei und mehr Jahren bei ihrem aktuellen Arbeitgeber, dem Nearshore-Partner.

Rollenverteilung

Die übliche Rollenverteilung zwischen dem Auftraggeber und dem osteuropäischen Auftragnehmer sah jeweils einen Projektmanager auf beiden Seiten vor. Nur in zwei Fällen gab es auch beiderseitig einen Software-Architekten und Integrations-Tests. Ansonsten fand man folgende Rollen nur beim Auftraggeber:

• Portfolio-Management,

• Requirements Engineering (für die Business-Anforderungen),

• Abnahmetests durch Benutzer,

• First Level Support.

Und folgende Rollen gab es meist nur beim Auftragnehmer:

• Architektur-Entwurf,

• Programmierung,

• Debugging,

• Stress-Tests,

• Integrationstests,

• Second Level Support.

Software Architect meets Requirements Engineer

Während idealerweise Software-Architekt und Requirements Engineer direkt miteinander kommunizieren, verlief in den hier untersuchten Projekten meist eine Grenze zwischen beiden: Der Architekt gehörte zum Dienstleister und der Requirements Engineer zum Auftraggeber. Darum verlief in zehn der 16 Nearshoring-Projekte die Kommunikation bezüglich der Anforderungen über den Projektleiter. Das führte zu Informationsverlusten, Missverständnissen und Fehlern.

So wurde in der Regel über Anforderungen nicht diskutiert. Sie wurden als Vorgaben übergeben nach dem Motto: "Tu, was dir gesagt wird". Immerhin sechs befragte Architekten beim Nearshore-Partner hatten die Möglichkeit, beim Requirements Engineer des Auftraggebers bei Unklarheiten bezüglich der Anforderungen nachzufragen. In vier dieser sechs Fälle gab es einen ausdrücklichen Ansprechpartner für die Klärung von Anforderungen. Dabei erwiesen sich Glossare als nützlich, wurden aber oft erst auf Anfrage bereitgestellt.

Problem: Kein Wissen über Anwendungsdomäne

Die Software-Architekten erstellten nicht nur die Architektur, sondern programmierten auch. Das Erstellen des Architekturentwurfs galt nicht als Vollzeitjob. Zu Beginn ihrer Tätigkeit wurden die Architekten beim Auftraggeber mindestens zwei Monate lang geschult, um die beim Auftraggeber üblichen Entwicklungsprozesse, die verwendeten Standards und die Prinzipien kennen zu lernen.

Domänenwissen - das heißt das Wissen über die Anwendungsdomäne der Software - wurde jedoch nicht geschult. Die Nearshore-Partner erlernten es auch nicht durch die Kommunikation mit Benutzern, denn diese Schnittstelle lag im Zuständigkeitsbereich des Auftraggebers. Damit fühlten sich die Auftragnehmer sehr unglücklich, weil sie sich so die Benutzer und den Verwendungszweck der Software nicht immer klar vorstellen konnten.

Ihnen war durchaus bewusst, dass das Fehlen solchen Wissens zu suboptimalen Entscheidungen beim Software-Entwurf führen kann. Aber sie sahen keine Möglichkeit, sich dieses Domänenwissen selbst anzueignen. Ein Interviewpartner drückte das Problem so aus:

"I have a really hard time understanding mortgage securitization and all the rules that go with it. We have no such industry in our country, our people’s life is much simpler, and that’s why it’s extremely hard to relate to what the onshore friends are talking about. We meet no business users, we even do not know what vocabulary our onshore fellows are using when they are talking with clients on those things. I know nothing about how the client suggests non-functional requirements or what motivates certain levels of security features… And if I do not understand those requirements, how can I explain it to my team here?"

Oft behalfen sich die Architekten, denen der Ansprechpartner fehlte, damit, mögliche Anforderungen zu erraten - im vollen Bewusstsein darüber, wie gefährlich das war. Rückfragen und Diskussionen über die Anforderungen waren jedoch (laut Wahrnehmung der Auftragnehmer) oft nicht vorgesehen oder bekamen schnell den Geruch einer Rebellion, was unbedingt vermieden werden sollte.

Den Teilnehmer der Umfrage war sehr wohl bewusst, dass der Transfer von Domänenwissen vermutlich viel aufwendiger wäre als der von technischem Wissen (wobei ja auf das Wissen aus einem mehrjährigen Studium aufgebaut werden kann), und dass ein tiefgehendes Domänenverständnis erst durch mehrjährigen Kontakt zu den Endbenutzern entsteht.

Das Problem ist keineswegs Nearshore-typisch. In einer ähnlichen Umfrage von einer schweizerischen Firma wurde festgestellt, wie schwierig es sei, indischen Dienstleistern das Prinzip der Rentenversicherung zu erklären. Vieles, was bei einem mitteleuropäischen Entwickler als implizites Wissen vorausgesetzt werden kann, weil er vermutlich selbst eine Rentenversicherung abgeschlossen hat, muss für einen indischen Experten eindeutig und vollständig spezifiziert werden. Da das Prinzip der Rentenversicherung in diesem Land unbekannt zu sein scheint, kann man bei indischen Auftragnehmern kein Wissen darüber voraussetzen. Damit entstehen hohe und oft zunächst unerwartete Anforderungen an die Qualität der Anforderungsspezifikation.

Dokumentation von Qualitätsanforderungen

Aufgrund unterschiedlicher Arbeitsweisen und Firmenkulturen ergaben auch die Dokumentationsformen des Auftraggebers manchmal wenig Sinn für den Nearshore-Partner. Meist enthielten die Spezifikationen der Qualitätsanforderungen überflüssig viele Informationen. Die Osteuropäer verwendeten für die Beschreibung der Qualitätsanforderungen daher eigene vereinfachte Vorlagen, die nicht mit dem Auftraggeber abgestimmt wurden. So konnte beim Nearshore-Partner eine Spezifikation entstehen, die projektübergreifend konsistent ist und zu seiner Firmenkultur passt.

Entscheidungen über Anforderungen

Die Anforderungen und deren Prioritäten wurden den Nearshore-Partnern kommuniziert und dann erwartet, dass diese genauso umgesetzt würden. Da die Anforderungen aber nicht im Detail abgestimmt wurden, konnte die technische Erfahrung der Entwickler bei der Entscheidung über Anforderungen auch nicht einbezogen werden.

Eine gemeinsame Diskussion über Sinn und Unsinn von Anforderungen und Prioritäten fand meist erst dann statt, wenn massive Probleme auftraten, die beim Nearshore-Partner wirklich nicht gelöst werden konnten. Ansonsten wurde erwartet, dass alle Anforderungen diskussionslos umgesetzt werden. Das führte nicht immer zur optimalen Lösung.

Sich ihrer finanziellen Abhängigkeit als Auftragnehmer bewusst, trafen die osteuropäischen Dienstleister ihre Entscheidungen vor allem nach dem Kriterium, wie wahrscheinlich es ist, ein Projekt oder sogar den Auftraggeber zu verlieren. Auch das führte nicht immer zur technisch und fachlich optimalen Lösung.

Diskussion der Umfrageergebnisse

Stellt man die Ergebnisse dieser Umfrage denen gegenüber, die bei der Befragung von Auftraggebern entstanden, so ergibt sich ein vollständiges Bild. Wo die Auftraggeber mangelnde fachliche und technische Kompetenz vermuten oder eine kulturell bedingte Unfähigkeit zum Melden von Problemen und dem Austragen von Konflikten, mangelnde Arbeitsethik oder fehlendes Qualitätsbewusstsein, sieht die Sache aus Auftragnehmersicht anders aus. Man traut sich nicht, Korrekturen anzubringen oder Kritik zu üben, weil man sich der abhängigen Position als Auftragnehmer bewusst ist.

Schmettert der Auftraggeber Kritik ab, merkt sich der Nearshore-Partner, dass er tun soll, was ihm gesagt wird. Über Probleme zu reden, gehört offenbar nicht dazu. So versuchte ein Nearshore-Dienstleister mit allen Mitteln, das geforderte Qualitätsniveau zu erreichen, auch wenn das unmöglich war. Bis der Kunde es endlich selbst begriff.

Das Kommunikationsproblem an der Schnittstelle zwischen Architekt und Requirements Engineer war oft schon durch die Rollenverteilung vorprogrammiert, aber auch dadurch, dass der Auftraggeber die Anforderungen einseitig verbindlich festgelegt hatte, ohne den NSP zur technischen Machbarkeit zu befragen. So entstanden suboptimale Entscheidungen sowohl bezüglich der Anforderungen als auch der Architektur.

Hilfreich gewesen wäre es hier entweder eine Person ausdrücklich mit der beidseitigen Kommunikation über Anforderungen zu beauftragen - in einigen Fällen fand das ja auch statt - oder auf beiden Seiten einen Architekten oder einen Requirements Engineer einzusetzen. Die regelmäßige gemeinsame Diskussion über Anforderungen und deren Prioritäten führt zu besseren Entscheidungen und Ergebnissen, so dass sich die Kosten senken lassen.