Teambuilding-Konzepte für verteilte Teams

APIs, der digitale Klebstoff – damit verbinden wir Komponenten oder Systeme zu einem Ganzen, sind Cloud-aware, flexibel, skalierbar, modular. Durch das Angebot gut dokumentierter Programmierschnittstellen (API) kann unsere Software einen erheblichen Wettbewerbsvorteil für sich verbuchen, wenn Skalierung durch teamfremde (ggf. externe) Entwickler realisierbar ist.

Soweit, so gut. Schaut man hinter die Kulissen auf die Akteure, so haben wir es oft mit „virtuellen Teams“ zu tun. Synonyme gefällig? Gerne: „verteilte Teams“, „Homework“ oder „Telearbeit“. Wenn wir aber eines aus den agilen Werten und Prinzipien gelernt haben, dann sind Kommunikation und Nähe zwischen den Akteuren die Ausgangspunkte erfolgreicher Projekte. Technologien, wie APIs, die eine Verteilung unterstützen, sind generell neutral – aber es kommt darauf an, wie man den damit verbundenen Herausforderungen begegnet. Klar, je weiter entfernt die Menschen von einander arbeiten, sei es aus Sicht der Örtlichkeit, der Zeitzonen, der Kultur, der Sprache – die Kommunikation wird bei verteilten Teams bedeutend schwieriger und ja, die zwischenmenschliche Nähe leidet besonders.

Teambuilding – mehr als nur  gemeinsam auf ein Bier

Was ist falsch am gemeinsamen Bier? Vordergründig: Nichts, passt gut und gehört klarerweise dazu! Ich werde selbst nach Jahren immer wieder zu einem gemeinsamen Bier mit ehemaligen Kollegen eingeladen und nutze diese Gelegenheiten sehr gerne :-). Aber mal ehrlich: Worüber spricht man beim gemeinsamen Bier? Den Projektstatus und Co. Wenn’s gut läuft, dann redet man auch über Fußball und/oder über’s Kino, weil man eben neben der gemeinsamen Arbeit auch noch andere Interessen teilt. Auf den zweiten Blick wird aber klar, dass man sich kaum über sich, das Team selbst, unterhält. Vergessen wir nicht: Jedes Team, egal ob co-located oder verteilt auf den ganzen Planeten, macht nach -> Bruce Tuckman initial oder nach Teamänderungen mehr oder weniger intensiv die vier Phasen „Forming“, „Storming“, „Norming“ und „Performing“ durch.

Teambuilding-Phasen nach Tuckman

Teambuilding-Phasen nach Tuckman

Es macht sich bezahlt in diesen Teambuilding-Prozess aktiv einzugreifen und dabei zu helfen, das Team in die nächste Phase zu heben. Eine in meiner Praxis bewährte Methode sind teaminterne Diskussionen, unterstützt z.B. durch Metaplantechniken, in denen sich das Team zu folgenden Fragen austauscht:
    • Was erwarte ich – an Prozessen und Rahmenbedingungen?
    • Was kann ich einbringen – an Programmiersprachen, Requirements Engineering Techniken, im Test, etc.?
    • Wie sollten wir miteinander umgehen – Klärung zu Aspekten wie Fehlerkultur, Offenheit, usw.
Performing Team

Performing Team

Es hilft auch, wenn man den Team’s Vorträge über Konfliktbewusstsein anbietet oder auch in diesem Kontext auf Retrospektiven setzt: Nicht nur prozessual und arbeitstechnisch sich zu fragen, was läuft gut und „was wollen wir verbessern“, sondern auch nochmals einen Blick auf die Metaplan-Antworten und checken, ob das auch noch passt.

Für bewusstes Teambuilding muss man die Teambuilding-Phasen bewusst machen und Aktivitäten setzen, die die Team-Irritationen so gering wie möglich halten.

In einem Projekt vor einiger Zeit hatten wir z.B. immer bei Abstimmung- und Planungsterminen auch die Frage: „Wie geht es uns als Team?“ Ein fortschrittlicher Ansatz, wie gesagt, auch schon vor einiger Zeit gelebte Praxis.

Physical closeness -> Mental closeness
Eine weitere Methode um „Nähe“ zwischen den Teammitgliedern herzustellen, habe ich von Jürgen Apello („How to Improve Team Collaboration with Personal Maps“1) gelernt: Er empfiehlt verteilten Teams die Erstellung von sogenannten Personal Maps. Jeder erstellt eine Mindmap über sich selbst und thematisiert darin Hobbies, Ausbildung und weiteres Wissenswertes über sich. Im Anschluss stellt jeweils ein Teammitglied ein anderes auf Basis der Personal Map vor. Er adressiert damit eine mentale Nähe zwischen den Teammitgliedern …

Wir bei SEQIS stehen ebenfalls vor der Herausforderung, dass die einzelnen (organisatorischen) Teams bei jeweils unterschiedlichen Kunden im Einsatz sind – und trotzdem soll und muss der Teamspirit passen und die Zusammenarbeit in den Teams stimmen. Daher haben wir diese Methode bei unserem letzten 4-tägigen Geschäftsjahres-KickOff -Meeting im Selbstversuch ausprobiert. Im Gegensatz zu einer Skype-Session konnten wir das in einem gemeinsamen Meeting-Saal machen. Den konkreten Setup können Sie beiliegender Abbildung entnehmen. Ergebnis: This rocks – und wurde von nahezu allen SEQISANERN im Rahmen des Gesamtfeedbacks zum Treffen thematisiert.

Personal Map - Setup

Personal Map – Setup

Das war noch nicht alles…
Neben den oben stehenden Empfehlungen nachfolgend noch eine Sammlung zur Verbesserung der Kommunikation und zur Förderung von Nähe bei verteilten Teams und Teammitgliedern, die in meinen Projekten funktioniert haben:

  • Definition einer Team Charter (= Teamroadmap, Absicherung, dass alle auf das Richtige fokussiert sind) inkl. Rollen, Verantwortlichkeiten, Ziele und Art-und-Weise, wie gearbeitet wird
  • Strenge Kommunikationsstrategie: Besonders wichtig, wenn das Team in unterschiedlichen Zeitzonen beheimatet ist und unterschiedliche Sprachen spricht
  • Ordentlicher technischer Support: Videokonferenzen, Instant Messaging, VoIP, … sind super, wenn sie auch wirklich funktionieren
  • Genaue Beobachtung der Individual-Performance: Bei Veränderung des Outputs, geringerer Mitarbeit, etc. kann auch im Hintergrund ein Burnout oder anderes lauern. Denken Sie daran: Sie sehen die Kollegen nicht, nonverbale Kommunikation fällt nahezu flach
  • Schaffen Sie Raum für Gemeinsames: Setzen Sie eine Intranet-Teampage auf, verwenden Sie ggf. Webcams
  • Vergessen Sie nicht auf Feedback: Ein Kollege hat ins Projekt-Social Network einen interessanten Artikel gepostet? Geben Sie Feedback!
  • Belohnen Sie außergewöhnliche Leistungen: Etablieren Sie teaminterne Punkte-/Leistungssysteme und vergessen Sie nicht darauf, dass physische Belohnungen gerne durch Post und Co. rund um den Planeten geliefert werden

… diese Liste ist natürlich nicht abschließend!

Haben Sie weitere Empfehlungen? -> Ich freue mich auf Ihre Kommentare!

Systemanalyse 3.0 – Glossar

