Umfrage

Woran Software-Entwicklung im Nearshoring scheitert

05.09.2014
Von  und Maya Daneva
Dr. Andrea Herrmann ist freie Trainerin für Software Engineering, Buchautorin und Inhaberin von zwei Gastprofessuren.

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)