24
PERSONALquarterly 02/17
SCHWERPUNKT
_VIRTUELLE KOOPERATION
Methode in einer Einzelfallstudie angewandt. In diesem Bei-
trag wird der aktuelle Stand nach einem FLOW-Interview mit
dem Geschäftsführer präsentiert, in dem wir bereits einen
fundierten Überblick über Kommunikations- und Informati-
onsflüsse gewinnen konnten.
Im Interview wurden Informationen über die Unterneh-
mensstruktur und die übergeordnete Kommunikation gesam-
melt. Das Unternehmen am Standort in Spanien beschäftigt
Informatiker, die für die Programmierung der Software zu-
ständig sind, während die Kunden und Berater in Deutsch-
land ansässig sind. Der Geschäftsführer pendelt regelmäßig
zwischen Deutschland und Spanien. Die Teams werden von
zwei Teamleitern geführt: von einem Teamleiter für das Bera-
terteam aus Deutschland und einem Teamleiter der Entwickler
in Spanien. Das Team der Berater besteht aus sieben bis acht
Personen. Auch eine Mitarbeiterin aus Spanien ist Teil des
Teams. Der Teamleiter der Informatiker arbeitet ebenfalls in
Deutschland, führt aber die Informatiker in Spanien. Er hat ei-
nen ständigen Vertreter, der vor Ort in Spanien ist. Zu seinem
Team gehören sechs Informatiker und zwei bis drei Grafiker
und Qualitätsbeauftragte.
Das Diagramm
Die aus dem Interview gewonnenen Informationen wurden im
nächsten Schritt in einem FLOW-Diagramm zusammengefasst
und visualisiert. Das Ergebnis ist das in Abbildung 2 darge-
stellte Diagramm.
Die zentrale Aktivität zum Projektstart ist ein Workshop
(1), an dem der Geschäftsführer, der Kunde und beide Team-
leiter sowie unterstützende Berater, die für das entsprechende
Projekt eingesetzt werden, aus Deutschland teilnehmen. Der
Workshop dient der grundlegenden Definition des Projekts
und der Klärung wesentlicher Parameter. Aus dem Workshop
resultiert ein Anforderungskatalog (2), in dem die Anforderun-
gen schriftlich festgehalten werden. Der Anforderungskatalog
wird mit dem Kunden rückgekoppelt und im weiteren Verlauf
von den Beratern in ein Konzept und in Story Cards für das
Ticketsystem überführt. Ebenso entsteht auf Basis des Anfor-
derungskatalogs ein „Click-Dummy“ (3), der es dem Kunden
ermöglicht, die Ideen der Entwickler und Berater nachzuvoll-
ziehen und ein erstes Gespür für die Software zu erhalten.
Bei dem Click-Dummy handelt es sich nicht um bereits pro-
grammierte Software, sondern um einen Prototypen, eigent-
lich jedoch um eine aufbereitete Präsentation, die zeigt, wie
das Endprodukt aussehen kann und welche Funktionalitäten
es aufweist. Deshalb ist er als fester Informationsspeicher
dargestellt. Erstellt wird der Click-Dummy von Beratern (4)
basierend auf den Ergebnissen des Workshops und des Anfor-
derungskatalogs. Der Click-Dummy ist vor allem für das klare
Bild zwischen Kunde und Unternehmen notwendig und unter-
stützt die Kommunikation zwischen Deutschland und Spanien.
Die Berater aus Deutschland, die mit der Entwicklung ver-
traut sind, stellen den Informationsfluss zwischen den Kunden
und den Entwicklern und damit auch den Informationsfluss
über die Ländergrenzen hinweg sicher. Fast täglich kommu-
nizieren sie mit den Entwicklern aus Spanien und skypen
oder telefonieren oft mit den externen Kunden; in der Regel
mit entsprechender Dokumentation. Die Ergebnisse werden
(überwiegend von den Beratern) in Story-Cards oder Tickets
festgehalten, die in einem Ticketsystem (5), wie es in der agilen
Softwareentwicklung häufig verwendet wird, zusammenge-
tragen werden. Auf diese Dokumentation können alle Projekt-
beteiligten zugreifen. Darüber hinaus generieren die Berater
Testfälle, die an die Qualitätssicherung weitergegeben werden.
Das Projekt endet mit einem Abschluss, bei dem der Kunde
die Software bekommt und vier Wochen Zeit hat, um sie zu
testen und Änderungswünsche zu äußern. Dieser Schritt ist
in Abbildung 2 nicht dargestellt.
Die Auswertung
Beim ersten Betrachten des Diagramms auf Grundlage des
ersten Interviews scheint der Anteil an flüssigen Informati-
onsspeichern, d.h. Personen, zu überwiegen. Von den meisten
Gesprächen, insbesondere von den Gesprächen zwischen den
Beratern und den Kunden, gibt es jedoch eine ausführliche
Dokumentation und Gesprächsprotokolle, die mit allen Ge-
sprächsteilnehmern abgestimmt werden. Auf diese Weise ge-
lingt es, die Gesprächsinhalte auch anderen Projektbeteiligten,
wie bspw. dem Teamleiter der Berater, zugänglich zu machen.
Außerdem können diese Protokolle bei etwaigen Unklarheiten
herangezogen werden.
Zudem fällt bereits nach dem ersten Interview auf, dass die
Kommunikation zwischen Deutschland und Spanien aufgrund
der sprachlichen Barriere eine erhöhte Schwierigkeit darstellt.
Die Kommunikation mit dem Kunden erfolgt über Berater aus
Deutschland, die neben dem Verständnis für die Anforderun-
gen an die Software auch die fachliche Expertise mitbringen,
Kundenwünsche aufzugreifen, zu konkretisieren und bspw. in
Form des Anforderungskatalogs weiterzuverarbeiten.
Derartige Indirektionen wie die Kommunikation der Anfor-
derungen über Dritte stellen häufig eine erhöhte Gefahr dar,
da die Informationen zu den Anforderungen nicht ungefiltert
bei den Entwicklern ankommen und deshalb Fehlinterpreta-
tionen nicht auszuschließen sind. In diesem Beispiel kommt
der Kunde jedoch nicht mit einem konkreten Anliegen, son-
dern dieses wird erst gemeinsam mit den Experten (Beratern)
erarbeitet. Zeichnen sich Lösungen ab, werden die Entwickler
einbezogen.
Ein weiterer auffälliger Punkt ist das Ticketsystem. Dort
werden in Form von Story-Cards die Anforderungen doku-
mentiert. Die Story-Cards werden üblicherweise vom Kunden
geschrieben, da nur er ohne Interpretation von seinen Wün-
