Requerimientos en el Software IX – Requerimientos escritos

Requerimientos en el Software IX – Requerimientos escritos

Como hemos visto en las entradas anteriores los requerimientos pueden tomarse con: 1º Storyboards, 2º Mockups, 3º Casos de Uso. Pero además se pueden tomar los requisitos simplemente escribiendo.

En el desarrollo ágil se siguen doce principios que asumen que el desarrollo software es dinámico. O sea, que los requerimientos no se definen una sola vez y se quedan intactos. Al contrario, los requerimientos evolucionan a medida que el proyecto se va desarrollando. Más aún teniendo en cuenta que los clientes van cambiando la idea del software a medida que lo van viendo crearse, sobre todo si no han tenido experiencia previa con el desarrollo de alguna aplicación.

En el desarrollo ágil los cambios son esperados y bienvenidos puesto que siempre se sabe que existen los cambios para tener un producto excelente que se encuentre en mejora continua.

12 Principios del desarrollo ágil:

http://agilemanifesto.org/iso/es/principles.html

  1. Entregas tempranas y continuas.
  2. Trabajar con prototipos software como medida del progreso.
  3. Excelencia técnica y buen diseño.
  4. Centrados en la SIMPLICIDAD
  5. Equipos autogestionados
  6. Intentar que la interación sea cara a cara
  7. Entregas frecuentes
  8. Los cambios en los requerimientos son bienvenidos para la mejora del producto
  9. Desarrollo sostenible con un camino fijado que todas las personas que intervengan en el desarrollo conozcan el camino que se está siguiendo y puedan mantener un ritmo sostenido en el tiempo, sin estrés pero sin pausa.
  10. Construir proyectos con gente motivada
  11. Colaboración diaria. Discusiones frecuentes con el cliente para asegurar que los requerimientos son los mejores posibles.
  12. Que se refleje en el comportamiento del equipo

Estos principios de desarrollo ágil se siguen en la metodología Scrum.

Si se siguen los principios ágiles para el desarrollo la calidad del producto final se conseguirá en mayor medida.

 

Las técnicas más usuales para escribir los requerimientos son:

  • Historias de uso. Para escribir los requerimientos.
  • Test de aceptación – Criterio de aceptación. Para evaluar la consecución del requerimiento.
  • Product Backlog – Conjunto de funciones que se planean alcanzar a lo largo del desarrollo del producto.
  • Story Maps – Mapa que se usa para organizar los requerimientos y ayudar a la estructura del proyecto.
Antonio Navas on EmailAntonio Navas on FacebookAntonio Navas on GoogleAntonio Navas on Linkedin
Antonio Navas
Software Product Engineer at Aertec Solutions
Inventor apasionado de soluciones tecnológicas. Especializado en acústica, web y aplicaciones móviles.
Con amplia experiencia en dirección de productos, ingeniería y sistemas de calidad.
Convencido cada día más que ha venido a este mundo para crear productos eficientes, bellos y rentables.

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.

Antonio Navas on EmailAntonio Navas on FacebookAntonio Navas on GoogleAntonio Navas on Linkedin
Antonio Navas
Software Product Engineer at Aertec Solutions
Inventor apasionado de soluciones tecnológicas. Especializado en acústica, web y aplicaciones móviles.
Con amplia experiencia en dirección de productos, ingeniería y sistemas de calidad.
Convencido cada día más que ha venido a este mundo para crear productos eficientes, bellos y rentables.

Elevator Pitch en 4 pasos

El Elevator Pitch está concebido para contar tu idea de negocio a alguien que pueda ayudarte a financiarla.

Como no siempre estamos buscando dinero yo me lo tomo como un esquema para contar cualquier idea que tengas a cualquier persona y que esta se interese por lo que cuentes. ¡Vender la idea siempre! practicar practicar practicar incluso con los amigos.

Muchas veces, más a los técnicos, nos cuesta contar historias a personas que no conocen nuestro trabajo. Por ello me parece muy interesante analizar el tema del Elevator Pitch puesto que se puede aplicar a cualquier mensaje que quieras lanzar, sea un proyecto, una idea, o simplemente lo que haces en tu día a día.

Analizaré lo que cuentan en este vídeo, como siempre, esquemáticamente para retener las ideas principales:

Presentar la esencia de tu idea de una forma convincente
20 segundos para contar la esencia

  1. Enganchar desde el principio dando unos datos impactantes.
    ¿Sabe que seis mil niños mueren cada día por falta de agua pura?
    ¿Sabes cuánto petroleo hace falta para hacer el maletín que llevas? Para hacer una hamburguesa 1.5 litros…¿Sabías que en esta ciudad hay chicos que juegan al futbol descalzos?
  2. He pensado crear…. NOOO… Mejor siempre decir: He creado el proyecto
  3. Al grano. ¿Qué queremos de esa persona? y ¿Qué haremos con esa ayuda?
    Necesitamos que nos ayude apoyándonos… Con su ayuda crearemos tal y tal cosa.
    Necesitamos X €, con los que crearemos tal y tal cosa. Lo vamos hacer, (no decir intentaremos…).
    Con su ayuda, vamos a construir pozos de agua limpia para la población de Otwal.
  4. El propósito es verle de nuevo, no conseguir el dinero ya.
    ¿Tendría su tarjeta, para llamarle esta tarde y concretarlo todo?

 

 

Antonio Navas on EmailAntonio Navas on FacebookAntonio Navas on GoogleAntonio Navas on Linkedin
Antonio Navas
Software Product Engineer at Aertec Solutions
Inventor apasionado de soluciones tecnológicas. Especializado en acústica, web y aplicaciones móviles.
Con amplia experiencia en dirección de productos, ingeniería y sistemas de calidad.
Convencido cada día más que ha venido a este mundo para crear productos eficientes, bellos y rentables.

Requerimientos en el Software VIII – Storyboards

Storyboards

Storyboards en software son representaciones visuales de una interacción con el producto software.

Existen dos tipos de storyboards ambos sirven de ayuda para discutir e indagar requerimientos entre los clientes y entre el equipo de desarrollo para comprender qué se pretende crear.

Storyboards tipo 1

Tipo comic, describe paso a paso los distintos momentos en los que se interactúa con el producto.

requerimientos8 Storyboards

Usos potenciales:

  • Asegura que todo el equipo de desarrollo sepa de qué se está hablando, centra la atención.
  • Estimula el identificar posibles features que mejoran al producto.
  • Asegura la claridad del objeto de uso del producto.
  • Se puede usar en las demos de marketing.

Storyboards tipo 2

Este segundo tipo de storyboards combina los mockups con el flujo básico de los casos de uso con objeto de mostrar cómo el usuario final interactúa con el interfaz de usuario del producto en detalle.

requerimientos8 Storyboards 2

Usos potenciales:

  • Ayuda al equipo de desarrollo a diseñar los requerimientos.
  • Ayuda a identificar qué podría complicarse en exceso.
  • Asegura al equipo de desarrollo estar atentos a las funcionalidades y el sentir del producto.
  • Sirve de ayuda a la hora de crear los manuales de usuario.

requerimientos8 Storyboards 2b

 

Antonio Navas on EmailAntonio Navas on FacebookAntonio Navas on GoogleAntonio Navas on Linkedin
Antonio Navas
Software Product Engineer at Aertec Solutions
Inventor apasionado de soluciones tecnológicas. Especializado en acústica, web y aplicaciones móviles.
Con amplia experiencia en dirección de productos, ingeniería y sistemas de calidad.
Convencido cada día más que ha venido a este mundo para crear productos eficientes, bellos y rentables.

Requerimientos en el Software VII – Mock Ups

Mock Ups

requerimientos7 mockups

Los Mock Ups o también conocidos como Wireframes son usados para:

  • Esbozar una idea que se va a desarrollar.
  • Mostrar la idea a un cliente y que nos dé su feedback.
  • Comunicar qué se desea al equipo de desarrollo.
El mockup se puede dibujar a mano o usar alguna herramienta tipo Balsamiq, Omnigroup, Wirify…
Antonio Navas on EmailAntonio Navas on FacebookAntonio Navas on GoogleAntonio Navas on Linkedin
Antonio Navas
Software Product Engineer at Aertec Solutions
Inventor apasionado de soluciones tecnológicas. Especializado en acústica, web y aplicaciones móviles.
Con amplia experiencia en dirección de productos, ingeniería y sistemas de calidad.
Convencido cada día más que ha venido a este mundo para crear productos eficientes, bellos y rentables.

