Zum Inhalt

Modul: Analysen bewerten und interpretieren#

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

Inhalt

Die Interpretation von Analysen gewinnbringend zu vollziehen hängt von vielen individuellen Faktoren ab. Es wird jeweils ein prinzipielles Vorgehen vorgeschlagen und anhand von Beispielen konkrete Szenarien betrachtet sowie die Erfahrungen geteilt, die die Veranstaltenden und Teilnehmenden in diesen Situationen gemacht haben. In diesem Zuge wird auf allgemeine Einflussfaktoren hingewiesen, die während dieser Tätigkeiten zu beachten sind, um z. B. Fehlschlüsse beim Interpretieren oder aufkommenden Unmut unter den Teilnehmenden durch eine ungeschickte Kommunikation zu vermeiden. Eine wichtige Voraussetzung ist dafür die Qualität (also die Richtigkeit) der Analysen sowie den positiven Nutzen sicherzustellen.

Rolle

AnalyseevaluatorIn

Nachdem die Analysen durchgeführt wurden, gilt es, Informationen abzuleiten sowie diese sinnvoll und positiv einzusetzen.

Achtung vor fehlerhaften Analysen

Schnell lässt man sich dazu verleiten, den modellierten Daten zu vertrauen und daraus (falsche) Schlüsse zu ziehen. Besonders gefährlich ist es, wenn dadurch zuvor aufgestellte Hypothesen bestätigt werden. Fehlerhafte Analysen führen zu fehlerhaften Interpretationen und diese können zu einer falschen Betrachtung der Realität führen. Daraus können Situationen entstehen, die negative Effekte auf die Lehrveranstaltung und die Beteiligten haben.

Aus diesem Grund wird hier ausdrücklich darauf hingewiesen, dass alle Analysen kritische auf ihre Richtigkeit hin zu untersuchen sind.

Qualität und positiven Nutzen sicherstellen#

Bevor die Analysen genauer betrachtet werden, sollten sie auf etwaige offensichtliche Fehler hin untersucht werden. Dazu können die folgenden (und ähnliche) kritischen Fragen gestellt und beantwortet werden:

  • Sind die richtigen und alle Daten berücksichtigt/importiert worden?
  • Sind die richtigen Zeiträume gewählt worden?
  • Stehen die Analysen im Einklang mit der Realität oder sind Widersprüche zu bekannten Strukturen/Fakten/Prozessen zu erkennen?
    • Entspricht z. B. die Anzahl der agierenden Personen denen, die an der Lehrveranstaltung beteiligt sind?
  • Decken sich die Zahlen oder stehen diese im Widerspruch zueinander?
    • Entspricht z. B. die Summe aufgeteilter Werte (auf Personen, Wochentage etc.) dem Gesamtwert?
  • Sind die Daten in den Darstellungen richtig/sinnvoll zueinander in Beziehung gesetzt worden?
    • Sind z. B. die Skalen bei vergleichenden Darstellungen einheitlich gewählt worden?

Anschließend sollte überprüft werden, ob die Analysen überhaupt die Analysefragen adressieren. Die Analysen können nicht nur die Fragen verfehlen, sie können auch zu wenig oder sogar auch zu viel Detailgrad bieten.

  • Stellen die Analysen Informationen dar, die dabei helfen, die Analysefragen zu beantworten?

Werden offensichtliche Fehler festgestellt, bestehen Unklarheiten oder adressieren die Analysen nicht die Analysefragen, ist dies zu klären, bevor mit der Interpretation begonnen wird.

Außerdem ist es wichtig, vor der Interpretation zu überprüfen, ob die abgestimmten Persönlichkeitsrechte der agierenden Personen gewahrt werden. Ist z. B. nur die Untersuchung pseudonymisierter Daten vereinbart -- wovon in diesem Kontext hier ausgegangen wird -- so dürfen von keiner Person einzelne Pseudonyme durch die Darstellungen aufgeschlüsselt werden können. Sein eigenes Verhalten in den Darstellungen wiederzuerkennen kann sehr leicht sein, wenn man z. B. die einzige Person ist, die etwas getan oder gelassen hat. Jedoch lässt sich bei genügend Wissen über andere Personen auch deren außergewöhnliches Verhalten wiedererkennen. Daraus können sich Diskriminierungen ergeben, die möglichst zu vermeiden sind.

  • Zeigen die Darstellungen außergewöhnliches Verhalten, mit dessen Hilfe einzelne Pseudonyme aufgeschlüsselt werden können?
  • Zeigen die Darstellungen außergewöhnliches Verhalten, auf dessen Grundlage einzelne Personen oder Gruppen von Personen diskriminiert werden könnten?

Wenn dies der Fall ist, müssen die Darstellungen angepasst werden (z. B. durch Ausblenden der Pseudonyme). In einigen Fällen müssen diese auch verworfen werden, wenn keine Anpassungen ohne zu großen Informationsverlust möglich sind.

Dies zuvor geschilderte Vorgehen wird jetzt auf die beispielhaften BI und PM Analysen aus dem Modul: Analysieren von Fakten, Strukturen und Verhalten teilweise angewendet (für einen eingeschränkten Zeitraum).

BI: Jira Status#

Beispielhafte Power BI Analyse bzgl. der Ticketnutzung - Seite 1.

Beispielhafte Power BI Analyse bzgl. der Ticketnutzung - Seite 2.

Untersuchung offensichtlicher Fehler:

  • Stehen die Analysen im Einklang mit der Realität oder sind Widersprüche zu bekannten Strukturen/Fakten/Prozessen zu erkennen?
    • In dem betrachteten Zeitraum hätten 29 Personen (26 Teilnehmende und drei Veranstaltende) Jira Issues erstellen können.
      • Die Anzahl der Ersteller von 24 liegt im akzeptablen Bereich.
    • In dem betrachteten Zeitraum existierten fünf Projekte, die zu untersuchen waren.
      • Die Anzahl der betrachteten Projekte stimmt.
    • Die Personen hatten jeden Tag in der Woche die Möglichkeit Jira Issues zu erstellen und zu pflegen.
      • Dass z. B. auch am Wochenende Events zu verzeichnen sind, muss kein Fehler sein.
  • Decken sich die Zahlen oder stehen diese im Widerspruch zueinander?
    • Aufsummiert ergeben die aufgeteilten Jira Issues nach erstellenden Personen (Seite 1, links) das gleiche Ergebnis, wie die Summe der erstellten Jira Issues (Seite 1, rechts). Nämlich 173.
    • Allerdings widerspricht die gesamte Anzahl in der Darstellung der zugewiesenen Jira Issues (Seite 2, rechts) nicht diesem Wert (173 gg. 177). -> zu untersuchen
    • Aufsummiert ergeben die Statusänderungen nach Wochentag (Seite 2. unten) das gleiche Ergebnis, wie die Summe der Statusänderungen (Seite 2, rechts). Nämlich 476.
  • Sind die Daten in den Darstellungen richtig/sinnvoll zueinander in Beziehung gesetzt worden?
    • In der Darstellung der zugewiesenen Jira Issues nach Ersteller (Seite 1, unten) wurde eine Skala in Prozent gewählt. Dadurch wird der Anteil der zugewiesenen Jira Issues dargestellt.
      • Aufgrund der stark abweichenden Anzahl von Jira Issues, die die Personen erstellt haben, wurde korrekterweise dieser Ansatz genutzt. Zuvor wurden diese Informationen in das Diagramm auf der linken Seite integriert, haben hier jedoch keinen Mehrwert geliefert.

Untersuchung der abgestimmten Persönlichkeitsrechte:

  • Zeigen die Darstellungen außergewöhnliches Verhalten, mit dessen Hilfe einzelne Pseudonyme aufgeschlüsselt werden können?
    • Anzahl der erstellten Jira Issues nach Personen (Seite 1, links)
      • Handlung: Ersteller ausgeblendet
    • Anzahl der zugewiesenen Jira Issues nach Ersteller (Seite 1, unten)
      • Handlung: Ersteller ausgeblendet
  • Zeigen die Darstellungen außergewöhnliches Verhalten, auf dessen Grundlage einzelnen Personen oder Gruppen von Personen diskriminiert werden könnten?
    • Anzahl von zugewiesenen Jira Issues nach Projekt (Seite 2, links)
      • Handlung: Projekte ausgeblendet

