RA #008 Agiles Projektmanagement in der Technischen Dokumentation

Große Projekte nehmen viel Zeit und Geld in Anspruch. Häufig kommt es im Projektverlauf auch zu Problemen bzw. Unstimmigkeiten in einzelnen Projektabschnitten. Oder der Projektumfang wird mitten im Projekt nochmal geändert. Hier kann es dann zu Problemen innerhalb des Teams und der Organisation kommen.

Beispielsweise müssen an einem Produkt kurz vor Auslieferung noch Änderungen vorgenommen werden. Diese werden dann in der kurzen Zeit umgesetzt aber niemand informiert die Technische Redaktion über die Änderungen. Die Betriebsanleitung zu dem Produkt entspricht dann nicht mehr dem aktuellen Zustand des Produktes und ist fehlerhaft. Schnell führt das dann zu entsprechenden Konsequenzen. Der Kunde bemerkt die fehlerhafte Betriebsanleitung und pocht auf eine Anpassung der Betriebsanleitung. Im gleichen Zuge mindert er aufgrund des fehlerhaften Produktes den Kaufpreis für das Produkt. Ja das ist möglich! Denn wenn die Betriebsanleitung fehlerhaft ist, ist das ganze Produkt fehlerhaft.

Die Ursachen sind meist dann im Projektmanagement zu finden. Hier wurde dann zu komplex und zu starr gearbeitet und entsprechende Stellen nicht über die Änderungen informiert. Die Frage nach einer einfacheren Methode für das Projektmanagement steht dann im Raum.

In dieser Episode möchte ich auf agiles Projektmanagement eingehen und wie dieses in einer Technischen Redaktion aussehen könnte. Zuerst muss aber noch geklärt werden was unter Projektmanagement verstanden wird.

Im klassischen Sinn werden Projekte nach dem sogenannten „Wasserfallmodell“ geplant. Es werden Aufgaben definiert, in Reihenfolge gebracht und terminiert. Die Verantwortlichen sowie benötigte Ressourcen werden für die Aufgaben festlegt. Dann arbeiten die Personen die festgelegten Aufgaben stetig ab, gleich wie bei einem Wasserfall.

Läuft die Abarbeitung der Aufgaben nicht rund, stockt der Fluss. Dann steht oft die Frage nach mehr Agilität im Raum. Um nicht nur sequentiell an einem Projekt zu arbeiten, gibt es nun die Möglichkeit mit einem agilen Projektmanagement parallel an mehreren Prozessen zu arbeiten.

Vor allem bei der Dokumentation von Softwareprojekten wird auf eine agile Arbeitsweise wie die Scrum-Methode zurückgegriffen.

Hier organisieren sich beim agilen Arbeiten die Personen in kleinen Teams und setzen auf den direkten Austausch von Informationen über eine Rollenverteilung. Eine Person übernimmt die Rolle des Product Owner und kümmert sich um die Anforderungen an das Produkt bzw. Projekt.

Zusammen mit seinem Team erstellt der Product Owner das sogenannte Sprint Backlog. Dies enthält die gesammelten Aufgaben, die im Sprint durchgeführt werden sollen. Ein Sprint ist ein Projektprozess, in dem innerhalb eines festgelegten Arbeitszeitraumes festgelegte Aufgabenpakete erledigt werden. Üblicherweise dauert solch ein Sprint etwa 1- 4 Wochen. Der Product Owner bestimmt welche Aufgaben das Team im Sprint zu erledigen hat. Nicht erledigte Aufgaben wandern in den nächsten Sprint mit hinein.

Eine weitere Person des Teams übernimmt die Rolle des Scrum Masters und räumt zusammen mit dem Team Hindernisse weg und kümmert sich darum, dass das Team effizient zusammenarbeiten kann.

Die restlichen Personen des Teams bilden das Entwicklungsteam und kümmern sich selbstständig um die Umsetzung der im Sprint festgelegten Aufgabenpakete. Es finden während eines Sprints regelmäßige Meetings statt, die während der Projektdauer abgehalten werden. So findet täglich ein kurzes Treffen statt. Bei diesem wird besprochen, an was seit dem letzten Treffen gearbeitet wurde, welche Aufgaben bis zum nächsten Treffen bearbeitet werden sollen und ob es etwas gibt, was einen bei der Arbeit behindert.

Am Ende des Sprints findet ein Review statt, welches die Ergebnisse des Projektes zeigen und der Product Owner überprüft, ob alle Anforderungen erfüllt wurden oder ob bestimmte Teile in einen nächsten Sprint übernommen werden müssen.

