Cómo medir el "cómo" y no el "qué" en performance laboral en IT

Métricas laborales IT

Uno de los problemas más usuales para los laburantes IT cada fin de año se da con la aparición de los resultados de los Performance Management (PM) Processes:

http://en.wikipedia.org/wiki/Performance_management
".. includes activities which ensure that goals are consistently being met in an effective and efficient manner."

"..incluye actividades las cuales aseguran que los objetivos son consistentemente alcanzado de modo efectivo y eficiente."


Performance Management "para la fábrica"
El modo estándar típico de ver qué tan bien labura un empleado, fuera de ámbitos informáticos es variado, una simplificación muy burda y rudimentaria se puede hacer reduciendo todo el análisis de PM a ver si el trabajo de un empleado responde positivamente a la respuesta que espera el "jefe" a la pregunta "¿Tu empleado hace lo que vos querés que haga?".

Es verdaderamente básico y por ende las mediciones típicas incorporan varios criterios más, a los efectos de "salpimentar" un poco de "realidad" el resultado del PM.

Como ven, el análisis PM típico, clásico, tradicional, se enfoca fuertemente en el "Qué", y no el "Cómo".

Es un enfoque de análisis de rendimiento de un empleado que se ha demostrado fuertemente incompatible con resultados que reflejen efectivamente la realidad de qué tan bueno y qué tan bien trabaja un empleado que realiza tareas altamente especializadas y no repetitivas. 

[En constrate positivo, ese mismo tipo de análisis funciona muy bien con tareas no especializadas y repetitivas, básicamente hablamos de "cantidades simples de algo, realizada en base a un plazo" > Cuantos jeans cosió un costurero en el año (desglose por mes), Cuantas chapas cortó un operario por día/semana/mes/año, etc. etc.]


La "fábrica" y los equipos de trabajo IT
Un craso error habitual en la medición de rendimiento de un empleado IT es que RR.HH. asocie "la fábrica" con el modo de trabajo de un equipo IT. Ello suele culminar con la adopción de un proceso de performance management que se orienta a la medición de "qué" hace el empleado, y no en el "cómo".

En el caso de IT, el "cómo" es vital para la mayoría de las tareas de nivel técnico de medio a alto. Por ejemplo: no es lo mismo que un buen developer escriba 20.000 líneas de código por año, de altísima calidad vs. un developer novato que escribe las mismas 20.000 líneas.

Muy similares ejemplos existen en otras especialidades IT complejas: project management, adm. de sistemas, adm. de redes, adm. de bases de datos, management IT, etc.



El problema al medir el "qué" en IT
El problema que suele tener RR.HH. para medir los "cómo" es que si bien la recolección de datos puede ser automatizada y/o sistematizada, la evaluación de performance suele quedar fuera de las áreas IT, es decir, el análisis queda en manos de personas que tienen menos entendimiento real/profesional de las tareas que los mismos empleados IT.

En el caso típico de la "fábrica" y sus tareas simples y repetitivas, no es mayor inconveniente, casi cualquiera de nosotros entiende mayormente los entresijos de cortar una chapa con maquinaria, al menos luego de una mínima introducción.

Sin embargo, es muy difícil - mucho pero muy difícil - que alguien que no escribió nunca un programa de computadora, entienda realmente el valor del código escritor por un developer, comparandolo con otro código de otro developer.

La solución es simple: la persona que evalúa el rendimiento de un trabajo IT especializado debe ser un especialista en ese trabajo, y debe tener un nivel técnico superior al de aquel que está siendo evaluado.

Más o menos es la misma idea de fondo que hay cuando vamos a estudiar un curso en la facultad: el profesor tiene que saber más que el alumno, sino los resultados no son fiables.


La medición del "cómo"

Las metodologías modernas de medición de rendimiento basada en el "cómo" se hace un trabajo (en vez de "qué" se hace en el trabajo), nacieron en los 70' de mano de algunas técnicas que fueron evolucionando y se diversificaron, justamente para adecuarse a los campos de especialización con los que estaban tratando.


Sabermetrics
http://en.wikipedia.org/wiki/Sabermetrics

Fue una de esas metodologías, y nació para ser utilizada para medir la performance de jugadores de equipos de beisbol. Al momento ya fue adaptada para medir la performance de practicantes de otros deportes ( http://en.wikipedia.org/wiki/APBRmetrics ).

La base de las metodologías de evaluación de performance basadas en el "cómo" es establecer cuales son las características deseables en un empleado. Esta parte es clave, se enfoca directamente en el "cómo" debería hacer algo idealmente un empleado, obviando sistemáticamente el "qué" hace el empleado.

Otra cuestión clave es detallar el mayor número posible de características deseables relativas al trabajo. La simplificación y la reducción de características están fuertemente contraindicadas, hay que intentar aumentar al máximo la clasificación en características especializadas que son deseables para el trabajo del empleado a la vez que se pone un especial énfasis en incluir características que no están exactamente relacionadas con el trabajo del empleado.

Un ejemplo burdo
Por ejemplo, en un developer C#, una característica "no relacionada" podría que fuera muy bueno configurando e instalando switches Cisco L2/L3, o que fuera muy buen pen-tester web en seguridad IT.

[Como ven, el listado de características deseables no se sale del marco de trabajo IT en gral., pero sí se sale completamente del centro habitual de considerar solo las características deseables propias del puesto de trabajo donde se desempeña el empleado específicamente (que es algo obligatorio de hacer en las metodologías tradicionales focalizadas en el "qué").]

Una vez que están definidas todas esas características, se puede realizar valoraciones numéricas con un tope, del 1 al 10 en cada característica. Luego, se busca correlacionar las puntuaciones individuales entre características complementarias según el marco de trabajo del empleado:

Por ejemplo, si un empleado conoce mucho de instalación de servidores Windows, y a la vez es buen developer C#, y a la vez se encarga de trabajar con un cliente que tiene pobremente configurados sus servidores Windows (y/o que está buscando actualizar la versión de los mismos, o migrar a una arquitectura más compleja/mejorada, etc.). Entonces este empleado se convierte en un "jugador valioso".

En contraste un buen developer (tan bueno en C# como el anterior), trabajando para el mismo cliente, no tiene tanto valor como jugador para el equipo...pero podría tenerlo en otro contexto!


La clave de las mediciones de performance por "cómo" vs. "qué" está en eso, encontrar las relaciones ocultas entre capacidades (skills), altamente especializadas, el contexto de trabajo y obtener información detallada y puntual que permita re-ordenar y re-asignar posiciones buscando lograr los mejores resultados.

Y eh aquí el objetivo: Las sabermetrics, usadas en el contexto del beisbol, permitieron cambiar de posiciones a jugadores, buscando optimizar las capacidades combinadas - sumadas - de todos los jugadores para obtener el máximo resultado posible para cada característica deseable necesaria en el trabajo del equipo.

Es decir, una vez que se obtiene los datos, se puede reorganizar la producción y las tarea del equipo IT, de modo tal que - por ejemplo - al colocar en una hoja de cálculo, de modo horizontal, de izq. a derecha...

Nombre de Empleado - Característica 1 - Característica 2 - Característica 3

...se obtenga el máximo posible en cada característica. 

De esta manera, si aparece por ejemplo un cliente con infraestructura basada en servers Linux y necesita developers C# y nuevos servers Windows, pero a la vez no va a dejar Linux, el equipo de trabajo disponga de todos los skills primarios - developers C# - y accesorios, tendientes a lograr los mejores resultados posibles en la asignación.


Recién luego de disponer de todos estos componentes para el análisis: características deseables, valoraciones por característica, y organización/contexto de la tarea del empleado (y posibles planes de reasignación/reoptimización de tareas), se podrá obtener una valoración real de los skills y del desempeño de un empleado en un equipo IT.

Por ejemplo, si tenemos un empleado A, administrador Windows, y lo ponemos a trabajar instalando aplicaciones para un cliente que usa servidores Linux, de seguro que su rendimiento va a ser bastante bajo. Si tenemos un empleado B, administrador Linux y lo ponemos a instalar aplicaciones para ese mismo cliente, va a descollar. 

La asignación es "instalar aplicación XXX en el cliente", a igual nivel de skills para instalar la aplicación XXX, el empleado B va a tener mucho más éxito y mejor performance que el empleado A.

Ahora si tenemos al empleado A trabajando con servers Linux, podríamos buscar ponerlo a trabajar en algun cliente que tuviera servidores Windows, y veríamos como despega su performance.