Glossar

  • Analysieren: eines der drei Basis-Elemente in Systemanalyse 3.0; das Arbeitsgebiet wird in die Primären Analyse-Elemente zerlegt, die anschließend in ein System gebracht werden, das das Design der Lösung darstellt
  • Anforderung: Aussage eines Stakeholders über eine benötigte Eigenschaft der Lösung; Ausdruck eines Bedarfs
  • Arbeitsgebiet: Bereich, in dem der Bedarf aufgetreten ist, der zur Systemanalyse geführt hat, in den meisten Fällen ein betrieblicher Teilbereich
  • Bedarf: Auslöser der Systemanalyse; erforderliche Änderung in einer Organisation
  • Basis-Elemente: Analysieren – Kommunizieren – Produzieren; die Grundbestandteile von Systemanalyse 3.0
  • Design: Darstellung der Lösung in Form von Text und Modellen
  • Kommunizieren: eines der drei Basis-Elemente in Systemanalyse 3.0; die Lösungs-Hypothese wird mit den Stakeholdern abgestimmt
  • Lösung: das Ziel der Systemanalyse; entwickelt sich aus der Lösungs-Hypothese; wird durch das Design dargestellt
  • Lösungsorientierte Analyse: eine Analyse-Methode, bei der die Lösung von Anfang an im Zentrum steht
  • Lösungs-Hypothese: die aktuelle Vorstellung, die der Systemanalytiker über die Lösung hat; ist während des Analyse-Prozesses einer stetigen Änderung unterworfen
  • Makro-Prozess der Systemanalyse: Zusammenstellung von Mikro-Prozessen zu einem Gesamtprozess
  • Mikro-Prozess der Systemanalyse: Zusammenstellung der Basis-Elemente zu einem Prozess
  • Primäres Analyse-Objekt: Element, in das ein Arbeitsgebiet bei der Analyse zerlegt wird
  • Primäres Daten-Analyse-Objekt: Element, in das ein Arbeitsgebiet in der Datensicht zerlegt wird; ist in Systemanalyse 3.0 das „Informationsobjekt“, das auch „Klasse“ oder „Entität“ genannt wird
  • Primäres Funktions-Analyse-Objekt: Element, in das ein Arbeitsgebiet in der Funktionssicht zerlegt wird; ist in Systemanalyse 3.0 die „Transaktion“
  • Produzieren: eines der drei Basis-Elemente in Systemanalyse 3.0; die in der Analyse ermittelte Lösung wird in den Artefakten festgehalten
  • Stakeholder: Person, die von einer Lösung betroffen ist
  • Transaktion: eine Summe von zusammengehörenden Tätigkeiten, die eine Einheit bilden und in der Regel von einer IT-Funktion unterstützt werden; Transaktionen sind das Primäre Funktions-Analyse-Element; aus Transaktionen werden die Prozesse zusammengesetzt
  • Waste: ein Begriff aus den agilen Methoden; Tätigkeiten und Dokumente, die während des Analyse- und Entwicklungsprozesses ausgeführt bzw. erstellt werden, die aber keinen sinnvollen Beitrag zur Lösung liefern. Diese sind nach Möglichkeit zu vermeiden

 

Systemanalyse 3.0 – Literatur

Literatur

 

[BABOK2015] Business Analysis Body of Knowledge, Version 3.0, IIBA, 2015

[GERSTBACH2015] Gerstbach, Ingrid, Peter: Basiswissen Business-Analyse, Redline 2015

[HEAP2013]  Heap, Tony: There’s no such thing as a requirement; http://www.its-all-design.com/theres-no-such-thing-as-a-requirement/

[HRUSCHKA2014] Hruschka Peter: Business Analyse und Requirements Engineering, Hanser 2014

[IIBA] International Institute of Business Analysis, http://www.iiba.org

[IREB] International Requirements Engineering Board, http://www.ireb.org

[KONNERTH] Konnerth, Tania: Der kreative Prozess; http://www.zeitzuleben.de/2452-kreativitat-was-ist-das-eigentlich/2/

[KRALLMANN2013] Krallmann, Hermann; Trier, Mathias: Systemanalyse; http://www.enzyklopaedie-der-wirtschaftsinformatik.de/wi-enzyklopaedie/lexikon/daten-wissen/Informationsmanagement/Information-/System/Systemanalyse

[ROBERTSON2013] Robertson, Suzanne, James: Mastering the Requirements Process, Addison Wesley 2013

[VOLERE] Das VOLERE-Requirements-Portal; http://www.volere.de

Systemanalyse 3.0 – Kapitel 3

Kapitel 3 – Die Quellen

(In dem wir vorstellen, was die Quellen von Systemanalyse 3.0 sind und wo die Gemeinsamkeiten und Unterschiede liegen)

Systemanalyse 3.0 – das ist nicht die Neuerfindung des Rades. Auf der Basis des Verständnisses eines Arbeitsgebiets Lösungen entwickeln – das gehört seit jeher zum Handwerkszeug in der Software-Entwicklung. Systemanalyse 3.0 bringt jedoch verschiedene Ansätze unter ein gemeinsames Dach. Verschiedene Konzepte werden neu kombiniert, sodass letztlich doch etwas Neues entsteht.

In diesem Kapitel werden die Grundzüge der einzelnen Quellen dargestellt, es wird diskutiert, inwieweit deren Konzepte in Systemanalyse 3.0 eingehen – und worin sie sich von Systemanalyse 3.0 unterscheiden. Dadurch wollen wir die Grundlage dafür legen, dass in den Folgekapiteln die Vorgehensweise in Systemanalyse 3.0 näher dargestellt werden kann.

Folgende Konzepte und Methoden werden im Folgenden behandelt:

  • klassische Systemanalyse
  • Business Analyse
  • Requirements Engineering
  • Agile Softwareentwicklungs-Methoden
  • Kreativitätsprozess.

Systemanalyse

Bis etwa zum Jahr 2000 war „Systemanalyse“ auch die gängige Bezeichnung für die „frühen Phasen“ in einem Software-Projekt. Zu diesem Zeitpunkt kam es in der Disziplin des Projektmanagements zu Standardisierungsbestrebungen. Damit verbunden war die Möglichkeit, sich auf diese Standards zertifizieren zu lassen.

Diese Möglichkeit sollte auch für Systemenalytiker geschaffen werden und so entstanden – quasi als Abspaltung von der Systemanalyse – die Disziplinen der Business Analyse und des Requirements Engineering.

Systemenalyse 3.0 greift die Tradition der Systemanalyse wieder auf und integriert dabei die neuen Entwicklungen der Business Analyse und des Requirements Engineering.

Inhalt

„Die Systemanalyse ist ein systematischer und systemischer Ansatz zur modellbasierten Analyse eines Unternehmensbereichs. Dabei werden für eine definierte Problemstellung im Kontext der Wirtschaftsinformatik, wie z. B. Anforderungsanalyse, Softwarekonzeption, Prozessverbesserung, Umstrukturierungen, Anforderungen an eine Lösungsgestaltung definiert oder eine Lösung im Sinne einer Intervention gestaltet.“ [KRALLMANN2013]

Auch in der klassischen Systemanalyse geht es also um die Analyse von definierten Problemstellungen und um die Gestaltung von Lösungen dafür.

Es gibt eine Reihe von Beschreibungen des Prozesses in der Systemanalyse, die sich jedoch alle rund um die Schritte „Istanalyse“ und „Sollkonzept“ gruppieren. Das gilt auch für den in Abbildung 1 dargestellten Prozess.

systemanalyse_prozess

Abbildung 1: Prozess der Systemanalyse

Nach dem Schritt „Projektbegründung“, in dem das Projekt gestartet wird, wird der aktuelle Zustand des Arbeitsgebietes aufgenommen und analysiert. Auf diesem aufbauend wird das zukünftige System entworfen – es wird ein „Sollkonzept“ erstellt. Dieses wird im Anschluss realisiert, d. h. konkret, es wird die Software entwickelt. Unter Implementierung wird dann schließlich die Inbetriebnahme des neuen Systems verstanden.

Systemanalyse und Systemanalyse 3.0

Das hier dargestellte Konzept der Systemanalyse 3.0 hat mit der klassischen Systemanalyse nicht nur den Namen gemeinsam. Auch der Inhalt, dass auf Basis des Problemverständnisses eine Lösung (oder auch mehrere Lösungen) für eine Problemstellung gefunden werden soll, findet sich sowohl in der klassischen Systemanalyse als auch in Systemanalyse 3.0.

