Der Erfolg eines Projekts hängt wesentlich von der Fähigkeit des Projektleiters ab, seine Mitarbeiter zu einem leistungsbereiten Team zu formen und erfolgreich zu führen. Dies gilt insbesondere in technologisch innovativen Bereichen wie im e-Business. Natürlich sind auch in E-Commerce-Projekten die meisten der auftretenden Probleme in der Projektarbeit "alte Bekannte". Dennoch dürfen solche Projekte nicht einfach in altbewährter Weise behandelt werden, denn für solche Projekte gibt es eine Reihe von spezifischen Herausforderungen.

Durch den starken technischen Fokus dieser Projekte werden Aspekte des Teammanagements oft vernachlässigt. Dabei liegt gerade hier der Schlüssel zum Projekterfolg. Wir schildern Ihnen wesentliche Aspekte des Team-Managements bei E-Commerce-Projekten unter informationstechnischen Gesichtspunkten.

Teambildung: Kriterien für Newcomer

Experten mit gutem Gesamtüberblick und fundierten Detailkenntnissen sind selten und meist in bereits laufenden Projekten verplant. Nicht selten wirken daher auch Berater ohne umfassende spezifische Erfahrungen in e-Business-Projekten mit. Eine wesentliche Frage im Vorfeld ist somit, nach welchen Kriterien solche Mitarbeiter auszusuchen sind.

Da die meisten der Projekte in diesem Umfeld objektorientiert arbeiten, sind Grundkenntnisse in diesem Bereich besonders wichtig. Erfahrungsgemäß ist der Umstieg von der strukturierten und prozeduralen zur objektorientierten Betrachtungsweise für die meisten Entwickler sehr mühsam. Hat man also beispielsweise für die Tätigkeit der Systementwicklung die Wahl zwischen einem C++-Entwickler mit zwei Jahren und einem Java-Entwickler mit einem halben Jahr Erfahrung, wäre in den meisten Fällen die Wahl des C++-Entwicklers sinnvoller - unabhängig von der eingesetzten Programmiersprache.

Ein weiteres zentrales Auswahlkriterium auch über diesen Kontext hinaus ist ein abwechslungsreicher Lebenslauf der potentiellen Team-Mitarbeiter, der eine gute Lernfähigkeit ausweist: Die Technik wandelt sich schnell, das Team muss ständig dazulernen. Die Erfahrung zeigt hier, dass man einen flexiblen einem "festgefahrenen", an alten Konzepten hängenden, Mitarbeiter vorziehen sollte, selbst dann, wenn dessen Erfahrungen näher an den Herausforderungen der Projektaufgabe liegen.

Teamausbildung: Coaching und Mentoring

Vor die Aufgabe gestellt, im Rahmen eines Projekts eine objektorientierte Ausbildung betreiben zu müssen, scheint folgender Rat angebracht: "Geben Sie rechtzeitig auf." Das klingt hart, doch ist es das Beste für alle Beteiligten und den Projekterfolg. Das folgende Szenario erläutert, warum.

Die Ausbildung für Software-Entwickler ist im Idealfall in zwei Abschnitte aufgeteilt: Zuerst durchläuft der Entwickler eine Java-Schulung oder erhält die Zeit, eine gutes Fachbuch durchzuarbeiten. Dies genügt in der Regel für die Beherrschung der Programmiersprachen-Elemente und der Entwicklungsumgebung. Nun kann der Entwickler zwar im Prinzip "alles" programmieren - allerdings nicht objektorientiert. Daher sollte der Entwickler im zweiten Schritt einen erfahrenen Kollegen als Mentor erhalten, der jederzeit für Rückfragen zur Verfügung steht, und der sich für das Design seines Schützlings verantwortlich zeichnet.

Als Einstieg in den "Entwicklungsalltag" dient idealerweise eine übersichtliche Aufgabe, die er zuerst alleine bearbeitet und welche dann vom Mentor überarbeitet wird. Dies sollte in der Folge mit neuen Aufgaben wiederholt werden. Nach ca. sechs Wochen sollte der Projektleiter den Eindruck haben, dass der "Newcomer" wesentliche Fortschritte im Verständnis erzielt hat. Bleiben diese aus, bleiben dem Projektleiter drei Optionen: Die erste Möglichkeit ist, dem betreffenden Entwickler die Struktur seiner Programme - das Klassendesign - vorzugeben. Dies wird erfahrungsgemäß als Bevormundung und Missachtung empfunden und führt mittelfristig zu Frustration und Leistungsabfall. Eine bessere Alternative ist es, ihm eine Aufgabe zu übertragen, bei der ein objektorientiertes Verständnis keine wesentliche Voraussetzung für den Erfolg ist. Diese Aufgabe ist gut zu bewältigen und ermöglicht so eine parallele und langsame Einarbeitung in die objektorientierte Technologie. Ist diese Vorgehensweise nicht möglich, sollte der Mitarbeiter nicht in einem solchen Projekt eingesetzt werden.

Die Teamstruktur: start small...

Beim Design des Teams ist darauf zu achten, dass eine relativ kleine Gruppe von zwei bis vier Mitarbeitern die Architektur und das Gesamtdesign der Anwendung respektive des Systems festlegt. Kommunikation spielt hier eine besonders große Rolle; ein zu großes Team verliert sich leicht in endlosen Diskussionen. Liegen nun Komponentendesign und Schnittstellen fest, können einzelne Bereiche gut von weiteren Entwicklern übernommen werden. Es gilt also, zunächst mit einem kleinen Team zu beginnen und erst nach der Designphase das Team zu erweitern.

Prozessübergreifendes Verantwortungsgefühl ist unverzichtbar

Spätestens dann muss es für jeden Bereich des Systems einen Verantwortlichen geben, der die Aufgabe hat, das Design in seinem Bereich "sauber" zu halten. Ansonsten besteht die Gefahr, dass Teammitarbeiter eigenmächtig Prozeduren oder Methoden hinzufügen, die dem Klassendesign nicht gerecht werden. Prozessübergreifendes Verantwortungsgefühl ist für diese Entwickler unverzichtbar: sie sollen Fehler nicht deshalb beheben, weil sie sie selbst programmiert haben, sondern weil sie für einen Bereich verantwortlich sind. Es ist dabei unerheblich, wie diese Fehler entstanden sind.