La importancia del feedback

En el post anterior estuvimos Creando nuestro primer microservicio dentro de la sección de Uso avanzado de Docker. Esta vez no voy a hablar de un tema puramente técnico, sino de la importancia del feedback y cuan importante es saber pedirlo como lo es saber darlo.

Antecedentes

Hace unos años estuve involucrado en un proceso de selección para una empresa situada en Malta cuya principal actividad era la de crear herramientas de formación en el ámbito deportivo. Éste es un sector que no he explorado aún y, por lo tanto, me llamaba la atención desarrollar plataformas de e-learning e iniciarme en el sector deportivo.

Una vez superada la primera criba con una videoconferencia en inglés con el Project Manager (PM), quién me presentó la empresa, su actividad, por qué están ubicados en Malta, cómo está estructurada y su modos de trabajo. La segunda parte de la charla fue para analizar mi experiencia profesional y conocimientos, expectativas, etc. Fue una charla bastante entretenida y agradable, todo sea dicho.

Como la primera impresión fue buena por ambas partes me solicitó que hiciera una prueba técnica para que su equipo pudiera valorar la calidad del código, el modo en que abordo un determinado problema, etc. Nada del otro mundo, pues nuestro sector ha normalizado este tipo de prácticas aunque me parezcan parciales y tendenciosas en su mayoría de casos. Además de parecerme muy injustas pues no son aplicables a todos los ámbitos.

Cuando voy al dentista, por ejemplo, no le pido una prueba técnica para evaluar su expeciencia y conocimientos de la materia antes de que me resuelva un problema. ¿Por qué entonces en nuestro sector hemos normalizado el que nos soliciten pruebas técnicas? ¿Acaso no existen los periodos de prueba en los contratos?

Este melón lo abriremos en otro momento.

La prueba técnica

Al recibir dicha prueba me sorprendió -gratamente- que estuviera enfocada a cubrir una necesidad tangible, real. Estaba bien descrita, sin ambigüedades ni aspectos supérfluos. Tenía unas horas para realizar dicha prueba y para entregarla debía publicarla en Github y dar permisos de lectura a dicho repositorio para que el PM pudiera evaluarla.

La prueba la hice en cuestión de un par de horas, tanto la prueba en sí como la cobertura de código. Además de un documento Markdown donde describía la prueba, qué tipos de tests se habían implementado, cómo ejecutarlos, qué aspectos me hubiera gustado completar, etc.

Hasta aquí todo parecía ir sobre ruedas: la comunicación tanto por email como por Telegram era buena y fluída.

A la espera del feedback

Una vez el código estaba en el repositorio y el PM ya tenía acceso al mismo le mando un email para confirmar dicha entrega y que supiera cuándo completé la prueba. Una hora después veo que el PM accede al repositorio y al código... así que asumí que en cuestión de horas, o unos días, tendría un feedback inicial.

Cual fue mi sorpresa que a partir de ese mismo momento la comunicación pasó a ser inexistente: ni un mensaje de confirmación de recepción de la prueba, ni un mensaje... nada. Pasaron los días y no recibía información sobre la prueba. Pasadas varias semanas y varios emails sin contestar por su parte, decido hacer el repositorio privado y eliminar las cuentas de acceso al mismo; asumiendo así que, por el motivo que fuera, había sido descartado.

Horas después de haber restringido el acceso a dicho repositorio recibo un mensaje del PM preguntándome que por qué había eliminado su acceso. Me sorprendió bastante no sólo esta pregunta, sino el tono de comunicación. Le comenté que no me parecía correcta la manera en que se había desarrollado la comunicación después de la entrega de mi prueba.

En vez de explicarme los porqués de ese cambio de comunicación y de por qué necesitaba más tiempo para evaluar la prueba, quería tener el acceso al código cuanto antes. Ahí caí en que la prueba técnica no tenía sólo valor de prueba, sino que además era la solución a un problema real que tenía la empresa y querían el código para poder incluirlo en producción lo antes posible.

Esta es otra de las razones por las que no estoy a favor de las pruebas técnicas o de los Hackathon, ya que muchas empresas recurren a solicitudes de contratación o eventos de este tipo para que les trabajen gratis.

El PM al ser consciente de que me había dado cuenta de todo esto cambió su tono.

El feedback

Posteriormente recibí un feedback por llamarlo así, donde en resumidas cuentas decía que finalmente él y su equipo me habían descartado porque:

• Una consulta SQL no era la versión más óptima.
  • Este aspecto era consciente de ello y por eso lo dejé comentado en el Markdown adjunto, donde además explicaba cómo mejorarla.
• Tenía un estilo propio de enfocar el desarrollo (WTF!)
• Que mi experiencia previa como Team Lead podría crear conflictos en el equipo (WTF!)

Sobra decir que, en este caso la calidad del feedback fue nula y que lo que más me molestó de todo esto, además de haber perdido mi tiempo e ilusiones en algo que no existía, fue ese feedback.

En la actualidad

Recientemente he hecho una prueba técnica en la empresa en la que trabajo; si bien no era una prueba técnica para optar a un puesto determinado, sí era para definir un plan de carrera dentro de la compañía.

En este caso la prueba parecía sencilla, con unos requisitos claros e includo un esqueleto de aplicación basado en Slim framework ya preconfigurado en un contenedor Docker. Dicha prueba requería de implementar un endpoint que obtuviera información de una API de terceros y, con la información obtenida, realizar unas comprobaciones para exponer la respuesta en dicho endpoint.

Una vez la prueba la entregué, en pocos días ya tenía un feedback en mi bandeja de entrada corporativa. Aquí el feedback se entregó a tiempo, siendo mucho más extenso -aunque me supiera insuficiente en algunos aspectos-.

Mi punto de vista

Yo he estado en el otro lado de la mesa realizando selección de perfiles técnicos y, en determinados casos, he solicitado pruebas técnicas. La mayoría de veces porque la persona que aspiraba al puesto no podía demostrar experiencia previa ni código de ejemplo a través de sus repositorios o bien, por el riesgo que suponía dicha contratación para la empresa ya que el candidato residía en otra ubicación.

Imaginaos la situación de un candidato que, tras pasar varias entrevistas con el recruiter de turno. la dirección de Recursos Humanos y con el Project Manager, le envían una oferta interesante para trabajar en las instalaciones de Tegucigalpa. Hace las maletas y después de una mudanza cambiando de pais y de continente, resulta que no puede aportar valor a la empresa por falta de conocimientos o de experiencia en el stack tecnológico con que se trabaja y se ven en un país extraño, sin trabajo y con lo puesto. En estos casos una prueba técnica estaría más que justificada.

Las pruebas técnicas que yo he diseñado siempre han estado enfocadas a cubrir una operativa clásica que la empresa tuviera. Por ejemplo desarrollando una pequeña API que realizara ciertas operaciones y así poder evaluar qué criterios de seguridad se aplica a las requests, el formato escogido, qué herramientas y cabeceras usa, cómo maneja los errores, qué información expone al usuario, cómo interactúa con la base de datos u otro servicio y qué información técnica restringe en caso de errores intencionados, cómo organiza el código, cómo enfocaría una extensión de la misma...

Y una vez recibo la prueba, la reviso y me guardo una valoración inicial. Pero el feedback se lo envío tras su defensa de su prueba técnica, que no es más que una sesión de videoconferencia en el que ambas partes (el candidato y yo) analizamos dicha prueba en vivo y en directo. Me gusta que el candidato me presente por qué la hizo así, qué problemas tuvo, qué aspectos le hubiera gustado cambiar o mejorar... y sólo después de esta sesión yo me siento capaz de dar un feedback medianamente de calidad.

La razón de hacerlo así es que en la mayoría de casos uno envía una prueba y depende única y exclusivamente de la interpretación de otra persona. Durante esa revisión no hay posibilidad de hacer preguntas del tipo "¿y esto por qué lo hiciste así?". No porque estuviera mal, sino por entender los porqués y ser capaz de comprender el modo de pensar de ese candidato. Por contra, en general, esa posibilidad no existe y se asumen ciertas respuestas a dichas preguntas. Y es injusto porque el evaluador no está libre de sesgos.

Para mí una prueba técnica es una herramienta útil tanto para la empresa por razones obvias, pero también lo es para el candidato, pues éste obtiene un feedback implícito de cómo se trabaja en dicha empresa:

• Tal y como se redacta la prueba es como se suelen redactar las tareas internas de la empresa.
• La especificación de los criterios de aceptación de la prueba suelen tener el mismo grado de detalle que una descripción de una incidencia.
• Tal y como se evalúa dicha prueba es como suelen validar las Pull Requests o mezclas de código: si es mediante una sesión de code-review conjunta o una única persona
• El grado de información que te aportan en el feeback suele coincidir con el grado de detalle de comentarios en dichas Pull Requests.

Toda comunicación dentro de la empresa es un feedback contínuo: una serie de peticiones que se solicitan con unas expectativas y luego toca evaluar si esas expectativas se cumplen. Es decir, si las tareas entregadas han sido realizadas teniendo en cuenta los criterios de aceptación.

Es importante saber dar feedback porque es la única manera de comentar aspectos negativos a mejorar, pero también de resaltar aquellos aspectos positivos que pueden ser extensibles o aplicables a otros casos. La calidad del feedback tiene que servir para que la persona que lo reciba pueda evolucionar. Si no se da feedback de calidad, al final lo que se genera es frustración y las personas no somos inmunes a la frustración.

Muchas empresas se han especializado en una parte de esta comunicación, siendo capaces de redactar incidencias con un lenguaje explícitamente efectivo y eficiente, con unas especificaciones detalladas... se han centrado en mejorar el canal y el mensaje; pero pocas han reparado que el emisor y el receptor son personas. Siguen reiterando en subsanar ciertos problemas de comunicación con tecnología, cuando la solución pasa por dar feedback de calidad.

Primeros pasos dando feedback

Dar feedback no tiene que suponer un esfuerzo, basta con empezar con pequeñas acciones que puedan ayudar:

• Cuando pides a un candidato que haga una prueba técnica, agradécelo.
• Cuando asistes a un evento de formación, rellenar una pequeña encuesta de satisfaccion.
• Cuando lees un post que te gusta, dale a like.
• Cuando ves un contenido que puede ser útil para los demás, compártelo.

Cada pequeño gesto cuenta.

Versión del documento

[^v1.0]: Última Modificación: 11/07/2021