¿Cómo trato con un colega lento y no dedicado en el equipo? [cerrado]

He estado trabajando en un nuevo proyecto. El proyecto funciona así: el usuario final puede acceder a una aplicación web mediante un enlace y puede agregar múltiples sistemas en su red y administrar los detalles de esos sistemas en particular. Mi parte involucra el front end y el servidor web, que se realiza en python. Mi python realmente se comunica con otro proyecto que se realiza por completo en c & c ++. El proyecto c / c ++ es la aplicación principal que hace toda la funcionalidad. Mi python le envía la solicitud del usuario y muestra la respuesta al usuario.

Estoy muy familiarizado con mi trabajo y lo terminaré pronto. Como eso no es mucho trabajo en ello. Y soy una persona que ama trabajar. Paso la mayor parte del tiempo en la oficina y solo voy a casa cuando tengo sueño.

La aplicación c / c ++ es administrada por otro colega que tiene más de 5 años de experiencia y puede hacer las cosas mucho más rápido que yo, pero nunca lo hace. Puede ser que no le gusta hacerlo. Su aplicación se bloquea a menudo cuando mi python se comunica con ella o devuelve valores incorrectos. Está lleno de errores. Dado que mi aplicación depende de ello, me está costando construirla. En lugar de arreglar los errores, me pide que ralentice mi trabajo. Me pide que le diga al gerente que mi trabajo necesita mucho tiempo. Me pide que engañe al gerente e incluso me obliga a trabajar lentamente como él.

Durante la reunión del proyecto, cuando el gerente le pregunta acerca de los errores, dice que lo arregló todo y que funciona bien. Como él es mi colega, no pude decirle nada al gerente. Obviamente necesito tener una buena relación con mis colegas más que con mi gerente, ya que la mayoría de las veces estaremos con nuestros colegas, no con el gerente.

No puedo decirle al gerente nada sobre esto, ya que si el gerente le pregunta por qué, entonces puede pensar que me quejé de él al gerente. Y sigue mintiendo en la reunión. Y dado que corrige el error lentamente, incluso ralentiza mi trabajo. Ahora pensé en trabajar en la parte frontal de mi aplicación y terminarla para que, mientras tanto, pueda estabilizar su proyecto. Ahora me está pidiendo que le diga al gerente que mi parte frontal requiere mucho trabajo y es posible que necesite más y más tiempo, simplemente para que pueda arrastrar el proyecto hacia abajo. Y lo triste es que nuestro gerente real se ha ido a los EE. UU., Por lo que tenemos un gerente temporal y este tipo no sabe mucho sobre el proyecto, por lo que c, c ++ simplemente lo engaña.

¿Alguien puede sugerirme cómo trato con esto? Quería terminar el proyecto pronto. ¿Cómo puedo hacer que funcione incluso manteniendo una buena relación con él?

Respuestas a comentarios:

Si realmente está engañando deliberadamente a la empresa, debe informarlo a la gerencia.

Soy nuevo en esta empresa y el otro tipo ha estado allí durante muchos años. Y acabo de empezar a conocer a mis colegas. Si voy directamente y lo reclamo, no creo que pueda establecer una buena relación con mis otros colegas. Incluso él tiene el poder de engañarlos. No digo que sea un mal tipo, puede hacer el trabajo, pero no lo está haciendo.

¿Su empresa no tiene ningún tipo de sistema de seguimiento de errores?

Aquí el sistema de seguimiento de errores real no está allí. La empresa intenta finalizar el proyecto lo antes posible y se lo entrega al QA. Y luego corrige los errores reportados por QA.

Esta es la razón por la cual las compañías deberían dar a los empleados acciones / opciones o algún tipo de propiedad. De esa manera, literalmente puede decirle al tipo "Me estás costando un crecimiento monetario ... ¿no quieres ganar dinero también?".

La compañía tiene las opciones sobre acciones que me han dado una participación de 2500, en su mayoría él también habría obtenido más.

La antigüedad merece algún beneficio de una duda. Realmente necesitas hablar con él primero y tratar de entender el problema. Él puede estar fuera de su alcance, usted puede ayudarlo, podría haber fácilmente variables que desconoce. Puede ser difícil ahora, pero fácilmente podría empeorar la situación saltando el arma.

Incluso lo hago, primero su aplicación no estaba manejando múltiples solicitudes a la vez, estaba usando una cola para manejar las solicitudes que le envié. Incluso le sugerí algunas de mis ideas al respecto. Dijo que ya tenía estas ideas y las ejecutará. Sus explicaciones fueron: "Todo requiere cierto tiempo para hacerlo y este es un proyecto que puede necesitar dos años para completarse y se nos pide que lo terminemos en dos meses". Solía ​​tener dificultades para codificar durante las primeras semanas debido a este error. Pero ahora lo arregló. Pero está usando una sola cola para las solicitudes de un usuario y eso ahora está ralentizando la aplicación, ya que procesa una solicitud a la vez.

¿Qué está haciendo QA todo este tiempo? ¿Por qué no informan / confirman el estado de los proyectos?

El gerente es la persona que decide cuándo realizar el QA. A partir de ahora aún no se ha dado a QA. Dijo que deberíamos dárselo antes de fin de mes.

Estás en una mala situación, no quisiera estar en tus zapatos. Es poco probable que pueda resolverlo sin entrar en conflicto con su colega.

Esto es lo que haría:

• No te conviertas en su compañero en el crimen. Negarse a mentir sobre el estado de su proyecto o su proyecto.

• Implemente (en su tiempo libre si es necesario) informes de errores a su aplicación, de modo que todos los errores se envíen por correo electrónico a sus compañeros de trabajo y a su gerente. Si el error es causado por su aplicación, hazlo visible en el correo electrónico (pon [XYZ APP BUG] en el asunto del correo electrónico o algo así).

• Mantener una base de datos de errores (además de enviar errores por correo electrónico). Puede decir que su propósito principal es rastrear sus errores, cuando en realidad rastreará principalmente sus errores. Entre otras cosas, debe realizar un seguimiento de cuánto tiempo lleva corregir un error específico.

• Tenga toda la comunicación entre procesos con su aplicación cubierta con pruebas ("cuando le envié esto, debería devolverme ese estilo"). Puede configurar una tarea cron que ejecute estas pruebas todos los días y, si fallan, se envía un correo electrónico a todos.

Básicamente, trate de no perder el tiempo discutiendo con él sobre errores y enfóquese en su trabajo. Si su aplicación está rota y, por lo tanto, no puede trabajar en su aplicación, el administrador no hace nada con ella, bueno, eso es un problema de administración y está cubierto con una base de datos de errores, correos electrónicos e informes de prueba.

Sin embargo, ten cuidado y no lo subestimes. Un holgazán de mucho tiempo como él podría tener uno o dos trucos bajo la manga. Él puede volver a todo el equipo contra usted o algo así, pero eso depende de su situación específica y está fuera del alcance de esta pregunta.

Voy a presentar una visión un poco controvertida: dices que estás trabajando tantas horas como puedas para mantenerte despierto. Entonces, tal vez no sea particularmente injusto decir "me estás haciendo quedar mal y en realidad estoy trabajando tantas horas como estoy dispuesto a hacerlo". Tal vez ha estado allí y hecho eso, y tal vez se quemó. Te prometo que lo harás si sigues así.

Salga a tomar una copa con él una noche y vea si no puede construir una mejor relación personal en la que basar a su profesional. Tal vez si acepta poner un poco más y acepta poner un poco menos, ambos pueden trabajar juntos mucho mejor.

Si yo fuera usted, también sería muy cuidadoso con toda esta actitud de "mi trabajo, su trabajo". Entre ustedes dos, tienen un producto para salir y esto no puede ser bueno para ese producto, lo que a su vez no es bueno ni para la empresa ni para el cliente y pagan por que ambos trabajen .

Sin embargo, todavía estoy de acuerdo con los otros puntos de vista de que debe revisar la importancia de su relación con su gerente y debe tener cuidado de confiar en su colega. Solo digo que tal vez, solo tal vez, necesites mirar tus propias acciones y las de él.

Mantener registros. Documente cada error que reciba cuando se comunique con su lado, cuando le haya pedido que lo arregle y cuándo (si alguna vez) lo hizo. Esa es la única forma en que sé cómo lidiar con esta situación. Entonces, cuando su gerente se le pregunta por qué las cosas no están progresando, puede mostrar claramente sin ser visto como un llorón o un mal colega.

Me gustaría señalar otra posibilidad que no se ha planteado. Dices que quiere que ralentices tu trabajo. ¿Te refieres a que literalmente está diciendo "trabaja menos horas" o que está diciendo "escribe algunas pruebas, prueba más, escribe documentación" y otras cosas que crees que te retrasarán? He visto nuevas personas que escriben código durante 16 horas al día y luego se quejan de errores en el código al que están llamando cuando de hecho están pasando parámetros no válidos, no están verificando valores de retorno, etc. No puedo descartar que su compañero de trabajo esté pensando en estas cosas.

La próxima vez que estés en una reunión y él diga que todo su código está bien, di "oh, bien, lo que te dije hace una hora, donde explota cuando llamo a XYZ con una fecha que no es un día hábil, está arreglado ahora? " Una de las tres cosas sucederá:

• Él mentirá, y dirá que no hay tal problema, usted dirá "¡lo hay! ¡Lo discutimos! ¡Le envié un correo electrónico!" y todo llegará a la atención de un gerente
• Él le dirá que, de hecho, eso no es un error en su código, es un error en su código, porque se supone que solo debe pasar días hábiles, y pronto descubrirá lo que ha estado pensando pero no dijo
• Él dirá "no, ese del que me acabas de hablar me ocuparé hoy, pero todo lo demás está bien". Si dice eso, solo agradézcale por ahora.

Puede aprender que sus largos días de codificación rápida no están produciendo un buen código, y alguien (su gerente tal vez) podría traducir para que el otro desarrollador le explique cuál es el problema. O bien, puede aprender que está trabajando con una serpiente mentirosa que lo hará quedar mal para proteger su posición cómoda. Sacar a la luz las cosas no puede empeorarlo. O bien, puede obtener suficiente movimiento de él para poder soportarlo, sin quedar atrapado en la política.

Lo que tienes es un problema político. Primero, la opinión de su gerente es mucho, mucho más importante de lo que parece pensar. Este tipo te está culpando por los retrasos y lo estás dejando. Usted es quien será despedido si arrojan a alguien debajo del autobús. Hasta donde el gerente sabe, usted es quien es incapaz de hacer el trabajo de manera oportuna.

Protéjase de cualquier manera que pueda, a través del seguimiento de errores, correos electrónicos, etc., pero NO acepte fingir que esta es su demora, no la suya. Nunca le des al jefe un informe de estado falso, volverá a morderte. Dígale al jefe la verdad sobre los problemas que tiene (y muestre pruebas) con su código que no funciona.

Esta persona que le está pidiendo que se afloje para que no se vea mal es una serpiente (bueno, eso es un insulto a la comunidad de serpientes (referencia sutil de Firefly), lo siento por todas las serpientes reales). Hará cualquier cosa para arrojarte debajo del autobús en lugar de él. No confíes en él.

Primero y ante todo:

Como él es mi colega, no pude decirle nada al gerente.

Absolutamente puede y debe asegurarse de que su gerente sepa la verdad, incluso si su compañero de trabajo le está mintiendo a la cara. Si no quiere decir nada en una reunión con los 3 en la sala, eso es totalmente comprensible. Pero al menos debe dejar de lado a su administrador (el real, no solo la temperatura) y hacerles saber que su trabajo está casi terminado y está esperando las correcciones de errores del otro desarrollador antes de que toda la aplicación esté lista para el horario estelar. . No acuse a su compañero de trabajo de mentir, pero no se siente y deje que su jefe opere con información incompleta.

Informe sus estados honestamente. Si su trabajo está siendo retenido por errores en el lado de otro desarrollador, documente que ha encontrado errores en C / C ++ y los ha informado (por favor, dígame que está utilizando algún tipo de documentación que deja un rastro de papel).

Mientras tanto, continúe y termine su trabajo, y avísele a su jefe cuando haya terminado. Si su gerente quiere saber por qué el resto del proyecto aún no está en funcionamiento, puede referirlo al otro desarrollador y tal vez mencionar que probablemente sea muy complicado / grande / requiere muchas pruebas / otro desarrollador es muy ocupado / etc. Si conoce C / C ++, puede ofrecer ayuda en la lógica de la aplicación principal para que las cosas se muevan con eso también. Sí, estará haciendo el trabajo del otro tipo, pero deja en claro que usted es el empleado que trabaja duro y es productivo, y el otro tipo no lo es, sin mencionar que lo hace aún más valioso para su jefe. Incluso puede presionar un poco al otro desarrollador para que intensifique las cosas y las haga más rápido.

