Masterarbeit "Themen und Entscheidungen im Zeitverlauf eines Restrukturierungsprojekts"
Hintergrund
Bei <Firma> ist ein x-köpfiges Entwicklerteam gerade dabei, eine (von überwiegend anderen Personen entwickelte) bestehende und im Produktivbetrieb befindliche Webanwendung stark zurestrukturieren.
Die Anwendung dient zu <Anwendungszweck>. Die Firma verdient mit dieser Anwendung ihr Geld und der Betrieb muss kontinuierlich aufrecht erhalten werden.
Die Entwickler sind recht jung und wenig erfahren.Ziele
Diese Arbeit untersucht, wie sich im zeitlichen Verlauf die Themen ändern, mit denen sich das Team befasst:- Wie viele Themen gibt es in jedem Themenkreis? (siehe unten)
- Wann und warum kommen Sie auf?
- Wann und warum treten Sie wieder in den Hintergrund?
- Welche Lösungsmöglichkeiten wurden jeweils diskutiert? Ausprobiert?
- Wie hat sich unterwegs die Einschätzung der Entwickler verändert:
- Zur Themenwichtigkeit?
- Zur Eignung jeder Lösungsmöglichkeit?
- Zu sinnvollen nächsten Schritten?
- Zur Bewertung vergangener Schritte: Zu früh? Zu spät? Zu wenig? Zu viel?
- Zur Bewertung des Erreichten?
- Welche Einschätzungen oder Entscheidungen haben sich als eher zutreffend oder eher nicht zutreffend herausgestellt?
- Welche wiederkehrenden Muster ergeben sich in diesen Verläufen?
Datensammlung
Um den Zeitverlauf zu ermitteln, werden gleichartige Daten erhoben zu mindestens 10 Zeitpunkten im Zweiwochenabstand und zwar überwiegend im Rahmen von Teamtreffen, die ungefähr den Planungsmeetings und Retrospektiven eines Scrum-Prozesses entsprechen. Nötigenfalls erfolgen jeweils im Anschluss genauere Nachfragen bei einzelnen Teammitgliedern zur Klärung von Mehrdeutigkeiten. Dazu wird eine fortlaufende Themenliste geführt, die im ersten Termin angelegt und in jedem späteren fortgeschrieben wird (Themen zufürgen und entfernen). Die Themen werden folgenden Themenkreisen zugeordnet: Software-Entwurfs/-struktur, eingesetzte Technologie, Vorgehensweise, Disziplin/Qualität. Konkrete Anforderungen und Funktonen der Software sind keine Themen. Zu jedem Thema gibt es anfangs eine Liste von Ideen, wie man damit umgehen kann, und zu jeder Idee eine Einschätzung, was ihre Vor- und Nachteile sind, wie wichtig diese jeweils sind und wie vielversprechend die Idee insgesamt im Vergleich zu den anderen beim gleichen Thema ist. Gleich oder später entscheidet man sich für ein Vorgehen in Bezug auf das Thema und entwickelt dazu im Folgenden wiederum eine Einschätzung. Das Vorgehen kann gelegentlich wechseln oder mehrgleisig sein. Die Einschätzungen sind anfangs Erwartungen, später auch Bewertungen. Beispiel:Themen könnten anfangs z.B. sein A:"Wir brauchen ein Framework für <Ziel X>" oder später dann B:"Wir müssen Funktion Y zuverlässiger bekommen".
Ideen zu A könnten z.B. sein: A1:"Angular benutzen!" oder A2:"ReactJS benutzen!". Ideen zu B könnten z.B. sein: B1:"Y neu schreiben" oder B2:"4-6 automatisierte Tests für Y implementieren".
Ein Nachteil von A1 könnte sein: A1N1:"Zu hoher Lernaufwand, weil Angular so umfangreich ist." und eine Einschätzung daraufhin A1E1:"Wir werden das nicht gut genug beherrschen, sondern herumstümpern."
Ein Vorgehen könnte daraufhin sein: AV1:"Wir evaluieren erstmal ReactJS und schieben Angular auf". Bei jedem Folgetreffen kann eine Idee oder ein Vorgehen zu einem existierenden Thema hinzukommen (weil es neu entdeckt wurde oder erneut wichtig geworden ist) oder verschwinden (weil es inzwischen als zu unwichtig angesehen wird). Es kann auch ein ganzes Thema hinzukommen oder verschwinden, alles in der Regel per Mehrheitsentscheid. Jedes Treffen wird aufgezeichnet (Audio), um die Themen, Ideen und Einschätzungen präzise erfassen und mit wörtlichen Zitaten belegen und illustrieren zu können. Die Einschätzungen werden auch quantifiziert und zwar jede Einschätzung von jeder Person einzeln auf folgenden Skalen:
Erwartungen und Bewertungen für Themen: 4:sehr wichtig, 3:wichtig, 2:wenig wichtig, 1:unwichtig, 0:weiß nicht.
Erwartungen für Ideen: 4:sehr hilfreich, 3:etwas hilfreich, 2:neutral, 1:schädlich, 0:weiß nicht.
Bewertungen für Ideen: 4:gut, 3:eher gut, 2:eher schlecht, 1:schlecht, 0:weiß nicht. (Diese Daten kann man per Audio sehr schnell sammeln, wenn jeder Entwickler einen Kennbuchstaben bekommt (A,B,C,D…) und Karten mit 0-4 darauf. Jeder hält eine Karte hoch und der Forscher spricht das Ergebnis ein: "A3, B2, C2, D4". Geschwindigkeit ist wichtig, denn die Zahl solcher Abstimmungen kann erheblich ausfallen.)
Datenanalyse
Zwischen den Datensammlungsterminen ist jeweils Dutzende von Stunden Zeit für eine gründliche Analyse auf folgende Fragen; separat für jedes Thema, gruppiert nach Themenkreisen:- Was ist das Thema? Wo verstehen Teammitglieder ein Thema verschieden?
- Wann taucht es auf? Warum? Wann verschwindet es? Warum?
- Wie verändert sich das Thema graduell im Zeitverlauf?
- Was sind die Ideen zu dem Thema? Wo verstehen Teammitglieder eine Idee verschieden?
- Wann tauchen die Ideen auf? Warum? Wann verschwinden sie? Warum?
- Welche werden umgesetzt? Welche nicht? Warum? (Die Diagnose "ohne jeden erkennbaren Grund" ist zulässig.)
Welche Entscheidungsgrundlagen (Fakten, eigene Einschätzungen, Quellen aus dem Netz, etc.) werden benutzt?
Welche Entscheidungsverfahren werden benutzt (Abstimmung, Do-ocracy, Anordnung, …) - Wie ändern sich die Einschätzungen über die Zeit? Warum? Wo gibt es dabei größere Unterschiede zwischen den Teammitgliedern?
- Welche Themen haben eine ähnliche Verlaufsstruktur?
- Gibt es typische Ähnlichkeiten pro Themenkreis?
- Welche Gründe für Verläufe kommen bei vielen Themen vor?
- Welche Vermutungen über das Team lassen sich aus den Mustern aufstellen? (Fazit)
Ausarbeitung
Die Ausarbeitung besteht aus drei Teilen:- Einführung in das Thema mit Beschreibung der Ausgangssituation und Diskussion verwandter Forschungsarbeiten.
- Beschreibung des Zeitverlaufs: Themen (mit Ideen und Einschätzungen sowie deren Bewertungen). Alle wichtigen Behauptungen werden mit mindestens einem Zitat belegt bzw. illustriert.
- Darstellung der Muster und des Fazits