Und doch gibt es auch folgende Unterschiede:

  • Realisierung und Implementierung liegen nicht im Aufgabenbereich von Systemanalyse 3.0. Die Lösung ist zwar das Hauptziel von Systemanalyse 3.0 – die Aufgabe endet aber bei der Konzeption der Lösung. Die Implementierung einschließlich der Konzeption der System-Architektur liegt nicht im Kompetenzbereich von Systemanalyse 3.0.
  • Die Analyse des Ist-Systems („Ist-Analyse“) kann ein bedeutender Schritt für das Verständnis des Arbeitsgebiets sein und hat dadurch auch einen Platz in Systemanalyse 3.0. Es wird aber immer auch Situationen geben, wo das nicht erforderlich ist. Deshalb ist die „Istanalyse“ kein eigener Punkt in der Beschreibung von Systemanalyse 3.0.
  • Der Prozess in Abbildung 1 ist ein typisches Beispiel für die „Wasserfall“-Vorgehensweise – zuerst Projektbegründung, dann Istanalyse, dann Sollkonzept, dann Realisierung, dann Implementierung. Systemanalyse 3.0 bekennt sich zum agilen Paradigma, wie es durch das Agile Manifest ausgedrückt wird.
  • Systemanalyse 3.0 legt einen deutlicheren Schwerpunkt auf das Finden der Lösung – insbesondere auf die Kreativität, die dafür erforderlich ist.

Business Analyse

Begriff und Inhalt der Business Analyse sind untrennbar mit dem „International Institute of Business Analysis“ (IIBA) verbunden. Das IIBA wurde 2003 in Toronto gegründet und hat sich folgende Aufgabenstellungen gesetzt:

  • Förderung der Wahrnehmung und Anerkennung des Berufsbilds des Business Analysten
  • Schaffung eines Standards für die Business Analyse durch Herausgabe des Business Analysis Body of Knowledge (BABOK-Guide)
  • Förderung der öffentlichen Anerkennung qualifizierter Business Analysten durch international anerkannte Zertifikate.
Inhalt

Mit dem BABOK-Guide hat das IIBA einen anerkannten Standard für die Business Analyse geschaffen. Der BABOK-Guide (Version 3) definiert den Inhalt der Business Analyse durch die Beschreibung von Tasks, die zu sechs Wissensgebieten (Knowledge Areas) zusammengefasst werden:

  • Business Analysis Planning and Monitoring: In diesem Wissensgebiet geht es darum, festzulegen, welche Inhalte der Business Analyse-Prozess haben wird. Es regelt die Identifikation der Stakeholder, die Auswahl von Business Analyse-Techniken, den Prozess für die Verwaltung der Anforderungen und die Messung des Arbeitsfortschritts.
  • Elicitation and Collaboration: beschreibt, wie die Business Analysten mit den Stakeholdern zusammenarbeiten, um deren Bedarf zu identifizieren und zu verstehen.
  • Requirements Life Cycle Management: beschreibt, wie der Business Analyst Anforderungen während ihres Lebenszyklus behandelt, wie die Anforderungen verfolgt, verwaltet und priorisiert werden.
  • Strategy Analysis: beschreibt, wie Business Analysten einen Bedarf identifizieren und davon eine Strategie ableiten.
  • Requirements Analysis and Design Definition: beschreibt die Modellierung der Anforderungen und wie die Anforderungen in ein Design übergeführt wird.
  • Solution Evaluation: beschreibt, wie Business Analysten Lösungen bewerten und wie deren Beitrag zum Geschäftswert gesteigert wird.

Mit diesen Wissensgebieten wird kein Prozess festgelegt. Vielmehr bieten sie ein Framework, das individuell in einem Vorhaben verwendet werden kann. Die Zusammenhänge der Wissensgebiete sind in Abbildung 2 dargestellt.

babok_knowledge_areas

Abbildung 2: Wissensgebiete in der Business Analyse (Quelle: Business Analysis Body of Knowledge, V3.0)

Business Analyse und Systemanalyse 3.0

Die Business Analyse, wie sie im BABOK-Guide dargestellt ist, ist die Basis für Systemanalyse 3.0. Es wird allerdings ein besonderer Schwerpunkt auf den IT-Kontext gelegt, sodass man Systemanalyse 3.0 als „Business Analyse im IT-Kontext“ bezeichnen kann.

Darüber hinaus gibt es einige weitere Besonderheiten in Systemanalyse 3.0:

Die Wissensgebiete und Aufgaben des BABOK-Guide sagen sehr wenig über den Weg aus, wie ein Business Analyst Lösungen, wenn möglich originelle Lösungen, findet. Es steht hier viel über das Finden der Anforderungen und über das Bewerten der Lösungen, aber kaum etwas über die Lösungsfindung. Durch Integration des Kreativitätsprozesses versucht Systemanalyse 3.0, dieses Manko zu beheben.

In der Version 3.0 des BABOK-Guides wird in einer der so genannten „Perspektiven“ auf Agile Softwareentwicklungs-Methoden eingegangen. Außerdem wurde vom IIBA eine „Agile Extension to the BABOK-Guide“ herausgegeben. Systemanalyse 3.0 baut die Ideen aus dem Agilen Manifest direkt in sein Vorgehensmodell ein.

Requirements Engineering

Es war ein langer Prozess, der die Anforderungen mehr und mehr ins Zentrum der Systemanalyse rückte und schließlich auch eine eigene Disziplin begründete – das Requirements Engineering. Die ersten diesbezüglichen Veröffentlichungen reichen bis in die 70er-Jahre zurück. Zu einem regelrechten Boom kam es nach der Jahrtausendwende. In diese Zeit fällt auch die Gründung des „International Requirements Engineering Boards“ (IREB), das sich ebenso wie das IIBA in Sachen Business Analyse für eine Standardisierung einsetzt und Zertifizierungen für Ausübende dieser Disziplin anbietet.

Inhalt

Das „International Requirements Engineering Board“ (IREB) hat mit seiner Zertifizierung zum „Certified Professional in Requirements Engineering“ (CPRE) einen de-facto-Standard im Requirements Engineering geschaffen. Die Inhalte sind in den entsprechenden Lehrplänen abgebildet.

Der IREB-Lehrplan sieht folgende Hauptaktivitäten im Requirements Engineering:

  • Ermitteln der Anforderungen
  • Dokumentieren der Anforderungen
  • Prüfen/Abstimmen der Anforderungen
  • Verwalten der Anforderungen.
Requirements Engineering und Systemanalyse 3.0

Die Anforderungen sind eine wichtige Grundlage für jede IT-Lösung – wenn nicht sogar die wichtigste. Das ist auch in Systemanalyse 3.0 so. Die Wege, wie man zu diesen kommt, sind in Systemanalyse 3.0 die gleichen wie im Requirements Engineering. Es gibt also große Gemeinsamkeiten.

Der wesentliche Unterschied besteht aber darin, dass in der Systemanalyse 3.0 das Design der Lösung explizit als Aufgabe gesehen wird, ja als eigentliches Ziel aller Bemühungen. Die Tätigkeit endet also nicht mit der Erhebung und Dokumentation der Anforderungen, eigentlich beginnt sie damit erst.

In Systemanalyse 3.0 sind die Anforderungen nur insofern von Bedeutung, als sie wichtig für das Verständnis des Arbeitsgebietes sind – und unter Umständen auch in die Lösung eingehen. Das tun sie dann, wenn der Systemanalytiker nicht einvernehmlich mit dem Stakeholder eine Alternative für die Anforderung findet, die den eigentlichen Bedarf des Stakeholders in besserer Art und Weise deckt.

Die von den Stakeholdern genannten Anforderungen werden festgehalten, damit sie nicht verloren gehen. Ein darüber hinaus gehendes „Management“ oder „Engineering“ der Anforderungen wird im Allgemeinen nicht erforderlich sein. Das „Engineering“ gilt der Lösung – und nicht den Anforderungen.

Wobei hier jedoch nicht bestritten werden soll, dass es durchaus auch Situationen gibt, wo die Ermittlung der Anforderungen im Zentrum steht. Ein Beispiel dafür ist die Erstellung von Ausschreibungsunterlagen, wo es zunächst gar nicht darum geht, eine Lösung zu entwickeln, sondern wo ein Lieferant gefunden werden soll, dessen Produkt die ermittelten Anforderungen erfüllt. In diesem Fall sind Anforderungen tatsächlich das Endprodukt der Arbeit des Systemanalytikers.

Agile Software-Entwicklung

Systemanalyse 3.0 ist Business Analyse im IT-Kontext. Und man kann nicht über Analyse im IT-Kontext sprechen, ohne auch über Agile Softwareentwicklungs-Methoden zu sprechen, die vor über zehn Jahren ihren Siegeszug angetreten haben. Die Agilen Methoden haben den Softwareentwicklungs-Prozess erfolgreich und unwiderruflich verändert.

Auf Basis des Agilen Manifests, das im Jahr 2001 veröffentlicht wurde, hat sich eine Reihe von konkreten Agilen Methoden entwickelt, die alle in gewisser Weise Auswirkungen auf die Arbeit des Systemanalytikers haben.

Inhalt

Hier sollen nicht die einzelnen Agilen Methoden behandelt werden. Vielmehr soll deren gemeinsame Grundlage – nämlich das besagte Agile Manifest aus dem Jahr 2001 dargestellt werden.

In der Agilen Softwareentwicklung schätzt man:

  • Individuen und Interaktionen mehr als Prozesse und Werkzeuge
  • Funktionierende Software mehr als umfassende Dokumentation
  • Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung
  • Reagieren auf Veränderung mehr als Befolgen eines Plans.

Zu beachten ist, dass auch die Werte auf der rechten Seite wichtig sind, die Werte auf der linken Seite werden jedoch höher eingeschätzt.

Kennzeichen aller Agilen Methoden ist es auch, einen Gegensatz zum so genannten Wasserfall-Modell der Software-Entwicklung zu bilden. Durch den Einsatz von iterativ-inkrementellen Vorgehensweisen soll die notwendige Flexibilität erreicht werden, um auf sich ändernde Anforderungen schnell und adäquat reagieren zu können.

Agile Methoden und Systemanalyse 3.0

Systemanalyse 3.0 ist neutral in Bezug auf die Vorgehensweise in der Software-Entwicklung. Der Prozess ist skalierbar und kann gleichermaßen für traditionelle und für Agile Methoden der Software-Entwicklung eingesetzt werden.

Die Unterstützung für die Agilen Methoden ist in Systemanalyse 3.0 unmittelbar integriert und wird nicht nur durch wiederholtes Ablaufen einzelner Prozessschritte abgebildet.

Der kreative Prozess

Das Finden einer Lösung für eine Problemstellung ist die zentrale Aufgabe des Systemanalytikers. Diese Lösung ergibt sich nicht gleichsam automatisch aus den erhobenen Anforderungen, sondern dazu bedarf es einer kreativen Anstrengung. Jetzt ist Kreativität nicht etwas, das man verordnen kann oder das durch Befolgen eines Prozesses sichergestellt werden kann.

Dennoch gibt es mehrere wissenschaftliche Ansätze, wie der kreative Prozess verläuft. Einer der ältesten – und dennoch bis heute gültigen – stammt von Graham Wallas, der im Jahr 1926 Ideen des deutschen Physiologen Hermann von Helmholtz und des französischen Mathematikers Henri de Poincaré zu einer systematischen Theorie des kreativen Denkens zusammengefasst hat.

Inhalt

Graham Wallas definiert vier Schritte im kreativen Prozess:

  • Vorbereitung: In der ersten Phase wird die Aufgabenstellung definiert. Durch Aneignung von Kenntnissen und Sammlung von Informationen wird die Basis für das Finden der Lösung gelegt.
  • Inkubation: Hier reifen die Ideen auf Basis der in der Vorbereitungsphasen gesammelten Informationen. Der Kreative entfernt sich bewusst von dem Problem, tut gar nichts, oder beschäftigt sich mit den Themen, die nichts mit dem zu lösenden Problem zu tun haben. Die Kenntnisse, die in der ersten Phase aufgebaut wurden, können ins Unterbewusstsein absinken und dort schwebend weiterverarbeitet werden.
  • Illumination: Hier kommt das, was in der Inkubationszeit wächst, zum Vorschein. Das kann in der Form eines Heureka-Erlebnisses, eines Geistesblitzes, sein. Sehr häufig aber wächst die Idee langsam, konkretisiert sich immer stärker, so lange bis – zunächst im Kopf – ein fertiges Konzept vorhanden ist, das schließlich festgeschrieben werden kann.
  • Verifikation: In dieser Phase werden die meist noch unstrukturiereten Ideen aus der Illuminations-Phase zu einem durchgängigen Konzept ausgearbeitet. Darin enthalten ist auch die Prüfung auf Machbarkeit.
Der kreative Prozess und Systemanalyse 3.0

Das Finden von Lösungen ist Aufgabe des Systemanalytikers. Deshalb gibt jede gute Vorgehensweise Raum für die genannten vier Phasen der Kreativität. Systemanalyse 3.0 tut dies, indem sie keinen strikten Prozess vorgibt, sondern Tätigkeiten beschreibt, die einen groben Rahmen bieten, innerhalb dessen sich der Systemanalytiker sehr frei bewegen kann. Die vier Phasen des kreativen Prozesses können sich innerhalb dieser Tätigkeiten entfalten, sodass die Voraussetzung für kreative Lösungen geschaffen wird.

Ausblick

Nun nachdem die Beziehung zu seinen Quellen geklärt ist, können wir im nächsten Kapitel Inhalt und Prozess von Systemanalyse 3.0 näher betrachten.

Systemanalyse 3.0 – Kapitel 2

Kapitel 2 – Was ist Systemanalyse 3.0?

(in dem wir erläutern, was der Inhalt von Systemanalyse 3.0 ist)

Was ist nun eigentlich Systemanalyse 3.0? Die folgenden Seiten sollen auf diese Frage Antwort geben. Dafür wollen wir diesen Ansatz zunächst definieren. Im Anschluss daran wird das Wesen von Systemanalyse 3.0 durch die Behandlung einiger Aspekte näher beleuchtet werden.

Definition

Systemanalyse ist das systematische Untersuchen eines Arbeitsgebiets mit dem Ziel, eine oder mehrere IT-gestützte Lösungen für einen definierten Bedarf zu finden und zu entwerfen.

Sehen wir uns die Bestandteile dieser Definition etwas genauer and:

Systemanalyse: Analyse im hier verwendeten Sinne ist die Untersuchung eines Sachverhalts durch die gedankliche Zerlegung in kleinere Bestandteile. Wichtig in diesem Zusammenhang ist der Begriff des Systems. Das heißt, die Bestandteile, in die ein Sachverhalt zerlegt wird, stehen zueinander in Beziehung. Diese Beziehungen sind für die Arbeit des Systemanalytikers von hoher Bedeutung.

Bedarf: Der Bedarf ist der Anlass dafür, dass Systemanalyse betrieben wird. Dieser Anlass kann ein Problem in den betrieblichen Prozessen sein, das es zu lösen gilt, es kann eine Marktchance sein, die man durch die Unterstützung durch ein IT-System wahrnehmen will – oder es kann auch ein in die Jahre gekommenes Alt-System sein, das abzulösen ist. Eine Lösung für diese Problemstellungen zu finden und zu entwerfen, ist Aufgabe der Systemanalyse. Normalerweise beschäftigt sich die Systemanalyse nicht mit technischen Aufgaben, sondern mit solchen aus dem Fachbereich – aber: Ausnahmen bestätigen die Regel.

Untersuchen eines Arbeitsgebiets: Es ist die Aufgabe des Systemanalytikers, einen definierten Bedarf zu untersuchen. In der Regel ist es dafür erforderlich, Einblicke in die Prinzipien, die Prozesse, die Arbeitsweisen eines Arbeitsgebiets zu bekommen. Unter „Arbeitsgebiet“ ist dabei meist ein betrieblicher Teilbereich zu verstehen. Erst durch dieses Verständnis ist es dem Systemanalytiker möglich, Problemstellungen in diesem Arbeitsgebiet zu lösen.

Diese Untersuchung erfolgt systematisch: Dem Systemanalytiker stehen für diese Untersuchung eine Menge von Techniken zur Verfügung. Diese Techniken beziehen sich auf das Erheben von Anforderungen, auf das Finden und Modellieren von Lösungsansätzen, auf die Dokumentation des Lösungsentwurfes.

Finden und Entwerfen von Lösungen: Zur Aufgabe eines Systemanalytikers gehört es definitiv, Lösungen für die Problemstellungen zu entwerfen, er ist nicht bloß ein Stenograf für die Anforderungen. Die Aufgabe endet jedoch dort, wo die Umsetzung dieser Lösungen beginnt, dort wo es um den Einsatz von ganz konkreten IT-Werkzeugen, wie Programmiersprachen, Datenbanken und dergleichen geht.

IT-gestützte Lösungen: viele der im Folgenden dargestellten Vorgehensweisen können sicher auch außerhalb eines IT-Kontexts angewendet werden, wie etwa im Prozess-Management, in der Strategieplanung oder auch – um einen ganz anderen Bereich zu nennen – beim Bau eines Hauses. Dennoch liegt der Fokus von Systemanalyse 3.0 klar im IT-Kontext- dafür ist es gemacht, dahingehend ist es abgestimmt.

Die Anforderungen und die Lösung

Eine viel diskutierte Frage ist jene, inwieweit der Analytiker (bzw. der Requirements Engineer) auch für die Lösung zuständig ist. Insbesondere das Konzept des Requirements Engineering sieht vor, dass in seinem Bereich lediglich das Erheben und Dokumentieren der Anforderungen liegt. Diese sind die Basis für das Design der Lösung, wofür dann ein Designer oder auch die Implementierung zuständig ist.

Unsere Erfahrung zeigt, dass diese Form der Arbeitsteilung in der Praxis nicht zweckmäßig ist, ja häufig auch nicht praktikabel. Das soll im Folgenden dargestellt werden.

Sehen wir uns doch zunächst einmal die Begriffe an: „Anforderung“ – „Lösung“. Was ist ihr Inhalt? Wir kommen einer Antwort näher, wenn wir der „Anforderung“ die Frage „Was“ zuordnen – und der Lösung die Frage „Wie“. Mit anderen Worten: die Anforderung beschreibt das „Was“ der Lösung, „was“ wird benötigt – und die Lösung das „Wie“, in welcher Art und Weise wird es umgesetzt.

 Eine Trennung zwischen Anforderung und Lösung ist meistens gar nicht so einfach möglich. Was in einer Detaillierungsebene die Lösung (das „Wie“) ist, ist für die nächste die Anforderung (das „Was“), für die es wiederum eine Lösung zu suchen gilt („one man’s ceiling is another man’s floor“). Das heißt also, jede Anforderung ist die Lösung eines Problems auf einer anderen Ebene. Betrachten wir dazu ein Beispiel: Nehmen wir an, ein Unternehmen stellt fest, dass es zu wenig Umsatz macht. Es besteht also der Bedarf, den Umsatz zu steigern („Was“). Das ist die erste Anforderung. Nun wird nach Lösungen für diese Anforderung gesucht („Wie“). Nach einigem Überlegen entscheidet man, dass die Vertriebskanäle ausgeweitet werden sollen. Eine mögliche Lösung ist also die Entwicklung eines Web-Auftritts mit Shop, um Online-Verkauf zu ermöglichen. An die IT-Abteilung wird das als Anforderung herangetragen: Wir brauchen einen Web-Shop. Das „Wie“ wird zu einem neuen „Was“. Nun wird nach Lösungen für diese Anforderung gesucht und die Alternativen „Kauf eines Standard-Produkts“ und „Eigenentwicklung“ geprüft. Man entscheidet sich für „Eigenentwicklung“ – die Lösung für die Anforderung „Wir brauchen einen Web-Shop“. Jetzt wären wir bei der Anforderung „Entwicklung eines Web-Shops“. Und auch dafür wird es wieder eine Reihe von Lösungen geben. Dieses Spiel ließe sich noch auf mehreren Ebenen fortsetzen. Wir sehen aber schon: Die Antwort auf die Frage, ob etwas Anforderung oder Lösung ist, ob es das „Was“ ist oder das „Wie“, ist eine Frage der Betrachtungsebene.

Letztlich ist jede Anforderung die Idee eines Stakeholders, wie ein Aspekt der zugrunde liegenden Problemstellung zu lösen ist. Da der Stakeholder üblicherweise ein Experte im Arbeitsgebiet ist, wird in den meisten Fällen diese Anforderung in die Lösung einfließen. Nicht selten kommt es jedoch auch vor, dann nach näherer Analyse der Systemanalytiker gemeinsam mit dem Stakeholder auf eine andere Lösung kommt, als es in der Anforderung formuliert ist. Es gibt also immer Optionen [HEAP2013] – eine Anforderung ist keine unumstößliche Bedingung, sie ist eine Idee, die in die Lösung einfließen kann oder – nach eingehender Analyse – auch nicht.

Der Business Analysis Body of Knowledge (BABOK-Guide) in Version 3 bringt zwei weitere Begriffe ins Spiel: nämlich den (Unternehmens-)Bedarf (Business Need) und das Design. Die Zusammenhänge sind in folgender Abbildung dargestellt:

anforderung_loesung

Abbildung 1: Bedarf – Anforderung – Design – Lösung

Es ist die Aufgabe des Systemanalytikers, einen (Unternehmens-)Bedarf zu analysieren. Die explizite Formulierung eines derartigen Bedarfs oder einzelner Aspekte davon wird „Anforderung“ genannt. Die so ermittelten Anforderungen sind ein wesentlicher Bestandteil (wenn auch nicht der einzige) für das Design der Lösung. Ebenso wie die Anforderung die formulierte Repräsentation des Bedarfs ist, ist das Desing die formulierte Repräsentation der Lösung.

In dieser Frage liege ein wesentlicher Unterschied zwischen Systemanalyse 3.0 und dem Requirements Engineering: im Konzept der Systemanalyse 3.0 ist der Analytiker sowohl für die Erhebung und Dokumentation der Anforderungen als auch für das Design der Lösung zuständig. Der Bedarf gehört zur Sphäre des Fachbereiches und ist die Grundlage für die Anforderungen. Die Lösung wird auf Basis des Designs von Software-Entwicklern (oder anderen für die Umsetzung verantwortlichen Personen) erstellt und wiederum vom Fachbereich genutzt. Der Einfachheit halber sprechen wir hier häufig von der „Lösung“, wo wir eigentlich exakt das „Design der Lösung“ meinen.

Das Design im Fokus

Das Design der Lösung befindet sich nicht nur innerhalb des Aufgabenbereichs des Systemanalytikers – es steht darüber hinaus auch im Zentrum seiner Bemühungen. Im Zweifel ist das Design der Lösung auch wichtiger als die Anforderungen.

Die Anforderungen sind wichtig – zweifellos, schließlich kommen sie von denen, die das Arbeitsgebiet am besten kennen. Sehr häufig werden sie eins-zu-eins in das Design der Lösung einfließen – manchmal werden sie durch den Systemanalytiker – immer in Zusammenarbeit mit den Stakeholdern – modifiziert oder sogar verworfen werden.

In der Systemanalyse ist das Ziel immer die Lösung – die Anforderungen sind ein wertvoller Input dafür, nicht mehr und nicht weniger.

Etwas plakativ könnte man formulieren: Systemanalyse 3.0 ist „Solution Engineering“ und nicht „Requirements Engineering“. Dieser „lösungsorientierte Ansatz“ hat unter anderem folgende Vorteile:

  1. Aufwand: Dadurch, dass von Anfang an die Lösung im Zentrum der Überlegung steht, wird sichergestellt, dass nur Aktivitäten ausgeführt und Artefakte erstellt werden, die auch der Lösung dienen. Wenn die Anforderungen im Mittelpunkt stehen, ist man versucht, sich mehr mit den Anforderungen und ihrem Management zu beschäftigen, als es für das Design der Lösung nützlich ist. Im Sinne und in der Ausdrucksweise der agilen Methoden ist also dieser lösungsorientierte Ansatz ein Mittel zur Vermeidung von „Waste“.
  2. Qualität: Systemanalyse 3.0 betrachtet nur das als „Anforderung“, was die Stakeholder auch als solche aussprechen bzw. was sich aus diversen Bestimmungen ergibt. Dadurch kommt der einzelnen Anforderung ein höherer Stellenwert zu. In den Vorgangsweisen, wo Anforderungserhebung und Lösungsfindung (theoretisch) getrennt sind, muss die gesamte Lösung in Form von Anforderungen beschrieben sein. Man spricht auch von „Anforderungen ERfinden“. Dadurch steigt die Zahl der Anforderungen dramatisch und die „echten“ Anforderungen gehen möglicherweise in der Masse jener Lösungsfaktoren unter, die von niemand angefordert wurden – und eigentlich „nur“ die Ideen des Systemanalytikers sind.

Business Analyse im IT-Kontext

Viele Diskussionen über das Wesen der Business Analyse entzünden sich an der Frage, wie sehr diese mit einem IT-Kontext verknüpft ist. Tatsächlich sind die Methoden und Techniken des BABOK-Guide sehr allgemein formuliert, sodass sie in vielen Anwendungsgebieten anwendbar sind – nicht nur in der IT, aber auch. Die Version 3 des BABOK-Guide macht das durch die so genannten „Perspektiven“ klar. Die „Perspektiven“ sind Spezialisierungen für einzelne Anwendungsgebiete.

Systemanalyse 3.0 hat seinen Schwerpunkt dagegen ganz eindeutig im IT-Kontext. Systemanalyse ist „Business Analyse im IT-Kontext“.

Der Systemanalytiker und Entscheidungen

Darf ein Systemanalytiker (Business Analyst / Requirements Engineer) Entscheidungen treffen? Sehr oft wird diese Frage verneint. Der Analytiker oder Requirements Engineer erhebt die Anforderungen und dokumentiert diese. Entscheidungen werden auf dieser Basis vom Auftraggeber oder auch vom Designer getroffen.

Systemanalyse 3.0 hat einen anderen Blickwinkel auf diese Frage. Da der Systemanalytiker das Design der Lösung entwirft, wird er nicht darum herumkommen, Entscheidungen zu treffen. Natürlich trifft er diese nicht endgültig. Er wird sein Design „verkaufen“ müssen – dem Auftraggeber, den Anwendern – allen Stakeholdern. Wenn er seine Entscheidung also nicht rechtzeitig mit diesen Gruppen abstimmt, wird er letztlich scheitern. Wenn er aber gar keine Entscheidungen trifft, wird er zu keiner Lösung kommen und so auch nicht erfolgreich sein können.

Zusammenfassung

Nachdem wir nun den Inhalt von Systemanalyse 3.0 definiert und einige Charakteristika erläutert haben, wollen wir im nächsten Kapitel Gemeinsamkeiten und Unterschiede von Systemanalyse 3.0 und seinen Quellen (klassische Systemanalyse, Business Analyse, Requirements Engineering, agile Softwareentwicklungs-Methoden, kreativer Prozess) darstellen.

Systemanalyse 3.0 – Kapitel 1

Lesen Sie im folgenden den ersten von voraussichtlichen zehn Artikeln über Systemanalyse 3.0 – den Analyse-Ansatz, in dessen Mittelpunkt die Lösung steht.

Kapitel 1 – Systemanalyse – gestern, heute, morgen

(in dem wir die Entwicklung der Systemanalyse in den letzten Jahren und Jahrzehnten besprechen und andeuten, wie der nächste Entwicklungsschritt aussehen könnte)

Business Architect, Projektmanager, Systemanalytiker, Systems-Engineer, Tester, Business Analyst, Software Architect, Requirements Engineer, Software-Entwickler, …

Groß ist die Zahl der Berufsbezeichnungen und der Job-Titles in der IT. Und es ist nicht immer klar, welche Aufgabe mit der jeweiligen Bezeichnung verbunden ist. Übersichtlicher wird die Lage, wenn man die Tätigkeitsbereiche in drei Gruppen einteilt [HRUSCHKA2014]:

  1. Das Team zum Ziel führen: das ist das Gebiet des Projektmanagements. Die Aufgabe in diesem Bereich liegt in der Zeit-, Kosten- und Terminplanung und im Setzen von geeigneten Maßnahmen zur Zielerreichung.
  2. Das Problem verstehen und Lösungen entwerfen: in diesem Tätigkeitsbereich wird die Aufgabenstellung analysiert und auf Basis dieser Analyse werden Lösungen vorgeschlagen und konzipiert.
  3. Lösungen mit einer gewählten Technologie implementieren: dabei handelt es sich um das weite Feld der Software-Entwicklung, das auch die Auswahl und die Integration der Technologien beinhaltet.

Jedes der oben genannten Berufsbilder lässt sich einem dieser Bereiche zuordnen, im einen oder anderen Fall gibt es vielleicht auch Überschneidungen.

In dieser Blog-Serie soll der zweite der genannten Bereiche behandelt werden, dessen Aufgabe es ist, die Aufgabenstellung unabhängig von den technischen Implementierungsdetails zu analysieren, die Anforderungen an eine Lösung zu erheben und auf dieser Grundlage eine oder auch mehrere Lösungen zu entwerfen und zur Umsetzung zu bringen.

Gerade dieses Gebiet hat in den letzten Jahren und Jahrzehnten eine gewaltige Entwicklung erlebt. Es handelt sich keineswegs um eine neue Disziplin. Auch der grundsätzliche Inhalt – das Konzipieren von Lösungen – hat sich seit den 60er-Jahren kaum geändert. Was sich jedoch geändert hat, sind die zur Verfügung stehenden Methoden und Techniken. Darüber hinaus haben auch verschiedene Standardisierungsbestrebungen zur Entwicklung dieses Fachbereiches beigetragen.

Lange Zeit war die Tätigkeit der Analyse und der Konzeption von Software-Lösungen als Systemanalyse bekannt. Dieser Begriff wurde in den letzten Jahren von zwei anderen Bezeichnungen weitgehend abgelöst: Requirements Engineering und Business Analyse. Dabei geht es aber nicht nur um eine neue Bezeichnung für den gleichen Inhalt, sondern es kam auch zu einer Verschiebung der Schwerpunkte innerhalb des Berufsbildes des Systemanalytikers.

Die Aufspaltung der ursprünglichen „Systemanalyse“ geht zurück auf die frühen 2000er-Jahre. Damals erlebten die Standardisierungsbestrebungen auf dem Gebiet des Projektmanagements einen Boom. Organisationen wie das PMI (Project Management Institute) schufen Standards und boten den Projektmanagern die Möglichkeit, sich auf diese Standards zertifizieren zu lassen. Diese Zertifikate wurden auch zunehmend von Arbeitgebern und im Rahmen von Ausschreibungen nachgefragt. Auf dem Gebiet der Systemanalyse gab es Derartiges nicht.

Diese Situation wurde von vielen Systemanalytikern als unbefriedigend empfunden. So taten sich nahezu gleichzeitig an verschiedenen Orten der Welt Menschen zusammen, um dem Abhilfe zu verschaffen. Im Jahr 2003 wurde in Toronto, Kanada, das International Institute of Business Analysis (IIBA) gegründet. Diese Organisation setzte es sich zur Aufgabe, das Berufsbild der Business Analyse – so nannte man dort die bisherige Systemanalyse – zu etablieren und einen Standard dafür zu schaffen. Das Instrument für Letzteres ist die Herausgabe des so genannten „Business Analysis Body of Knowledge“ (BABOK-Guide), der sich mittlerweile zu einem Standardwerk der Business Analyse entwickelt hat und im April 2015 in seiner dritten Version erschienen ist.

