Cómo escribir RFCs técnicos que de verdad se leen y conducen a decisiones
Las decisiones técnicas más caras de una organización de ingeniería se toman en hilos de Slack que desaparecen, en reuniones a las que falta la mitad de los implicados o en la cabeza de un ingeniero senior sin que nadie más opine. Seis meses después, cuando la arquitectura empieza a crujir y alguien pregunta «¿por qué lo construimos así?», nadie se acuerda. O peor: cada uno lo recuerda de una forma distinta.
Los RFCs — documentos de Request for Comments — resuelven exactamente este problema. Son una de las herramientas más potentes al alcance de un equipo de ingeniería, y una de las más infrautilizadas. Los he visto transformar la manera en que los equipos deciden, se alinean entre zonas horarias y construyen memoria institucional. También los he visto hacerse mal: novelas de 40 páginas que nadie lee y que lo frenan todo.
Así es como se hacen bien.
Por qué importan los RFCs
Un RFC es una propuesta escrita para una decisión técnica relevante, que se comparte con el equipo para recibir feedback antes de empezar a implementar. Nada más. No es una especificación. No es documentación. Es una propuesta que invita a opinar.
El valor viene de tres cosas:
Obliga a pensar con claridad. Escribir te fuerza a estructurar el razonamiento. Esa idea vaga que parecía brillante en tu cabeza se pone a prueba cuando tienes que explicarla por escrito. He escrito RFCs en los que el propio acto de escribir destapó un fallo fundamental de mi solución que no había visto. De eso se trata: sale mucho más barato encontrar el fallo en un documento que en código de producción.
Alineación asíncrona. En un equipo distribuido en varias zonas horarias, las reuniones síncronas son caras y excluyentes. Siempre hay alguien conectándose a deshoras, siempre falta alguien. Un RFC permite que cada uno aporte su perspectiva en su propio horario. El ingeniero de Buenos Aires y el de Berlín leen el mismo documento y dejan sus comentarios sin tener que buscar 30 minutos de coincidencia.
Memoria institucional. Dentro de seis meses, alguien nuevo en el equipo preguntará por qué el sistema usa event sourcing en lugar de un CRUD tradicional. En vez de tirar de tradición oral («creo que eso lo decidió María, pero se fue en marzo»), le pasas el enlace al RFC-047. El contexto, las alternativas y el razonamiento están ahí. Solo esto ya justifica el coste de escribir RFCs.
La estructura de RFC que funciona
He iterado plantillas de RFC en varios equipos y organizaciones. Esta es la estructura que produce documentos útiles de forma consistente sin convertirse en una carga:
1. Título y metadatos
- Número de RFC y título. La numeración secuencial (RFC-001, RFC-002) facilita las referencias.
- Autor(es) y fecha.
- Estado. Borrador, En revisión, Aceptado, Rechazado, Sustituido.
- Revisores. Nombra a las personas cuya opinión necesitas específicamente.
2. Contexto y planteamiento del problema (1-2 párrafos)
¿Cuál es la situación? ¿Qué problema estamos resolviendo? ¿Por qué ahora? Esta sección sitúa al lector. No des por hecho que tiene el mismo contexto que tú. Enlaza tickets, métricas o incidentes que hagan el problema concreto.
Mal: «Necesitamos mejorar nuestro pipeline de datos.» Bien: «Nuestro pipeline ETL por lotes procesa 2M de registros cada noche. Con nuestra trayectoria de crecimiento, llegaremos a 10M de registros en el T1 de 2024. La arquitectura actual tarda 4 horas en procesar 2M de registros y no escala de forma lineal. El mes pasado tuvimos dos incidentes en los que el job nocturno no terminó antes del horario laboral (INC-234, INC-251).»
3. Solución propuesta (el núcleo del documento)
Describe qué quieres construir, cómo funciona y por qué este enfoque. Incluye:
- Arquitectura o diseño del sistema. Los diagramas ayudan: un esquema simple de cajas y flechas comunica más que cinco párrafos de texto.
- Las decisiones técnicas clave dentro de la propuesta y por qué las tomaste.
- El alcance. Qué entra y, sobre todo, qué queda explícitamente fuera.
4. Alternativas consideradas (sección innegociable)
Enumera al menos dos alternativas que evaluaste y por qué las descartaste. Esta sección cumple tres funciones: demuestra que hiciste el trabajo previo, se adelanta a los comentarios de «¿y por qué no consideraste X?» y documenta el panorama de la decisión para quien lo lea en el futuro.
Si no se te ocurre ninguna alternativa, es que no has pensado lo suficiente en el problema.
5. Riesgos y preguntas abiertas
¿Qué puede salir mal? ¿Qué no tienes claro? ¿Qué suposiciones estás haciendo que podrían fallar? Aquí es donde vive la honestidad intelectual. Una propuesta que afirma tener cero riesgos no transmite confianza: transmite ingenuidad.
6. Plan de implementación
Un calendario aproximado y las fases. No hace falta un plan de proyecto detallado: solo lo justo para demostrar que es viable e identificar dependencias. «Fase 1: migrar la capa de ingesta (2 semanas). Fase 2: migrar la capa de transformación (3 semanas). Fase 3: retirar el pipeline antiguo (1 semana).»
7. Decisión y resultado (se rellena tras la revisión)
¿Qué se decidió? ¿Cuándo? ¿Quién? ¿Hubo modificaciones sobre la propuesta original? Esto cierra el círculo y convierte el RFC de propuesta en registro.
Errores comunes que matan un RFC
Demasiado largo. Si tu RFC pasa de 4 páginas, la mayoría no lo leerá con atención. Lo hojearán, se perderán los matices y o bien lo aprobarán sin mirar o plantearán objeciones que el texto ya responde. Recorta sin piedad. Los detalles de implementación, los esquemas de API y los modelos de datos van a los apéndices.
Demasiado abstracto. «Deberíamos adoptar una arquitectura de microservicios», sin especificar qué servicios, dónde están las fronteras ni cómo se comunican, no es una propuesta: es un deseo. Un RFC tiene que ser lo bastante concreto como para que alguien pueda discrepar de un aspecto específico.
Sin un punto de decisión claro. El RFC debe decirlo explícitamente: «Necesitamos decidir esto antes del [fecha]. Si para entonces no hay objeciones, seguimos adelante con el enfoque propuesto». Sin fecha límite, los RFCs se convierten en borradores perpetuos que nunca se traducen en acción.
Escribir RFCs para todo. No toda decisión necesita un RFC. Elegir entre dos paquetes de NPM para formatear fechas no necesita un documento. Los RFCs son para decisiones difíciles de revertir, que afectan a varios equipos o que implican una inversión significativa. Yo aplico esta regla: si la implementación lleva menos de una semana y es fácil de revertir, hazlo y ya. Si lleva más de una semana o es difícil de revertir, escribe un RFC.
Usar el RFC como permiso. El proceso de RFC va de recoger opiniones, no de pedir aprobación. Si cada RFC tiene que ser «aprobado» por un comité, has montado un comité de control de cambios con pasos extra. El objetivo son mejores decisiones gracias a la aportación colectiva, no un peaje burocrático.
Cómo crear el hábito del RFC sin burocracia
El mayor reto no es escribir un RFC: es convertirlo en un hábito del equipo. Esto es lo que funciona:
Empieza con una plantilla ligera. No crees una plantilla de 15 campos el primer día. Empieza con Problema, Propuesta, Alternativas, Riesgos. Cuatro secciones. Ya añadirás estructura más adelante, cuando el equipo vea qué le resulta útil.
Convierte los primeros RFCs en victorias visibles. Elige una decisión a la que el equipo lleva tiempo dando vueltas. Redáctala como RFC. Cuando desemboque en una decisión clara con el razonamiento documentado, el equipo verá el valor. Eso vende la práctica mejor que cualquier mandato de proceso.
Guarda los RFCs donde la gente ya trabaja. Una carpeta compartida de Google Drive que nadie visita es donde los RFCs van a morir. Ponlos en el repositorio (un directorio /rfcs), en Notion si esa es la casa de tu equipo, o en Confluence si no te queda otra. Allí donde el equipo ya busca la información.
Asigna revisores con nombre y apellidos. Un «por favor, revisen esto» dirigido a nadie va dirigido a nadie. Nombra a 2-3 revisores concretos cuya experiencia sea relevante. Dales un plazo. Insiste si no responden.
Mantén el periodo de revisión corto. Cinco días laborables bastan para la mayoría de los RFCs. Si un RFC pasa tres semanas en revisión, el autor ya ha pasado página mentalmente y el documento queda obsoleto.
Celebra los buenos RFCs. Cuando alguien escribe un RFC que libra al equipo de una mala decisión o desemboca en una arquitectura notablemente mejor, dilo en voz alta. «El RFC de Alejandro sobre la estrategia de caché nos salvó de un diseño que habría reventado a 10x de carga» hace que escribir RFCs parezca valioso, y no un deber escolar.
Los equipos distribuidos son quienes más los necesitan
Los RFCs valen aún más cuando el equipo está distribuido. Son el gran igualador: el ingeniero más callado en las reuniones tiene la misma voz en un documento escrito. Quien trabaja en otra zona horaria no se pierde la discusión, porque no hay discusión que perderse. Todos contribuyen de forma asíncrona.
En Conectia hemos visto cómo la práctica del RFC marca una diferencia tangible en el funcionamiento de los equipos distribuidos. Cuando nuestros ingenieros senior se incorporan al equipo de un cliente, contar con un proceso claro de RFC les permite aportar criterio arquitectónico desde el primer día, no solo código. Entienden el contexto de las decisiones existentes (porque está por escrito) y pueden proponer mejoras a través del mismo proceso estructurado. Así es como los equipos distribuidos deciden igual de bien —o mejor— que los que comparten oficina.
La inversión es pequeña: una plantilla, un sitio donde guardarlos y el compromiso de escribir antes de construir cuando la decisión es significativa. El retorno es enorme: mejores decisiones, menos conversaciones de «¿por qué hicimos esto?» y un equipo que piensa antes de programar.
¿Estás construyendo un equipo distribuido que toma decisiones técnicas sólidas en asíncrono? Habla con un CTO: nuestros ingenieros senior de LATAM aportan el pensamiento estructurado y las habilidades de comunicación que los equipos distribuidos necesitan.
