When Domains Collide: An Activity Theory Exploration of Cross-Disciplinary Collaboration
Diese Studie nutzt die Aktivitätstheorie, um durch eine Mixed-Methods-Forschung mit Interviews und einer Umfrage die Erwartungen und daraus resultierenden Reibungen in der interdisziplinären Zusammenarbeit zwischen Domänenexperten und Softwareentwicklern zu analysieren und praktische Lösungsansätze aufzuzeigen.
Originalarbeit lizenziert unter CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). Dies ist eine KI-generierte Erklärung des untenstehenden Papers. Sie wurde nicht von den Autoren verfasst oder gebilligt. Für technische Genauigkeit konsultieren Sie das Originalpaper. Vollständigen Haftungsausschluss lesen
Stellen Sie sich vor, Sie bauen ein riesiges, komplexes Haus. Aber anstatt nur Architekten und Bauarbeiter zu haben, arbeiten Sie mit einem Team aus Experten für alles Mögliche zusammen: Ein Physiker weiß genau, wie das Fundament den Boden berühren muss, ein Biologe erklärt, wie das Haus auf Pilze reagiert, und ein Mediziner sorgt dafür, dass die Räume für Operationen geeignet sind.
Das ist das Szenario dieser Studie: Cross-Disciplinary Software Development (CDSD). Das bedeutet, dass Software-Entwickler (die "Bauarbeiter") und Fachexperten aus anderen Bereichen (die "Physiker", "Ärzte" etc.) Seite an Seite am selben Code arbeiten. Sie gehören zum selben Team, teilen sich die Verantwortung und bauen das Produkt gemeinsam.
Klingt toll, oder? Theoretisch ja. In der Praxis ist es oft wie ein Tanz, bei dem jeder eine andere Musik hört.
Hier ist die einfache Erklärung der Studie, übersetzt in eine Geschichte:
1. Das Problem: Wenn zwei Welten aufeinandertreffen
Die Forscher haben herausgefunden, dass diese Teams oft aneinander vorbeireden. Nicht weil die Leute dumm sind, sondern weil sie unterschiedliche Philosophien haben.
- Der Software-Entwickler (SDE) denkt: "Wir müssen sauber bauen, alles dokumentieren und sicherstellen, dass das Haus in 10 Jahren noch steht." (Qualität, Struktur, Sicherheit).
- Der Fachexperte (DE) denkt: "Ich brauche das Haus jetzt, um meine Experimente zu machen. Wenn es heute funktioniert, ist es gut. Wir können später aufräumen." (Geschwindigkeit, Ergebnis, Experiment).
Das führt zu Reibungen. Der Entwickler fühlt sich wie ein Hausmeister, der ständig den Dreck wegmachen muss, den der Experte hinterlässt. Der Experte fühlt sich wie ein Künstler, der von einem strengen Lehrer ständig korrigiert wird, obwohl er nur malen will.
2. Die Lupe: "Aktivitätstheorie"
Um dieses Chaos zu verstehen, haben die Forscher eine theoretische Lupe benutzt, die sie Aktivitätstheorie nennen.
Stellen Sie sich das Team als ein Orchester vor:
- Die Musiker (Subjekte): Entwickler und Experten.
- Das Instrument (Werkzeuge): Computer, Code-Tools, Server.
- Die Partitur (Regeln): Wie schreibt man Code? Was ist erlaubt?
- Der Dirigent (Aufteilung der Arbeit): Wer macht was?
- Das Ziel (Objekt): Ein funktionierendes Programm.
Das Problem ist: Jeder Musiker spielt ein anderes Stück, benutzt ein anderes Instrument und liest eine andere Partitur. Die Theorie hilft zu sehen, wo genau die Noten falsch sitzen.
3. Was erwarten die Parteien voneinander? (Die "Wunschzettel")
Die Studie hat herausgefunden, was jeder von der anderen Seite erwartet – und wo diese Erwartungen oft nicht erfüllt werden:
Was die Entwickler (SDEs) von den Experten (DEs) wollen:
- "Bitte sei verlässlich." (Der Code muss funktionieren, nicht nur einmal).
- "Bitte sag mir genau, was du willst." (Keine vagen Wünsche).
- "Bitte nimm Verantwortung." (Wenn du den Code geschrieben hast, kümmer dich auch darum).
- "Bitte schreib mit, was du tust." (Dokumentation ist wichtig, sonst weiß niemand, wie das Haus funktioniert).
- "Bitte benutze unsere Werkzeuge." (Verstehe, wie unsere Baumaschinen funktionieren).
Was die Experten (DEs) von den Entwicklern (SDEs) wollen:
- "Bitte teste meinen Code." (Mach die Fehler, die ich übersehen habe).
- "Bitte mach meinen Code professionell." (Mach aus meinem Skizzen-Code ein echtes Produkt).
- "Bitte hilf mir mit der Technik." (Richte die Server ein, damit ich arbeiten kann).
- "Bitte lerne mein Fach." (Verstehe, warum ich diesen merkwürdigen Code brauche).
4. Die 21 Reibungspunkte (Wo es knallt)
Die Forscher haben 21 konkrete Punkte identifiziert, an denen es knirscht. Hier sind die häufigsten, als Metaphern:
- Der "Schnell-und-Schmutzig"-Konflikt: Der Experte will schnell ein Ergebnis ("Ich will sehen, ob die Idee funktioniert!"). Der Entwickler muss sich den Kopf zerbrechen, wie man das in 10 Jahren noch wartet. Das führt zu technischer Schulden (wie ein Haus, das man provisorisch gebaut hat und das später einstürzen könnte).
- Die "Wem gehört das?"-Verwirrung: Da alle zusammenarbeiten, weiß niemand genau, wer wofür zuständig ist. Ist der Code des Experten jetzt auch Aufgabe des Entwicklers? Oder umgekehrt? Das führt zu Verantwortungslosigkeit ("Das war nicht mein Job").
- Die "Blackbox"-Dokumentation: Der Experte schreibt Code, den nur er versteht. Der Entwickler kommt und fragt: "Was macht das hier?" Antwort: "Keine Ahnung, ich habe es nur schnell hingeschrieben." Das ist wie ein Haus ohne Baupläne.
- Die "Werkzeug"-Barriere: Der Experte benutzt alte, seltsame Werkzeuge, die der Entwickler nicht kennt. Der Entwickler muss erst lernen, wie man mit diesen Werkzeugen umgeht, anstatt zu bauen.
- Die "Überlastung": Beide Seiten fühlen sich überfordert. Der Experte muss plötzlich auch noch Software-Engineering lernen, und der Entwickler muss plötzlich auch noch Biologie oder Physik verstehen.
5. Die Lösung: Wie man den Tanz wieder harmonisch macht
Die Studie schlägt vor, nicht einfach zu sagen "Seid netter zueinander", sondern strukturelle Änderungen vorzunehmen:
- Vor dem Start klären: Bevor das Projekt beginnt, sollten beide Seiten ihre "Wunschzettel" vergleichen. "Was erwarte ich von dir? Was erwartest du von mir?" Das muss explizit besprochen werden, nicht nur im Kopf behalten.
- Gemeinsame Regeln: Nicht nur die Entwickler bestimmen die Regeln. Die Experten müssen auch mitreden, wie die "Baupläne" aussehen.
- Intelligente Werkzeuge: Die Software-Tools selbst sollten helfen. Stell dir einen digitalen Assistenten vor (vielleicht eine KI), der dem Experten sagt: "Hey, dieser Code ist gut für den Test, aber für den echten Einsatz brauchen wir noch eine Dokumentation." Und dem Entwickler sagt: "Hey, der Experte braucht das Ergebnis schnell, lass uns einen Kompromiss finden."
- Vertrauen aufbauen: Es braucht Zeit, bis beide Seiten verstehen, dass der andere nicht "schlecht" arbeitet, sondern nur einen anderen Fokus hat.
Fazit
Die Botschaft der Studie ist: Die Zusammenarbeit scheitert selten an der Fähigkeit, sondern an den stillschweigenden Annahmen.
Wenn ein Physiker und ein Programmierer zusammenarbeiten, ist es wie ein Tanz zwischen einem Balletttänzer und einem Breakdancer. Beide sind großartige Tänzer, aber sie tanzen zu unterschiedlichen Rhythmen. Wenn sie nicht aufhören, sich anzusehen und zu besprechen, wie sie ihren gemeinsamen Tanz choreografieren, stolpern sie über die Füße des anderen.
Diese Studie gibt ihnen eine Karte, damit sie wissen, wo die Stolpersteine liegen, bevor sie tanzen.
Ertrinken Sie in Arbeiten in Ihrem Fachgebiet?
Erhalten Sie tägliche Digests der neuesten Arbeiten passend zu Ihren Forschungsbegriffen — mit technischen Zusammenfassungen, in Ihrer Sprache.