Bei wissenschaftlicher Zusammenarbeit ist das Anstrengendste oft nicht die Aufgabenverteilung, sondern die Weitergabe von Kontext. A bittet B, einen Abschnitt eines Übersichtsartikels zu überarbeiten, doch B findet die von A genannte Literaturstelle nicht; C schickt eine Datentabelle in die Gruppe, und drei Tage später fragt D wieder: „Wo ist diese Tabelle?“ Der Kern dieser Reibung ist nicht Faulheit, sondern dass Informationen über Chat, E-Mail und Cloud-Speicher verstreut sind und es keine gemeinsame Arbeitsfläche gibt. Die gemeinsame Forschungswerkstatt von MuchSci ist genau für dieses Problem konzipiert: Sie bringt „Menschen, Agenten und Dateien“, die eine Projektgruppe benötigt, in denselben Raum, damit alle rund um denselben Kontext vorankommen.
Man versteht sie, indem man „Chat-Tool“ und „Kollaborationscontainer“ trennt. Ersteres übermittelt Nachrichten, Letzteres erhält den vollständigen Kontext eines Projekts. Die gemeinsame Forschungswerkstatt gehört zu Letzterem.
01 Die eigentliche Schwierigkeit wissenschaftlicher Zusammenarbeit ist nicht die Aufgabenverteilung, sondern die Kontextweitergabe
Zuerst ein besonders anschaulicher Vergleich.
▲ Abb. 1 | Ein normaler Gruppenchat ist nach dem Gespräch vorbei; die gemeinsame Forschungswerkstatt bewahrt Materialien, Rollen und Prozess auf
Das Problem gewöhnlicher Kommunikation ist nicht, dass man keine Nachrichten senden kann, sondern dass Nachrichten und Dateien mit der Zeit in den Hintergrund geraten. Das vor drei Tagen gesendete PDF, die letzte Woche festgelegte Struktur, die im letzten Monat diskutierte Hypothese – all das muss manuell wieder hervorgeholt werden.Der Kontext wissenschaftlicher Zusammenarbeit ist kumulativ, nicht jede Runde beginnt bei null. Wenn der Container diese Kumulation nicht tragen kann, müssen Teammitglieder Erklärungen immer wieder wiederholen.
Die gemeinsame Forschungswerkstatt gibt jedem Projekt einen eigenen Raum. In diesem Raum gibt es feste Mitglieder, gebundene Agenten, projektbezogene Dateien und einen Verlauf. Öffnet man ihn, kehrt man zum Stand beim letzten Verlassen zurück. Das ist besonders für Projekte wichtig, die sich über Wochen oder Monate erstrecken.
02 Wie die Projektgruppe drei Objekttypen zusammenbringt
Öffnet man in MuchSci „Meine Projektgruppen“, sieht man das Grundgerüst einer Projektgruppe.
▲ Abb. 2 | Im Inneren der gemeinsamen Forschungswerkstatt: Mitglieder, Agenten und Dateien teilen sich denselben Raum
Die erste Ebene sind die Mitglieder. Projektgründer und normale Mitglieder werden in der Liste klar unterschieden. Diese Unterscheidung ist nicht nur ein Kennzeichen; sie entscheidet, wer die Projektstruktur anpassen darf und wer die Projektgruppe verlassen kann. In wissenschaftlicher Zusammenarbeit gibt es ohnehin Rollenunterschiede; werden sie explizit gemacht, lassen sich spätere Berechtigungsstreitigkeiten verringern.
Die zweite Ebene sind die Agenten. Eine Projektgruppe kann mehrere Agenten binden, etwa Literaturrecherche, Büroassistent, Chemoinformatik usw. Nach der Bindung reicht es, wenn Mitglieder im Chat `@` eingeben, um sie aufzurufen. Das bedeutet: Agenten sind keine Werkzeuge außerhalb des Dialogs, sondern ständige Mitglieder der Projektgruppe.
Die dritte Ebene sind die Dateien. Wissensdatenbank, Literatur, Entwürfe und Liefergegenstände bleiben beim Projekt und werden nicht von neuen Chatnachrichten verdrängt. Dateien und Dialog befinden sich im selben Container; bei der Diskussion kann man Materialien direkt referenzieren, statt einen Dateilink zu werfen und alle selbst suchen zu lassen.
03 Was ist anders, wenn man in einer Projektgruppe spricht, als in einem Gruppenchat?
Der Screenshot zeigt eine Projektgruppe namens „Industrieabteilung“. Auf ihrer Karte stehen die gebundenen Agenten; unten befindet sich die Schaltfläche „Gemeinsame Forschungswerkstatt betreten“.
▲ Abb. 3 | Liste „Meine Projektgruppen“: Eine Projektgruppe bindet mehrere Agenten; Klick öffnet den Kollaborationsraum
Nach dem Betreten der Projektgruppe wirkt die Oberfläche eher wie eine Projektwerkbank. Oben stehen „Zurück zu Industrieabteilung“ und „Chatverlauf“; rechts gibt es drei Tabs: Mitglieder, Agenten, Dateien; das Eingabefeld unten zeigt den Hinweis „@ eingeben, um einen gebundenen Projektgruppen-Agenten aufzurufen, z. B.: @Büroassistent Hilf mir, ein Redemanuskript zu erstellen“, daneben der Einstieg „+ Wissensdatenbank“.
▲ Abb. 4 | Im Inneren der Projektgruppe: Die Mitgliederliste unterscheidet Gründer und normale Mitglieder; im Chat kann man Agenten direkt mit @ aufrufen
Der Schlüssel hier ist der „@“-Mechanismus. In einem normalen Chat ruft man mit @ eine Person herbei, damit sie eine Nachricht ansieht; im Chat einer Projektgruppe ruft man mit @ einen Agenten auf und nutzt seine Fähigkeiten. Dasselbe Eingabefeld kann Nachrichten an Mitglieder senden und Aufgaben an Agenten vergeben. Durch dieses Design werden Agenten Teil des Kollaborationsablaufs und nicht ein separat zu öffnendes Plugin.
04 Wann sollte man eine Projektgruppe erstellen?
Nicht jede Zusammenarbeit braucht eine Projektgruppe. Je klarer man die Szenarien abgrenzt, desto besser lässt sie sich einsetzen.
▲ Abb. 5 | Nur Projekte mit langer Laufzeit, hohem Kontextbedarf und der Notwendigkeit einer Agentenbeteiligung rechtfertigen eine Projektgruppe
Für einmalige Mitteilungen und Diskussionen, die sich in wenigen Minuten klären lassen, reicht gewöhnliche Kommunikation. Wenn es aber ein Projekt ist, das Wochen oder Monate dauert, bei dem man Materialien wiederholt durchsehen muss, mehrere Personen gemeinsam Dateien bearbeiten müssen und Agenten an Recherche oder Schreiben beteiligt werden sollen, dann sind die Container-Vorteile der gemeinsamen Forschungswerkstatt deutlich. Sie ersetzt nicht den Chat, sondern gibt langfristiger Zusammenarbeit eine stabile Kontextbasis.
▲ Abb. 6 | Von der Erstellung der Projektgruppe bis zum iterativen Entwurf bleibt der Kontext stets im Projektraum
In der Praxis sieht der Ablauf ungefähr so aus: Projektgruppe erstellen, Dateien ablegen, im Chat Agenten mit @ aufrufen, rund um den gemeinsamen Kontext iterieren und schließlich übergeben. Das Wertvolle daran ist: Die Nachvollziehbarkeit des gesamten Prozesses wird nicht zusätzlich dokumentiert, sondern ist im Container angelegt.
05 Grenzen
Wie üblich werden die Grenzen offen benannt.
① Dieser Beitrag beschreibt die funktionale Einordnung und den Mechanismus, nicht eine Wirkungszusage. Eine Projektgruppe kann Kontext bündeln, garantiert aber keine effiziente Zusammenarbeit; die tatsächliche Wirkung hängt auch von Nutzungsgewohnheiten der Mitglieder, Klarheit der Aufgaben, Art der Dateiorganisation und weiteren Faktoren ab.
② Die Aufteilung der Berechtigungen zwischen Projektgründer und normalen Mitgliedern muss von den Beteiligten verstanden werden. Funktionell werden Rollen unterschieden, aber akademische Einschätzungen, Aufgabenverteilung und Zuordnung geistigen Eigentums innerhalb des Projekts müssen weiterhin vom Team selbst vereinbart werden.
③ Für Dateien und Diskussionsinhalte, die innerhalb einer Projektgruppe geteilt werden, gelten die Forschungsdatenmanagement- und Datenschutzvorgaben der jeweiligen Einrichtung. Bei nicht veröffentlichten Daten, sensiblen Informationen oder Vertraulichkeitsvereinbarungen von Partnern sind die aktuell geltenden Regelungen der Einrichtung maßgeblich.