Organisation#

Da sich die Organsiation des Projekts in den zuvor besprochenen Werkzeugen und Workflows wiederspiegelt, wird diese erst an an dieser Stelle besprochen.

Der organisatorische Aufbau von Projekten kann sehr unterschiedlich sein, jedes Projekt sollte daher sein eigenes Projektstatut oder Readaktionsstatut, bzw. eine eigene Projektdokumentation besitzen, in welcher die Abweichungen und Besonderheiten im Vergleich zu einem Standardpublikationsprojekt beschrieben sind.

Projektleiter, Redaktion, Chefredakteur#

Jedes Projekt hat einen primären Projektverantwortlichen.

Für Projekte mit mehreren Beitragenden bzw. mit einer komplexeren Organisationsstruktur kann eine Redaktion gemäß der Statuten des CCCA mit eigenem Redaktionsstatut eingerichtet werden. Einer Redaktion steht ein Chefredakteur vor. Der Projektverantwortliche oder Chefredakteur ist der primäre Ansprechpartner für alle Projektdetails. Er ist die höchste Instanz für inhaltliche und oraganisatorische Entscheidungen.

Workflow#

../../_images/AASS-Cover-3.0.0.var-1.pdf.png

Die Arbeits- und Ausbildungsstandards für den Sanitätsdienst, später fortgeführt als Kompendium des CCCA, werden seit 2008 von der ARGE AASS bzw. dem CCCA als Gemeinschaftsprojekt entwickelt und herausgegeben. Dementsprechend ist die Organisation der Entwicklung und Wartung von entscheidender Wichtigkeit.

Bis zur Version 3 erfolgte die Entwicklung in Anlehnung an das agile Projektmanagement-Modell Scrum. Dabei erfolgt die Arbeit in Entwicklungszyklen, sogenannten Sprints, welche i. d. R. 3 Monate dauern. Am Anfang jedes Sprints werden Entwicklungsziele für den jeweiligen Zyklus vereinbart, diese werden dann innerhalb des Sprints umgesetzt und am Ende findet ein gemeinsames Review statt, bei welchem die Entwicklungen des Sprints vorgestellt, begutachtet und diskutiert, sowie anschließend entweder angenommen oder verworfen werden.

../../_images/Scrum_Framework.png

Abb. 1 Das Schema des Scrum-Prozesses#

Ⓒ Dr. Ian Mitchell, https://en.wikipedia.org/wiki/File:Scrum_Framework.png ℓ CC BY-SA 4.0

Dies ermöglicht ein hohes Maß an gegenseitiger Abstimmung und Qualitätssicherung, und war insbesonders im ersten Entwicklungsprozess ideal. Andererseits erfordert dieses Modell allerdings einen festen Zeitplan und viele Präsenzzeiten für das Herausgeber-Team und ist daher dauerhaft in dieser Form schwer zu bewerkstelligen. Daher, und durch die zunehmende Perfektionierung von Teleworking-Tools, sowie aufgrund der Neuausrichtung der AASS zu dem designierten Nachfolgeprojekt „Kompendium des CCCA, welches die bisherigen AASS auf ein neues Fundament heben soll, ist die Entwicklungsarbeit des Projekts einem radikalem Umbau zu einem digitalen, kontinuierlichen Workflow unterworfen.

Zusammenarbeit#

Die Organisation der Arbeit am Projekt ist eine große Herausforderung. Bei der Entwicklung der AASS geschah vieles in „physischer Präsenzform“ im Sinne von regelmäßiger Treffen als Beteiligter und Stakeholder. Dabei war von Vorteil, dass die AASS im Grunde eine zielgerichtete Entwicklungsstrategie verfolgte: Das Werk sollte in den Rettungssanitäterkursen des ASB Floridsdorf-Donaustadt eingesetzt werden. Dadurch ergaben sich viele Entwicklungsziele und die Motivation der Beteiligten, die in Personalunion diese Kurse durchführten bzw. an ihnen beteiligt waren. Auch richteten sich die Zeitvorgaben nach den Terminen der Kurse.

Das Kompendium ist jedoch von diesen äußeren Vorgaben entkoppelt, und auch das persönliche Ziel der einzelnen Mitwirkenden und die Bereitschaft, Zeit zu investieren, ist viel individueller. Dem muss die Projektorganisation Rechnung tragen und dies in die Entwicklungsstrategie einbeziehen. Ein fixes Entwicklungszyklus-Modell mit abschließendem Review für alle Bereiche erscheint in diesem Kontext als nicht sinnvoll.

Eine vordefinierte Best-Practice-Lösung kann es derzeit auch noch nicht geben, da die Evaluation der Bedürfnisse und Erwartungen der Mitwirkenden noch nicht erfolgt ist (was wesentlich daran liegt, dass es noch keinen soliden Grundstock an Mitwirkenden bzw. Anzahl von regelmäßigen Mitarbeitern, gibt und dieser derzeit erst angeworben wird).

