Komplexe Kunden: So schützen Sie Ihr Team vor ihnen

Ich arbeite als Projektmanager für Live Typing. Letztes Jahr haben wir in unserem Unternehmensblog geschrieben, dass es nicht das Wichtigste ist, dies zu überraschen und den Kunden zu warnen, wenn die Frist abläuft. Aber je länger wir arbeiten, desto mehr ist uns klar, dass schlimmere als die festgesetzten Fristen nur komplexe, emotionale Kunden und Teams sein können, die unter ihrem Druck stehen.

Unternehmen, die während der Arbeit einige Stammkunden gewonnen haben, wissen bereits beim ersten Anruf, wie man verdächtige Leads filtert, und können es sich leisten. Leider können junge Studios, die Erfahrung und Einkommen anstreben, nicht auf solche Kunden verzichten.


Bevor Live Typing in die Top Ten der verschiedenen Branchenbewertungen aufgenommen wurde, arbeitete er mit einem Kunden zusammen, der das Team so demotivierte, dass die Mitarbeiter das Unternehmen verließen. Aus den Gründen, die ich im Folgenden erläutern werde, haben wir uns erneut mit dem Kunden geeinigt. Aus Angst vor einer neuen Beziehungskrise entwickelte ich eine spezielle Managementtaktik, um das Team sicher und gesund zu halten. Schließlich ist es schwierig, einen coolen Entwickler zu finden, und die Schulung und Anpassung eines neuen Mitarbeiters ist teurer als die Beibehaltung eines alten. Darüber hinaus sind die Besonderheiten des Outsourcings so, dass die Entwickler nach diesem Projekt das nächste übernehmen, und es ist wichtig, dass sie dies mit einem Gehirn tun, das noch nicht vollständig in die Luft gesprengt wurde.

Wie ich es gemacht habe, lesen Sie im Artikel.

Aus offensichtlichen Gründen werde ich den Kunden einfach als "Kunden" bezeichnen. Selbst bei dem Projekt, bei dem wir wiederholt zusammengearbeitet haben, haben wir im Team nichts anderes gesagt. Warum? Darüber weiter unten.

Hintergrund

Vor zwei Jahren kam ein Projekt zu uns. Bevor er zu uns kam, arbeiteten ungefähr fünf Teams daran und er sammelte einen anständigen Legacy-Code.

Die Beziehungen des Klienten zu früheren Teams waren weit entfernt von denen des Partners, und so beschloss er, automatisch eine offensive Position einzunehmen und sich mit einer Mauer des Misstrauens abzusichern.

Um die Kommunikation und Entwicklung zu beschleunigen, machte der erste Projektmanager den Chat in Slack für den Kunden und das Team gemeinsam - die Anwendung wurde nicht von uns entwickelt und warf viele Fragen auf, die schnell an den Kunden gerichtet werden mussten. In den meisten Fällen beschleunigt diese Methode die Übertragung von Informationen zwischen Teammitgliedern, aber unser Kunde hat sich nicht die Möglichkeit genommen, unhöfliche Kommentare im Chat oder in einer persönlichen Nachricht an eine bestimmte Person abzugeben.

Der Klient wandte sich an Persönlichkeiten, was zu offenen Konflikten führte, und sein Name wurde auch von denen gehört, die nicht beteiligt waren. Infolgedessen verlor das Unternehmen mindestens einen Mitarbeiter, der sich mit dieser Einstellung nicht abfinden konnte, und einige weitere verließen das Unternehmen nach einigen Monaten. Die formalen Gründe für das Verlassen schienen unterschiedlich zu sein, aber wir wissen etwas.

Als der Kunde kein Geld mehr hat, haben wir Schluss gemacht. Das Geld, so ist es erwähnenswert, ging, einschließlich der Unterstützung für Legacy-Code und der Entwicklung von Funktionen aus Gründen der Funktionalität.

Der Kunde kehrte später zurück. Er überzeugte uns, dass er die Anwendung von Grund auf neu entwickeln, veralteten Code aufgeben, die Funktionalität reduzieren und auf eine andere Art kommunizieren wollte. Wir akzeptierten es, aber nach einiger Zeit begann sich die Geschichte zu wiederholen.

Der Kunde hat unseren Bewertungen und Angeboten nicht vertraut. Er hatte seine eigene Vorstellung davon, wie das Produkt funktionieren sollte. Wir haben auch verstanden, wie es geht, aber der Kunde hat die Argumente nicht wahrgenommen und statt eines Partners mit Erfahrung in der Anwendungsentwicklung nur die Hände in uns gesehen, die seine Wunschliste zum Leben erwecken. Wir wissen nicht, warum sich der Kunde in eine solche Position gebracht hat und werden nicht spekulieren.

Die Situation heizte sich auf. In Erinnerung daran, wie sich Ereignisse in der Vergangenheit entwickelt haben, haben wir in einer für uns ungewöhnlichen Reihenfolge Prioritäten gesetzt: Zunächst müssen Sie das Team retten und erst dann das Projekt erfolgreich abschließen und, wenn möglich, die Kundenbindung aufrechterhalten.

Schutztaktik für komplexe Kunden

Schauen wir uns nun die Techniken an, mit denen wir unser Ziel erreicht haben, Fehler, die Sie nicht wiederholen sollten, und Schlussfolgerungen, die Sie für Ihre Arbeit verwenden können.

Erklären Sie den Wert von Design

Das Projekt begann also von vorne. Im Rahmen dieser Entscheidung entstand der Vorschlag, MVP zu betreiben und unsere Arbeit nach dem Festpreismodell zu bezahlen. Das schien logisch, denn wenn es keinen Code von jemand anderem gibt, gibt es keine Risiken.

Das Minus des Fixpreises als Zahlungsmodell ist, dass es dem Projekt die Flexibilität entzieht: Während die Funktionalität implementiert wird, auf die sich die Parteien in der technischen Aufgabe geeinigt haben, kann sich der Markt ändern und das Ergebnis der Arbeit wird die tatsächlichen Benutzerprobleme nicht mehr lösen. Es ist nur möglich, MVPs zu einem festen Preis zu entwickeln, wenn Sie alle Hypothesen gründlich und gründlich getestet, die technischen Spezifikationen entworfen und die detaillierte Dokumentation geschrieben haben. Unser Kunde hat das Design einfach vernachlässigt oder vielmehr auf sich genommen.

Die Geschichte mit der Wahl eines Dienstes für Chats ist bezeichnend. Der Kunde hat selbst nach möglichen technischen Lösungen gesucht und uns verschiedene Dienstleistungen zur Auswahl gestellt: "Was ist besser?" Wir haben uns für Service A entschieden, weil es für das Projekt mit einer Reihe von API-Methoden geeignet ist, und aus Sicht der Entwicklung und Integration war es besser als Service B. Wir haben den Service nicht für die Arbeit mit unserer Infrastruktur konzipiert und nichts anderes als diese formalen Kriterien überprüft: Weder Stabilität , keine Antwortgeschwindigkeit, nichts - es gab kein Budget. Der Chat reagierte langsamer als es möglich war, wenn Zeit für eine Überprüfung blieb.

Fallen Sie nicht auf Manipulationen herein im Sinne von „Wenn Sie es brauchen, um eine Aufgabe zu erledigen, tun Sie es kostenlos! Sie müssen es gut machen! “Wenn es solche gibt: Das Wesentliche bei der Outsourcing-Entwicklung ist die Lösung von Kundenproblemen für Kundengelder.

Der Analytiker muss gestalten. Er verfügt über das Wissen, das es ihm ermöglicht, zu verstehen und klar zu formulieren, was der Kunde im Endeffekt genau benötigt, und eine gemeinsame Systemarchitektur zu erstellen: Welche Dienste werden im Produkt enthalten sein, gibt es eine Integration mit Systemen von Drittanbietern, wie werden Anforderungen zwischen Diensten ausgetauscht, wo werden Informationen gespeichert, wie Dies ist zum einen erforderlich, damit das Produkt des Kunden schnell und zuverlässig funktioniert, und zum anderen, um zu klären, was Sie einsparen können und was sich genau nicht lohnt.

Machen Sie die Bedeutung von MVP für alle gleich

Was MVP für uns bedeutete:

• Wir sind uns über die Grundfunktionalität der Anwendung einig und optimieren nur die Funktionen, die sich darauf beziehen, auf das Ideal. Andere Funktionen sollten funktionieren, damit die Anwendung nicht geschlossen werden muss.
• Wir stellen ein Minimum an Funktionen zur Verfügung, die zur Lösung eines Geschäftsproblems erforderlich sind, und keinen dafür vorgesehenen Administrationsbereich.
• Wir verschieben die Anpassung auf einen späteren Zeitpunkt, dh wir verwenden Komponenten im Design, die auf mehreren Bildschirmen wiederverwendet werden können, lehnen komplexe Layoutelemente ab und vereinfachen das Design bei Bedarf.
  

