Woran Software-Entwicklung im Nearshoring scheitert

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.