La Agile Inception

por | Abr 12, 2021 | Agile | 0 Comentarios

Los modelos tradicionales por fases estaban presentes en etapas mucho más tempranas que la construcción de software. La ideación de un producto estaba ocupada por largas fases de análisis y diseño cuya solución quedaba plasmada en grandes cantidades de papel. Pero esta documentación podía no ser consultada o creada por todas las partes interesadas, lo que a la larga traería problemas para el producto. Por suerte, los valores y principios Agile también llegaron a la conceptualización de producto.

En un artículo anterior te contábamos qué es la conceptualización y para qué sirve (Piensa en el usuario antes de crear producto). Recuerda que es el proceso para convertir una idea en un producto, donde se alternan fases de divergencia y convergencia para conseguir una buena solución. Pero, ¿qué tiene lugar en una conceptualización?

En 2010, Jonathan Rasmusson escribió su libro “Agile Samurai” donde recoge una serie de actividades que ocurren en una Agile Inception. Para lograr una buena conceptualización necesitarás identificar a las personas relevantes que tienen que participar de todas las partes del proceso.

Las primeras actividades hacen referencia al dominio del problema y su propósito es alinear a los participantes en cuál es el reto a resolver. El resto de actividades responden al dominio de la solución donde a partir de la información obtenida se empieza a construir un prototipo a muy alto nivel.

Dominio del problema

Para qué estamos aquí: con el objetivo de lograr una visión compartida del producto, se dedica la primera actividad a alinear a todos los participantes respecto a la idea del producto.

Elevator Pitch: ¿Cómo elaborarías un discurso de venta sobre el producto que estás conceptualizando? Para esta actividad, Jonathan Rassmusson propone utilizar la siguiente plantilla:

elevator pitch

Caja de producto: Imagina que tu producto tiene que mostrarse en un lineal de un supermercado donde está rodeado de productos de la competencia. ¿Cuál es su propuesta de valor? ¿Qué información debería mostrar? Con la metáfora de la caja de producto, se escogerá el eslogan y las frases claves para su propuesta de valor.

product box

Qué no es: para acotar las expectativas del producto, podéis comenzar por escribir lo que no es el producto. Después seguro que es más fácil describir lo que es. Incluso puede ocurrir que existan dudas. Todo ello lo podemos reflejar en una tabla así:

que es

Conoce a tus vecinos: en la última actividad del dominio del problema identificarás a las personas involucradas en el producto y el nivel de participación, desde los que participarán en el día a día hasta los que únicamente necesitan estar informados. Puedes representarlo en círculos concéntricos.

Dominio de la solución

Solución de alto nivel: para comenzar en el dominio de la solución, qué mejor forma que crear un primer boceto de cómo sería el producto. Es probable que necesites involucrar a parte del equipo que construirá la solución.

¿Qué nos mantiene despiertos por la noche?: Para asegurar que el producto sea un éxito, se debe hacer una gestión de riesgos identificando sobre cuáles se puede actuar y cuáles se escapan del ámbito de actuación. El resultado será una serie de métricas que te permitirán identificar cuándo aparecen esos riesgos durante la construcción del producto.

Mídelo: Con la información que has recibido hasta ahora puedes dar una estimación aproximada del tamaño de la solución en términos temporales e identificar posibles hitos que se necesiten cumplir.

Trade-offs: Dentro de un proyecto hay un montón de dimensiones que pueden actuar: alcance, coste, tiempo, presupuesto, … En esta actividad se establecerá sobre cuáles hay poder de negociación y cuáles son innamovibles.

trade off

Cuánto nos va a costar: Ahora que ya estás llegando al final del proceso, hay información suficiente para hacer una estimación de qué se necesitará para sacar adelante el producto: personas, materiales, infraestructura, licencias, … Y esto se puede empezar a traducir en coste para construir el producto.

Podemos encontrarnos con Agile Inception que se alargan desde varios días hasta varias semanas, en función del tamaño del producto, el conocimiento, la experiencia en este tipo de sesiones de co-creación, … Incluso, en algunas ocasiones, según se va obteniendo información sobre el producto puede llegar a darse el caso en que no tenga sentido continuar con su ideación y posterior desarrollo. Sin embargo, lejos de pensar que es un fracaso, estas actividades te han evitado construir un producto que no cubría las necesidades.

También puedes pensar en eliminar alguna de las actividades para acortar los tiempos del proceso. En ese caso piensa en qué conversaciones están dejando de ocurrir por esa decisión y qué impacto pueden tener en el producto final. Por supuesto, también puedes añadir más actividades, pero en ese caso identifica que su propósito no está cubierto ya por otro ejercicio y cuál es el resultado que esperas obtener.

0 comentarios

Enviar un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Aceptarás nuestra política de cookies si continúas navegando.

ACEPTAR
Aviso de cookies