MVP-Clients haben jedoch unterschiedliche Interpretationen. Was bedeutete das für uns:

• minimale Funktionalität für minimales Geld.

In der Zukunft passierte es irgendwie, dass „minimales Geld“ übrig blieb und die Position „Wir wissen, wie es geht, also tun Sie, was wir sagen“ hinzugefügt wurde.

Eine solche Position bedroht eine normale Partnerschaft. Die Bedrohung kann nur durch das Design und eine funktionale Aufgabe beseitigt werden, die alles beschreibt, was die Anwendung tun sollte. Gibt es neue, nicht festgeschriebene Anforderungen und Vorschläge? Beachten Sie das Bundesgesetz und bieten Sie an, Zeit zu kaufen. Vielleicht ist dies Formalismus und nicht Kundenorientierung, aber es ist fair in Bezug auf Ihr Unternehmen.

Noch einmal: MVP wird mit Fix kombiniert, wenn es Design gibt. Wir hatten es nicht, aber Sie sollten es haben.

Lassen Sie die Entwickler mit Ihnen streiten

Und arbeiten Sie niemals mit einem unverbindlichen Entwurf des Kunden, wie wir gearbeitet haben.

Entwickler sind am häufigsten gebunden: Sobald die Aufgabe festgelegt ist, werden sie dies tun. Bei Projekten mit begrenztem Budget muss jedoch die Umsetzung jeder potenziell komplexen Aufgabe in Frage gestellt werden, um sie zu flexen und die Frist einzuhalten.

Die Quelle solcher Aufgaben war unerwartet das Design, mit dem sich der clientseitige Designer befasste. Unseren Entwicklern wurde mitgeteilt, dass sie umgehend nach Korrekturen gefragt werden, sodass wir nicht mit der statischen Version des Entwurfs, sondern mit dem Figma-Editor arbeiten, in dem dieser Entwurf erstellt wurde. Die Entwickler gaben eine Bewertung ab und machten sich an die Arbeit.

Und dann tauchten nacheinander Elemente auf, die ursprünglich nicht vorhanden waren - dies war aus dem Backup ersichtlich, das ich für alle Fälle erstellt hatte. Es ist jedoch unmöglich, vor Beginn der Entwicklung zu überprüfen, ob sich ein bestimmtes Designelement geändert hat - zumindest, weil der Entwickler die Aufgaben in einer für ihn bequemen Reihenfolge ausführt.

Das Erkennen von Inkonsistenzen half dieser Redefreiheit. Der Entwickler könnte auf mich zukommen und nicht nur die Elemente ansprechen, die nicht schnell erfunden werden können, sondern auch die Elemente, die im Design des Kunden enthalten sind - das ist verständlich, da der Designer sie dort selbst heimlich eingeführt hat -, aber nicht in unserer Kopie. Diese Elemente wurden nicht in die Bewertung einbezogen, was bedeutet, dass wir sie nicht auf eigene Kosten behandeln sollten.

In der Welt der gesunden Entwicklung erlaubt der feste Preis nicht, den Arbeitsaufwand zu erhöhen und die Bedingungen für unterwegs zu ändern.

Halten Sie den Kunden vom Team fern

Das letzte Mal haben wir die Entwickler und den Kunden direkt miteinander verbunden - es gibt Teams, bei denen der Manager zuallererst die Bedingungen und das Budget überwachen und nicht als Übermittler der Kundenanforderungen dienen sollte.

Dies ist eine großartige Methode mit ihren Vorteilen: Die Reaktion jeder Seite ist schneller, das Team versteht die Geschäftsaufgabe besser, seine Autorität wächst und der Manager stirbt nicht als Sender. Aber da ich wusste, dass der Kunde persönlich werden kann, habe ich ihn vom Team isoliert. Nur der Kunde, der Account Manager und der Projektmanager, also ich, blieben im Chat.

Was hat es uns gegeben? Ich moderierte die Kommunikation und erlaubte persönlichen Beziehungen nicht, die Arbeitsroutine zu vergiften. In Momenten, in denen der Kunde das Team auf ihre Weise kritisierte, antwortete ich, dass wir Maßnahmen ergreifen und den Mitarbeiter bestrafen würden. Beobachtungen zeigen, dass es ausreicht, um einige Kunden zu beruhigen, jemanden aus dem Team zu opfern, auch zum Spaß. Daher arbeitete der Mitarbeiter ruhig weiter und wusste nicht einmal, dass er bestraft wurde.

