Streitkultur

Inhaltsverzeichnis

Wo Menschen zusammenarbeiten, gibt es Reibereien aller Art. In Projekten entstehen unproduktive Auseinandersetzungen meist aus den verschiedenen Rollen der beteiligten Personen. Eine Auswahl der Fragen, über die man sich trefflich streiten kann: Wie lange und wie gründlich erhebt und beschreibt man die Anforderungen? Welche Darstellungsart ist die beste? Wann muss die Spezifikation fertig sein? Wenn sie nicht pünktlich fertig wird, was tun? Lassen sich nach Unterzeichnung des Vertrags die Anforderungen oder gar der Umfang noch ändern, und wenn ja wie? Was sind nötige Änderungen? Ist es wichtiger, das Projekt mit hohem Gewinn abzuschließen oder den Kunden glücklich zu machen?

Ein Requirements Engineer (auch wenn er vielleicht als Berater oder Business Analyst auftritt) und ein Projektleiter beschäftigen sich laut Rollendefinition zwar mit ähnlichen Themen, verfolgen aber unterschiedliche Ziele. Der Projektleiter soll das Vorhaben pünktlich abschließen, innerhalb des Budgets bleiben und den bei Vertragsunterzeichnung vereinbarten Projektumfang in einer Qualität liefern, die keine Klagen erlaubt. Um den finanziellen Rahmen nicht zu sprengen, muss das Requirements Engineering und Management (RE & M) ebenfalls möglichst effizient abgewickelt werden. Aus Sicht des Auftraggebers ist hingegen der Requirements Engineer der „Gute“, der Anforderungen kundenorientiert und in hervorragender Qualität spezifiziert, um Fehler im Entwicklungsprozess so weit wie möglich zu vermeiden.

Im Tagesgeschäft lassen sich die beiden Interessen oft nicht zur Deckung bringen. Beispielsweise dürfte der Projektleiter öfter mal einen Workshop oder eine Anforderung für unwichtiger halten als der Requirements Engineer – nicht selten ein Grund für Unmut im Projektteam.

Keine saubere Abgrenzung möglich

Es mag folgerichtig erscheinen, die Projektrollen so zu gestalten, dass sich die Protagonisten nicht in die Quere kommen. Ein spezieller Requirements Engineer könnte sich mit den Anforderungen beschäftigen, und alle anderen halten sich raus. Theoretisch reizvoll, praktisch nicht durchzuhalten. Denn die Anforderungen skizzieren schließlich das Ergebnis des Projekts. Der Vertrieb stellt sie meist schon im Vorfeld auf und reicht sie an das später installierte Team weiter. Alle Phasen bauen auf den ursprünglichen Anforderungen auf: der Entwurf, die Implementierung, die Qualitätssicherung und das Projektmanagement selbst. Alle arbeiten mit der Anforderungsspezifikation und modifizieren sie für ihre Zwecke. Und schon reden sie zwangsläufig dem Requirements Engineer (sofern es ihn überhaupt gibt) in seine Arbeit hinein oder erledigen einen Teil davon gleich selbst.

Jeder ist ein kleiner Chef

Dem Projektmanagement ergeht es nicht besser. Nicht nur der Leiter des jeweiligen Vorhabens beschäftigt sich mit Terminen und Budget, sondern auch jedes Mitglied, allerdings nur für den Teil, den es eigenverantwortlich durchführt. Jede Person in einem Team darf sich daher als kleiner Projektleiter fühlen.

Da die Arbeit aller Beteiligten miteinander verknüpft ist und sich an vielen Stellen überlappt, lassen sich ihre Rollen nicht konsequent abgrenzen. Solange die Betroffenen die zwangsläufigen Konflikte konstruktiv austragen, profitiert jedes Vorhaben von den Überlagerungen. Dieser nützliche Effekt tritt allerdings nicht ein, wenn eine Person zwei oder mehrere Rollen innehat, da die unterschiedlichen Ziele nicht auf den Tisch kommen und nicht von einzelnen Personen vertreten werden.

