Soy el Tech Lead, mi jefe es el PM. En caso de desacuerdo, ¿cuánto debo insistir en mi punto de vista?

Todos nos encontramos con este tipo de conflicto.

Lo único que puedes hacer es DOCUMENTAR TODO

No hay nada de malo en que el jefe sea el jefe hasta que intente imponer sus errores a los demás. La forma más efectiva de hacer retroceder es hacer lo siguiente.

• Documente las fallas que ve en su enfoque.
• Documente las consecuencias que prevé al adoptar su enfoque.
• Presentar un enfoque alternativo
• Demuestre cómo su enfoque mitigará las preocupaciones que planteó
• Analizar las ventajas y desventajas de cada enfoque.
• Afirme firmemente que, debido a su análisis, se debe adoptar su enfoque.
• Guarde toda esta documentación
• Seguir las órdenes.

Luego, cuando explote y te pregunten por qué dejaste que sucediera, puedes responder que no lo hiciste. Documentó su enfoque recomendado, que fue anulado y predijo con éxito las consecuencias de no seguir su enfoque.

Este es un caso en el que debe dejar caer la pelota para probar su punto, pero hacer un registro en papel para que no se le pueda culpar.

Dejando a un lado los roles que ustedes dos tienen como Tech Lead y Project Manager respectivamente, está la carta de triunfo de que él es su jefe.

Entonces, realmente debe tener esa dinámica en mente: no estoy diciendo que nunca presente su caso cuando los dos no están de acuerdo, pero una vez que sienta que ha defendido su caso, si su jefe aún insiste en su opción preferida entonces solo tienes que aceptarlo. Tienes que ser tan poco emocional sobre el tema que se está discutiendo tanto como sea posible - de tu publicación parece que tu jefe tiene forma de volverse agresivo en estas discusiones y tan tentador/natural como puede parecer que no puedes estar a la altura porque eso solo aumentará su respuesta emocional y lo profundizará más. si su objetivoes básicamente bueno, pero su método propuesto es donde tiene el problema, asegúrese de enfatizar repetidamente que está de acuerdo con lo que están tratando de lograr, en serio, use las palabras "Estoy de acuerdo con usted" donde pueda porque esto puede desactivar la confrontación tono que este tipo de discusiones pueden desarrollar.

Si cree que seguir su camino tendría serias consecuencias negativas en la calidad del resultado, me aseguraría de documentar sus inquietudes (y las consecuencias asociadas) por correo electrónico como un movimiento de CYA, esto no tiene que ser un algo de confrontación o algo por el estilo: simplemente escríbalos en un correo electrónico mientras el problema aún se está "discutiendo", por ejemplo:

Hola [jefe/PM], estaba pensando en la función X en el Widgetron 3000 que estábamos discutiendo, veo de dónde vienes y estoy de acuerdo en que sería genial si pudiéramos hacer funcionar esa función, pero me preocupa que si ¿Utiliza el Unobtanium como sugiere que podría provocar que el condensador de flujo se vuelva inestable? Y corremos el riesgo de causar problemas mayores en el futuro. Si usáramos el Handwavium en su lugar, ¿no nos permitiría seguir haciendo la función X sin el mismo riesgo?

Es posible que no los escuchen y si están decididos, es casi seguro que no lo harán, pero probablemente le responderán anulándolos al menos y lo importante es que usted tiene estas preocupaciones y consecuencias y sus el despido posterior de ellos por escrito y, en caso de que haya algún intento de culparlo en el futuro, puede señalar esa cadena de correo electrónico y demostrar que los planteó y que fueron rechazados.

Si hay confusión en las discusiones que está teniendo, esto bien podría conducir a la confusión y al código enredado que está insinuando que ya está ahí. Suena como si estuvieras apilando espaguetis encima de espaguetis y te quejaras de que el plato se está desbordando.

Dependiendo de los plazos del proyecto, esta podría ser una buena oportunidad para dar un paso atrás y para que ambos vuelvan a evaluar el panorama general.

Vuelva a los requisitos básicos y vea si los problemas se pueden resolver cerrando todas esas pequeñas solicitudes y errores ad-hoc y analice y reescriba, y hágalo correctamente.

Si los plazos no permiten una reevaluación fundamental, comprométase con las solicitudes más recientes e inclúyalas lo mejor que pueda en ese momento. Luego deje que los errores salgan en las pruebas.

Después de eso, dé un paso atrás y vea si los cambios más grandes son más apropiados que las correcciones adicionales iterativas.

Suena como si estuvieras tratando de decirle rotundamente que no en algunas cosas. Lo que funciona mucho mejor es decirle lo que se necesita para hacer lo que quiere de forma segura, con el nivel de calidad adecuado.

Ese código es realmente difícil de cambiar sin romperse. Para manejar esos casos extremos, necesitaremos pasar algunas semanas agregando algunas pruebas en esa área y haciendo algunas refactorizaciones y limpieza primero. De lo contrario, el tiempo para corregir los errores después será completamente impredecible. Entonces deberíamos poder implementar los casos extremos en una semana más o menos, con mucha más confianza.

No mienta ni aumente su estimación. Sea tan preciso como pueda. Ser un jugador de equipo sincero y solidario. No estás diciendo que no. Estás diciendo: "Sí, definitivamente, estoy a bordo. Así es como lo hacemos". Luego conoce el costo real, incluida la deuda técnica, y puede decidir si aún vale la pena y cómo encaja realmente en comparación con otras prioridades.

Esta técnica puede ser realmente efectiva. Lo aprendí por primera vez en el contexto de la crianza de los hijos, y funciona en todo tipo de situaciones aparentemente estancadas. En resumen, pregúntate qué haría falta para que dijeras que sí. La respuesta casi nunca es nada, y te sorprendería lo que la otra parte está dispuesta a conceder también.

Como lo veo en su descripción, su PM está a cargo de los requisitos y usted está a cargo de la implementación. Los requisitos siempre deben estar documentados, incluso en un proceso acelerado como ágil/scrum. Si su PM está pidiendo menos documentación, no más, eso es una seria señal de alerta. El PM debe obtener los requisitos del cliente, presentarle los requisitos y exigir el cumplimiento documentado de esos requisitos (pruebas unitarias, pruebas del sistema, demostraciones, etc.). Hable sobre esto con su gerente funcional, su trabajo es facilitarle hacer su trabajo. Si su PM es su Funcional, ahora se trata de un problema de Recursos Humanos y debe hablar con su representante de Recursos Humanos. No lo presente como una queja, sino como un problema que le gustaría resolver para que todos puedan volver a trabajar.

Dicho esto, a partir de su publicación y comentarios, parece que tiene varias señales de alerta presentes, y debe revisar las siguientes políticas de su empresa y dejar que lo guíen: Ética/Código de conducta, Lugar de trabajo libre de amenazas, Violencia- lugar de trabajo libre y lugar de trabajo libre de acoso.

El PM está a cargo de qué , usted está a cargo de cómo . La clave es dejar en claro que sus cambios son parte del cómo y no del qué .

Por ejemplo, PM quiere la característica X. Quiere hacer los cambios A, B y C. Simplemente diga:

Para entregar X necesitamos que A, B y C estén en su lugar. No podemos entregar X sin entregar primero A, B y C.

Deje en claro que X requiere A, B y C. Si PM quiere X, entonces PM también obtiene A, B y C. No entres en demasiados detalles. PM no es técnico y no se espera que entienda por qué X depende de A, B y C.

Si X realmente no depende de A, B y C, entonces no utilice este enfoque.

Recuerde que nadie quiere software roto, ni siquiera el PM.

"Me temo que sus ideas serán perjudiciales para la aplicación, ya que al corregir los casos extremos se producirá una nueva serie de errores y la calidad del código base se verá afectada. Debido a eso, he tratado de hacerle cambiar de opinión. un par de veces, pero su postura se volvió progresivamente más agresiva hasta el punto de ser casi verbalmente abusivo".

