Looking for the #PerfectRFC [Spanish]
Aug 22, 2017 · 2 min read
Desde que empecé en el oficio de Producto he intentado una y otra vez dar con el RFC perfecto. En resumidas cuentas es el documento donde se vuelca todo el trabajo de Discovery, y es el ejecutor del Delivery. Su papel para la construcción de features es trascendental.
Este doc tiene como objetivos principales:
- Reflejar el trabajo de Discovery para un desarrollo.
- Estimar correctamente para incorporar el feature al roadmap.
- Coordinar los distintos equipos que participan el en Delivery.
- Garantizar la visión definida por Producto en el deploy.
A continuación explico mi acercamiento personal a la estandarización del RFC, tanto referente al contenido a incluir como al proceso a seguir.
Secciones principales:
- Objetivo: Objetivo principal que cumple el feature. No hay más que uno.
- KPIs: Métricas involucradas y objetivos previstos.
- Feature + Overview: User Story del desarrollo y descripción general.
- Child Stories: Especificaciones técnicas, trabajadas con el equipo de QA.
- Design Thinking: Wireframe + mockup, desde el esbozo hasta el diseño final.
- Userflow: Diagrama visual, que refuerza y clarifica los flujos creados/afectados.
- Discovery: Shortcut del trabajo de Discovery, como lo está aplicando la competencia, testings, analítica y feedback implicado.

Proceso para la construcción:
- Se descubre el feature, y se incorpora el Discovery inicial implicado. Se define objetivo y KPIs con toda la compañía, en especial con negocio.
- Se describe el feature en términos generales (overview). Éste sirve para (1) el equipo de diseño pueda crear el wireframe y (2) el equipo de desarrollo pueda estimar (junto al wireframe). Si alguno de los dos no se logra cumplir, la descripción general no tiene el suficiente detalle.
- Llegados a este punto el RFC es un documento muy vivo. Lo tenemos encarado pero no cerrado, tocan ejercicios para obtener feedback, opiniones, análisis, etc. Tanto con nuestros usuarios como internamente.
- Una vez acotado al 90%, se definen junto al equipo de QA las user stories, que tiene como objetivo controlar todos los contextos posibles dentro de un feature. Ayuda tanto a verificar que no se nos olvida ninguna casuística como a garantizar que el desarrollo sale tal cual estaba definido.
- Mockup final, que pueden construirse en paralelo con las especificaciones técnicas. Tip: si utilizáis InVision+Confluence, insertar el widget para ‘embed’ el diseño. Te ahorras tener que ir modificándolo en varios sitios según evoluciona el diseño, así queda todo centralizado en InVision.
- Userflow: Finalmente, se refuerza el desarrollo y las user stories dibujando un diagrama de los flujos del usuario. Un soporte más visual para ayudar a interpretarlo completamente.
Un error común es entender el RFC únicamente al nivel de las especificaciones. El proceso aplicado para la construcción es igual de importante, y sin una combinación de los dos no aplica el #PerfectRFC.
Espero que os pueda ser de ayuda PMs.
Best!
