Modul: Daten aufzeichnen#

Vorgehensmodell für die Datenanalyse: Hervorgehoben sind die Abschnitte, die von diesem Modul abgedeckt werden.

Inhalt

Die aufzuzeichnenden Daten sind maßgeblich von den Zielen abhängig, die durch die Analysen erreicht werden sollen. Es wird beschrieben, wie mit Hilfe der technischen Umgebung Daten aufgezeichnet werden können und wie dies die Ausprägung der technischen Umgebung beeinflusst. Außerdem wird die Wichtigkeit von Verhaltenskonventionen in der menschlichen Umgebung für die Datenaufzeichnung betont und beschrieben, wie diese Verhaltenskonventionen kommuniziert werden können.

Rolle

DatenversteherIn

Abhängigkeiten der Datenaufzeichnung#

Damit eine Analyse bestimmte Ziele erreichen kann, werden Daten benötigt, aus denen der Informationsgewinn generiert werden kann. Werden von der technischen Umgebung diese Daten bisher nicht, nur teilweise oder fehlerhaft aufgezeichnet, gilt es, die technische Umgebung entsprechend anzupassen. Bei der (Weiter-)Entwicklung einer LLUA sollten grundlegende Fähigkeiten der Datenaufzeichnung berücksichtigt werden, auch wenn zu Beginn nur die Organisation und Kollaboration und nicht die Datenanalyse im Vordergrund steht.

Des weiteren ist die Datenaufzeichnung nicht nur von den Fähigkeiten der technischen Umgebung, sondern auch von dem Mitwirken der menschlichen Umgebung -- also den Personen -- abhängig. Wenn diese die technische Umgebung nicht oder falsch nutzen, können keine bzw. fehlerhafte Daten aufgezeichnet werden. Aus diesem Grund ist es notwendig, dass den Personen Verhaltenskonventionen erklärt und sie zu dessen Einhaltung motiviert werden.

Zu Beginn der Entwicklung einer LLUA sind in der Regel nicht alle Ziele definiert, die durch die Analyse von Daten erreicht werden sollen und es werden im Lauf der Zeit neue hinzukommen. In der Vergangenheit nicht aufgezeichnete Daten können eventuell verhindern oder erschweren, dass diese neuen Ziele erreicht werden. Dadurch gingen z. B. Möglichkeiten für die Ursachenforschung oder für semesterübergreifende Vergleiche verloren. Dennoch sollte darauf verzichtet werden, Daten aufzuzeichnen und zu speichern, für die auch in Zukunft keine Verwendung gesehen wird (ausgenommen sind hier natürlich Daten, die die LLUA selbst zur Erfüllung ihrer Funktionalitäten oder die AdministratorIn zur gewissenhaften Durchführung ihrer Arbeit benötigt). Auf der anderen Seite sollten den Personen keine Verhaltenskonventionen auferlegt werden, mit denen Daten aufgezeichnet werden können, für die es bisher keine Verwendung gibt. Aus diesen Gründen sollten folgende Grundsätze verfolgt werden:

Wenn (nahe) Ziele existieren, bestimmte Sachverhalte zu untersuchen, so sollten Maßnahmen ergriffen werden, die korrespondierenden Daten aufzuzeichnen und zu speichern.
Wenn keine (nahen) Ziele existieren, bestimmte Sachverhalte zu untersuchen, so sollten diese Daten nicht aufgezeichnet werden.
Wenn die LLUA mit Fähigkeiten der Datenaufzeichnung ausgestattet wurde und später neue Erkenntnisse dazu führen, dass diese Daten nicht benötigt werden, so sollten diese Fähigkeiten abgeschaltet und die aufgezeichneten Daten gelöscht werden.
Verhaltenskonventionen für die Datenaufzeichnung werden den Personen nur auferlegt, wenn für die daraus resultierenden Daten aktuell eine Absicht der Analyse besteht.

Technische Umgebung#

Die technische Umgebung ist das zentrale Werkzeug, mit welchem die Daten aufgezeichnet werden, und kann entsprechend der Analyseabsichten ausgerichtet bzw. angepasst werden. Bei der Konzeption einer LLUA mit konkreten Analyseabsichten sollte die Datenaufzeichnung also von Beginn an berücksichtigt werden. Ein wichtiger Faktor dabei ist, dass der Zugriff auf die aufgezeichneten Daten gewährleistet sein muss. Die Wahl einer Cloud-basierten proprietären Lösung, ohne umfangreiche Individualisierungsmöglichkeiten und ohne Zugriff auf die Daten, ist somit nicht anzuraten.