Jetzt ist die Frage, braucht es überhaupt ein agiles Projektmanagement in der Technischen Redaktion? Reicht das normale Konzept des Wasserfallmodell nicht aus?

Moderne Produkte werden immer komplexer. Selbst einfache Produkte wie beispielsweise eine Kaffeemaschine können sehr komplex und umfangreich sein. Beispielsweise indem Softwarekomponenten auch mit in diese Maschinen verbaut werden. Die Kaffeemaschine kann sich dann mit dem Internet verbinden oder mit dem Smartphone gesteuert werden. Durch die anhaltend steigende Komplexität von Produkten verbreitet sich daher das agile Projektmanagement in immer mehr Unternehmen.

Wie anfangs bereits erwähnt, kann es schnell dazu kommen, dass die Technische Dokumentation vergessen wird. Oder ein Teilaspekt davon wird vernachlässigt. Das Produkt ist fertig und steht für die Auslieferung bereit. Die Anleitung liegt in Deutsch vor. Nur soll das Produkt ins Ausland verschickt werden und es fehlt die Übersetzung in die jeweilige Landessprache. Schon ist der Schlamassel groß. Nun muss eine Übersetzung her und zwar in Windeseile. Die Folge sind natürlich sehr hohe Kosten für den Hersteller. Die Anleitung muss aufgrund des Zeitmangels dann von mehreren Übersetzern bearbeitet werden. Mit etwas bessere Planung hätten hier viele Kosten gespart werden können.

Ein agiles Projektmanagement hätte in solch einem Fall sicher sehr gute Vorteile gehabt. Durch die Aufteilung von umfangreichen und komplexen Aufgabenstellungen in kleine Pakete wäre der Hersteller am Ende gar nicht in diese Situation gekommen.

Die fehlende Übersetzung wäre dann schon frühzeitig aufgefallen und hätte rechtzeitig erledigt werden können. Für deutlich weniger Geld.

Gibt es an dem agilen Projektmanagement eine Kehrseite?

Meistens kommt agiles Projektmanagement dann zum Einsatz, wenn die Projektanforderungen zu Beginn noch recht diffus sind. Projekte in der Technischen Dokumentation sind selten diffus, höchsten in den Feinheiten unklar.

Viele Technische Redakteure und Redakteurinnen sehen deswegen agiles Projektmanagement eher als ein Problem an. Durch die veränderte Arbeitsweise entsteht für sie gefühlt ein stärkerer Zeitdruck. Ergebnisse müssen nun innerhalb von vier Wochen präsentiert werden und nicht wie häufig nur alle 2-3 Monate am Ende des Projektes.

Dann könnte es aber auch so passieren, wie Anfangs erwähnt und die Technische Redaktion wird nicht über Änderungen des Produktes informiert. Ein agiles Team in der Produktentwicklung, in dessen Reihen dann auch ein Technischer Redakteur oder Redakteurin sitz, kann auf mögliche Änderungen regieren. Das Team kann entweder selbst die Übernahme der Änderungen in die Technische Dokumentation übernehmen oder ein entsprechendes anderes Team darauf ansetzen.

Diese Arbeitsweise ist den Mitarbeitern und Mitarbeiterinnen einer Technischen Redaktion nämlich nicht unbekannt. Jedes Dokumentationsprojekt setzt sich aus kleineren Einheiten zusammen. Die Informationen für das Projekt werden modulbasiert bzw. Topic-orientiert innerhalb des Teams verteilt.

Daraus lassen sich kleine Arbeitspakete ableiten wie Transport, Betrieb oder Wartung, die von der Technischen Redaktion abgearbeitet werden. Diese werden beispielsweise auch als User Stories im agilen Projektmanagement bezeichnet.

Eine User-Story hat eine festgelegte Form, bei der eine Person eine Rolle übernimmt, die eine bestimmte Funktion nutzt, um ein bestimmtes Ziel zu erreichen. Als Beispiel nenne ich hier den Technischen Redakteur bzw. den Grafiker als Rolle, welcher mit Hilfe einer Bildbearbeitungssoftware die bereitgestellten Technischen Zeichnungen des Produktes bearbeitet, um Abbildungen für die Technische Dokumentation zu erstellen.

Die ganzen Arbeitspakete bzw. User-Stories werden gesammelt, nach Ihrer Priorisierung aufgeteilt und dann von den Teammitgliedern abgearbeitet. Die Teammitglieder befassen sich zuerst mit denen Paketen, welche die höchste Priorisierung haben. Welches der Personen im Team gerade an welchem Paket arbeitet, stimmen die Teammitglieder in einem täglichen Meeting ab.

