Traté de concentrarme en sus preguntas clave en su parte de TL; DR , pero me tomé el tiempo para analizar algunos otros puntos.

Clave TL;DR; Preguntas

¿Cómo puedo comunicarle a Eva que las cosas no son como ella cree que son?

Tenga en cuenta que, según lo que ha dicho, tampoco se ha mencionado ninguna evidencia concreta de que las cosas son como usted cree que son.

Ahora, no estoy diciendo que no tengas motivos razonables para pensar que te pueden culpar a tus espaldas. Lo que estoy diciendo es que no sabes a ciencia cierta que esto es lo que realmente está sucediendo.

También podría ser que los varios proyectos fallidos que mencionaste hayan colocado el entorno de inicio y su gestión bajo un estrés intenso... especialmente si piensan que están tratando de evitar que su inicio tenga que declararse en bancarrota o algo así de serio. , y terminan desahogándose ante la primera señal de frustración adicional, ya sea real o percibida.

Por lo tanto, tenga presente esta distinción como una posibilidad.

Por otro lado, si asumimos que tiene razón, no parece que haya mucho que pueda hacer. ¿Cuántos otros desarrolladores de software existen allí con la responsabilidad de dar vida a las aplicaciones? Parece que solo tú y Adam están escribiendo código.

También dijiste que

Adán y Eva son muy cercanos.

No sé qué significa "muy cerca" en este contexto (por ejemplo, salen con frecuencia, o son pareja, familia, etc.), pero en cualquier caso, parece que el nivel de relación/confianza entre ellos es mayor. que el tuyo. (No dices cuánto tiempo has estado allí, etc.) Creo que eso puede hacer que las percepciones sobre cualquier tipo de crítica sean aún peores, independientemente de cuán bien intencionadas sean, especialmente porque le informas a Adán, no a Eva.

¿Qué alternativas tengo para señalar esto a Adán y/o Eva?

Por lo que dijiste, no parece que haya muchas buenas alternativas. Creo que prepararía mi currículum y empezaría a buscar en otra parte. Si lo están culpando a usted ahora, también lo culparán cuando el proyecto fracase, incluso si fue debido a sus propias prácticas de gestión (o falta de ellas); no parece un entorno en el que me gustaría quedarme.

Si le dices a Adam que es su culpa, no es como si él fuera a decir "Sí, ese es un punto justo; déjame decirle a Eve cuánto estoy de acuerdo con eso".

Tampoco parece que tenga reuniones periódicas con Eve (por ejemplo, 1 a 1), lo que puede dificultar las cosas. También podría empeorar las cosas si vas directamente a Eva, ya que Adán podría percibirlo como "pasar por encima de mi cabeza para culparme" y Eva como "pasar por encima de la cabeza de Adán para culparlo", independientemente de cuán objetivo y preciso sea. sus descripciones de la situación son.

Si Eve confía en Adam más de lo que confía en ti por cualquier razón (y parece que ese podría ser el caso), entonces ir a Eve será simplemente un ejercicio para pegarte un tiro en el pie.

Además, si bien sus intenciones pueden ser buenas, es poco probable que tomen bien su consejo de gestión no solicitado [1]. Simplemente encuentre un lugar diferente (y con suerte mejor) para trabajar y deje que el fracaso de cualquier proyecto futuro sea una consecuencia inequívoca de su propia acción; sus prácticas de gestión deficientes y/o la competencia técnica de Adam (o la falta de ella) serán los únicos culpables después de que ya no esté allí.

Otros detalles

[Yo] hice algunas sugerencias, como tener una lista de requisitos para cada tarea, ya que actualmente no seguimos ese proceso, y que revisara mi trabajo cuando haya "terminado".

Aquí está el primer gran problema que veo. En resumen: ¿Cómo puede alguien saber cuándo algo está "hecho" cuando nadie sabe lo que significa "hecho"? Hasta que el equipo comience a incluir este criterio de "terminado" como parte de las funciones, historias de usuarios, tareas, etc., no hay nada que revisar.

¿Ustedes realizan una reunión diaria de pie? Si no, deberías hacerlo. (Más abajo).

Hoy, teníamos otra característica que debía rehacerse, se terminó antes de que me fuera de vacaciones, pero Adam/Even decidió categorizar los datos en el servidor cuando yo estaba fuera, Adam lo hizo en el servidor hoy, pero la aplicación necesita para reflejar ese cambio. Por lo tanto, no pudo categorizar los datos sobre las aplicaciones.

Entonces este es el momento apropiado para exponer los siguientes hechos en términos inequívocos:

• la función se realizó antes de que usted se fuera, según el requisito en ese momento;
• los requisitos fueron cambiados arbitrariamente por Adam;
• Adam hizo estos cambios durante tu ausencia

Puede reformularlo tan apropiadamente como desee, pero debe ser explícito acerca de cuáles son los hechos. Si resulta que lo están culpando a sus espaldas, entonces este es el momento de usar los hechos a su favor de una manera que no requiera hacer una acusación directa. Simplemente presentar los hechos como parte de la conversación regular y dejar que los hechos se mantengan por sí mismos sería mi estrategia aquí.

