¿Qué es un flujo de trabajo efectivo para escribir una especificación o documento de requisitos del producto (PRD)?

Un par de suposiciones:

  • Trabajas para una empresa pequeña y de rápido movimiento. Este es un “PRD mínimo viable”.
  • Su equipo ya ha decidido en qué trabajar. Este flujo de trabajo comienza a descubrir cómo trabajar en él.

Aquí está mi flujo de trabajo. Estoy seguro de que podría mejorar, pero funciona más o menos.

Finalmente, su PRD (llamado una especificación de ahora en adelante) necesitará al menos 3 secciones:

  1. Historias de usuarios . ¿Cuál es la lista exhaustiva de características que necesitamos construir para este proyecto? ¿Cuáles son las historias de usuarios que el equipo de desarrollo debe ejecutar?
  2. Wireframes y simulacros. ¿Cómo se ve esta cosa?
  3. Métricas de éxito. ¿Cómo medimos el éxito? ¿Qué métricas necesitamos para instrumentar y rastrear?

Nota: no creo en los diagramas de flujo . Son muy útiles para que usted, el propietario del producto, descubra cómo su característica se conecta al resto del producto. Pero esa información se puede comunicar adecuadamente con palabras, por ejemplo: “Un enlace a la extensión de Chrome se muestra de forma destacada en el widget de sugerencias en la barra lateral de cada página de inicio de sesión”. Los diagramas de flujo son difíciles de hacer y deben guardarse para proyectos más grandes donde es necesario visualizar la relación entre varias páginas.

Otras secciones que puede desear según su equipo: Introducción / Objetivos, Panorama competitivo, Lista de características.

Ahora que sabe cómo se verá el esqueleto de su especificación, créelo en Confluence . De hecho, crea una plantilla de página para que puedas ahorrarte algo de tiempo. Agregue una tabla de contenido y un indicador de estado en la parte superior:

Realmente no importa si comienzas con wireframes o historias de usuarios . Encuentro saltar entre ellos es la mejor manera de hacerlo. Probablemente tengas una idea decente de cómo se ve y se comporta esto de todos modos.

Wireframes

  1. Use una pizarra para esbozar la interfaz de usuario y trabajar con el diseño. Toma una habitación donde no molestes a nadie y comienza a dibujar. Involucre el diseño lo antes posible para tener una visión compartida de la interfaz de usuario.
  2. Una vez establecida la visión de la interfaz de usuario, genere maquetas en Balsamiq, Photoshop, o simplemente conéctela en HTML . Esto realmente depende de su equipo y la función.
  3. Agregue sus tramas al PRD. Cree una tabla con tres columnas: Título de la página, Estructura metálica y Descripción (donde llame a cualquier interacción que necesite explicación).


Historias de usuarios

Tenga en cuenta que estas son las escrituras. Lo que escriba aquí irá directamente al equipo de desarrollo, se convertirá en tareas y se enviará. No cometas errores, sé claro como el cristal, sé minucioso.

Es posible que desee escribir una descripción funcional en oraciones completas o hacer una lista de características. Anímate, pero ten en cuenta que solo sirve tu propia comprensión del producto. Solo las historias de los usuarios son importantes para el equipo de desarrollo.

Escriba historias de usuarios en Confluence directamente. Cree una tabla con tres columnas: Prioridad, Historia de usuario y Tamaño (es posible que no necesite prioridad y tamaño, dependiendo de su proceso de desarrollo, que no está cubierto aquí).


Idealmente, sus historias de usuario se conectan perfectamente a su proceso de desarrollo. La historia del usuario debe convertirse en un carril para nadar, y los puntos deben convertirse en tareas. Esto significa que en su sesión de planificación, los desarrolladores están agregando tareas adicionales y cambiando las que escribió. Debería tener cubiertas todas las tareas del producto, pero espere que se agreguen tareas técnicas (y tal vez requiera cambios en lo que escribió).

Métricas de éxito

¿Cómo medirás el éxito? ¿Cuáles son las métricas clave que desea medir y cómo desea moverlas?

Esta es la parte menos agradable del proceso, porque tan pronto como diga “Quiero que esto aumente las suscripciones en un 30%”, tendrá la oportunidad de fallar. Está bien. Eso es bueno. Mejorará al anticipar el impacto de su trabajo y mejorará al trabajar en proyectos de alto impacto.

