Entregar y recibir feedback de calidad
Tags: spanish
Published: 2024-01-12 14:45:59


> “La clave para aprender es la retroalimentación. Es casi imposible aprender algo sin ella”. <br>Steven Levitt.

Segundo post y hoy hablaré un poco acerca de cómo entregar y recibir feedback o retroalimentación de calidad y de forma positiva. Este post resumirá algunos aspectos claves de cómo ejercitar correctamente nuestra forma de comunicación más usual que poseemos a la hora de corregir tareas.

De por sí, el feedback es una herramienta esencial para el desarrollo personal y profesional, pero **¿cómo podemos dar y recibir retroalimentación en forma efectiva y de calidad?**

## ¿Qué es una retroalimentación y porqué es importante?
La retroalimentación es una parte esencial, no solo del desarrollo de software, sino también de la vida en general. Es el **mecanismo con el cual recibimos una confirmación de que nuestras acciones o pensamientos están bien realizados o son necesarias correcciones**.

Cuando hablamos de desarrollo de software, tendemos a pensar que es exclusiva cuando realizamos un **Pull Request** (o **Merge Request** o **mergear** el código) y esperamos que una persona nos confirme que el código está bien. Sin embargo, también hay otros momentos donde aparecen las retroalimentaciones, como en la toma de requerimientos o en los resultados de las pruebas.

Por ejemplo, en la toma de requerimientos, es importante que los desarrolladores reciban retroalimentación de los usuarios para comprender sus necesidades y expectativas. En los resultados de las pruebas, es importante que los desarrolladores reciban retroalimentación de los testers para identificar y corregir errores.

Las retroalimentaciones son importantes porque **nos permiten confirmar que las decisiones y cambios que estamos haciendo están en el camino correcto o debemos enmendar el curso** para poder satisfacer las necesidades de nuestros usuarios. Este paso es necesario, ya que nuestro análisis podría haber dado 5 tareas y pensar que tenemos las 5 tareas listas, pero en realidad 1 ha presentado errores, por lo cual se hace necesario **escuchar el problema y presentar un cambio para solucionarlo**.

Entonces, si es algo que nos permite mejorar, _¿por qué debemos ejercitar una cultura de retroalimentación constructiva?_

## La retroalimentación te cambia la vida... en todo sentido
Las **palabras tienen el poder suficiente para crear realidades**, no imaginemos como los encantamientos de Harry Potter, pero sí poseen la capacidad de cambiar el comportamiento de las personas en función de las palabras y el tono en que se usen para poder entregar un mensaje o una retroalimentación.

Es posible que sientas que tu trabajo es bastante completo y prolijo, pero a la hora de la revisión es posible que no esté perfecto, quizás solo bien, pero a los ojos del revisor, que en ocasiones puede ser implacable, está **todo mal** y **nada funciona**. Por lo cual, se hace necesario que ante esta negativa podamos hacer un cambio positivo en la vida de la persona que está solicitando la revisión.

No está demás recordar que, al igual que el arte, la informática tiene una componente creacionista bastante grande, por lo cual en ocasiones, alterar el producto original podría desembocar en una serie de emociones y sentimientos negativos desde la persona que solicita la revisión. El **famoso ego trastocado** que se manifiesta.

Por tanto, la retroalimentación puede producir un cambio en la vida de la persona revisada, ya que en función de lo indicado como comentarios o sugerencias, **la persona tendrá un cambio de comportamiento en relación** a la parte previa de la revisión. Puede ser una persona que **acepte, negocie o niegue los cambios propuestos**, ya que su ego se ve afectado tanto por no haber entendido el problema como por el hecho de que su obra está siendo modificada.

## Demos retroalimentación constructiva
Una **retroalimentación constructiva** es una conversación o mensajes que nos permiten indicar de manera **abierta, honesta, específica y respetuosa** los puntos de mejora o corrección sugeridos, siempre recordando que se revisan acciones realizadas o decisiones tomadas, y que no es un proceso para criticar o hacer sentir mal a la persona que solicita la revisión.

Antes de comenzar una retroalimentación, y habiendo revisado el trabajo entregado, debemos pensar qué queremos decir:

* ¿Qué puedo destacar del trabajo?
* ¿Qué funcionó bien y qué sugerencias de correcciones puedo dejar?
* ¿Son relevantes las sugerencias o simplemente es ser quisquilloso o quisquillosa?

Estas preguntas nos permiten identificar qué queremos comunicar, idealmente en positivo, a la persona a la que tenemos que entregar su retroalimentación.

Cuando ya tengas listos tus comentarios, te sugiero **elegir un momento ideal para hacerlo** (no, 5 minutos antes de terminar la jornada no es un buen momento), donde se pueda generar un espacio de tiempo necesario y de calidad donde se pueda propiciar una conversación. En cambio, si es un comentario escrito, evalúa enviarlo durante la jornada laboral, quizás a media mañana o tras el almuerzo, para que la persona sienta la oportunidad de leerlo tranquilamente.

Para estructurar tu mensaje, la invitación es a **comenzar con lo positivo** que se ha revisado, lo que resultó de la revisión y qué cosas nos sorprendieron de lo realizado ("una buena implementación del algoritmo", "no sabía que se podía hacer con Y y funcionó de maravillas").

A la hora de comenzar a apuntar a los aspectos que no funcionaron o negativos, en lugar de solo indicarlos, también es tu **deber y responsabilidad con la otra persona de dar espacios y sugerencias de mejoras** en tonos constructivos, centrándote en aspectos laborales y no en cómo es la persona ("creo que la forma en que lo abordaste podría funcionar en otros contextos, pero acá te conviene seguir Z... si no sabes cómo hacerlo, puedo contactar con Y para que dé algunos consejos").

Al finalizar, **establece una pauta o una guía** que nos permita saber que las recomendaciones serán realizadas, por ejemplo, anotar los compromisos adquiridos, las mejoras propuestas y ponerse de acuerdo de cuándo volver a evaluar si los nuevos cambios funcionaron o no.

## Recibamos retroalimentación
Sí, **la informática puede lastimar el ego**. Desde ese PR que es rechazado por ser incompleto hasta requerimientos mal implementados porque no entendimos al cliente. Si no te gusta sentir tu ego lastimado, creo que la carrera no es para ti.

Ya que subiste ese PR y ves el comentario de "No, tu código no será fusionado", siempre **debemos estar dispuestos a escuchar los motivos del rechazo** o lo negativo que hemos hecho. Debemos practicar la **escucha activa**, o con atención, de lo que nos dicen. En ocasiones nuestro cerebro se cierra a que "yo tengo la razón", pero por lo general esa falta de empatía y capacidad de escuchar por la negación hace que la frustración salga a flote. Por tanto, cuando veas la cruz roja o el momento de escuchar lo negativo, intenta no cerrar tu mente. Es todo lo contrario, es abrirla para entender qué podemos hacer mejor.

> _No entendí eso de chequear los enteros_

Si **tienes una duda, no te quedes con la pregunta, ¡haz la pregunta!** La retroalimentación **es útil si tú también puedes entender lo que te están diciendo**. Es mejor pecar por preguntar que pecar por ignorancia. Además, es gratis y es una conversación o una comunicación que te está ayudando a ser una mejor persona o un mejor trabajador. No son solo palabras al viento "por que sí". Es la **instancia donde pueden compartir conocimiento, experiencia y hablar de código**. Ambos están ahí porque les llama la atención, les gusta o son personas buenas para programar. No desperdicies tu oportunidad.

Por último, considera estas dos cosas:

* No es un proceso de evaluación de cómo eres como persona. Siempre hablamos del trabajo.
* Es posible que seamos desordenados para programar, pero a la hora de presentar nuestro trabajo debemos ser lo más pulcros posible, para que la evaluación se centre en lo que hicimos y no sea un juicio de valor de nuestro ser o creencias y vivencias.

Las retroalimentaciones son procesos de aprendizaje y conversación, por lo cual no "hay que tomarse todo a pecho". Hay que meditar lo que nos han dicho.

* "_tu código es desordenado_", podemos consultar cómo ordenarlo
* "_no es la solución que esperaba_", ¿me ayudas a saber cómo la harías?"

## Seamos agradecidos del proceso
Quienes brindan retroalimentación **deben practicar constantemente la compasión, el entendimiento y la reflexión activa** sobre cómo comunicar lo bueno, lo malo y lo mejorable de algo. Por su parte, quienes la reciben deben considerar **practicar la paciencia, la comprensión y adoptar la actitud de mejora continua**.

Este proceso no nace ni está enraizado en nuestra labor porque debe existir, sino que debemos verlo como un espacio de aprendizaje conjunto, en el que ambas partes ganan.

## Resumen (por Bard)
Para dar retroalimentación de calidad, debemos:

* Centrarnos en el trabajo, no en la persona.
* Ser específicos y concretos en nuestros comentarios.
* Ofrecer sugerencias de mejora.
* Elegir un momento y lugar apropiados para dar la retroalimentación.

Para recibir retroalimentación de calidad, debemos:

* Estar abiertos a escuchar comentarios negativos.
* Hacer preguntas para aclarar lo que no entendemos.
* No tomarnos los comentarios a pecho.

## Consejos concretos
* No abuses de la posición de dominancia o experiencia a la hora de dar feedback
* Siempre hay algo positivo qué destacar, ¡recuérdalo!
* Recuerda que en ese código o análisis hay tiempo invertido, ¡no lo desperdicies ni lo menoscabes!
* Todos fuimos juniors o aprendices un día, ¡sé un buen guía a quien está comenzando!
* Anota en columnas las cosas buenas, malas, mejorables y lo que no entendiste. Añade un pequeño espacio para acciones concretas que tomarás como retroalimentador (hacer que lea X o hablar con Y para que lo guíe).

## Notas
[1] Imagina cuántas veces se acuerdan de nuestras familias cuando "fallan los sistemas"... aunque la culpa no es del sistema informático<br>
[2] Obviamente si no estás pagando un servicio de QA o coaching.<br>
[3] Aprendemos a la fuerza, pero en general no existen los linters cuando iniciamos nuestro camino... después aparecen los linters y otras lindas herramientas, pero al principio muchos creen que "estamos hackeando Facebook con una lata de Monster"

_Imagen por deepai.org al poner el título como prompt_