Como ingenieros, creo que queremos creer que las métricas cuantificables en todos los casos resultarán en un análisis más imparcial y, por lo tanto, mejor de una situación o decisión. Sin embargo, al evaluar el desempeño de una persona (en oposición al desempeño de una máquina o programa) tenemos que reconocemos que las personas son inteligentes y, por lo tanto, capaces de afectar las métricas por las cuales trataríamos de medirlas. En algunos casos, esto puede producir el efecto deseado: el individuo hace más (o menos) de lo que identificamos como un signo de que está haciendo bien (o mal). En otros casos, las métricas se pueden jugar fácilmente, o resultan ser sustitutos deficientes para capturar el “rendimiento de ingeniería”.
El resultado es que una forma justa de evaluar a los ingenieros será una combinación de lo objetivo y lo subjetivo. Ser un buen ingeniero de software se define por muchos criterios subjetivos:
- ¿Puede simplificar y explicar problemas complejos a personas menos técnicas?
- ¿Puede hacer que otros ingenieros estén de acuerdo con sus planes, y puede hacer que lo ayuden a construirlo, o es molesto trabajar con él?
- ¿Escribes software de calidad? ¿Programa a la defensiva, hace que las pruebas sean parte de su proceso y construye sistemas que son fáciles de solucionar y mantener en el futuro?
- ¿Eres eficiente? ¿Aprovechas bien tu tiempo y haces las cosas? (Aquí hay cierta objetividad, pero cuando agregas “nivel de complejidad” se vuelve muy subjetivo una vez más)
- Cuando se encuentran errores, o ocurren cosas malas, o si está trabajando dentro de un plazo, ¿puede mantener la compostura y entregar resultados?
- etc …
Para mí, es igualmente importante capturar cosas subjetivas, porque es una gran parte (¿más grande?) De lo que significa ser un buen ingeniero, y si solo intentas hacerlo con métricas objetivas, perderás el bosque en los árboles.
- Cómo crear un nuevo software yo mismo
- ¿Cuál es la pila de tecnología de Blossom?
- ¿Es la automatización de pruebas un buen campo para alguien a quien le gusta la programación pero no puede entrar en desarrollo?
- ¿Qué es el diseño orientado a objetos usando UML?
- ¿La "forma de Google" de hacer las cosas suele ser la mejor manera?
Ahora, hay cosas objetivas que pueden ayudar a un ingeniero a argumentar ante su gerente que se están desempeñando bien de manera subjetiva, pero no es toda la historia. Me gusta decirle a mi gente que las métricas son una gran parte de la discusión, pero si voy a preguntarles a sus compañeros si son buenos para explicar las cosas y todos dicen “no, Bob es confuso y conflictivo” no hay suficiente métricas en el mundo para cambiar eso.
Una medida objetiva que me gusta es la entrega de trabajo al cliente. es bastante objetivo decir que se lanzó la función X y que los clientes pueden usarla. Vinculando a los ingenieros con un resultado concreto que el equipo se haya comprometido (importante … no les pidas que entreguen algo y luego nunca prioricen o financien el trabajo). Es una gran medida objetiva de la capacidad de los ingenieros para entregar.
Al mirar medidas objetivas como líneas de código, número de comentarios sobre revisiones de código, número de puntos de historia entregados, etc., esté dispuesto a moderar su percepción del valor de la persona frente a algunos comentarios de sus pares y su propia percepción de su contribución. No intente eliminar lo subjetivo, hay aspectos importantes de ser un buen ingeniero que son de naturaleza subjetiva.