Requerimientos en el Software IX-iv – Requerimientos escritos – Story maps

Story Maps

Los Story Maps son usados para organizar los requerimientos y ayudar la estructura del proyecto. Presenta el product backlog de una manera visual con la historias de usuario agrupadas dentro de específicas categorías funcionales. Priorizando las historias de usuario a través de múltiples categorías proveyendo una visión de lo que está siendo desarrollado.

Story Maps se compone de un conjunto de columnas. Cada una de ellas representa una categoría agrupando historias de usuario. Dentro de cada columna las historias de usuario son priorizadas de la más a la menos importante. Esta estructura intenta mostrar la prioritaria historia de usuario para todo el proyecto.

Storymap

Ejemplo:

ejemploStorymap

Requerimientos en el Software IX-iii – Requerimientos escritos – Product Backlog

Product Backlog

El product Backlog es un conjunto de funcionalidades del software que el product manager planea desarrollar para un producto a lo largo del proyecto. Es una forma de organizar el trabajo priorizando y planeando las tareas dentro del proyecto.

Para crear el product backlog:

  1. Después de realizar las historias de uso, las funcionalidades deberán ser plasmadas en una lista. A cada historia de usuario se le deberá asignar un único identificador simple como una secuencia de números o nombres.
  2. Priorizar las historias de uso y funcionalidades. Ayudará al cliente a identificar lo que quiere y sus necesidades. Y ayudará al equipo a identificar qué es lo más importante y a qué habrá que dedicarle más recursos conociendo cuál es el core del proyecto.
  3. Empezar a planificar el proyecto usando prioridades y puntos de referencias.
  4. Historias de usuario son agrupadas en Units of Works para ser completadas en un determinado intervalo de tiempo (sprints).
  5. Product Backlogs es flexible. Un sprint en proceso no debería cambiar pero una vez se le enseñe al cliente este debe evaluar el trabajo hecho y añadir o modificar historias de usuario o requerimientos o cambiar la prioridad de las historias de usuario o requerimientos.

Requerimientos en el Software IX-ii – Requerimientos escritos – Test de Aceptación

Test de Aceptación

Los test de aceptación son usados para verificar si un requerimiento ha sido alcanzado satisfactoriamente.

Ejemplo:

Como cliente quiero ser capaz de pagar con tarjeta de crédito así podré elegir el método más conveniente para realizar un pago.

Para dar como bueno el criterio de aceptación se debe fragmentar en varios pasos que se podrán chequear para dar como aceptable el criterio por ejemplo:

  1. Insertar la tarjeta en un lector de tarjetas.
  2. Insertar el PIN de la tarjeta.
  3. Confirmar que el pago ha sido aceptado.

Este criterio de aceptación será como válido si los tres puntos se cumplen.

Requerimientos en el Software IX-i – Requerimientos escritos – Historias de Uso

Historias de Uso

Las técnicas que hemos visto hasta ahora para expresar los requerimientos han sido las siguientes:

  • Casos de Uso.
  • Mockups.
  • Storyboards.
  • Historias de Uso.

Las Historias de Uso expresan los requerimientos siendo fácil escribir, leer y evaluar.

historiadeuso

Como cliente, quiero ser capaz de identificar qué restricciones tengo en mi dieta, así poder conocer qué puedo pedir cuando compro comida.

Product Management – Ahorrar y generar dinero en la empresa

La figura del product manager dentro de una startup o una multinacional

software product management

A continuación hago una reflexión de la figura del product manager dentro de una empresa.

Desde mi propia experiencia el product manager en el producto/s de una empresa lo:

  • Concibe
  • Planifica
  • Desarrolla
  • Testea
  • Lanza al mercado

Lleva al mercado productos para satisfacer a los clientes y alcanzar los objetivos de negocio. También quita del mercado los productos que no se ajusta al mercado o del que no puede conseguir beneficios.


  1. Ayuda a las ventas
    1. Esfuerzos en identificar oportunidades de mercado y aproximarse con estrategia y planes de acción.
    2. Adquiriendo clientes, conociéndoles y enfocándose en desarrollar productos orientados a cubrir las necesidades de éstos.
    3. Formando, coordinando y dirigiendo a los equipos de ventas apoyándoles en sus dudas técnicas y a llevar a cabo las tareas de disciplina en ventas para evitar la frustración y conseguir los objetivos a través de llevar a cabo con estrategia las tareas y planes de ventas.
  2. Reduce riesgos del fallo en el producto
    1. Lleva a cabo investigación de mercado y conocer al cliente para detectar sus necesidades antes del desarrollo del producto.
    2. Objetivo: Asegurar que el producto cubre las necesidades y no se desarrolla funciones innecesarias evitando desperdicios de tiempo-dinero en productos inservibles.
  3. Mejora la comunicación efectiva dentro de los departamentos de la compañía.
    1. Identificar problemas del mercado.
    2. Encontrar la mejor solución con el equipo técnico.
    3. Llevarla al mercado a tiempo.
    4. Colaborar entre los equipos (Técnico – Marketing – Ventas) mejorando la productividad y uso de recursos de la compañía.
  4. Calidad
    1. Analizar recogiendo datos en el uso del producto por cliente interno y externo.
    2. Testeo continuo para conseguir calidad.
    3. Mejorar productos y conseguir beneficios.
    4. Si el producto hace falta renovarlo irá soportado de suficiente información.
  5. Negociación con los clientes importantes.

Conclusión: El product manager deberá combinar con sus esfuerzos el engrasar la maquinaria de los equipos de la compañía, equipos de Ventas, Marketing, desarrollo técnico y managers, combinando sus esfuerzos para reducir gastos innecesarios y generar el mayor beneficio con los productos a la compañía.