Anzahl der Personen in einem Team, die mit dem Kunden kommunizieren müssen?

In meinem Team funktioniert das so:

Wenn wir mit einem Problem konfrontiert sind, etwas Schlimmes passiert ist, das Projekt in Flammen steht, haben wir normalerweise Kontakt mit dem Kunden auf Managementebene (entweder PM oder TeamLead). Dasselbe gilt, wenn der Kunde fragt, wie viel/lange es dauern würde, ein Feature X hinzuzufügen. In solchen Fällen wird den Entwicklern gesagt, dass sie das Gespräch an die Managementebene weiterleiten sollen . Der Kunde hat auch Leute auf Managementebene auf seiner Seite.

Wenn Entwickler an einer bestimmten Funktion arbeiten oder ein Fehler von einem bestimmten Benutzer auf der Client-Seite gemeldet wird, sind Entwickler verpflichtet, sich direkt an die Person zu wenden .

Wir sind zu diesem Ansatz gekommen, indem wir restriktivere ausprobiert haben:

• Single Point of Contact - Wir hatten Probleme mit Verzerrungen der übermittelten Nachrichten: vom Client zur SPoC-Person, dann zu den Entwicklern und dann auf dem gleichen Weg zurück
• Jeder - wir hatten Probleme, dass einige Dinge mit Entwicklern konsultiert wurden, mit Ausnahme der Managementebene ; Ein weiteres Problem war, dass Entwickler direkt vom Kunden für etwas verantwortlich gemacht wurden

Nun arbeiten wir seit etwa einem Jahr erfolgreich mit unserem Modell. Entwickler werden weniger von Kunden abgelenkt und erhalten auf der anderen Seite spezifische Informationen zu Low-Level-Aufgaben direkt von der daran interessierten Person.

Es gibt eine Reihe von Faktoren, die Sie berücksichtigen sollten, warum Sie sich für Ihre Kommunikationsstrategie entscheiden:

• Kommunikationswege verkürzen. Grundsätzlich ist der kürzere Kommunikationsweg der bessere. Wenn Informationen vom IT-Mitarbeiter auf der Seite des Kunden über den PM des Kunden, Ihren PM, Ihren technischen Leiter zu Ihrem Entwickler gelangen, riskieren Sie Missverständnisse. Es wäre effizienter, wenn der IT-Mann auf Kundenseite direkt mit dem Entwickler Kontakt aufnehmen könnte.

• Ausgehende Nachrichten kontrollieren. Wenn Sie alle Kommunikationswege offen lassen, kann dies dazu führen, dass Ihr Entwickler unangemessene Versprechungen macht, nur weil es aus seiner Sicht eine gute Sache ist. Es kann darum gehen, morgen ein Feature zu versprechen, aber es kann auch sagen, dass "ich nur ein paar Tage dafür brauchen würde", was sogar wahr sein kann, es sei denn, Sie müssen berücksichtigen, wie es den Rest des Projekts beeinflussen würde.

• Kontrolle eingehender Nachrichten. Manchmal hat man es mit einem dieser schwierigen Kunden zu tun. Entweder neigen sie dazu, jeden ohne wirklichen Grund anzuschreien, oder sie ändern ihre Meinung etwa zweimal pro Stunde. In beiden Fällen möchten Sie wahrscheinlich jemanden, der das Team von solchen Kunden isoliert, damit Sie eine Art Filter haben, der nur relevante und aussagekräftige Nachrichten an das Team weiterleitet.

• Die richtigen Leute informieren. Was Sie im Grunde im Projekt wollen, sind Leute, die alle Informationen kennen, die sie brauchen. Wenn Sie nun mehrere Kommunikationswege haben, können Sie in eine Situation geraten, in der der Kunde einem Entwickler etwas gesagt hat, das mit einem PM und einem technischen Leiter geteilt werden sollte, aber der Entwickler dachte, jeder wüsste das und die Nachricht wurde nicht weitergeleitet. Auf der anderen Seite kann die gleiche Situation auftreten, wenn Sie eine einzige Kontaktperson haben und sie schlecht darin ist, zu entscheiden, wer was wissen soll. In diesem Fall hängt die Entscheidung stark von den Personen im Projektteam ab.

• Interne Angelegenheiten behalten, naja, intern. Es ist nicht so selten, dass wir uns mit einigen projektbezogenen Themen befassen und wir nicht alles mit dem Kunden teilen möchten. Besonders wenn die Beziehungen zwischen Ihnen und dem Kunden alles andere als ideal sind, ziehen Sie es vielleicht vor, gut durchdachte Botschaften zu kommunizieren, anstatt sie mit allen Informationen zum Problem zu aktualisieren.

• Gesamtbild berücksichtigen. Höchstwahrscheinlich ist ein Projektteam nicht die einzige Gruppe, die den Kunden kontaktiert, Sie haben wahrscheinlich auch andere Projekte, die von verschiedenen Teams, Verkäufern oder dem Management durchgeführt werden, die den Kunden kontaktieren. Da Sie Teil der Organisation sind, sollten Sie auch das Gesamtbild berücksichtigen. Wenn der Standardansatz innerhalb des Unternehmens darin besteht, jedes Thema sehr offen mit dem Kunden zu besprechen (eher ein typischer Fall für eine agile Organisation), möchten Sie möglicherweise mehr Kommunikationswege haben. Wenn Sie andererseits versuchen, mit dem Kunden zu spielen, um das Beste aus ihm herauszuholen (was manchmal in großen Unternehmen vorkommt), sollten die Kommunikationswege sehr begrenzt sein.

Es geht darum, die richtige Balance zu finden. Ich würde sagen, das Ziel ist es, effizient zu kommunizieren, dh Botschaften sind relevant und erreichen so schnell wie möglich den richtigen Adressaten, aber Sie dürfen Ihr Umfeld und seine Zwänge nicht vergessen.

Da die aktuelle Situation in Ihrem speziellen Fall ein Problem darstellt, würde ich daran arbeiten, sie kontrollierter zu gestalten, aber es ist schwer zu sagen, wo das Gleichgewicht liegt. Vielleicht möchten Sie hier und da die Kommunikationspfade abschneiden und sehen, ob es hilft. Wenn ja, gehen Sie einen Schritt weiter und bewerten Sie das Ergebnis erneut und so weiter und so weiter, bis Sie Ihr eigenes Gleichgewicht gefunden haben.

Wenn dieser Kunde Konflikte verursacht, indem er jeden in Ihrem Team anspricht, würde ich Ihnen empfehlen, einen Single Point of Contact (SPOC)-Mechanismus einzurichten.

Dieser Kunde muss diese zugewiesene Person oder Abteilung durchlaufen, um nach Informationen zu suchen. Wenn der Kunde weiterhin andere Mitglieder des Teams anruft, müssen Sie spezifische Anweisungen geben, damit sie den Anruf sofort an diese SPOC-Person oder -Gruppe weiterleiten.

Bei agilen Methoden erhalten Sie eine Rolle des Product Owners oder ähnliches, wodurch eine einzelne Person geschaffen wird, die für die Arbeit an der Produktvision auf Ihrer Seite verantwortlich ist. Ich würde jedoch Folgendes vorschlagen (vorausgesetzt, Ihr Team besteht aus <10 Personen):

1. Ich würde eine Person für die allgemeine Kommunikation bezüglich des Projekts/Produkts verantwortlich machen. Diese Rolle kann zum Beispiel jeden Monat transitiv sein.

2. Meiner Meinung nach ist es gut, von Zeit zu Zeit ein Treffen zu vereinbaren, bei dem alle Teammitglieder den Kunden oder seinen Vertreter treffen können, um die nächsten Schritte im Projekt zu besprechen. Dies ist der einfachste Weg, um alle auf die gleiche Seite zu bringen. Natürlich können Sie je nach Größe des Teams und Größe des Projekts Variationen verwenden. Beispielsweise kann das Treffen um eine Arbeitsgruppe und einen bestimmten Teil des Systems arrangiert werden.