Requerimientos en el Software VI – Casos de Uso

Casos de Uso

requerimientos6 simbologia

Una buena herramienta para comprender un producto son los CASOS DE USO.

Identifica, clarifica y organiza con detalles una tarea dentro de un producto desde el punto de vista de un actor, normalmente un usuario.

Tabla de Casos de Uso

requerimientos6 casos de uso

 

Diagrama de Caso de Uso

requerimientos6

Antonio Navas on EmailAntonio Navas on FacebookAntonio Navas on GoogleAntonio Navas on Linkedin
Antonio Navas
Software Product Engineer at Aertec Solutions
Inventor apasionado de soluciones tecnológicas. Especializado en acústica, web y aplicaciones móviles.
Con amplia experiencia en dirección de productos, ingeniería y sistemas de calidad.
Convencido cada día más que ha venido a este mundo para crear productos eficientes, bellos y rentables.

Requerimientos en el Software IV – Comprendiendo al cliente para redactar los requisitos

Comprendiendo al cliente para redactar los requisitos

Eschuchar al cliente

Comprender al cliente realizándole las preguntas adecuadas y escucharle es de vital importancia para poder obtener las verdaderas necesidades del cliente y redactar con ello correctamente los requisitos.

Otras fuentes para obtener requisitos son:

  • Entrevistas con los usuarios finales.
  • Estudios de mercado para ver la viabilidad del producto.
  • Observar cómo un usuario final interactúa con el producto o un mock-up de este.
  • Viendo otros productos similares (estudio de la competencia).

En reuniones con el cliente se le debe ayudar a gestionar las expectativas transmitiéndole:

  • Los objetivos realistas del producto.
  • Tiempos de ejecución.
  • Qué se hará y qué no se hará en el producto.
  • Priorizar los requerimientos. Qué se hará antes y qué después.

En la reunión con el cliente se debe ser asertivo:

  • Abierto a las ideas y perspectivas del cliente.
  • No aceptar las ideas pasivamente, también hay que sugerir ideas y perspectivas pero no forzar agresivamente nuestro punto de vista.
  • Se debe proporcionar al cliente una estructura en la conversación sobre los requerimientos para ayudarle a organizar sus pensamientos.
  • El cliente puede tener un conjunto de ideas pero no conocer qué es técnicamente factible o ser de difícil comprensión para los usuarios finales. Para ello debemos ser capaces de captar el porqué el cliente tiene ese conjunto de ideas y la mejor manera de comprenderlo es preguntar al cliente cómo ven ellos a un usuario final interactuando con el producto y por qué. Para posteriormente proponerles ideas y explicarles porqué ciertas ideas pueden no funcionar explorando las posibles limitaciones en diferentes escenarios.
  • Es de vital importancia que el cliente esté informado y que comprenda sus opciones. Pero al final es él el que debe tomar la decisión de los requisitos que desea que sean cumplidos.

Después de la primera reunión con el cliente:

  • Mostrarle Mock-ups y prototipos producidos desde la primera reunión.
  • Mostrarle la lista de requerimientos con un identificador único para facilitar el hablar de ellos.
  • Preguntarle qué le gusta del producto, qué no le gusta y qué quieren.
  • Revisar con el cliente de nuevo los requerimientos.
  • Preguntarle por la elección del diseño.
  • Que diga abiertamente todo el feedback que desee.
Antonio Navas on EmailAntonio Navas on FacebookAntonio Navas on GoogleAntonio Navas on Linkedin
Antonio Navas
Software Product Engineer at Aertec Solutions
Inventor apasionado de soluciones tecnológicas. Especializado en acústica, web y aplicaciones móviles.
Con amplia experiencia en dirección de productos, ingeniería y sistemas de calidad.
Convencido cada día más que ha venido a este mundo para crear productos eficientes, bellos y rentables.

Requerimientos en el Software V – Preguntando al cliente

Preguntando al cliente

Preguntando al cliente

Distintos tipos de preguntas en función de lo que se quiera indagar:

Para averiguar los requerimientos de negocio:

  • ¿Qué problema quiere resolver?
  • ¿Qué le motiva para resolver este problema?
  • ¿Qué cosas haría una aplicación buena que resolviera este problema?
  • ¿Qué cosas haría como mínimo una solución que resolviera esos problemas?
  • ¿Quién usaría esta solución?
  • ¿Qué tipo de usuarios usarían esta solución?
  • ¿En este sector quiénes son las personas de referencia?
  • ¿Hay más proyectos relacionados con este, se harán más soluciones relacionadas?
  • ¿Existen soluciones en el mercado similares?
  • ¿Qué debemos incluir en el alcance del proyecto y qué debemos dejar fuera? ¿Hasta dónde debemos llegar?

Para averiguar las reglas de negocio:

  • ¿Qué normativas debemos cumplir a la hora de desarrollar el producto?

Para averiguar los requerimientos de usuario:

  • ¿Con este producto qué objetivos alcanzará más fácilmente? O sea, ¿Este producto le ayudará a…?
  • ¿Qué problemas esperas solventar con este producto?
  • ¿Cómo describiría el producto? Es un producto que…
  • ¿Qué aspectos del producto le motivan más conseguir?
  • ¿Qué aspectos son más valiosos para los usuarios?
  • ¿Qué aspectos son menos valiosos para los usuarios?

Para averiguar los requerimientos no funcionales o de calidad:

  • Para las distintas partes del producto defina qué calidades alcanzar: eficiencia, seguridad, calidad, diseño, confiabilidad-robustez…

Para averiguar las interfaces externas:

  • ¿A qué eventos el producto debe responder?
  • ¿Con qué se debe comunicar el producto?
  • ¿En qué ambiente el producto será usado?

Para averiguar algunas condiciones excepcionales:

  • ¿Alguna vez alguien querrá…?
  • ¿Podría alguna vez ocurrir que…?
  • ¿Qué pasaría si…?

Para conocer algunas limitaciones:

  • ¿Qué es lo más importante del producto para ti?
  • ¿Cómo juzgarías, o en qué puntos te fijarías para saber que el producto ha sido un éxito?
  • ¿Qué puntos, con qué valores, podemos valorar el éxito del producto?
  • ¿Cómo debería el producto hacer cambiar la manera en la que ahora se hacen las cosas?
  • ¿Hay algo más que deberíamos preguntarte?

Para investigar en más profundidad algunos aspectos:

  • Por favor, ¿Podría ayudarme a comprender por qué… ? por ejemplo: por qué algo es importante, por qué es requerido, por qué es tan prioritario, por qué se hace de esta manera…
Antonio Navas on EmailAntonio Navas on FacebookAntonio Navas on GoogleAntonio Navas on Linkedin
Antonio Navas
Software Product Engineer at Aertec Solutions
Inventor apasionado de soluciones tecnológicas. Especializado en acústica, web y aplicaciones móviles.
Con amplia experiencia en dirección de productos, ingeniería y sistemas de calidad.
Convencido cada día más que ha venido a este mundo para crear productos eficientes, bellos y rentables.

Requerimientos en el Software III – Gestión de las expectativas de un cliente

Gestión de las expectativas de un cliente

Espectativas del cliente

Visión y Alzance del proyecto software

Al desarrollar un producto se debe tener una VISIÓN GLOBAL DEL PRODUCTO como el valor o necesidad que cubre del cliente/usuarios finales dentro de un mercado o espacio donde vaya a operar la solución. ¿Cuál es el objetivo del producto? ¿Para qué se ha creado?

Cambios en el producto

Cualquier cambio que se vaya a realizar en el proyecto debe analizarse si afecta a la visión del producto, cosa que no debe ocurrir. El propósito del producto no debe variar.

Alcance o Scope de un producto

El Scope o alcance es lo que un producto realísticamente puede llegar a hacer. Es lo que debe conocer el cliente para gestionar las expectativas de este y jamás prometer lo que no se pueda llegar a hacer.

Para manejar las expectativas del cliente debemos:

  1. Mantener una buena comunicación entre el cliente y el equipo para crear juntos las expectativas.
  2. Dibujar el alcance con el cliente a través de herramientas como diagramas de casos de uso.
  3. Preguntar al cliente por la priorización de los requerimientos para realizar los más importantes para el cliente primero.
  4. Preguntar al cliente constantemente si hemos llegado a lo esperado (en cada paso del desarrollo) para no dedicar exceso de tiempo en requerimientos innecesarios.

