Teammitglied ignoriert häufig "kleine" Anfragen

TL;DR

Sie haben ein oder mehrere Prozessprobleme im Zusammenhang mit Kommunikation und Priorisierung. Sie benötigen zusätzliche Informationen, um den Prozess Ihres Teams gemeinsam und nachhaltig zu überprüfen und anzupassen.

Ihre Probleme, neu formuliert

Sie machen in Ihrem ursprünglichen Beitrag folgende Punkte:

1. Ich sage, es sind kleine Anfragen, weil es keine kritischen Probleme sind, aber sie helfen mir, mich auf dem Laufenden zu halten und dafür zu sorgen, dass das Team reibungslos läuft[.]

2. Ich habe das Gefühl, dass er einseitig entscheidet, welche meiner E-Mails es wert sind, beantwortet zu werden.

3. Ich habe begonnen, diese kleinen, ignorierten Anfragen zu verfolgen, und sie sind im Durchschnitt etwa eine pro Woche.

Dies sind, was ich für die Schlüsselelemente Ihrer Situation halte. Ich werde jeden von ihnen im Folgenden im Detail untersuchen.

Analyse der beschriebenen Probleme

Bewertung der von Ihnen präsentierten Informationen

Sie fragen ein paar Dinge, die eng miteinander verbunden sind. Ich habe versucht, sie für die Analyse auseinander zu ziehen, aber am Ende bleiben sie eng miteinander verbunden. Indem sie jedoch aufgeschlüsselt werden, werden die Einzelheiten adressierbar.

1. Sie selbst geben die Aussage ab, dass dies keine unternehmenskritischen Probleme sind, die auf den Boden fallen gelassen werden. Wenn Sie der Meinung sind, dass die Probleme nicht wichtig sind, warum sollte der Entwickler es tun? Wenn sie wichtig sind , müssen Sie einen Weg finden, das Maß der wirklichen Wichtigkeit effektiv zu kommunizieren.
2. Sie machen eine „Gefühlsaussage“ über die ignorierten E-Mails. Ihre Gefühle sind für das pragmatische Projektmanagement weitgehend irrelevant. Stattdessen müssen Sie den Entwickler fragen , warum diese Anfragen für ihn keine Priorität haben, sodass Sie eher auf Informationen des Entwicklers als auf Gefühle reagieren, die subjektiv und nicht beweisbar sind.
3. Dass pro Woche durchschnittlich eine kleine Anfrage (anstelle einer wichtigen Leistung) übersehen oder ignoriert wird, ist kein hohes Volumen. Sie messen etwas, das von außen betrachtet eine statistisch geringe Menge an Kommunikationsausfällen zu sein scheint, eine ziemlich hohe Bedeutung bei.

Insgesamt scheint es, dass Sie Informationen mit niedriger Priorität übermitteln und eine Antwort oder Bestätigung mit hoher Priorität erwarten. Ihre Erwartungen werden nicht erfüllt und Sie reagieren darauf. Allerdings haben Sie das Prozessproblem noch nicht eindeutig identifiziert.

Extrahieren der Kernprobleme

Die zentralen Probleme scheinen zu sein, dass Sie:

1. Informationen zu jagen, die für Sie wahrscheinlich wichtiger sind, als Sie effektiv an andere weitergeben.
2. Besorgt über ein Kommunikationsproblem, aber keine Informationen über die Perspektive oder den Kontext des Entwicklers.

Kurz gesagt, Sie bewegen sich in einem Informationsvakuum. Das ist nie konstruktiv. Es gibt eindeutig eine Unterbrechung in Ihrem Kommunikationsprozess sowie in den Betriebsannahmen zwischen Ihnen und dem Entwickler. Sie brauchen beide mehr (und bessere) Informationen, um die Prozessprobleme hier zu lösen.

Mögliche Lösungen

Es gibt viele Möglichkeiten, dieses Problem anzugehen, aber es gibt einige Schlüsselelemente, die Sie unbedingt berücksichtigen müssen. Erwägen Sie insbesondere, einen oder mehrere der folgenden Schritte zu übernehmen.

1. Wenn die „kleinen Bitten“ nicht so wichtig sind oder wenn sie die meiste Zeit erfüllt werden, dann können Sie es einfach als ein sehr kleines Problem behandeln, wenn Sie größere Drachen töten müssen.
2. Wenn die "kleinen Anfragen" tatsächlich wichtig sind , was Ihrer Darstellung hier widersprechen würde, müssen Sie sicherstellen, dass sie von Ihrem Projekt verfolgt werden, für das Team sichtbar sind und ihre Priorität allen Beteiligten klar kommuniziert wird.
3. Wenn Sie ein Kommunikationsproblem jeglicher Art haben, müssen Sie eine Diskussion darüber eröffnen. Dies muss keine gegnerische Konfrontation sein, aber Sie müssen einen Dialog öffnen, damit weder Sie noch der Entwickler in einem Informationsvakuum agieren.
4. Sie müssen die Zeitbeschränkungen und Prioritäten des Entwicklers verstehen, um zu sehen, wie sie mit dem Projekt übereinstimmen. Unabhängig davon, ob er Ihre Nachrichten ignoriert oder nicht, trifft er wahrscheinlich Prioritätensetzungsentscheidungen basierend auf seiner verfügbaren Bandbreite und seinem Verständnis seiner unmittelbaren Prioritäten.
5. Wenn E-Mail für Sie nicht funktioniert, verlassen Sie sich nicht mehr auf E-Mail als Kommunikationsmechanismus. Manchmal ist das persönliche Gespräch der beste Weg, um über etwas zu kommunizieren, besonders wenn es zu wichtig ist, um sich im Informationsstrom zu verlieren.
6. Erkennen Sie an, dass Elemente mit niedrigerer Priorität eine niedrigere Priorität haben . Nicht alles kann gleichzeitig Job Nr. 1 sein, daher müssen Aufgaben mit niedrigerer Priorität dringenderen Angelegenheiten weichen.
7. Erkennen Sie, dass selbst "kleine Anfragen" zeitaufwändig sein können. Sie verursachen Overhead beim Aufgabenwechsel, und die Wissenschaft sagt uns, dass es oft fast eine halbe Stunde dauert, um den Fluss wiederzuerlangen, zusätzlich zu der Zeit, die die Aufgabe selbst in Anspruch nimmt.
8. Schlagen Sie einen Prozess vor, auf den sich alle einigen können. Wenn der Prozess und die Prioritäten nicht eindeutig sind, bewegen Sie sich in einem grauen (und weitgehend unüberschaubaren) Bereich.

Am Ende des Tages ist es ein Prozessfehler, es sei denn, dieser Entwickler hasst Sie persönlich und mit Leidenschaft (was hier nicht bewiesen wird), dann ist es ein Prozessfehler . Als Projektmanager ist es Ihre Aufgabe, Prozessprobleme zu identifizieren und Prozesskontrollen zu definieren. Glücklicherweise müssen Sie Prozesssteuerungen und Kommunikationsstrategien nicht selbst definieren; Sie können mit Ihrem Team zusammenarbeiten, um einen effektiveren Prozess zu finden!

Eine sehr gründliche Analyse findet sich bereits in der Antwort von CodeGnome. Vielleicht wären ein paar Zeilen hilfreich:

• E-Mail ist ein sehr schlechtes Werkzeug für die meisten Problemverfolgungen. Verwenden Sie einen Issue-Tracker, Backlog mit Post-its, gemeinsames Excel-Sheet. Alles wird E-Mail schlagen. Stellen Sie sicher, dass die Probleme an einem zentralen Ort für alle sichtbar sind und die Priorität aus geschäftlicher Sicht angegeben wird.
• Probleme mit niedriger Priorität sollten im Issue-Tracker platziert und vorzugsweise mit dem gesamten Team bei einer bestimmten Veranstaltung besprochen werden. Während dieses Ereignisses können Sie auch den Umfang und die Priorität angeben.
• Wenn der Entwickler den Umfang bestimmt und Sie dies nicht möchten, stellen Sie sicher, dass der Umfang auf andere Weise bestimmt wird. Entweder Sie legen es fest, besprechen es mit dem Team und legen es dann fest, oder vielleicht ein Stakeholder?

Der von Ihnen vorgelegte Fall vermittelt insgesamt den Eindruck, dass Transparenz, Klarheit und Selbstkontrolle verbessert werden könnten. Führen Sie einen Dialog mit dem Team, bestimmen Sie die Erwartungen zwischen allen am Projekt beteiligten Parteien. Wenn etwas nicht reibungslos läuft, führen Sie eine Gruppendiskussion darüber, wie es besser werden kann.

Als PM verstehe ich, dass es an Ihnen liegt, diese Situation zu lösen. Es ist eine gute Idee, das Teammitglied zu konfrontieren, aber bevor Sie dies tun, ist auch eine kleine Analyse in Bezug auf die Berichtshierarchie erforderlich, falls es eine gibt. Wenn es sich um eine Matrixorganisation handelt, bei der die Person mit einer anderen Person zusammenarbeitet, ist es eine gute Idee, diese Person ebenfalls einzubeziehen.

Ein optimierter Prozess zur Verfolgung der Anforderung mit Priorität und erwarteten Abschlussterminen gegenüber einem einfachen Tracker oder Dashboard wird definitiv helfen, da dies dem Einzelnen mehr Klarheit bringt.