6 min read
Recibís este mensaje en Slack un martes a las 9:03am: “Hola”. Nada más.
Sabés que la persona quiere algo, pero no qué. Le respondés “Hola, ¿qué necesitás?” y esperás.
Veinte minutos después llega: “¿Podés mirar el tema del servicio de pagos?”. Nueva pregunta tuya: “¿Qué tema?”.
Pasa otra media hora. Cuando por fin entendés que había un error 500 en staging, ya perdiste una hora entera en un intercambio que se resolvía con un solo mensaje bien escrito.
En equipos distribuidos, o simplemente con horarios distintos, la comunicación asíncrona (la que no requiere que ambas personas estén disponibles al mismo tiempo) es la base de la productividad.
Y la habilidad central de la comunicación asíncrona es una sola: escribir mensajes que se puedan entender y accionar sin una conversación de ida y vuelta.
Principio 1: poné la conclusión primero (BLUF)
BLUF significa Bottom Line Up Front (la conclusión por delante). Empezá por lo que necesitás o lo que decidiste, y después da el contexto.
Quien lee decide en las primeras líneas si le toca actuar.
Antes: “Estuve revisando los logs de ayer y vi que a partir de las 18:00 hubo varios errores en el servicio de pagos, creo que puede ser por el cambio de la pasarela, hablé con Pedro y me dijo que…”
Después: “Necesito tu aprobación para hacer rollback del cambio de pasarela de pagos (PR #482). Desde las 18:00 hay 3% de errores en cobros. Detalles abajo.”
Principio 2: mensajes completos, no “Hola”
Un mensaje completo contesta de antemano las preguntas obvias: qué pasa, dónde, desde cuándo, qué ya probaste, qué necesitás y para cuándo.
Incluí enlaces, no descripciones (“mirá el PR #482” en lugar de “el PR de ayer”). Es más trabajo para quien escribe, pero ahorra tiempo a quien lee, multiplicado por todas las veces que se lee.
Principio 3: elegí el canal adecuado
| Situación | Canal |
|---|---|
| Algo urgente que bloquea a alguien | Mensaje directo o llamada |
| Pregunta rápida, la respuesta no se necesita guardar | Chat (Slack, Teams) |
| Decisión técnica o diseño que se va a consultar después | Documento escrito (ADR — Architecture Decision Record, o un documento de diseño) |
| Discusión sobre un cambio de código | Comentarios del Pull Request |
| Tema delicado o con carga emocional | Conversación en vivo (el texto pierde el tono) |
La regla práctica: si la información va a ser útil dentro de tres meses, no debería vivir en un hilo de chat que nadie va a encontrar.
Principio 4: la descripción de un Pull Request es comunicación asíncrona pura
Un PR (Pull Request — solicitud de integración de cambios) es probablemente el mensaje asíncrono más importante que escribe un desarrollador.
Quien lo revisa no estaba cuando escribiste el código y no puede preguntarte en el momento. Una buena descripción responde:
## ¿Qué cambia?
Resumen en una o dos frases.
## ¿Por qué?
El problema o el requerimiento que motiva el cambio (enlace al ticket).
## ¿Cómo lo probé?
Pruebas automáticas, pruebas manuales, capturas si hay interfaz.
## Riesgos y puntos de atención
Qué debería mirar con más cuidado quien revise.
Qué podría romperse y cómo se revierte.
La IA ya puede escribir la descripción de tus PRs, pero vos tenés que revisarla
Hoy las herramientas de inteligencia artificial pueden generar la descripción de un Pull Request leyendo los cambios del código.
Para el 80% mecánico del trabajo, resumir qué archivos cambiaron y qué hace cada cambio, es un ahorro real de tiempo y suele producir un buen borrador.
Pero un borrador no es una descripción final. Toda descripción generada con IA debe ser revisada por una persona antes de enviar el PR a revisión. El factor humano sigue siendo clave por razones concretas:
- La IA ve el “qué”, no siempre el “por qué”: puede describir que cambiaste un timeout de 5 a 30 segundos, pero no sabe que fue porque un proveedor externo se volvió más lento en horario pico. El contexto de negocio lo aportás vos.
- Puede afirmar cosas que el código no hace: los resúmenes automáticos a veces describen la intención aparente y no el comportamiento real, o mencionan una prueba que nunca se escribió. Si la descripción dice “agrega validación de montos negativos”, verificá que el código efectivamente lo haga.
- No conoce los riesgos de tu sistema: no sabe que ese endpoint lo usa un cliente grande, ni que ese cambio requiere una migración previa en producción.
- Pierde lo que no está en el diff: decisiones descartadas, alternativas evaluadas, la conversación previa con el equipo.
- Quien envía el PR es responsable de lo que dice: si la descripción es incorrecta y alguien aprueba confiando en ella, el error es tuyo, no de la herramienta.
Checklist antes de enviar un PR cuya descripción generó una IA:
- ¿Explica el porqué del cambio, no solo el qué?
- ¿Cada afirmación coincide con lo que realmente hace el código?
- ¿Indica cómo se probó, y esas pruebas existen de verdad?
- ¿Menciona el alcance real (y lo que queda fuera)?
- ¿Señala los riesgos y cómo se revierte?
- ¿No incluye datos sensibles (credenciales, datos de clientes, URLs internas)?
- ¿Tiene los enlaces al ticket y a la documentación relevante?
Usá la IA como el compañero que te prepara el primer borrador, y asumí vos el rol de editor responsable. El tiempo que ahorrás escribiendo lo reinvertís en revisar bien.
Guía paso a paso para mejorar tus mensajes esta semana
Paso 1 — Antes de enviar, preguntate: “¿Esta persona podría actuar solo con lo que escribí?”
Paso 2 — Poné la petición o la conclusión en la primera línea.
Paso 3 — Agregá contexto con enlaces, no con referencias vagas.
Paso 4 — Indicá qué necesitás y para cuándo, con fecha y hora si es posible.
Paso 5 — Elegí el canal según la durabilidad de la información.
Conclusión
Escribir bien es una forma de respeto por el tiempo de los demás, y en equipos modernos es una de las habilidades que más diferencian a un desarrollador de nivel medio de uno senior.
Las herramientas de IA pueden acelerar el borrador, pero el criterio de qué incluir, qué verificar y qué responsabilidad asumir sigue siendo humano.
Recordá suscribirte aquí para recibir los próximos posts directamente en tu correo.
Referencias:
GitLab Handbook — Communication: https://handbook.gitlab.com/handbook/company/culture/all-remote/effective-communication/
Remote: Office Not Required — Jason Fried y David Heinemeier Hansson