A menudo encontrará que sus métricas de éxito requieren instrumentación adicional, que es importante identificar en la sesión de planificación.

Ya terminaste! ¡Casi!

Actualice el estado de la especificación a “Listo para revisión”. Envíe un correo electrónico a su equipo diciéndole a todos que lo lean y le envíen preguntas o comentarios. Programe una hora para que las personas relevantes revisen las especificaciones. Haga lo que necesite hacer para tener una sesión de planificación muy fluida y eficiente.

Ok, ahora ya terminaste. Ve a recompensarte de alguna manera y luego comienza a trabajar en lo siguiente.

Los clientes a menudo acuden a nosotros con una consulta similar, aquí en la ruta escalable (una red de más de 2500 ingenieros independientes que crean productos digitales).

Realmente no es necesario definir cada cosa posible que hará su producto, y francamente a nadie le gusta escribir (o leer) documentos detallados de requisitos. Entonces, en su lugar, desarrollamos el flujo de trabajo y la plantilla a continuación para escribir un PRD que sea lo suficientemente bueno como para obtener una estimación razonablemente precisa de nosotros u otra tienda de desarrollo. Creemos que logra el equilibrio correcto entre estar preparado y ser ágil. En otras palabras, el mínimo esfuerzo necesario para comenzar a construir un gran producto.

EL MARCO “DESCUBIERTO MÍNIMO”

A menudo, el propietario de un producto tendrá grandes ideas para su proyecto y todas las características que pueda tener en el futuro. Soñar en grande es genial, pero es extremadamente importante desde el principio reducir su enfoque al conjunto mínimo de características que necesita en la primera versión. Esto se llama el producto mínimo viable. Después de lanzar su producto y recibir comentarios de sus usuarios, puede decidir qué características adicionales desea agregar. Pero mientras escribe su documento de requisitos, aclare todas esas posibles características futuras y simplemente defina las que se incluirán en la primera versión de su producto.

EL MARCO “DESCUBIERTO MÍNIMO”

A menudo, el propietario de un producto tendrá grandes ideas para su proyecto y todas las características que pueda tener en el futuro. Soñar en grande es genial, pero es extremadamente importante desde el principio reducir su enfoque al conjunto mínimo de características que necesita en la primera versión. Esto se llama el producto mínimo viable. Después de lanzar su producto y recibir comentarios de sus usuarios, puede decidir qué características adicionales desea agregar. Pero mientras escribe su documento de requisitos, aclare todas esas posibles características futuras y simplemente defina las que se incluirán en la primera versión de su producto.

Nota: Por supuesto, si hay una característica futura que debe conocerse desde el principio, entonces el equipo de desarrollo debe saber que se acerca y hablaré sobre cómo incluirla.

Preámbulo suficiente, a continuación se presentan las secciones que sugiero para un documento de requisitos simple:

  1. Metas
  2. Personas de usuario
  3. Historias de usuarios
  4. Mapa del sitio
  5. Descripciones de página
  6. Wireframes (opcional)
  7. Requerimientos no funcionales
  8. Riesgos
  9. Iteraciones futuras

METAS

Las metas y objetivos comerciales sirven como contexto, mostrando al equipo de desarrollo por qué están construyendo lo que están construyendo.

Aquí hay algunas preguntas comunes que puede hacerse al desarrollar esta sección:

  • ¿Cuál es el propósito de este proyecto?
  • ¿Cuáles son los problemas que resolverá?
  • ¿Cómo racionalizará o mejorará el proceso actual o facilitará un nuevo proceso?
  • ¿Cuál es la visión del producto?

Consulte nuestra Plantilla de requisitos de productos gratuitos para obtener más ejemplos.

PERSONAS DE USUARIO

Las Personas de usuario son individuos hipotéticos que coinciden con su audiencia deseada o real. Pensar en los antecedentes de estos usuarios mejorará su capacidad para crear un producto que se adapte a sus necesidades.

