Infobest-Blog

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.

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…

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…