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.

Un par de cosas importantes a considerar para armar un equipo interno de desarrollo

IMHO, "cosas importantes a considerar para un equipo interno de desarrollo" (van a ver que lo pueden aplicar a "cosas importantes a considerar para un equipo IT" en gral.):

- Capacidad Técnica
- Capacidad Humana
- Excelente Administración de los RR.HH.


* Capacidad Técnica
La gente que labure en un equipo tiene que tener la capacidad técnica para resolver el trabajo que es responsabilidad de ellos. Si no saben hacer el laburo para el que les pagan, y la empresa necesita que lo hagan "ya o ya mismo", entonces la empresa va a tener montones de problemas.

Cabe la posibilidad de darles tiempo de aclimatación/training previo, antes de poner el equipo en producción, pero ese tiempo debe estar bien administrado (y claro, alguien va a tener que "cubrir" el servicio no provisto por el equipo a la organización mientras se "aclimatan"). Cabe señalar que la "falta de capacidad técnica actual con opción a training" solamente está "permitida" para los miembros del equipo, los jefes de equipo (o alguien, cualquiera), debe tener capacidad técnica desde el día 1 (uno), para dirigir el aprendizaje del equipo y manejar bien ese tiempo de preparación dado al equipo antes de entrar a producción.

En mi experiencia, en los equipos donde todos los miembros (o casi todos), carecen de capacidad técnica efectiva para el trabajo que les encomendaron, no importa el tiempo de training que se les de, normalmente las cosas no funcionan bien. El motivo es que un equipo así es una "gallina sin cabeza" (si me disculpan la métafora brusca), porque corren para todos lados, y no tienen cómo pensar a donde van yendo.

En este caso, Ojo, darle a un equipo "un tiempo" para que "acostumbren", para "formarlos" no quiere decir darles 2 años para que aprendan cómo trabajar, especialmente si durante esos dos años los errores van a costarle mucho dinero/recursos malgastados/tiempo a la organización. 

IMHO, alguien tiene que saber "algo", desde la práctica profesional no se puede armar un team de 100% novatos y querer formarlos a todos "on the job", mientras hacen el trabajo (que no saben hacer recordemos). 

Más o menos es mandatorio - por puro y simple sentido común - que la persona que "sepa" tenga que ser el jefe del equipo, por contraste, imaginen un jefe que no tiene capacidad técnica y dirige a miembros de equipo que no la tienen, y tiene uno o dos miembros que sí tienen capacidad ¿Cómo termina el cuento?


* Capacidad Humana
Estos tipos tienen que saber laburar bien (o como dije antes, alguno debería ya tener experiencia), "ponerse la camiseta", como dicen los jefes habitualmente, frase que está un poco sobre-utilizada, pero es aplicable a este caso.

El laburo IT tiene esto de tener que quedarse fuera de hora a veces, o ir la "extra mile" (la "milla extra"), para lograr los objetivos. Los miembros de un equipo tienen que estar al tanto de eso.

También tiene que haber un convencimiento común de que están laburando para algo, útil si es posible, con un objetivo. La capacidad de liderazgo debe estar presente para que esto ocurra, como ya dije y redundo aquí, alguno tiene que "saber algo" (saber cómo ser un buen líder de equipo cuenta como "saber algo").


* Excelente administración de los RR.HH.
Ninguna de las dos anteriores se va a dar - o va a durar poco - si no existe una buena base (o sea esto es "fundamental", en el estricto sentido literal de "fundamental"), laboral. Las retribuciones/sueldos/condiciones de trabajo para la duración del proyecto en el que el equipo va a trabajar tienen que estar de antemano acordadas. Eso incluye sueldo, horario, vacaciones ("esto" de las vacaciones es MUY importante para los empleados por cierto, más que los aumentos de sueldo típicamente), aumentos de sueldo y su criterio exacto (el por qué y cómo van a conseguir aumentos de sueldo, y no olvidarse de la inflación), objetivos laborales a cumplir, un buen manejo de los cambios en la relación laboral(recordemos que los cambios en la relación laboral deben ser de común acuerdo), por ejemplo, si le agregan responsabilidades a un miembro del equipo, hay que preguntarle primero y luego proponer un ajuste apropiado en la retribución, etc. Básicamente, debe haber no una buena, sino una excelente administración de los 
RR.HH.

