El miembro del equipo con frecuencia ignora las solicitudes "pequeñas"

TL;RD

Tiene uno o más problemas de proceso relacionados con la comunicación y la priorización. Necesita información adicional para inspeccionar y adaptar el proceso de su equipo de manera colaborativa y sostenible.

Tus problemas, replanteados

Usted hace los siguientes puntos en su publicación original:

1. Digo que son solicitudes pequeñas porque no son problemas críticos, pero me ayudan a mantenerme informado y a que el equipo funcione sin problemas[.]

2. Siento que él decide unilateralmente a cuál de mis correos electrónicos vale la pena responder.

3. He comenzado a realizar un seguimiento de estas pequeñas solicitudes ignoradas y promedian una por semana.

Estos son los que considero los elementos clave de su situación. Examinaré cada uno de ellos en detalle a continuación.

Análisis de los problemas descritos

Evaluación de la información que ha presentado

Estás preguntando un par de cosas que están estrechamente relacionadas. He tratado de separarlos para el análisis, pero al final permanecen estrechamente vinculados. Sin embargo, al desglosarlos, los detalles se vuelven direccionables.

1. Usted mismo afirma que estos no son problemas de misión crítica que se están tirando al suelo. Si no cree que los problemas sean importantes, ¿por qué debería hacerlo el desarrollador? Si son importantes, entonces necesita encontrar una manera de comunicar efectivamente el nivel de importancia real.
2. Haces una "declaración de sentimientos" sobre los correos electrónicos ignorados. Sus sentimientos son en gran medida irrelevantes para la gestión pragmática de proyectos. En cambio, debe preguntarle al desarrollador por qué estas solicitudes no son prioridades para él, de modo que actúe según la información del desarrollador en lugar de los sentimientos que son subjetivos e indemostrables.
3. Un promedio de una solicitud pequeña (en lugar de un entregable clave) que se pierde o se ignora por semana no es un volumen alto. Le está dando un nivel bastante alto de importancia a algo que parece, desde una perspectiva externa, ser un nivel estadísticamente pequeño de fallas de comunicación.

En general, parece que está comunicando información de baja prioridad y espera una respuesta o reconocimiento de alta prioridad. Tus expectativas no se están cumpliendo y estás teniendo una reacción a eso. Sin embargo, aún no ha identificado claramente el problema del proceso involucrado.

Extrayendo los problemas centrales

Los problemas centrales parecen ser que usted es:

1. Perseguir información que probablemente sea más importante para usted de lo que está comunicando efectivamente a cualquier otra persona.
2. Preocupado por un problema de comunicación, pero carece de información sobre la perspectiva o el contexto del desarrollador.

En resumen, está operando en un vacío de información. Eso nunca es constructivo. Claramente existe una desconexión en su proceso de comunicación, así como en las suposiciones operativas entre usted y el desarrollador. Ambos necesitan más (y mejor) información para resolver los problemas del proceso aquí.

Soluciones posibles

Hay varias formas de abordar este problema, pero hay algunos elementos clave que definitivamente debe tener en cuenta. Específicamente, considere adoptar uno o más de los siguientes pasos.

1. Si las "pequeñas solicitudes" no son tan importantes, o si se atienden la mayor parte del tiempo, simplemente puedes tratarlo como un problema menor cuando tienes dragones más grandes para matar.
2. Si las "pequeñas solicitudes" son realmente importantes , lo que contradiría la forma en que las presentó aquí, entonces debe asegurarse de que su proyecto las rastree, que sean visibles para el equipo y que su prioridad se comunique claramente a todos los involucrados.
3. Si tiene un problema de comunicación de cualquier tipo, debe abrir una discusión al respecto. Esto no tiene que ser una confrontación adversaria, pero sí necesita abrir un diálogo para que ni usted ni el desarrollador estén operando en un vacío de información.
4. Debe comprender las limitaciones de tiempo y las prioridades del desarrollador para ver cómo se alinean con el proyecto. Ya sea que ignore o no sus mensajes, es probable que esté tomando decisiones de priorización basadas en su ancho de banda disponible y su comprensión de sus prioridades inmediatas.
5. Si el correo electrónico no funciona para usted, deje de depender del correo electrónico como mecanismo de comunicación. A veces, cara a cara es la mejor manera de comunicarse sobre algo, especialmente si es demasiado importante como para perderse en el flujo de información.
6. Reconozca que los elementos de menor prioridad son de menor prioridad . No todo puede ser el Trabajo #1 al mismo tiempo, por lo que las tareas de menor prioridad deben dar paso a asuntos más urgentes.
7. Reconozca que incluso las "pequeñas solicitudes" pueden llevar mucho tiempo. Crean una sobrecarga de cambio de tareas, y la ciencia nos dice que a menudo lleva casi media hora recuperar el flujo además del tiempo que lleva la tarea en sí.
8. Formule un proceso en el que todos puedan estar de acuerdo. Si el proceso y las prioridades no son explícitos, entonces está operando en un área gris (y en gran medida inmanejable).

Al final del día, a menos que este desarrollador lo odie personalmente y con pasión (lo que no se evidencia como se presenta aquí), entonces es una falla del proceso . Como gerente de proyecto, su trabajo es identificar los problemas del proceso y definir los controles del proceso. Afortunadamente, definir controles de procesos y estrategias de comunicación no es algo que deba hacer por su cuenta; ¡puedes colaborar con tu equipo para identificar un proceso más efectivo!

Ya se proporciona un análisis muy completo en la respuesta de CodeGnome. Quizás algunas líneas de fondo serían útiles:

• El correo electrónico es una herramienta muy mala para el seguimiento de la mayoría de los problemas. Use un rastreador de problemas, trabajo pendiente con post-it, hoja de Excel compartida. Cualquier cosa vencerá al correo electrónico. Asegúrese de que una ubicación central tenga los problemas visibles para todos, lo que indica la prioridad desde la perspectiva comercial.
• Los problemas de baja prioridad deben colocarse en el rastreador de problemas y discutirse preferiblemente con todo el equipo, en un evento designado. Durante este evento, también puede indicar el alcance y la prioridad.
• Si el desarrollador está determinando el alcance y usted no quiere que eso suceda, asegúrese de que el alcance se determine de otra manera. ¿Lo establece usted, lo discute con el equipo y luego lo establece, o tal vez una parte interesada?

El caso que presenta da una sensación general de que la transparencia, la claridad y la autoinspección podrían mejorarse. Tener un diálogo con el equipo, determinar las expectativas entre todas las partes involucradas en el proyecto. Si algo no va bien, organice un debate en grupo sobre cómo mejorarlo.

Como PM entiendo que le corresponde a usted resolver esta situación. Es una buena idea confrontar al miembro del equipo, pero antes de hacerlo, también se requiere un poco de análisis en términos de la jerarquía de informes, si la hay. Si se trata de una organización matricial donde el informe de la persona está con otra persona, será una buena idea incluir a esa persona también.

Tener un proceso simplificado de seguimiento del requisito con prioridad y fechas de cierre esperadas en un simple rastreador o tablero definitivamente ayudará, ya que esto brindará más claridad para el individuo.