tu no

Continúe con su propio trabajo y deje que su líder de equipo resuelva las cosas por sí mismo cuando regrese.

Debería ser bastante evidente que este tipo no ha hecho todo lo posible, así que simplemente deje que el proceso natural tenga lugar aquí.

Si hace algo, será etiquetado como la rata de la oficina, en el mejor de los casos.

En el peor de los casos, tendrá personas observando cada uno de sus movimientos, informando cada vez que llega cinco minutos tarde, sale temprano, almuerza mucho, toma un descanso no programado o necesita arreglar algo por razones personales.

Es responsabilidad del líder del equipo, no de usted, vigilar las acciones (o inacciones) del grupo.

Si su objetivo es realmente un equipo eficaz, delatar a un miembro del equipo no es la forma de hacerlo, ya que solo causará conflicto, no unidad.

TLDR

¿Cómo te acercas al líder del equipo? USTED NO

Concéntrese en su propio trabajo y deje el resto al líder del equipo. La otra persona se ahorcará o no. Mantenerse al margen de esta

Según su descripción de la situación, hay dos problemas distintos:

1. Su compañero de trabajo parece estar trabajando en tareas que no están relacionadas con el trabajo pendiente o la lista de defectos.

2. Su compañero de trabajo lo está ralentizando, es decir, está afectando su capacidad para cumplir con sus propios compromisos.

Con respecto al n. ° 1: como han dicho otras respuestas, esta no es su responsabilidad.

Tampoco asumiría necesariamente que el trabajo no está asignado. Es posible que alguien se haya acercado a "Joe" y le haya pedido que se haga cargo de un proyecto paralelo/de investigación. (En un entorno ágil, mencionó los sprints, cualquier trabajo debe documentarse en el backlog y/o en el tablero, pero ninguna persona u organización es perfecta).

"Joe" también puede ser un pariente o amigo de alguien en la alta dirección; ese tipo de cosas es en mi experiencia demasiado común. Otra razón más para dejar que el líder de su equipo se ocupe del problema.

Con respecto al #2: si está afectando su productividad, eso es algo que puede y debe tratar de abordar.

Le sugiero que comience uno a uno y establezca algunos límites: si está "ayudando" a "Joe" durante más de, digamos, 15 minutos a la vez, diga: "Oye, me encantaría trabajar contigo". un poco más sobre esto, pero estoy trabajando en X e Y y realmente necesitamos que estén listos para el final de este sprint".

Si eso da como resultado una escena, o si tiene razones para creer que lo hará, entonces tal vez sea hora de involucrar al líder del equipo. Pero, al hacerlo, concéntrese en el impacto en su productividad. Pida orientación para manejar la situación: desea hacer lo mejor para el equipo, pero necesita orientación sobre qué es eso. (Esta es una cuestión de priorizar el uso de su tiempo; no asuma que sabe lo que quieren el líder y la gerencia de su equipo... por ejemplo, es posible que se le pida que pase algún tiempo emparejado con Joe).

De hecho, he tenido este problema y, a veces, todavía tengo este problema en mi equipo actual con personas con las que he estado trabajando durante más de un año .

Personalmente, soy un gran admirador de la rendición de cuentas , y es por eso que lucho con el enfoque de decir nada . Antes de continuar, tenga en cuenta que la rendición de cuentas no siempre significa decirle a alguien que su trabajo es inútil o que no ha hecho nada significativo para el equipo. No tiene que ser degradante o un ataque personal (Algo que tuve que aprender con el tiempo). A veces puede ser un simple malentendido de las prioridades, expectativas poco claras de en qué trabajar, debilidad en áreas donde realmente se trabaja, o tal vez Joe tiene cosas personales en su vida.

Entonces, ¿cómo entra en juego la rendición de cuentas? Al final del día, todos estamos trabajando en algo para alcanzar una meta. En el software, por lo general es para resolver errores, crear funcionalidad en un sistema o fortalecer un producto existente. Estos son básicamente los requisitos de trabajo a un nivel muy bajo para un programador que trabaja en una base de código en una empresa. En mi opinión, si alguien no está haciendo sus tareas, no solo es una responsabilidad para usted y el equipo, es una pérdida de recursos de la empresa (tiempo + dinero).

Algo que afectará el alcance de lo que tiene sentido para usted en función de su pregunta involucrada: ¿Quién, en ausencia (o no) del líder del equipo, delega y prioriza el trabajo? Esta es la persona que debe rendir cuentas de la misma manera que Joe.

... no hizo nada útil y en realidad nos retrasó.

Esta es una declaración muy grande y lo más probable es que se perciba como un ataque personal. Lo que ayudará es reconstruir su crítica para que esté más orientada hacia

1. Comprender cómo Joe comenzó a trabajar en las tareas que consideraba importantes
2. Qué tareas siente el equipo que eran más importantes y valiosas en las que debería haber estado trabajando
3. Le preocupa que el trabajo que estaba haciendo no contribuyera a la meta del Sprint

Debe demostrar que sus preocupaciones son válidas y que se refieren al trabajo [que no] se está realizando y que en realidad no están relacionadas con la persona. (Si realmente no te gusta Joe, busca otro equipo o, en última instancia, otro trabajo. No vale la pena la negatividad que trae estar cerca de alguien que no te gusta)

Hacía tareas de la nada que no eran requisitos (desconocido para nosotros en ese momento), nos pedía ayuda después de pasar demasiado tiempo en ellas y luego, finalmente, simplemente no las completaba.

Esto se siente como "mal mantenimiento" ya que había trabajo en marcha que no estaba siendo rastreado, nadie preguntaba por qué se estaba haciendo este trabajo, y parece que las personas estaban enfocadas en otras cosas y perdieron de vista, nuevamente, el objetivo del sprint. Cuando Joe pidió ayuda, eso le dio una ventana de oportunidad muy pequeña para profundizar un poco más y determinar por qué estaba trabajando en estas tareas y qué tenían que ver con su plato de trabajo. En el Sprint, el equipo generalmente debe tener una buena idea de lo que queda por hacer y los elementos de mayor prioridad en la cartera de pedidos (que supongo que todos tienen visibilidad). El trabajo en progreso que no se completa no siempre es algo malo, dependiendo del trabajo. Por ejemplo, si Joe estuviera investigando una nueva tecnología que ayudaría a acelerar las conexiones de la base de datos, por ejemplo, entonces diría que eso es potencialmente valioso, aunque la prioridad de otro trabajo podría ser lo primero. La comunicación abierta resuelve problemas como este.

En última instancia, un líder de equipo tiene mucho más en su plato (generalmente) que los desarrolladores que trabajan para ellos. El líder del equipo no pasará por todas las revisiones y comprobaciones de código. Creo que este es el caso porque existe un entendimiento y respeto mutuos de que sus compañeros harán su trabajo según lo prescrito y si surge algún problema (no pudimos hacer X debido a una dependencia de Y), se sacará a la luz durante un cita. No le hace ningún bien a un líder de equipo microgestionar el trabajo de 2 semanas revisando cada registro. Ahí es donde debe concentrar su energía si va a hablar sobre esto y abstenerse de atacar personalmente a Joe; hará más daño que bien.

Nuevamente, las cosas en las que debe concentrarse aquí son: Asegurarse de que su líder de equipo sepa que esta es una preocupación genuina para usted y que no se está quejando simplemente. ¿En qué deberían estar trabajando todos? ¿Quién delega ese trabajo cuando el líder del equipo es MIA? Tenga una comunicación abierta sobre el trabajo que se está realizando y cómo contribuye a la meta del Sprint/Equipo/Producto. Si no siente que algo en lo que se está trabajando sea valioso porque hay elementos de mayor prioridad, no hay nada de malo en eso, pero debe construir su caso sobre hechos.

Yo agregaría que los hechos deben hablar por sí mismos.

No creo que debas "delatar" a "Joe", pero dado que debería haber algún tipo de "de pie" en el que todos informen sobre el estado pasado y presente.

Cuando informa que trabajó en la Tarea 1, 2, 3 y solucionó el error X, Y, Z, todo con respecto a los boletos 8, 9, 10 ... y cerró 2 de los tres boletos. ¿El tercer billete? Está en manos de Joe esperando su respuesta.

