Häufige Fehler in der Kundenkommunikation: Wie Sie Ihren Kunden nicht frustrieren
Veröffentlicht: 2022-03-11Wenn jemand ein Projekt anfordert, müssen wir davon ausgehen, dass es sehr wichtig ist und dass ihm das Produkt, an dem Sie arbeiten, sehr am Herzen liegt. Man kann also davon ausgehen, dass ein Kunde zwangsläufig große Erwartungen an das Endprodukt knüpft und daher bei der Lieferung emotional werden kann.
Im Laufe des Projekts kann sich ein Kunde über ein geliefertes Feature sehr freuen und Sie lieben, und am nächsten Tag kann er oder sie feststellen, dass etwas nicht funktioniert und diese Zuneigung verschwunden ist. Meistens ist es nur eine Frage der Kundenkommunikation, die schief gelaufen ist.
Obwohl es keine Erfolgsrezepte für die Remote-Softwareentwicklung gibt, glaube ich, dass einige Dinge vermieden werden müssen , um eine gesunde und produktive Beziehung zu Kunden aufrechtzuerhalten, die so viel Vertrauen in Ihre Hände gelegt haben.
Versagen Sie nicht bei der grundlegenden Kommunikation mit Kunden
Stellen Sie sich die Kommunikation mit Kunden so vor, wie Sie es mit der täglichen Kommunikation mit Kollegen, Freunden oder anderen Personen tun würden, denen Sie Höflichkeit entgegenbringen würden.
Wenn ein alter Freund zu Besuch zu Hause ist und Sie zustimmen, ein paar Wochen später mittags eine lokale Delikatesse „in Ihrer alten Wohnung“ zu genießen, würden Sie einfach dort auftauchen? Würden Sie in der Zwischenzeit in Kontakt bleiben, ein paar Tage im Voraus anrufen, um dies zu bestätigen? Oder würden Sie vielleicht annehmen, dass sie zu beschäftigt sind und sie nicht ohne guten Grund stören wollen? Würdest du erwarten, dass sie dich benachrichtigen, wenn sie ankommen?
Sie werden wahrscheinlich nicht jeden Tag chatten, es sei denn, Sie haben viel zu besprechen, aber Sie werden aus Höflichkeit und Praktikabilität eine Form der Kommunikation beibehalten: Sie möchten nicht, dass die andere Person denkt, Sie hätten sie vergessen , aber Sie wollen bestimmt nicht ohne Grund durch die halbe Stadt fahren.
Sicherlich haben auch Sie schon einmal ähnliche Situationen in Ihrer beruflichen Kommunikation erlebt, selbst mit langjährigen Partnern und Kollegen. Einige Projekte werden mit minimaler Kommunikation ausgeführt, so wie man sagt „das Übliche, mittags, wir sehen uns dort“, um ein leichtes Mittagessen zu bestätigen. Selbst wenn etwas dazwischenkommt, wird die andere Partei Sie sicherlich informieren und Sie werden einer Verschiebung zustimmen.
In der Welt der Softwareentwicklung sind die Dinge jedoch nicht so einfach oder linear.
Wenn Sie anfangen, an einem Projekt zu arbeiten, insbesondere wenn Sie es mit einem neuen Kunden zu tun haben, werden diese, wenn sie nie etwas von Ihnen hören, anfangen, über Ihre Arbeit und Ihr Engagement nachzudenken. Selbst wenn Sie nach ein paar Wochen mit einem makellosen Produkt auftauchen, haben Kunden möglicherweise bereits eine weniger als ideale Wahrnehmung von Ihnen.
Obwohl es sich manchmal unangenehm anfühlt, schadet es nicht, mit dem Kunden zu sprechen, auch wenn Sie nichts Außergewöhnliches zu berichten haben! Haben Sie Zweifel an einem winzigen Punkt einer User Story? Wenn du denkst, dass es wichtig ist, lass es sie wissen. Sie haben etwas Verspätung und sind sich nicht sicher, ob Sie den vereinbarten voraussichtlichen Termin einhalten können? Rufen Sie den Kunden so schnell wie möglich an! Es ist besser, sie hören sofort davon.
Sie haben keine Zweifel und das Projekt liegt perfekt im Zeitplan, aber der Kunde redet nicht viel? Warum schicken Sie nicht einfach alle paar Tage eine E-Mail, in der Sie Ihren Fortschritt beschreiben? Es schadet nicht, denn die E-Mails stören niemanden, außerdem dokumentieren Sie Ihre Fortschritte und pflegen eine regelmäßige Kommunikation mit dem Kunden.
Fehlerhafte Kundenkommunikation fördert unrealistische Erwartungen
Also, am Anfang habe ich erwähnt, dass der Kunde zwangsläufig viele Erwartungen an das Projekt haben wird, richtig? Rechts. Zeitraum.
Der Kunde erwartet bereits viel von dem Produkt. Wenn es nicht so läuft, wie sie es sich vorgestellt haben, werden die Kunden unweigerlich frustriert. Warum also sollte jemand mehr versprechen, als er halten kann, und so noch unrealistischere Erwartungen wecken?
Hier ist eine kurze Parallele: Sie haben ein Tablet online gekauft und Ihnen wurde eine 10-tägige Lieferung versprochen. Am 8. Tag teilt Ihnen der Shop mit, dass es ein Problem gibt, und verzögert die Lieferung um eine Woche. Um Sie für die Unannehmlichkeiten zu entschädigen, verspricht Ihnen der Einzelhändler ein Guthaben von 75 $.
Wahrscheinlich haben Sie das Tablet in den nächsten Tagen sowieso nicht wirklich gebraucht, also denken Sie, dass es ein gutes Geschäft ist! Jetzt können Sie das Tablet genießen und das Guthaben verwenden, um Ihren Kindern etwas Schönes zu kaufen. Aber der Laden ruft am nächsten Tag an und sagt, dass alles über Nacht geklärt wurde.
Am nächsten Tag erhalten Sie das Tablet. Keine Extras, kein Guthaben. Jetzt bist du frustriert!
"Was? Erst gestern hast du mir gesagt, ich würde ein besseres Angebot machen! Das ist nicht fair! Ich habe den Kindern schon gesagt…“
Spulen Sie ein paar Tage zurück und alles, was Sie erwartet haben, war sowieso das Tablet. Hätte dir niemand ein besseres Angebot versprochen, hättest du dich am nächsten Tag über dein Spielzeug gefreut. Aber jetzt haben Sie das Gefühl, dass Sie aus keinem guten Grund etwas verpassen, außer der Entscheidung des Shops, Sie darüber zu informieren.
Wie können Entwickler, insbesondere Freiberufler, ähnliche Situationen in ihrer Kommunikation mit Kunden vermeiden?
Indem Sie nicht verrückt werden und alles sagen, was Ihnen in den Sinn kommt. Vorschläge sind nicht verboten; Eigentlich sind sie sehr willkommen, wenn Sie der Meinung sind, dass eine bestimmte angeforderte Funktion keine sehr gute Option zur Lösung des vorliegenden Problems ist. Aber der Schlüssel ist: Erst denken.
Hören Sie dem Kunden zu.
Analysiere ihr Problem.
Analysieren Sie die vorgeschlagene Lösung.
Stellen Sie sicher, dass es innerhalb des Budgets/Zeitplans liegt.
Machen Sie schließlich weiter und präsentieren Sie Ihren Vorschlag.
Aus diesem Grund können die Fähigkeiten zur Kundenkommunikation schwierig sein, denn wenn Sie nur bei einem der ersten vier Schritte scheitern, könnten Sie am Ende Ihre Zeit und, schlimmer noch, die Zeit Ihres Kunden verschwenden.
Gehen Sie nicht davon aus, dass Sie wissen, was der Kunde braucht
Um es mit Mary Schmich zu sagen, meine Damen und Herren der Klasse '17: Hören Sie dem Kunden zu. Wenn ich Ihnen nur einen Tipp für die Zukunft geben dürfte, wäre es der, dem Kunden zuzuhören.
Wenn Sie für ein Projekt berufen wurden, dann deshalb, weil jemand etwas braucht. Und wer wüsste diese Notwendigkeit besser als Ihr Kunde? Es mag offensichtlich erscheinen, aber in der realen Welt wird es manchmal vergessen.
Lassen Sie mich Ihnen ein Beispiel geben. Ein Einzelhändler fragt nach einem „Softwaresystem“ für sein Geschäft. Sobald Sie es sehen, kommen Sie zu dem Schluss, dass sie alle verfügbaren Produkte registrieren, jeden getätigten Einkauf aufzeichnen, Quittungen für Kunden erstellen und darüber berichten möchten, was regelmäßig verkauft wurde und welche Artikel zur Neige gehen Lager.
Bei Ihrem ersten Treffen möchten Sie also zeigen, dass Sie effizient sind, und ihnen präsentieren, was Sie vorbereitet haben, die vorgeschlagenen Funktionen, ein grundlegendes Design, das zur visuellen Identität des Shops passt, und so weiter. Aber dann sagt der verwirrte Kunde, dass er eigentlich einen Algorithmus braucht, um zu berechnen, wie die Produkte besser in den Regalen präsentiert werden können, um den Umsatz für bestimmte Marken und Produkte zu steigern!
Der Fehler hier war einfach nicht zu erkennen, welches Problem Sie lösen sollten. Da es in diesem Fall sehr früh im Projekt war, bliebe natürlich viel Zeit, um es richtig zu machen, aber manchmal passiert diese Art von Fehler später. Auch wenn es nicht so drastisch sein kann wie das vorherige Beispiel, kann es dennoch dem Projekt und/oder Ihrer Beziehung zum Kunden schaden.
Mein Vorschlag ist folgender: Sprechen Sie möglichst viel mit Ihren zukünftigen Nutzern und konsultieren Sie verschiedene Projektbeteiligte. Sie haben einen guten Überblick über die Situation und wissen, was sie brauchen. Versuchen Sie herauszufinden, was sie derzeit tun, bei jedem Schritt und erklären Sie, wie sich Software als nützlich erweisen würde. Ich sage gerne, wenn ich versuche zu verstehen, was ein Kunde wünscht, ist es mein Ziel, seine Arbeit fast selbst ausführen zu können. Wenn Sie sich diesem Punkt nähern, haben Sie wirklich herausgefunden, was ihre Bedürfnisse sind.
Nicht verstehen, wonach der Kunde fragt
Es ist nicht ungewöhnlich, eine Art Dokumentation über das vorliegende Problem zu erhalten. Manchmal ist es nur eine allgemeine Beschreibung, während es manchmal ein detailliertes Dokument mit Anwendungsfällen und Geschäftsregeln ist. Auf jeden Fall, egal wie klar die Aufzeichnungen sind, das Einzige, was Sie nicht tun können, ist einfach davon auszugehen, dass alles, was dort geschrieben wird, die absolute Wahrheit ist.

