Kommunikation als Systementwickler / Systemberater
Viele meiner Kolleginnen und Kollegen haben Probleme in der Kommunikation mit Kunden. Dabei wollen beide eigentlich das Gleiche: Probleme lösen und abhaken. Es muss zwischenmenschlich nicht mal funken, obwohl das hilfreich ist und man sich nochmal auf anderen Ebenen begegnen und sich mit Klartext austauschen kann. Oft genügt es, wenn ein Infofluss hergestellt wird und man auf Fragen ehrlich antwortet. Stichwort: Transparenz.
Ich will das an zwei Beispielen verdeutlichen:
Szenario: Ein Kundenprojekt wurde vom Vertrieb und der Projektplanung falsch eingeordnet (haben aneinander vorbeigeredet) und jetzt hängen alle völlig random knietief drin. Der Kunde ärgert sich, wo doch alles so leicht und schnell hätte gehen sollen. Aber bisher knallt es bei fast jedem umgesetzten Punkt.
Problem: Viel zu viele To-Do-Punkte, kein tiefes Verständnis bei den Abläufen auf Seite der Entwickler und ständig kommen E-Mails rein die beschreiben, was alles nicht klappt und langsam wirds auch eng, weil in zwei Stunden ist Durchlauf A, heute Nacht Durchtlauf B - im Zweifel wieder alles auf Start für die beiden Punkte. Richtiger wäre es gewesen das ganze Punkt für Punkt umzusetzen. Vor allem bei der Fülle und Breite. Aber auch die Lernkuve ist nicht für die Katz'. Das hilft ja auch dem Vertrieb bei der Preisgestaltung. Aber zurück zum Schützengraben:
Lösung: Was jetzt hilft ist: Konkret werden! Meeting mit Kundenseite und den involvierten Entwicklern - 15 Minuten max. Offen kommunizieren, dass jetzt nach Priorität umgesetzt werden muss um den Karren aus dem Dreck zu ziehen. Prio 1 ist Durchlauf A. Was war das Problem? Dateien wurden nicht übermittelt. Oder im falschen Format. Was auch immer. Optimalerweise kann man schon sagen: Hier wurde falsch konvertiert oder eine Verarbeitungsroutine abgeklemmt - die müssen wir uns aber nochmal ansehen weil da noch eine Querverarbeitung dran hängt in einem Nebenaufruf. Daran setzen sich jetzt n Mitarbeiter und in einer Stunde besprechen wir, ob wir das zurückrollen oder hinbekommen. Nach Durchlauf A treffen wir uns um Durchlauf B zu besprechen. Und so weiter. Punkt für Punkt mit verlässlichen Aussagen und konkreten Fallbacks.
Oder anders: Scheiße schaufeln.
Das sind die Tage, auf die weder Kunden noch Entwickler Bock haben. Aber natürlich muss man da durch. Und nicht nur irgendwie, sondern konkret. Gemotzt wird bitte intern oder, noch besser, danach, Meetings so sachlich und ehrlich wie möglich begehen. Es geht nicht um Schuld - jedenfalls noch nicht :]
Szenario: Kunde kann auf dem Testsystem nicht alles so umsetzen, wie er es bräuchte. Allerdings ist der Kollege, der den Kunden bisher betreut und das Testsystem eingerichtet hat, krank. Gestern schon und heute. Es muss also ein Dienstag sein. Man versucht selbst ein bisschen was anzuschieben, bekommt auch 12 Probleme gelöst aber beim -vermeintlich- letzten Problem bewegt sich nichts. Man vereinbart: Wir warten auf den Kollegen, der morgen wieder da sein müsste.
Problem: Uns fällt am Folgetag auf, dass der Kollege immer noch krank ist. Mist! Aber der Kunde will vorwärts kommen mit seinem Thema. Also ist zuerst die Überlegung da: Wann kann ich das unterbringen um im Debug das Problem Zeile für Zeile aufzudröseln? Gar nicht? Wer kann mich dabei unterstützen? Habe ich doch ein Zeitfenster?
Lösung: Egal wie die Lösungsvorschläge aussehen: Kunden proaktiv anrufen, das Problem umreißen und die Optionen nennen, die dir zur Verfügung stehen. Er entscheidet sich schon für eine. Und auch hier wieder: Konkret daran halten. Das hat jetzt für den ausgewählten Zeitslot die gleiche Priorität, als wäre es das eigene Projekt.
Kunden wollen nicht vergessen werden und möchten das Gefühl haben, besser noch sehen, dass sich etwas bewegt - auch wenn es sich mal nicht so flüssig bewegt, wie sonst. Oder wie erhofft. Oder wie versprochen. Redet miteinander und kommuniziert die Probleme. Alles andere dann im Nachgang. Vorwärts!