Somit bleibt festzuhalten dass die zukünftige Redaktions- und Reviewstruktur noch nicht feststeht und im Team diskutiert und gemeinsam festgelegt werden wird.

Einige Grundideen seien aber hier angeführt:

Digitaler, Internet-basierter Workflow#

Viele Arbeiten bzw. Abläufe sollen ortsunabhängig gestaltet werden, sodass sie nach Möglichkeit auch von weit entfernten Teilnehmern problemlos und mit hoher Qualität durchgeführt werden können. Präsenzzeiten, also „echte, physische“ Treffen sollen grundsätzlich weiterhin stattfinden, sollen aber möglichst Zeit-effizient organisiert sein, sodass sie den einzelnen Teilnehmern einen Mehrwert (in- und außerhalb des Projekts) bringen (fachlicher Austausch, Brainstorming, Besprechung von Themen die von Angesicht zu Angesicht einfacher zu bereden sind, Socialisen und Networking).

Analog zum Konzept des „Home Office“, welches – zumindest theoretisch – ähnliche Ideen und Strategien verfolgt, liegt der Aufbau einer entsprechenden digitalen, Internet-basierten, Infrastruktur zur Zusammenarbeit (Kollaboration) nahe. Da es sicher nicht in unseren Bereich fällt, eigene Technologien oder Software zu entwickeln, ist es ratsam, bereits in der Industrie bewährte Lösungen an unsere Bedürfnisse anzupassen.

Im Speziellen hat die Softwareentwicklung ähnliche Herausforderungen zu bewältigen (verteilte Teams, Notwendigkeit für Reviews, Qualitätssicherung, Projektmanagement). Besonders die Community-basierte Entwicklung von freier Software, bei welcher Programmierer ehrenamtlich und geographisch oft weit verteilt sind, weist große Parallelen zu unserer Situation auf. Lösungen wie verteilte Versionsverwaltungssysteme und Kollaborations-Web-Plattformen mit Diskussions- und Projektmanagementfunktionen sind seit Jahren in diesen Bereichen populär und werden steig weiterentwickelt.

Einige dieser Techniken, z. B. das verteilte Versionsverwaltungssystem Git, wurden schon seit über 10 Jahren bei der Entwicklung der AASS eingesetzt. Auch das mittlerweile zur Erzeugung des Kompendiums eingesetzte System der Sphinx-Toolchain war ursprünglich eigentlich als Dokumentationssystem der Programmiersprache Python gedacht und hat sich mittlerweile in vielen anderen Publikationsprojekten bewährt.

Es erschient somit logisch, die vorhandenen Werkzeuge zu nutzen und Tätigkeiten bzw. Anforderungen wie Diskussionen, Arbeitspläne, Review u. ä. zumindest teilweise über solche Kollaborationsplattformen zu realisieren. Problematisch kann sein, dass deren Bedienung sich vor allem an den Bedürfnissen von Entwicklern orientiert und damit unerfahrene Mitarbeiter oft ein gewisses Verständnisproblem haben. Das wird sicher dadurch verstärkt, dass wir gegenwärtig noch keinen vorgegebenen Workflow haben wie Standardaufgaben (Review, Zweige in der Versionsverwaltung etc.) zu erledigen sind – wir sind generell noch in einem Ausprobierstadium.

Essentiell ist es somit einen gewissen Grundstock an technisch versierten Mitarbeitern zu haben, die den weniger Technik-affinen Hilfestellung geben bzw. diesen derzeit noch komplizierte Arbeitsschritte abnehmen, Bedienungsprobleme identifizieren können und Vorschläge für gute Standard-Workflows machen.

Digitaler Workflow auf GitLab#

Gitlab ist eine Web-basierte Plattform, welche einerseits einen relativ bequemen Zugriff auf die Versionsverwaltung (Git) ermöglicht, andererseits aber wesentliche Möglichkeiten für das Projektmanagement bietet (virtuelle Whiteboards, Ticket-System, Wiki, Diskussionsfunktionen, …). Außerdem erlaubt es die Bearbeitung von Textdateien direkt im Webbrowser, ohne dass sonst irgendwelche Software installiert werden muss.

Aktuell sind neben dem derzeit in Überarbeitung befindlichen Kompendium auch die im Entwurf befindlichen neuen Statuten des CCCA als Projekt auf Gitlab zu finden. Mitarbeiter können sich somit einen Benutzer auf Gitlab erstellen, dem Projektleiter diesen nennen, damit dieser den Benutzer in das Projekt aufnimmt und den Zugriff ermöglicht, und dann z. B. direkt den Entwurf der neuen Statuten bearbeiten und Vorschläge einbringen.

Die Webseite von Gitlab lautet https://gitlab.com.

Creative Commons Lizenzvertrag Dieses Werk ist lizenziert unter der Creative Commons Namensnennung - Weitergabe unter gleichen Bedingungen 3.0 Österreich Lizenz (CC BY-SA 3.0 AT). Einzelne Beiträge und Medien können abweichend lizensiert sein.