¿Qué Es un RFC?
Un Request for Comments (RFC) es un documento escrito que propone un cambio técnico significativo, describe el problema que se está resolviendo, presenta una solución, evalúa alternativas y solicita retroalimentación del equipo u organización. Los RFCs son una de las herramientas más importantes en el kit de herramientas de toma de decisiones de una organización de ingeniería.
El proceso de RFC sirve múltiples propósitos: obliga al autor a pensar rigurosamente en su propuesta, distribuye conocimiento a través del equipo, crea un registro buscable de decisiones técnicas y da voz a todos en elecciones importantes independientemente de su horario de reuniones o zona horaria.
Cuándo Escribir un RFC
- Nuevos sistemas o servicios: Crear un nuevo microservicio, pipeline de datos o componente mayor
- Cambios de arquitectura: Migrar bases de datos, introducir nuevos patrones, cambiar límites de servicios
- Cambios entre equipos: Cualquier cosa que afecte el código o flujos de trabajo de múltiples equipos
- Adopción de tecnología: Introducir nuevos lenguajes, frameworks o herramientas al stack
- Cambios de proceso: Nuevas estrategias de despliegue, requisitos de testing o flujos de desarrollo
- Cualquier cosa irreversible: Decisiones de un solo sentido que serían costosas de deshacer
La Plantilla de RFC
// RFC metadata and structure
interface RFC {
id: string; // "RFC-042"
title: string; // "Migrate User Service to Event-Driven Architecture"
author: string; // "Jane Smith"
status: "draft" | "in-review" | "accepted" | "rejected" | "superseded";
created: string; // "2026-03-15"
reviewDeadline: string; // "2026-03-29"
approvers: string[]; // ["Tech Lead", "Staff Engineer"]
stakeholders: string[]; // ["Platform Team", "Product Team"]
}
// The document sections:
// 1. Summary (2-3 sentences)
// 2. Context and Problem Statement
// 3. Goals and Non-Goals
// 4. Proposed Solution (with diagrams)
// 5. Alternatives Considered
// 6. Data Model Changes
// 7. API Changes
// 8. Migration Plan
// 9. Risks and Mitigations
// 10. Observability and Monitoring
// 11. Security Considerations
// 12. Timeline and Milestones
// 13. Open Questions
// 14. Decision (filled post-review)Escribiendo Cada Sección Bien
Resumen
Escríbelo al final. Debería ser 2-3 oraciones que un VP ocupado pueda leer y entender la propuesta a alto nivel. Si alguien lee solo el resumen, debería saber qué estás proponiendo y por qué.
Contexto y Planteamiento del Problema
Esta es la sección más importante. Si el lector no entiende el problema, no puede evaluar la solución. Incluye:
- ¿Cuál es el estado actual del sistema?
- ¿Qué problema u oportunidad aborda este RFC?
- ¿Qué datos respaldan la necesidad de cambio? (métricas, conteo de incidentes, encuestas de desarrolladores)
- ¿Qué pasa si no hacemos nada?
Objetivos y No-Objetivos
Declarar explícitamente lo que la propuesta NO pretende resolver es tan importante como declarar lo que sí pretende. Esto previene el crecimiento del alcance durante la revisión y establece expectativas claras.
Alternativas Consideradas
Esta sección construye confianza. Muestra que el autor ha hecho su tarea y considerado otros enfoques. Para cada alternativa, explica por qué fue rechazada. Una propuesta sin alternativas consideradas sugiere que el autor tiene una solución en busca de un problema.
Errores Comunes al Escribir RFCs
- Solución antes del problema: Saltar directo a la solución sin establecer por qué se necesita el cambio
- Sin alternativas: Presentar solo una opción hace que los revisores sospechen. Siempre incluye al menos dos alternativas con compensaciones honestas.
- Plan de migración faltante: Proponer una nueva arquitectura sin explicar cómo llegar de aquí a allá
- Ignorar preocupaciones operativas: Un gran diseño que es imposible de monitorear o depurar en producción no es un gran diseño
- Demasiado largo: Un RFC de más de 5-7 páginas pierde lectores. Sé conciso. Usa diagramas. Enlaza a documentos de soporte para detalles profundos.
El Proceso de Revisión
Ciclo de Vida del RFC
| Fase | Duración | Actividades |
|---|---|---|
| Borrador | 1-3 días | El autor escribe el RFC, obtiene retroalimentación informal de 1-2 revisores de confianza |
| Revisión | 5-10 días | Compartido con todas las partes interesadas. Comentarios recopilados asincrónicamente. |
| Discusión | 1 reunión | Reunión sincrónica opcional para resolver puntos contenciosos |
| Decisión | 1-2 días | Los aprobadores toman una decisión basada en la retroalimentación |
| Archivo | Continuo | El RFC se almacena en un repositorio buscable para referencia futura |
Consejos para una Revisión Efectiva
- Establece un plazo de revisión: Sin un plazo, las revisiones se prolongan indefinidamente. Dos semanas suele ser suficiente.
- Nombra revisores específicos: "Todos deberían revisar esto" significa que nadie lo hará. Nombra 3-5 personas cuyo input es esencial.
- Responde a todos los comentarios: Incluso si la respuesta es "Reconocido, no se necesita cambio porque X." Esto muestra respeto por el tiempo del revisor.
- Separa lo obligatorio de lo deseable: Etiqueta los comentarios para que el autor sepa qué retroalimentación requiere cambios antes de la aprobación.
- Acepta lo suficientemente bueno: El objetivo es una buena decisión, no un documento perfecto. No dejes que lo perfecto sea enemigo de lo bueno.
Construyendo una Cultura de RFC
Introducir RFCs a un equipo que nunca los ha usado requiere paciencia y modelado:
- Comienza escribiendo RFCs tú mismo como Tech Lead. Muestra al equipo cómo luce uno bueno.
- Mantén la plantilla inicial simple. Puedes agregar secciones a medida que el equipo madura.
- Celebra buenos RFCs públicamente. "El RFC de Sarah sobre la capa de caché es un gran ejemplo de análisis exhaustivo."
- Haz que el repositorio de RFCs sea fácilmente buscable y descubrible.
- No requieras RFCs para cambios pequeños. Usa buen juicio sobre cuándo el proceso es justificado.
Resumen
Los RFCs son una piedra angular de la toma de decisiones técnicas reflexiva. Fuerzan el pensamiento riguroso, distribuyen conocimiento, crean responsabilidad y dejan un rastro buscable de decisiones para futuros ingenieros. Invierte en construir una práctica de RFC en tu equipo y la calidad de tus decisiones técnicas mejorará dramáticamente.