Cómo tratar con un compañero de trabajo que me culpó del error que fue su culpa

Algunas personas tienen la tendencia a culpar agresivamente a otros para desviar la atención de ellos mismos. Como usted también es relativamente nuevo, debe haber sido muy conveniente para él hacer lo que hizo.

Aquí está mi consejo. Escriba un correo, describa cuál fue el problema, cómo llegó a la raíz del problema, cuál fue la solución final y cómo se puede prevenir en el futuro. Incluya a todas las partes interesadas en este correo.

Al final de este correo, escriba algo en estas líneas,

XYZ,

¿Puede añadir estos pasos en la documentación apropiada o en el documento de Procedimientos Operativos Estándar para este trozo de código?

De esta manera no le está “señalando con el dedo”, sino que le está diciendo explícitamente que él es el propietario de este trozo de código y, por lo tanto, el responsable del mismo. Llamar la atención es importante porque no todos (especialmente la alta dirección) abrirán ningún enlace de código para ver de quién es el código.

Un poco duro, pero se lo merece.

He construido una carrera de no jugar el juego de la culpa, pero la verdad es que los humanos escuchan la voz más fuerte. Sin embargo, si te involucras en defenderte, te bajará a su nivel y te vencerá con experiencia.

Si puedes encontrar uno, necesitas un campeón. Lo ideal sería que fuera tu manager, pero a veces, es otro desarrollador muy respetado. Ellos irán al bate para que tú silencies al ruidoso. Todo lo que tienes que hacer es tener una discusión privada con ellos sobre los hechos (no la culpa) de lo que hiciste para resolver el problema y cómo les gustaría que procedieras para que, la próxima vez que algo esté mal en el servicio, el problema pueda ser encontrado y arreglado más rápido. Eso puede implicar escribir una pequeña utilidad de prueba que pruebe el servicio directamente (sin usar el código de los otros desarrolladores), o algún registro o algo así, de modo que el problema de “nosotros contra ellos” pueda determinarse muy rápidamente. Si saben quién fue realmente el culpable, pueden limpiar tu nombre sin que entres en conflicto directo con el ruidoso.

Siempre me he inclinado hacia atrás para evitar poner a otros desarrolladores en la defensa. He dicho cosas como: “Tengo problemas para duplicar el problema, ¿puede decirme qué llamadas está haciendo al servicio y qué es lo que está recibiendo para que pueda probar el servicio correctamente? Si el desarrollador se molesta en darle rastros de las llamadas y respuestas reales, pregúntele qué esperaba recibir. Sin embargo, la mayoría de las veces, el desarrollador sólo te mostrará su código. En ese caso, a veces puedes detectar el problema. Incluso si lo haces, no los llames. Tienen que encontrar el problema por sí mismos. Haz que ejecuten el código a través de un depurador, y que inocentemente pregunten qué contiene una determinada variable en una determinada línea de código. Podría seguir, pero ya te haces una idea.

Es una tradición muy fina en la industria de la tecnología de la información (y en algunas otras, como la aviación) que cuando alguien encuentra un problema, todos trabajan juntos para encontrar una solución, e idealmente para encontrar la causa de fondo para que los procesos puedan ser mejorados, pero nadie tiene la culpa personal o sufre sanciones por cometer el error. El resultado es que la gente es abierta y honesta sobre sus errores, en lugar de tratar de encubrirlos, lo cual es en beneficio de todos.

Parece que hay gente en su tienda que no ha comprado en esta cultura, y eso es algo que necesita atención de la dirección.

Creo que deberías hablar con tu gerente sobre cómo se manejan los asuntos, especialmente los asuntos prioritarios que impactan la experiencia del usuario.

En este caso tienes 2 sistemas comunicándose entre sí y de repente la comunicación deja de funcionar. Cuando la comunicación falla, es importante que ambas partes miren a ambos sistemas. Todos ponen el foco en su servicio, lo que los lleva a no investigar las cosas en su extremo. La mayor pérdida de tiempo en la resolución de un problema es tratar de averiguar qué es lo que está mal en una parte de él que en realidad está funcionando como debería.

Estas son, sin embargo, experiencias de aprendizaje. Apuesto a que ahora saben perfectamente cómo solucionar los problemas de su servicio. Intente establecer un plan de solución de problemas basado en su experiencia, y dé uno de los primeros pasos para asegurarse de que es realmente su servicio el que está fallando (“¿Funciona el servicio al ser llamado desde otra página?”, “¿Falla el servicio parcial o totalmente?”). Usted es EL tipo del servicio web, puede tener un poco de confianza en su trabajo.

Trate de dejar ir el hecho de que en realidad fue su código el que falló. Tratar de llamarlo por eso es un poco mezquino. No debería haber puesto tanto énfasis en ti desde el principio. Véalo como un asunto general dentro de la compañía con la solución de problemas y maneje como tal con su gerente. Tampoco sabes si era realmente su código, también podría haberlo copiado de otra sección escrita por un colega.

Creo que la sugerencia de hablar con su gerente es buena. Tu gerente necesita saber que te culparon injustamente.

Pero encima de eso, estás siendo puesto a prueba. Tu instinto inicial es correcto; tienes que responder, o empeorará. Le enviaría un correo electrónico directamente y le haría saber que el problema estaba en su código, y que por esta vez, no se lo has dicho a nadie más que a tu manager, a quien tenías que decírselo para protegerte. Y por último le haría saber que si lo hace de nuevo, lo harás público.

Llego un poco tarde a la pregunta aquí, pero junto con el muy buen consejo de la respuesta de Edgar, hay una segunda parte de esto.

Si envías una comunicación en la que encuentras el problema y notas dónde se resolvió, entonces los otros desarrolladores probablemente sabrán dónde está el problema (esto es bueno), pero la dirección probablemente no.

Hacerlo así significa que le has hecho un favor a este tipo: te llamó públicamente, encontraste el problema, lo arreglaste y no lo dejaste caer con la dirección. Construir una confianza como esta con tus compañeros de trabajo te mantendrá en buen lugar a largo plazo.

Ligera nota al margen - esto obviamente depende ligeramente de la naturaleza de la falla que encuentres en su trabajo. Si lo que encuentras es tan atrozmente malo que indica incompetencia por su parte, puedes escalar esto tranquilamente a tu gerente - ellos querrán saberlo y estarás construyendo la confianza con ellos también.

Sugiero que lo consultes con la almohada antes de responder a los aspectos personales de la situación. Si arreglas el problema y vuelves a poner las cosas en marcha, entonces sigues siendo “el hombre”. Después de descansar un poco será más fácil ser amable.

Mientras que el tema principal ya se trató ampliamente en otras respuestas - el otro tipo te acosa - me gustaría señalar otra perspectiva.

El arreglo se hizo en el código que el otro tipo poseía, pero la mayoría de las veces el servicio podría haber evitado un problema mayor siendo más conservador en el manejo de las solicitudes de los clientes. ¿Valida las entradas? ¿Informa de algún error en tiempo de ejecución? ¿Existe un entorno de pruebas (esto se aplica también al consumidor)? A veces un problema en el servicio sólo esperaba salir a la superficie, así que yo diría que sólo porque se hizo un arreglo en un lugar no significa que esa sea toda la historia. Además, para problemas como este, hay más que sólo código. También hay un proceso.