nodos en la red

Kit AE [I]: Mapa de Entorno de Negocio / Matriz Poder x Interés

En las sesiones de trabajo con emprendedores ágiles tengo siempre 'a mano' un montón de prácticas, 'técnicas' o instrumentos, muchas de ellas procedentes de disciplinas alejadas del Entrepreneurship o de los enfoques Agile, identificadas a lo largo de dos décadas de carrera profesional en Consultoría.  Son cosas sencillas, que ayudan, sobre todo, a pensar con claridad.  En muchos casos el resultado es lo de menos.  Lo importante es el proceso.  La conversación.

Una práctica que casi siempre resulta de utilidad es la de crear una representación gráfica, un esquema, que identifique a las partes interesadas en la iniciativa emprendedora.  Llamo 'partes interesadas' a aquellas personas o grupos de personas, organizaciones, colectivos, etc, que pueden verse influidas o pueden influir en el desarrollo de dicha iniciativa.  Es una versión 'lite' del tradicional Stakeholder Mapping que toda persona con formación básica en Project Management conoce como una actividad más de un proceso de Stakeholder Analysis.  En este caso hablamos del Mapa del Entorno de Negocio, que algunos denominan 'ecosistema de negocio'.

20 principios para el Emprendedor Ágil [alpha release]

1. Decide, antes de empezar, cuándo vas a tirar la toalla.
2. Tu producto no es el Producto: tu Modelo de Negocio es el Producto.
3. El único plan que vale es aprender a medida que avanzas.
4. No esperes a estar preparado para empezar.
5. No necesitas ese dinero [todavía].
6. La verdad está ahí fuera [así que sal a la calle!].
7. Un emprendedor necesita amigos [redes sociales amplias, diversificadas, de calidad].
8. Averigua dónde les duele [y asegúrate de que les duele mucho].
9. Céntrate [no, en serio: céntrate].
10. Haz más, más rápido.
11. No hagas planes, haz prototipos.
12. Simplifica [al máximo].
13. Entrega pronto [y a menudo].
14. Obsesiónate con las métricas [las pocas imprescindibles].
15. Obtén feedback pronto [y a menudo].
16. Equivócate pronto [y aprende rápido].
17. Vuelve a empezar otra vez [y sigue aprendiendo].
18. Manténte pequeño [hasta que ya no debas seguir siéndolo].
19. Cuídate [mantente en forma, come sano, descansa].
20. Desconecta de vez en cuando.

Y a manera de corolario: búscate pronto un buen abogado.

Documentar otras hipótesis del negocio

Continuando con la última entrada, veremos ahora cómo trabajar con las hipótesis relacionadas con la creación, promoción y venta de vuestro producto.  Siguiendo el trabajo de Brant Cooper & Patrick Vlaskovits, autores de la muy recomendable 'Entrepreneur's Guide to Customer Development', hablaremos de tres grandes conjuntos o categorías de hipótesis: las relativas al negocio; las que hacemos sobre nuestro producto [p.ej., el conjunto de funcionalidades requerido para completar la primera iteración del Producto Mínimo Viable] y las relacionadas con el proceso de adquisición de clientes, también denominado 'embudo' ['de ventas'].

Documentar las hipótesis C-P-S

A estas alturas, los hipotéticos lectores saben perfectamente que el elemento más importante de un plan de negocio son los supuestos, que también llamamos hipótesis, sobre todo lo referente al negocio.  Me repito, lo sé.  Y, sin embargo, repetir esto en cada foro al que me invitan a hablar no hace más fácil el trabajo para el emprendedor. Vamos a dar una vuelta más al tema de los supuestos o hipótesis, comenzando por los relativos al combinado Cliente - Problema - Solución [C-P-S].

Agile Practices for Business Planning

Este esquema, de elaboración propia, recoge las prácticas "ágiles" que he encontrado más útiles a la hora de gestionar el desarrollo de un Business Plan (BP) para una iniciativa emprendedora de carácter innovador.  Todas son bien conocidas por los familiarizados con las metodologías ágiles de desarrollo de software y/o gestión de proyectos.  Algunas [p.ej., "Propiedad Colectiva", "Integración contínua", "Refactoring"], son más difíciles de adaptar a la tarea específica de elaborar un BP que otras [tal vez debería decir: más difíciles de aceptar por el equipo], pero en general todas se trasladan bien.

El corazón del sistema es la Pila de "producto", el artefacto en el que se recogen los diferentes componentes de la entrega final [p.ej., test de hipótesis de mercado nº17 o previsión Free Cash-flow], con el detalle apropiado, estimados y ordenados por prioridad [y sí, lógicamente, también existe la correspondiente "Pila de Tareas", lo que en Scrum denominaríamos un Sprint Backlog, que no aparece explícitamente reflejada en el esquema]. Aspectos que pudieran considerarse 'menores', como la insistencia en mantener un "Diseño simple", el establecimiento de unas pocas reglas de estilo  o de un "Vocabulario común" proporcionan sin embargo un gran retorno, en términos de ahorro de tiempo y esfuerzo, así como en la mejora de la comunicación.  He encontrado útil, en el marco de las labores de tutorías, facilitar al equipo emprendedor algún ejemplo durante los trabajos de preparación.

Organizar el tiempo disponible en períodos claramente delimitados [ej, 'Sprints'], siguiendo un proceso iterativo, con entregas frecuentes... ha dado resultados fantásticos.  Introduce en el equipo una sensación de "metodización", un ritmo de trabajo, una disciplina, que la mayoría agradece.  En realidad, no creo que haya forma mejor de desarrollar el Business Plan de una nueva empresa innovadora.  Para el que tenga curiosidad, he utilizado iteraciones de una o dos semanas. A menudo he empezado con  iteraciones de una semana, ampliado a dos tras unas pocas iteraciones, para regresar a las iteraciones más cortas poco antes de la fecha prevista de entrega.

