3 Abbruch des Lernprozesses durch Offshoring

Was passiert nun bei der Offshore-Entwicklung? Der Lernprozess wird unterbrochen, erarbeitetes implizites Wissen geht unweigerlich verloren. Das ist immer der Fall, wenn Analyse, Design und Implementierung in getrennten Teams stattfindet. Lernprozesse müssen nachgeholt werden. Dazu ist viel Kommunikation erforderlich. Fehlentscheidungen des Teams der vorhergehenden Phase können nur mit viel Aufwand oder gar nicht korrigiert werden – wenn sie denn überhaupt erkannt und anerkannt werden. Dadurch entstehen Brüche im Entwurf, die innere Konsistenz geht verloren, die Theorie wird nicht durchgehalten. Auf konkreterer Ebene wird versucht, mit umständlichen Korrekturen und Workarounds doch noch irgendwie die gewünschten Ergebnisse zu erzielen. Die Offshore-Entwicklung erzwingt einen sehr harter Schnitt zwischen den Teams. Im Vergleich zur direkten Kommunikation in und zwischen Teams an einem Ort bleibt die technisch vermittelte Kommunikation über Kontinente hinweg sehr beschränkt. Die hierarchische Beziehung zwischen Auftraggeber und Auftragnehmer reduziert die Kommunikation noch weiter.

Wie in Bild 3 dargestellt zieht Trumpf die Trennlinie zwischen lokaler und entfernter selp bild3Entwicklung auf einem hohen Abstraktionsniveau und überlässt den indischen Entwickler/innen den größten Teil der Entwurfstätigkeiten. Die Inder/innen müssen sich vergleichsweise wenig Wissen von der Firma Trumpf aneignen und kennen selbst das Fachgebiet. Mit wenigen Rückfragen lassen sich offene Fragen klären.

Ganz anders bei Schoppe & Faeser. Da erfolgt der Schnitt auf sehr niedrigem Abstraktionsniveau, die Entwürfe sind schon sehr konkret. Der Großteil des Lernprozesses fand in Deutschland statt. Der Informations- und Wissensverlust ist enorm, obwohl die Programmiervorgaben in Struktogrammen übergeben wurden. Struktogramme sind genauso wie andere grafische Darstellungen unvollständig – andernfalls wären sie eine Programmiersprache. Die indischen „Technokulis“ hatten kaum eine Chance, Fehlentscheidungen auf abstrakter Ebene zu korrigieren. Der Kunde will es ja so haben, wie er es aufgeschrieben hat. Die indischen Entwickler/innen mussten oft Adhoc-Entscheidungen und Annahmen treffen, da die immer auftretenden, kleinen, scheinbar unbedeutenden Unklarheiten aufwändige Rückfragen nicht rechtfertigten. Sie hatten keine Chance, gute Software zu bauen.

weiter

Kommentar verfassen

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden / Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden / Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden / Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden / Ändern )

Verbinde mit %s


%d Bloggern gefällt das: