Infobest-Blog

Vor kurzem habe ich eine seltsame Diskussion in einem Webforum zum Thema IT-Outsourcing verfolgt. Ausgangspunkt für den illustren Diskurs war das Posting einer russischen IT-Firma, die ihre Offshore-Dienstleistungen für Programmierung auf dem deutschen Markt anbieten wollte. Woraufhin sich eine Reihe von IT-Experten mit Hang zum Intellektuellen zu Wort meldeten und den russischen Unternehmer mit teilweise unverhohlenem Sarkasmus in Grund und  Boden “argumentierten”. Es wurde ein bunter Reigen an Kritikpunkten aufgeführt:

• Derartige Preise machen den deutschen Markt kaputt
• Zu solchen Preisen kann niemand vernünftige Arbeit anbieten
• Offshore Dienstleistungen sind sowieso meistens von schlechterer Qualität
• Die meisten Offshore Projekte gehen in die Hose
• Man kann komplexe Entwicklungsprojekte nicht remote durchführen
• Es wird nur mit billigen Tagessätzen gelockt, dahinter stehen dann aber viel höhere Zeitaufwände, welche die günstigen Sätze kaputt machen

Hallo? Jemand zuhause?

Die Wirklichkeit scheint sich in derartigen Intellektuellenkreisen noch nicht herumgesprochen zu haben: Seit Jahren, beinahe Jahrzehnten, werden Milliarden $ durch Offshore/Nearshore/Outsourcing Dienstleistungen in der IT umgesetzt. Gerade große Konzerne greifen auf bekannte Beratungsunternehmen und IT-Dienstleister wie IBM, Accenture, EDS, CSC u.a. zurück, die dank ihrer schieren Größe weltweit tätig und vernetzt sind und über eigene Offshore-Zentren mit mehreren Tausend Mitarbeitern verfügen. Nicht selten werden für einzelne Projekte in der einen Ecke der Welt mehrere hundert Offshore-Mitarbeiter auf der anderen Seite der Erdkugel eingesetzt. Das ist alles längst Realität und Normalität, und vor diesem Hintergrund erschien mir die verbissen geführte Forumsdebatte wie ein mittelalterlicher Inquisitionsprozeß, bei dem es um die Verteidigung des kirlichen Lehrsatzes geht, daß die Erde eine Scheibe ist.

Man kann die ökonomischen, geopolitischen oder sozialen Konsequenzen dieser Realität beurteilen wie man möchte - aber sie zu negieren ist völliger Unsinn. Wahrscheinlich sind das die gleichen Experten, die ihren in China oder Taiwan hergestellten Flachbildschirm beim Billigdiscounter kaufen und ein gutes deutsches Wertarbeits-Auto fahren - aus US-Produktion.

Ich möchte aber noch etwas Inhaltliches zu den genannten Vorwürfen anmerken, die so einfach nicht richtig sind:

Dumping-Preise machen den deutschen Markt kaputt: Ein großer Teil der Arbeiten und Prozesse in der SW-Entwicklung sind heutzutage eine Commodity bzw. können nach standardisierten Abläufen durchgeführt werden. Damit sind sie weltweit handelbar und werden zu dem Tarif angeboten und nachgefragt, der ein optimales Preis-Leistungs-Verhältnis darstellt. Wenn der Flachbildschirm in Korea oder Mexiko nach dem gleichen ISO-zertifizierten Prozeß hergestellt werden kann wie in Deutschland oder Frankreich, dann entscheidet der günstigste Preis. So einfach ist das, und wer den Preisverfall in der SW-Industrie mit diesem Argument beklagt, der muß schön völlig leergeweinte Tränensäcke aus den letzten Jahrzehnten haben, in denen er die Globalisierung der Textil-, Elektronik- oder Automobilindustrie bejammert hat.

Niedrige Preise gleich schlechte Qualität: Die für uns niedrigen Preise sind im Offshore-Land i.d.R. überdurchschnittlich hoch. Weshalb sollte daher die Qualität darunter leiden? Wir setzen in unserem Nearshore-Zentrum in Rumänien bis auf wenige Ausnahmen (z.B. Sekretariat) nur hochqualifizierte Absolven technischer Studiengänge ein, die meistens über viele Jahre hervorragender Berufserfahrung in der SW-Entwicklung verfügen. Aufgrund weltweit gängiger Standards können sie nach den gleichen Prozessen und Modellen arbeiten wie deutsche, amerikanische oder japanische Entwickler. Eine Reihe von Studien der vergangenen Jahre belegen, daß nur rund ein Drittel aller SW-Projekte im definierten Zeit- und Kostenrahmen enden und ca. ein Viertel der Projekte komplett gegen die Wand gefahren wird. Diese Studien untersuchen zum allergrößten Teil jedoch Projekte ohne Outsourcing-Komponenten. Es scheint also durchaus kein Problem zu sein, auch ein rein deutsches Projekt mit deutschem Kunden, deutschem Projektleiter, deutschen Entwicklern, deutschen Analysten / Designern und deutschen QA-Leuten zu versenken.

Projekte remote durchzuführen ist zu schwierig bis unmöglich: Dann scheinen wir in den vergangenen Jahren bei Infobest etwas falsch gemacht zu haben…. Selbstverständlich sind Projekte, die ganz oder teilweise an einer mehr oder weniger vom Kunden entfernten Lokation durchgeführt werden, anspruchsvoller als reine Onsite Projekte. Es kann aber sehr gut gelingen, wenn man sich entsprechende Gedanken über Kommunikation und Projektlogistik macht und auf eine saubere Umsetzung achtet. In unseren Projekten hat es sich z.B. als Best Practice herausgestellt, bei der Analyse und Erfassung von Anforderungen die nötigen Workshops immer mit dem Kunden vor Ort durchzuführen. Der persönliche Kontakt ist in der Anfangsphase eines Projektes von fundamentaler Bedeutung. Dieser Einsatz von einigen wenigen Tagen schafft dann jedoch die Möglichkeit, große Teile der Architektur- und Designarbeit sowie die gesamte Entwicklung remote durchzuführen. Während dieser Phasen genügen dann meist wöchentliche Jour-fix-Termine am Telefon, detaillierte regelmäßige Statusmeldungen und unkomplizierte Frage-Antwort-Spiele über Chat oder Email, um das Projekt auf Kurs zu halten. Dazu gehören auch noch klare Zuständigkeiten und Kompetenzen, eine saubere Projektplanung oder eine durchdachte Qualitätssicherung. Aber hierbei spielt es keine Rolle, ob das Projekt Onsite oder Offshore durchgeführt wird.

Höhere Zeitaufwände machen niedrige Tagessätze kaputt: Was am Ende entscheidet, ist das Gesamtergebnis. Wenn ein Kunde durch Einsatz von Offshore-Kapazitäten eine vergleichbare Qualität zu 40% bis 50% niedrigeren Kosten erhält und dabei 10% bis 15% mehr Projektoverhead in Kauf nimmt, wird er mit dem Ergebnis sehr gut leben können. Sicher mag es Anbieter geben, die durch niedrige Sätze locken und ihre Marge dann durch erhöhte Zeitaufwände wieder aufbessern. Aber erstens verfahren auch deutsche SW-Anbieter nicht selten nach diesem Modell, das ist keineswegs eine Offshore-Spezialität. Und zweitens liegt es auch beim Kunden, sich auf ein transparentes und überprüfbares Leistungserbringungs-Modell mit dem Lieferanten zu einigen. Zu unseren Standards gehört z.B. der Einsatz eines gemeinsam genutzten bzw. zugänglichen Versionierungs-Tools wie SVN. Damit kann der Kunde jederzeit sehen, wie der aktuelle Arbeitsfortschritt ist, welche Entwickler an welchen Komponenten arbeiten und wann welche Bausteine in welchem Zustand ein- oder ausgecheckt werden. Damit hat er ein vergleichbares Maß an Kontrolle, das er auch bei einem deutschen Dienstleister hätte.

Zu einem erfolgreichen Offshore-Projekt gehören noch wesentlich mehr Parameter als die hier genannten, dies soll und kann keine erschöpfende Liste sein. Sie soll aber zum Nachdenken anregen.

Vor einigen Monaten hatte ich ein Gespräch mit einem kritischen Interessenten und habe ihm u.a. die genannten Punkte erläutert. Seine verständliche Grundhaltung war die, daß Papier geduldig und Worte zeitlos sind. Wir haben uns dann schließlich darauf verständigt, ein kleines Testprojekt von wenigen Manntagen durchzuführen, damit er sich ohne Risiko von unserem Nearshore-Modell und der Arbeitsweise überzeugen kann. Mit ähnlichen “vertrauensbildenden Maßnahmen” haben wir in den letzten Jahren hervorragende Ergebnisse erzielt und insbesondere mittelständische Unternehmen, die nicht über die Ressourcen, Verbindungen und Erfahrungswerte globaler Konzerne verfügen, zu unseren Kunden gemacht.

Neulich hatte ich die Frage gestellt, welche konkrete Erfahrungen Sie in Ihren Projekten mit Entwicklungsmodellen gemacht haben. Ich spreche dieses Thema auch in den zahlreichen Gesprächen mit Kunden und Kollegen an und finde die Antworten, die in der Praxis gefunden werden, sehr spannend.

Hier und heute möchte ich ein solches Praxisbeispiel anführen und daran verdeutlichen, daß es auf die konkrete Situation ankommt und nicht auf die Erfüllung irgendwelcher dogmatischer Theorien.

Zunächst also die Ausgangslage: Ein mittelständischer Hersteller von Standard-Software sucht einen Nearshore-Partner, um neue Module und Produkte entwickeln zu lassen. Im aktuellen Geschäftsmodell des Kunden sind Flexibiliät und Geschwindigkeit von größter Bedeutung, um auf häufig veränderte Einsatz-Szenarien und Anforderungen reagieren zu können. Der klassische Wasserfall-Ansatz, egal wie dynamisch ausgelegt und mit welch schlauen Change Management Prozeduren gekrönt, würde zu viel Zeit und Aufwand für Dokumentation und Spezifikation erfordern, obwohl Anforderungen mehrheitlich beschreibbar und folglich spezifizierbar wären.

Gemeinsam mit dem Nearshore-Partner Infobest wurde daher ein agiles Modell entwickelt, das einige wesentliche Elemente von Scrum enthält wie z.B. eine zentrale Backlog-Liste; Priorisierung der Features in der Backlog-Liste durch den Kunden; 2-wöchige Sprints; Einschätzung durch den Lieferanten, welche Punkte aus der Backlog-Liste in den nächsten Sprint passen (und damit Entscheidung darüber, welcher Inhalt mit einem gegebenen Budget umgesetzt wird, ein ganz zentrales Scrum-Theorem). Soweit so gut die Theorie. Allerdings wurde z.B. darauf verzichtet, tägliche Scrum-Meetings zu sklavisch festgelegten Uhrzeiten anzusetzen, geschweige denn den Kunden darin einzubeziehen. Die Entwickler und Tester arbeiten zu teilweise sehr unterschiedlichen Tages- (und Nacht)zeiten, so daß solche Meetings keinen Sinn ergeben. Stattdessen treffen sich alle  oder einige der Projektmitglieder mehrmals täglich zu Abstimmungsgesprächen und der Projektleiter stellt sicher, daß er den Überblick über die Aktivitäten behält. Unnötig zu erwähnen, daß seine Arbeitszeiten die “umspannendsten” sind. Ebenfalls von der Scrum-Theorie abweichend beinhaltet nicht jede Lieferung am Ende eines Sprints zwangsweise eine vollständig lauffähige neue Version des gesamten Produktes. Vielmehr wurde genau festgelegt, welche Art der Qualitätssicherung innerhalb eines Sprints von Infobest zu leisten ist und in welcher Form der Kunde am Ende eines Sprints seine eigene Abnahme für den jeweiligen Sprint durchführt. So kann es durchaus passieren, daß ein bestimmter Teil vollständig und QA-gesichert geliefert wird, das Produkt insgesamt jedoch auch Elemente enthält, die aufgrund von Seiteneffekten oder Sprint-übergreifenden Themen (ein typisches Beispiel wäre die Überarbeitung des UI-Layouts oder Reports) nicht vollständig erledigt sind. Der Kunde stimmt daher viel mehr mit dem Lieferanten ab, welche der Sprints eine komplette neue Version darstellen sollen und welche Sprints lediglich die neu entwickelten Funktionen des individuellen Sprints vollständig enthalten müssen.

Nicht orthodox? Mag sein und sicher werden die Verfechter der Scrum-Philosophie an dieser Stelle die Bleistifte spitzen, um ihre Argumente darzulegen, warum das alles so ganz furchtbar ist. Aber das Schöne an diesem “eingedampften” Scrum-Modell ist, daß es genau für dieses Projekt-Szenario wunderbar funktioniert.

was Sie nicht alles wissen: Der Rumäne schlechthin kann morgens nicht pünktlich zur 7-Uhr-Schicht erscheinen, geht vor Feierabend schon nachhause und weiß in der Zwischenzeit nicht, was er tut. Ein solches Statement ist an geistiger Armut schwer zu überbieten und ist selbst für NPD und Republikaner zu dümmlich, um als Wahlkampf-Hilfe zu dienen.

Es ist aber nicht nur dümmlich, es ist auch noch falsch. Lassen Sie sich das von jemandem erklären, der als Deutscher seit 9 Jahren ein Unternehmen in Rumänien betreibt und über 30 Mitarbeiter persönlich kennt und führt: Der Rumäne schlechthin ist genauso gut, motiviert, zuverlässig und talentiert - oder eben das genaue Gegenteil - wie der Deutsche schlechthin. Unsere Mitarbeiter jedenfalls haben mich oder das Unternehmen noch nie im Stich gelassen. In wirtschaftlich schwierigen Zeiten haben Mitarbeiter persönliche Opfer gebracht, um damit den Erhalt aller Arbeitsplätze zu sichern. Und wann immer Kundentermine eingehalten werden mußten, konnte ich mich darauf verlassen, daß notfalls auch die eine oder andere unbezahlte Überstunde klaglos geleistet wurde. Faulenzer und Drückeberger gibt es überall, so natürlich auch dort. Aber sicher nicht mehr oder weniger als hier.

Zudem ist Rumänien das Land mit der weltweit höchsten Dichte an Studierenden je Einwohner (können Sie in OECD-Berichten nachlesen) und einem hervorragenden Ruf in mathematisch-technischen Studiengängen. Da wird schon mal der eine oder andere dabei herauskommen, der vielleicht doch weiß, was er tut… Sie könnten alternativ auch mal zu Microsoft ins Silicon Valley fahren und dort nachsehen, welches die nach Englisch am häufigsten gesprochene Sprache ist: es ist nämlich nicht Hindi oder Urdu, sondern - tatsächlich Rumänisch.

Dann bleibt nur zu hoffen, daß Ministerpräsidenten schlechthin nicht immer solchen Unsinn von sich geben wie Sie. Oder wissen Sie am Ende etwa gar nicht, was Sie da tun?

In den vergangenen Wochen und Monaten hatte ich zahlreiche Gespräche mit Verantwortlichen aus dem Bereich Software-Entwicklung.  Besonders interessant dabei war, daß viele Gesprächspartner ein gemeinsames Problem zu teilen scheinen: Die gängigen Entwicklungsmodelle mit dem klassischen Wasserfall-Ansatz (Analyse, Design, Entwicklung, Test, Implementierung) scheinen oft zu kurz zu greifen. Selbst in “dynamisierter” Form mit entsprechenden Iterationsschleifen lösen sie folgendes grundsätzliches Problem nicht: In der Analyse-Phase sind die zukünftigen Anwender einer Software kaum in der Lage sind, ihre Anforderungen präzise und vollständig zu formulieren. Ihnen fehlt zudem häufig die Vorstellungskraft, “was man so alles mit IT machen kann”. Aus diesem Grund liefert die anschließende Entwicklung auf der Grundlage dieses lückenhaften Anforderungsprofils nur eine mangelhafte Software, die permanent nachgebessert und erweitert werden muß.

Andererseits hat keiner meiner Gesprächspartner Zuflucht in agile Methoden gesucht, was meine erste Vermutung gewesen wäre. Nicht, daß agile Methoden per Definition das Allheilmittel wären, es wäre aus meiner Sicht nur eine naheliegende Antwort auf das Problem gewesen. Ich würde daher sehr gerne die Meinungen von möglichst vielen Betroffenen kennen und würde mich über Gedankenansätze und Anregungen an dieser Stelle freuen.

• Nach welchem Modell entwickeln Sie Software?

• Wie lösen Sie das Problem unzureichender Anforderungsanalysen?

• Oder kennen Sie dieses Problem gar nicht?

• Was halten Sie von Scrum und anderen agilen Methoden?

Vielleicht die spannendste Frage überhaupt: Woran scheitern häufig Nearshore-Projekte? Wir hatten in Teil 1 schon im Groben resumiert, welches die wesentlichen Voraussetzungen für die Machbarkeit und den Erfolg von Nearshore-Projekten sind. Sie erinnern sich: Spezifizierbarkeit des Projektes, Organisationsgrad bzw. Verständnis für Entwicklungsmodelle und Projektmanagement sowie vernünftige Kommunikation stehen sicher ganz weit vorne.

Es gibt jedoch einen weiteren sehr wesentlichen Aspekt, der auch dann extremen Einfluß auf ein Nearshore-Projekt nehmen kann, wenn die besten Voraussetzungen geschaffen wurden und alle Beteiligten guten Willens und froher Natur sind: die Kontinuität.

Aha, was meint er denn damit? Vielleicht am einfachsten ein paar Geschichten aus dem Nähkästchen:

• Im Verlaufe des Projektes wechselt der Kunden-Projektleiter. Es gibt keine wirkliche Übergabe und kein Briefing auf Kunden-Seite. Der Lieferant weiß nicht so recht, wie er mit der Situation umgehen soll, da der neue Projektleiter ein erklärter Nearshore-Skeptiker ist. Und getreu dem Modell der “self-fulfilling-prophecy” nimmt das Schicksal natürlich seinen Lauf. Der schlaue Lieferant denkt an das Handbuch zur Lösung schwieriger Aufgaben und versucht natürlich, als erstes ein Kennenlern-Gespräch mit dem neuen Verantwortlichen zu führen. Dieser möchte aber nicht, keine Zeit, darum kümmern sich “meine Leute”, ich muß mich erst einarbeiten. Davon steht im Handbuch leider nichts.
• Das Projekt steuert auf seinen Höhepunkt zu, nur noch wenige Tage bis zur ersten Lieferung an den Kunden. Da fällt diesem ein, daß noch “schnell mal eben” eine kleine Änderung gemacht werden muß. Design Freeze hin oder her, dieser Punkt ist für den Business Case unglaublich wichtig, der CIO wetzt schon die Messer und wenn das nicht gemacht werden kann, dann ist der Lieferant wohl zu unflexibel und überhaupt hat man ja gleich bezweifelt, daß Nearshore etwas Gescheites ist wegen der Flexibilität und jeder deutsche Lieferant wäre da sicher einsichtiger…. die Dinge nehmen ihren Lauf, diese kleine Änderung betrifft einen Teil des Codes, der bereits durch den kompletten Funktionstest gelaufen ist und für einen umfangreichen Regressionstest reicht weder Zeit noch Aufwand, denn der Kunde besteht natürlich auf pünktliche Lieferung.
• Zu Beginn des Projektes werden akribisch genau die verantwortlichen Personen, ihre Rollen, Funktionen und Kompetenzen im Projekt definiert und sämtliche Spielregeln für Kommunikation festgelegt. Anstatt aber die ersten CRs wie vereinbart durch den CR-Verantwortlichen im Projektportal gesondert zu protokollieren, schreibt der Kunden-Projektleiter alle Änderungswünsche in einzelne Mails hinein. Anfangs macht sich der Lieferant noch die Mühe, die Punkte herauszukopieren, aber irgendwann wird auch das zu aufwändig. Man spricht den Kunden darauf an, dieser zeigt sich einsichtig, bleibt aber trotzdem bei seinen Mails. Weil eben die Zeit für aufwändigere Dokumentation fehlt. Soll sich der Lieferant darüber beschweren und auf dem vereinbarten Change Management Prozeß bestehen? Und was, wenn es dennoch nichts nützt? Spannend wird ein solches Thema traditionell immer dann, wenn CRs gesondert abgerechnet werden sollen…

Ich denke Sie erkennen, worauf ich hinaus will. Vernünftige Spielregeln zu vereinbaren ist das eine, sie in der täglichen Arbeit auch umzusetzen, das andere. Natürlich stehen hier beide Projektpartner gleichermaßen in der Pflicht, aber es liegt in der Natur solcher Beziehungen, daß sich ein Lieferant schwerer damit tut, seinen Kunden “bei der Stange” zu halten als umgekehrt. Das schöne Sprichtwort gilt letztendlich auch hier: nobody has ever won an argument with a customer…

Aber lassen wir keinen falschen Eindruck entstehen: Ich habe sehr viele sehr gute Projekte gesehen, und wenn das nicht auch die überwiegende Mehrheit der Projekte wäre, würde es wohl kein Nearshoring und keine Nearshore-Lieferanten geben.  Aber glatt laufende Projekte sind wenig spannend und wir wollten ja auch ein wenig über das Scheitern sprechen…

Zum 1. Juni 2009 haben die Unternehmen Continental Automotive und Infobest eine langfristige Zusammenarbeit in verschiedenen IT-Bereichen vereinbart. Kern dieser Kooperation ist die Weiterentwicklung und Pflege der bei Continental Automotive weltweit intern genutzten Anwendungen, die mehrheitlich auf C++ und .Net entwickelt werden.

Im Rahmen dieser Kooperation kommen die IT-Experten der rumänischen Infobest-Gesellschaft zum Einsatz. Bereits in der Vergangenheit konnte sich Continental Automotive von der Qualität und dem hervorragenden Preis-Leistungs-Verhältnis des deutsch-rumänischen IT-Dienstleisters in verschiedenen Einzelprojekten überzeugen.

Infobest gibt den Aufbau eines Experten-Teams für den Bereich Sharepoint bekannt. Das Kernteam wird zunächst am rumänischen Standort in Timisoara eingerichtet und konzentriert sich auf die Aspekte Applikationsentwicklung und administrativer Support für Sharepoint-Technologien. Dabei werden bereits bestehende Erfahrungen und Kenntnisse in diesem Umfeld konsolidiert und als eigenständige Leistungspakete gebündelt. Die schrittweise Erweiterung des Kernteams in den kommenden 3 Monaten ist bereits fest eingeplant und budgetiert.

Lotus Notes und Domino sind weltweit bekannte Email- und Groupware-Plattformen mit einem etablierten Markt in Deutschland, Österreich und der Schweiz. In den vergangenen Jahren wurden tausende von Notes-Anwendungen für diese Plattform entwickelt, von ganz einfach bis extrem komplex, von kunden-spezifisch bis Standard und von Client-only bis Web-Interface. Was es aber seltsamerweise kaum gibt, sind Notes-Entwickler in Nearshore-Destinationen. Das mag allerlei Ursachen haben, über die zu spekulieren müßig ist. Tatsache bleibt, daß man in Osteuropa wirkliche Notes-Fachleute wie die Nadel im Heuhaufen suchen muß.