Und doch lassen sich Rollen so zuschneiden, dass sich das Reibungspotenzial in Grenzen hält. Man unterscheidet dabei zunächst zwischen einer Rolle und einem Fachgebiet (Abbildung 1, siehe „Alle Links“). Eine Rolle beschreibt den Teil eines Projektes, für den eine Person verantwortlich ist. Diese Konstruktion kann sich in Arbeitspaketen, -ergebnissen oder auch Tätigkeiten manifestieren. Rollendefinitionen hängen ab vom Vorgehensmodell, von der verwendeten Technik, der Struktur der Firma oder den Fähigkeiten der Mitarbeiter. Ein Fachgebiet besteht aus einer Menge von Methoden, Wissen und Erfahrung, die es einer Person ermöglichen, Ergebnisse eines bestimmten Typs zu erarbeiten. Zwischen Personen, Rollen und Fachgebieten entstehen n:m-Beziehungen: Eine Person kann mehrere Rollen einnehmen und mehrere Personen können dieselbe Rolle spielen. Eine Rolle arbeitet üblicherweise in mehreren Fachgebieten, und in jedem Fachgebiet tummeln sich mehrere Rollen.

Das Fachgebiet Requirements Engineering & Management (RE & M) umfasst die notwendigen Tätigkeiten für das Erheben, das Analysieren, das Verstehen sowie das Dokumentieren von Produkt- und Projektanforderungen. Schließlich sind Maßnahmen zum Auflösen von Unstimmigkeiten, zum Verifizieren und Validieren von Anforderungen (beispielsweise Reviews) ebenfalls ein Teil des RE & M. Das Projektmanagement (PM) hingegen spezifiziert das Anwenden von Wissen, Fähigkeiten, Werkzeugen und Techniken auf Projektaktivitäten, um die Anforderungen zu erfüllen. Dazu gehören entsprechende Managementprozesse: Planen, Durchführen, Kontrollieren und Beenden.

Unterschiedliche Aufgaben: RE und PM

Kurzum, es geht bei RE & M um das Schaffen eines gemeinsamen Verständnisses der Anforderungen und im PM um das Erstellen und Ausführen eines Plans. Daher benötigen Anforderungsmanager andere Kompetenzen als Projektleiter, ihre Ausbildung muss andere Schwerpunkte berücksichtigen. Sowohl die Termino-logie des RE & M als auch die Werkzeuge unterscheiden sich von denen des PM. Daher sollten sich diese beiden Fachgebiete, wenn möglich, auf verschiedene Rollen und Personen verteilen. Konflikte sind durch das Rollenmodell beziehungsweise die innige Verzahnung der Tätigkeiten zwar nicht auszuschließen. Es ist jedoch hilfreich, die Konfliktlinien richtig zu verstehen, sobald sie sich abzeichnen.

Agilität führtzusammen

Agile Entwicklungsmethoden können den Widerspruch entschärfen. Scrum etwa zeichnet sich aus durch Einfachheit und ein überschaubares Rollenmodell mit nur drei Rollen. Agile Methoden unterscheiden sich deutlich von den nicht agilen, sie versuchen nämlich gar nicht erst, Rollen so zu gestalten, dass sie möglichst unabhängig voneinander arbeiten können. Im Gegenteil: Das Vorgehensmodell geht grundsätzlich davon aus, dass alle Teammitglieder eng zusammenarbeiten. Sie planen gemeinsam, jeder trägt Verantwortung und sie treffen Entscheidungen kollektiv. Die Lücke zwischen den Zielen des Projektmanagements und RE & M verschwindet, wenn das Team eigenständig festlegt, was es wann und in welcher Qualität umsetzt. Alle Zugehörigen eines Scrum-Teams besetzen eine von drei Rollen:

– Der Product Owner spezifiziert und priorisiert die Anforderungen, zum Beispiel in Form von User Stories. Er stellt das Budget bereit und entscheidet im Review am Ende eines Sprints, ob die Anforderungen erfüllt sind.

– Das Entwicklungsteam kümmert sich um das Arbeitsergebnis, legt fest, wie, wie viel und in welcher Qualität gearbeitet wird. Die Gruppe agiert selbst organisiert und interdisziplinär, ohne besondere Rollenteilung. Personen mit selten gebrauchten Spezialkenntnissen lassen sich bei Bedarf hinzuholen, gehören dem Team aber nicht an.

– Der Scrum Master leitet die Teammitglieder an, unterstützt sie bei der effizienten und richtigen Durchführung des Prozesses. Er passt auf, dass Mitglieder die Regeln einhalten, räumt Hindernisse aus dem Weg und vertritt das Projekt nach außen.