No ha dejado en claro que el primer ministro está incursionando en áreas técnicas. Decidir que el programa necesita manejar los casos extremos correctamente está absolutamente en el ámbito del PM. Asegurarse de que una nueva serie de errores no resulte de esto es, literalmente, su trabajo.

Creo que tiene razón en querer permanecer en su área de especialización. Habrá momentos en los que haya cierta superposición como en este caso. Todavía puede asegurarse de que sus inquietudes desde el punto de vista técnico aún se aborden. Si bien es posible que no tome la decisión final, es importante que aún identifique y enfatice, si es necesario, los riesgos que asume el PM al aceptar o ignorar ciertas compensaciones. En este caso, puede tener estas características, pero existe el riesgo de que los cambios futuros sean más difíciles, llevarán más tiempo y podrían tener más errores.

Al final, estás haciendo sugerencias y el PM está tomando decisiones. Con suerte, su nivel de responsabilidad es proporcional a su nivel de autoridad.

Soy un desarrollador sénior y básicamente estoy desempeñando los roles de gerente de proyecto técnico y líder de equipo. Mi perspectiva a su pregunta es más desde el lado de PM:

En mi situación, era un desarrollador junior que constantemente cuestionaba y desafiaba las decisiones que estaba tomando con respecto al proyecto.

Hubo momentos en los que teníamos discusiones acaloradas sobre las características y el alcance, y finalmente llegué a un punto en el que ya no podía manejarlo. En lugar de alentarlo a contribuir con sus ideas, comencé a cerrarlo antes de que comenzara. Tratar de lidiar con su deseo de que yo viera las cosas a su manera se volvió más agotador y consumía más tiempo que comencé a cuestionarme si encajaba bien en el equipo.

La resolución aún no ha sucedido, pero mi desarrollador junior ha mejorado su actitud considerablemente en las últimas semanas.

Lo que hice fue definir claramente sus roles y responsabilidades, y comencé a tratarlo menos como un amigo y más como el PM para Dev. Cuando comienza a desafiarme en algo ahora, solo le permito ir tan lejos y luego digo algo como: "No es tu responsabilidad decidir eso".

Si bien su situación es bastante diferente, mi respuesta para usted es esta:

No puede abordar ninguno de los problemas técnicos mientras haya problemas personales sin resolver.

Siéntate y habla con él. Discúlpese por las cosas que ha dicho o hecho que podrían haberse manejado mejor . Sé que esto es difícil, pero al romper el hielo, le da a su compañero de trabajo un camino para disculparse también. (Puede que no, pero como mínimo se derribarán algunos ladrillos en la pared virtual entre ustedes). Enfatiza que quieres trabajar en equipo y que realmente quieres que el proyecto tenga tanto éxito como él.

Una vez que lo deje fuera del camino, puede comenzar a lidiar con la técnica. Aquí están algunas sugerencias:

1. Yo Y Tú, no Yo VS Tú : No debería haber perdedores para la discusión, solo debería haber 2 ganadores. Si empiezas con la actitud y el objetivo de que ambos deben ganar, realmente no hay discusión y el proyecto/tarea será un éxito.
2. Aborde un problema a la vez : diga "Me gustaría reunirme con usted para discutir ____", y luego manténgase firme... no mencione otros problemas. Si te pregunta sobre otras áreas problemáticas, solo di algo como: "Todavía no estoy preparado para hablar de eso".
3. Vaya por una victoria : No vaya por el gran elefante en la habitación. Trabaje en los problemas más pequeños y cree un patrón que puedan trabajar juntos antes de abordar cualquiera de los problemas principales.
4. Esté preparado : "Me pidió que implementara la función de esta manera, y solo quiero mostrarle que llegué a estimaciones de costos y que probablemente llevará XXX horas implementarla. Ahora tengo algunas otras ideas que podrían lograr el objetivo, pero podría ser más fácil y menos costoso de implementar".
5. Escúchalo : Si solo te estás concentrando en lo que vas a decir a continuación, o jugando con tu teléfono... para él será obvio que no estás escuchando. Imagine que ambos están parados en orillas opuestas de un río, y hay un objeto que nunca antes habían visto flotando en el aire entre ustedes. Nunca puedes ver su lado porque no puedes cruzar el río, así que tienes tu perspectiva y él tiene la suya . Pero puedes escucharlo describir lo que ve; y también puede estudiar el objeto caminando arriba y abajo de la corriente para obtener una vista diferente desde su lado. No hay nada de malo en tener una diferencia de opinión, pero al escuchar puedes empezar a apreciar su punto de vista.
6. Tome descansos : en sus reuniones, si algo no se ha resuelto y las cosas se calientan... pida tomar un descanso. Presionar cuando uno de ustedes está molesto solo empeorará las cosas.
7. No te centres en lo negativo : Si te centras en el millón de razones por las que su idea no funcionará, se sentirá socavado e inútil. Si comienza elogiando las cosas que le gustan de su idea, estará más dispuesto a comprometerse. En lugar de decir cosas como "No trabajaré porque...", cámbialo por una pregunta... "Sí, creo que eso podría funcionar, pero ¿qué pasa con ____?"
8. Acepte que es posible que no tenga toda la información : puede haber cosas que el PM sabe que no puede explicarle. Las razones pueden ir desde la confidencialidad hasta la falta de comprensión de su parte (y eso se convierte en vergüenza). En algún momento, tienes que aceptar su decisión.
9. Perdón : Hay un dicho: La falta de perdón es un veneno que TÚ tragas y esperas que la otra persona muera por ello. Mi esposa solía mencionar cosas de hace 15 años; pero un seminario de matrimonio al que fuimos decía que dejáramos que las heridas del pasado expiraran. Si sucedió algo que te lastimó hace más de 30 días, trata de dejarlo pasar.

Mi sugerencia es muy simple:

1) Exprese su preocupación por la implementación de los casos extremos y asegúrese de que se registren de manera clara y concisa.

2) Escuche la respuesta del director del proyecto. Si cree que ha entendido mal un punto, aclárelo.

3) Agregue los casos extremos a la implementación si el gerente del proyecto todavía los quiere en la aplicación.

4) Abandonar la discusión sobre el punto a menos que salga a la luz información nueva o pertinente.

5) Continúe trabajando con los nuevos casos extremos con tanta preocupación por la calidad del código como antes de la discusión.

No sé sobre la aplicación que está produciendo, pero sé que a los desarrolladores en general les gusta el código limpio y fácil de administrar. Entiendo de su pregunta que lidiar con los casos extremos agregará una complejidad significativa a la base del código que dificultará el mantenimiento del código y aumentará el riesgo del proyecto.

La otra perspectiva es que los casos extremos pueden ser importantes para el usuario final de la aplicación y, aunque su manejo haría que el código base fuera más difícil de seguir y mantener, el manejo de los casos extremos puede ser realmente un requisito. Muchas personas olvidan cuándo el software funciona correctamente, pero pueden decirle la cantidad de veces que no hace lo que ellos quieren que haga.

Al final, el Project Manager tiene la responsabilidad final desde su perspectiva. Si toma una decisión para los casos extremos, es su responsabilidad. Es su responsabilidad implementar los casos extremos y la aplicación lo mejor que pueda.

Debe leer, piense que su jefe es uno de ellos: https://en.wikipedia.org/wiki/Psychopathy_in_the_workplace

Significa que debes correr lo más rápido que puedas o comenzar una pelea que te costará mucho e incluso si ganas y él se va, te dará poco beneficio.

Si no puede conseguir que sus superiores vean la situación y la corrijan, debe corregirla usted mismo encontrando un nuevo trabajo.