Dennoch werden sich im Laufe der Nutzung einer LLUA voraussichtlich neue Analyseabsichten ergeben und die LLUA muss weiterentwickelt werden. Aus diesem Grund sollte bei der Auswahl der Werkzeuge für eine LLUA darauf geachtet werden, dass diese möglichst (modular) erweiterbar/konfigurierbar sind, um sie an die individuellen Bedürfnisse anzupassen.

Generelle Attribute, die die Daten beinhalten bzw. aus ihnen gewonnen werden sollten, um Analysen durchzuführen:

Aktion, die ausgeführt wurde
Person/Programm, die/das die Aktion ausgeführt hat
Zeitpunkt der Aktion (für Process Mining essentiell)

Da die individuellen Bedürfnisse breit gefächert sein können, kann hier nicht das ganze Spektrum abgedeckt werden. Im Folgenden werden stattdessen einige Beispiele genannt, wie konkrete Datenaufzeichnungen in eine LLUA prinzipiell und konkret integriert werden können.

Organisation und Koordination von Aufgaben#

Prinzipiell

Um herauszufinden, wie und wann die Teilnehmenden ihre Aufgaben Organisieren und Koordinieren, kann die Funktionalität geboten werden, Aufgaben in Form von Tickets/Issues explizit zu beschreiben. Alleine durch die Menge an Tickets pro Team ließen sich z. B. Erkenntnisse darüber gewinnen, wie feingranular die Teams ihre Tätigkeiten planen. Durch entsprechende Zeitstempel ließen sich außerdem die Zeitpunkte identifizieren und so ggf. intensive Planungsaktivitäten erkennen.

Durch die Möglichkeit, diese Tickets im Status zu verschieben, ließe sich z. B. herausfinden, wann an welchen Aufgaben gearbeitet wird und ob die Teilnehmenden diese Art des Projektmanagements bereits beherrschen oder sie stärker darin geschult/darauf hingewiesen werden sollten. So könnte außerdem untersucht werden, wer an welchen bzw. an wie vielen Tickets gearbeitet hat oder ob es bestimmte Ticketstatus gibt, die einen Flaschenhals darstellen, weil sie z. B. nur von bestimmten Rollen/Personen bearbeitet werden können.

Soll herausgefunden werden, wer für welche Aufgaben zuständig ist bzw. die Verantwortlichkeit übernimmt, kann die Funktionalität hilfreich sein, dass einem Ticket eine Person zugeordnet werden kann.

Konkret

Solche Funktionen werden in der Regel von sogenannten Issue-Trackern bereitgestellt. In der exemplarischen LLUA wird für diesen Bereich die Issue-Tracker Funktion von Jira eingesetzt. Diese deckt z. B. alle oben genannten Funktionen ab und bietet darüber hinaus eine Vielzahl individueller Konfigurationsmöglichkeiten (siehe auch den Abschnitt Konfiguration von Jira in diesem Handbuch).

Arbeitszeiterfassung#

Prinzipiell

Um zu untersuchen, wie viel Arbeitszeit die Teilnehmenden oder ganze Teams investieren muss eine Möglichkeit der Zeiterfassung zur Verfügung stehen. Für detailliertere Analysen ist es sinnvoll, dass die investierte Zeit im Kontext der Aufgaben bzw. der Tickets gebucht werden kann. Die Buchung der Arbeitszeit an einem Ticket pro Person sollte als Funktion also bereitstehen. So lässt sich herausfinden, für welche Aufgaben wie viel Zeit benötigt wurde und wie viele Personen an einer Aufgabe gearbeitet haben (alle Personen, die Zeit auf eine Aufgabe buchen, haben aller Wahrscheinlichkeit nach auch an der Aufgabe gearbeitet). Daraus lassen sich ggf. weitere Schlüsse über geeignete (Klein-)Gruppen und KooperationspartnerInnen ziehen.

Zusätzlich sollte sich angeben lassen, für welchen Zeitraum die Arbeitszeit gebucht werden soll, sollte diese nicht gerade erst abgeschlossen sein, sondern die Buchung zu einem späteren Zeitpunkt stattfinden. Die aufgezeichneten Daten sollten sowohl auch den Zeitpunkt beinhalten, wann die Buchung der Arbeitszeit durchgeführt wurde. So lässt sich z. B. analysieren, wann die Teilnehmenden arbeiten und spekulieren/einschätzen, wie verlässlich die Arbeitszeitangaben sind.

Außerdem ist es hilfreich, wenn die benötigte Arbeitszeit für ein Ticket zuvor geschätzt werden kann. So können z. B. Analysen ermöglicht werden, die die Abweichung von geschätzter und tatsächlich benötigter Zeit untersuchen.

