Looking for the #PerfectRFC [Spanish]

Arnau Giró
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:

  1. Objetivo: Objetivo principal que cumple el feature. No hay más que uno.
  2. KPIs: Métricas involucradas y objetivos previstos.
  3. Feature + Overview: User Story del desarrollo y descripción general.
  4. Child Stories: Especificaciones técnicas, trabajadas con el equipo de QA.
  5. Design Thinking: Wireframe + mockup, desde el esbozo hasta el diseño final.
  6. Userflow: Diagrama visual, que refuerza y clarifica los flujos creados/afectados.
  7. Discovery: Shortcut del trabajo de Discovery, como lo está aplicando la competencia, testings, analítica y feedback implicado.
#PerfectRFC

Proceso para la construcción:

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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!

)
Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade