¿Debo informar a un desarrollador de software que necesita mejorar su productividad de prueba?

Tienes un problema de gestión. Y, sea cierto o no, debe explicarles que el tiempo que pasa probando es la razón por la que el código es tan bueno y, dado que sigue siendo más rápido que otras personas, tienen dos opciones:

1. Déjalo en paz y espera mantenerlo durante algunos años antes de que descubra su valor y vaya a donde obtendrá una paga decente.
2. Moléstelo por el tiempo que pasa probando, lo que resultará en que no proporcione un código tan bueno o, más probablemente, en que se vaya por completo.

o incluso 3: Date cuenta de que tienen algo muy bueno y asegúrate de tener los recursos para mantenerlo feliz todo el tiempo que puedas, con buenas condiciones de trabajo, mejor paga, lo que sea necesario. Que está brindando suficientes beneficios a la empresa como para que les importe más eso que el tiempo que deja descansar la mente mientras realiza las pruebas. (Y, podría señalar, para algunas personas, que el tiempo de inactividad es absolutamente esencial para tener un tiempo de actividad de alta calidad).

Permítanme reiterar esto : el hecho de que los dedos de alguien no se muevan no significa que estén inactivos. Su gerencia parece pensar que están midiendo algo útil, pero están descontando por completo el tiempo dedicado a pensar, planificar y recargar, todo lo cual es válido y necesario. Pero, como parecen ser algo cortos de vista, la mejor manera es explicar que, mientras está probando, también está pensando y mejorando el producto . Eso puede ser cierto o no, tal vez se esté recargando (lo que hace que el producto sea mejor), pero estoy bastante seguro de que su gerencia no entendería ese concepto. Tal vez se está perdiendo el tiempo, lo que lo hace más feliz y, por lo tanto, mejora el producto. Tal vez podría trabajar aún más eficientemente y, a medida que mejora en las pruebas, se acelerará.

¿Por qué la gerencia no mira a los otros desarrolladores, que son más lentos y menos productivos que su nuevo desarrollador junior? Intente desviarlos hacia sus otros desarrolladores. O, ¿por qué no hacer que ellos hagan las pruebas de su trabajo, ya que son tan rápidos en eso?

Están sucediendo muchas cosas aquí, y no muchas buenas.

Contrató a un desarrollador de software junior que parece estar, en general, muy bien. Ese es un buen comienzo. Sin embargo, los jóvenes necesitan tutoría para aprender y desarrollar sus habilidades. Así que ha elegido a un desarrollador junior, que puede no tener mucho conocimiento y experiencia en buenas técnicas de prueba manual, y espera que sea un probador manual altamente competente sin ningún tipo de tutoría o supervisión de un probador experimentado.

Incluso sin acceso a evaluadores experimentados y evaluadores de control de calidad, su desarrollador junior está escribiendo código con pocos defectos. Además de eso, están completando el paquete de trabajo general de diseño, desarrollo y prueba de la solución en 5 a 6 semanas cuando se estima que un desarrollador intermedio o senior diferente tardaría 8 semanas en hacer el trabajo. Están entregando 2-3 semanas más rápido y aparentemente de mayor calidad de lo que esperaría de una persona de mayor rango.

Cuando se trata de estimar, ¿le preguntó a su ingeniero junior cuánto tiempo tomaría hacer el trabajo? Una de las reglas fundamentales de la estimación es que las personas más cercanas a la obra son mejores en la estimación. Aunque, como junior, es posible que necesiten tutoría en buenas técnicas para comprender y estimar el trabajo. También me preguntaría si tiene sentido estimar el desarrollo y las pruebas de forma independiente o si tiene sentido estimar la finalización de todo el elemento de trabajo.

Esto conduce a "tiempo de inactividad". Medir el "tiempo de inactividad" no significa mucho en el trabajo del conocimiento. ¿Qué significa que están inactivos el 50% del tiempo? ¿Cómo se determina este número? Es posible que desee reconsiderar si esto significa algo, especialmente porque el trabajo se está haciendo más rápido de lo previsto.

Tampoco entiendo la vacilación de tener una conversación con el ingeniero junior para entender lo que está pasando. No tiene que ser una confrontación, pero tales conversaciones deben ser algo habitual entre cualquier gerente o líder de equipo y sus subordinados directos o miembros del equipo. Así es como encuentra y soluciona los problemas.

También recomendaría traer de vuelta a los especialistas en pruebas, de alguna forma. Incluso si su función es ayudar a supervisar y enseñar a los desarrolladores buenas técnicas de prueba, en lugar de ser las personas que diseñan y ejecutan todas las pruebas. Las pruebas son una especialidad y un conjunto de habilidades que no todos tienen. No tener personas que puedan mejorar el estado del arte local y subir de nivel a los ingenieros a su alrededor puede ser un detrimento para el equipo y la organización.

Entonces, en resumen:

• Reconsidere su estimación. Estimar el acabado del trabajo, sin tratar de estimar el ciclo iterativo de diseño/desarrollo/prueba.
• Involucre a su ingeniero junior en la estimación del trabajo.
• Reconsidere si el "tiempo de inactividad" es una medida valiosa para los trabajadores del conocimiento. Pista: no lo es.
• Tenga una conversación con su ingeniero júnior sobre cómo asegurarse de que tenga lo que necesita para ser eficaz y eficiente. Eso incluye tutoría y entrenamiento para desarrollar y fortalecer habilidades débiles.

Esto es realmente simple. No hay nada malo con el desempeño real de este joven desarrollador. El problema es su rendimiento medido por alguna métrica de rendimiento bastante estúpida. Así que simplemente explíquele lo que debe hacer para sortear esas métricas de rendimiento.

Una vez tuve el problema de que alguien contaba con qué frecuencia registrabas cosas en Perforce. Por lo tanto, pasa dos semanas implementando una función y la verifica. Una verificación en dos semanas, eso es un rendimiento increíblemente malo. Una vez que se le informa, verifica el progreso más pequeño, al menos cuatro veces al día. Eso es un factor 40 en la mejora del rendimiento.

Discutí esto con la gerencia y traté de argumentar que deberíamos traer algo de control de calidad para reducir los tiempos de prueba, pero quieren tener una reunión con él y escalar cosas que absolutamente no quiero hacer.

Argumentaste mal.

Si la gerencia quiere que los desarrolladores realicen el control de calidad y usted no puede hacerlos cambiar de opinión, se acabó. Tienes que trabajar con lo que tienes.

En su lugar, debería haber enfatizado que los diferentes desarrolladores tienen diferentes puntos fuertes y que el desarrollador está haciendo un gran trabajo al ofrecer funciones en general.

Vale la pena señalar que hay dos factores en juego. Son un poco más lentos en las pruebas, claro, pero eso empeora por el hecho de que funcionan más rápido durante el desarrollo.

Pero puedes convertir esto en algo positivo:

• Haz que trabajen en tareas que no impliquen muchas pruebas. Esto maximiza la tarea en la que son buenos.
• Involúcrelos fuertemente en las reuniones de revisión de diseño durante su fase de desarrollo. Si es un buen desarrollador, otros pueden beneficiarse de sus puntos fuertes.
• Haga que todos revisen las estrategias de prueba de los demás. Esto permite que todos compartan metodologías.

Dependiendo del tipo de prueba involucrada, podría ser bueno alentarlo a alternar entre escribir código y probar con más frecuencia (por ejemplo, escribir durante una semana o terminar una pequeña parte de la función y luego probarla). Mencionó que lo encontró un poco impulsivo; quizás en este caso sería mejor intentar convencer a la gerencia de que su desempeño actual ya es bueno. (Especialmente porque es un junior: tratar descaradamente de exprimir más trabajo de un desarrollador junior que ya se está desempeñando mejor que sus superiores sin promoverlo directamente es una forma segura de sacarlo de la empresa, y eso no es en absoluto lo que quieres. )