¿Cómo trabajar con personas mayores que no están dispuestas a ayudar?

Soy un desarrollador junior en mi equipo. Me uní a este equipo el año pasado y es mi primer trabajo. Nuestro horario de trabajo es de 10 a 7.

Cuando comparto algo de PR(1) con ellos. Se toman un buen tiempo para echarles un vistazo. La mayoría de las veces, en el último día del sprint(2), a la hora (5-6 p. m.) dicen: "esto debería funcionar así, esto está mal", etc. No tengo ningún problema en que me lo digan. donde mi código es incorrecto, pero tengo un problema con el tiempo.

El último día del sprint, durante las últimas horas de trabajo del día, que te digan "esto está mal, eso está mal, corrige esto" es aterrador. Yo, entonces, muchas veces quise preguntarles: "¿Qué estaban haciendo antes, durmiendo?"

Y si hay una historia (3), de la cual no tengo ni idea de cómo debería funcionar, si le hago más de 4-5 preguntas... me dice "Tú déjalo. Yo haré esto" en lugar de explicándome cualquier cosa. Esto es tan grosero e irritante.

Debido a que son mis mayores, me aterroriza traer este tema durante el retro o frente a los gerentes. ¿Cómo debo lidiar con esto?

1) PR = "Solicitud de extracción". Donde un desarrollador pide a sus compañeros o personas mayores que revisen su trabajo.

2) Sprint = El trabajo se organiza para encajar en un período de tiempo corto conocido, llamado sprint , generalmente de 1 o 2 semanas de duración. Lo ideal es que el equipo solo se comprometa con la mayor cantidad de trabajo posible dentro de ese sprint.

3) Los elementos de trabajo se presentan como "historias" de usuario que normalmente contendrán solo una pequeña cantidad de funcionalidad. Por ejemplo, "Como usuario comercial, dado que seleccioné un rango de fechas, el informe solo debe incluir facturas para ese período".

¿Qué crees que harían por algo así? ¿Despedirte? ¿Reprenderte? Qué daño real podría resultar de decirle a sus superiores que su puntualidad le está causando problemas. Tal vez hay razones que no conoces. Podrían decirte esas cosas. Más preocupante para mí es que no lo llevarás a un estilo retro. Definitivamente debe informar a su gerente de eso. Se supone que lo retro es un espacio seguro.
Ya que estás hablando de sprints, supongo que estás haciendo Scrum. ¿Es una revisión de código parte de su definición de hecho? Si es así, ¿por qué se hace al final del sprint? ¿El ticket permanece "en curso" hasta entonces?
Podría considerar preguntarles si podrían echar un vistazo a sus solicitudes de extracción, eso es lo que hago cuando es importante.
¿Existe una definición acordada de hecho? ¿Cada una de las historias de usuario tiene criterios de aceptación claros y comprobables?
Tienes razón en no abordar el comportamiento de otros en una retrospectiva. Podría terminar poniéndose a la defensiva y desencadenando una "tormenta de culpa" que lo coloca en una posición mucho más vulnerable. Es mucho mejor acercarse a estas personas individualmente (no en una reunión formal) en un contexto de baja presión y tratar de evaluar lo que necesitan y decirles lo que necesita.
Cuando lo mencione en retro (que creo que es el lugar correcto para discutir esto), asegúrese de hacerlo sin culpar a nadie. Obtener comentarios de relaciones públicas cuando es demasiado tarde para hacer algo al respecto en el Sprint actual suena como algo que también podría ser un problema para otros.

Respuestas (2)

Debido a que son mis mayores, me aterroriza traer este tema durante retro o frente a los gerentes. ¿Cómo debo lidiar con esto?

No deberías estar aterrorizado. De hecho, la Retrospectiva es exactamente el lugar para sacar a relucir estas cosas de sprints anteriores. Sin embargo, también debes mencionarlo profesionalmente. Una frase que me viene a la mente:

En el último sprint, recibí comentarios sobre mi progreso y código solo hasta el último día del sprint y solo unas pocas horas antes del final del sprint. Esto me dio poco o nada de tiempo para completar los cambios solicitados.

Mantenlo simple y apégate a los hechos. Además, no es necesario señalar con el dedo ni mencionar a compañeros de trabajo específicos a menos que se le solicite. Su gerente o maestro de scrum ahora debe estar al tanto de la situación y poder manejarla.

Ahora, con respecto a los compañeros de trabajo malhumorados que carecen de paciencia y habilidades de enseñanza, hay pocas cosas que pueda hacer para cambiarlos . Sin embargo, puedes decidir si te ofende o no su respuesta contundente (te sugiero que no lo hagas).

Alternativamente, ya debería saber qué compañero de trabajo es más paciente o más amable con usted. Esta es también una gran oportunidad para mejorar sus habilidades autosuficientes y de búsqueda en Google: intente buscar en Google y piense en posibles soluciones antes de preguntar a sus compañeros de trabajo.

Tal vez usted no esté haciendo esto y por eso pueden ser reacios a ayudar o responder a todas sus preguntas. Si les demuestras que te esfuerzas antes de preguntarles (por ejemplo, exponer las posibles soluciones o los aspectos que investigaste), seguramente obtendrás mejores comentarios (je, incluso en toda la red SE animamos a los usuarios a esforzarse en sus preguntas, y los que no suelen tener no tan buena acogida).

Finalmente, diría que como eres un Junior todavía tienes cosas que aprender, y cada día serás más y más autosuficiente (o al menos deberías hacerlo si practicas tus habilidades), así que está bien que preguntes si pones un poco de esfuerzo antes de hacerlo.

Aclarar sus dudas/revisar su código al final de la jornada laboral puede ser solo una señal de que están abrumados y eso pasa mucho. Por otro lado, eso no puede impedir que hagas el trabajo, por lo que la única salida es tener una conversación sincera con ellos. Si eso falla, ahí es donde entra la administración.

¿Cómo trabajar con personas mayores que no están dispuestas a ayudar?
RespuestasAquíPolítica de privacidad1y, 0v