Konkret

Jira bietet von Haus aus die Funktion der Arbeitszeitbuchung an einem Ticket an. Für eine elaborierte Arbeitszeitbuchung wurde in der exemplarischen LLUA Jira um das Plugin WorklogPRO erweitert. Dieses ermöglicht es außerdem individuelle Felder für den Worklog zu definieren, die Arbeitszeit via eines Widgets zu stoppen (funktioniert wie eine Stoppuhr) und bietet eine gute Übersicht inkl. Filtermöglichkeiten aller gebuchten Worklogs (siehe auch den Abschnitt Konfiguration WorklogPRO in diesem Handbuch).

Arten von Tätigkeiten#

Prinzipiell

Für die Analyse, für welche Art von Tätigkeit wie viel Arbeitszeit benötigt wird, ist es hilfreich, wenn bei der Buchung der Arbeitszeit die Art der Tätigkeit bestimmt werden kann. Dies kann z. B. durch ein weiteres Eingabefeld realisiert werden. Es hat sich gezeigt, dass für sinnvolle Auswertungen möglichst Auswahlmöglichkeiten (z. B. in Form eines Drop-Down-Menüs) bereitgestellt werden sollten. Freitext-Felder sind -- wann immer es möglich ist -- zu vermeiden.

Konkret

Jira um das Plugin WorklogPRO erweitert (siehe oben).

Zugriff auf Lehr- und Lernmaterialien#

Prinzipiell

Damit die Zugriffe auf Lehr- und Lernmaterialien untersucht werden können, müssen diese in einer Umgebung bereitgestellt werden, welche die Zugriffe aufzeichnet. Hilfreich ist es, wenn die aufgezeichneten Daten auch den Zeitpunkt eines Zugriffs beinhalten, um z. B. Zeiträume und Abfolgen von Zugriffen zu bestimmen. So können Analysen durchgeführt werden, die z. B. untersuchen, zu welchen Zeitpunkten und in welcher Reihenfolge auf die Materialien zugegriffen wird oder in welchem Kontext (z. B. Bearbeitung eines Tickets) welche Materialien abgerufen werden.

Hinweis

In einem solchen Szenario sollte berücksichtigt werden, dass bereits heruntergeladene Materialien von den Teilnehmenden offline genutzt werden können, ohne dass die LLUA diese Zugriffe aufzeichnen kann (Aktivitäten auf lokalen/privaten Endgeräten werden nicht aufgezeichnet).

Konkret

In der exemplarischen LLUA werden die Lehr- und Lernmaterialien in Confluence bereitgestellt oder verlinkt. Außerdem wurde Confluence um das Access Log Plugin erweitert, um die Aufzeichnung aller Zugriffe und Aktivitäten (wie z. B. create, view, update, delete, download und preview) zu vereinfachen.

Kommunikationsstrukturen#

Prinzipiell

Die Untersuchung von (digitalen) Kommunikationsstrukturen kann auf unterschiedlicher Basis erfolgen, abhängig davon, welche Arten von Kommunikation und Kommunikationsmedien mit in die Analyse eingeschlossen werden sollen.

Alleine die Teilnahme an einem Meeting, ohne weitere Informationen, wie z. B. Redeanteil oder Rolle im Meeting, können einen Aufschluss über die Struktur bzw. den Informationsfluss ermöglichen. An dieser Stelle wird als beispielhaftes Kommunikationsmedium ein textbasierter Chat betrachtet.

Ein Chat-Programm, das (kurzlebige, spontane) Einzel- und Gruppen-Chats sowie (langlebige) kontextorientierte Kommunikation (wie z. B. in thematischen Channels) ermöglicht und die einzelnen Chat-Nachrichten, Antworten sowie Reaktionen (Quick-Reactions) aufzeichnet, bietet umfangreiche Möglichkeiten der Analyse.

So lassen sich z. B. die direkte Kommunikation einzelner Personen aber auch Kommunikationen mehrerer Personen untersuchen und daraus Strukturen ableiten. Außerdem werden so Analysen ermöglicht, die darauf abzielen, ineffizientes Kommunikationsverhalten (wie z. B. eine Person dient als Mittels-Mann/Frau) zu identifizieren und ggf. Gruppenbildungen vorzuschlagen. Auch die generelle Aktivität einzelner Personen/Gruppen lässt sich so untersuchen und daraus ggf. Vorschläge für die Veranstaltenden ableiten, dass diese befragt werden sollen, ob sie Hilfe benötigen oder ihnen etwas fehlt, um weiterzuarbeiten.