PM: Jira Status#

Beispielhafter Prozess der Jira Issue Statusübergänge (`Activities`: 100%, `Paths`: 100%, `Performance`: `Median duration`, `Secondary`: 'Absolute frequency')

Untersuchung offensichtlicher Fehler:

  • Stehen die Analysen im Einklang mit der Realität oder sind Widersprüche zu bekannten Strukturen/Fakten/Prozessen zu erkennen?
    • Es sind nur Status abgebildet, die in den betrachteten Projekten konfiguriert sind.
    • Die einzelnen Statusübergänge spiegeln fast den erlaubten Workflow wider.
      • Die Schleifen an den Status sind nach dem aktuellen Workflow nicht erlaubt. -> zu untersuchen
      • Der Übergang von To Do nach Done ist nach dem aktuellen Workflow nicht erlaubt. -> zu untersuchen
      • Eine genauere Untersuchung ergibt, dass in dem betrachteten Zeitraum zu Beginn in einem der betrachteten Projekte der Workflow nicht korrekt konfiguriert war. Sie sind also nicht per se falsch. Weitere Nachforschungen ergaben, dass eine frühere Analyse dieses Fehlverhalten aufgedeckt hat. In einem der betrachteten Projekte war der Workflow nicht korrekt konfiguriert. Wird dieser Zeitraum herausgefiltert, so verschwinden die Schleifen und der nicht erlaubte Übergang.
  • Decken sich die Zahlen oder stehen diese im Widerspruch zueinander?
    • Die Anzahl der Vorkommnisse der einzelnen Status müsste sich mit den Zahlen aus den BI Berichten decken.
      • Dies ist an dieser Stelle nicht zu bewerten, da unterschiedliche Zeiträume und Filter eingesetzt wurden.
  • Sind die Daten in den Darstellungen richtig/sinnvoll zueinander in Beziehung gesetzt worden?
    • Für die verstrichene Zeit zwischen den Status wurde der Median gewählt, um starken Ausreißern entgegenzuwirken.
    • Außerdem wurde zur Zeitdauer, zusätzlich die Häufigkeit angezeigt, was eine sinnvolle Ergänzung ist, um anzuzeigen, aus wie vielen Vorkommnissen sich der Median ergibt. Daraus lässt sich z. B. schließen, wie relevant eine genauere Untersuchung bestimmter Übergänge ist.

Unten wird ein Prozess präsentiert, in dem die Cases herausgefiltert werden, die Schleifen an einzelnen Status und/oder den Übergang von To Do nach Done beinhalten.

Untersuchung der abgestimmten Persönlichkeitsrechte:

Da in der Darstellung weder Personen noch Gruppen betrachtet werden, bestehen hier keine Gefährdungen der Persönlichkeitsrechte.

Sollte die Belegung der Spalten anders gewählt werden und z. B. die Personen als Activity genutzt werden, muss geprüft werden, ob die Pseudonyme der Personen nicht ausgeblendet werden sollten (die Pseudonyme stehen dann in den Knoten, wo jetzt die Statustypen stehen). Diese Herangehensweise kann sinnvoll sein, wenn z. B. untersucht werden soll, in welcher Reihenfolge Personen an einzelnen Issues arbeiten und ob sich in diesen Reihenfolgen dominante Muster abzeichnen.

Interpretation#

Ziel der Interpretation ist es, die Analysen in einen realweltlichen Zusammenhang zu bringen, um so Informationen abzuleiten, die gewinnbringend eingesetzt werden können.

Die Interpretation durchgeführter Analysen wird immer vor dem Hintergrund der ausgehenden Analysefrage durchgeführt. Die Interpretation von Analysen ist eine individuelle und keine einfache Tätigkeit. Es müssen unterschiedliche Einflussfaktoren, wie z. B. der allgemeine Kontext und die Erwartungen, die Menge an Daten, die Anzahl der Personen und die Phasen der Lehrveranstaltung/der betrachtete Zeitraum einbezogen werden.