Luego ves como Joe dice que trabajó en Esto, Aquello y El Otro y... bueno... esas cosas no están asociadas con los boletos excepto de pasada... y no se cerraron boletos en respuesta al trabajo realizado... .

La comparación debería hablar por sí sola.

Si enfatiza lo que hizo... el silencio con respecto a lo que hizo Joe debe escucharse fácilmente si su líder de equipo está prestando atención.

Creo que lo que debes hacer es presentar un informe de actividad con todas las tareas que realizaste cada día - puedes explicar esto con una simple razón, eres nuevo allí.

Puedes aclarar si el líder del equipo quiere que gestiones estrictamente las actividades del sprint o te anima a resolver otras tareas como lo hizo Joe.

Esto debería ser suficiente para advertirle acerca de Joe y asegurarse de que conozca sus tareas realizadas sin decir algo específico.

Si bien me gustan las respuestas "no"; Creo que hay una solución potencial aquí para el futuro. Si bien generalmente estoy de acuerdo en que es trabajo de su líder identificar quién hizo qué (en parte para que puedan consultar a la persona adecuada sobre errores y similares), esto se puede hacer de varias maneras para los pasos de revisión.

Si actualmente no tiene un paso de revisión de código, una "revisión semanal" o un "informe de progreso" que envía a su cliente potencial, stand-ups donde informa lo que ha hecho o una variedad de otros medidores de seguimiento; estos pueden ser útiles para que las personas desmotivadas se den cuenta o se motiven.

Del mismo modo, parece que tampoco tiene un sistema de seguimiento de tareas (como Jira). Si lo tiene, su falta de progreso ya se está rastreando implícitamente porque en algún momento su líder debería notar que los boletos bajo su nombre no parecen moverse, o que los boletos se generan rápidamente y luego se invalidan. En nuestro servidor de comunicaciones (hipchat) tenemos un canal Jira para nuestro equipo que suelta toda la información que pasa por él, como nuevos tickets, cambio de estado, etc.

Además, como alguien que hace cosas mofetas, es posible que no veas el valor de su trabajo, pero es muy probable que lo hayan contratado para hacer cosas raras como esta. Algunas personas son contratadas, no para trabajar 40 horas o ser excelentes en la parte básica de su trabajo, sino por sus contribuciones auxiliares (o la capacidad percibida para hacerlas).

En mi caso, una herramienta que construí (y probablemente no tendría autorización para construir) cambió por completo nuestro enfoque de un trabajo principal en nuestro equipo y ayudó a descubrir problemas tan rampantes en otros equipos que los tres equipos juntos han estado refactorizando todo nuestro Acercarse. Además, tenemos productos más precisos que salen de nuestros equipos, mejores requisitos, un mejor diagnóstico de problemas y encontramos los problemas mucho antes. Nuestras tareas han pasado de semanas a horas.

Tal contribución puede ser una vez en una luna azul; pero puede ser la razón exacta por la que contrataron a este tipo; esperando que tengan un cerebro que se acerque al espacio de búsqueda del problema de tal manera que llegue a una gran solución.

Por último, también he trabajado con el tipo del que hablas. Básicamente, no hizo nada, no usó el sistema de flujo de trabajo de manera adecuada, rechazó ciertas categorías de tareas (debido a que no estaba familiarizada con esa sección del código; ¡la tragedia autocumplida de todo esto!) y otros problemas.

Dicho esto, ella no fue enlatada directamente; solo (tal vez) dejar ir como resultado de alejarse. Mi mejor conjetura es que es difícil despedir a alguien en mi trabajo o que el líder no tiene estómago para eso.

Creo que cada persona en un equipo dado tiene la responsabilidad de hablar si ve algo que va en detrimento del progreso del equipo. Ignorarlo por completo te hace un poco cómplice de las fallas.

Podría decir que una persona no hizo nada mientras el líder de su equipo estaba fuera, lo que provocó que el equipo no cumpliera el objetivo del sprint, o también podría decir que su equipo en su conjunto no trabajó lo suficientemente bien como para cumplir el objetivo. objetivo de carrera. Dos perspectivas diferentes de lo mismo.