Los usuarios son una de las áreas en las que las personas tienden a ahogarse. Así que establezcamos algunas reglas para mantenerlo a flote.

  • Cubre los tipos principales de usuarios. No necesita crear una persona para cada tipo de usuario, solo lo suficiente para ilustrar los grupos principales que utilizarán su producto. Para aplicaciones simples, 3 buenos perfiles cubrirán más del 80% de su base de usuarios, pero si su aplicación es compleja, es posible que necesite más.
  • Concéntrate en lo que sabes. Inventar detalles para simplemente llenar un perfil de usuario final es contraproducente.
  • Comience con estas 5 métricas. Ocupación, edad, género, ubicación, educación. Serán el marco para su perfil.
  • Nombre a sus usuarios finales. Es más fácil relacionarse con “David el Ejecutivo” que con el “Usuario final D”.
  • Dale a cada perfil un objetivo. Cada usuario necesita un objetivo que se ajuste a su perfil. Esta será su razón de ser.

Básicamente, todo se reduce a esto: sus personajes deben ser lo suficientemente detallados como para permitirle ver el producto a través de sus ojos. Cada perfil debe funcionar como otra persona en la sala al tomar una decisión. “¿David iniciaría sesión para leer su mensaje o deberíamos enviárselo por correo electrónico?”

Si tiene un sitio web existente, use Google Analytics para ayudarlo a crear estos perfiles. Le brinda información invaluable, puede ver de dónde provienen sus visitantes, qué palabras clave usaron para encontrarlo y qué contenido y comportamientos exhiben en línea. Si este es un producto nuevo, Alexa (y otros sitios similares como Similar Web) le proporcionarán datos similares para su competencia.

HISTORIAS DE USUARIOS

Las historias de usuario son descripciones breves de una característica, contadas desde la perspectiva de uno de sus perfiles de usuario final recién creados. Por lo general, están estructurados de la siguiente manera:

Como [tipo de usuario], quiero [algún objetivo] para que [alguna razón].

Las historias de usuarios son un punto de partida, no un destino. A menudo es mejor pensar en ellos como indicadores de sus eventuales requisitos. Estas historias son vitales porque las discusiones que comienzan ayudarán a dar forma a su arquitectura y diseño de contenido.

Entonces, ¿cómo puede usar este concepto para hacer avanzar su producto sin atascarse en cientos de historias e ideas destacadas?

  • Limítese a historias de alto nivel (y debe tener). Estas historias de alto nivel se conocen como épicas y se pueden dividir posteriormente en historias más pequeñas y manejables.
  • Tus historias deben ser cortas y específicas.
  • Deben describir quién necesita qué y por qué.
  • Deben estar centrados en el usuario. Recuerda que puedes usar tus personajes.

Aquí hay un ejemplo enfocado en un rol de usuario:

  • Como administrador, quiero poder ver nuevos productos y categorías de productos a medida que se solicitan para poder escribir contenido para el sitio web.

Y aquí hay uno más centrado en la persona del usuario:

  • Como usuario del sitio web, es vital elegir el producto correcto. Quiero ver mis opciones de productos una al lado de la otra para poder tomar una decisión informada rápidamente.

No tiene que escribir una historia de usuario para cada pequeña funcionalidad en su aplicación por adelantado. Debería centrarse en las epopeyas porque los detalles se desarrollarán cuando se creen estructuras y diseños. Épicas y desglosadas en historias más pequeñas en las sesiones de preparación de pedidos pendientes. Recuerde, en este momento está escribiendo para brindar a los diseñadores y desarrolladores la información mínima necesaria para iniciar una conversación productiva sobre cómo crear su aplicación.

MAPA DEL SITIO

Una vez que se definen sus historias de usuario principales, debe tener una idea sólida de qué páginas o pantallas se ubicarán en su aplicación. El mapa del sitio es el primer paso para documentar esto.

Un buen mapa del sitio incluye lo siguiente:

  • Una lista completa de todas las páginas o pantallas. Esto incluye todo, desde páginas que detallan información sobre productos y servicios hasta una página “Acerca de nosotros” y una política de privacidad. Dedique un poco de lluvia de ideas para asegurarse de que se enumere todo lo que desea en su aplicación.
  • La jerarquía entre estas páginas (opcional). Si tiene una idea de cómo sus páginas se relacionan entre sí jerárquicamente, entonces comunicar esto será útil para diseñar la navegación. Sin embargo, este paso no es obligatorio, y una lista completa de todas las páginas es suficiente por lo mínimo.

Figura 1: Ejemplo de mapa del sitio