Eve a Adam: ¿Por qué los datos [sic] no están categorizados? Adam me mira y dice: ¡Pensé que lo era! Yo: No, no lo es, la última vez que tocamos esta pantalla desde el lado de la aplicación fue antes de irme de vacaciones.

Creo que su respuesta aquí no tuvo en cuenta los hechos relevantes que señalé anteriormente. Cualquier persona razonable debe concluir que no es razonable estar molesto contigo en esta situación. Dicho esto, también he conocido gente poco razonable, así que...

Adam siempre microgestiona (y a veces tanto Adam como Eve) mi trabajo

¿Has considerado decir que, tal vez, solo tal vez, si te dejaran hacer tus tareas sin que te digan constantemente cómo hacer tu trabajo, entonces tal vez podrías estar más empoderado para ser más productivo/exitoso y, por lo tanto, ayudarlos a ser más exitosos de lo que ya son, especialmente después de varios proyectos fallidos?

Tenga en cuenta que esto debería redactarse mejor; Lo puse así para evitar ambigüedades. También asumo que no tienen buenas razones para preocuparse por tu desempeño cuando te dejan solo.

[son] siempre actualizados de todo lo que hago cada hora.

Esto es muy disruptivo, especialmente para un desarrollador de software . Dado que el desarrollo de software se trata de resolver problemas en su cabeza , las interrupciones constantes interrumpirán su proceso de pensamiento.

Esto es como arrojar agua con frecuencia a alguien que está tratando de encender una hoguera y luego esperar que tenga éxito en hacer una hoguera. es absurdo

Todos deben estar de acuerdo en realizar una sola reunión diaria en la que todos brinden su actualización, discutan problemas y soluciones, y luego vuelvan a trabajar sin interrupciones innecesarias. Esta reunión suele durar entre 15 y 20 minutos y algunos de los temas que todos deben considerar incluyen:

• Lo que hiciste el día anterior (por ejemplo, ayer hice A, B, C, etc.)
• Cualquier obstáculo con el que te hayas topado (p. ej., estoy atascado en una tarea D; me gustaría discutir posibles soluciones después de que todos los demás hayan dado sus actualizaciones)
• Lo que espera hacer hoy (por ejemplo, hoy espero terminar Dy comenzar E)

Cada miembro proporciona la misma información durante cada reunión, todos los días. Es un stand-up diario , después de todo. :)

Estuve de acuerdo con Adam en volver de vacaciones y comenzar a construir dos dispositivos de prueba e integrar el resto de las funciones.

Nunca he estado en un entorno de inicio, pero algo me dice que las cosas cambian rápidamente en dicho entorno. Por lo tanto, el hecho de que lo hayan hecho mientras no estabas no debería ser un problema. Por otro lado, tampoco debe usarse en su contra.

Varias deficiencias técnicas y de gestión que considero son la fuente de estos problemas.

No creo que haya mucho que puedas hacer, aparte de cambiar a los gerentes. Considere si se ha discutido algo de lo siguiente:

• cosas que cree que ha identificado como problemas;
• posibles formas de solucionar/resolver esos problemas;
• por qué cree que es probable que funcione una solución propuesta;

y si se hizo antes de que fracasaran los proyectos, o al menos inmediatamente después del fracaso más reciente, si es que lo hizo. Si nada ha cambiado después de varias fallas, no veo ninguna razón para pensar que algo cambie.

Esta es la razón por la que las metodologías ágiles incorporan una retrospectiva del equipo al final de cada sprint (¡es decir, no del proyecto!): para brindar la oportunidad de reflexionar sobre lo que funcionó y lo que no funcionó tan bien en el sprint y comprometerse a arreglarlo para el futuro. próximo.

No espera hasta que el proyecto haya fallado, y ciertamente no espera hasta que varios de ellos hayan fallado. Si hay una negativa, en cualquier nivel, a aprender de los errores del pasado, seguirán repitiéndolos y fallando. El primer paso para solucionar los problemas es reconocer su existencia.

Además, si nada mejora, los proyectos seguirán fracasando, acabarán con la empresa en bancarrota y te quedarás sin trabajo si decides quedarte allí. La única forma en que puede cambiar a sus gerentes aquí es consiguiendo un trabajo diferente.

notas al pie

[1] Una vez tuve un gerente Mque me asignó Lcomo líder del equipo. Para mi sorpresa, Mme dijo durante una "evaluación de desempeño" que las tareas en las que estaba trabajando "no eran importantes". Mi respuesta Mfue, básicamente, que ese Lera el líder del equipo, que era su responsabilidad como líder identificar/crear las historias en las que quería que trabajáramos durante nuestros sprints y que, según L, las tareas eran "muy importantes". ". ¿ MActuó de manera razonable y dijo: "Gracias por llamarme la atención; hablaré Lporque parece que tenemos ideas diferentes sobre lo que es importante"? No. Solo se molestó más y no arregló nada...