Esta es una traducción del artículo original The Agile Inception Deck de Jonathan Rasmusson.
Una de las áreas en las que las metodologías ágiles no dicen absolutamente nada es el arranque del proyecto. A continuación, encontrarás un método sencillo que puedes utilizar para llenar ese vacío y conseguir que tu proyecto vaya en la dirección correcta mucho antes de escribir la primera línea de código.
10 preguntas que debes hacer al principio de tu próximo proyecto
Empieza con optimismo. A medida que empieza tu proyecto, tú y tu equipo estáis en sintonía. O eso parece. Entonces empezáis a construirlo y te das cuenta de que todos teníais algo diferente en mente. ¿Te ha pasado?
¿Cuántos de tus proyectos empiezan así? Tú y tu equipo os reunís al inicio del proyecto pensando que estáis todos en sintonía…
…y cuando empezáis a construir algo, te das cuenta de que estabais pensando en algo totalmente diferente.
Esto ocurre todo el tiempo en los proyectos: suponer que hay consenso cuando en realidad no es así.
Mientras los buenos equipos pueden empezar con estos problemas y adaptarse a medida que avanzan, es un defecto que puede herir o matar a los incautos antes incluso de que crucen la puerta.
Para cortar este problema de raíz, cuando estaba en ThoughtWorks, creamos una herramienta ligera para el arranque de proyectos llamada “The Agile Inception Deck: 10 preguntas y ejercicios que sería una locura no llevar a cabo antes de empezar tu proyecto”.
Estas preguntas tienen dos objetivos: el alineamiento y el ajuste de las expectativas.
El alineamiento trata de hacer que tú y todos los demás estéis en sintonía con respecto a porqué estamos aquí, qué tratamos de hacer y cómo lo vamos a conseguir. Cosas básicas.
El ajuste de las expectativas, por otro lado, trata de comunicar de forma clara con tu equipo y los demás stakeholders (interesados) qué necesitamos para que el proyecto sea un éxito. Estás definiendo las reglas del combate.
Sí que podemos construir esto para ti. No, no debería ser muy difícil. Esto es lo que vamos a necesitar…
Necesitas tener esa conversación pronto y asegurarte de que tus clientes saben lo que necesitarás para serviles mejor. No lo des por hecho. Sé explícito y pregunta.
¿Cómo sabes lo que tus clientes necesitan realmente? Una buena forma de empezar es preguntarles:
1. ¿Por qué estamos aquí?
No se puede construir un gran producto si en primer lugar no sabes por qué lo estás construyendo. Preguntar el porqué te dará a ti y al equipo el contexto necesario para tomar las mejores decisiones durante la ejecución.
Por ejemplo, digamos que fuisteis contratados por una empresa de construcción para crear un sistema en línea para el mapeo de carreteras que fueron cerradas temporalmente en una obra determinada.
Una pregunta obvia que os ayudaría a ti y al equipo a construir la solución es “¿por qué?”: ¿Por qué la empresa está gastando el capital de los accionistas en este proyecto en primer lugar?
¿Se trata de la seguridad? ¿Es un requisito legal? ¿O se trata de actuar como un agente de tráfico para mover eficientemente materiales y bienes en el lugar de la obra?
Conocer y entender el requisito principal detrás del proyecto te dará la visión necesaria para hacer las compensaciones que inevitablemente vendrán durante la entrega de una forma equilibrada. No podrás hacerlo si no sabes el porqué.
2. Crea un Elevator Pitch
Los proyectos pueden ser muchas cosas para mucha gente. Este ejercicio trata de hacer que no sea así.
Un buen elavator pitch (discurso de ascensor) cuenta a los demás qué es el producto, para quien es, por qué es especial aproximadamente en el tiempo que dura un viaje en ascensor.
Crear uno bueno puede ser más difícil de lo que imaginas. Sin embargo, una vez lo logras te sentirás muy bien. Podrás sintetizar de forma rápida un concepto abstracto grande (que es como empiezan la mayoría de los proyectos) en algo ajustado, real y concreto.
3. Diseña una Product Box
Reflexionar sobre el producto desde la perspectiva del cliente siempre es interesante. La construcción de una product box no solo te pondrá en la cabeza de tu cliente, es un gran ejercicio para la formación de equipos, a medida que das permiso para dibujar y colorear en el trabajo.
No tienes que conseguir algo muy elaborado ni complejo. Simplemente pregúntate:
- ¿Cuáles son las tres razones más importantes por las que van a comprar este producto?
- Si hubiera un slogan que resumiera el espíritu de esto, ¿cuál seria?
4. Crea una NOT List
Decir que sí es fácil. Lo difícil es decir no. La NOT List empieza a poner marcas en el terreno para establecer las expectativas sobre lo que no va a ser parte de este proyecto.
Decir lo que no se va a hacer es muy efectivo. Elimina de antemano una gran cantidad de desperdicios al permitir que el equipo se centre en aquello que está claramente IN scope (dentro del alcance), ignorando aquello que está OUT. A partir de la columna IN fluirán todas tus historias de usuario de alto nivel.
Además, no es raro encontrar muchas cosas que podrían estar dentro del alcance pero por alguna razón (normalmente tiempo y dinero) no están. Es mejor resolver esto ahora que dejarlo para más tarde.
Este ejercicio realmente define las “grandes piedras” del alcance. Lo que estás diciendo aquí es: “Si movemos estas piedras como parte del proyecto estaremos bien”.
5. Conoce a tus vecinos
Una vez casi pierdo un proyecto porque no me había dado cuenta de que la comunidad en torno a un proyecto es siempre más grande de lo que piensas. Es fácil creer que todo gira en torno a ti y al núcleo de tu equipo, pero la realidad es que la mayoría de los proyectos requieren más que solamente la gente del día a día para ser un éxito (sobre todo en las grandes empresas).
Este ejercicio trata de conseguir que tú y tu equipo penséis de antemano a quien vais a necesitar conocer y que establezcáis relaciones con ellos antes de empezar. Esto no es solamente por cortesía, les permitirá prepararse para tu llegada y estar ahí para cuando les necesites.
6. Muestra la solución
Eliges la arquitectura cuando eliges a tu equipo, así que mejor asegúrate de que todos estáis de acuerdo con la solución antes de empezar.
Este ejercicio trata de dar a conocer tus cartas. Si estás pensando en resolver este proyecto con un conjunto de herramientas o arquitectura, lo mejor es decirlo cuanto antes. No te gustaría que te pillasen con la guardia baja por culpa de algún estándar corporativo.
También es una oportunidad para aclarar cualquier cosa si no tienes todas las respuestas (¡no pasa nada!), que se sepa.
7. Pregunta qué nos quita el sueño
Hay miles de cosas que podrían estar mal en nuestros proyectos. Algunas las podremos controlar, otras no. Este ejercicio trata de asegurar que identificamos los riesgos por los que merece la pena preocuparse y los que no.
Por ejemplo, no se puede hacer mucho para prevenir el colapso de la economía, o que tu cliente sea promovido a vicepresidente de ingeniería. Así que no te preocupes.
Tener miembros del equipo ocupados a tiempo completo, sin embargo, es algo que puedes gestionar y por lo que vale la pena luchar.
Esta es tu oportunidad para desafiar a la locura antes de que el proyecto empiece y luchar por aquello que vas a necesitar para hacer del mismo un éxito. Puede que no recibas todo lo que pidas, pero por pedir que no quede.
8. Examínalo
Este ejercicio trata de responder a la pregunta: ¿cómo de grande es esto? No podemos decir exactamente cuántos días va a durar este proyecto de principio a fin, pero podemos decir si será sobre 3, 6 o 9 meses.
Para este ejercicio necesitarás planificar y estimar a alto nivel. La NOT List te vendrá bien en este punto. Tendrás que llegar a algunos números de alto nivel para dar a los interesados al menos una idea del tamaño del proyecto y lo que están buscando.
La clave aquí no es la precisión, sino determinar si el proyecto es realmente factible con tus recursos.
9. Sé claro sobre lo que vas a dar
Todos los proyectos tienen palancas como tiempo, dinero, alcance y calidad. Es mejor saber qué es lo más importante, y con cuáles podemos jugar.
En algunos proyectos lo único que importa es el dinero. En otros, lo más importante es la fecha de entrega.
Necesitas tener esta conversación cuanto antes para saber si, cuando la cosa se ponga fea, podrás ser flexible con el alcance (preferible) o tendrás margen de maniobra en torno a la fecha.
Otro tema que debes debatir: ¿qué es lo que realmente haría que este proyecto fuese un gran éxito? ¿Su facilidad de uso? ¿Sencillez? ¿Velocidad? ¿Flexibilidad? ¿Seguridad? Escribe estas cosas y asegúrate de que están en la mente de todos antes de empezar. Estas aspiraciones de alto nivel pueden ser tus señales cuando el camino se vuelva oscuro.
10. Muestra lo que os va a llevar
Este ejercicio trata sobre dos cuestiones que ocupan la mente de todos los stakeholders: ¿Cuánto tiempo nos va a llevar y cuánto nos va a costar?
Si se trata de una parte de un proyecto, puede que el presupuesto ya haya sido establecido. En este caso todo lo que necesitas hacer son algunas cuentas en un papel para saber si el proyecto es factible con las cartas que te han dado.
Esta es una oportunidad para explicar qué tipo de equipo necesitarás para sacar el proyecto adelante. En este momento se pueden establecer expectativas en torno a las dimensiones del equipo, conocimientos y habilidades transversales necesarias para el desarrollo del proyecto.
Se trata de conseguir la gente adecuada en el autobús
Hacer un Inception Deck para tu proyecto no es magia. Es simplemente cuestión de conseguir la gente adecuada en una habitación, hacerles preguntas difíciles y luego compartir los resultados con tus stakeholders y todos los demás del equipo.
Puede llevar desde un par de días hasta una o dos semanas en completarse y normalmente es bueno hacerlo durante planificaciones de 3 a 6 meses. Sin embargo, es una valiosa herramienta para establecer las expectativas iniciales de tu proyecto, y para recordar a los demás de qué vas tú y de qué va tu proyecto.
Así que antes de iniciar tu próximo proyecto ágil, asegúrate de hacer primero las preguntas difíciles y conseguir alinear a todos. Te verás como un profesional y prepararás tu proyecto para el éxito mucho antes de que se escriba la primera línea de código.
¡Gracias Jonathan Rasmusson por darme permiso para realizar esta traducción de su artículo original The Agile Inception Deck!
¡Gracias también a Maialen Muñoa por ayudarme con la traducción!
También te puede interesar mi artículo Inception Deck - Actividades para una reunión productiva.