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 solo 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.
Analizando muchas de vuestras respuestas a la pregunta ¿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.
Como bien hace alusión uno de los comentarios, 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 tenéis como
desarrolladores, y que por tanto, son propias de vuestra 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?.
Siguiendo en la línea de vuestras respuestas. He considerado
seleccionar como una de las principales competencias soft del trabajo
como desarrollador: la pasión y vocación por programar ¿Cómo podríamos
medirlo? Un buen indicador es la dedicación de vuestro tiempo libre a
programar.
Algunos reclutadores/evaluadores solemos 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.
Más adelante hablaremos de ¿Quién y cuándo evaluar?, pero antes me
encantaría conocer vuestras opiniones sobre las evaluaciones de
rendimiento/desempeño.
