Introducción

Estás en el lugar correcto si eres un emprendedor y tienes una idea para un producto nuevo, o si eres parte de una empresa consolidada y tienes la necesidad de fabricar un software para resolver una necesidad interna o de tus clientes.

En esta guía te explicaremos cómo aterrizar tus ideas en un documento al que llamaremos Especificación de Producto. Utilizaremos lenguaje informal para describir qué debe hacer el producto. Además, hemos incluido una serie de ejemplos y una plantilla gratuita para que puedas ahorrar tiempo creando la tuya.

Al terminar esta guía, habrás pasado desde ideas abstractas a lo concreto. Tendrás un documento que constituye un lenguaje común entre tú y quién fabricará tu software. Y podrás avanzar rápidamente a la fase de cotización y posterior desarrollo del producto que quieres fabricar.

¿Qué es una Especificación de Producto?

Es un documento que describe un software, el problema que resuelve, quién lo usará y sus características o funciones. Todo esto desde el punto de vista del usuario, dejando de lado los tecnicismos de implementación y usando un lenguaje informal.

La Especificación de Producto (EP) que utilizaremos en esta guía, la hemos adaptado para enfocarse en productos de software que deben estar fuertemente alineados a los objetivos del negocio.

Una gran ventaja de la EP que presentamos es que puede ser escrita por personas no técnicas y está compuesta principalmente por texto. Ahorraremos bastante tiempo en la creación de diagramas y gráficos en una etapa temprana en dónde los cambios abundan.

De todas formas, si el contexto lo amerita, vale la pena agregar diagramas para complementar y explicar lógica compleja.

¿Por qué debería hacer una Especificación de Producto?

Porque tienes el conocimiento y experiencia del problema, y tienes una idea sobre cómo se puede resolver.

Escribir qué hará el software con un lenguaje informal y detallar el paso a paso sobre cómo funcionará en sus flujos más importantes, es un excelente ejercicio durante la etapa de ideación, prueba de concepto o prototipado, que permite aterrizar la idea y alinear al equipo sobre una base común.

Además, imaginar el funcionamiento del producto ayuda a descubrir que ciertos enfoques de la solución no son los correctos y sacará a la superficie otras alternativas que podrían funcionar de mejor forma. Es necesario realizar el ejercicio, ya que en la imaginación todo funciona fácilmente.

¿Qué debe contener una EP?

1. ¿Qué problema resuelve el software?

Describir el problema que enfrentan los usuarios o clientes y la solución. Se puede seguir un enfoque de lo más general a lo más específico.

Por ejemplo, se puede utilizar la siguiente estructura:

Describir el contexto del problema y quién lo tiene
Cuantificar el impacto del problema
Describir la solución y cómo lo resolverá

2. ¿Quiénes son los usuarios esperados?

Describir quiénes usarán el software.

Preguntas guía que podemos seguir:

¿Quién se espera que ocupe el software (usuario)?
¿Quién pagará por el software es el mismo que lo usará (el usuario es cliente o son distintos)?
¿Habrá un sólo tipo de usuario o serán varios (administrador, jefe de área, supervisor, operador, etc)?
En caso de que sean varios tipos de usuarios, ¿cuáles son sus roles y permisos?

3. ¿Cuáles son los principales objetivos del negocio?

Siempre debemos recordar que en una empresa, la tecnología está para potenciar el negocio y no al revés. Para que un equipo técnico o empresa proveedora de software pueda potenciar el negocio de su cliente, debe tener claro hacia dónde se dirige la organización y cuáles son sus objetivos en el corto, mediano y largo plazo. De esta manera podrá alinear al máximo las capacidades técnicas con el desarrollo del producto.

Por ejemplo, podemos establecer objetivos mes a mes o más deparados a 3, 6, 9 y 12 meses.

4. Características y funciones del software

En esta sección debemos listar lo que se necesita que el software sea capaz de realizar desde la perspectiva del usuario final. Lo haremos utilizando las llamadas “Historias de Usuario”. Éstas tienen la ventaja de que son redactadas en lenguaje informal.

El formato es el siguiente: “Como [Tipo de usuario], quiero [Acción] para [Beneficio/Propósito]”, en dónde:

Tipo de usuario: es el rol del usuario final.
Acción: es el objetivo que tiene la función de software para el usuario final.
Beneficio/Propósito: es la experiencia del usuario final con la función de software.

En las metodologías ágiles, las historias de usuario pertenecen a una épica. Una épica es una agrupación grande de cambios de un software.

Organizaremos las historias de usuario por aplicación, módulo y/o agrupación de una misma área.

Por ejemplo, para un software con 2 aplicaciones (una app web y una móvil) y diferentes tipos de usuarios.

Web (Panel de Administración):

Gestión de usuarios
- Como administrador, quiero desactivar usuarios de la app móvil que incumplan los términos y condiciones, y así poder mantener la app más segura.
- Como administrador, quiero reactivar usuarios de la app móvil que demuestren que no han infringido los términos y condiciones de la plataforma, y así poder dar la oportunidad a los usuarios de probar que siguen las reglas.
Publicaciones
- Como administrador, quiero poder moderar (despublicar u ocultar) los posts que infrinjan los términos y condiciones de la plataforma.
Gestión de anuncios
- Como administrador, quiero poder moderar (despublicar u ocultar) los anuncios que infrinjan los términos y condiciones de la plataforma.

App móvil:

Cuenta de usuarios
- Como visitante, quiero poder registrarme en la app para poder ingresar y ser parte de la comunidad.
- Como usuario, quiero poder ingresar a la app utilizando sólo mi huella digital y así no tener que recordar mi contraseña.
Interacción con Publicaciones
- Como usuario, quiero poder publicar mi vida con descripción y fotos, para que sean visibles al resto de usuarios de mi red y sepan lo que hago con mi tiempo o logros personales.
- Como usuario, quiero poder editar mis publicaciones y así corregir contenido erróneo que escribí rápidamente.
- Como usuario, quiero poder eliminar mis publicaciones y así evitar divulgar información o fotografías personales por accidente.
- Como usuario, quiero poder visualizar las publicaciones más relevantes de mi red y así estar informado de lo que están haciendo otros.
- Como usuario, quiero poder demostrar mi sentimiento de apoyo, enviado un me gusta, a la publicación de otro usuario y así conectarme con la comunidad.
- Como usuario, quiero poder comentar la publicación de otro usuario que haya publicado, para hacerle saber a él, y el resto de usuarios que la lean, lo que pienso sobre lo que ha compartido.
Anuncios
- Como usuario, quiero poder visualizar anuncios sobre productos que son de mi interés y así no perder oportunidades de compra.

5. Dependencias entre funciones

Si D necesita de A para funcionar, entonces D depende de A. Esta dependencia debe ser mencionada y explicada. Cabe señalar que las dependencias dependen del contexto y segmento del software, lo que para un tipo de clientes es dependencia, para otro no lo es; simplemente porque el software será diferente para un segmento que para otro.

A continuación se presentan 5 ejemplos en donde primero se explica el contexto y luego se describe la dependencia:

En un software B2B de despacho de mercadería a grandes volúmenes
- Dependencia: El usuario debe firmar el contrato antes de activar su cuenta.
En un app B2C de citas
- Dependencia: Se debe completar el perfil antes de usar la app.
En un software de acumulación de puntos de un supermercado
- Dependencia: El usuario debe tener “créditos o puntos” acumulados antes de canjearlos y acceder a descuentos en su compra.
En una app B2C de almacenamiento de archivos
- Dependencia: Al completar todo su perfil el usuario accede a 10GB extra de almacenamiento.
En un e-commerce B2C de productos fitness
- Dependencia: El usuario debe seleccionar una ciudad antes de que la app muestre el costo de despacho y así poder calcular el total de la compra.

6. Casos de uso para ilustrar escenarios clave

Describir los flujos más importantes del software paso a paso desde el punto de vista de los usuarios.

Es importante describir sólo los más relevantes y necesarios, y no aquellos comunes y obvios. Centrarse en los que son críticos para el problema que se está solucionando.

Por ejemplo, en el caso de un cajero automático o ATM, podemos tener el siguiente flujo que describe cómo girar dinero:

El usuario (cliente) ingresa su tarjeta bancaria (débito o crédito).
El cajero solicita al usuario el PIN de 4 dígitos.
El usuario ingresa el PIN y presiona continuar.
El cajero le muestra al usuario el menú principal.
El usuario selecciona la opción Girar dinero.
El cajero le muestra opciones de monto predefinidas $ (5.000, 10.000, 20.000, 40.000, 50.000 u Otro monto).
El usuario selecciona una opción:
1. Opción predefinida (ej.: 20.000): El cajero continúa con la confirmación.
2. Opción “Otro monto”: El cajero le solicita al usuario tipear el monto, una vez tipeado continúa con la confirmación.
El cajero le muestra en pantalla al usuario el monto y le solicita confirmación.
Una vez confirmado el monto el cajero le pregunta al usuario si desea o no comprobante de la transacción.
El cajero procede con la transacción:
1. Si el PIN está incorrecto o el usuario no tiene fondos o el cajero/usuario no tiene fondos, muestra el mensaje de error y lleva al usuario al menú principal.
2. Si todo está en orden, el cajero procede a girar el dinero.
Finalmente, le pregunta al usuario si quiere hacer otra operación.
1. Si: El cajero vuelve al menú principal (punto 4).
2. No: El cajero devuelve la tarjeta y retorna a la pantalla principal (pre PIN).