In etwa zeitgleich mit dem IIBA wurde in Deutschland das International Requirements Engineering Board (IREB) gegründet, das eine ähnliche Zielsetzung wie das IIBA erfolgt. Wie das IIBA bietet auch das IREB Zertifizierungen für Systemanalytiker an. Hier wird die Disziplin der Systemanalyse nun Requirements Engineering genannt.

Obwohl also sowohl die Business Analyse als auch das Requirements Engineering ähnliche Wurzeln haben, gibt es doch auch Unterschiede in den Schwerpunktsetzungen, die sich auch in den (neuen) Namen ausdrücken: Während Business Analyse den Fokus auf die fachliche („Business“) Analyse legt und auch über den Bereich der IT hinausgeht, liegt ein deutlicher Schwerpunkt des Requirements Engineering in der System-Modellierung. Dadurch hab das Requirements Engineering einen viel deutlicheren IT-Bezug als Business Analyse.

Eine besondere Herausforderung für die Disziplin der Systemanalyse ist der aktuelle Mega-Trend auf dem Gebiet der Software-Entwicklung: die agile Vorgehensweise. Die ursprüngliche Idee dieser Methoden sollte Analyse-Tätigkeit überhaupt weitgehend überflüssig machen. Mittlerweile hat man erkannt, dass es ganz ohne diese doch nicht geht. Aber dennoch hat dieses geänderte Paradigma wesentliche Auswirkungen auf die Tätigkeit des Systemanalytikers.

Ein weiterer Aspekt, der hier besondere Berücksichtigung finden soll, ist jener der Kreativität. Sehr oft wird der Prozess der Systemanalyse als ein fast mechanischer betrachtet, wo kein Raum für Kreativität vorhanden ist – ja auch gar nicht benötigt wird. Tatsächlich ist jedoch das Finden der Lösung im Rahmen der Systemanalyse ein bedeutender Schritt, ja das eigentliche Ziel der Arbeit des Analytikers, und ist keineswegs mit der Erhebung und Dokumentation der Anforderungen erledigt.

Das ist nun der Hintergrund hinter dem Konzept der Systemanalyse 3.0.

Es soll ein Ansatz dargestellt werden, der folgende Aspekte in sich vereinigt:

  • Die klassische Systemanalyse
  • Business Analyse
  • Requirements Engineering
  • Agile Software-Entwicklung
  • Kreativität.

sa30_overview

Abbildung 1: Systemanalyse 3.0 – die Quellen

Wir nennen diesen Ansatz „Systemanalyse 3.0“. Warum sprechen wir gerade von der dritten Version der Systemanalyse?

Die Version 1 war das Vorgehen der klassischen Systemanalyse. Diese wurde von den Konzepten der Business Analyse und des Requirements Engineering abgelöst.

Mit der hier vorgestellten Version 3 sollen die verschiedenen Richtungen wieder zu einem einheitlichen Konzept zusammengeführt werden. Dieses einheitliche Konzept soll zusätzlich um die Ideen der agilen Software-Entwicklung und der Kreativitätstheorien erweitert werden.

Der nächste Artikel wird beschreiben, was Systemanalyse 3.0 ist und wie wir sie definieren wollen.

Wenn Druck in ein Projekt reinkommt: Trotzdem Dinge richtig tun

In meiner Projektpraxis kommt es immer wieder vor, dass trotz großer Anstrengungen die Ergebnisse weit hinter den Plänen oder Erwartungen nachhinken. Nachfolgend finden Sie einige Empfehlungen, die in der Praxis helfen.

Die Ausgangslage: Alle im Projekt arbeiten mit großem Einsatz und dennoch sind Ziele, selbst wenn sie realistisch dimensioniert sind, was nicht immer der Fall ist J, nicht und nicht erreichbar. Die Projektleitung bzw. der Auftraggeber werden immer unzufriedener, wesentliche Entwicklungsziele werden re-priorisiert, Überstunden und Urlaubsverzicht eingefordert, die Projektmitarbeiter verlieren das Vertrauen an die Zielerreichung und die Projektleitung, … die Spirale dreht sich steil und eng nach unten.

Hier ist es wichtig, sich nicht vollständig vom Panik-Modus diktieren zu lassen und aktionistisch Maßnahmen zu setzen, die lediglich eine hektische Betriebsamkeit nach außen (zum Auftraggeber) vermitteln. Es gilt durch eine klare und strukturierte Vorgehensweise Maßnahmen in der richtigen Reihenfolge zu setzen.

In meiner Praxis haben sich folgende Prioritäten und Reihenfolgen als richtig herausgestellt:

  1. Abgestimmte Vorgehensweise der Entscheider
  2. Fokus auf Qualität
  3. Work in Progress-Limits einführen und einhalten
  4. Häufige Lieferungen
  5. Nachfrage und Durchsatz balancieren
  6. Das Richtige priorisieren
  7. Vorhersagbarkeit erhöhen

Wenn Sie nun „Work in Progress-Limits einführen“ oder „Häufige Lieferungen“ lesen, so ist das ein Indikator für agiles Vorgehen. Aber gleich an dieser Stelle der Widerruf: Nein, auch in der traditionellen Vorgehensweise kann man die Anzahl der gleichzeitig durchzuführenden Arbeiten sinnvoll dimensionieren und Zwischenergebnisse in Form von in sich abgeschlossenen Artefakten liefern und mit den betroffenen Stakeholdern bzw. Projektleitern, Fachbereich, Analysten, Programmierer und Testern besprechen.

Trotz Druck die richtigen Dinge tun

Trotz Druck die richtigen Dinge tun

1. Abgestimmte Vorgehensweise der Entscheider

Neben den klassischen Rollen, wie beispielsweise dem Projektleiter, gibt es eine Vielzahl von steuernden Personen im Projekt. Product Owner, Featureteam-Leiter, Release Manager, Delivery Manager, usw. Oft genug verfolgen alle Beteiligten unterschiedliche Prioritäten, ein gemeinsamer Plan existiert nicht.

Ein enger Schulterschluss der „Entscheider“ ist in solchen Situationen dringend notwendig. Es gilt, den Kreis der Entscheider zu identifizieren und zu einer engen, zyklischen Abstimmung auf Basis eines abgestimmten Plans zu bringen. Aus dieser Gruppe kommen die wesentlichen Impulse und next steps für das gesamte Projekt. Es empfiehlt sich, den Kreis der Entscheider klein zu halten (max. 5-6 Personen), sich mindestens 1 x pro Woche ernsthaft zu einer Abstimmung zu treffen – pünktlich, ohne Störungen, ohne überboardender Dominanz des Tagesgeschäfts (sonst kommen strategische Punkte zu kurz!), usw.

In meiner Praxis hat sich auch eine 70-100-Regel bei Entscheidungen als günstig erwiesen: Wenn im Entscheiderteam jeder zumindest zu 70% hinter einer Entscheidungen stehen kann, dann wird diese Entscheidung zu 100% getragen. Politisches Kleingeld á la „Ich will das ja auch nicht, aber die da haben so entschieden“ zu machen schwächt das Entscheiderteam nachhaltig.

2. Fokus auf Qualität

„Wir nehmen uns gerne die Zeit, Dinge immer wieder zu machen – statt sie einmal richtig zu tun.“ Natürlich ist bei fehlender Qualität (Defects, nicht erfüllte Requirements, usw.) ein deutlicher Mehraufwand, der durch Korrektur, neuerlicher Q-Sicherung, Deployment, Einführung, usw. entsteht, mehr Zeit in die Entwicklung eines Features gelaufen. Auch das Vertrauen in die Akteure sinkt („Die produzieren nur Mist“). Gerne unterschätzt wird auch, dass alle an der Korrektur beteiligten Personen immer wieder und wieder aus den laufenden Arbeiten herausgerissen werden um den oder die Fehler zu beseitigen. Dadurch kommt man in den gefährlichen Multitasking-Modus, mit dem daraus resultierenden Mehr an neuen Fehlern und deutlichem Mehr an Zeitbedarf für alles.

