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.
Foto: vege, Fotolia.com
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.
Wichtig: Projekte einschließlich Benutzersicht verstehen
Wenn Auftraggeber Schwierigkeiten allein auf die mangelnde Kompetenz der Auftragnehmer schieben und mit rein technischen Schulungen zu beheben versuchen, ignorieren sie das vorhandene Bedürfnis, das Projekt bis hin zur Benutzersicht zu verstehen. Hier wird vergessen, den Auftraggeber als gleichwertigen Partner zu sehen, dessen Vorbildung nicht unbedingt eine geringere sein muss.
Im Vergleich mit einer anderen Studie, die wir in Deutschland, den Niederlanden, Finnland und Belgien in ähnlich umfangreichen Projekten ohne Nearshoring oder Offshoring, aber mit Unterbeauftragung vorgenommen haben, wurden insbesondere folgende Unterschiede beobachtet:
Die Software-Architekten kommunizieren viel intensiver mit den Requirements Engineers, jedoch ebenfalls nicht mit den Endanwendern.
Trotzdem hatten sich die Architekten durch jahrelange Tätigkeit umfangreiches Domänenwissen angeeignet. Sie bezeichneten dies als unabdingbar, um fehlende oder unvollständige Anforderungen zu identifizieren.
ISO-Standards wurden hier gemeinsam bei Auftraggeber und Auftragnehmer verwendet und führten nicht nur zu einer Harmonisierung der Arbeitsprozesse, sondern auch der Spezifikationsvorlagen und verwendeten Terminologien.
In diesen Projekten waren die Architekten an der Entscheidung über Qualitätsanforderungen aktiv beteiligt, basierend auf ihrem technischen und ihrem Domänenwissen. Der Maßstab ihrer Entscheidungen war der Business Case des Projekts. Beim Aushandeln von Qualitätsniveaus verwendete daher der Architekt den Business Case, um die Auftraggeber zu überzeugen und ihre "Sprache zu sprechen".
Es scheint, dass in diesen Projekten innerhalb desselben mitteuropäischen Kulturkreises anders zusammengearbeitet wird als im Nearshoring (und vermutlich auch Offshoring): mehr auf Augenhöhe und infolgedessen mit besserer inhaltlicher Abstimmung.
Dagegen scheinen die unterschiedlichen Kulturkreise, die im Offshoring und Nearshoring oft als Hauptproblem angesehen werden, weniger Gewicht zu haben als bisher angenommen. Frühere Studien haben schon gezeigt, dass verschiedene Firmenkulturen viel relevanter sind. In einer Studie zeigten sich Differenzen umso eher, je mehr Firmen am Projekt beteiligt waren. Dagegen hatten die Teamgröße und die geographische Verteilung der Mitarbeiter einen nur geringen, statistisch nicht signifikanten Einfluss.
Passend dazu zeigte eine Fallstudie bei Microsoft, dass bei der Softwareentwicklung innerhalb einer Firma der Qualitätsunterschied des Codes bei der international verteilten Entwicklung kaum schlechter ist als bei der Entwicklung innerhalb derselben Niederlassung. Das lässt sich durch firmenweite Standards und gemeinsames Wissen erklären. In einer anderen Microsoft-Studie wurde ein negativer Effekt von organisationalen Unterschieden auf die Codequalität festgestellt. Dieser wiederum kann durch einen guten Software-Engineering-Prozess deutlich reduziert werden.
Bitte nicht "von oben herab"
Daraus folgt, dass man kulturelle Unterschiede bei der internationalen Softwareentwicklung nicht als unüberwindliche Barriere ansehen sollte und vor allem nicht als Begründung dafür, einem Offshoring-Partner von oben herab Bedingungen zu diktieren. Eine partnerschaftliche Zusammenarbeit auf Augenhöhe mit gemeinsam verwendeten Standards, dem Austausch von Wissen und gemeinsamen Entscheidungen ist möglich und führt zu besseren Projektergebnissen.
Das passt auch zu den Ergebnissen einer anderen Studie, die zeigte, dass Kommunikation in der verteilten Entwicklung viele auftretende Probleme zu lösen im Stande war. Das Fazit dieser Studie lautete: Kommunizieren Sie mit Ihrem Partner möglichst oft und direkt (Face-to-Face), in jedem Fall sofort, wenn eine Frage auftritt, und unterstützt durch formale Regeln, Werkzeuge und eine gemeinsame Terminologie. (hv)