Unsere Meinung zu Nearshoring

13. April 2016
Axel Schlumberger

In letzter Zeit häufen sich bei uns die Anfragen von osteuropäischen Firmen, die an einer Zusammenarbeit mit uns interessiert sind. Sie locken mit günstigen Stundensätzen und großen Entwicklungszentren, versprechen sogar teilweise kostenlose „Kennernlern-Angebote“. Und es ist natürlich in der Tat verlockend, plötzlich nur noch ein Drittel oder gar Viertel des Stundensatzes eines in Deutschland ansässigen Entwicklers zu bezahlen und auf eine Fülle von technischen Qualifikationen zugreifen zu können.

Allerdings sollte man die Risiken von Nearshoring nicht unterschätzen. In der Softwareentwicklung ist nichts wichtiger als eine gute Kommunikation. Wenn die Kommunikation nicht eindeutig ist und wenn Anforderungen falsch interpretiert werden, kann das am Ende sehr teuer werden. Denn bei der Entwicklung in eine falsche Richtung muss der Quellcode meist in mehreren Architektur-Schichten angepasst werden. Das Datenmmodel, die Datenzugriffslogik, die Businesslogik und die Benutzerschnittstelle müssen umgebaut und getestet werden. Auch müssen ggf. Unit-Tests neu geschrieben werden. Bei Missverständnissen aufgrund von Sprach- und Kulturunterschieden entsteht schließlich oft auch ein hoher Moderationsaufwand.

Kommunikationsprobleme können so schließlich dazu führen, dass Nearshoring am Ende teurer wird als eine reine Entwicklung in Deutschland.

Bei der Kommunikation ist oft die Sprache schon ein großes Hindernis. Natürlich sprechen viele Entwickler in den osteuropäischen Gebieten auch Englisch. Aber dies sind längst nicht alle. Und längst nicht alle sprechen gutes Englisch. Doch selbst wenn eine gute Kommunikation auf Englisch möglich ist, werden bei der Softwareentwicklung häufig Fachbegriffe aus dem Fachbereich verwendet, die bei einer Übersetzung schnell zu Missverständnissen führen können. Dies ist vor allem dann der Fall, wenn die Fachbereichssprache des Kunden Deutsch ist.

Missverständnisse und Fachbegriffe

Schon einfache Begriffe wie z.B. „Bundesland“ oder „Kreis“ müssen auf Englisch mit „Federal State“ oder „County“ übersetzt werden. Man könnte „Kreis“ aber z.B. auch mit „District“ oder „Region“ übersetzen. Kürzt man „Federal State“ mit „State“ ab, kann es plötzlich mit dem Land verwechselt werden. „County“ kann bei falscher Aussprache als „Country“ verstanden werden.
Man kann sich vorstellen, wie schnell schon diese einfachen Begriffe durcheinander gebracht werden können, wenn man in einer fremden Sprache kommuniziert.

Schließlich gibt es aber auch Fachbegriffe für die es sehr schwierig wird, überhaupt ein passendes englisches Wort zu finden. Für Wörter wie „Spurrinnentiefe“, „Wiederbeschaffungszeitwert“ oder „Alterswertminderung“ werden sie weder bei leo.org, noch bei dict.cc eine Übersetzung finden.

Für einen osteuropäischen Entwickler oder Projektleiter wird es somit sehr viel schwieriger, sich in die Fachbereichs-Welt des Kunden hineinzudenken. Noch schlimmer wird es, wenn das Entwicklungsteam intern mit Tschechisch oder Polnisch kommuniziert und der Projektleiter dies wieder an den Kunden zurück übersetzen muss.

Reisekosten

Neben der Sprache darf man aber auch die Vor-Ort-Kommunikation nicht unterschätzen. Wenn es darum geht, Anforderungen zu Papier zu bringen ist es immer noch am besten, mit Papier und Bleistift oder Whiteboard im gleichen Raum zu sitzen und Skizzen zu machen. Hierfür ist die Kommunikation über Telefon oder Skype nur bedingt geeignet. Noch schlimmer sind Telefonkonferenzen, bei denen niemand so genau weiss, wer eigentlich gerade spricht oder sprechen sollte. Am Ende werden dann meist doch Meetings vor Ort gemacht, mit entsprechend hohem Reiseaufwand.

Kulturunterschiede

Sind die Anforderungen schließlich zu Papier gebracht, kann am Ende kein UML-Diagramm, kein Mockup-Screen und auch kein detailliertes Pflichtenheft die direkte Kommunikation ersetzen. Hierfür müssen Softwareentwickler die Fachwelt des Kunden verstehen wollen und immer wieder die richtigen Fragen stellen. Hier kommt die Mentalität und die Kultur ins Spiel. Viele Softwareprojekte, die beispielsweise nach Indien ausgelagert wurden, hatten oder haben immer noch damit zu kämpfen. In der indischen Mentalität möchte man eine Aufgabe möglichst nach vorgegebenen Schema abarbeiten. Auch hat man schnell die Angst, das Gesicht zu verlieren wenn man etwas nicht verstanden hat und fragt dann erst gar nicht nach.

Nearshoring hat den Vorteil, dass die Kulturunterschiede zwischen Deutschen und Polen, Tschechen oder Ungarn nicht so gross sind. Dennoch sollte man sie nicht unterschätzen. Der Moderationsaufwand, um unterschiedliche Ansichten und Arbeitsweisen in Einklang zu bringen kann am Ende höher sein, als anfangs vermutet. (siehe hierzu den Artikel aus der Computerwoche)

Fazit

Wir arbeiten aus obigen Gründen bisher nicht mit Nearshoring-Agenturen zusammen und raten auch unseren Kunden davon ab. Es macht aus unserer Sicht nur dann Sinn, wenn kleine Projekte umgesetzt werden, bei denen die Anforderungen schon klar und unmissverständlich zu Papier gebracht wurden und die Fachbereichssprache idealerweise schon Englisch ist. Dies kann z.B. bei der Entwicklung eines Android oder iPhone-App der Fall sein, bei der das Backend und das Web-Interface bereits umgesetzt und somit eine unmissverständliche Schnittstelle geschaffen wurde.