Me acabo de levantar :). La culpa la ha tenido esto. La verdad que como dice Santiago, apetece dormir después de un buen trabajo y más cuando las cosas han salido bien. Pero una vez superado creo que ya que Diego le ha dado un enfoque real-time yo le daré un enfoque instructivo: » Como afrontar una demo». O dejar por escrito las cosas que se han de tener en cuenta aunque siempre acabes haciéndolo de la peor manera. Siempre dentro de mi modesto entender:
1º Analiza el objetivo de la demostración. A quien va dirigido y que es lo que quieres llegar a mostrar. En nuestro caso teníamos claro que la idea era demostrar con algo vistoso que nuestra plataforma funciona y permite crear un market place de dispositivos alrededor de un router permitiendo crear aplicaciones como churros. Este objetivo ha de ser transmitido a todo el equipo para que se sienta importante e involucrado en el proyecto. Sin ellos no hay demo (Gracias chicos :)).
2º Ten claro en que va constar la demostración y hasta donde quieres llegar. Aquí hemos fallado 🙂 Las ganas de hacer cosas crecían inversamente proporcional al tiempo que teníamos para desarrollarlas. La verdad que todo empezó con 2 o 3 ejemplos de aplicación que teníamos allí desordenados desde hacía tiempo y por el afán de innovación faltaban 12 horas para la demo y aún probábamos de añadir alguna cosa más. No es que me guste cortar el afán innovador del equipo, pero siempre he pensado que lo mejor es no cortarse en la definición, montar una lista (tan larga como uno quiera). Marcar las features mínimas para sentirse satisfechos y empezar a desarrollar hasta donde se llegue (Siempre superando ese mínimo).
3º Los timings de desarrollo. Sin querer fomentar los sobreesfuerzos en los equipos de trabajo… si alguna vez puedes pedirle un poquito más a alguien, este es el momento. Y así lo hemos hecho. Pero como siempre algo hemos hecho mal. No se si es por previsión o por sentirme más a gusto (Al fin y al cabo, las broncas por una mala planificación siempre caerán sobre mi persona). Pero el sprint final me gusta hacerlo el día D-2 🙂 Es decir, la penúltima noche. Parece una tontería, pero la sensación de riesgo, a 1 hora de la Demo y fallando todo por culpa de falta de sueño… no se la recomiendo a nadie :). Es jugársela… y que se te vaya todo a tomar por saco por culpa de una línea que has puesto 30 min antes de empezar la demo… crea inseguridad y desilusión en el equipo. También es cierto que la especie humana tiene la costumbre de dar el último esfuerzo en el último instante poniendo a prueba su «yo» interior :).
4º El plan B siempre debe existir :). Y nosotros finalmente no lo hicimos. Nos la juguemos a una sola carta :). Porque la solución de Diego de simular un accidente con los dispositivos no es buena solución (Aunque efectiva :))
5º No esperes con una demo mostrar todo lo que eres capaz. Porque ese no es el objetivo de una demo. Apóyate de una presentación, susténtate con un buen speach y hazle ver la mejora y el negocio a tu observador. Demuestra que tienes el enfoque de su mercado y que sabes lo que necesita para mejorar.
Y creo que con esto ya he hecho mi pequeña contribución a la comunidad :). Espero que os sea de ayuda. Y si alguien quiere añadir otros puntos al respecto… ya sabe…
Yo tambien escribo 