Um die Veranstaltenden und Teilnehmenden in den Lehrveranstaltungen zu unterstützen, kann es nützlich sein, konkrete Anpassungsvorschläge abzuleiten. Diese können ihnen vorschlagen, inwiefern sie ihr Verhalten anpassen sollten, um z. B. einem abgezielten Verhalten (welches erlernt werden soll) stärker zu entsprechen. In anderen Fällen können diese auch Anpassungen für die Struktur der Lehrveranstaltung oder den zurzeit angebotenen Lernmaterialien beinhalten.

Hinweis

Die analysierenden Personen müssen das Erkenntnis erlangen, dass die Ergebnisse der Datenanalyse kein Spiegel der Realität sind, sie also kein umfassendes Abbild dieser vermitteln. Durch die Datenanalyse wird lediglich ein Ausschnitt abstrakt und vereinfacht betrachtet.

Hinweis

Die Schlüsse und die Informationen, die durch die Interpretation gezogen/generiert werden, können davon abhängen, wer diese Interpretation durchführt. Denn die Ergebnisse werden zu Teilen von dem Vor- und Kontextwissen der analysierenden Personen beeinflusst.

Für die Interpretation kann wie folgt vorgegangen werden:

  • Bekannte Fakten festhalten (betrachteter Zeitraum, aktive Teilnehmende, vorherige Analysen etc.)
  • Erwartungen formulieren
  • Darstellungen beschreiben und Fakten extrahieren
  • Übereinstimmungen, Abweichungen und sonstige Auffälligkeiten festhalten
  • Hypothesen für die Übereinstimmungen und Abweichungen formulieren (und ggf. überprüfen)
  • Einschränkungen der Interpretationsfähigkeit benennen
  • Anpassungsvorschläge ableiten

Um eine konkrete Vorstellung eines möglichen Interpretationsvorgangs zu vermitteln, werden im Folgenden ausgewählte Teile der BI und PM Analysen für "Jira Status" (siehe oben) besprochen. Erläuterungen zu den oben abgebildeten Grafiken sind hier zu finden.

BI: Jira Status#

Wie verteilen sich die Ticketerstellungen über die Teilnehmenden?

Diese Frage wird in erster Linie von dem linken Diagramm der BI Analyse "Jira Status" Seite 1 adressiert.

Bekannte Fakten

  • Der betrachtete Zeitraum entspricht sieben Wochen (von der eine Woche die Pfingstferien waren). [Anmerkung: Dieser Zeitraum dient hier lediglich als Beispiel. In den sieben Wochen, wurden alle zwei Wochen Zwischenberichte veröffentlicht. Zur Verstärkung des Lerneffekts sollte das Feedback zeitnah und nicht erst nach z. B. sieben Wochen gegeben werden.]
  • In diesem Zeitraum waren 26 Teilnehmende aktiv.

Erwartungen

  • Alle Teilnehmenden erstellen Tickets. Das war so vorgegeben, damit die Ticketerstellung (weiter) geübt wird.
  • Alle Teilnehmenden erstellen ähnlich viele Tickets. Die Abweichung ist gering. Nur einige Teilnehmende könnten viele Tickets erstellt haben, wenn sie z. B. in mehreren Planungs-Meetings die groben Tickets (Task) der nächsten Woche für das gesamte Team erstellt haben.
  • Auch in diesem Fall sollten von den Verantwortlichen (Assignee) zusätzlich detailliertere Tickets (Sub-Task) erstellt werden.

Darstellung beschreiben und Fakten extrahieren

  • Die Erstellung von Tickets verteilt sich ungleichmäßig über die Teilnehmenden. Der maximale Wert liegt bei 18, der minimale bei 1.
  • Es werden nur 24 Balken dargestellt. Dieser Wert wird von "Anzahl von Ersteller" auf der rechten Seite bestätigt.

Übereinstimmungen, Abweichungen und sonstige Auffälligkeiten festhalten