Was???
Exakt. Erstens kann etwas für jemanden in einem bestimmten Kontext etwas bedeuten und für Menschen, die nicht zu dieser Realität gehören, etwas völlig anderes. Und wenn es etwas gibt, das Sie und der Kunde nicht gemeinsam haben, dann ist es der Kontext!
Zweitens ist nicht jeder ein sehr begabter Schriftsteller; Sie versuchen, A zu sagen, beschreiben aber am Ende B.
Also, nachdem Sie alles gelesen haben, was Sie erhalten haben, wie können Sie sicher sein, dass das, was Sie lesen, wirklich das ist, was sie gemeint haben? Nun, Sie werden alles verdauen, einige Notizen machen, alles analysieren und… ein Meeting einberufen . (Sehen Sie? Es dreht sich alles um Kommunikation!) Bei dem Treffen werden Sie über das Problem sprechen und mit eigenen Worten beschreiben, was Sie verstanden haben. An dieser Stelle werden Sie wahrscheinlich Missverständnisse erkennen können.
„Oh, aber in meinem Fall habe ich keine Dokumente bekommen. Ich saß einfach beim Kunden und sie erklärten mir alles, während ich mir ein paar Notizen machte.“
Nun, es gibt immer noch keine Garantie dafür, dass Sie verstanden haben, was sie meinten, und mein Vorschlag bleibt bestehen: Nehmen Sie sich etwas Zeit mit Ihren Notizen, denken Sie über das ganze Problem nach, organisieren Sie alles, am besten in einer Art Zeitleiste, und rufen Sie dann erneut an / treffen Sie sich mit der Klient zu präsentieren, was Sie verstanden haben. Es mag sich für Sie wiederholend anhören, aber manchmal hat selbst der Kunde keine vollständige Vorstellung von allen Prozessen, die zur Erfüllung einer bestimmten Aufgabe erforderlich sind, und sieht dann, wie komplex die Software sein muss.
Am Ende müssen Sie sicher sein, dass es keine Zweideutigkeiten oder Missverständnisse gibt.
Warum Sie nicht alles liefern sollten, was der Kunde verlangt, ohne nachzudenken
OK, jetzt, wo Sie wissen, dass Sie dem Kunden zuhören und bestätigen sollten, was Sie verstanden haben, können Sie einfach weitermachen und alles tun, worum er Sie gebeten hat, richtig?
Falsch!
Jetzt ist der Moment gekommen, in dem Sie endlich all Ihre Erfahrung nutzen und sich fragen können: Wird das, was der Kunde Sie gefragt hat, sein Problem lösen? Ist das, was sie dich gefragt haben, wirklich das, was sie brauchen?
Sie wären überrascht zu sehen, wie oft die Antwort „nein“ lautet.
Bevor wir einfach liefern, was der Kunde verlangt hat, müssen wir das Problem analysieren, und wenn Sie mit dem, was der Arbeitgeber vorgeschlagen hat, nicht einverstanden sind, dann ist es Ihre Aufgabe und berufliche Verantwortung, dies klarzustellen. Natürlich sollten Sie dann erklären, warum Sie der Meinung sind, dass ihr Vorschlag nicht gut ist und was Ihr alternativer Ansatz tun wird, um diese Mängel zu beheben. Wieder einmal ist die Kommunikation der Schlüssel.
Wenn Sie und der Kunde vernünftig sind, werden Sie entweder mit Ihrer Lösung fortfahren oder eine Brainstorming-Sitzung durchführen, um eine bessere Lösung zu finden (falls Ihre Idee aus irgendeinem Grund für den Kunden nicht akzeptabel war).
Prototyp – Schreiben Sie keine umfangreiche Dokumentation
Ich habe bereits gesagt, dass Sie und Ihr Kunde im Allgemeinen nicht die gleiche Perspektive haben, oder? Genauso wie es Ihr Verständnis ihrer Dokumentation beeinflusst, wird es ihr Verständnis dessen beeinflussen, was Sie schriftlich liefern. Es ist auch eine Frage des Kontextes.
Also stimme ich zu, dass wir irgendwie (auf einer höheren oder niedrigeren Ebene) dokumentieren müssen, was wir entwickeln werden. Aber mehrere Seiten Text ohne visuelle Elemente auszuhändigen, wird Ihnen nicht viel nützen. Der Kunde wird sich beim Lesen langweilen, wird nicht mehr aufpassen und wahrscheinlich nicht verstehen können, was Sie mit diesen komplexen Geschäftsregeln meinen – oder er wird etwas völlig anderes interpretieren, als Sie es sich vorgestellt haben.
Denken Sie daran, dass diese Missverständnisse noch schlimmer sein können, wenn der Kunde keinen technischen Hintergrund hat.
All diese Faktoren können zu demselben problematischen Ergebnis führen: Kunden werden sich beschweren, wenn Sie das Produkt liefern, weil es wahrscheinlich nicht das ist, was sie sich vorgestellt haben.
Hier ist, was ich vorschlage: Erstellen Sie immer einen Prototyp, auch wenn es nur eine Skizze ist, um Ihren Plan zu zeichnen. Und welche Definitionen Sie auch immer treffen müssen, beginnen Sie damit. Machen Sie Referenzen und versuchen Sie, es einfach zu halten.
Hören Sie auf, Zeit damit zu verschwenden, den Kunden davon zu überzeugen, dass Sie Recht haben
Ich kann mir fast sicher sein, dass jeder Entwickler diese Situation schon einmal erlebt hat: Zu Beginn des Projekts sagt der Kunde: „Ich brauche eine gelbe Hintergrundfarbe für die Software. Der Vorstand hat dem bereits zugestimmt.“ Dann, wenn die Software geliefert wird, heißt es: „Oh, aber die Hintergrundfarbe kann nicht gelb sein. Ich habe dir gesagt, es muss grün sein!“ Wie soll man nun damit umgehen?
Sicherlich wird es sowieso keinen Zweck haben, einfach darauf zu bestehen, dass Sie Recht hatten und sie Unrecht hatten. Wenn überhaupt, wird es Ihnen und dem Kunden nur eine harte Zeit bereiten.
Es ist immer gut, eine gute Aufzeichnung der Kommunikation mit dem Kunden zu haben, nur um sicherzustellen, dass Sie auf derselben Seite sind und eine schriftliche Spur hinterlassen. Wenn es sich um etwas Einfaches handelt, können Sie dem Kunden meistens einfach eine E-Mail schreiben und sagen: „Wie wir bei diesem Meeting vereinbart haben, wird der Hintergrund des Systems gelb sein.“ Und wenn der Kunde in Zukunft seine Meinung ändert, können Sie argumentieren, dass Sie es wegen des in der E-Mail erwähnten Treffens so gemacht haben, aber wenn diese Änderung wirklich vorgenommen werden muss, können Sie sie für weitere x Stunden ausführen (und manchmal extra x Dollar).
Aber wenn es keinen Beweis dafür gibt, dass Sie Recht hatten, müssen Sie wahrscheinlich eine Entscheidung treffen (und eine Lektion lernen): Ist die Änderung so groß, dass eine Änderung der aktuellen Architektur erforderlich ist oder andere Funktionen beeinträchtigt werden? Wenn nicht, ist es wahrscheinlich am besten, einfach weiterzumachen, es zu tun und den Kunden an Ihre Seite zu holen (aber mit offenen Augen, damit es nicht wieder passiert). Wenn ja, dann ist ein Gespräch mit dem Kunden die beste Lösung; nicht einer, der sich darauf konzentriert, „wie Sie Recht hatten“, sondern darauf, „wie wir das aktuelle Problem lösen können“.
In jedem Fall ist der beste Weg, um große Änderungen zu vermeiden, kurze neue Funktionen in kurzen Zeiträumen bereitzustellen. Wenn also etwas geändert werden muss, wird es wahrscheinlich keine große Transformation dessen sein, was bereits vorhanden ist.
Wissen, wann Sie Fristen einhalten müssen
Zu guter Letzt besteht einer der größten Fehler, den Sie machen können, darin, Ihrem Kunden eine Frist für die Fertigstellung des Projekts zu setzen. Und sie werden dich bitten, diesen Fehler zu machen!
Als Kunde möchten Sie natürlich wissen, wann Sie all die netten Funktionen nutzen können, über die Sie in den letzten Wochen (Monaten?) gesprochen haben. Da ein Projekt aber kein definiertes Produkt ist, kann vom Beginn der Entwicklung bis zur Einsatzreife der Software viel passieren.
Zunächst einmal kann man das Unvorhersehbare nicht vorhersagen. Es ist sehr wahrscheinlich, dass Sie sich mit etwas auseinandersetzen müssen, mit dem Sie nicht gerechnet haben. Es könnte eine vom Kunden versprochene Lizenz sein, die nicht rechtzeitig gekauft wurde, oder eine andere interne Software, die Sie verwenden müssen, aber nicht veröffentlicht wurde, als es hätte sein sollen, oder die Umgebung war anders als die, die am Anfang vereinbart wurde. oder der Kunde hat seine Meinung bezüglich einiger (weniger) Funktionen geändert und Sie mussten ein paar Dinge neu machen.
Nichts davon ist wirklich die Schuld eines Entwicklers und kann die Deadline eines Projekts stark beeinflussen. Aber wenn Sie bereit sind, dem Kunden zu gefallen, versprochen haben, dass Sie alles bis zu einem bestimmten Datum liefern würden, und dies aus den richtigen Gründen nicht tun, dann kann ich Ihnen garantieren, dass der Kunde es zumindest ein wenig tun wird , frustriert. Wenn Sie Freiberufler sind, müssen Sie Ihre Zeit effizient verwalten, wie dieser Toptal Engineering Blog-Artikel erklärt. Vergessen Sie nicht, dass Kundenbeziehungsmanagement auch Ihr Job ist.
Also, tun Sie sich und denjenigen, die von dem Projekt abhängig sind, einen Gefallen und geben Sie ihnen zumindest eine Schätzung, wie lange es dauern wird, alles zu entwickeln, aber machen Sie immer klar, dass es sich nur um eine Schätzung und nicht um eine Frist handelt.
Außerdem empfehle ich dringend (insbesondere wenn Sie bereits einen Kostenvoranschlag abgegeben haben), dass Sie dem Kunden immer sagen, wenn etwas länger als erwartet dauert, damit er Ihnen helfen kann!