Nachrichteninhalte

Dieser Hinweis ist keine rechtliche Beratung, sondern dient lediglich dem freundlichen und erfolgreichen Einsatz der Datenanalyse in projektbasierten Lehrveranstaltungen.

Aus Einhaltung des Datenschutzes und der Wahrung von Persönlichkeitsrechten, sollten Nachrichteninhalte nicht Bestandteil der Analyse sein.

Hinweis

Es hat sich gezeigt, dass es nicht immer leicht ist, die Teilnehmenden zu motivieren, ein möglicherweise ungewohntes Chat-Programm zu nutzen. Einige Teilnehmende greifen -- auch nach häufigem Bitten und Motivieren -- lieber auf Dienste wie WhatsApp zurück. Dies sollte bei der Interpretation der Analysen berücksichtigt werden.

Konkret

In der exemplarischen LLUA wird als Chat-Programm Mattermost eingesetzt. Alle Beteiligten einer Lehrveranstaltung werden in ein Team eingeladen. In diesem Team-Bereich können sowohl öffentliche als auch private Channels erzeugt werden. Diese können z. B. für thematische oder gruppenorientierte Kommunikation eingesetzt werden. Direkte Einzel- und Gruppen-Chats können erstellt werden. All dies und jede Nachricht, Antwort sowie Reaktion wird von Mattermost in der Datenbank hinterlegt und kann somit ausgewertet werden.

Verhaltenskonventionen#

Verhaltenskonventionen existieren in projektbasierten Lehrveranstaltungen auf unterschiedlichen Ebenen (z. B. menschlicher Umgang, Einhaltung der universitären Regeln und Einhaltung der Lehrveranstaltungsregeln). Diese können sowohl implizit existieren als auch explizit benannt werden (z. B. kann für das Bestehen der Lehrveranstaltung die aktive Teilnahme an 12 von 14 Präsenzterminen explizit gefordert werden).

Hier stehen die Verhaltenskonventionen im Fokus, die die Datenaufzeichnung betreffen.

Datenaufzeichnung#

Diese Verhaltenskonventionen sollten explizit benannt werden, damit sichergestellt ist, dass alle Veranstaltenden und Teilnehmenden das gleiche Verständnis von ihnen haben.

Ein Beispiel für eine solche Verhaltenskonvention könnte sein, dass die Teilnehmenden ihre Arbeitszeit erfassen sollen. Verfolgen die Veranstaltenden damit lediglich das Ziel, herauszufinden, wie viel Zeit von den Teilnehmenden in die einzelnen Phasen, Wochen oder Tage der Lehrveranstaltung investiert wird, so genügt es, die Arbeitszeit auf der jeweiligen Ebene zu erfassen. Wollen die Veranstaltenden eine genauere Auswertung machen, um zum Beispiel herauszufinden, für welche Tätigkeiten wie viel Zeit investiert wird, so ist auch die Verhaltenskonvention eine andere bzw. detailliertere.

Von der technischen Umgebung müssen für die jeweilige abgezielte Zeiterfassung entsprechende Funktionen bereitgestellt werden, denn die Arbeitszeit soll natürlich nicht auf individuelle Weise in Dateien oder ähnlichem dokumentiert werden (s. o.). Das Ziel ist es, auswertbare und korrekte Daten zu erhalten, die möglichst wenig Vorverarbeitung benötigen (siehe auch Abschnitt Konfiguration der WorklogPRO App in Jira).

Für eine genaue Auswertung bietet es sich z. B. an, dass die Teilnehmenden instruiert werden, für alle ihre Tätigkeiten Tickets zu erstellen und die Arbeitszeit direkt im Kontext des jeweiligen Tickets einzutragen. Weitere beispielhafte Konventionen, die bei der Erprobung der LLUA im Sinne der Datenaufzeichnung zum Einsatz kommen, sind:

der aktuelle Status eines Jira Tickets muss die Realität widerspiegeln (z. B.: wird gerade an der Aufgabe gearbeitet: In Progress; ist die Aufgabe abgeschlossen: Closed)
jedem Jira Ticket ist eine verantwortliche Person zuzuweisen (spätestens vor Beginn der Arbeit)
wenn eine Versionsverwaltung für Programmcode genutzt wird, müssen die Commit Messages die ID des zugehörigen Jira Tickets beinhalten
die gesamte Dokumentation der Tätigkeiten muss in Confluence erstellt bzw. dort hochgeladen werden
die textuelle Kommunikation erfolgt mittels Mattermost

Verhaltenskonventionen an einem Beispiel