Abbildung 2 zeigt, wie sich Rollen und Fachgebiete zueinander verhalten. Da sich das Entwicklerteam selbst verwaltet, arbeitet es wie der Scrum Master im Fachgebiet Projektmanagement. Solange klar ist, wer welche Arten von Entscheidungen trifft, entstehen keine Reibereien.

Arbeiten, ohne zu streiten

Da jedes Mitglied in allen Fachgebieten arbeiten können soll, treten Rollenkonflikte per definitionem nicht auf. Auch wenn das RE & M sich hier auf alle drei Rollen verteilt, ist in Scrum der Umgang mit Anforderungen grundsätzlich konfliktarm ausgelegt. Denn das Vorgehensmodell trennt klar zwischen Produkt- und Projektanforderungen sowie zwischen Spezifikation und Analyse. Der Product Owner legt alle Anforderungen fest, der Scrum Master setzt die Projektanforderungen um, der Entwickler die Produktanforderungen.

Neues kann jederzeithinzukommen

Bei den verschiedenen Ereignissen eines Sprints geht es ebenfalls entweder um Projekt- oder Produktanforderungen: Das Sprint Planning Meeting ist der Zeitpunkt, um über sie zu entscheiden, insbesondere welche Ziele man im nächsten Sprint erreichen will. Während eines Sprints bleiben diese Festlegungen grundsätzlich eingefroren, falls nichts Wesentliches dagegenspricht. Neue Anforderungen können zwar jederzeit hinzukommen, werden jedoch frühestens in der nächsten Runde umgesetzt. Im Daily Scrum Meeting synchronisiert das Entwicklungsteam seine Tätigkeiten und schätzt den Fortschritt gemessen am Ziel eines Sprints ab. Im Review entscheidet der Product Owner, ob die Produktanforderungen erfüllt sind, und in der Retrospektive untersucht das Team den Projektverlauf und hält fest, was sich künftig im Arbeitsprozess verbessern lässt.

Um rollenbedingte Konflikte zu vermeiden, gibt es also grundsätzlich zwei entgegengesetzte Ansätze:

– Man verteilt die Aufgaben so auf die verschiedenen Rollen, dass sie sich in möglichst wenigen Fachgebieten in die Quere kommen. Die Verantwortlichen müssen alle Überschneidungen sichtbar machen und durch Absprachen entschärfen.

– In der agilen Entwicklung akzeptiert man die starke gegenseitige Abhängigkeit sämtlicher Projektaktivitäten als gegeben. Alle Beteiligten müssen viel miteinander reden, damit keine Missstimmung entsteht. Grundsätzlich ist jeder für alle Aspekte eines Vorhabens verantwortlich.

Jedoch darf oder möchte nicht jeder Scrum praktizieren. Daher ist es wichtig, das persönliche Rollenmodell zu überprüfen und gegebenenfalls übersichtlicher zu gestalten. Selbstverständlich sind Rollen in anderen Vorgehensmodellen – auch in linearen – ebenfalls sauber abgrenzbar. Falls es trotzdem zu Auseinandersetzungen kommt, gilt: Ruhe bewahren. Untersuchen sollte man zunächst, ob sich im selben Fachgebiet mehrere Personen gegenseitig stören. Solche durch Rollen ausgelösten Konflikte lassen sich leicht durch das präzise Abstecken von Arbeitspaketen eindämmen.

Dr. habil. Andrea Herrmann

ist freiberufliche Software-Engineering-Trainerin und -Forscherin sowie Privatdozentin an der Universität Heidelberg.

Dr.-Ing. Eric Knauss

forscht und lehrt im Bereich Software Engineering, derzeit an der University of Victoria, Kanada.

Uwe Valentini

ist Senior Consultant für Systems und Software Engineering bei der HOOD Group.

Dr. Rüdiger Weißbach

ist Professor für Wirtschaftsinformatik am Department Wirtschaft der Hochschule für Angewandte Wissenschaften Hamburg.

Literatur

[1] Andrea Herrmann, Eric Knauss, Rüdiger Weißbach (Hg.); Requirements Engineering und Projektmanagement; Springer Verlag, Berlin 2013

Alle Links: www.ix.de/ix1308112 (jd)