¿Qué debemos evitar al momento de crear una EP?

Cuando creamos una EP debemos poner atención y evitar lo siguiente:

Establecer objetivos poco realistas, lo que provocará un desarrollo apresurado o el incumplimiento de los plazos establecidos.
Usar lenguaje ambiguo o vago que podría dar espacio a malas interpretaciones, o lenguaje demasiado técnico que no es relevante para el usuario final.
Omitir características y funciones claves para el software, y en general cualquier información que tenga impacto en el usuario.

La mayor parte de los errores se cometen en las historias de usuario, es por ello que a continuación dejamos 3 ejemplos de historias incorrectas y su respectivo análisis:

1. Historia Mal Redactada

“Como usuario, quiero poder publicar mi vida.”

Problemas:

Falta de contexto: ¿Qué se quiere publicar?
Objetivo ambiguo: No está claro qué significa "publicar mi vida".
Sin resultado: No especifica qué condiciones deben cumplirse para que la funcionalidad esté completa.

Versión Mejorada:

“Como usuario, quiero poder publicar mi vida con descripción y fotos, para que sean visibles al resto de usuarios de mi red y sepan lo que hago con mi tiempo o logros personales.”

2. Historia Incompleta

"Quiero comentar."

Problemas:

Sin contexto ni actor: ¿Quién quiere comentar y a quién?
Falta de propósito: ¿Por qué el usuario quiere comentar?
No es accionable: No describe qué funcionalidad específica debe implementarse.

Versión Mejorada:

“Como usuario, quiero poder comentar la publicación de otro usuario que haya publicado, para hacerle saber a él, y el resto de usuarios que la lean, lo que pienso sobre lo que ha compartido.”

3. Historia con Detalles Técnicos Irrelevantes

"Como usuario, quiero que el sistema use un formulario con validación JavaScript para subir mi foto al servidor usando un método POST."

Problemas:

Exceso de detalles técnicos: Los usuarios finales no están interesados en cómo se implementará la funcionalidad.
Falta de enfoque en el objetivo: Describe la solución técnica en lugar del problema o necesidad del usuario.

Versión Mejorada:

"Como usuario, quiero subir una foto de perfil a la plataforma utilizando un formulario sencillo, para que otros usuarios me puedan identificar fácilmente."

Ejemplos y Plantillas Gratuitas

En nuestro blog hemos escrito varios artículos con ejemplos de EP para productos del tipo marketplace, B2C y B2B, e integraciones. Básate en ellos para tomar ideas y usarlos como punto de partida.

Ejemplos y Plantillas de Especificación de Productos para:

Cómo puede ayudar Ustart

Las empresas contratan a Ustart para impulsar su innovación tecnológica y acelerar su crecimiento.

Tanto si eres una startup que busca dejar su huella, como si eres una empresa consolidada que busca afrontar nuevos retos; estamos aquí para acompañarte en cada paso del camino.

Desde landing pages, e-commerce, aplicaciones web dinámicas, soluciones móviles intuitivas, APIs, SaaS y mucho más; nos especializamos en crear software robusto adaptado a tus necesidades.

Contáctanos, conversemos, accede a toda nuestra experiencia acumulada y trabajemos juntos para construir tu futuro.

Bono

Tenemos un bono para tí, pero sólo si quieres maximizar las probabilidades de éxito de tu producto.

En Ustart, nos encanta trabajar con emprendimientos y pequeñas y medianas empresas, es por eso que semanalmente ayudamos a crear, gratuitamente, una Especificación de Producto.

Necesitarás la EP para poder crear tu roadmap con una base sólida de tu software y poder avanzar en el desarrollo del mismo.

¿De qué se trata?

Consiste en reunirnos 1 hora diaria por 5 días, de lunes a viernes, en la que juntos daremos forma a tu producto.

Sólo tenemos 1 cupo por semana. ¡Asegura el tuyo e inscríbete lo antes posible!

Quiero Inscribirme Ahora

Cómo dar forma a una idea de producto