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

85

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.

muntoo
fuente
66
¿Cómo sabes que el chico de C ++ es más rápido que tú? Podría ser naturalmente lento.
Trabajo
3
Comentaristas: los comentarios son para obtener aclaraciones sobre la pregunta y para vincular a recursos relacionados. Si está de acuerdo con una de las respuestas a continuación, vote hacia arriba. Si tiene una mejor respuesta, déjela como respuesta: no la deje como comentario. Si desea hablar sobre el tema de esta pregunta con otras personas, utilice el chat .
1
@ Job hay una suposición de que la antigüedad significa un mejor codificador, lo que no siempre es el caso.
Rudolf Olah

Respuestas:

126

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.

Lukas Stejskal
fuente
45
+1 para enfatizar que el interlocutor nunca debe mentir sobre el estado de su proyecto.
Eric Hydrick
66
Iba a sugerir una picada de ganado, ¡pero las sugerencias de Lukas son mejores!
Russ Clarke
99
+1 para 'ten cuidado y no lo subestimes. Un holgazán de mucho tiempo como él podría tener uno o dos trucos bajo la manga '. Realmente debe tener ...
amyassin
3
@Brian, creo que estas soluciones técnicas pueden resolver el problema de la relación. Tenga en cuenta que el colega tiene 5 años de antigüedad y es un desarrollador supuestamente bastante capaz. Ashin, por otro lado, es un novato, por lo que no tiene mucha influencia. En este caso, es mejor atenerse a los hechos concretos en lugar de hablar sobre el problema con sus colegas y posiblemente con el gerente. Si es palabra contra palabra, el gerente probablemente confiará en el colega, o no, pero no puede darse el lujo de molestarlo de todos modos porque podría ser valioso para la compañía (mantener sistemas heredados, etc.)
Lukas Stejskal
3
Para agregar al punto de intercomunicación, falsifique también el sistema externo (c / c ++). Tú tienes tu proyecto, él tiene el suyo, así que no dejes que su proyecto no se termine y detenga el tuyo. Falsifique los resultados esperados de su servicio para su aplicación y escriba una prueba que compare los dos. Creo que Martin Fowler tiene un buen artículo sobre esa práctica, y definitivamente puedo recomendarlo.
Cthulhu
128

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.

pdr
fuente
44
Estoy de acuerdo en que trabajar hasta que tengas sueño es contraproducente. Nadie debería trabajar más de 40 horas a menos que sea un momento crucial y ciertamente no de manera regular.
HLGEM
36
Considera que si trabajas 12 horas y él trabaja 7, y no puedes avanzar si él no avanza, podrías ser el que termine viéndose mal . ¡Después de todo, necesitabas 12 horas para hacer lo que el chico acaba de hacer en 7! Entonces, tal vez en lugar de que disminuyas la velocidad o que él acelere, deberías pedir un proyecto adicional para pasar las horas adicionales mientras esperas que haga su parte. ¿Seguramente hay otras cosas que podrías estar haciendo / aprendiendo / documentando?
Konerak
44
Este es un gran consejo para ashin. Él puede (debería), por supuesto, defenderse con buenas pruebas unitarias, buena documentación, material tipo CYA, pero como humanos estamos juntos en esto. Estírate y encuentra una manera de acercarte a tu colega: trabaja con él y no con él. No seas tan estrecho con "el tuyo" y "mío" si no tienes que dibujar esa línea. Podría evitar resolver esto entre ustedes. Tendrá que aprender a ser abierto y flexible, así que ¿por qué no hacerlo cuando no está sobrecargado y ver si puede hacer que esto funcione sin la participación del gerente? Eso seguramente se notará sin que digas una palabra.
bmike
99
+1 para los srs. Me doy cuenta de que el formato es responder a la pregunta que se hizo, pero todos parecen muy contentos de hablar mal de la fiesta B después de escuchar un lado de una historia que involucra al menos a tres personas. ¿Tal vez el nivel de producción de la fiesta B ha sido completamente satisfactorio y en línea con su nivel de compensación durante años hasta que un chico nuevo al que le gusta quedarse en la oficina 12 horas y hablar sobre lo poco dedicado que se mostró el resto?
Affe
15
@Ashin: En serio, entiendo ese deseo de inicio de carrera y no estoy buscando aplastarlo. Pero te advierto que, eventualmente, conduce al agotamiento y que no es algo agradable. Incluso si pasas tu tiempo libre en proyectos personales, eso te ayudará. Pero alguien me dijo cuando comencé esta carrera que necesitaba algunos pasatiempos fuera de la codificación. Me reí y lo despedí, ¿por qué querría hacer eso? Y lo pagué más tarde.
pdr
40

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.

Otávio Décio
fuente
55
Los registros de correo electrónico son especialmente útiles para esto. Siempre hago un seguimiento de cada acuerdo con un correo electrónico y siempre notifico cuando termino por correo también.
Pelshoff
55
@Pelshoff, absolutamente. Incluso si cada persona está en una habitación individual, envíe un correo electrónico documentando sus solicitudes y seguimientos con cc al gerente.
Otávio Décio
16
¿Le pidió que no informara al gerente frente al gerente? Si le pregunta personalmente, dígale que lo hará después de aclararlo con el gerente. Otra cosa: NUNCA dé la menor impresión de que se está quejando. Siempre dígalo de una manera que le muestre simplemente declarando los hechos, nada más y nada menos.
Otávio Décio
3
El problema es que usted, como empleado, tiene la responsabilidad de hacer que la empresa tenga éxito. Y si la empresa tiene éxito, debería significar que usted tiene éxito (aumento, bonificación, beneficios). Esta persona está perjudicando a la empresa y, por lo tanto, a usted indirectamente.
Defiende
3
@Ashin: Él puede pedirte que no le envíes un cc al gerente, pero eso no significa que debas cumplir. ¿Tiene alguna autoridad para hacer algo si continúas contactando al gerente? Además, puede usar la función BCC para que él no sepa que el administrador fue CC'd.
FrustratedWithFormsDesigner
34

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.

Kate Gregory
fuente
1
Sí, durante mi etapa inicial, solía decir que el error se debe a que no pasé los argumentos correctos. Y así creé un registro en python que registrará una información antes y después de llamar a sus métodos. Y registraré los argumentos que pasé y el estado de devolución que obtuve. Y cuando nuevamente me dijo esto. Le mostré mi archivo de registro y así comenzó a corregir sus errores uno por uno. Pero lo triste es que lo sabía muy bien, puede que piense en arreglarlo más tarde, o puede que no lo esté probando en absoluto. él solo está dando sus métodos.
CALIENTE el
32

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.

revs HLGEM
fuente
44
Secundo esto. El software de seguimiento de errores es de vital importancia aquí. Suena codicioso, pero nunca debes mentirle a tu jefe para ocultar sus fallas. Esto suena como una situación muy peligrosa, así que tenga cuidado al respecto. Los correos electrónicos con el administrador CCed son una buena idea. Y él puede pedirle que no haga eso, pero usted está en su derecho de ignorar eso y / o responder al correo electrónico y enviarle un CC a su gerente nuevamente, negándose a seguir su ejemplo. Muy doloroso para la política, pero muestra la verdad del asunto como nada más.
WolfgangSenff
1
+1 para el primer párrafo. Además, el OP dice que quiere una buena relación con sus colegas, lo que de alguna manera implica plural, pero que se preocupa principalmente por este tipo injusto. Ahora está trabajando con ese tipo, mañana otros compañeros de trabajo trabajarán con ese tipo y recibirán el mismo tratamiento. Abordar la situación será beneficioso para todos esos otros colegas a largo plazo.
Sharptooth
"Dígale al jefe la verdad sobre los problemas que tiene (y muestre pruebas) con su código que no funciona". ¿Pero qué prueba? Si el gerente no conoce el proyecto a nivel de código / componentes, entonces no puede simplemente mostrarle el código. Además, me temo que llegar a una reunión con el jefe con impresiones de excepciones parecerá que tengo demasiado de "cubrir mi trasero".
maayank
28

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.

Eric Hydrick
fuente
55
Quizás su software es un orden de magnitud más complejo que el de Ashin. Tomar la línea dura con un colega con el que tiene que trabajar estrechamente pero que no se ha molestado en conocer es antisocial, contraproducente y muy poco profesional.
hplbsh
3
El que paga su salario es su empresa y no su colega.
Rudy
@lttlrck, estoy de acuerdo contigo, su aplicación es más compleja que yo. Pero es un proyecto existente. Al igual que nuestra empresa tiene una aplicación independiente existente escrita en c & c ++ que hace el mismo trabajo. Y ahora han planeado construirlo en la web para que el usuario pueda usarlo directamente sin instalarlo. Y hasta donde pude saber en mi etapa inicial de él y el gerente que, usan el mismo código del proyecto existente ligeramente modificado y además exponen sus clases y métodos a la pitón usando boostlibrary.
CALIENTE
3
@Ashin kn, el hecho de que su parte de la aplicación sea un proyecto existente no implica necesariamente que su tarea sea más fácil que la tuya. Pocas aplicaciones inicialmente diseñadas para uso de escritorio solo requieren ligeras modificaciones para exponerlas como servicios (por ejemplo, a través de una interfaz web); Los cambios son a menudo más importantes por desgracia. Cuando se trata de código heredado para cambiar la forma en que se usa por completo, un ligero cambio puede conducir rápidamente a una serie de efectos secundarios no deseados, incluso en aplicaciones que inicialmente no estaban demasiado mal diseñadas. Podría explicar su actitud más cautelosa, que parece tan lenta.
Bruno
1
+1 paraIf you know C/C++, you can offer to help on the main application logic to get things moving with that as well.
gyozo kudor
27

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.
Palmadita
fuente
44
Hasta ahora, uno de los mejores planes aquí. Solo agregaría "salir y oler las flores" ya que la parte de "trabajar hasta sentir sueño" suena aterradora.
Leonardo Herrera
@Leonardo - gracias :-) Estoy de acuerdo. Equilibrio trabajo / vida y todo eso, pero más allá del alcance de la pregunta del OP.
Pat
+1 para cuando se informan errores o problemas con el código - no el desarrollador
Ubermensch
16

"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 ++).

dr jimbob
fuente
12

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.

Trevor Powell
fuente
3
+1 por enfatizar que "comportarse profesionalmente es lo más importante para su carrera a largo plazo".
Skarab
1
+1 excelente respuesta: definitivamente la mejor que he visto aquí hasta ahora. Una solución humana a un problema humano. No se mencionan rastreadores de errores agresivos, etc. ;-)
TrojanName
8

¿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.

temptar
fuente
2
El sistema de seguimiento de errores 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. Incluso debería sugerirle al administrador que inicie un sistema de seguimiento de errores que pueda resolver muchos problemas como estos, eso espero.
CALIENTE el
¿Cómo informa QA de los errores por correo electrónico? Quiero decir, si estuvieras atascado desesperadamente, podrías hacer algo tan simple como una hoja de cálculo de Excel antes de tomar la molestia de implementar un sistema completo de seguimiento de errores.
temptar
2
Exactamente. Enmascarar a los colegas nunca puede realmente adelantarte en una empresa, o al menos no en ninguna empresa con equipos de gestión incluso escasos.
WolfgangSenff
@temptar: los informes de control de calidad se envían por correo electrónico e incluso registran los errores en algunos lugares, también, no lo tengo muy claro, ya que llevo aquí solo 3 meses y este es mi primer proyecto. sí, como dijiste, déjame mantener registros por mí mismo y déjame mantener informado a mi gerente por correo electrónico. Gracias por las sugerencias
HOT
2
@Ashin, es posible que desee buscar en Trac o Mantis, ya que son sistemas gratuitos de seguimiento de errores que son relativamente fáciles de configurar y usar.
Tangurena
8

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.

JeffO
fuente
4

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.

toto2
fuente
3

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.

Stefan Mohr
fuente
2

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!

AndSoYouCode
fuente
1

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í.

ioWint
fuente
-1
  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.

revs KyleM
fuente