Infobest hat bereits 2000 ein Notes-Team in seiner rumänischen Niederlassung aufgebaut, zunächst nur mit der Zielsetzung, eigene Standard-Produkte zu entwickeln. Mittlerweile verfügt das Nearshore-Büro über langjährige Expertise und hat zahlreiche Notes-Projekte unterschiedlichster Größenordnungen und Inhalte für diverse mitteleuropäische Kunden wie Philips, Continental, Bosch, Allianz und zahlreiche mittelständische Unternehmen durchgeführt hat.

Ab Anfang April 2009 verstärken wir unser Notes-Team in Rumänien wieder. Wenn Sie in diesem Bereich Projekte zu vergeben haben und die Nearshore-Karte einmal spielen möchten, sollten wir darüber sprechen. Auf Wunsch kann Ihr Projekt auch durch einen erfahrenen deutschen Notes-Projektleiter begleitet werden, ebenso kann das gesamte Projekt in deutscher Sprache abgewickelt werden.

Heute möchte ich ein wenig zu den verschiedenen Gestaltungsmöglichkeiten für Nearshore-Projekte schreiben. Zunächst hängen diese natürlich von der Natur des Projektes ab, ein klassisches Entwicklungsprojekt bietet andere Optionen als z.B. ein Wartungs- oder ein Testprojekt. Nehmen wir also der Einfachheit halber einen Kunden an, der eine Neuentwicklung im Bereich Business Anwendung umsetzen will, mittlere Größenordnung (200 bis 300 PT).

Szenario 1: Die Anforderungen für das Projekt sind schwer zu erfassen und erfordern viel fachliches Knowhow. Die Spezifikation dieser Anforderungen muß daher vor Ort erfolgen und geschieht in mehreren Iterationsschritten mit zahlreichen Workshops, in denen unterschiedliche Anwendergruppen heterogene Anforderungen äußern.
Projektorganisation: Ein “Brückenkopf” wird beim Kunden vor Ort zu Projektbeginn durchgehend eingesetzt, der mit dem Kunden zusammen die Anforderungen sammelt, auswertet und in eine Spezifikation gießt. Dieser Brückenkopf kann entweder ein deutscher Projektleiter / Analyst sein (der natürlich die Nearshore-Kollegen kennt) oder ein Nearshore-Projektleiter /-Analyst, der diese Aufgabe ausfüllen kann. Die Kommunikation findet zwischen Kunde und Brückenkopf sowie zwischen Brückenkopf und Nearshore-Team statt. Diese Gestaltung kann nach Abnahme der Spezifikation auch derart aufgelöst werden, daß der Kunde dann direkt mit dem Nearshore-Team kommuniziert. Das Projekt wird dann entweder als Festpreis umgesetzt oder nach Aufwand, abhängig von Detaillierung und Qualität der Spezifikation und von der zu erwartenden Volatilität im Projekt. Letzteres heißt konkret: Wenn zu erwarten steht, daß der Kunde die Anforderungen nach Abschluß der Spezifikation häufig ändert oder erweitert bzw. viele kleinere Phasen mit neuen Anforderungen unmittelbar anschließend zu erwarten sind, dann würde ein Festpreis einen immensen Overhead produzieren, alleine um die Change Requests zu verwalten. “Time and Material” ist hier erfahrungsgemäß die einfachere und kostengünstigere Variante.

Szenario 2: Der Kunde hat ein hervorragend spezifiziertes Projekt zu vergeben. Funktionale und nicht-funktionale Anforderungen sind sauber definiert, die UI ist entsprechend Standard-Layouts vorgegeben, sämtliche Schnittstellen und andere relevanten technischen Formate liegen auf dem Tisch.
Projektorganisation: Dieses Paket kann z.B. im Rahmen eines Workshops beim Kunden vor Ort an einen Nearshore-Projektleiter übergeben werden, der als zentraler Ansprechpartner für dieses Projekt dient. Er ist dafür verantwortlich, das Projekt mit seinem Nearshore-Team aufzusetzen und durchzuführen. Ein Festpreis bietet sich an, die gesamte weitere Organsiation des Projektes bis hin zur Lieferung und Abnahme kann beim Nearshore-Partner liegen und von diesem verantwortet werden.

