He estado trabajando para mi empresa actual durante 7 meses y estoy completando mis dos años en la industria en total. Mi empresa es una empresa grande, con plazos relativamente relajados y horarios flexibles.
Somos un equipo recién establecido, la mayoría de nosotros somos jóvenes con experiencia que va desde recién graduados hasta dos años de experiencia como máximo. El único compañero de trabajo senior, que también es el scrum master, no se molestará en guiar a nadie y solo se ocupará de sus propios asuntos. Nuestro gerente también es una persona extremadamente práctica.
A menudo, cuando se les da trabajo para producir, los nuevos compañeros de trabajo graduados se retiran a sus pequeños "equipos de amigos", acumulan tareas y trabajan a toda prisa sin planificar, diseñar, consultar o discutir nada con los demás. Como resultado, esto domina nuestros esfuerzos de desarrollo debido a su rápido ritmo.
En este punto, produjeron un código con muchos errores sin una estructura reconocible. El producto no se descama incluso con cargas pequeñas. Ahora tenemos una configuración de desarrollo local muy alucinante, dos configuraciones de prueba diferentes que no funcionan según lo previsto, y todavía nos dicen "lo arreglaremos más tarde".
En un momento, traté de refactorizar una parte del código porque tardaba demasiado en compilarse y el administrador se quejaba. A pesar de que mis compañeros de trabajo sabían lo que estaba haciendo, nadie se quejó ni se opuso a mí al principio, pero llegué a escuchar que el Scrum Master, que es el compañero de trabajo más antiguo de nuestro equipo, se burlaba de mis intentos detrás de mí para arreglar las cosas como "desperdicios". del tiempo", que "a nadie le importaba".
Así que decidí renunciar por completo a la refactorización, no fue bienvenido. En ese momento logré tomar dos nuevas características para desarrollarlas y completarlas.
Durante nuestras reuniones con el gerente, expresé mis preocupaciones con respecto a todo esto abiertamente desde el primer día. El gerente a menudo está de acuerdo conmigo, pero nunca ofrece una solución práctica. Él cree que con el tiempo todo estará bien.
Me preguntó por qué no estaba proporcionando las "soluciones" o "mejoras" a los problemas que detecto. También me preguntó sobre la refactorización que tenía que hacer, ya que no estaba aprobando el estado en el que se encontraba el código, y le dije que no podía seguir adelante porque estaba solo haciendo eso, que a nadie parece importarle. sobre la calidad además de mí. También mencioné la reacción que recibí del scrum master, que otro colega buscó arreglos y nunca me informó al respecto, así que me concentré en otras tareas.
Entonces, en este punto, siento que el gerente piensa que es mi responsabilidad arreglar las cosas, ya que soy yo quien señala ese problema. Sin embargo, encuentro este enfoque injusto. Debo decir que no creo que sea responsable de los errores de los demás, ya que no están dispuestos a aprender de mi "refactorización" y piensan que es una "pérdida de tiempo".
Como se dará cuenta, también soy bastante nuevo en la fuerza laboral y tengo toneladas de habilidades blandas y duras para aprender. Así que aquí está mi principal dilema:
¿Qué pasaría si evito el trabajo relacionado con este producto y me concentro únicamente en otras tareas a partir de ahora? ¿Soy realmente responsable de este tipo de trabajo que producen los compañeros de trabajo excluyéndome?
Editar: Debería haber dejado en claro que estamos haciendo ágil, scrum y kanban. Como resultado, no hay asignación de tareas, nos ofrecemos como voluntarios para tareas abiertas. Además, todos tenemos el mismo gerente del que mencioné en la publicación y tenemos una jerarquía horizontal en nuestro equipo, por lo que no hay "jefe", "líder de equipo" ni nada. Se espera que actuemos colectivamente.
Edición 2: acortó la publicación. Edición 3: acortó aún más la publicación.
tl;dr: Los compañeros de trabajo están codificando el producto sin dejar que otros contribuyan, el gerente parece esperar que proporcione la solución, aunque a nadie en el equipo parece importarle además de mí. ¿Soy realmente responsable de arreglar el trabajo en el que apenas he contribuido ya que estamos trabajando en equipo?
No arruines tu salud mental con esto. Sí, técnicamente eres responsable de esto ya que todos en tu equipo lo son. Y si este fuera un tema limitado a un número reducido de colegas, mi respuesta sería diferente. Pero esto parece ser un problema de todo el equipo, y usted solo no lo solucionará.
¿Hay algún otro trabajo que deba hacerse? Concéntrate en eso. No tienes que estresarte por un producto en el que no trabajaste, y cuando trataste de ayudar a alguien, tu trabajo fue desechado e incluso recibiste reacciones negativas de tus compañeros de trabajo. Dado que parece que puede trabajar en lo que quiera, eligiendo entre una serie de tareas, hágalo. Si su gerente le pregunta sobre esto, puede ser honesto al respecto, ya que parece ser razonable:
He decidido centrar mi trabajo en tareas fuera del proyecto X. Aunque quería ayudar a mejorar el código, mis contribuciones han sido rechazadas y la gente se ha quejado de mi participación. Esto se sintió como una gran pérdida de tiempo y no quiero seguir perdiendo mi tiempo cuando podría ser más productivo y producir un trabajo valioso para la empresa como en los proyectos Y y Z.
Trabajas en un equipo al que no le importa la calidad, cada miembro solo piensa en sí mismo. No te conviertas en eso, pero actúa en consecuencia. Cuidar demasiado en ese tipo de ambiente te volverá loco. También te aconsejo que comiences a buscar trabajo y cuando te entrevisten en empresas, no dudes en hacerles preguntas para asegurarte de que no terminarás en un lugar como este nuevamente.
Si las tareas no están de acuerdo con tu contrato de trabajo, tienes que hacer lo que tu "autorizador" (software de traducción -.-, tu jefe, gerente, scrum master -> la persona que te da tus tareas) te asignará.
Pero puede dejar en claro que necesita apoyo para hacer su trabajo, como compañeros de trabajo cooperativos, documentación del código, estándares de codificación, acuerdos sobre la arquitectura del software, etc.
¡Nadie puede esperar que construyas una casa sin un juego de herramientas apropiado! Deja claro a tu jefe (y a ti mismo) lo que realmente necesitas, lo que te gustaría tener y cómo conseguirlo.
Pero si este lugar de trabajo no vale la pena este esfuerzo (y esta es tu opinión, la única que cuenta), entonces puedes buscar uno nuevo que encaje más con tu lista de "en qué quiero trabajar" :)
EDITAR después del comentario:
Si usted, como equipo, es responsable del cumplimiento de las metas, entonces cada miembro del equipo es responsable, usted también. Siempre hay tareas que nadie quiere asumir, pero uno tiene que hacerlo. Tal vez sea posible hacer un "trato" con tus compañeros de trabajo: tomas esta tarea que no te gusta (tu compañero de trabajo actúa como si tampoco la amara) y acepta apoyarte con lo que quieres (ver "deja en claro ...").
En mi opinión todo trabajo en equipo se basa implícitamente en este tipo de tratos, pero a veces hay que pronunciarlos.
Y para entenderlo en el contexto de su pregunta: No, usted no es responsable del trabajo de sus compañeros de trabajo, pero es responsable (con ellos) de su producción.
Dado que este es un equipo Scrum Agile, escriba un ticket en el backlog para cualquier cosa que vea que necesita ser corregida. El 'equipo', como ha indicado, recogerá esas historias en la planificación o las mantendrá en la lista de espera. Eso debería satisfacer a su gerente, indicar que los puso en la cartera de pedidos y que necesita hablar con el maestro de scrum si no se incorporan durante la planificación.
Luego deben traerse y la gente debe tomarlos EN ORDEN DE PRIORIDAD. Esa es otra cosa que podría plantear en la planificación de que las personas están eligiendo y no trabajando las cosas en orden de prioridad.
También debería estar haciendo reuniones de compromiso durante la planificación. En mi organización lanzamos un puño de cinco (clasificación del 1 al 5) sobre la confianza que teníamos en el plan. Esta es su oportunidad de sacar un 1 o un 2 e indicar que siente que las correcciones de errores están relegadas. La regla del primero de cinco es que todo se detiene si alguien saca un 1 o un 2 y el equipo tiene que revisar el plan hasta que obtenga al menos los 3.
Por último, debe tener un propietario del producto que acepte sus historias. Si no, quién está aceptando este trabajo como 'hecho'. Es posible que sea necesario abordar una 'definición de hecho'. Si está haciendo Agile/scrum, ¿tiene retrospectivas de final de sprint con la oportunidad de plantear inquietudes y cambiar patrones? Si no, tal vez esta es la conversación que necesita tener con su gerencia de que en realidad no están haciendo Agile/Scrum sino Ad-Hoc.
Usted no es el líder , por lo que no es responsable de las fallas del equipo solo por la parte que jugó en él (es decir, su código e impacto en el equipo), no necesita preocuparse por eso .
¡Copiar el código interno fue algo inteligente por cierto!
¿Por qué reinventar la rueda si la empresa ya posee un código adecuado?
Tu Scrum Master tenía razón en que perdiste el tiempo.
Sin embargo, si el código copiado causara problemas o errores en el producto final, debería intentar mejorarlo y darlo como razonamiento.
Su gerente no quiere que administre o dirija, pero puede esperar que pueda solucionar problemas que otros no pueden o no quieren.
Si puede, eso seguramente aumentaría su respeto y su posición con el jefe; de lo contrario, su crítica podría interpretarse como un lloriqueo.
Dependiendo de la cantidad de trabajo en la empresa, puede que no sea posible evitar ese proyecto.
rath
gordito
gordito
bizcochos
gordito
EJoshuaS - Apoya a Ucrania
bizcochos
Walfrat
EJoshuaS - Apoya a Ucrania
bizcochos