Importante: Cada cambio en los requerimientos o en el alcance debería ser aceptado por escrito por el cliente puesto que conllevará a una revisión de tiempos en el desarrollo que deberá conocer y entender el cliente para estar dentro del presupuesto (o número de horas) acordado o si afecta a este.

Antonio Navas on EmailAntonio Navas on FacebookAntonio Navas on GoogleAntonio Navas on Linkedin
Antonio Navas
Software Product Engineer at Aertec Solutions
Inventor apasionado de soluciones tecnológicas. Especializado en acústica, web y aplicaciones móviles.
Con amplia experiencia en dirección de productos, ingeniería y sistemas de calidad.
Convencido cada día más que ha venido a este mundo para crear productos eficientes, bellos y rentables.

Requerimientos en el Software II – Tipos de Requerimientos en el Software

Tipos de Requerimientos en el Software

  1. Requerimientos del proyecto.
    1. Requerimientos de negocio
    2. Reglas de negocio
  2. Requerimientos CORE
    1. Requerimientos de usuario
    2. Requerimientos funcionales
    3. Requerimientos no funcionales o de Calidad
  3. Requerimientos que añaden contexto
    1. Interfaces externas
    2. Configuraciones físicas del producto
    3. Limitaciones de desarrollo
  1. Requerimientos del proyecto.

    1. Requerimientos de negocio: Requerimientos que envuelven propósitos del proyecto, con objetivos medibles en el análisis de negocios. Por ejemplo, el cliente necesita reducir los errores en la numeración de sus facturas en un 25%.
    2. Reglas de negocio: Restricciones de cómo el producto funcionará. Ejemplo, uniformidad de la marca, normas legales, políticas de privacidad…
  2. Requerimientos CORE

    1. Requerimientos de usuario o usuarios finales: Qué tareas puede realizar el usuario con el producto, o qué puede hacer el producto para el usuario. (Son los requerimientos más importantes). Se pueden expresar en:
      1. Casos de uso (use cases).
      2. Historias de usuario (user stories).
      3. Storyboards.
      4. Escenarios (scenarios). El usuario final describe el requerimiento en sus propias palabras.
    2. Requerimientos funcionales: Comportamientos que el producto final debería soportar. Son expresados como:
      1. Datos de entrada
      2. Datos de salida
      3. Descripción del comportamiento en sí mismo con Information Flow diagrams o data flow diagrams:

        Diagrama de flujo de datos

        Diagrama de flujo de datos

    3. Requerimientos no funcionales o Requerimientos de Calidad (Quality Requariments): incluyendo la precisión, fiabilidad, seguridad, facilidad de uso, eficiencia, rendimiento y facilidad de mantenimiento. Normalmente los requerimientos de Calidad son complementarios a requerimientos funcionales y están enlazados a estos.
  3. Requerimientos que añaden contexto

    1. Interfaces externas: Ejemplo, una aplicación que necesita información de una base de datos (un servicio de datos) que se localiza en internet, necesitará unos requerimientos de interfaces externas para comunicarse, como pueden ser: protocolos, formatos, compatibilidades, entidades de datos… Estas interfaces pueden ser representadas en los diagramas de flujos de datos.
    2. Configuraciones físicas del producto: Requerimientos de cómo debe ser diseñado la aplicación para que funcione en el ambiente donde va a vivir el producto. (Por ejemplo, la aplicación que desarrollamos de localización de los tronos debíamos tener en cuenta que el emisor GPS pudiese tener cobertura y ser resistente a la lluvia).
    3. Limitaciones de desarrollo: Cualquier limitación que tengamos en lo que respecta a memoria, tecnología usada, documentación y proceso usado en el desarrollo de la aplicación.
Antonio Navas on EmailAntonio Navas on FacebookAntonio Navas on GoogleAntonio Navas on Linkedin
Antonio Navas
Software Product Engineer at Aertec Solutions
Inventor apasionado de soluciones tecnológicas. Especializado en acústica, web y aplicaciones móviles.
Con amplia experiencia en dirección de productos, ingeniería y sistemas de calidad.
Convencido cada día más que ha venido a este mundo para crear productos eficientes, bellos y rentables.