Reservar un tiempo para reflexionar sobre el proceso es [Retrospectivas], en mi opinión, imprescindible.

He rodeado con un trazo más grueso aquellas prácticas que me han parecido especialmente útiles, pero tened en cuenta que unas prácticas necesitan o apoyan a otras, por lo que no son igualmente efectivas si se utilizan de forma aislada.  Las flechas indican aproximadamente esas relaciones de soporte entre una práctica y otra. 

Sigo trabajando en esto.

Agile De Bono

Creo que todos los convencidos de los métodos ágiles valoran la importancia de las retrospectivas, esas reuniones de trabajo de corta duración en las que el equipo mira hacia atrás y se pregunta por lo que salió bien, lo que podría mejorar y lo que debería hacerse para mejorar el proceso o cualquier otro aspecto que influya en el rendimiento del equipo [por ejemplo, no es broma, la comida o la necesidad de ajustarse a los horarios, tomarse tiempo para descansar].

Cuando se trata de hacer una retrospectiva de proyecto, de una iteración larga o de una 'release', un sistema que me gusta utilizar es el de construir una 'línea de tiempo' en la que miembros del equipo [u otras partes interesadas] escriben en tarjetas o post-its aquellos sucesos que consideran especialmente memorables o importantes y los sitúan, por ejemplo a lo largo de una pared, en orden cronológico [aproximado].  En la retrospectiva puedes solicitar del equipo que utilicen sólo los hechos o que hablen también de cómo recuerdan haberse sentido [mad, sad, glad, etc].

Pues bien, una variante que he empleado de este ejercicio utiliza los Seis Sombreros para Pensar de De Bono, probablemente la técnica de pensamiento lateral más conocida, más [y peor] utilizada del mundo.  En realidad, TODAS las herramientas de De Bono, desde el OPV al PMI, pasando por lo que quieras, pueden utilizarse en un momento u otro, en el ámbito del Project Management.

Agile Entrepreneur

Supongo que nadie se escandalizará si digo que la mayoría de los planes de negocio (BP) elaborados por emprendedores y/o profesionales del entorno sirven de poca o ninguna ayuda a la hora de dirigir el proyecto de creación de una nueva empresa.  Por lo general, un BP se hace, se encuaderna y se guarda en un cajón.  Años después aparece, lo revisas y te echas unas risas.  Sencillamente, la incertidumbre que rodea la puesta en marcha de una empresa es de tal calibre que no hay estimación o predicción que sobreviva intacta más allá de algunos meses [¿semanas? ¿según salga de la impresora?].  No es que las proyecciones a 3 o 5 años sean pura patraña, es que hay problemas con las previsiones a 1 año.

Pero no hablo sólo de las cifras.  He visto una y otra vez como el equipo emprendedor ha tenido que ir adaptando sus estrategias, su modelo de generación de ingresos o, incluso, la propia idea del negocio en el primer año de vida.  Y me refiero a empresas que han ganado premios en certámenes de Entrepreneurship, que han obtenido un NEOTEC o un préstamo participativo de ENISA y/o que están participadas por Capital Riesgo.  Es decir, estoy hablando de start-ups que han hecho sus deberes, han dedicado un tiempo y/o unos recursos preciosos a la elaboración de impecables planes de negocio [que muy pocos leerán, como sabemos].

Entre todos [profesores, consultores, profesionales del mundo del capital riesgo, empleados de entidades financieras, etc] mantenemos vivas una serie de prácticas que, en el mejor de los casos, aportan poco valor a ninguna de las partes interesadas.

¿Cómo de bueno eres estimando?

Cuando te ves obligado a hacer una estimación, ¿Cómo sabes hasta qué punto puedes fiarte de ella?  Es de suponer que estás estimando algo de lo que tienes un mínimo conocimiento.  Por ejemplo, la duración o el coste de una actividad en un proyecto.  Por regla general, tendrás al menos una idea de los límites en los que se puede mover el valor que tratas de estimar, eres capaz de decir si una cifra dada es imposiblemente grande o ridículamente pequeña.  Pero, de nuevo, ¿Cómo de bueno eres estimando?

Minimum Viable Product [revisado]

Recientemente tuve la oportunidad de debatir con un reducido [pero selecto] público acerca del concepto 'Minimum Viable Product' (MVP), una idea de la que se ha hablado bastante en los últimos meses en gran medida gracias a una entrevista que hicieron a Eric Ries los chicos de Venturehacks.

En estos momentos hay suficiente información disponible en el dominio público sobre MVP, desde una mini-guía  elaborada por el propio Eric, hasta un buen artículo introductorio en la Wikipedia, como para que no sea necesario extenderse demasiado en esta entrada [pero al final lo haré, me conozco!].

En los orígenes del paradigma "ágil"

Imagino que a estas alturas todos los hipotéticos que andáis interesados, como Juan, Ángel y yo mismo en las múltiples derivadas del paradigma "ágil" en la gestión estáis al tanto de la publicación, por parte del SEI, de un documento bastante majo que resume la posición oficial del Instituto con relación al tema "ágil".  Por cierto que uno de los autores es mi muy estimado David Anderson [o al menos lo era, hasta que me he enterado de que se ha pasado al lado oscuro... ved los comentarios de Juan Palacio], uno de los primeros que se atrevió a hablar de TOC para el desarrollo de Software.