Writemaps.com es una buena solución para crear rápidamente un mapa del sitio que pueda compartir fácilmente con sus partes interesadas. O simplemente use uno de los complementos gratuitos para Google Docs.

DESCRIPCIONES DE LA PÁGINA

Una vez que tenga una lista de todas las páginas o pantallas en su aplicación, puede dar el siguiente paso y definir qué habrá en cada página. Haga una lista simple y numerada de los elementos principales que se incluirán en cada página y coloque los elementos más importantes en la parte superior de la lista (esto transmitirá la importancia relativa de cada elemento que informará el diseño). Aquí hay algunos ejemplos simples de un sitio web de comercio electrónico.

NOTA: Si desea hacer un esfuerzo adicional, puede definir la URL de cada página, que a menudo ayuda a organizar las cosas.

MARCOS DE ALAMBRE

Los wireframes son diseños de página simples que describen el tamaño y la ubicación de elementos, características en una página. Generalmente carecen de color, estilos de fuente, logotipos o cualquier elemento de diseño.

Piense en una estructura alámbrica como un plano que le muestra la ubicación de los elementos separados del diseño de esos elementos. A menudo surgen problemas que solo pueden notarse a través de una herramienta visual. A menudo me encuentro moviendo, o incluso eliminando, las características de un sitio web cuando llego a la etapa de tramado.

Debido a la naturaleza iterativa del proceso, esbozaré los primeros intentos en un bloc de notas y luego pasaré a una herramienta de creación de prototipos simple como Balsamiq. Las siguientes figuras muestran la progresión de mis wireframes de bocetos en papel a una versión más final.

Figura 2: Una estructura metálica esbozada de la tabla de comparación de productos en el sitio web

Wireframing es probablemente el paso más lento de este proceso y para algunos proyectos simples puede ser excesivo. Para proyectos complejos en los que es necesario pensar seriamente en el diseño, los wireframes son una herramienta indispensable.

Como propietario del producto, es posible que no tenga experiencia con la estructura de alambre, pero le animo a que intente hacerlo usted mismo. Hacer bocetos en papel y tomar una foto con su teléfono puede funcionar notablemente bien. Encuentro que cuando los emprendedores se toman el tiempo de aprender a trazar y pensar profundamente cómo funcionará su producto, sus proyectos de desarrollo se han desarrollado sin problemas.

Dicho esto, los wireframes son una parte opcional del marco de referencia ‘mínimo mínimo’ porque se puede cambiar a la fase de diseño de un proyecto. Cuando un Propietario del producto nos proporciona toda la otra información en este artículo, tenemos suficiente información para preparar una estimación razonablemente precisa del esfuerzo que tomará construir el producto y comenzar.

Figura 3: un mapa del sitio creado en un software de creación de prototipos.

REQUERIMIENTOS NO FUNCIONALES

Si bien la mayor parte del documento de requisitos define cómo funcionará el software (requisitos funcionales), esta parte del documento define los requisitos que pueden ser importantes para su negocio, pero no se trata de cómo funciona el software en sí. Este es un lugar donde puede comunicar cualquier parámetro especial que los desarrolladores deberán tener en cuenta. Aquí hay unos ejemplos:

  • La aplicación debe estar construida en Ruby on Rails
  • La aplicación debe estar alojada en AWS
  • La aplicación debe usar Stripe para el procesamiento de pagos
  • La aplicación debe funcionar en todos los navegadores modernos.
  • La aplicación debe ser receptiva (funciona bien y se ve bien en todos los tamaños de pantalla)
  • La aplicación debe ser compatible con 1000 usuarios simultáneos.

Riesgos

Si hay riesgos significativos conocidos que enfrenta el proyecto, es una buena idea documentarlos. Con frecuencia, es una buena idea que un equipo de desarrollo intente abordar primero las partes riesgosas de un proyecto de software para que pueda saber desde el principio antes de invertir demasiado tiempo y dinero si una característica en particular no es factible.

Aquí hay unos ejemplos:

  • Nuestro motor de recomendación predictiva, que es un diferenciador clave para nuestro inicio, puede ser difícil de codificar.
  • Nuestra cuenta comercial puede no ser aprobada con Stripe.

FUTURAS ITERACIONES

Mientras escribe el documento de requisitos, debe pensar constantemente “¿Es esto absolutamente necesario para mi MVP?” . Si una característica es una buena idea e importante para el plan a largo plazo para el negocio, pero no se incluye en el MVP, debe documentarla brevemente en la sección de iteraciones futuras para que no se olvide y los desarrolladores puedan asegurarse La aplicación se puede ampliar en el futuro para admitir estas características clave.

Un buen documento de requisitos del producto ahorrará tiempo y dinero durante toda la vida de un proyecto. Para acelerar aún más el proceso, aquí hay un enlace para descargar la plantilla de documento de requisitos real que utilizamos en la ruta escalable. También he agregado algunos ejemplos útiles que se relacionan con este artículo.

Durante más de 10 años construyendo productos, me he enfrentado a este problema personalmente muchas veces. Finalmente, creé una plantilla maestra para hacer referencia. Dependiendo de la complejidad y la amplitud del producto en cuestión, puedo optar por omitir algunas secciones, pero más o menos la plantilla que estoy a punto de compartir ha resistido el paso del tiempo.

Puede leer sobre cómo implementar esta plantilla en este artículo:

Plantilla de documento de requisitos del producto (PRD) – Talvinder

Nick, aquí hay una versión diferente de tus 3 secciones, con una grande antes de las historias de los usuarios. La moraleja de la historia es CAMINAR a través de los procesos comerciales de los clientes antes de EJECUTAR con los requisitos y el diseño del producto.

  1. Crear flujos de trabajo de clientes : ¿qué hacen y cómo lo hacen (como está)? ¿Cómo quieren hacerlo en el futuro (ser)?
  2. Historias de usuarios comerciales : sin importar su producto, escriba historias de usuarios que describan las tareas laborales de una persona: QUIÉN es el usuario objetivo, QUÉ tarea laboral está realizando, QUÉ objetivo esperan lograr, POR QUÉ es importante para ellos.
  3. Wireframes y simulacros : comience con las interacciones del usuario y trabaje hacia atrás para llegar a la funcionalidad del producto.
  4. Métricas de éxito

Aquí hay un breve artículo para una perspectiva adicional. Diseño de procesos antes de productos

No haga nada de lo que se describe en las otras respuestas. Cree un lienzo de página único que especifique lo siguiente:

  1. un mercado objetivo (usuario específico)
  2. El problema específico que está tratando de resolver
  3. la solución específica que proporcionará en términos de beneficios para el usuario
  4. y el modelo de ingresos que se utilizará

Tenga en cuenta que el problema que está tratando de resolver no es la falta de su solución. Piense en ello como una pregunta que le haría a su usuario objetivo. Por ejemplo, “¿Estás frustrado de no poder hacer ?”.

Luego … ve a hablar con tus usuarios objetivo sobre el problema, recibe comentarios de que la solución que tienes es buena y están dispuestos a pagar el precio que tienes en mente. Si ese no es el comentario, modifique el problema / solución / precio y vuelva a hacerlo.

Luego … entregue el documento de lienzo a alguien que construirá el producto y discuta los detalles para que tengan contexto.

Lo más importante es dejar el diseño del producto y los requisitos a los expertos. Si sus expertos solicitan una especificación (o un PRD), busque mejores expertos.

Diviértete y {create: awesome}

Trabaja constantemente en ello y, mientras lo haces, siempre trata de mantenerlo corto y puntual .

También puede usar una herramienta diseñada específicamente para escribirlos. Pengloo, por ejemplo, es una herramienta en línea simple que creamos para desarrollar ideas y convertirlas en documentos de diseño, esquemas, especificaciones de productos y otros documentos vivos bien pensados ​​y procesables.

Lo que encontramos genial al respecto es:

Estructura : estructura intuitivamente tus ideas para obtener una excelente visión general de lo que estás creando.

Simplifique : divida los grandes conceptos en unidades más pequeñas y manejables.

Funciona como Legos : cada idea o más bien cada capítulo se comporta como un bloque de Lego que se puede mover libremente.

Aquí hay una muestra,
Cómo escribir un documento de requisito de producto (muestra PRD 101) por Shoieb Yunus en publicaciones

Las métricas de éxito están muy cerca. Se unen en análisis y lo llevan de vuelta a la próxima versión PRD y lanzamiento.

¿Tiene un DOC de muestra “vacío” que puede compartir, que será realmente útil.