¿Cómo puedo evitar que me culpen por el fracaso de la gestión de proyectos cuando soy simplemente un programador senior?

Soy líder técnico en un proyecto con un Project Manager (PM) y un equipo de desarrolladores. El liderazgo enfatiza con frecuencia que soy responsable del éxito del proyecto.

Estoy descubriendo que tengo que organizarme y coordinarme porque si no no puedo liderar técnicamente al equipo. Por ejemplo, las historias de los usuarios no se documentan como deberían, los miembros del equipo no asisten a las reuniones de sprint, etc. Los riesgos no se comunican ni se abordan. Básicamente, cualquier trabajo, técnico o no, es muy difícil o imposible de completar.

Estoy cansado de hacer el trabajo de PM y, sin embargo, si paro, el proyecto probablemente fracasará. Se lo mencioné a mi gerente, pero él lo ignoró. ¿Qué debo decir para asegurarme de que no me culpen por el posible desastre?

Los comentarios no son para una discusión extensa; esta conversación se ha movido a chat .
Muchas oraciones aquí tienen varias palabras en blanco y negro: "no pueden, no son, no son, no funcionan, son imposibles". Si bien el uso de estas palabras es útil para enfatizar su situación a los demás, en realidad, la mayoría de ellas probablemente estén atenuadas por "considero mi opinión basada en mi experiencia y comprensión de las buenas prácticas" junto con "lo veo con frecuencia". Otros pueden venir a diferentes conclusiones sobre la gravedad de, o en algunos casos, incluso la necesidad de ciertas actividades.La mayoría de las personas se preocupan y quieren hacer un buen trabajo, por lo que preguntaría más sobre cuáles son los problemas subyacentes que pueden estar afectándolos personalmente.
Recuerde también que todo el mundo tiene una carga que llevar.

Respuestas (6)

Estoy cansado de hacer el trabajo de PM y, sin embargo, si paro, el proyecto probablemente fracasará.

Entonces deja que falle. Lo antes posible. Al hacer el trabajo de otras personas, se está convirtiendo en un facilitador. Les permite hacer un mal trabajo y no obtener ningún comentario al respecto. Y a nivel personal, si estás haciendo el trabajo de dos personas, tienes el doble de probabilidades de convertirte en el chivo expiatorio, porque no importa lo que falle primero en el proyecto, fuiste tú quien trabajó en él . Y a nadie le importará si deberías haber sido tú. Fuiste tu.

Documenta todo lo que falta para hacer tu trabajo correctamente.

Advierta sobre cualquier cosa que vea que podría dificultar el éxito del proyecto.

Solo si algo falla, el PM recibirá la retroalimentación de su jefe de que necesita hacer un mejor trabajo. Mientras los cubra, nunca recibirán esta retroalimentación y nunca mejorarán.

Así que asegúrese de que algo falle lo suficientemente pronto como para cambiar las cosas y volver a encarrilar el proyecto.

Lo peor que podrías hacer es encubrirlos y hacer su trabajo hasta que ya no sea posible para ti, porque entonces será demasiado tarde para cambiar algo y se verá como tu culpa. No importa si el trabajo del PM es escribir historias de usuario, una vez que escribió el primer lote, nadie recordará que debería ser el trabajo del PM y cuando le dice a la gente que no puede escribir más y hacer su propio trabajo también, es suena como tu fracaso.

No le hagas eso al proyecto y no te hagas eso a ti mismo.

El fracaso es una retroalimentación importante. Las personas y las organizaciones aprenden a través del fracaso. No lo cubra. Priva a todos de comentarios y oportunidades de mejora. Fracasa pronto y abiertamente. Luego sugiera mejoras y ayude a solucionarlo.

... y si el gerente de OP lo ignora, entonces probablemente debería escalar al gerente del gerente, de lo contrario, todo lo que diga se hará realidad.
Bueno, yo no lo escalaría. O solo al nivel del que recibiste órdenes. Quienquiera que te haya dicho que hagas de este proyecto un éxito, infórmale de lo que necesitas y de lo que falta actualmente y de que el éxito del proyecto está en peligro. No pases por encima de su cabeza. Si no brindan, déjalos fallar , no hagas su trabajo encima del tuyo.
Agregaría a @nvoigt para asegurarme de que todos sus escalamientos estén por escrito con marcas de tiempo, como en un correo electrónico. archivarlos. Toda la documentación típica de CYA para demostrar que usted hizo sonar el silbato y no se hizo nada al respecto.
Y si tiene conversaciones en persona, simplemente resúmalas en un correo electrónico. "Solo para reiterar nuestra conversación anterior, discutimos cómo debe suceder X para que el equipo funcione de manera efectiva..." cosas así. CC a su gerente, para que si es su problema, se convierta en su problema.
Me gustaría sugerirle que comunique esto. Por ejemplo, si va a tirar entradas sin criterios de aceptación, explíquelo de antemano. Envíales un correo electrónico donde expliques brevemente por qué (no puedes hacer tu trabajo real) para que tengas documentación y, lo que es más importante: "Te he notificado X veces, ¿hay algo que no está claro?" y algo así como "Si quieres alguna aclaración, solo pregúntame". Contesta las preguntas, no lo hagas por ellos.
Solo para reiterar: Documente, documente , DOCUMENTE toda comunicación por escrito y sea muy explícito sobre lo que usted y su equipo están esperando. Asegúrate de enviarle una copia a tu gerente para que nadie pueda volver más tarde y decir "Pero no le avisaste a nadie".
Considero que esta respuesta es extremadamente pasiva y agresiva (¿pasiva agresiva?) Por ejemplo, ¿qué pasa si nada falla de inmediato, pero continúa indefinidamente? Debe enfatizarse que este enfoque funcionará en algunas culturas de empresa, pero será completamente contraproducente en otras. Si OP no tiene una buena idea de la cultura, desaconsejaría encarecidamente este enfoque. En cambio, creo que el enfoque correcto ya está resumido en un comentario anterior: "¿Puedes despedir/reasignar al PM? Si no, entonces no eres realmente responsable, sino solo un chivo expiatorio".
@ldog Estaría de acuerdo si "Advierta sobre cualquier cosa que vea que podría obstaculizar el éxito del proyecto". faltaría en la respuesta. Un ejemplo: OP está escribiendo documentos faltantes en User Stories. ¿Por qué no hacer una cita con PM para hablar sobre la documentación que falta? No "por qué falta", sino "Necesitamos saber las respuestas a estas preguntas: ... Por favor, responda". - Es tan fácil como eso.
No entiendo cómo alguien podría pensar que "dejar que el proyecto fracase y culpar a los demás después" es un buen consejo.

Ve a hablar con (!) ese gerente de proyecto. Ve a hablar con tu gerente. Tal vez les pida a los tres que se reúnan en la oficina de su gerente. Una vez allí, cuéntales tus inquietudes.

Y luego... escucha.

No digas nada. Has tenido tus cinco minutos para decir tu parte, ahora dales a cada uno de ellos la misma oportunidad de decir la suya. No pierda ese tiempo formulando su refutación. En lugar de eso, escucha atentamente y prepárate para aprender algo en lo que no habías pensado hasta entonces. Los tres son "partes interesadas". A todos ustedes se les paga para tener el propósito común de lograr el éxito del proyecto. La comunicación entre los tres obviamente se ha roto de alguna manera.

Este. La comunicación es la clave. Solo asegúrese de comunicarse claramente de una manera que los demás no puedan malinterpretar.

No te recomiendo que dejes que el proyecto fracase, para dar una lección o lo que sea.

La gente tiene la suposición equivocada de que los que son castigados por el fracaso de los proyectos son siempre los culpables. Es como si nunca hubieran trabajado en el mundo real.

Además, la mentalidad de fracaso rápido que algunas personas creen que es ampliamente aplicable es simplemente incorrecta. Algunas fallas pueden causar daños profesionales severos.

Debido a que se le ha encargado el éxito de los proyectos, debe resaltar los problemas a la persona que le ha dado esta responsabilidad. Parece que este no es tu jefe.

Si su gerente no le brinda el apoyo adecuado, debe considerar presentar una queja al equipo de recursos humanos. Es posible que no entiendan el contexto del problema, pero pueden hacer que su jefe explique por qué se niega a apoyarlo.

Los recursos humanos generalmente están interesados ​​​​en las fallas de comunicación entre los empleados de una organización que podrían causar daños a la organización.

Por lo general, no alentaría a las personas a pasar por encima de la cabeza de su jefe, pero como el liderazgo se está comunicando directamente con usted, parece que en este caso sería adecuado acudir a ellos también si no obtiene la resolución de los problemas.