Hay una serie de problemas en el trabajo. Sé consciente de:

1. Estás haciendo suposiciones sobre las motivaciones de otras personas
2. Estás coloreando hechos con opiniones.
3. Los extraños (cualquier otra persona) no conocen la historia ni sus frustraciones con su colega.
4. Puede parecer infantil si parece que estás jugando un juego de "gotcha". Tu colega probablemente pueda jugar mejor, después de todo, todavía tiene un trabajo, ¿no?

Por lo tanto, al presentar el estado de su proyecto:

1. No menciones a la otra persona.
2. Al informar errores o problemas con el código, no el desarrollador. Diga "La llamada al método FooBar () está devolviendo 1 cuando debería devolver un 2". Entonces, cualquier problema no es un ataque personal, solo estás hablando de código, no de personas.
3. atenerse a los hechos de los que tiene pruebas.
4. Si su colega se pone a la defensiva o es hostil, haga preguntas. "No entiendo por qué crees que debería hacerlo _ "
5. Sea ajeno a los desaires sociales o insinuaciones. Finge que no obtienes el ataque personal.
6. Duerma mucho la noche anterior a cualquier reunión de estado, para que sea mentalmente ágil.
7. Documento, documento, documento.
8. No seas tímido al pedirle a este chico que te ayude con algún problema interesante, podría llevarte si siente que lo respetas. Se trata de construir una buena relación. (tenga en cuenta que esto no es una mierda, esto es otra cosa)
9. Prepárese para irse si es necesario, de modo que no esté necesitado o atrapado emocionalmente. Esto ayudará a mantener la cabeza en las reuniones.

"Soy una persona a la que le encanta trabajar. Paso la mayor parte del tiempo en la oficina y solo voy a casa cuando tengo sueño".

Esto no es saludable y no se puede esperar de los colegas, a menos que se le compense hasta el punto de poder tomarse años libres por el agotamiento inevitable. (Algo así como> 10% de propiedad de la empresa o más de $ 200ka año). Mantener la experiencia para llegar al punto donde puede desarrollarse muy rápidamente lleva tiempo. Parte de su tiempo debe dedicarse a desarrollar experiencia.

"El proyecto c / c ++ es la aplicación principal que hace toda la funcionalidad. Mi python le envía la solicitud del usuario y muestra la respuesta al usuario ... Puede que no le guste hacerlo".

Python es un lenguaje más ágil que C / C ++. Su aplicación parece contener toda la funcionalidad; su aplicación solo la interfaz de usuario. Lo más probable es que no tengan la misma dificultad. Puede que no esté produciendo código rápidamente; pero la codificación de calidad es mucho mejor que la codificación de cantidad. Es muy probable que tengas expectativas poco realistas de cuán rápido puede codificar en las horas que está dispuesto / espera que trabaje (generalmente ~ 40 horas semanales; y recuerda que si ha estado allí durante años, es probable que haya acumulado otras tareas como administrar otras o ayudar a mantener mayores) proyectos que ocupan una parte significativa de la semana laboral).

No mientas por él; pero de nuevo no lo critiques tampoco. Hable acerca de cómo su sistema es excelente; concedido necesita más trabajo hasta que esté terminado. Dele a su gerente una actualización de estado precisa sin nombrar nombres / asignar culpas. Escriba una versión simulada de su sistema que se ajuste al mismo estándar que su sistema debería cumplir. Asegúrese de que su sistema funcione perfectamente con su sistema simulado con un conjunto de pruebas automatizadas. Entonces su sistema puede estar terminado (por ejemplo, se sincroniza perfectamente con la maqueta), incluso si el sistema en vivo todavía tiene errores.

Luego puede escribir un conjunto de pruebas automáticas para que su sistema se llame externamente y cumpla con los estándares acordados. Por ejemplo, prueba que Foo (1,2,3) devuelve una respuesta de "Barra 4 5 6". Esto podría ayudarlo a identificar errores y acelerar su desarrollo (y no necesita meterse con su código). Una vez que se hagan esas cosas, podrá pasar a otro proyecto / tarea (como ayudarlo con las partes C / C ++).

Como otros han mencionado, comportarse profesionalmente es lo más importante para su carrera a largo plazo. Y honestamente, siempre y cuando te comportes profesionalmente, estarás en muy buena forma, sin importar cómo se comporten los que te rodean.

En esta situación, hay un par de consideraciones que debe tener en cuenta.

Primero, debe comprender que usted es responsable de que su programa trabaje según las especificaciones deseadas, dentro del plazo establecido. Si su programa interactúa con el programa de otra persona, usted también es responsable de asegurarse de que ese otro programa también funcione en el mismo plazo. Para decirlo de otra manera: si la otra persona no cumple con su fecha límite, entonces usted también ha incumplido su fecha límite, incluso si su parte del proyecto fue puntual. En términos de gestión, esto se llama poseer las entradas .

Ha notado correctamente que cuando su colega declara en una reunión que se corrigieron los errores de su programa, no puede declararlo inmediatamente como incorrecto ante el gerente (su gerente vería eso como "arrojar a su compañero de trabajo debajo del autobús"; un muy mal movimiento de carrera). Otros, por otro lado, han señalado que no es profesional no declarar el verdadero estado del proyecto al gerente. Ambas partes son completamente correctas.

Entonces, si es malo contradecir a tu colega frente al gerente, y también es malo no contradecirlo, ¿qué haces?

La respuesta en realidad es bastante simple: debe hablar con su colega mucho antes de la reunión con el gerente y hacerles saber que en la próxima reunión tendrá que decirle al gerente sobre los problemas que ha tenido con su programa, y ​​que está afectando su capacidad de entregar su parte del proyecto a tiempo, y si hay algo que pueda hacer para ayudarlos a abordar los problemas que ha tenido. Debe tener esta conversación al menos dos días completos antes de la reunión donde se lo dirá al gerente, y preferiblemente con una semana completa de anticipación.

En la mayoría de los casos, solo decirle a su colega que tendrá que enumerar su programa como un riesgo en una reunión en particular los motivará a abordar los problemas que está teniendo, y nunca tendrá que hablar con el gerente en absoluto . En otros, donde los problemas dependen más del horario, el colega a menudo estará de acuerdo con usted, y ustedes dos pueden ir juntos al gerente.

Nunca he tenido un colega que no me arregló las cosas rápidamente ni estuvo de acuerdo con mis preocupaciones, cuando se expresó de esta manera. Pero si sucediera, al advertirle a su colega con anticipación, aún estaría en una mejor posición al hablar con el gerente. Como hablaste con tu colega e intentaste encontrar una solución por tu cuenta, y les advertiste con anticipación que tendrías que plantear el problema en esta reunión, tu colega no se sorprenderá cuando lo hagan, y el gerente ganó No pienses que simplemente estás tratando de echar la culpa.

Recuerde que cuando expresa sus inquietudes, ya sea al colega o al gerente, sus inquietudes se refieren al programa de su colega que está devolviendo datos incorrectos (o cualquier otra cosa que esté haciendo); Estas son cosas medibles que pueden ser verificadas y reparadas. Sus preocupaciones no son acerca de que su colega sea lento o no esté dedicado Estas no son cosas medibles, que pueden o no ser ciertas, y que es poco probable que se solucionen al mencionarlas en una reunión frente al jefe.

¿Qué sistema de seguimiento de errores estás usando? Esperaba que al menos resaltara dónde los errores no se solucionan a su debido tiempo. Cuando su código esté esperando la entrada de la otra capa, los retrasos deben resaltarse en la documentación de seguimiento del proyecto. ¿Esto tampoco está sucediendo?

Me parece que aquí hay una gestión de proyectos inadecuada. Debe a) rastrear los errores que lo afectan yb) hacer un seguimiento de las discusiones por escrito.

Tu colega no debería pedirte que infles tu tiempo de desarrollo para cubrir su falta de voluntad. En algún momento, esto es algo que tendrá que abordar con su gerente. Tal como están las cosas, estás encubriendo a tu colega y eso seguramente será contraproducente.

No hay nada malo en defender a un colega, pero para que alguien espere que mientas a tu jefe a diario tiene que irse. No podría respetarlo como persona y no desearía tener a esta persona como un conocido casual. Quiere ser un enemigo, tráelo.

¿Cómo puede argumentar retrasos en la capa de aplicación debido a la interfaz? Es por eso que haces esto para que puedan estar separados. ¿Qué sigue, tiene aún más demoras porque alguien quiere construir un frente móvil?

