Sie moderieren mehrtägige Workshops, interaktive Workshops. Workshops mit wichtigen Kunden, mit massgeblichen Stakeholdern? Sie sind also gefordert, die Ressourcen der Teilnehmer möglichst effektiv und effizient einzusetzen, damit sie ihre Ziele erreichen, ihre Lieferergebnisse erhalten? Ich möchte ihnen demonstrieren, wie sie einen Workshop mittels UML in einem Team vorbereiten können.
Workshops vorbereiten? Ich improvisiere!
Gewiss, für einen einstündigen Workshop über ein definiertes Thema mit einem definierten Ergebnis müssen Sie sich nicht mittels UML akribisch auf alle Eventualitäten vorbereiten. Solche Workshops meistert ein erfahrener Requirements Engineer meistens mit Leichtigkeit, siehe unseren beliebten Kurs Visual Facilitation. Wenn Sie sich aber in einem Umfeld bewegen, wo Sie Innovationen entwickeln müssen, Kreativitätstechniken einsetzen dürfen und an wenigen Tagen konzentriert alle Stakeholder versammelt haben, bedarf es Vorbereitung - ganz gewiss.
Haben Sie jemals versucht, in einem Team einen mehrtägigen Workshop vorzubereiten?
Dann haben Sie sich normalerweise zusammen gesetzt, zu Dritt, haben zuerst ein PowerPoint geöffnet, ein Inhaltsverzeichnis erstellt? Dann Arbeitspakete geschnürt, verteilt, sich mehr oder weniger regelmässig getroffen, um sich abzustimmen? Und eventuell haben Sie bemerkt, dass Ihre Vorgehensweise nicht sonderlich effektiv und effizient ist. Allein der Abgleich unterschiedlicherer PowerPoint-Versionen erfordert Blut, Schweiss und Tränen.
Wieso nicht strukturiert?
Bereits in meinen vorherigen Beiträgen (Requirements Engineering in Business Intelligence sowie Wie bereitet man sich auf eine Präsentation vor) empfahl ich, dass man auch Probleme, die scheinbar nicht viel mit RE gemein haben, RE-mässig strukturiert lösen kann. So auch beim Thema, wie man sich auf einen Workshop vorbereitet.
Strukturiert bedeutet, vom Groben ins Feinen zu gehen und ordentlich zu arbeiten - keine Hektik, kein Stress.
Hier mein Vorschlag, wie man sich auf einen grossen und gewichtigen Workshop vorbereitet. Die Aktivitäten sind:
- Auftrag klären
- Stakeholder analysieren
- Lieferergebnisse definieren
- Grobablauf definieren
- Hilfsmittel beschreiben
- Prototyp
- Auftraggeber konsultieren
- Feinablauf definieren
- Sich vorbereiten
1. Auftrag klären
Viele Workshops scheitern, bevor sie beginnen, weil nicht geklärt wird, was überhaupt bezweckt werden soll. Als Requirements Engineer ist man oftmals in der Situation, dass jemand einen Workshop ordert. Mittels der Kreativitätstechnik Brainstorming können rasch Ziele, Vorgaben und allenfalls Teilnehmer eines Workshops gemeinsam mit dem Auftraggeber konkretisiert werden. Dieser Stoff bildet dann die Basis für das weitere Vorgehen.
2. Stakeholder analysieren
Auch beim Vorbereiten eines Workshops sind wir Requirements Engineers auf Stakeholder Analyse angewiesen. Wir müssen unser Umfeld kennenlernen. Hier können Stakeholder als Akteure gruppiert und sortiert werden. Sofern die Informationen zugänglich sind, können Stakeholder auch hinsichtlich definierter Eigenschaften bewertet werden. Meine Erfahrung lehrte mich hier zudem, dass es sich anschickt, bereits im Voraus potenzielle Gruppen zu bilden. Das heisst, man paart passende oder eben unpassende Stakeholder geschickt in Gruppen, damit das Ergebnis einer eventuellen Gruppenarbeit möglichst befruchtend ist.
3. Lieferergebnisse definieren
Lieferergebnisse und deren Beziehungen modellieren wir als Klassendiagramm. Wir erhalten so eine Übersicht, was wir überhaupt liefern wollen. Zusätzlich attributisieren wir unsere Klassen, so dass wir die Frage beantworten können, welche Eigenschaften unsere Lieferergebnisse aufweisen müssen. Diese Klassen können wir dann im Ablauf des Workshops als Objekte einbinden. In zeitgemässen Tools können wir damit auch später eine Traceability generieren lassen, welche Aktivitäten welche Lieferergebnisse hervorbringen.
4. Grobablauf definieren
Nun haben wir den Auftrag geklärt, Stakeholder analysiert und die Lieferergebnisse strukturiert. So können wir jetzt einen Grobablauf definieren. Hierfür nutzen wir ein Aktivitätsdiagramm.
Da wir RE sind, starten wir immer zuerst mit einem groben Ablauf.
Welche Aktivitäten in welcher Abfolge produzieren welche Lieferergebnisse? Eventuell haben wir eine erste Aktivität Begrüssung, schliesslich müssen wir an einem grösseren Workshop uns gegenseitig vorstellen, unsere individuellen Erwartungen und Ziele dem Publikum präsentieren? Eventuell wollen wir ein Eisbrecher-Spiel einsetzen. Es dürfen auch unkonventionelle Spiele sein, siehe zum Beispiel Kennenlernspiele.
5. Hilfsmittel beschreiben
An einem Workshop nutzt man üblicherweise Hilfsmittel. Das können Techniken sein wie:
- Brainstorming
- Methode 635
- Gruppenarbeiten
- Moderierte Diskussionsrunde
- Priorisierungstechniken
- und so weiter
Diese Hilfsmittel sind zu dokumentieren und anschliessend mit dem Feinablauf zu verknüpfen.
6. Prototyp
Unser Vorgehen muss natürlich getestet werden. Wir müssen sicherstellen, dass zum Beispiel die zu verwendende Technik wirklich auch die zu erwartenden Ergebnisse erzielt.
Wir müssen aber auch prüfen, ob der Grobablauf stringent, also flüssig und sinnig ist.
Dies, indem wir innerhalb des Vorbereitungsteams den Workshop durchspielen. Das heisst, wir erproben die Hilfsmittel und den Grobablauf, wir testen, ob wir wirklich die zu erwartenden Lieferergebnisse produzieren können. Hier empfehle ich, dass wir in definierte Rollen schlüpfen. Mögliche Rollen sind: Manager, Macher, Nörgler. Falls wir mit den Stakeholdern sehr vertraut sind, können wir auch unsere Stakeholder mimen.
7. Auftraggeber konsultieren
Nun sind wir gerüstet, dem Auftraggeber unser Vorgehen zu präsentieren. Wir wollen den Auftraggeber überzeugen, dass es richtig war, in uns zu investieren. Wir wollen ihn für diesen einmaligen Workshop begeistern und ihm aufzeigen, dass wir bestens vorbereitet sind. Wir öffnen also unser Modellierungstool und erklären jeden einzelnen Schritt.
8. Feinablauf definieren
Nachdem der Auftraggeber den Grobablauf, die Lieferergebnisse sowie die Hilfsmittel abgenommen hat, können wir unseren Workshop weiter detaillieren.
Hier wählen wir bewusst einen risikobasierten Ansatz. Wir bereiten uns darauf vor, wo wir Risiken, Unsicherheiten erwarten.
Ein Begrüssungsspiel zum Beispiel müssen wir nicht weiter konkretisieren, dafür aber den Ablauf eines Brainstormings mit unterschiedlichen Gruppen und Phasen.
9. Sich vorbereiten
Je nach Erfordernis können wir nochmals einen Prototyp durchspielen. Wichtig ist aber, dass wir ab einem bestimmten Zeitpunkt die Vorbereitung einfrieren. Das heisst, das Modell ist ab diesem Zeitpunkt nicht mehr editierbar. Nun gilt die individuell ausgedruckte Version. Man kann den Ablauf zum Beispiel um handschriftliche Kommentare präzisieren, während man zum Veranstaltungsort fährt - vorzugsweise mit öffentlichen Verkehrsmitteln, um die Reisezeit sinnvoll nutzen zu können.
Vorteile
Wer modellbasiert arbeitet, hat automatisch die Vorteile eines solchen Vorgehens. Nämlich Struktur und Verständlichkeit. Ein Team kann sich so gezielter vorbereiten, weil es sich besser verständigen kann. Ausserdem können Modelle beliebig skaliert werden - von einem Grob- bis zu einem Detailablauf. Wir können in einem Modell auch gemeinsam genutzte Objekte, zum Beispiel Hilfsmittel, Lieferergebnisse oder Aktivitäten, beliebig wiederverwenden respektive darauf verweisen.
Insbesondere bei gewichtigen Workshops ist es - auch für unsere Berufsgruppe - entscheidend, dass wir sogleich den Mehrwert des Requirements Engineerings demonstrieren.
Gewichtige Workshops sind, wenn zum Beispiel ein OEM-Produzent mit seinem Kunden eine erste Produktvision zu festigen versucht.
Oder falls eine Business-Abteilung einen Dienstleister einlädt, um gemeinsam einen Projektscope zu definieren. An solchen Workshops müssen wir zeigen, dass Requirements Engineering bereits ganz am Anfang involviert werden soll und dass sich das auzahlt.
Fazit
Ich selber kann diese Vorgehensweise sehr empfehlen, allerdings mit dem ausdrücklichen Vermerk, dass sich der Aufwand nur lohnt, wenn ein gewichtiger Workshop ansteht. Für überschaubare Workshops genügen - wie bereits eingangs erwähnt - Papier und Stift. Der Requirements Engineer muss einschätzen können, wie er sich vorbereiten muss, was in dieser Projektsituation geboten ist, usw.
Wie man mit Papier und Stift einen überschaubaren Workshop vorbereitet und schliesslich durchführt, vermitteln wir - wie bereits eingangs erwähnt - in unserem Kurs Visual Facilitation.
Abschliessend: Man lernt so UML auch in einem nicht-technischen Umfeld kennen. Ich persönlich schätze UML, um die Welt abbilden zu können. Man muss UML nicht immer als reine Modellierungssprache für IT-Systeme reduzieren; denn:
UML kann mehr, als wir ahnen.