Umfrage

Woran Software-Entwicklung im Nearshoring scheitert

Eine Umfrage zeigt: Die Kommunikationsschnittstellen zwischen Auftraggeber und -nehmer werden oft falsch besetzt. Außerdem ist eine "Kommunikation auf Augenhöhe" in vielen Fällen nicht gegeben.

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.

Woran Software-Entwicklung im Nearshoring scheitert
Woran Software-Entwicklung im Nearshoring scheitert
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.