Agile RE Blog 2: Das Ökosystem des Projekts

Im letzten Blog haben wir den Kontext aufgebaut und das Requirements Engineering ist in dem Kontext positioniert. Es ist geklärt, welche Aufgaben Requirements Engineering hat: Taktisch die RICHTIGEN Produkt zum RICHTIGEN Zeitpunkt für Markt definieren im Produktportfolio und die detaillierte wirtschaftliche Ausarbeitung der Eigenschaften des RICHTIGEN Produkts – unter Beachten der organisatorischen und technischen Randbedingungen – in Projekten als operative Ebene der Organisation.

Nun ist noch in keinem Satz das Wort „AGIL“ vorgekommen. Es wird also Zeit sich diesem Punkt zu nähern.

Dazu möchte ich die kleinere Einheit an, das Projekt unter die Lupe nehmen. Ich gehe davon aus, dass es das Produkt schon gibt, was wohl der Regelfall sein wird. Das Projekt dient also der Überführung des bestehenden Zustandes des Produkts in den neuen Zustand des zu DIESEM ZEITPUNKT RICHTIGEN Produkts.

Bei einem Projekt handelt es sich um ein zeitlich begrenztem Ökosystem, das ein mehr oder weniger klar definiertes Ziel (eine Vision) erreichen will (in die Realität umsetzen will). Umgangssprachlich bedeutet dies: Ein Team von Leuten arbeitet an einem Produkt, welches einer oder mehreren Benutzergruppen anschließend zur Nutzung übergeben wird. Das Team, welches das Produkt erstellt, ist in einem sozialen Kontext in die Umgebung eingebunden, in der das Produkt geschaffen wird. Dieser soziale Kontext hat eine enge Wechselwirkung auf das Team und somit auch auf das Ergebnis des Teams, also dem Produkt. Mit einem Wort, das Team und die Einbettung des Teams im Kontext der Organisation (mit Kunden, mit Abteilungen wie Marketing oder Operations oder dem Chef selbst) spielt eine große Rolle für eine erfolgreiche Projektarbeit.

Nun ist es eine Aufgabe des Requirements Engineering diesen Kontext zu untersuchen und die Wechselwirkungen zwischen dem zu schaffenden Produkt und dem Kontext herauszufinden. Das hilft und die RICHTIGEN Eigenschaften im Detail zu erkennen und – über Beachten der Randbedingungen – den TCO zu erhöhen. Im Requirements Engineering werden dazu Stakeholder abgeholt, andere Informationsquellen angezapft und alles miteinander verknüpft und vernetzt und es muss damit umgegangen werden, dass sich das Ziel des Projekts (die Vision) während dem Arbeiten verändert.

Nach allgemeiner Auffassung der Forschung [Dir2011] entsprechen diese Eigenschaften (viele Stakeholder, viele Informationsquellen, viele Abhängigkeiten, moving Target) der Definition eines komplexen Problems. Abstrakt formuliert beschäftigt sich ein Projekt mit dem Lösen einer komplexen Problemstellung (siehe Abbildung 3). Dazu kann nach allgemein annerkannter Auffassung der Forschung [Dir2011] kein mechanisches Fertigungsverfahren eingesetzt werden, wie zum Beispiel zum Herstellen von Hamburgern (Brötchen, Hackfleisch, Majo, Ketchup, Gurke, Salat in definierten Arbeitsschritten zusammen pappen). Um eine komplexe Problemstellung zu lösen bedarf es Wissensarbeiter, die in einer möglichst effizienten Art und Weise zusammenarbeiten und mit Wissen arbeiten beziehungsweise sich Wissen erarbeiten.

 

Abbildung 3: Produkte über Projekte erstellen und verbessern bedeutet das Lösen eines komplexen Problems

Um das Produkt von einem Zustand in den nächsten Zustand zu überführen, wird also Wissen benötigt und es werden Fähigkeiten benötigt, das Wissen zu erarbeiten und mit dem Wissen zu arbeiten. Wesentliche Teilaspekte des Wissens sind hierbei:

1. Das Wissen um die Eigenschaften und Fähigkeiten, welche die aktuelle Version des Produkts besitzt und das Wissen um die Eigenschaften und Fähigkeiten, welche das neue Produkt in Zukunft besitzen soll è Produktwissen also
2. Das Wissen und die Fähigkeiten, wie das Produkt entwickelt wird und produktiv gesetzt wird è das Wissen, um das Vorgehensmodell, also Prozesswissen.

Mit den Eigenschaften und Fähigkeiten des Produktes an sich beschäftigt sich genau das „Hilfsmittel“ Requirements Engineering. Wesentlich für einen Projekterfolg sind jedoch ebenso die Fähigkeiten, WIE das Produkt entwickelt wird, also auch WIE das Hilfsmittel Requirements Engineering eingesetzt wird. Beide Aspekte spielen untrennbar zusammen.

Eine wesentliche Eigenschaft der Wissensarbeit zum Lösen einer komplexen Problemstellung ist, dass bei Start eines Projekts das Wissen noch nicht vollständig, oft sogar nur sehr rudimentär vorhanden ist – was genau ein Problem zu einem komplexen Problem macht. Das Projektteam besitzt in keinem Fall das volle Wissen über die Eigenschaften und Fähigkeiten des zukünftigen Produkts, sondern nur eine mehr oder weniger klar umrissene Vorstellung davon. Es ist ja gerade Aufgabe des Requirements Engineering dies im Projekt zu präzisieren. Das Projektteam besitzt jedoch genauso wenig das volle Wissen, wie das Produkt entwickelt wird, da die Stakeholder eventuell unbekannt sind (wie sollen wir also mit diesen zusammen arbeiten), ebenso wie das Testen (was können wir Automatisieren und wo brauchen wir noch den Mensch im Testen), aber auch der Vorgang des Deployments und viele andere Details. Zudem ändert sich alles dies auch noch im Verlauf der Projektarbeit.

Abbildung 4: Das Ökosystem Projekt löst das gestellte Problem wirtschaftlich

Ganz allgemein kann gesagt werden, dass am Anfang eines Projekts das Wissen nicht ausreichend geschweige denn vollständig vorhanden ist und vom Team erst erfahren und gelernt werden muss. Das notwendige Wissen, um das Problem des Projekts zu lösen, hat erhebliche Lücken in jeder Hinsicht. Eine wesentliche Aufgabe eines Projektteams ist es diese Wissenslücken zu füllen. Das gilt für Lücken im Domänenwissen, ebenso wie für fachlich- technisches Wissen und für das Prozesswissen.

Das klingt alles so Abstrakt, also möchte ich hier ein paar Beispiele aus meiner persönlichen Erfahrung wiedergeben (anonymisiert):

In einem Projekt erstellte unser Team ein Planungssystem für Zugfahrten. Zum Domänenwissen gehört zum Beispiel dass die im Kursbuch stehenden Zeiten für Ankunft und Abfahrt nur für den Bahnkunden relevant sind. Intern, im Führerstand der Lokomotive zum Beispiel gelten durchaus andere Zeiten, die im sogenannten technischen Fahrplan für den Lokomotivführer stehen. Nur wenige alte Hasen im Projektteam hatte vor dem Projekt überhaupt eine Ahnung, dass es hier unterschiedliche Sichten gibt. Erst das Arbeiten mit den Fachleuten brachte diese Erkenntnis für alle.

Technisches Wissen beschäftigt sich zum Beispiel mit der Build- und Deployumgebung, also mit dem Stagingprozess eines Produkts bis es schließlich für die Produktion freigegeben ist. Eine internationale Bankingsoftware muss für jedes Land durch die Abnahmetests der dort geltenden gesetzlichen Regelungen gejagt werden, bevor die Software dort die Freigabe zur Produktion erhält. Ich wusste zum Beispiel lange Zeit nicht, dass unter anderem gefordert werden kann, dass gewisse Daten physikalisch in einem Land abgespeichert sein müssen, also zum Beispiel nicht in einer Amazon Wolke sein können, die irgendwo schwebt. Die Durchführung von Abnahmetests muss die Verfügbarkeit von Testdaten berücksichtigen.

Organisatorisches Wissen setzt dem Projekt Randbedingungen, in welchem die Entwicklung abläuft. Bei einem bestimmten Kunden zum Beispiel darf ein Projekt aus organisatorischen Gründen erst mit einer neuen Phase anfangen zu arbeiten, wenn die vorhergehende Phase in einem offiziellen Review als erfolgreich abgenommen gilt. Ich habe es selbst erlebt, dass Projekte in der Review Phase zu zwei Wochen Stillstand verurteilt waren. Das war mir bei Start des Coaching eines Projektteams in dieser Organisation nicht bewusst und – ganz ehrlich – ich hätte es vorher auch nie geglaubt. Dieser Fall ist schon ein Hinweis für mögliche Ansatzpunkte von mehr Agilität.

Fassen wir die bisherigen Erkenntnisse zusammen:

1. Das Ziel einer Organisation ist es das RICHTIGE Produkte zum RICHTIGEN Zeitpunkt herzustellen
2. Ein Produkt oder die bessere Version des Produkts wird über ein Projekt erstellt
3. Ein Projekt ist ein soziotechnisches Ökosystem
4. Ein Projekt startet mit einem komplexen Problem zu dessen Lösung sich das Projektteam Wissen erarbeiten muss, da Wissenslücken jeder Art vorhanden sind.
5. Das Wissen fällt in die beiden Kategorien:
   a. Wissen WIE das Produkt gebaut werden soll, das Prozesswissen
   b. Wissen, WAS das Produkt können soll, hierzu setzen wir als Hilfsmittel Requirements Engineering ein

Dieser Blog hat uns also die Erkenntnis gebracht, dass Projektarbeit Wissensarbeit ist. Ein Projektteam ist eigentlich eine Art Lerngruppe. Ein Projektteam ist dann erfolgreich, wenn es sich effizient die richtige Menge Wissen erarbeitet und dieses effizient zum Bau des Produktes einsetzt.