Entgegen der Erwartungen ...

  • haben nur 24 von 26 Teilnehmende Tickets erstellt.
  • ist die Abweichung (1 zu 18) sehr hoch.

Hypothesen

  • Einige der Teilnehmenden haben in den sechs Wochen kaum gearbeitet, benutzen dafür keine Tickets oder haben sehr große Tickets. -> zu untersuchen
  • Einige Teilnehmende planen für ihr gesamtes Team. -> zu untersuchen

Einschränkungen

  • Wenn die Teilnehmenden keine Tickets erstellen aber trotzdem arbeiten, spiegelt sich das in dieser Darstellung nicht wider. Somit kann nicht auf die Gesamtzahl erbrachter/geplanter Arbeitsleistungen geschlossen werden.

Anpassungsvorschläge

  • Alle Teilnehmenden sollten Tickets erstellen.
  • Grobe Tickets (Tasks), die z. B. während eines Planungs-Meetings erstellt werden, sollten durch Sub-Tasks von den Verantwortlichen (beim/vorm Bearbeiten) verfeinert werden.

Die genannten Anpassungsvorschläge sind nicht neu, sondern finden sich bereits in den Verhaltenskonventionen, die den Teilnehmenden bekannt sind. Somit trägt diese Analyse dazu bei, die vereinbarten Verhaltenskonventionen zu überprüfen und auf diejenigen hinzuweisen, die noch nicht ausreichend verinnerlicht wurden.

PM: Jira Status#

Werden die Status richtig gepflegt (sind die Zeiten zwischen den Status realistisch)?

Diese Frage wird in unserem Beispiel von der folgenden (korrigierten, s. o.) PM Analyse adressiert.

Beispielhafter Prozess der Jira Issue Statusübergänge *korrigiert* (`Activities`: 100%, `Paths`: 100%, `Performance`: `Median duration`, `Secondary`: 'Absolute frequency')

Bekannte Fakten

  • Der betrachtete Zeitraum entspricht sieben Wochen (von der eine Woche die Pfingstferien waren).
  • Mögliche Status und die intendierten Statusübergänge:

Workflow der Statusübergänge für Jira Issues (Task und Sub-Task).
  • Tickets insgesamt: 173 (durch BI, siehe oben)

Erwartungen

  • Der Median des Statusübergangs von To Do nach In Progress liegt nicht im Sekunden- oder wenigen Minutenbereich.
  • Der Median des Statusübergangs von In Progress nach Done liegt zwischen ein und zwei Stunden.

Darstellung beschreiben und Fakten extrahieren

  • Dargestellt ist der Prozess der Statusübergänge der Tickets (nach dem Herausfiltern nicht mehr erlaubter Statusübergänge).
  • In den Knoten stehen die Status sowie ihre absolute Häufigkeit.
  • An den Übergängen steht der Median in verstrichener Zeit und die absolute Häufigkeit.
  • Insgesamt werden 166 Tickets betrachtet.
  • Die Übergänge, die im Median am längsten dauern, sind To Do nach Aborted und Waiting nach Aborted.
  • Die Abstände zwischen den Statusübergänge, die in den Erwartungen erwähnt wurden, betragen im Median
    • To Do nach In Progress 43,5 Minuten, bei 142 Vorkommnissen
    • In Progress nach Done 78,4 Minuten, bei 124 Vorkommnissen

Übereinstimmungen, Abweichungen und sonstige Auffälligkeiten festhalten

  • Der Statusübergang von To Do nach In Progress entspricht der Erwartung. Die Teilnehmenden scheinen nach der Erstellung eines Tickets im Median 43,5 Minuten später mit der Bearbeitung zu beginnen.
  • Der Statusübergang von In Progress nach Done entspricht der Erwartung. Die Teilnehmenden scheinen nach dem Beginn der Bearbeitung eines Tickets im Median 78,4 Minuten später diese abzuschließen.
  • Von insgesamt 24 (zeitweise) abgebrochenen Tickets (Aborted), wurden fünf im Median innerhalb von 75 Sekunden wieder geöffnet (Reopened).
  • Von insgesamt sieben (zeitweise) wartenden Tickets (Waiting), wurden fünf im Median innerhalb von 2 Sekunden wieder geöffnet (Reopened).
  • Drei Tickets wurden, nachdem sie (zeitweise) beendet wurden (Done) wieder geöffnet (Reopened). Im Median hat dies 72 Sekunden gedauert (Max: 42 Minuten, Min: 2 Sekunden).

Hypothesen

  • In einigen Fällen scheinen die Status Waiting und Aborted nur versehentlich gesetzt worden zu sein. Dies ist aus der kurzen Verweildauer zu schließen.
  • Dass die beiden fokussierten Statusübergänge den Erwartungen entsprechen zeigt, dass die Teilnehmenden mittlerweile (dies ist Phase 3 der Lehrveranstaltung) zufriedenstellend mit den Status arbeiten. ** [Anmerkung: Zusätzlich könnte hier die tatsächlich gebuchte Zeit untersucht und in dem gegenübergestellt werden.]
  • Der Status Waiting wird nur wenig benutzt und dazu in einigen Fällen anscheinend fehlerhaft. Entweder ist den Teilnehmenden die Verwendung dieses Status nicht klar oder sie haben keine Verwendung für ihn, weil sie z. B. nur wenige Abhängigkeiten untereinander haben, durch die sie aufeinander warten müssen. -> zu untersuchen

Einschränkungen

  • Die Statusübergänge können nur als Events bewertet werden. Die tatsächliche aktive Arbeitszeit der Teilnehmenden kann davon abweichen, wenn sie nicht korrekt den Status des Tickets verändert haben.
    • -> zu untersuchen Zum Beispiel: Wenn die Teilnehmenden ihre Arbeitszeit auf Tickets buchen, wie verhält sich diese im Median zu der Zeit, die hier an dem In Progress nach Done Status steht?
  • Durch die Wahl der Darstellung und Nutzung des Medians werden nur gemittelte Werte betrachtet. Um z. B. Ausreißer und deren Ursachen zu untersuchen, müssten weitere Filter angewendet und ggf. weitere Daten hinzugezogen werden.

Anpassungsvorschläge

  • Um versehentliche Statusübergänge rückgängig zu machen und sie so bereits bei der Datenaufzeichnung zu vermeiden, kann möglicherweise eine Erweiterung für Jira installiert werden, die diese Funktionalität ermöglicht. Die Teilnehmenden müssten außerdem gebeten werden, diese Funktionalität zu nutzen und nicht dem allgemeinen Workflow zu folgen.
  • Den Teilnehmenden nochmal den Status Waiting und seine Verwendung erläutern.

Ergänzung

In früheren Analysen der gleichen Lehrveranstaltung ist z. B. aufgefallen, dass die Statusübergänge von To Do nach In Progress sowie von In Progress nach Done beide sehr kurze Zeitdauern hatten (im Median nur wenige Sekunden). Daraus wurde die Hypothese abgeleitet, dass die Status nicht richtig benutzt worden sind, sondern lediglich (irgendwann) nach Beendigung der Tätigkeit schnell hintereinander gesetzt wurden. Der resultierende Anpassungsvorschlag war, die Status und ihren Nutzen den Teilnehmenden erneut zu erklären und sie darum zu bitten, diese sorgfältig zu nutzen. Wie hier zu sehen ist, hat sich dieses Verhalten positiv entwickelt.

Übergreifend#

Potential birgt auch eine Kombination der BI und PM Analysen, welches ausgeschöpft werden sollte.

In dem obigen Beispiel ließen sich mit Hilfe der PM Analyse z. B. auch in der BI Analyse die nicht erlaubten Statusübergänge herausfiltern und so nur korrekte Status-Workflows betrachten. Außerdem bieten in der BI Analyse die Darstellungen der Statusübergänge nach Wochentag sowie Uhrzeit (Seite 2, Mitte oben und unten) die Möglichkeit, weiter zu untersuchen, inwiefern die Statusübergänge richtig genutzt werden.