Woran Software-Entwicklung im Nearshoring scheitert

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.