Die Abstimmung innerhalb des Teams sollte vorher festgelegt sein. Diese muss nicht in Präsenzsitzungen stattfinden. Auch rein virtuelle Treffen sind gerade heute kein Problem mehr. Die Corona-Pandemie hat uns gezeigt, wie einfach Online-Meetings über Tools wie Zoom oder Microsoft Teams abzuhalten sind. Die Teammitglieder legen vorher gewisse Kommunikationsetikette fest. Das können feste E-Mail-Regeln, der Umgang mit Kamera und Ton bei Videomeetings, Chat-Regeln und die Arbeitsstrukturen im Home-Office sein.

Durch Online-Projektmanagement-Tools lassen sich verteilte Teams zudem auch gut verwalten. Es gibt digitale Whiteboards, auf denen Aufgaben und Milestones notiert werden können. Eine digitale Pinnwand erhöht die Kreativität der Teammitglieder bei der Ideen- und Themensammlung. Auch Fragelisten, Kommentarfunktionen oder Umfragen lassen sich leicht über Kollaborationstools managen. Gerade das Feedback von Teammitgliedern, Führungskräften und anderen Mitarbeitern kann sinnvoll dazu beitragen, um Koordinationsprobleme, Disharmonien oder Informationsverlust im Projektverlauf zu vermeiden.

Das tägliche Meeting sollte vielleicht 15 Minuten dauern und jedes Mitglied des Teams berichtet, an welchem Arbeitspaket er bisher gearbeitet hat, ob er an diesem Paket Unterstützung benötigt oder welches Arbeitspaket er dann als nächstes angehen wird.

In einer Übersicht können die Teammitglieder festhalten, welche Arbeitspakete definiert sind, welche durch wen in Arbeit sind und welche erledigt sind.

Die anschließende Überprüfung der Ergebnisse aus den Arbeitspaketen ist ebenfalls ein wichtiger Bestandteil des agilen Projektmanagements. Bevor ein Arbeitspaket als abgeschlossen anzusehen ist, sollte dieses überprüft werden. Die Testkriterien müssen vorher festlegt sein, was das umgesetzte Arbeitspaket leisten bzw. erfüllen muss.

Nehmen wir unser Beispiel von oben mit der Erstellung von Abbildungen für die Technische Dokumentation. Diese Aufgabe kann nicht jeder im Team erfüllen. Im Idealfall hat sich natürlich ein Grafiker, um diese Aufgabe gekümmert. Das Endergebnis muss überprüft werden, ob die erstellten Abbildungen für den Endanwender der Technischen Dokumentation verständlich sind . Dies könnte durch einen Test erfolgen, indem eine Person aus der Anwendungszielgruppe diese Abbildung zum Anschauen bekommt. Ist die Abbildung für den Endanwender verständlich, kann diese in der Dokumentation verwendet werden. Dann kann das Arbeitspaket als abgeschlossen betrachtet werden.

Am Ende eines Sprints nimmt der Product Owner alle abgearbeiteten Arbeitspakete ab. Dann gleicht man die Arbeitspakete mit denen am Anfang festgelegten Anforderungen ab und erstellt mögliche neue Arbeitspakete bis das Projekt vollständig abgeschlossen ist.

Auf mögliche kurzfristige Änderungen kann der Product Owner so leicht reagieren. Dann kann es nicht dazu kommen, dass Teile der Dokumentation oder die Übersetzung der Dokumentation fehlen.

Der Abschluss im agilen Projektmanagement bildet die Präsentation bzw. Demonstration der fertigen Arbeitspakete. Hierbei unterscheidet sich das agile Projektmanagement nicht von dem klassischen Projektmanagement. Irgendwann müssen die Ergebnisse dem Kunden präsentiert werden. In unserem Fall wäre das die fertige Technische Dokumentation, die dem Kunden ausgehändigt wird.

Fassen wir zum Schluss der Folge nochmal kurz zusammen. Das agile Projektmanagement besteht aus den folgenden vier Hauptschritten.

1. Das Definieren und priorisieren von Anforderungen, welche das Produkt (in dem Fall die Technische Dokumentation) einhalten muss.
2. Erstellen der Arbeitspakete, welche hier auch als Informationsmodule bezeichnet werden können.
3. Überprüfen der Ergebnisse aus den Arbeitspaketen
4. Präsentation bzw. Demonstration des Produktes

Nun können Sie selbst den ersten Schritt zu einem agilen Projektmanagement wagen. Vielleicht kann diese Arbeitsmethode auch in Ihrer Technischen Redaktion eingebracht werden?