¿Cómo lidiar con un compañero de trabajo técnicamente incompetente?

Soy ingeniero de software. Trabajo en una startup mediana que está creciendo muy, muy rápido. En general, me encanta mi trabajo, mis compañeros de trabajo y el ambiente.

Una cosa sobre mi empresa es que la mayoría del personal tiene formación técnica. Incluso nuestros gerentes de producto, control de calidad, atención al cliente y equipo de ventas tienen experiencia en ingeniería. Esto puede sonar ridículo e innecesario para algunas personas, pero hace que muchas cosas sean muy fáciles para mí. Puedo simplemente ir a un miembro de soporte y explicar el error/característica/algoritmo en lenguaje de ingeniero e inmediatamente entenderán y responderán al cliente en el lenguaje apropiado de lenguaje humano/empresarial. Esto permite a los gerentes de producto diseñar un buen producto tecnológico. Por ejemplo, uno de nuestros gerentes de producto es ingeniero de EE por educación, por lo que es muy fácil hablar con ellos sobre varios aspectos de mi trabajo, entienden las dificultades, las prioridades, etc.

Sin embargo, hay un compañero de trabajo en el equipo de control de calidad que desafortunadamente me frustra. He estado trabajando estrechamente con ellos durante los últimos meses, ya que estamos creando un producto completamente nuevo y soy el líder técnico de una de las partes. El título de su trabajo es "Ingeniero de control de calidad de hardware". Saben cosas básicas como cómo usar la terminal, leer código, electrónica básica, etc. Pero cada vez que entramos en temas más complicados como depurar cosas no triviales, parecen un poco indefensos. Termino depurando con ellos durante largos períodos de tiempo. En algún momento, me dictan lo que están tratando de probar y ejecuto pruebas (manuales) para ellos. Estas partes ni siquiera están relacionadas con mi parte de la tubería. Mi trabajo está probado y funciona, pero hay otros problemas en otros lugares y para asegurarme de que mi trabajo no tenga errores, también necesito entender los errores en otras partes.

También debo decir que definitivamente no estoy hablando de un compañero de trabajo que está holgazaneando o algo por el estilo. (e incluso si lo hicieran, no me importaría ya que no tengo una posición más alta que la de ellos; de hecho, soy más joven). Me imagino que para un puesto de control de calidad tienen experiencia técnica más que suficiente. Entienden conceptos técnicos y pueden realizar pruebas. Es solo que parecen obstaculizar el desarrollo ya que todos los demás, incluso en posiciones menos técnicas, tienen más conocimiento en el campo. Esto me frustra. ¿Cómo debo abordar esta situación? Creo que, dado que están haciendo todo bien, ¿debería corregir la forma en que abordo este problema?

Solo quiero asegurarme de respetar a mi compañero de trabajo y mejorar mi productividad y la de la empresa y hacer el mejor producto que podamos hacer. ¿Algunas ideas?

¿Es su colega consciente de su relativa falta de conocimiento? Según su tiempo con ellos, ¿han mostrado pruebas de que quieren aprender más que sea útil para su trabajo?
No entiendo lo que crees que puedes hacer. No se puede hacer que alguien de repente entienda las pruebas y si no es parte de su trabajo (lo han logrado hasta ahora), entonces no hay ningún requisito para que lo aprendan.
¿Por qué se está metiendo en temas sobre algoritmos, en primer lugar con una persona de control de calidad? ¿Y por qué depurar y ejecutar pruebas manuales "juntas"? La tarea debe tener unos requisitos y "criterios de aceptación" claros, los cumples o no. El control de calidad es responsable de informar si no hay coincidencias o si hay errores de efectos secundarios.
Aquí existe una seria cuestión de proceso: ¿quién es responsable de diseñar, validar, ejecutar e informar sobre los casos de prueba? Tengo que diseñar mis propios casos de prueba, hacer que otro desarrollador los valide, y luego el personal no técnico los ejecuta y los informa, momento en el que se pasa o no.
"Mi trabajo está probado y funciona, pero hay otros problemas en otros lugares y para asegurarme de que mi trabajo no tenga errores, también necesito entender los errores en otras partes". Si su trabajo está probado y funciona, eso debería demostrar que su trabajo es no es buggy De lo contrario, es posible que sea necesario rediseñar las pruebas, o el producto, para proporcionar un mejor aislamiento entre los componentes.

Respuestas (3)

Termino depurando con ellos durante largos períodos de tiempo. En algún momento, me dictan lo que están tratando de probar y ejecuto pruebas (manuales) para ellos.

Por favor, deje de hacerlo inmediatamente. Parece que de alguna manera quieren depender de ti y tú (sin saberlo) los estás ayudando a depender de ti. El chat/ayuda ocasional es entendido y apreciado, pero eso nunca debe llegar a un punto en el que estés haciendo el trabajo de otra persona por ellos.

Me imagino que para un puesto de control de calidad tienen experiencia técnica más que suficiente. Entienden conceptos técnicos y pueden realizar pruebas. Es solo que parecen obstaculizar el desarrollo ya que todos los demás, incluso en posiciones menos técnicas, tienen más conocimiento en el campo.

Esto indica claramente que no son adecuados para su función. No hay excusa para no estar calificado para un rol/posición. tienes que hacerlo

  • Aprende los conocimientos / cualidades requeridas para un trabajo / puesto
  • Abran paso a alguien que esté calificado.

Sugerencia ( en el orden dado )

  1. DEJA de ayudarlos en todas las tareas. Que lo trabajen y prolonguen o fracasen.
  2. Trate de visualizar el cuello de botella general sin señalar con el dedo a su gerente/jefe. Además, haga una lista de ocasiones en las que los ayudó a lograr el resultado, más allá de su horario/jurisdicción esperados.
  3. Comunique las soluciones que puede ofrecer (p. ej., cualquier sesión de formación/orientación que pueda llevarse a cabo para ponerlos al día).
  4. Finalmente, reafirme el hecho de que, debido al cuello de botella, la productividad general del equipo disminuye.

Si la alta gerencia es sensata, debería poder obtener la "pista" y tomar las medidas necesarias.

No definiste el rol de esta persona, y tampoco lo hizo el autor original de esta pregunta. En una organización pequeña, este desajuste a menudo puede provenir de expectativas no coincidentes sobre roles y responsabilidades, y cómo eso podría afectar un proceso que, para empezar, no estaba claramente definido. Eso no lo convierte en el déficit de QA Hardware Engineers, es un problema de proceso. No es poco común ni insostenible que un desarrollador ayude al control de calidad a reproducir/diagnosticar un problema. Ese podría ser un proceso válido, solo alguien debe dejar en claro que es parte del proceso si ese es el caso.
El OP también podría querer dejar que su supervisor/jefe se entere de la situación. No para llamarlos por disciplina, sino para entrenarlos más. En un buen ambiente de trabajo, puede hacer que ellos, su jefe y el jefe del OP se reúnan para discutir estrategias de capacitación para ayudar a la persona en cuestión, en lugar de meterla en problemas.
Una cosa que el que respondió no mencionó: si los está ayudando, en realidad puede empeorar el problema. O no son adecuados para el trabajo tal como está escrito, o son adecuados y su trabajo debe adaptarse según corresponda para el control de calidad, con todas las herramientas necesarias. Una cosa es que sea un ingeniero de pruebas; otra cosa es si solo tienen un historial de control de calidad de la vieja escuela donde están acostumbrados a romper cosas y escribir errores.

Son ingenieros de hardware. Tienes suerte de que incluso puedan escribir código. Ese no es un rol centrado en el software.

Si se supone que debe ser un rol centrado en el software, debe quedar claro que un ingeniero de hardware no va a ser suficiente. Las personas también tardan un tiempo en acostumbrarse a ser buenas en su trabajo. Trata de darle algo de tiempo a este compañero de trabajo. QA no significa no junior.

Después de ser corregido sobre lo que hace un ingeniero de control de calidad de hardware, esta persona suena como un junior. Para un junior, esto no parece gran cosa.

FALSO. Un ingeniero de hardware que no puede escribir código ha quedado obsoleto desde hace algunas décadas. Incluso si el software nunca es el producto del trabajo de alguien, hay demasiados puntos en un flujo de trabajo de hardware en los que poder escribir código para modelar algo, o ejercitar su proyecto, o hacer arreglos triviales en lo que otra persona escribió, es absolutamente esencial . Alguien que no puede hacer eso está tratando de trabajar con ambas manos atadas a la espalda . Además, tal incapacidad indicaría una gran brecha en la capacidad de pensar como un ingeniero .
Pero en este caso , está confundiendo completamente el título del trabajo : un "ingeniero de preguntas y respuestas de hardware" no diseña hardware, lo prueba . Y el software es el corazón palpitante de tales pruebas.
El software de prueba de @ChrisStratton para asegurarse de que funciona en el hardware requiere que sepa cómo hacer exactamente eso y nada más en este momento. Otra cosa a considerar es que si esta persona acaba de salir de la escuela o no está familiarizada con el idioma, es esencialmente un estudiante de tercer año.
Está interpretando "Ingeniero de control de calidad de hardware" como alguien que prueba software en diferentes CPU. Ese sería un rol de "control de calidad de portabilidad". Estoy con la interpretación de Chris: alguien que está probando nuevos diseños de hardware para validar el hardware . El OP da varias pistas de que la empresa emplea a personas con habilidades de diseño de hardware, por lo que probablemente no solo estén creando y probando software. El control de calidad de hardware significa que es posible que tengan que escribir software para probar cualquier caso de esquina de hardware que se les ocurra.
Supongo que el 'Ingeniero de control de calidad de hardware' no es un ingeniero en absoluto.

O es el caso de que el control de calidad de asistencia del desarrollador es una parte esperada del proceso de control de calidad del hardware, o no lo es.

Si es el caso de que el control de calidad del hardware debe ser autosuficiente, esta brecha en la capacidad técnica debe informarse a la gerencia de este ingeniero como un lastre en la velocidad del proyecto.

De cualquier manera, según su descripción, parece que está pasando mucho tiempo probando que el código de otra persona funcione en el hardware. Eres la persona equivocada para hacer esto. La persona que debe hacer esto debe ser el desarrollador que trabaja en ese código, no usted.

Indique a este ingeniero que trabaje con los desarrolladores que son directamente responsables de la funcionalidad que intenta probar. Debe ser parte de cualquier proceso de desarrollo para que Desarrollo y control de calidad trabajen juntos hasta cierto punto para asegurarse de que el producto se pruebe, pero eso no significa algún recurso de desarrollo arbitrario, significa que el autor real del código se está probando, o al menos mínimo, una persona cuyo trabajo reciente se haya centrado en esa parte del código base.

Pasar tiempo con el control de calidad tratando de probar el código de otra persona a partir de una parte del producto que normalmente no toca es fundamentalmente ineficiente, aparte de la experiencia de este ingeniero en particular. Intenta solucionar ese problema primero.

Después de abordar eso, si el esfuerzo adicional para apoyar a esta persona sigue siendo un gran lastre para los recursos de desarrollo, intente ver si puede hacer que esta persona se empareje con otra persona en la organización de control de calidad para realizar esfuerzos de depuración o reproducción más profundos. Es probable que se beneficien de la instrucción/transferencia de conocimientos de alguien que esté acostumbrado a ver las cosas desde la misma perspectiva y resolver los mismos tipos de problemas generales. Si no se les puede enseñar en absoluto, entonces ese problema surgirá de forma natural en los lugares de la estructura de gestión que estén mejor preparados para abordarlos y, si no lo están, aprenderán a ser autosuficientes y usted ya no tendrá el problema.

¿Cómo lidiar con un compañero de trabajo técnicamente incompetente?
RespuestasAquíPolítica de privacidad1y, 0v