Hace unas semanas hablamos brevemente de las evaluaciones del rendimiento de los desarrolladores: Por qué, qué y cómo. Ahora nos toca hablar de quién y cuándo evaluar.
¿El departamento de RRHH, el jefe del proyecto, el cliente para el que estás trabajando, el chef executive master universe, tus compañeros, tú mismo, un programa informático, uno que (por fin) conoces personalmente cuando llega tu evaluación? Los protagonistas que pueden evaluar nuestro trabajo, pueden ser muchos. Y si bien pueden emplearse muchas de estas fuentes para recopilar información, antes de elegir el método de evaluación deben seleccionarse y estudiarse cada una de ellas.
La información desde distintas perspectivas: ¿Quién evaluar?
Como comenté en el post de no se encuentra talento técnico en España, categorizar a los profesionales y dirigir su motivación hacia la consecución de subir un peldaño en el organigrama, genera más problemas que beneficios. Si a esto, le añadimos que el evaluador sea del departamento de RRHH o/y los jefes de proyecto, la controversia está servida. Los motivos generales del por qué se nos critica tanto, es porque se nos percibe como poco (nada) cualificados para evaluar el trabajo de un desarrollador y además, más interesados en defender los intereses de la empresa (jefes) que el de los empleados.
La dicotomía de “ellos” y “nosotros” siempre ha existido, por eso en muchos modelos de evaluación se han introducido cambios. Hace unos 3 años, leía sobre el programa de reconocimiento de los kudos. Consiste en una evaluación horizontal en la que los propios compañeros, premian el trabajo bien hecho. Idea estupenda en cuanto a intención, pero insuficiente para hacer una buena evaluación global del rendimiento.
Si queremos que a los desarrolladores se les evalúe objetivamente pero de manera personalizada, y la empresa quiere dar ese trato y saber el valor que aporta cada uno de sus desarrolladores, lo mejor es utilizar más de una fuente información; ya sean kudos, RRHH, jefes, clientes o uno mismo.
No hay mejor forma de hacer una evaluación objetiva que consiguiendo información desde diferentes perspectivas, por eso cada vez más se busca una evaluación 360 grados. Este tipo de evaluaciones, permite ayudar a mejorar profesionalmente al desarrollador y por supuesto, mejorar los resultados de la empresa. Pero como cualquier método de evaluación, tiene ventajas y desventajas a tener en cuenta:
| Ventajas | Desventajas |
|---|---|
| Se recopila y se contrasta información de distintas perspectivas | Combinar y analizar todas las respuestas es complejo |
| Cantidad y calidad de información | El feedback que aporta al evaluado puede hacerle sentir incómodo |
| Menos sesgos, prejuicios, información más objetiva porque la retroalimentación es de más de una persona. | Conflicto de opiniones y perspectivas |
| La retroalimentación de los compañeros, incentiva el desarrollo del empleado. | Para que funcione correctamente, requiere involucrar a muchas de las partes y formarles en este ejercicio. |
La evaluación es un proceso continuo: ¿Cuándo evaluar?
Ya hemos dicho que lo primero que debe de hacerse es definir los puestos de trabajo, funciones, competencias y cualquier aspecto que se va a evaluar, involucrando desde el principio al desarrollador. Si hablamos de cuándo, creo que es un error esperar un año para hablar por primera vez con quién/quienes nos evalúan.
Las evaluaciones inoportunas, suelen ser contraducentes porque generan frustración e insatisfacción en el desarrollador,no recogen el esfuerzo que se ha realizado durante todo un año y no menos importante, se pierde información muy valiosa por el camino.
Si hiciéramos las evaluaciones de rendimiento usando sprints, no sería necesario esperar un año para saber si vamos en la dirección correcta. Las metodologías ágiles pueden facilitar ese seguimiento continuo del profesional (y del equipo). Demuestran que no es necesario esperar un año para saber si se está haciendo un buen trabajo y no menos importante, si las expectativas puesta en cada uno, se están cumpliendo.
Si hemos realizado iteraciones de 2 a 4 semanas, no habrá sorpresas en la evaluación anual. Además, podremos emplear esa fecha anual para hacer una retrospectiva. Puede ser un buen momento para hablar con tranquilidad de cómo ha ido el año, previsiones del siguiente, conocerse mejor, solventar las posibles barreras, detectar mejoras, y asentar una buena base de confianza tanto de manera individual como en equipo. En definitiva, mejorar la calidad del trabajo de los que participan e introducir mejoras para la empresa.
Conclusión
Evaluaciones 360º, metodologías ágiles y muchos otros procedimientos pueden ser muy útiles a la hora de evaluar, pero por muchos formalismos que queramos implantar, siempre debe existir un espacio para la espontaneidad.
El seguimiento de los profesionales debe ser una prioridad en las empresas. Creo que el éxito en cualquier relación, está en cuidar los pequeños detalles que forman parte de nuestro día a día y no esperar al año por compromiso.