Ya que estás corriendo sprints y stand-ups, asumiré que también estás haciendo retrospectivas de sprints. En la retrospectiva del sprint, puede mencionar el hecho de que no cree que el equipo lo haya hecho bien al priorizar las tareas y que los stand-ups no fueron efectivos (lo cual es cierto o todo el equipo habría sabido que las personas estaban trabajando en el mal). cosas).

Podría elaborar diciendo que las personas a veces no estaban trabajando en las tareas más importantes o más relevantes. No es necesario dar nombres.

También podría valer la pena discutir por qué sus stand-ups no alertaron a nadie sobre el hecho de que las personas estaban trabajando en cosas que no deberían haber hecho. Quizás necesites un cambio de formato stand-up.

Entonces, espero que el líder de su equipo inicie una discusión sobre esto en la que, como equipo, puedan discutir las posibles causas de esto y las posibles acciones para esto.
Por ejemplo, una posible causa puede ser que la persona comenzó a trabajar en un problema y luego descubrió otros problemas semirelacionados y comenzó a trabajar en ellos primero como parte del problema original, en lugar de detenerse y crear un problema nuevo, discutiendo el cambio potencial. en alcance y/o esfuerzo y luego continuar.

Si te pone realmente nervioso que la otra persona lo perciba como un ataque, puedes expresarlo de forma que te incluyas a ti mismo, por ejemplo, agregando que es algo que sabes que haces tú mismo de vez en cuando o que es algo que todos lucha con a veces.

El propósito no es señalar con el dedo y jugar el juego de la culpa, sino usar comentarios constructivos para identificar debilidades o problemas dentro del equipo y trabajar juntos para resolverlos.
Su objetivo principal es lograr que el equipo trabaje en conjunto de la mejor manera posible.

A menudo sucederá que la persona es consciente de este problema y quiere solucionarlo, pero no conoce la causa raíz o no puede encontrar una solución. O podrían estar felizmente inconscientes del problema en absoluto.
En ambos casos, tener la discusión en equipo les ayudará a resolverlo y todos estarán más felices.

Obviamente, habrá casos en los que tendrás un miembro del equipo que simplemente no será un jugador de equipo y no seguirá las reglas del equipo, incluso después de intentar resolverlo de manera amistosa. En ese caso, podría hablar con el líder de su equipo y decirle que le preocupa que el problema de la persona que trabaja en lo incorrecto no se resuelva, aunque se haya discutido en retrospectivas y stand-ups.

Luego, pase lo que pase después de eso, está por encima de su nivel de pago, a menos que el líder del equipo le pida más ayuda en el asunto y usted acepte ayudar.

Estoy de acuerdo con la mayoría de las respuestas publicadas hasta ahora, no es su trabajo mejorar el rendimiento del equipo.

Sin embargo, si desea que el líder de su equipo conozca sus circunstancias, puede usar la reunión diaria posterior para informarle lo que sucedió en su ausencia. Ahora definitivamente deberías evitar hablar mal de Joe, en su lugar solo habla de todo lo que TÚ has hecho en las 2 semanas, también incluye que estabas ayudando a Joe (no en un sentido negativo, solo para explicar cómo pasaste tu tiempo). Nadie se inmutará, ya que solo desea informar a su líder de equipo. También es posible que desee convencer a su otro compañero de trabajo para que haga lo mismo. Esto deja a Joe con 2 opciones en el diario:

1. Mentir abiertamente sobre lo que ha hecho: el líder de tu equipo debería notarlo ya sea en el diario o cuando revise el historial de confirmaciones.

2. Diga lo que estaba haciendo en ese tiempo: si su líder de equipo está un poco a la altura de su Tarea, se dará cuenta de que estas Tareas no estaban en el Alcance para ese Sprint.

En ambos casos, su líder de equipo debería notar que algo no estaba saliendo según lo planeado. En este Punto es su Trabajo determinar cómo continuar. También te guardas las apariencias si hubo alguna instrucción de tu Teamlead a Joe para que se encargue de esas tareas, de las que quizás no estés al tanto.

