Managing Projects: Verteilte Teams

Herzlich willkommen im ersten Teil der Serie "Managing Projects" mit dem Titel "Verteilte Teams" bei IT Projekten. Verteilte Teams finden sich immer öfter zusammen, um ein gemeinsames Projekt zu realisieren. Zwei Trends in der IT Branche sind das Offshoring und Outsourcing. In beiden Fällen arbeiten Teams verteilt zusammen an gemeinsamen Projekten.



Die dadurch entstehende Distanz auf unterschiedlichen Ebenen (geografisch, kulturell etc) steht im Gegensatz zu modernen Prozessen in denen direkte ("face to face") Kommunikation hohe Priorität erhält, zum Beispiel in der agilen Softwareentwicklung.

Doch zunächst einmal definieren wir, was unter verteilten Teams verstanden wird. Es gibt 2 Arten, die man unterscheidet:

Verteilte Teams

Hierbei handelt es sich um mehrere eigenständige Teams, die an unterschiedlichen Orten agieren. Zum Beispiel ein Entwicklerteam, das in New York arbeitet und ein anderes, das in Berlin tätig ist. Beide Teams arbeiten typischerweise an unterschiedlichen Bereichen eines Produkts/Projekts (engli. distributed Team).

Verstreute Teams

Bei dieser Art des Teams sind die Teammitglieder selber verstreut, bedeutet ein Entwicklerteam aus 5 Leuten agiert zum Beispiel von 5 Standorten aus (Berlin, Moskau, New York, Tokio, Stuttgart) (engl. dispersed Team).

Je nach Größe der Teams sollten folgende Rollen besetzt werden:

• (Chef-)Architekt: Entwirft die Architektur des Gesamtsystems und verantwortet die Einhaltung gewisser Regeln für die technische Realisierung.
• Datenbankadministrator: Ist verantwortlich für das Design der Datenbank und hilft allen Teammitglieder als Spezialist bei Themen, die die Datenbank betreffen.
• (Interface-)Designer: Spezialist in Sachen UX/UI/HCI und verantwortlich für ein Frontend aus einem "Guß"
• QA/QS Verantwortlicher: Kümmert sich um strukturierte Tests und sichert so die Akzeptanz beim Kunden.
• Entwickler: Programmieren die benötigen Features unter Berücksichtigung der architektonischen Vorgaben des Architekten und erstellen für Ihre Features Unit Tests und Dokumentationen.
• Anforderungsmanager: Nehmen die Anforderungen entgegen und bereiten diese für die Umsetzung auf.
• Fachliche Spezialisten/KnowHow Träger: Sie stehen als Spezialisten und KnowHow Träger zur Seite, wenn es fachliche Fragen gibt.
• Release Manager: Verantwortlich für die Integration der Features und für das Bereitstellen einer neuen Programmversion.

Rollen-übergreifend muss natürlich jedes Teammitglied für seine Aufgaben geeignete Dokumentationsmaßnahmen treffen und einhalten.

Die Schwierigkeit ist nun, verteilte Teams so zu gestalten, dass Sie effektiv zum Projekterfolg beitragen. Natürlich hat jedes Projekt seine Eigenheiten und eigenen Regeln. Generell hat sich jedoch der Ansatz durchgesetzt, dass ein Team immer in der Lage sein sollte ein Feature eigenständig zu liefern. Das bedeutet, dass in einem Team immer alle Rollen vertreten/vorhanden/besetzt sind, die für die Umsetzung eines Features, bzw. einer Anforderung notwendig sind. So entsteht ein hohes Maß an Eigenverantwortung in den Teams, das in 90% der Fälle zur Motivation führt, ein Feature umzusetzen. Natürlich sollten Schlüsselrollen auch Teamübergreifend besetzt sein. So sollte ein Chefarchitekt regelmäßig mit allen Architekten der einzelnen Teams im Austausch stehen, damit eine Teamübergreifende Grundarchitektur eingehalten wird und die Features auch integrierbar sind.

Doch ist eine face-to-face Kommunikation bei verteilten Teams notwendig oder sogar unabdingbar? Meiner Meinung ist sie unabdingbar und sollte von Beginn des Projekts an mit eingeplant werden (Kosten). Selbst verstreute Teams sollten regelmäßig zusammengeführt werden für einen Austausch und ein Status Gespräch. Zusätzlich können natürlich unterstützende Maßnahmen eingeführt werden (wöchtl. Statustelkos ...).

Fassen wir zusammen. Es gibt verteilte und verstreute Teams. Bei letzteren handelt es sich um Teams deren Mitglieder an verschiedenen Standorten agieren. Bei Verteilten Teams handelt es sich um mehrere Teams, die jeweils an anderen Standorten agieren. Beide Formen sind in aktuellen Projekten zu finden und tauchen auch auf Grund der Globalisierung und der immer fortschreitenden Internationalisierung immer häufiger auf.

Für jedes Team, verteilt oder verstreut, ist es wichtig bestimmte Rollen zu besetzen. So sollte jedes Team in die Lage versetzt werden eine Anforderung komplett umzusetzen. Dies natürlich unter Berücksichtigung bestimmter Paramter, zum Beispiel der Vorgaben des Chefarchitekten.

Kommunikation ist gerade bei solchen Teams, die nicht immer an einem Ort arbeiten von höchster Wichtigkeit. Regelmäßige Telefon- und Videokonferenzen können die direkte Kommunikation nicht ersetzen. Gemeinsame vor Ort Meetings sollten von Anfang an mit eingeplant werden. Hier ist der Projektleiter gefordert, dies einzufordern und zu organiseren.

Da die Teams in die Lage versetzt werden, Anforderungen eigenständig umzusetzen ist es wichtig, dass teamübergreifende Projektbeteiligte bestimmte Grundentscheidungen treffen. Als Beispiel nenne ich den Chefarchitekten, der für eine Grundarchitektur und eine technische Vision verantwortlich ist. Diese muss er dann in die einzelnen Teams einbringen.

In der nächsten Folge werde ich auf einige Notwendigkeiten für den Projekterfolg eingehen. Darunter fallen zum Beispiel das Definieren von Zielen, setzen von Meilensteinen, Kontakt zum Kunden und vieles mehr. Erscheinen wird der Artikel vorraussichtlich nach Ostern 2010.


Abschliessend noch ein schlauer Spruch: "Adding people to a late project makes it even later."