Discovery de un proyecto: aspectos clave

31 Aug 2022
María Dueñas

María Dueñas

Ver biografía y publicaciones del autor

Si en vez de leer prefieres escuchar, dale al play.

Discovery de un proyecto: aspectos clave
11:14

Antes de iniciar un proyecto, hay que tener en cuenta muchas variables para saber si los esfuerzos que vamos a emprender tienen sentido, tanto para nosotros como para los usuarios finales. Es como intentar ir a la batalla sin un plan, tenemos que establecer una hoja de ruta que nos guíe, pero no sin antes de saber qué tenemos, qué necesitamos y si todos los implicados están alineados con el mismo objetivo. Lesmes López, Agile Delivery Manager (ADM) en Codurance, dirigió un meetup en el que ofreció claves, herramientas útiles y pautas para realizar con éxito el discovery de un proyecto.

Empezó por lo básico: ¿Qué es un discovery de un proyecto?

Actividades y entregables que nos permiten comprender y alinearnos sobre un problema y las soluciones más adecuadas con los medios disponibles.

- Lesmes López, Agile Delivery Manager

A partir de esta definición, explicó la importancia de cada uno de los elementos de un Discovery.

Actividades y entregables

Son el output final de un discovery, es decir, la representación de las actividades a las que hemos llegado a partir de nuestro discovery. Hay muchos formatos que nos pueden ayudar a representar estas actividades y entregables, debemos elegir el que mejor se adapte a nuestro proyecto.

blog_discovery_3

Comprender y alinearnos

Si cada miembro del equipo no comparte una visión común del problema o no entiende la información disponible de la misma manera, es muy probable que se presenten soluciones muy diferentes entre sí o centradas en aspectos distintos. Por eso, el outcome de un discovery consiste en que las actividades y entregables nos permitan comprender y alinearnos como equipo hacia objetivos que tienen sentido para todos. Así lo afirma López: "Lo importante es que salgamos con una comprensión conjunta y alineada de las necesidades que queremos satisfacer".  

Para alinearnos, es conveniente analizar el problema desde diferentes perspectivas. El ADM señala que es necesario considerar al menos 3 ángulos:

  • Negocio (valor) - Cuál es el valor que se aporta al usuario y entenderlo.

  • UX (usuario) - Cuál es la experiencia del usuario y cómo se puede mejorar.

  • Tecnología (factible) - Cómo de factible es implementar, mantener y mejorar a lo largo del tiempo la solución que proponemos.

En la búsqueda de este alineamiento, es importante contar con los stakeholders, que son en definitiva las personas que ayudarán a entender el problema y las posibles soluciones que existen. Entre ellos destacó a los expertos de dominio, el equipo de ventas, los líderes técnicos, el equipo de marketing y, sobre todo, a los detractores. No hay que dejar fuera a las personas que sabemos que pueden complicar un discovery. "Es clave incorporar a los detractores desde el principio, porque tarde o temprano los encontrarás y pueden generar bloqueos a ciertas soluciones", afirmó. En definitiva, se trata de unir y crear una visión común desde cada perspectiva particular. 

blog_discovery_1

Problemas y soluciones

Entonces, ¿sobre qué queremos alinearnos? Sobre el problema que nos bloquea o no nos permite avanzar y las soluciones para dar respuesta a ese problema. Esta es la clave. López explicó que para abordar esta definición conjunta de problemas y soluciones hay que tener en cuenta varios niveles, ya que en función del grado de incertidumbre o complejidad que haya en estos ámbitos, habrá que poner más énfasis en unas herramientas u otras. La naturaleza del problema a resolver nos define las actividades y entregables. Por ejemplo, si el proyecto que vamos a tratar es más táctico que estratégico, las herramientas que utilicemos estarán enfocadas en reforzar la táctica ya que damos por hecho que la estrategia ya existe. Es posible que reforcemos un poco esa estrategia al principio, pero al final nos centraremos en la táctica.

Asimismo, el discovery puede ser para crear un producto nuevo, desarrollar nuevas capacidades de un producto existente, esto suele ser lo más habitual cuando se desarrolla software, o implementar una modernización, por ejemplo de un sistema legacy. Dependiendo de la necesidad principal, las soluciones van a ir encaminadas a solucionar el problema detectado. El discovery tiene que ver con la cantidad de información que desconocemos y tenemos que descubrir.

Según estas categorías, López presentó algunas herramientas útiles para cada caso:

      • Producto nuevo
        - Business Model Canvas. Es una herramienta que permite plasmar una proposición de valor. Hay que plantearse hipótesis realistas.
        - Steve Blank, Customer Development. Foco en el cliente. No vamos a desarrollar un producto sino un cliente, tenemos que entender lo que quiere.

      • Modernización de un sistema antiguo
        - Value Stream Mapping. Muestra el proceso de generación de valor  y permite identificar dónde se generan colas o bloqueos. Ayuda a encontrar los puntos en los que se puede ahorrar tiempo para optimizar la cadena de valor.
        - Architecture Discovery. Representa cómo es la arquitectura actual vs como podría ser.
        - Event Storming. Consiste en plasmar un producto para comprender las áreas críticas que hay que abordar para que todo el sistema funcione mejor.
        - Service Blueprint. Permite hacer un mapa de cómo es el servicio para visualizarlo y tomar decisiones en base a eso. 

      • Útiles en cualquier caso
        - Recopilación de expectativas, realistas o no. 
        - Wardley Maps. Herramienta de análisis estratégico que permite visualizar hacia dónde debe evolucionar el proyecto para aportar más valor.
        - Customer Journeys. Detallar el recorrido del usuario para establecer donde están los pain points que se pueden resolver para mejorar la experiencia.
        - Entrevistas con usuarios.
        - Shadowing Session. Sesiones que permiten observar lo que hacen los usuarios e interpretarlo para saber qué puntos se pueden mejorar.
        - Design Sprints. Se trabaja sobre una serie de hipótesis y muchas pruebas que permiten establecer el problema y la solución.