Wenn Sie vermuten, dass der Klient unruhig ist, bringen Sie das Team erst für eine Weile mit, wenn Sie vom Gegenteil überzeugt sind.

Formulieren Sie das Feedback des Kunden an das Team neu

In einer Atmosphäre ständigen Misstrauens und Kritik gelingt es dem Team nicht mehr, das Feedback in der Form zu verarbeiten, in der es ankommt, und der Kunde beginnt zu glauben, dass das Team nur mit bösen Absichten zur Arbeit kommt - und verkörpert sie.

Was tun mit diesem Manager? Kosmetische Bearbeitung würde nicht schaden: Ich habe die Persönlichkeitsbeurteilung aus dem Feedback entfernt und nur den Wortlaut des Fehlers ohne Bedeutungsverlust gelassen. Und da Sie vom Kunden kein Lob erhalten haben, habe ich nicht vergessen, dem Team mein eigenes Feedback zu geben - für Aufgaben, bei denen keine Fragen aufgeworfen wurden, was bedeutet, dass sie aus Sicht des Kunden gut ausgeführt wurden.

Es war: “Die Anwendung funktioniert nicht Zahlung. Welche Hände hast du gemacht? "
Es wurde: „Leute, die Anwendung muss etwas bezahlen, der Kunde bittet, es herauszufinden, hier sind die Screenshots. Und mit den Animationen, die vor einer Woche zurückgeblieben sind, war alles in Ordnung. “

Beeilen Sie sich nicht, um Fehler zu bekommen

Das Eingeben von Fehlern in den Task-Manager, sobald sie vom Client empfangen wurden, ist unerfahren. Mit kritischem Auge hilft der Manager dabei, Stunden an Entwicklern und Testern zu sparen. Wenn Sie nur mit dem Kunden sprechen oder nach den Aktionen fragen, die zu dem Fehler geführt haben, und das Video aufzeichnen, können Sie verstehen, dass der Fehler keine Priorität hat oder aufgetreten ist, weil der Kunde etwas falsch gemacht hat - und Sie müssen ihn jetzt nicht mehr bearbeiten. Also habe ich ein Viertel der eingehenden Fehler herausgesucht, und ein weiterer Teil betraf den integrierten Service-Support-Service - es waren genügend SDKs von Drittanbietern im Projekt.

Kundenname nicht erwähnen

Vielleicht die wichtigste Erkenntnis. Nach der alten Erinnerung eines Teils des Teams führte die Äußerung des Namens eines Kunden zu einer voreingenommenen Haltung gegenüber einer noch so angemessenen Bemerkung. Und ich kam auf die Idee, den Kunden nur den Kunden zu nennen, was das Negative reduzierte. Es scheint, dass jeder versteht, über wen er spricht, aber glauben Sie mir - diese Nuance hat die Ökologie des Projekts verbessert.

Fazit

Aus Gründen der Klarheit habe ich mich dazu entschlossen, alles oben Genannte auf eine Tabelle zu reduzieren, in der das Prinzip "Wie geht das nicht und wie geht das?"



Unsere Ratschläge sind jedoch nur dann hilfreich, wenn die für die Bearbeitung eingehender Kunden in Ihrem Unternehmen verantwortliche Person oder der Account Manager in der Verhandlungsphase Kundenmängel aufdeckt.

Hier sind einige wichtige Punkte, auf die wir jetzt achten:

1. Was der Kunde über den vorherigen Auftragnehmer sagt, wenn er es war. Wenn er negativ über ihn spricht, besteht die Möglichkeit, dass er keine andere Meinung als seine eigene wahrnimmt und seine Entscheidungen durchsetzen wird.
2. Hat der Kunde Erfahrung in der IT. Für einen erfahrenen Kunden wirft der Entwicklungsprozess weniger Fragen auf.
3. Ob er um jeden Cent handelt oder nicht. Je höher der Wunsch des Kunden ist, weniger zu zahlen, desto williger und hartnäckiger argumentiert er.

Ich hoffe, dieser Artikel wird jemandem nützlich sein. Und wenn Sie schon an meiner Stelle waren, dann erzählen Sie uns, wie Sie so schwierige Kunden gelöst haben.