Evaluación del rendimiento de los desarrolladores: ¿Por qué, qué y cómo?

Sabemos que evaluar de manera objetiva es muy complicado, de hecho una de las reglas básicas es «si no lo puedes medir, no lo puedes evaluar». Para medir hay que parametrizar y para parametrizar hay que definir variables, consiguiendo dos objetivos imprescindibles: fiabilidad y validez.

 

 

Si trasladamos esa complejidad al ámbito profesional y más concretamente a la evaluación del rendimiento de los profesionales, nos metemos en temas que generan mucha controversia.

 

Las llamadas evaluaciones de desempeño o revisiones anuales provocan mucho descontento no sólo entre los evaluados también entre los evaluadores, fundamentalmente por un motivo: la toma de decisiones en el qué, cómo, quién y cuándo evaluar no suele ser percibida como la más adecuada.

 

Explicar la finalidad de las evaluaciones: ¿Por qué evaluar?

 

Si queremos eliminar las malas experiencias que todos hemos vivido en las evaluaciones de rendimiento (o al menos reducirlas), hay que empezar explicando a los profesionales por qué es necesario evaluar.

 

Si hacemos de las evaluaciones una herramienta impuesta, lo único que se consigue es malos entendidos, y generar la opinión generalizada de que no sirven para nada más que para cumplir con las burocracias y decirnos si subirnos o no, el salario.

 

Las evaluaciones de rendimiento (bien hechas) son una herramienta valiosísima tanto para el desarrollador como para la empresa. Por un lado, permiten que mejorar como profesionales, y por otro, saber si la organización va en la dirección establecida o por el contrario, necesita realizar cambios.

 

Definir las competencias, funciones y objetivos del desarrollador: ¿Qué evaluar?

 

Hay competencias que serán generalizables a cualquier profesión y a cualquier puesto de trabajo, pero otras son específicas.

 

¿Qué cualidades te convierten en un buen programador? Es impresionante la variedad de respuestas: gusto, vocación, hacer todo lo que te diga la empresa, saber lo que se hace y cómo funciona el código, imaginación, ilusión, práctica, constancia, creatividad, hacer lo mismo en el menor tiempo y que quede bonito para vender, pereza-impaciencia-hibris, ocioso, orgulloso, inquieto, la capacidad de resolver problemas, el que se relaja y disfruta programando fuera de su trabajo, pasión, hambre de conocimiento, entender que el código debe escribirse de forma sea comprensible por otros programadores y sea fácil de mantener, observador, analítico, capacidad para adaptarse, capacidad para buscar soluciones en situaciones dispares, paciencia, autodidacta, entender problemas y estimar su complejidad, compartir el código con los demás, estructurar el código, concisión, resolutividad, eficiencia, no desanimarse con las caídas o los errores, aprender de los errores, pensar, los genes, curiosidad, foco, humildad, buscar siempre la manera de automatizar las cosas, profundo conocimiento de la teoría de lenguajes de programación y saber aplicarlos, etc … y la lista podría ser interminable si siguiéramos preguntando a más desarrolladores.

 

Hay que distinguir entre las Soft Skills y las Hard Skills. La mayoría de las respuestas hablan de competencias soft, es decir esas habilidades más relacionadas con la actitud, la personalidad y el comportamiento. En cambio las competencias hard están relacionadas con los conocimientos y la experiencia técnica que se tienen como desarrolladores, y que por tanto, son propias de su especialidad.

 

Ya hemos dejado claro la importancia de las competencias, pero no es lo único que se deben tener en cuenta en las evaluaciones de rendimiento, las funciones y los objetivos son imprescindibles para darle sentido.

 

El diseño del método de evaluación de rendimiento suele ser una especialidad de RRHH, pero no debería ser exclusiva de ese área o/y dirección, sino también del equipo técnico.

 

Demostrar que se puede medir: ¿Cómo evaluar?

 

Sabemos que trabajar como desarrollador es una profesión creativa e intelectual, y por tanto son complicadas de evaluar. Pero ya hemos visto en vuestras respuestas que sí somos capaces de distinguir a los buenos y no tan buenos desarrolladores es porque si se puede evaluar, el problema es que no nos hemos puesto a analizarlo y parametrizarlo objetivamente.

 

Sabiendo lo que queremos medir, ahora viene uno de los mayores quebraderos de cabeza no sólo en las evaluaciones de rendimiento, también en los procesos de selección, el ¿Cómo?.

 

Algunos reclutadores/evaluadores suelen mirar el Github porque es una manera visible y accesible de conocer a priori esa inquietud e incluso conocimientos, pero como bien dicen los comentarios debatidos en el foro de meetup: Github no es tu CV. Todos conocemos muchísimos desarrolladores que no les gusta darse visibilidad o simplemente utilizan repositorios de código privados y tienen pasión por su trabajo. Así que cuidado con afirmar que si no estás en Github no tienes pasión por programar y más cuidado aún con afirmar que sólo los buenos están en Github. Github pues ser un buen indicador para evaluar la pasión y vocación por programar, pero no el único.

 

 

 

 

 

 

 

 

Fuente: http://www.genbetadev.com/