Escribir RFCs Técnicos que Realmente se Lean e Impulsen Decisiones
Las decisiones técnicas más costosas en una organización de ingeniería ocurren en hilos de Slack que desaparecen, en reuniones donde la mitad de los interesados está ausente, o en la cabeza de un ingeniero senior sin la contribución de nadie más. Luego, seis meses después, cuando la arquitectura está crujiendo y alguien pregunta "¿por qué lo construimos de esta manera?", nadie recuerda. O peor, todos recuerdan de manera diferente.
Los RFCs — documentos de Solicitud de Comentarios — resuelven este problema. Son una de las herramientas más poderosas disponibles para los equipos de ingeniería y una de las más infrautilizadas. Los he visto transformar cómo los equipos toman decisiones, se alinean entre zonas horarias y construyen memoria institucional. También los he visto hacer mal, convirtiéndose en novelas de 40 páginas que nadie lee y que ralentizan todo.
Aquí está cómo hacerlos bien.
Por Qué Importan los RFCs
Un RFC es una propuesta escrita para una decisión técnica significativa, compartida con el equipo para obtener feedback antes de que comience la implementación. Eso es todo. No una especificación. No documentación. Una propuesta que invita a la contribución.
El valor proviene de tres cosas:
Claridad forzada del pensamiento. Escribir te obliga a estructurar tu razonamiento. La idea vaga que parecía genial en tu cabeza se pone a prueba cuando tienes que explicarla en papel. He escrito RFCs donde el acto de escribir reveló que mi solución propuesta tenía un defecto fundamental que no había notado. Ese es el punto — es más barato encontrar el defecto en un documento que en código de producción.
Alineación asíncrona. En un equipo distribuido que abarca múltiples zonas horarias, las reuniones sincrónicas son costosas y excluyentes. Alguien siempre se une a una hora inconveniente, alguien siempre falta. Un RFC permite que todos contribuyan con su perspectiva en su propio horario. El ingeniero en Buenos Aires y el de Berlín leen el mismo documento y añaden sus comentarios sin necesitar encontrar una superposición de 30 minutos.
Memoria institucional. Dentro de seis meses, un nuevo miembro del equipo preguntará por qué el sistema usa event sourcing en lugar de un patrón CRUD tradicional. En lugar de depender de la historia oral ("creo que María decidió eso, pero se fue en marzo"), los señalas al RFC-047. El contexto, las alternativas y el razonamiento están todos ahí. Esto solo vale el costo de escribir RFCs.
La Estructura de RFC que Funciona
He iterado en plantillas de RFC en múltiples equipos y organizaciones. Esta es la estructura que consistentemente produce documentos útiles sin ser 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, Superado.
- Revisores. Nombra a las personas cuya contribución necesitas específicamente.
2. Contexto y declaración del problema (1-2 párrafos)
¿Cuál es la situación? ¿Qué problema estamos resolviendo? ¿Por qué ahora? Esta sección da fundamento al lector. No asumas que tienen el mismo contexto que tú. Enlaza a tickets, métricas o incidentes relevantes que hagan el problema concreto.
Malo: "Necesitamos mejorar nuestro pipeline de datos." Bueno: "Nuestro pipeline ETL actual procesa 2M de registros por la noche. Con nuestra trayectoria de crecimiento, alcanzaremos 10M de registros para el T1 de 2024. La arquitectura actual tarda 4 horas en procesar 2M de registros y no escalará de manera lineal. El mes pasado tuvimos dos incidentes donde el trabajo por lotes no se completó antes del horario laboral (INC-234, INC-251)."
3. Solución propuesta (el núcleo del documento)
Describe lo que quieres construir, cómo funciona y por qué este enfoque. Incluye:
- Arquitectura o diseño del sistema. Los diagramas ayudan. Un diagrama simple de cajas y flechas comunica más que cinco párrafos de texto.
- Decisiones técnicas clave dentro de la propuesta y por qué las tomaste.
- Alcance. Qué está incluido y, de manera crítica, qué no está explícitamente incluido.
4. Alternativas consideradas (sección no negociable)
Enumera al menos dos alternativas que evaluaste y por qué las rechazaste. Esta sección hace tres cosas: muestra que hiciste tu tarea, previene comentarios de "¿pero por qué no consideraste X?" y documenta el panorama de decisiones para futuros lectores.
Si no puedes pensar en alternativas, no has pensado suficiente en el problema.
5. Riesgos y preguntas abiertas
¿Qué podría salir mal? ¿Sobre qué estás inseguro? ¿Qué suposiciones estás haciendo que podrían ser incorrectas? Esta sección es donde vive la honestidad intelectual. Una propuesta que afirma cero riesgos no es segura — es ingenua.
6. Plan de implementación
Un cronograma aproximado y fases. No un plan detallado del proyecto — solo lo suficiente para mostrar que es factible e identificar dependencias. "Fase 1: migrar la capa de ingesta (2 semanas). Fase 2: migrar la capa de transformación (3 semanas). Fase 3: descomisionar el pipeline antiguo (1 semana)."
7. Decisión y resultado (completado después de la revisión)
¿Qué se decidió? ¿Cuándo? ¿Por quién? ¿Alguna modificación a la propuesta original? Esto cierra el ciclo y convierte el RFC de una propuesta en un registro.
Errores Comunes que Matan los RFCs
Demasiado largo. Si tu RFC tiene más de 4 páginas, la mayoría de las personas no lo leerá cuidadosamente. Hojearán, perderán los matices y o bien lo aprobarán sin más o plantearán objeciones que ya están abordadas en el texto. Sé despiadado al cortar. Mueve detalles de implementación, esquemas de API y modelos de datos a apéndices.
Demasiado abstracto. "Deberíamos adoptar una arquitectura de microservicios" sin especificar qué servicios, cuáles son los límites o cómo se comunican no es una propuesta — es un deseo. Los RFCs necesitan ser lo suficientemente concretos para que alguien pueda estar en desacuerdo con un aspecto específico.
Sin punto de decisión claro. El RFC debería declarar explícitamente: "Necesitamos una decisión sobre esto para [fecha]. Si no se plantean objeciones para entonces, procedemos con el enfoque propuesto." Sin un plazo, los RFCs se convierten en borradores perpetuos que nunca se convierten en acción.
Escribir RFCs para todo. No todas las decisiones necesitan un RFC. Elegir entre dos paquetes NPM para el formateo de fechas no necesita un documento. Los RFCs son para decisiones que son difíciles de revertir, afectan a múltiples equipos o implican una inversión significativa. Uso esta regla: si la implementación tarda menos de una semana y es fácilmente reversible, simplemente hazla. Si tarda más de una semana o es difícil de revertir, escribe un RFC.
Usar los RFCs como permisos. El proceso de RFC debería ser sobre obtener contribuciones, no aprobación. Si cada RFC necesita ser "aprobado" por un comité, has construido una junta de revisión de cambios con pasos extra. El objetivo es mejores decisiones a través de la contribución colectiva, no la burocracia de la aprobación.
Construir el Hábito del RFC Sin Burocracia
El mayor desafío 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. Puedes añadir estructura más adelante cuando el equipo vea qué es útil.
Haz que los primeros RFCs sean victorias visibles. Elige una decisión sobre la que el equipo ha estado yendo y viniendo. Redáctala como un RFC. Cuando conduce a una decisión clara con razonamiento documentado, el equipo ve el valor. Eso vende la práctica mejor que cualquier mandato de proceso.
Almacena 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 tu repositorio (un directorio /rfcs), en Notion si ese es el hogar de tu equipo, o en Confluence si estás atascado con él. Donde sea que el equipo ya busque información.
Asigna revisores explícitamente. "Por favor revisa" dirigido a nadie está dirigido a nadie. Nombra 2-3 revisores específicos cuya experiencia sea relevante. Dales un plazo. Haz seguimiento si no responden.
Mantén el período de revisión corto. Cinco días laborables es suficiente para la mayoría de los RFCs. Si un RFC está en revisión durante tres semanas, el autor ya ha seguido adelante mentalmente y el documento se queda obsoleto.
Celebra los buenos RFCs. Cuando alguien escribe un RFC que salva al equipo de una mala decisión o lleva a una arquitectura notablemente mejor, señálalo. "El RFC de Alejandro sobre la estrategia de caché nos salvó de un diseño que se habría roto con 10x de carga" hace que escribir RFCs se sienta valioso, no como tarea.
RFCs para Equipos Distribuidos
Los RFCs se vuelven incluso más valiosos cuando tu equipo está distribuido. Son el gran igualador — el ingeniero que es más callado en las reuniones tiene voz igual en un documento escrito. El miembro del equipo en una zona horaria diferente no se pierde la discusión porque no hay discusión que perderse. Todos contribuyen de manera asíncrona.
En Conectia, hemos visto la práctica de RFC hacer una diferencia tangible en cómo operan los equipos distribuidos. Cuando nuestros ingenieros senior se unen al equipo de un cliente, tener un proceso claro de RFC significa que pueden contribuir al pensamiento arquitectónico desde el primer día, no solo código. Entienden el contexto detrás de las decisiones existentes (porque está escrito) y pueden proponer mejoras a través del mismo proceso estructurado. Es cómo los equipos distribuidos toman decisiones tan bien como — o mejor que — los co-ubicados.
La inversión es pequeña: una plantilla, una ubicación de almacenamiento y un compromiso de escribir antes de construir para decisiones significativas. El retorno es enorme: mejores decisiones, menos conversaciones de "¿por qué hicimos esto?" y un equipo que piensa antes de codificar.
¿Construyendo un equipo distribuido que toma decisiones técnicas sólidas de manera asíncrona? Habla con un CTO — nuestros ingenieros senior de LATAM traen el pensamiento estructurado y las habilidades de comunicación que los equipos distribuidos necesitan.