Un ejemplo negativo: si la empresa/organización le da más responsabilidades a un miembro del equipo, unilateralmente (y se tiene que quedar más horas a laburar, o peor), y aparte no le mejoran la retribución. ¿Qué es lo más probable que haga ese miembro del equipo? 

"That's Why" dicen los americanos para estos casos, "Ese es el por qué", en jerga local sería "Aaaah, por eso era". Por eso hablo de necesitar "excelente administración".

Sin ese nivel de excelente administración de los RR.HH. (para con el equipo), la inversión de la organización, corre un altísimo riesgo de perderse y/o malograrse. Olvídense de que el equipo tenga éxito a corto plazo, lo contrario es más probable que ocurra (y si no se corrije, ese mal desempeño persiste a mediano y largo plazo).

Recordemos que los individuos tienen una flexibilidad de acción mucho mayor que las organizaciones (un tipo renuncia y a los dos días/dos meses ya está laburando en otro lugar), una organización pierde un miembro de equipo con dos años de experiencia y training, y lo recupera a duras penas, con un alto costo económico en gral. (el nuevo miembro de equipo típicamente "le sale" más caro, por simple actualización por inflación y de sueldo promedio de mercado, que es bastante mayor que los aumentos anuales típicos), y se pierde todo el expertise especializado en la organización que tenía el miembro de equipo saliente. Si la organización no dispone de los medios económicos para solventar la diferencia de precio en el costeo del recurso (el nuevo empleado), no se recupera el recurso perdido hasta tener la plata (así de simple suele ser).

El soft libre de infraestructura como producto/servicio en Corrientes

Estas son un par de ideas que tengo en mente, las comparto aquí.

Preguntas, respuestas, dudas, críticas, todas bienvenidas.


Soft comercial de infraestructura

- El software comercial de nivel industrial requerido para hacer funcionar una infraestructura es en la mayoría de los casos demasiado caro de pagar para la mayoría de las empresas y organizaciones en la ciudad de Corrientes.

- La cantidad potencial de clientes para el software comercial de infraestructura es muy baja.

- Las ganancias potenciales se dan en grandes ventas con altos márgenes de ganancias, necesariamente a grandes clientes locales. La dificultad consiste en que serían grandes empresas y organizaciones en Corrientes, que no son muchas.

- Las futuras ventas por actualizaciones luego de que algun cliente efectivamente compre y pague por software comercial de infraestructura van a ser bajas, ya que para un segundo ciclo de vida del software de infraestructura, y habiendo conocido de primera mano los costos en el primer ciclo de vida, muchos van a intentar optar por software libre para su infraestructura.

- El ahorro en costos de software de infraestructura comercial puede ser inmediatamente volcado a adquirir hardware de infraestructura, que también tiene un costo elevado, pero casi nulas posibilidades prácticas de ser evitado.

- Dada la coyuntura socio-económica a mediano plazo (la que se puede advertir hoy), la cantidad final típica de software comercial de infraestructura a utilizar por empresas y organizaciones en Corrientes va ser en la práctica la mínima indispensable.



Software libre de infraestructura

- La mayoría de las infraestructuras informáticas en Corrientes son tamaño medio o chico, y ello es razón práctica por la cual en la mayoría de los casos no van a necesitar implementar software comercial de infraestructura, más allá de que puedan ofrecer - algunas - más y mejores capacidades técnicas que una alternativa basada en software libre.

- Los "kick-points" (para "echar" o "desbancar" las opciones de software libre), para venta de software comercial de infraestructura están basados típicamente en la complejidad de la arquitectura de la empresa/organización. Por ejemplo, el que necesite una arquitectura de base de datos basada en replicación multimaster ( http://en.wikipedia.org/wiki/Multi-master_replication ). Dicha complejidad de requerimientos suele estar ausente por completo en infraestructuras de tamaño medio a chico.

- La cantidad potencial de clientes en Corrientes para el software libre de infraestructura es alta.

- Las ganancias potenciales se dan en ventas chicas, con bajos márgenes de ganancias, a un elevado número de clientes locales. La dificultad consiste en que por el tamaño de la operación, se debe automatizar al máximo los deployments y esquematizar las arquitecturas de modo de evitar tener que dar soporte a arquitecturas excesivamente customizadas (que van a demandar más horas/hombre de mantenimiento).

- Cualquier precio de venta de software libre se constituye en un 100% de ingreso para quien lo vende, no pierde dinero en costos a pagar a proveedores de ese soft (por licenciamiento por ejemplo).

- La implementación de software libre de infraestructura implica en gral. que el componente de capacitación queda a cargo del vendedor, el precio de esta capacitación también es un 100% de ingreso para el vendedor.

- Similar noción a las anteriores se aplica a cualquier soporte pago extra fuera del contrato por la venta inicial.

- El favorable esquema probable de precios configurado por los tres factores anteriores se contrasta con los típicos altos costos de software comercial de infraestructura dados en gral. por casi ilimitadas capacidades técnicas que pocos usan (mucho menos las infraestructuras chicas), un esquema de soporte internacional de poco uso en la práctica (fácilmente superable con un esquema local de soporte, onsite, en persona), etc. La coyuntura permite permite precios elevados para la software libre de infraestructura, con buenos márgenes de ganancias (y sustento eficaz para los costos operacionales de la empresa vendedora), y que aún así tienen el potencial de ser mucho menores que los costos de ofertas de software comercial de infraestructura comparables.

- La cantidad actual de software libre de infraestructura, el ámbito técnico que abarcan, el nivel de calidad de los desarrollos y su madurez; se configuran en que un proveedor de software libre de infraestructura dispone en la práctica de un "supermercado" de software, de cero costo de licenciamiento, del cual puede elegir cual software va a ofrecer en una solución, cuales software va a ensamblar como un producto, e inclusive tener amplias perspectivas de crecimiento para sus productos/servicios, si hiciera falta, para lo cual simplemente va a añadir más software del "supermercado" a su cartera de soluciones.

- Un plus presente en el software libre es la capacidad de customizarlo a un nivel muy alto, permitiendo que software "enlatado" pueda ser modificado de modo de ofrecer capacidades iguales a los que puede ofrecer un desarrollo a medida, pero reemplazando la necesidad de tiempo de desarrollo, por tiempo de customización de la solución (que es mucho menor en gral. y en comparación). 

Permite reemplazar un equipo completo de desarrollo por un analista (que va a trabajar sobre organizaciones muy simples y poco demandantes de capacidades del software en gral.), y alguien - que puede no ser un programador siquiera - que entienda cómo modificar el código para cargar componentes necesarios para la organización, y customizar la apariencia de la aplicación.

Ejemplos:

* Cloud Computing y Virtualización

"10 open source projects that power the cloud"
http://www.computerworlduk.com/slideshow/cloud-computing/3406332/10-open-source-projects-that-power-cloud/


* CRM

"The Top 10 Open-Source CRM Solutions"
http://www.insidecrm.com/articles/crm-blog/the-top-10-opensource-crm-solutions-53507/


* ERP

"10 Programas ERP Software Libre y gratis para PYMEs"
http://e-global.es/erp/10-programas-erp-software-libre-y-gratis-para-pymes.html


* Business Intelligence

"List of Top Open Source Business Intelligence Solutions"
http://www.softwareforenterprise.us/2009/12/21/list-of-top-open-source-business-intelligence-bi-software-solutions/

"Pentaho rankeado en los top como proveedor Open Source en importante encuesta de usuarios de BI"
http://www.cognus.cl/content/view/795891/Pentaho-rankeado-en-los-top-como-proveedor-Open-Source-en-importante-encuesta-de-usuarios-de-BI.html


- No hay "representaciones exclusivas" de un software libre para ningun proveedor

- Los resellers de soluciones comerciales de infraestructura están impedidos mayormente de convertirse en proveedores de soluciones de infraestructura basadas en software libre, ya que normalmente van a solaparse con sus propias ofertas de software comercial (y además, a los proveedores de soft comercial puede no gustarle la idea y quitarles la representación en la zona).

Etc.Etc. (hay muchas más circunstancias)

Conclusiones

Bueno, como pueden leer arriba, la coyuntura en gral. tiene muy buen perfil para vender software libre de infraestructura en Corrientes. 

No todo es soplar y hacer botellas, hay que desarrollar los productos, delinear la oferta de servicios, entrenar(se) apropiadamente a quienes van a hacer todo el trabajo, etc. etc.

Sin embargo las ideas de arriba me llevan a preguntar.. 


¿Por qué no todo el mundo en Ctes. está vendiendo soft libre de infraestructura ahora mismo?

Deberían.