3. Work in Progress-Limits einführen und einhalten

Kommt ein Projekt unter Druck, wird durch schlechte Projektleitungen noch mehr Öl ins Feuer gegossen, indem noch mehr gleichzeitige Tasks beauftragt werden („Schlagzahl erhöhen“) oder der vorliegende Plan ohne Feedback aus den Ergebnissen des Projekts stumpfsinnig eingehalten wird. Die Projektleitung ist von außen oberflächlich betrachtet fein raus – sie hat ja alles getan, was möglich und geplant war („Alles ist im Laufen, jetzt müssen die Teams nur noch liefern“).

Eine professionelle Projektleitung konzentriert sich auf die optimale Aus- bzw. Belastung der Teams und die Beseitigung von Schwachstellen und Bottlenecks. Auch wenn es an dieser Stelle bedeutet, ein re-planning zu machen. Je früher klar ist, wie es um den Projektplan wirklich bestellt ist, desto mehr Zeit hat das Projekt Maßnahmen zur Zielerreichung zu ergreifen.

Zur Optimierung des Outputs hat sich die Einführung von Work in Progress-, kurz WiP-, Limits herauskristallisiert. Man belastet die Teams mit wenigen, gleichzeitigen Tasks, verkürzt aber damit substanziell die Durchlaufzeit der einzelnen Tasks, da Overheads durch Taskswitching vermieden werden und zwei weitere Super-Effekte entstehen: Es gibt für den Auftraggeber (Product Owner und Co) rascher Feedback (à häufige Lieferungen) und für neuerliche Tasks kann sich der Auftraggeber später entscheiden, was er genau haben will („late commitment“).

4. Häufige Lieferungen

Die Basisüberlegung dazu: Vertrauen in Akteure wird dann etabliert, wenn diese oft Zugesagtes einhalten. Im Gegensatz zu ein bis zwei Lieferungen pro Jahr hat man durch Lieferungen alle zwei bis vier Wochen öfters die Chance Vertrauen zu gewinnen.

In einem kritischen Projektverlauf ist es besser, öfters nachzuweisen, dass alles im Lot ist. Sich für 6 Monate wegzusperren und nichts zu liefern erhöht die Unsicherheit beim Auftraggeber.

Ein weiterer Vorteil, der sich durch häufige Lieferungen ergibt: Integration wird bei der Herstellung der einzelnen Artefakte im Rahmen der Definition-of-Done (DoD) erledigt und ein späteres Scheitern aus Integrationsproblemen, insbesondere wahrscheinlich bei großen Projekten, verhindert.

5. Nachfrage und Durchsatz balancieren

Gerade wenn unterschiedliche Auftraggeber, z.B. verschiedene Fachbereiche, Anforderungen an das Projekt stellen (können), ist ein Gatekeeping an der Eingangsseite des Projekts wichtig. Es ist notwendig, die eigene Kapazität als Kennzahl parat zu haben und im Zweifelsfalls die Auftraggeber selbst entscheiden zu lassen, welche Anforderung welche Priorität hat. Natürlich wird der Fachbereich damit argumentieren, dass wenn „Feature X nicht bis Datum Y fertig wird die Ziele des Fachbereichs nicht erreicht werden können“ und daran „die Projektleitung Schuld hat!“. Dieser Schlagabtausch ist normal und im Regelfall, wenn die Kapazitätsplanung fundiert vermittelt wird, schnell wieder vorbei. Schafft es die Projektleitung zwischen den einzelnen Gruppen der Anforderer ein wechselseitiges Geben-und-Nehmen zu etablieren, ist das perfekt. Jedoch fokussiert sich in der Praxis die Projektleitung leider zu sehr darauf eher mehr reinzunehmen und die eigene Mannschaft die sprichwörtliche Suppe auslöffeln zu lassen.

Schafft man es, Nachfrage und Durchsatz zu balancieren, wird das Projekt in Richtung optimaler Auslastung mehr Output schaffen. Durch kontinuierliche Verbesserung des projektinternen Wertschöpfungsprozesses, weniger Störungen durch Überlastung und etablierten Teams, die wissen, was sie wie leisten können, wird die Kapazität des Projekts kontinuierlich wachsen – was wiederum zu mehr Nachfragen führen wird.

6. Das Richtige priorisieren

Es gilt, die aus Sicht des Business Value hochwertigsten Features zu priorisieren. Hauptproblem: Oft ist die Bewertung des Werts durch die jahrelange Rechtfertigungspolitik in den Unternehmen wertlos geworden („Für jede Änderung lässt sich ein Business Case berechnen!“). Nach der Realisierung ist eine Total-Cost-of-Ownership (TCO) Berechnung für das Projekt ziemlich wertlos: Das Feature wurde ja bereits realisiert und hat das Projekt belastet. Oder es werden Listen mit Kriterien, wie „potentieller Gewinn“ und „potentieller Schaden“ geführt – allerdings ohne gemeinsames Spielverständnis.

Also, wie damit umgehen? Eine Möglichkeit ist das Schaffen einer klaren Business Value Bewertung, die die zugrundeliegenden Strategien (mehr Umsatz, mehr Kunden, mehr…) berücksichtigt und Änderungen der Strategie mitnehmen kann. Diese Bewertung ist mit den Auftraggebern und den planungsverantwortlichen im Projekt gemeinsam zu schaffen.

Weiteres Aspekte in Richtung das Richtige zu tun:

  • Durchstich-Strategie, d.h. zuerst das Feature in einer funktionalen Basis herzustellen und es erst in Folge zu „behübschen“; damit gibt es die Funktion in der Basis und falls letztendlich Ressourcen knapp werden, gibt es die Funktion zumindest in einer einfachen Variante
  • Risikobasierte Priorisierung, d.h. jene Features mit der größten Wahrscheinlichkeit zu Scheitern, zuerst schaffen: Zuerst Unbekanntes und Neues angehen, Bekanntes ist ja leichter herzustellen
  • Silobildung vermeiden, d.h. Prüfungen aus fachlicher oder technischer Architektur bei allen Anforderungen gewährleisten, insbesondere dann wichtig, wenn im Projekt in einzelnen Teams entwickelt wird

7. Vorhersagbarkeit erhöhen

Ein guter Witz basiert darauf, überraschend zu sein à ohne Überraschungsmoment gibt es keinen guten Witz. Aber: Ein Projekt ist jedoch kein Witz. Je vorhersagbarer Lieferungen des Projekts werden – und es geht hier im Kern um Termine, Kosten und Qualität – desto mehr Vertrauen werden alle Stakeholder in die Leistungen des Projekts haben. Abstimmungen zwischen Auftraggebern werden dadurch vereinfacht – diese brauchen keine überdimensionierten Sicherheiten in ihre Pläne einchecken und reduzieren daher die Anforderungen an das Projekt, das deshalb auch entspannter wird. Die mit der Umsetzung betrauten Projektmitarbeiter des Teams werden ebenfalls durch bessere Vorhersagbarkeit profitieren (Optimierungen der Arbeiten bis hin zu verlässlicheren Freizeiten, usw.) und sich besser auf die jeweilige Situation einstellen können.

Abhängig davon, in welchem Projektmanagement-Framework entwickelt wird (Scrum, DSDM, FDD, Kanban, Wasserfall, V-Modell, etc.) werden Schätzungen und Messungen dabei helfen, vorhersagbarer zu werden. Wichtig ist in allen Fällen, dass die Zielerreichung auch wirklich projektinterne Kultur ist.

Referenzen:

[Anderson-2012] – David Anderson, „Kanban – Evolutionäres Change Management für IT-Organisationen“, 2012

%d Bloggern gefällt das: