Investigación, prototipos y un alcance que se puede cotizar.

Qué te llevas al final

Cinco cosas, y cada una es un objeto que alguien puede usar, no la descripción de lo que hicimos.

• Un orden de releases

  Qué se construye primero, y la razón por la que va primero. Normalmente esa razón es el riesgo en las integraciones y no lo que se ve terminado antes.

• Una estimación, con sus supuestos

  Qué cuesta la primera release en tiempo y dinero, y la lista de cosas que cambiarían ese número si resultaran distintas.

• Un backlog

  Épicas e historias al nivel que se puede estimar de verdad, y no una lista de funcionalidades que después hay que volver a deducir.

• El mapa de integraciones

  De qué sistemas tiene que leer el producto y en cuáles tiene que escribir, qué puede hacer ya cada uno, y cuáles nadie revisó todavía.

• Un prototipo que la gente usó

  Clickeable, de punta a punta, puesto delante de las personas que lo usarían, no un recorrido mostrado a quienes lo encargaron.

Tres respuestas que esto puede dar, y una nos cuesta el desarrollo

Un discovery que sólo puede terminar de una forma no es un discovery. Es la primera factura de un proyecto que ya estaba decidido.

1. 01

   Constrúyelo, y éste es el orden

   El concepto se sostiene, las integraciones son alcanzables y el trabajo puede empezar. Lo que agrega el discovery es la secuencia: qué release va primero, de qué depende y cuánto cuesta la primera.

   El caso habitual, y el que todos planifican.

2. 02

   Construye menos

   A veces una parte de lo que se pidió ya existe como producto maduro, e integrarlo cuesta una fracción de construirlo. A veces la primera release sólo necesita un tercio del alcance para valer la pena. Las dos respuestas achican el proyecto.

   En una plataforma para pacientes que necesitaba consultas por video, recomendamos integrar un proveedor especializado en vez de construirlo desde cero.

3. 03

   Todavía no

   La idea es clara para quienes la tienen y no está probada con quienes la usarían. Entonces la salida honesta es un prototipo y un conjunto de hallazgos, y el desarrollo espera a que vuelvan.

   mEMR llegó con un concepto de producto liderado por médicos. Hicimos la investigación y construimos prototipos de alta fidelidad para probarlo con médicos y pacientes antes de escribir una línea de código.

Cuándo vale la pena hacerlo

Tres situaciones donde el costo de enterarse después es mucho más alto que el costo de enterarse ahora.

• Quienes lo usarían no lo vieron

  Un concepto puede ser claro para los fundadores y estar equivocado sobre el flujo de trabajo en el que tiene que encajar. Cuando los usuarios son médicos, o inspectores, o cualquiera cuyo día el producto tiene que sobrevivir, la distancia entre una idea bien argumentada y una usable es donde desaparecen los presupuestos.

  Para eso sirve un prototipo: no es una demo, es un instrumento para enterarse temprano.

• Tiene que conectarse a sistemas que nadie abrió en años

  La capa de integración es donde se deciden estos proyectos. Qué puede exponer ya un sistema, qué no, y quién tiene que aprobar la conexión son preguntas de respuesta larga, y encontrarlas durante el desarrollo convierte un cronograma en una negociación.

  El discovery es donde se hacen esas preguntas, mientras las respuestas todavía pueden cambiar el plan.

• La primera release tiene que ser defendible ante alguien que no estuvo en la sala

  En las instituciones, el alcance lo aprueba gente que no fue parte de la conversación que lo produjo. Un backlog con una razón atada a cada prioridad sobrevive esa reunión; una lista de funcionalidades no.

  Esa razón es el entregable. Sin ella, la reunión reabre decisiones que ya estaban tomadas.