Szenario 3: Der Kunde hat eine Vielzahl von kleineren bis mittleren Projekten oder Versionen innerhalb eines Projektes (z.B. typisch bei Produktentwicklungen). Der Aufwand, um für jedes einzelne kleine Projekt oder jede Version eine abnahmefähige Spezifikation zu erstellen, wäre recht hoch und ist aus organisatorischen Gründen nicht zwingend erforderlich.
Projektorganisation: Hier macht es wenig Sinn, mit Pflichtenheften und Festpreisen zu hantieren, das Change Management würde vermutlich mehr Overhead produzieren als das gesamte Projektvolumen nach Aufwand beträgt. Daher ist der Kunde am besten beraten, für den Zeitraum, den er selbst projektseitig überschauen bzw. prognostizieren kann, ein festes Kontingent von Nearshore-Mitarbeitern als “sein” Team einzukaufen. Damit kann er sicherstellen, daß für alle Projekte bzw. Produktversionen immer die gleichen Nearshore-Kollegen zuständig sind, keine permanenten Einarbeitungen nötig sind, zeitraubende Festpreis-Verhandlungen entfallen und der Aufwand, der sonst in die X-te Review einer Spezifikation investiert würde, lieber für die Entwicklung oder Qualitätssicherung zur Verfügung steht. Natürlich liegt das Risiko für die Qualität des Anforderungs- und Projektmanagements annähernd komplett beim Kunden, ebenso trägt er die Verantwortung für eine gleichmäßige Auslastung des Teams. Unter den entsprechenden Voraussetzungen ist das aber tatsächlich eine sehr effiziente Organisationsform, soz. als eine verlängerte Werkbank. Hier muß natürlich vom Nearshore-Partner sichergestellt werden, daß seine Aufwände transparent sind und möglichst im groben Rahmen vorab mit dem Kunden besprochen werden. Ebenso ist eine sehr gute und schnelle Kommunikation der Beteiligten zwingend erforderlich. Unter dem Strich aber bleibt es eine Projektform, die starkes gegenseitiges Vertrauen voraussetzt.

Wir haben in den vergangenen Jahren alle diese Szenarien erlebt und durchgespielt. Und mit allen Szenarien erfolgreich Nearshore-Projekte umgesetzt. Natürlich gibt es noch zahlreiche Nuancen und Facetten, aber im Großen und Ganzen lassen sich mit diesen Spielarten die meisten Fälle abdecken.

Unser Unternehmen ist seit 2000 im Nearshore-Geschäft tätig. Da haben wir einiges an Erfahrungen gesammelt und Interessantem erlebt. Und weil wir auch heute noch bei vielen Unternehmen auf Skepsis und Fragen zu diesem Thema stoßen, möchte ich ein wenig aus unserer Praxis plaudern und verschiedene Aspekte näher beleuchten.
Fangen wir heute mal mit der Frage an, unter welchen Voraussetzungen Nearshore (oder Offshore) Sinn macht und in welchen Fällen man besser die Finger davon läßt.

Eine wesentliche Funktion für “Nearshore-Fähigkeit” ist die Spezifizierbarkeit der zu entwickelnden Komponenten. Hier reicht die Bandbreite von Extrem zu Extrem. Auf der einen Seite haben wir Projekte erlebt, bei denen irgendwelche Anforderer (also die späteren Anwender der Software) aus irgendwelchen Fachabteilungen ihre konkreten Wünsche und Anforderungen an die Funktionalitäten der Software nur sehr zögerlich, inkonsistent und lückenhaft an Mitarbeiter der IT-Abteilung unseres Kunden übermittelt haben. Diese mußten dann auf Basis dieses Inputs irgendeine Spezifikation zaubern, die für uns als Auftragnehmer sehr schwer zu überprüfen war, v.a. weil wir selbst keinen direkten Kontakt zu den eigentlichen Anforderern herstellen konnten. Eine solche Ausgangsbasis ist natürlich eher problematisch. Auf der anderen Seite des Spektrums gibt es Kunden, die sehr präzise Informationen in einen Spezifikationsprozeß liefern können, so daß wir gemeinsam mit dem Kunden eine solide Ausgangsbasis schaffen, i.d.R. in Form von Anwendungsfällen (neudeutsch Use Cases) und nicht-funktionalen Anforderungen, gelegentlich auch konkreten UI-Spezifikationen. Da wir nicht selten zur Abgabe eines Festpreis-Angebotes “ermutigt” werden, verwenden wir nach Möglichkeit unsere eigenen Dokumentations-Standards für die Anforderungs-Spezifikation. Wenn diese Anforderungs-Spezifikation noch vom “Anforderer” abgenommen wird, ist das die wirklich ideale Ausgangsbasis. Und vorher sollte keine weitere Arbeit im Projekt investiert werden, d.h. vor Klarstellung einer Anforderungs-Spezifikation macht keine Aufwandschätzung, keine Architektur, kein weiteres Design, keine Datenmodellierung, geschweige denn Programmierung Sinn.