3. Um zu vermeiden, dass der Kunde seine Fähigkeit verliert, informiert zu bleiben, können Sie von Zeit zu Zeit kürzere Besprechungen vereinbaren. Dies würde das Protokoll eines täglichen Aufstehens verwenden, aber es muss nicht täglich sein. Der Punkt ist, dass das Team alle anderen darüber informiert, was passiert. Es muss kurz sein und der Kunde muss zuhören. Sie können ihn am Ende kommentieren lassen, aber das Meeting selbst kann nicht für Diskussionen genutzt werden. Sie müssen später genommen werden, vorzugsweise von der unter Punkt 1 zugewiesenen Person.

Das Einzige, was Sie auf jeden Fall vermeiden sollten, ist die Ad-hoc-Kontaktaufnahme mit einem bestimmten Entwickler. Dies führt zu Missverständnissen und Informationsverlust.

Ich kann eindeutig sagen, dass es auf diese Frage keine richtige Antwort gibt. Es gibt Vor- und Nachteile für beide Extreme, und dies wird eher zu einem Balanceakt zwischen den beiden. Sie steuern die Kommunikation über ein oder zwei, Sie können sicherstellen, dass eine konsistente Botschaft nach draußen geht und weniger Missverständnisse hereinkommen. Beides sind Vorteile. Sie ersticken jedoch die Teambildung und riskieren die Entwicklung von Misstrauen zwischen Auftraggeber und Auftragnehmer sowie eine unangemessene Filterung sowohl ausgehender als auch eingehender Nachrichten durch Ihren POC. Strafen.

Hier muss man sich durchtasten und ein Gleichgewicht finden. Ziehen Sie einige Bereiche fest und lassen Sie andere locker, wenn möglich. Wofür Sie sich auch entscheiden, erfassen Sie Ihre Risiken und arbeiten Sie daran.

Wie andere gesagt haben, gibt es im Allgemeinen keine richtige Antwort. In Ihrem Fall haben Sie gefragt, ob die Umstellung der Kommunikation auf einen Ein- oder Zwei-Kanal-Ansatz Probleme verursachen würde. Nein, da Sie bereits gesagt haben, dass der direkt zum Team gehende Eigentümer Probleme verursacht. Das Entfernen einiger dieser Kanäle kann also nur helfen, ein Problem zu kontrollieren, das Sie bereits haben.

Es sollte EINEN Punkt der Wahrheit geben.

Ansonsten gibt es viel zu viel Politik, Fehlinterpretationen und verschwendete Zeit.

Ich stimme Mark Phillips größtenteils zu. Das Festhalten an einem einzigen Punkt der Wahrheit schützt dich vor „Er sagte, sie sagte“. Wenn Sie wirklich in Gedanken sind, ist eine konsistente Botschaft entscheidend, wenn Sie Glaubwürdigkeit und Vertrauen bewahren wollen.

Wenn Sie jedoch in Ihrem Team inkonsistente Nachrichten erhalten, haben Sie ein größeres Problem mit der internen Kommunikation.

Kunden/Projekte kennender und den Kunden bekannter PM-Leiter erleichtert für alle Seiten alles, insbesondere in „Notsituationen“.
Auch der Leiter, der den Kunden informiert und dem Kunden einen neuen PM vorstellt, wenn der PM auf ein anderes Projekt geändert/verschoben wird, verhindert, dass die Beziehung zum Kunden geschwächt wird.

Abgesehen von den oben genannten oder ähnlichen Bedingungen sollte die Kontaktperson des Kunden nur der zugehörige PM sein, um das Projekt wie erforderlich abzuschließen, ohne ein Chaos, das durch mehrere Informationen aus mehreren Quellen verursacht wird.

M0N4K0 im Detail SPOC sehr gut erklärt.