Wer heute auf die Anfänge des Offshoring Mitte der 1980er Jahre zurückblickt, wundert sich, wie das überhaupt funktionieren konnte: Es gab kein Internet, Telefongespräche waren noch unglaublich teuer und von herzlich schlechter Qualität (Rauschen, Knistern); in nicht wenigen Fällen flog der indische IT Projektmanager für ein Vor-Ort-Gespräch beim Auftraggeber ein, die Programmspezifikation (in Englisch) wurde durchgesprochen, anschließend verstaute der IT Manager die Unterlagen im Koffer und flog zurück auf den Subkontinent. Mit Fertigstellung wurde die Software auf einem Datenträger in den Koffer gepackt und an den Auftraggeber ausgeliefert.
Im Vergleich dazu ist Offshoring heutzutage ein Kinderspiel: Umfangreiche Datenpakete können per Internet ausgetauscht werden, SSLVPN Tunnel erlauben eine Echtzeit-Verbindung von Offshore-Entwicklerteams zu Entwicklungsumgebungen beim europäischen Auftraggeber, der Austausch erfolgt per Videotelefonie, Webkonferenzen oder auch per Slack und andere Instant-Messaging-Dienste. Ganz zu schweigen davon, dass Flüge für Vor-Ort-Workshops signifikant günstiger geworden sind. Dennoch bleibt die effiziente Kommunikation mit Offshore IT Teams eine Herausforderung.
Die unterschiedlichen Zeitzonen sind hierbei meiner Erfahrung nach allerdings völlig unkritisch; während der Sommerzeit beträgt der Unterschied in den Zeitzonen 3,5 Stunden (während der Winterzeit: 4,5 Stunden). Hier verbleibt eine ausreichende Schnittmenge an gemeinsamer Arbeitszeit für die erforderlichen Statusmeetings und Abstimmungsprozesse.
Was mehr Bauchschmerzen bereitet, ist der indische Dialekt, der zu Beginn eines Projektes eine zähe Kommunikation verursacht: „Sorry, I didn’t quite get that. Could you please repeat that?“. Die Erfahrung lehrt allerdings, dass man sich an den Dialekt innerhalb von zwei (2) Wochen gewöhnt hat. Und wer einen Schritt weitergehen möchte, der kann die zentralen Ansprechpartner im IT Offshore Team in akzentfreiem Englisch schulen lassen; die IT Industrie hat auf dieses Thema schon längst reagiert, ich kenne IT Professionals, die sprechen ein geradezu unglaubliches britisch-näselndes Oxford-Englisch. (Die Anforderung an ein akzentfreies Englisch war insbesondere zu den Hochzeiten der Call Center Ära von besonderer Relevanz; inzwischen hat sich die Call Center Industrie aber zu den Philippinen verlagert, die als ehemalige US Kolonie kulturell den US-amerikanischen Nutzern von Call-Center-Dienstleistungen näher sind).
Kommen wir zur Frage, wie man ein IT Offshore Team fachlich am besten steuert. Gleich vorweg: Der Black Box Ansatz funktioniert nicht. Man sollte nicht einfach ein Paket mit Anforderungen über den Zaun schmeißen (=per Email verschicken) und eine Delivery Deadline 3 Monate später setzen. In Zeiten von Agilem Projektmanagement ist ein solcher Ansatz eigentlich ohnehin obsolet geworden; ich habe in den letzten 5 Jahren auch nicht erlebt, dass solche Anfängerfehler gemacht werden. Aber ich möchte es der Vollständigkeit halber erwähnt haben.
Was sich bewährt hat: Zu Beginn eines Projektes empfiehlt es sich, einen persönlichen Kick-Off-Termin zu gestalten, in dem mindestens die zentralen Ansprechpartner (=IT Projektmanager) des Offshore Teams am Tisch sitzen. Zum einen erlaubt dies, sich über die Projektziele und den fachlichen Kontext detailliert auszutauschen und ein gemeinsames Verständnis sicherzustellen. Zum anderen ist die indische Kultur eine beziehungsorientierte Kultur; der persönliche Kontakt schafft Vertrauen, reduziert Fluktuation, schafft Commitment und führt zu einer lebendigen und offenen Kommunikationskultur, die entscheidend ist für den Projekterfolg: Offene Punkte müssen adressiert werden, dies gelingt nicht in einer verkrampften, überformalisierten oder unpersönlichen Kommunikationskultur.
Statusmeetings sollten wöchentlich stattfinden, erreichte Ziele und nächste Ziele werden in einem Protokoll festgehalten; darüber hinaus findet Kommunikation zur Klärung von operativen Details bei Bedarf statt, etwa über Webkonferenzen (GoToMeeting, TeamViewer, Skype) oder Instant-Messaging-Dienste (Slack, Mattermost). Im Umfeld von Agilen Projektmanagement Kulturen habe ich es auch erlebt, dass tägliche Scrum-Statusmeldungen vom Offshore-Team bereitgestellt werden: Was haben wir am Vortag erreicht, was steht für heute an, welche Hindernisse gibt es?
Grundsätzlich gilt, dass die IT Industrie in Indien einen hohen Reifegrad besitzt; Firmen wie IBM oder Cognizant haben in Indien mehr Mitarbeiter als im Mutterland USA. Die für die IT Industrie typischen Prozesse und Methoden sind am Offshore Standort Indien gelebte Praxis, das reicht von Scrum, ISTQB, PRINCE bis zu ISO 9001:2001. Die großen Player wie TCS (Tata Consultancy Services), Infosys, WIPRO, Tech Mahindra, Cap Gemini, Accenture und viele mehr haben je eigene Sets an Standards und Prozessvorlagen. In jedem Fall sollte ein Auftraggeber eigene (Coding) Standards, (Benamungs-)Konventionen und Anforderungen für die Testing-Dokumentation zu Beginn eines Projektes ganz klar kommunizieren. Insbesondere im Hinblick auf die Einhaltung von Coding Standards sollten bereits zu Beginn Entwicklungsergebnisse detailliert analysiert werden (Software Peer Review) und Feedback zeitnah an die Entwickler zurückgespielt werden.
Eigentlich ein no brainer, dennoch erwähnt: Offshore IT Teams sollten so eng wie möglich eingebunden werden, sowohl technisch (Versionsverwaltungssysteme wie Github, Softwaresysteme für kontinuierliche Entwicklung wie Jenkins) als auch kommunikativ (Feedback von Endnutzern, allgemeine Teamkommunikation). Infos zum Programm, zu den Anforderungen, zur Architektur, etc. sollten in einem TeamOrdner zugänglich sein. Gerade vor dem Hintergrund der beziehungsorientierten Kultur Indiens macht es Sinn, beispielsweise ein Board am Offshore Standort einzurichten, wo Fotos von allen (deutschen) Teammitgliedern angeheftet sind.
Abschließend sei noch auf eine besondere Variante der Zusammenarbeit mit IT Offshore Teams hingewiesen, nämlich das Offshore Management by Proxy. Hier sitzt ein zentraler Ansprechpartner (nicht: der IT Projektmanager, denn dieser sollte am Offshore Standort das Entwicklerteam leiten) dauerhaft am (deutschen) Standort des Auftraggebers und stellt die effiziente Kommunikation sicher. Diese Variante macht vor allem Sinn für größere Projekte sowie für Projekte, die agil entwickelt werden. Dieser zentrale Ansprechpartner kanalisiert Anforderungen des Auftraggebers, stellt die effiziente Kommunikation sicher, ist mit beiden Kulturen vertraut und senkt insbesondere die Kommunikationshürden für den Auftraggeber deutlich ab.
„Man muss einfach reden, aber kompliziert denken, nicht umgekehrt.“
Franz-Josef Strauss