Eine andere zentrale Komponente der Nearshore-Fähikeit ist der Organisationsgrad des Kunden. Damit meine ich im Wesentlichen die Prozesse und Standards in der Software-Entwicklung und im Projektmanagement, die angewendet werden - oder eben auch nicht. Um Nearshore erfolgreich zu betreiben, müssen zunächst die Zuständigkeiten klar defniert sein, also wer ist wofür der Ansprechpartner, wer kann was an wen delegieren und wer ist die abschließende Instanz für die Klärung bestimmter Fragen. Binsenweisheit? Hatten wir auch schon häufig gedacht. Aber es ist erstaunlich, wie oft in der Praxis diese einfachen Dinge aufgrund von Kompetenz-Gerangel und der in großen Organisationen permanent stattfindenden Neuorgansiation nicht funktionieren. 
Neben den Zuständigkeiten sollte es einen klar beschriebenen Entwicklungs-Prozeß geben. Es ist nachrangig, ob und wie sehr dieser einer der gängigen Theorien à la RUP, V-Modell, Wasserfall, etc. entspricht oder hausgemacht ist. Jeder mag hier seiner Religion frönen, was zählt ist, daß der Prozeß einigermaßen klar, verständlich, der Aufgabenstellung angemessen ist und auch tatsächlich stattfindet, d.h. nicht nur auf Papier und in tollen Powerpoint-Präsentationen lebt.
Was ich deutlich kritischer sehe sind agile Modelle wie Scrum oder Prototyping, letzteres häufig eine pseudo-wissenschaftliche Ausrede in Fällen, in denen angeblich die Anforderungen nicht modelliert oder spezfiziert werden können (”Der Kunde weiß nicht genau, was er will”). Das kann schon auch mit Nearshore funktionieren, aber der Organisations- und Abstimmungsgrad auf beiden Seiten (Kunde und Nearshore-Partner) muß deutlich höher sein und alle Aktivitäten müssen viel stärker synchron getaktet werden - und zwar von allen Beteiligten. Das übersteigt in der Praxis meistens die Fähigkeiten an Koordination und Kommunikation. Also im Zweifelsfall lieber die Finger davon lassen.
Neben dem Entwicklungsprozeß sollte aber auch das Projektmanagement des Kunden zumindest in zentralen Punkten einheitlich funktionieren. Dazu gehören z.B. frühzeitige Projektbeschreibungen, einheitliche Projektpläne, Risikobetrachtungen, ein Kommunikationsplan und Qualitätsrichtlinien. Auch das muß nicht unbedingt streng katholisch nach PMI oder Prince2 gehandhabt werden und kann bei kleineren Projekten auch überschaubar und einfach gestaltet werden (die Devise heißt nicht, in Schönheit zu sterben). Aber wenn man schon zu Beginn des Projektes nicht genau definieren kann, was im Scope des Projektes liegt und was nicht, sind die Voraussetzungen denkbar schlecht. Das ist natürlich kein Punkt, der nur speziell für Nearshore gilt, sondern der (wie alle anderen Punkte auch) für alle Projekte relevant ist, im Fall von Nearshore aber eine besonders zentrale Bedeutung hat.

Und da aller guten Dinge drei sind, hier noch ein dritter Baustein für erfolgreiches Nearshore-Geschäft: Kommunikation. Das gehört natürlich streng genommen in das allgemeine Projektmanagement hinein. Aber da für Nearshore die Kommunikation wirklich einer der absolut zentralen und wichtigsten Aspekte ist, sei ihm ein Logenplatz gegönnt. Und damit diese funktioniert, sollten ein paar Spielregeln gleich zu Beginn des Projektes festgelegt werden: welche Inhalte / Dokumente werden z.B. in einem Projekt-Portal abgelegt; welche Themen sollten per Mail behandelt werden; wann und wofür werden Chat und Telefon eingesetzt; gibt es einen Jour Fix z.B. für wöchentliche Statusbesprechungen; wie häufig und in welcher Form erfolgt die Rückmeldung über den Projektverlauf, reicht ein wöchentlicher Bericht, welche Themen müssen ad hoc kommuniziert werden; wann wird was wohin eskaliert?
Bei all diesen Fragestellungen müssen sich beide Partner darüber im Klaren sein, daß vereinzelt Sprachbarrieren bestehen können und kulturelle Unterschiede zu unterschiedlichen Interpretationen von Sachverhalten führen können. Hier bietet sich das oft zitierte (und von mir persönlich erlebte) Beispiel an, daß ein Inder eine Frage, auf die er eigentlich mit Nein antworten müßte, aus Gründen des Gesichtsverlustes häufig doch mit Ja beantwortet oder hartnäckig ignoriert. Mit unseren rumänischen Kollegen sind die kulturellen Unterschiede natürlich weit kleiner als im beschriebenen Fall. Aber es ist z.B. so, daß ein Rumäne bei Fragen oder Problemen viel schneller ein persönliches Gespräch sucht und gemeinsam mit anderen Beteiligten mögliche Lösungen bespricht, als sich stundenlang in Einsamkeit zu quälen oder über unpersönliche Kanäle wie Email zu kommunizieren. Und noch ein kleiner Beitrag zum Thema Vorurteil: Neulich sagte ein Kunde zu mir nach einem ersten Telefonat mit einem unserer deutsch-sprachigen rumänischen Projektleiter: “Das ist unglaublich, der Mensch ist wirklich super fit. Man glaubt gar nicht, daß das ein Rumäne ist”. Klar, die leben sonst alle in Erdlöchern und fressen kleine Kinder…