No estoy seguro de estar de acuerdo contigo en que las personas que sugieren dejarlo si fallan no viven en el mundo real. Es posible que hayan aceptado que a veces los empleados se encuentran en situaciones sin salida en el mundo real . Donde los supervisores/jefes/HR/etc. no están dispuestos a ayudar. El resto de las otras respuestas alentaron la comunicación y las acciones cya que pueden mitigar el problema, un chat de recursos humanos también puede ayudar. Creo que el incentivo para dejar que fracase es para que la persona no se estrese demasiado, trabaje horas extras no pagadas o algo así.
"Algunas fallas pueden causar daños profesionales severos": la idea de fallar rápido y fallar temprano previene daños profesionales severos porque inhibe que los daños se acumulen. Si los bordes ásperos y problemáticos de un problema se exponen tan pronto como se crean, ni siquiera tienen tiempo para causar grandes problemas. Los grandes problemas ocurren porque la gente trata de ignorar muchas "pequeñas cosas", y luego se combinan en una gran bola de problemas que nadie puede resolver más tarde.
@ T.Sar Eso es cierto para cierto tipo de producto o servicio. No es un principio de software aplicable a nivel mundial.
@GregoryCurrie Es un principio de proceso, no de producto o servicio. Se trata de iterar. se trata de encontrar problemas, solucionarlos y hacer que todo sea un poco mejor la próxima vez. Esto ni siquiera se limita al software: varios otros campos tienen mantras similares de "fallo rápido" que se utilizan para evitar daños más graves más adelante. "Falla rápido" es más o menos la versión de gestión de procesos de "si tienes que comer cuervo, cómelo mientras es joven y tierno".
@GregoryCurrie Tenga en cuenta que "fallar rápido" generalmente no se trata del proyecto en su conjunto, sino de los sprints o partes más pequeñas del mismo. Se trata de poner en evidencia la pieza rota, arreglarla o reemplazarla y volver a intentarlo. No es "fallar rápido y darse por vencido".
@ T.Sar ' No es "fallar rápido y rendirse". Y, sin embargo, así es exactamente como se vende.
@GregoryCurrie No, no lo es. Nadie lo vende como "fracasar rápido y darse por vencido". Fallar rápido siempre es parte del concepto de aprender e iterar su proceso. El principio no puede pagar la ignorancia de sus usuarios.
@ T.Sar Otras respuestas dicen "Deje que el proyecto fracase". No, "pruebe algunas cosas y vea si puede hacer que no falle". Lo que diga ahora no cambia la forma en que algunos de sus defensores lo venden. No tienes que fallar para aprender. Aquellos que dicen que necesitas hacerlo, a menudo son demasiado estúpidos para adaptarse.
@GregoryCurrie Te estás perdiendo el punto sobre la idea general de fallar rápido. Lo referiré a este artículo de Forbes sobre la idea general . No es lo mejor, pero ayuda a entender el concepto y por qué ayuda hoy en día.
Estoy de acuerdo con todo, excepto con ir a Recursos Humanos, para agregar más partes móviles al proyecto, estás perdiendo el enfoque y asumiendo que Recursos Humanos hará una contribución significativa.
Al menos en cualquier lugar en el que he trabajado, ir a Recursos Humanos sería algo muy extraño para este tipo de problema. Aunque supongo que depende mucho de la estructura de la empresa.
@GregoryCurrie ¿Adaptarse a qué? En el mundo real, los proyectos pueden fracasar por razones dentro y fuera de tu control. Hipotecarse para recuperar el control de lo que no controla a veces puede ser una opción, pero aun así puede no ser suficiente. Puedes hacer todo bien y aun así fallar. Las fallas sucederán. No se trata de aceptar el fracaso, se trata de que el fracaso simplemente ocurra a veces, así que también podrías tratar de salvar algo bueno de él. Castigar y culpar son cosas que en realidad no solucionan los problemas, solo refuerzan las estructuras de poder y lo engañan para que se someta a la sumisión.
Como defensor del método del fracaso rápido, me gustaría decir que nadie dice "fracasar y darse por vencido". Tu publicación se lee un poco como si hubiera dicho "maliciosa y silenciosamente falla a sus espaldas para castigarlos". No dije tal cosa. Mi publicación dice claramente que debe advertir a las personas sobre el problema y termina con "Luego sugiera mejoras y ayude a solucionarlo".

Documento, documento, documento. Ponga todo por escrito y guarde copias.

Si no tiene autoridad para contratar/despedir, entonces no es responsable del éxito del proyecto. Esa es la responsabilidad de la dirección del equipo. Su trabajo es simplemente darles la información que necesitan para tomar las decisiones de contratación.

Pase lo que pase, es posible que te culpen. Eso es solo parte de la vida. Pero, puede documentar para que cuando llegue la culpa, tenga la documentación para demostrar que advirtió a las personas de antemano.

¿De qué eres responsable? Tu propia salud. Tómese el tiempo suficiente para mantenerse saludable. En cualquier trabajo, hay muchas más cosas por hacer de las que se pueden hacer sin suicidarse. Por lo tanto, haga una lista de las 20 cosas que se deben hacer y solo trabaje en las cinco más importantes. Cuando la gente pregunte por los demás, señale que usted está haciendo lo más importante. Deja que el resto de las tareas fracasen. Si la gerencia dice que son importantes, pueden contratar para que se hagan.

Todas las respuestas hasta ahora son buenas. Pero no están juntos como yo sugeriría.

@nvoigt da en el clavo, más o menos. No seas un facilitador . No evite que surja la retroalimentación. No tomes cada trabajo del que alguien más abdique, como si fuera tu trabajo. No cubra las grietas ni actúe de una manera que no pueda sostener, si se convierte en "lo normal". Incluso para las mejores intenciones.

Pero esa no es toda la respuesta, para mí.

Tienes dos prioridades. Primero, intentar arreglar esto, para que el problema se resuelva. En segundo lugar, como bien dices, que no te culpen totalmente si no se resuelve.

Ese director de proyecto es responsable ante alguien. Esa persona necesita saber lo que está pasando. El proyecto como un todo es responsable ante alguien (por encima o más allá de usted). Esa persona necesita saber lo que está pasando.

Esas son las personas que tienen poder de decisión sobre el problema. Si no lo hacen, siguen siendo las personas que deciden si escalarlo o no.

Tu trabajo es hacer tu trabajo . Si se percibe que su trabajo hace que el proyecto tenga éxito, entonces necesita las herramientas adecuadas y deben funcionar bien. Un PM efectivo y productivo es una herramienta de este tipo. Si en secreto, no tienes uno, y eso está afectando el proyecto, no es tu decisión lo que debería suceder. Los gerentes pueden decidir hablar con ellos, despedirlos, apoyarlos, cambiar las tareas o roles de las personas, darle formalmente más control o, de hecho (como lamentablemente sucede a menudo), ignorarlo hasta que se dispare y luego preguntarse qué sucedió. Cuál de ellos tiene razón, no es su función ejecutiva decidir .

Por lo tanto, su trabajo es hacer que esas 1 o 2 personas se den cuenta de que su PM no es efectivo y está afectando el proyecto. Presente su evidencia documentada del problema. Luego pregúntales qué les gustaría que hicieras. Entonces hacerlo.

Es por eso que nvoigt y David R, ambos tienen razón. documentarlo. Tanto para cubrirse como para presentar con fuerza el tema. Lo que documenta son incidentes que muestran el comportamiento problemático y el impacto en el proyecto, que no debería ser simplemente "así que hice su trabajo por ellos". Considere qué motiva a esas personas: plazos, ganancias, motivación del equipo, calidad del cliente, lo que sea. Asegúrese de que su presentación no se trate de su pobreza. Se trata de cómo existe un problema y está afectando las cosas que les importan, o corren el riesgo de hacerlo. Si puede, venga con 2 soluciones y su costo/impacto/factibilidad, para ayudar a resolverlo. Imagina que te preguntaron "Entonces, ¿qué quieres?" o "¿Qué crees que deberíamos hacer?".

Además, permita que ocurra la falla. Si no gestionan los proyectos, habrá un impacto. documentarlo. Su papel es líder tecnológico. "El PM de nuestros equipos no es PMing, y estas fueron las consecuencias de hoy. No es la primera vez, por mucho. Necesitamos que esto se resuelva, o corremos el riesgo de perder los plazos/beneficios/costos de errores/reputación/lo que sea". Si los miembros del equipo necesitan tareas, o cualquiera que sea el trabajo del PM, dígales que hablen con el PM, lo siento, ese es su trabajo, el mío es el líder técnico. Duro, y la gente lo rechazará, pero hágalo de todos modos. ¡Establece límites ! Una habilidad clave.

No lo lleve directamente a Recursos Humanos. De nuevo, esa no es tu llamada. Alguien en tecnología le ha dado un trabajo que hacer, alguien en tecnología le ha dado un trabajo al PM, el problema es la gestión tecnológica de su equipo. La(s) persona(s) responsable(s), su llamada es si ir o no fuera de la tecnología. La única excepción que puedo ver es si la persona más importante en tecnología no está haciendo su trabajo, en cuyo caso solicite conocer a alguien aún más alto, y esté muy seguro de su terreno. Pero RR.HH. sigue siendo el lugar equivocado para su perspectiva sobre el PM, que se trata de tareas tecnológicas no realizadas, no de su estado laboral.