Concéntrese en los resultados, evite la negatividad

Cuando el líder de su equipo regrese, lo más probable es que le pregunten cómo le fue.

En lugar de asumir/implicar que algo malo ha sucedido, apégate a los hechos. En su caso, algo como esto parece apropiado:

En general, mi trabajo en tareas de sprint fue bien, pero me pidieron que ayudara un poco más de lo habitual en tareas fuera de sprint.

Si al líder de su equipo no le importa, entonces no debería importarle demasiado. Probablemente al menos tenga curiosidad, entonces puedes simplemente indicar que ayudaste a Joe con algunas cosas (¡sin negatividad en tu expresión!). Luego, depende de su líder de equipo investigar qué es eso y evaluar si está contento con que se le dé prioridad.

Como puede ver, trato de ver las cosas de manera positiva tanto como sea posible. Sin embargo, si Joe obviamente estaba haciendo algo inútil para la empresa (como configurar una solución de transmisión para poder ver a su gato), entonces esta respuesta no es adecuada para la situación.

Debe hacer lo que es ético, independientemente de su impacto en su carrera y posición en el equipo.

Esto es muy similar a la situación en la que me encuentro actualmente. Esencialmente, alguien no está haciendo su trabajo y le cuesta al equipo, y también le cuesta a sus compañeros de trabajo individuales que viajan en el mismo barco, por lo que deben trabajar más duro para compensar o absorber la pérdida. Es absolutamente algo sobre lo que no es ético permanecer en silencio .

La forma en que intensifiqué la situación (después de más de un año de intentos de remediación más amigables en la parte inferior de la jerarquía corporativa, que no funcionó) fue que armé una lista de las malas acciones de esa persona y expliqué cómo cada una afecta a la totalidad. equipo mal -- en nuestro caso también el cliente que nos paga. Expliqué cómo tenía que hacer más trabajo para compensar a esa persona, pero esa no es una solución realista y sostenible.

¿Por qué "delatar" no es el despreciable gesto de comer bebés que los "expertos en el lugar de trabajo" aquí están haciendo que sea? Porque podrías estar trabajando en un hospital o en el departamento de bomberos y la incompetencia de tus compañeros de trabajo puede costarles la vida a algunas personas. Así que no se equivoque: "delatar" es lo correcto, independientemente del impacto que tenga en su carrera y en la posición del equipo (¡y estoy poniendo un signo de exclamación aquí)! E incluso peor que delatar la demonización es la idea (muy extendida en este foro) de que no deberías hacerlo para preservar tu posición social entre tus compañeros de trabajo porque es bueno para tu carrera en general (¿a quién le importa la moralidad?)

En mi caso, la alta gerencia me escuchó, que también fue criticada por no prestar atención y no ser práctica para ver el problema antes, y la preponderancia de la evidencia fue tan abrumadora que tuvieron que estar de acuerdo conmigo. Sugerí que la persona en cuestión era tan irremediablemente incompetente que merecía ser despedida (reemplazada por alguien que pueda hacer el trabajo de manera competente y confiable) y que cualquier otro beneficio de la duda era similar a meter la mano en el fuego por el enésima vez y que fue fácil para la gerencia hacerlo porque el cliente básicamente no tenía ni idea y no puede monitorear el desempeño de los contribuyentes individuales, por lo tanto, el tipo se mezcla con el resto de nosotros. Creo que puedes armar un caso similar peroes importante que lo documente en una presentación estructurada y desapasionada que se centre en el impacto en el equipo y no suene como una disputa personal. También es fundamental que usted mismo sea creíble para emitir tales advertencias al tener la reputación de ser competente.

Ahora, debe tener en cuenta que, como dije, es probable que esto afecte la posición de su equipo personal y su carrera dentro de esa empresa. Pero la vida nos presenta desafíos de esta naturaleza donde lo éticamente correcto es asumir el costo. Como usted parece un individuo competente y confiado ( have been recognized already for getting stuff done and working without needing micro-managing), estoy seguro de que puede encontrar alternativas en caso de que este curso de acción moralmente admirable comience a tener consecuencias políticas intolerables.