Hier wird das vorherige Beispiel aufgegriffen, das die Verfeinerung der Analysefrage "Wie viele Tätigkeiten (Tickets) werden in dieser Lehrveranstaltung bisher insgesamt verfolgt?" beschreibt. Damit diese Analysefrage untersucht werden kann, muss ihr die folgende Verhaltenskonvention vorausgehen:

die Teilnehmenden erstellen Tickets für ihre Tätigkeiten, um ihre Arbeit in den Teams zu organisieren

Durch die Untersuchung der Analysefrage kann u. a. die Einhaltung der geforderten Verhaltenskonvention überprüft werden.

Außerdem muss in dem genannten Beispiel diese weitere Verhaltenskonvention gelten:

jedem Ticket wird eine verantwortliche Person zugewiesen

Gilt diese Verhaltenskonvention nicht, so ist die Untersuchung der Analysefrage "Wer ist für diese Tickets als VerantwortlicheR zugewiesen?" wenig zielführend, da das Ergebnis nicht repräsentativ ist. Möglicherweise ist kein einziges Ticket einer Person zugewiesen, da die Teilnehmenden nicht dazu aufgefordert wurden.

Kommunikation von Verhaltenskonventionen#

Bei der Kommunikation der Verhaltenskonventionen sollte sichergestellt werden, dass sie alle Veranstaltenden und Teilnehmenden erreicht. Besonders wichtige oder komplizierte Verhaltenskonventionen sollten an einer zentralen Stelle textuell festgehalten werden, sodass alle Beteiligten die Konventionen nachlesen können. Außerdem sollten Veranstaltende nicht davor zurückschrecken, solche Verhaltenskonventionen im Verlauf der Lehrveranstaltung oft zu betonen. Dies ist besonders wichtig, wenn sich z. B. durch Datenanalysen abzeichnet, dass sich die Einhaltung bestimmter Konventionen wieder verschlechtert.

Die Erfahrung hat gezeigt, dass die Verhaltenskonventionen nicht nur deutlich kommuniziert, sondern auch motiviert werden müssen. Wenn die Teilnehmenden die Verhaltenskonventionen nicht als sinnvoll erachten, werden sie diese möglicherweise nicht einhalten.

Teilnehmende die zuvor noch nicht in einem größeren Projekt mit anderen Personen zusammengearbeitet haben, könnten z. B. nur schwerlich den Nutzen von Tickets erkennen. Sie könnten diese Tätigkeit lediglich als Overhead betrachten und sind somit wenig gewillt, Tickets zu erstellen und zu pflegen. Hier gilt es, ein anschauliches Beispiel zu wählen und so die Vorteile dieses Verhaltens hervorzuheben.

Für die Motivation ist es hilfreich, wenn die Verhaltenskonventionen, wie die Erstellung und Pflege von Tickets, einen direkten Nutzen für die Teilnehmenden haben, der anschaulich vorgetragen werden kann. Es kommt jedoch auch vor, dass Verhaltenskonventionen eingeführt werden müssen, die keinen direkten Nutzen für die Teilnehmenden haben, weil ein bestimmter Sachverhalt untersucht werden soll.

Die Veranstaltenden wollen z. B. untersuchen, ob die Teilnehmenden ihre Arbeitszeit wie vorgesehen in die einzelnen Tätigkeitsarten (z. B. Meeting, Setup, Entwurf, Implementation und Testen) investieren. Auf dieser Grundlage wollen sie herauszufinden, was den Teilnehmenden schwer fällt oder in welchen Bereichen weitere Materialien bereitgestellt werden sollten. Dazu erweitern sie die technische Umgebung so, dass bei der Buchung der Arbeitszeit, ebenfalls eine Tätigkeitsart angegeben werden kann/muss. Dies hat für die Teilnehmenden zunächst keinen direkten Nutzen und wird von einigen vielleicht sogar als nervig empfunden.

Möglicherweise erreicht man einige Teilnehmende über ihr Interesse daran, dass sie selbst einsehen können, wie sich ihre Arbeitszeit auf die Tätigkeitsarten verteilt (sollte die technische Umgebung diese Möglichkeit bieten). Eine bessere Motivation wäre in diesem Falle, die Absichten der Veranstaltenden offen zu legen. Die Verbesserung der Lehrveranstaltung und die Aussicht darauf, dass die Tätigkeiten in Zukunft einfacher werden, weil z. B. mehr Materialien bereitstehen, kann die Teilnehmenden motivieren. Außerdem kann ihnen so gezeigt werden, dass sie in die Verbesserung der Lehrveranstaltung involviert werden und sie durch gewissenhaftes Handeln diese mitgestalten können.