Haz tu trabajo. Documente cualquier problema que tenga con una falla en su aplicación. Y luego VAYA A CASA! No me importa si tienes sueño o no. Encuentra amigos que valga la pena tener.

Acabo de leer "The Clean Coder" de RC Martin (tío Bob). El punto principal del libro es que los programadores en general no reciben mucho respeto porque no se comportan profesionalmente . Eso significa principalmente que no se comunican de manera efectiva con la administración sobre el estado del proyecto.

Mentir es ciertamente una muy, muy mala forma de comunicación. Tu colega está siendo extremadamente poco profesional y tú también. Ambos no están haciendo nada bueno para mejorar la percepción de los programadores.

Le aconsejaría que vaya de inmediato a la gerencia. Sin embargo, me he metido en problemas en el pasado por haber sido demasiado "honesto" (en alguna situación no relacionada), por lo que no estoy seguro de que deba seguir mi consejo. Además, como muchos han señalado, tal vez su percepción de la situación no sea tan precisa como cree.

Es difícil e irracional estimar el esfuerzo relativo y la complejidad de otro proyecto si no está familiarizado con el código base. Usted dice que su código es propenso a errores, pero podría estar en gran forma con todos los problemas restantes en un nivel muy alto de abstracción ... ¡El problema es que ese es el único código que necesita su front-end!

O tal vez es un mal empleado y lleva a la compañía a dar un paseo. No puedo decirlo, y es posible que tampoco tenga toda la información que necesita saber con confianza.

Sugeriría una táctica a mitad de camino. La próxima vez que se encuentre, traiga algunos detalles de un error importante en su código que lo esté afectando. Cuando dice que todo está bien, cortésmente diga que hay un problema pendiente que está bloqueando su progreso.

Políticamente, decirlo así te permite afirmar que no es del todo correcto, mientras le da una oportunidad para jugar tonto y no ponerse a la defensiva.

Su gerente debe preguntar en la próxima reunión si está arreglado. Si no, la presión recae sobre él para corregir un error. Si es una solución, diga gracias, está funcionando muy bien ahora, y encontró un nuevo bloqueador. Si quieres ser especialmente amable, digamos que te lo encontraste poco antes de la reunión.

No estás mintiendo, per se, ni estás tomando partido. Estás jugando a la política llamando la atención sobre los problemas y dejando que tu colega salve la cara si las cosas realmente no están yendo tan bien.

Es tentador hablar con su gerente, pero no olvide con cuál de ellos tiene que trabajar más.

La respuesta de Pat fue genial. Estoy de acuerdo al 100% No vaya a una reunión furtiva con el jefe. Tómelo con su colega entre 4 ojos o hágalo con los 3. Pero la sugerencia de Pat de enfocarse en los problemas del código y no en las personas es el camino correcto.

Por cierto, 40h / semana es suficiente amigo. ¡Necesitas mantener tu motivación alta!

Pida a alguien más que los ayude a ambos en las pruebas de integración La persona podrá decir dónde ocurre el problema. Como temptar señaló, me pregunto por qué ni siquiera hay un excelente para rastrear los problemas. Como no hay seguimiento, ¡es como cada vez que el otro tipo se escapa al decir que todo está bien a partir de ahora! no funciona de esa manera!

Es su módulo si necesita hacerlo, debe levantar la bandera roja sobre cuál es la causa del retraso en su lado. La experiencia en MERE Years no tiene nada que ver, es solo el conocimiento y eso es en lo que su gerente debería insistir. Como dije, incluso siento que hay una mala gestión del proyecto aquí.

1. Mostrar iniciativa al solicitar tareas adicionales y preguntar cómo puede agregar valor a la organización es la mejor manera de ganar confianza.

Es posible que su gerente no sea lo suficientemente técnico como para descubrir quién está desacelerando el proyecto, pero probablemente sea lo suficientemente inteligente como para reconocer que un desarrollador que está buscando activamente nuevas tareas está agilizando su tarea actual. Esto conducirá a una conversación en la que puede dejar en claro que está esperando la reparación de errores de otros en su tarea actual. Enmarque la discusión en términos de cómo puede agregar valor adicional a la organización utilizando eficientemente su tiempo libre, no cómo su colega está siendo demasiado lento con sus correcciones de errores.