Además, como dice Mike Robinson, hable con el primer ministro, ¡y escuche! Si escalas esto y nunca hablas ni los escuchas, sentirán fuertemente que fuiste prepotente. Déles la oportunidad de explicar el problema. Dependes de ellos, ¿qué pasó cuando sucedió X? ¿Y Y? Úsalo y piensa bien qué hacer con él. Puede que no cambie nada. Puede influir en lo que presentas como "el problema" o "mis soluciones recomendadas", o cómo las sombreas.

Por último, busque las muchas publicaciones excelentes aquí sobre cómo documentar un problema, plantearlo y protegerse. Ponga las cosas por correo electrónico, y después de las reuniones, envíe un correo electrónico agradeciéndoles por su tiempo y anotando los resultados o lo que dijeron que es importante.

Si dijeron algo que parece un problema, "Entiendo que sientas que esto no es un problema y no planeas tomar medidas. Me preocupa que esto esté subestimando el impacto en el equipo, su trabajo y nuestros plazos, y nuestra eficiencia. Llamo su atención sobre los siguientes impactos que mencioné en nuestra reunión, que ya han surgido, antes de dejarlo, me gustaría verificar mi propia certeza profesional, ¿está seguro de que no desea que haga nada y que la situación se va a dejar como está?" O una redacción así. Documente que es una preocupación para usted, pero que habiéndola planteado, se remite a su decisión. Documente para que ambas partes queden claras: que definitivamente lo planteó y explicó el efecto, y definitivamente tomaron una decisión que siguió.

Por último, si implican o dicen que usted necesita hacer tanto su trabajo como el de otra persona (o parte del trabajo de otra persona), entonces, por supuesto, usted es solo una persona. Si asume otro rol medio, entonces su trabajo designado tomará el doble de tiempo. Nuevamente, esa es su elección, si cree que afectará su trabajo, haga lo mismo que arriba."Entiendo que sienta que puedo incluir la gestión de proyectos en mi carga de trabajo. No me siento cómodo de que esto se pueda hacer sin un impacto considerable en mi propio trabajo, que como discutimos es una carga de trabajo completa en sí mismo. Puedo hacer mi propia trabajo al 100%, o mi trabajo en menor medida y parte de otra persona, para lo que también puedo estar menos capacitado. Si es más importante cubrir la gestión de proyectos a costa de mi propia carga de trabajo, entonces espero que esto sea resuelto rápidamente para que mi propio trabajo sufra el menor tiempo posible. Me gustaría revisar la situación en un mes si ese es el caso, para evaluar si está funcionando aceptablemente". Luego documente si no lo es, o los impactos. No caiga en la tentación de ser presionado para compensar con horas extra no pagadas.

Mi función no se centra en la organización o la coordinación, pero se me considera el miembro de más alto nivel del equipo , por lo que el liderazgo insiste con frecuencia en que soy responsable del éxito del proyecto .

Personalmente, después de leer lo anterior, me quedé sorprendido, en el peor sentido. Creo que usted describió el problema aquí, porque como usted mismo ha dicho: no debe tener roles de coordinación en el proyecto. Sin embargo, parece que estás haciendo eso. Deténgase inmediatamente, esta es una clara violación de los límites. No hay forma de que seas responsable del éxito del proyecto solo porque eres "senior". Eso es una completa tontería, desde un punto de vista lógico. No eres un pulpo. Tiene roles específicos en un proyecto y se adhiere a ellos mediante un acuerdo por escrito. Este es claramente un problema para la alta dirección que aparentemente quiere hacer la vista gorda, porque:

Se lo mencioné a mi gerente, pero él lo ignoró.

Esto es viscoso en el mejor de los casos. Tu gerente debería haberte ayudado a aclarar sus expectativas, pero TÚ, por otro lado, deberías haberle dicho tus límites primero, en lugar de poner tus manos en roles fuera de tu enfoque. Esto es independientemente de lo bueno que seas, ese no es el problema aquí.

En conclusión, sugiero encarecidamente que se ciña a sus funciones y alce la voz (en sentido figurado) con su gerente. Estás siendo maltratado y sobrecargado de trabajo más allá de tus roles, según entiendo por tu pregunta.

Estoy totalmente en desacuerdo con 'No hay forma de que seas responsable del éxito del proyecto solo porque eres 'senior''. No creo que haya ninguna manera de que podamos decir eso con absoluta confianza. Estas cosas suceden, y suceden a menudo, en muchas organizaciones, sea o no lógico.