Neil Killick explica tres áreas que nos ayudan a entender la división entre el espacio del problema y el de la solución. Primero está la capability, que es exactamente lo que el usuario necesita hacer. Luego el área funcional, que describe las herramientas que necesitamos implementar para que el usuario pueda lograr lo que busca. Y por último, el área técnica, que son los pasos que debemos dar para implementar las funcionalidades que el usuario necesita.

blog_discovery_4

Adecuadas con los medios disponibles

Esto es lo básico, el discovery debe ser realista en cuanto a los medios disponibles. Para ello, es necesario tener en cuenta la naturaleza del equipo que tenemos (laboratorio de innovación vs equipo de producto) y la empresa en la que nos encontramos. Las soluciones deben ajustarse al contexto y al entorno en el que nos ubicamos.

Para ejemplificar este apartado, el ADM introdujo el triángulo de hierro adaptado de Kent Beck en el que, jugando con las variables de alcance (more), coste (cheaper), tiempo (faster) y calidad (better), se exponen 3 fases diferentes dentro de los desarrollos: 

  • Explore (better/sooner/cheaper) - Limitar el alcance pero acelerar el feedback. Hacer el máximo de pruebas posibles, lo que se busca es entregar rápido y recoger esa información.
     
  • Expand (better/sooner/more) - Entregar funcionalidades rápido y de calidad, pero sin limitar el coste. 

  • Extract (better/cheaper/more) - Sacar el máximo rendimiento al producto. Entrega económica de valor a largo plazo y a gran escala.


Estas fases muestran tres momentos en los que puede estar un producto, de modo que el discovery del proyecto debe adaptarse a la fase en la que se encuentra: explore, expand o extract. Teniendo en cuenta que la calidad (better) debe estar intrínseca en cualquiera de las etapas.

blog_discovery_2

Inception Deck

Para ejemplificar acciones que se pueden tomar al plantear un discovery, López introdujo el Inception Deck. Conjunto de dinámicas que permiten la recogida de información para establecer propósitos y objetivos, y en las que todo el equipo debe participar por igual. Consta de 10 pasos:

1. ¿Por qué estamos aquí? - Recopilación de objetivos. Encontrar un objetivo único, claro y cuantificable para todo el equipo. 

2. Elevator pitch - Definición del producto. Enumerar cualidades del proyecto para que todos tengan una definición clara de lo que es. A quién va dirigido, competencia, características únicas etc.

3. Product box - Enumerar los puntos claves del proyectos. ¿Cómo lo venderías?

4. Not list - Una lista de lo que no entra dentro del proyecto para limitar un scope. Ayuda a dinamizar las comunicaciones.

5. Meet the neighbors - Identificar el mapa de todas las personas que influyen en el proyecto. Tenga en cuenta a todos aquellos que puedan verse afectados por el proyecto o que tengan un impacto en el mismo.

6. Show solution - Un approach a gran nivel de cuál sería solución. No tiene que ser el producto final, sino una primera aproximación. 

7. Up at night - Hacer un análisis de los posibles riesgos que pueden afectar al proyecto. Tener claro qué probabilidad hay de que ocurran y qué tan graves son. 

8. Size it up - Estimar la magnitud del proyecto y el tiempo que llevaría realizarlo. *López no enfatiza este paso porque considera que no es de gran aporte. 

9. What' going to give - Establecer que cualidades o características son indispensables y marcan de cierta manera el rumbo y las decisiones sobre la solución. Nuestros 'trade off'.

10. What going to take - Estimar el coste del proyecto y las decisiones que implica este compromiso. *López no destaca este paso porque considera que no es de gran aporte. 

Otras herramientas que mencionó como de gran importancia y utilidad dentro de un discovery son el User Persona y el User Story Mapping. Las cuales nos permiten definir el perfil de nuestro usuario final, el recorrido que sigue con el producto y en qué áreas podemos ofrecer una mejor experiencia.

Este encuentro formó parte del circuito de Agile Project Managment que busca ofrecer recursos útiles para trabajar con proyectos ágiles de forma efectiva. Si te interesa revisar más contenidos sobre este circuito lo puedes hacer en nuestra página de Insights donde también encontrarás videos de sesiones pasadas y podcasts. Además, si quieres que te hagamos llegar contenido relevante para inspirarte suscríbete a nuestra newsletter. 

Aquí te dejamos el vídeo de la sesión completa y la presentación para que puedas repasar conceptos:

 

Revisa también el meetup sobre el Pensamiento Lean en el desarrollo de software:

 

Bibliografía:

Publicaciones relacionadas