Richtige Kommunikation im Softwareprojekt
Als ich diese Woche durch die schmalen Gänge einer amerikanischen Grossbank geführt wurde, fielen mir die vielen Indischen Angestellten auf. „Das sind alles Programmierer„, bekam ich als Antwort. Sie würden mit Hochdruck an der Umstellung der veralteten Banksysteme arbeiten. 500 Programmierer sitzen in der Zentrale vor Ort, weitere 500 in Bangalore.
„Leider erhalten wir nur selten die Softwarelösungen, welche wir auch gefordert haben. Zwar werden die Prozesse und Anforderungen sehr sauber definiert, doch durch die Übersetzung von Deutsch nach Englisch und von Englisch nach Hindu bleibt viel wichtige Information auf der Strecke„, so mein Gastgeber.
Das Ergebnis wäre fehlerhafte und falsche Software, die sie nur durch kostenintensive Nacharbeiten nutzbar machen können. Er redete sogar davon, dass die Entscheidung für Offshoring eine der grössten Fehlentscheidungen der Firmengeschichte ist.
Nur, warum ist das so? Warum ist die Kommunikation und der zwischenmenschliche Dialog in der Softwarebranche so wichtig?
Kommunikation als Erfolgsfaktor
Sieht man sich an, wie wir miteinander kommunizieren, so stellt man fest, dass die Kommunikation aus vielen Komponenten besteht. Die reine Sachinformation ist nur ein Teil davon. Die non-verbale Kommunikation wie Gestik, Mimik und Körpersprache, macht einen weitaus größeren Anteil aus. Ob man nun will oder nicht, die Einstellung des Kommunizierenden lässt sich also nicht verbergen.
Diese so wichtige non-verbale Kommunikation geht beim Versenden von übersetzten Dokumenten völlig verloren. Selbst bei Videokonferenzen, bei dem man den Gesprächspartner immerhin visuell wahr nimmt, kommt es häufig zu Missverständnissen und falschen Interpretationen. Diese Tatsache kann sich bei der Definition von Anforderungen für die Software niemand leisten.
Fehlt es dann noch an der richtigen Methodik (Fragetechniken, aktives Zuhören etc.), um Anforderungen gut beschreiben zu können, ist der Misserfolg vorprogrammiert. Erst recht wenn dann noch Transformationsverluste (Stille Post-Prinzip) bei der Weitergabe von Informationen zustande kommen.
Globale Kommunikation
Gerade an der Nahtstelle zwischen IT und Fachabteilung kommt es sehr häufig zu drastischen Missverständnissen. „Die IT-Fuzzies vestehen uns nicht„, hört man immer wieder von den Fachbereichen.
So kann man sich vorstellen, wie schwerfällig die interkulturelle Kommunikation quer über den Globus sein kann, wenn sich die interne Abstimmung schon so schwierig gestaltet.
Wann Offshoring funktionieren kann
Trotz allen kommunikativen und sozio-kulturellen Schwierigkeiten glaube ich, dass sich Offshore-Projekte unter bestimmten Bedingungen lohnen können. z.B.:
- Die fachliche und räumliche Nähe zum Auftraggeber/Anforderer spielt eine eher untergeordnete Rolle
- Die direkte Kommunikation von Mensch zu Mensch wird nicht als Erfolgsfaktor identifiziert
- Die Aufgaben sind klar beschreib- und spezifizierbar und relativ einfach in der Entwicklung
- Das Offshore-Projekt hat einen in sich abgeschlossenen Charakter ohne umfassende Integrationsleistung
Gerde bei IT-Offshoring Projekten -also dem auslagern von Programmierleistungen in Niedriglohnländer- ist diese Art der Kommunikation eine ganz besondere Herausforderung.
Erst kürzlich machte auch die Produktmangerin eine leidvolle Erfahrung, als sie indische Kunden sogar an einem heiligen Feiertag eingeladen hat und dies dort als Beleidigung empfunden wurde.
In der globalisierten IT zählt also die Fähigkeit richtig und präzise zu Kommunizieren inzwischen mehr wie die technische Brillianz oder Genialität.
Weiterführende Infos:
- Beispiele des „Stille Post“ Problems aus dem EU-Parlament
- Kommunikation in der IT Java-Magazine 06.06 bis 10.06
- Eignungskriterien für IT-Offshoring (pdf)
„Hallo Oliver,
vielen Dank für den tollen Artikel zum Thema richtige Kommunikation im Sofwareprojekt! Mir gefällt dabei auch, dass Du auf die non-verbale Kommunikation eingehst, der leider oftmals keine Beachtung geschenkt wird. Der Kommunikationskonflikt zwischen IT-Abteilungen mit anderen Abteilungen sorgt oftmals für unnötige Verzögerung der Projekte und Frust auf beiden Seiten. Gerade bei Offshore-Projekten kommen noch häufig die sprachlichen Barrieren hinzu und somit ist das Chaos komplett.
Dein Beitrag hat mir sehr geholfen, das Thema einmal aus einer anderen Sichtweise zu sehen.
Danke und viele Grüße,
Mel Nell“
Hallo Oliver,
vielen Dank für den tollen Artikel zum Thema richtige Kommunikation im Sofwareprojekt! Mir gefällt dabei auch, dass Du auf die non-verbale Kommunikation eingehst, der leider oftmals keine Beachtung geschenkt wird. Der Kommunikationskonflikt zwischen IT-Abteilungen mit anderen Abteilungen sorgt oftmals für unnötige Verzögerung der Projekte und Frust auf beiden Seiten. Gerade bei Offshore-Projekten kommen noch häufig die sprachlichen Barrieren hinzu und somit ist das Chaos komplett.
Dein Beitrag hat mir sehr geholfen, das Thema einmal aus einer anderen Sichtweise zu sehen.
Danke und viele Grüße,
Mel Nell
Spannend geschrieben.
Meistens geht es darum, wie im Beitrag auch beschrieben, einfach sehr einfach zu kommunizieren, so dass sich alle (Fachabteilung, Softwareentwickler, Projektleiter, etc.) verstehen.
Zu oft wird ein Jargon/ Begriffe verwendet, dass nur ein Teil der Ansprechpartner versteht.
Besonders beim Offshore Outsourcing ist es wichtig, dass die Leute in direktem Kontakt sind. Dass heisst, der IT Leiter oder Entwickler beim Kunden hat direkten Kontakt zum Entwickler in Indien. Es sollte nicht über verschiedenste IT Projektleiter, Team Leads, etc. gehen, bis dahin sind die Informationen, wie im Bild hier im Beitrag beschrieben nicht mehr ganz klar.
Meiner Erfahrung nach kann es klappen. Mann muss nur eine einfache Sprache finden die jeder versteht und dass muss man sich vom Gegenüber einfach bestätigen lassen (die andere Seite kann die ganzen Punkte beispielsweise nochmals auflisten).
Danke für Eure tollen Informationen.
Viele Grüsse
Sascha Thattil
Im Prinzip spreche ich zwei Themen an. 1.) Kommunikation generell und 2.) Kommunikation speziell beim Offshoring.
Wie wir wissen ist die richtige Kommunikation schon im Alltag außerordentlich schwierig. Das Eine gesagt, das Andere gemeint und sofort falsch verstanden. (Von den Lexikas Frau/Deutsch, Deutsch/Frau oder Schwäbisch/Deutsch, Deutsch/Schwäbisch brauch ich ja nicht berichten).
Privat wie geschäftlich entstehen mit falsch gesprochen Worten fatale Missverständnisse. Erst recht im schriftlichen Verkehr, bei dem noch mehr Interpretationsmöglichkeiten der Information entstehen.
In der Softwarebranche gibt es nun hinlänglich die Story, dass ein Kunde etwas fordert und er am Ende etwas ganz anderes bekommt nur weil es der Entwickler falsch verstanden hat. Die Schuld dem Entwickler in die Schuhe zu schieben ist dann richtig, wenn dieser die falsche oder gar keine Methode zur Anforderungsdefinition angewendet hat. Alleine durch die richtige Fragetechnik lassen sich nämlich schon viele Risiken minimieren.
Gar keine Schuld trifft den Entwickler, wenn der Auftraggeber nicht richtig kommunizieren kann oder will. Vor allem dann, wenn ein Auftraggeber sein Position von „oben“ herunter immer und immer wieder verdeutlicht – Prinzip: „Er ist ja schliesslich Kunde und Geldgeber und darf den Entwickler ruhig verunsichern“.
Auch dann kommt es zwangsläufig zu Missverständnissen, da sich der Entwickler ja gar nicht mehr traut etwas nachzufragen. Die Angst etwas nicht verstanden zu haben und sich durch erneutes Nachfragen die Blöße zu geben, ist dann natürlich zu groß.
Übrigens ist es manchmal auch erschreckend, wie viele Führungskräfte nicht richtig kommunizieren können – gerade bei Delegationsgesprächen wird die Erwartungshaltung oft nicht klar und eindeutig geäußert.
Was stimmen muss ist die Kommunikationskultur zwischen allen Projektbeteiligten.
Ich behaupte, dass jedes Projekt in der IT in Time und in Budget erfolgreich ist, wenn die Kunst der Kommunikation von jedem gut beherrscht wird.
Interessant und erstaunlich zugleich. Wenn doch das Kommunikationsproblem bekannt ist, warum verwendet man nicht darauf mehr Zeit? Und kommen viele Mißverständnisse nicht einfach daher, dass die Software-Programmierer vom jeweils zugrunde liegenden Geschäft zu wenig verstehen?
Man müsste den Programmierern mehr Zeit geben, sich den relevanten Prozess selbst anzuschauen (unmittelbar vor Ort). Wird das gemacht? Vermutlich nur sehr selten.