Quería compartir con vosotros los aprendizajes de este último mes en el que he podido asistir al gigaTIC, AgilityTres60 (dónde Esther y yo pudimos realizar un taller sobre el uso del futuro) y un meetup que impartimos Aday y yo sobre Lean y LeanStartup.
Customer Development
Hoy en día, en Silicon Valley, cuando alguien tiene una idea trata de buscar financiación de terceros para poder crearla. Este modelo funciona dado el ecosistema de ese lugar. Sin embargo, no siempre ha sido tan bonito. A ráiz de las .com hubo resistencia en apostar por financiar ideas relacionadas con el software. La gente perdió la confianza en la tecnología debido a la burbuja lo que hizo que los emprendedores tuvieran que buscar nuevas maneras de financiación. Según nos contaba Aday, muchas personas que querían emprender tuvieron que encontrar nuevas formas basadas en el microfinanciamiento. Es decir, en vez de buscar grandes inversiones, se fueron a “la calle” a preguntarle a los usuarios por sus problemas de cara a generar software que solucionara problemas. De esta manera, surge el concepto de customer development (desarrollo de cliente). Al parecer, este movimiento tuve su origen unos años antes, y al igual que Agile, utiliza la iteración para trabajar con los clientes en sus necesidades e iterar en las soluciones que se les ofrece. Jutno al desarrollo de negocio y al desarrollo agile de software, componen lo que conocemos como Lean Startup.
A raíz de esta charla tan interesante que nos brindó Aday, tenemos que añadirle el concepto de Lean Thinking. Muchas organizaciones y profesionales piensan que Lean es una manera de eficientar procesos, esto es, reducir costes o aumentar la fabricación de producto. Realmente, la propuesta de Lean es anteponer la capacidad de entregar valor de manera contínua a nuestros clientes sobre eficientar los recursos (tener altos % de ocupación).
Con todo ello, nos damos cuenta que las empresas que son referencia en el mundo digital y aquellas que están naciendo, tienen muy claro que el usuario final es su cliente y es a quién debe atender, aportando soluciones a sus necesidades (qué es por lo que pagan). Sin embargo, estas conversaciones ocurren poco en la mayoría de empresas en las que he estado, al tener poca cultura de Desarrollo de Producto.
Logic Model: Medir y Conseguir el cambio.
Durante el Agility 360, Alberto Serrano nos facilitó un taller para explicarnos el modelo que usan desde Jerónimo Palacios & Associates para provocar el cambio de mentalidad. Según nos contó, mezclan el Logic Model con Evidence Based Management (EBM).
El taller consistía en hacer cuatro flipcharts donde co-creamos entre varios grupos diferentes mediciones que podemos hacer en base al logic model. En este caso, construímos cuatro grandes bloques:
- Actividades: ¿Qué acciones tomamos? Si hacemos Scrum, algunas acciones pueden ser los diferentes eventos de Scrum (Daily, Review, Retrospectiva o Planning), otras acciones pueden ser ¿Tenemos Product Owner?, ¿Disponemos de equipos multidisciplinares para entregar valor?. Este tipo de acciones nos indican el estado actual de una organización en base al estado de sus equipos. Medir las acciones nos da una información importante para entender los siguientes pasos.
- Output: Los outputs representan los resultados de esas acciones. Por ejemplo, de una Planning obtenemos el Sprint Backlog, el Sprint Goal y una predicción. Todos estos resultados no nos dicen nada sobre el éxito o no de lo que estamos construyendo. Sin embargo, medirlo nos ayuda a entender si estamos siendo efectivos con nuestras actividades. Si obtenemos 5 Sprint Goals quizás algo no está funcionado como querríamos.
- OutComes: Estos representan los resultados de valor que obtenemos. En este punto, mejorar la satisfacción de cliente o el número de clicks de la aplicación. Para los outcomes, Alberto nos contó que aquí aplican EBM. EBM nos proporciona un arquetipo de áreas que debemos estudiar en un Producto Software. Es importante que a la hora de desarrollar un producto digital, equilibremos estas áreas: valor actual, time-2-market, habilidad para innovar. Por ejemplo, si “machacamos” al equipo para desarrollar una funcionalidad muy rápido, podemos obtener mucho valor, pero generaremos deuda técnica que impacta en nuestra capacidad de innovar y de llegar a mercado rápido.
- Impactos: Por último, los impactos son los beneficios que aparecen a largo plazo, como puede ser aumentar los usuarios un 10%. Los impactos ocurren con el tiempo y en algunas organizaciones es donde ponen el foco.
Lo que aprendemos de este modelo es que, si queremos mejorar nuestros impactos, tenemos que poner focos desde las acciones, hasta todo el proceso intermedio para entender dónde están los puntos de mejora. ¿Medimos este tipo de cosas o nos centramos en alcance el fecha?
Necesidades actuales o necesidades futuras
Esther contó conmigo para un taller que ha diseñado en el que utilizar el futuro para tomar decisiones en el presente. Tuvimos la suerte de realizar el taller tanto en el GigaTIC y en el AgilityTres60. El taller propone varias dinámicas para pensar en el futuro y tomar acción en el presente a diferentes niveles: personal, producto y equipo.
La dinámica de producto trataba de acercarnos una reflexión sobre lo que necesitarán nuestros usuarios en el futuro. En grandes organizaciones, realizamos ejercicios como Design Thinking, Sprint 0 o Inception, tratando de cubrir las necesidades de nuestros usuarios hoy. Sin embargo, dado que su capacidad de entrega es baja por la cantidad de procesos existentes, para cuando se entrega el producto, las necesidades han cambiado y gran parte del trabajo pasa a ser inútil. En un gran banco en el que estuve, hicieron reconocimiento facial como proceso de autenticación, pero tardaron tanto en desarrollar que antes de ponerlo a disposición de sus usuarios, ya lo tenían todos los móviles implantado.
Inspeccionar el pasado para aprender y hacer mejor las cosas es parte de la mejora contínua, pero incorporar el futuro a esa inspección nos hace tomar acciones más inteligentes y nos lleven a un mayor éxito.
¿Que significa terminado?
Durante el AgilityTres60 pude participar en una mesa redonda cuyo debate giraba en torno a Definition of Done(DoD) y Continuos Delivery (CD). La única manera de saber si nuestro producto resuelve necesidades es dándoselo a un usuario y que nos diga su parecer. Scrum no obliga a que haya una entrega continua, pero si que fomenta que se haga lo antes posible de cara a poder iterar. Si nos gastamos todo el presupuesto en un producto y no funciona en el mercado, nos quedamos sin opciones para poder mejorarlo.
En esta mesa redonda vimos la importancia de que el DoD tienda a ser más amplio a medida que el equipo madura. Esto significa no solo que aumentemos parámetros como la cobertura de código o el número de test, sino también que acabemos incorporando la cultura de CD en el desarrollo.
Conclusiones
Estos eventos donde hemos participado nos ha permitido entender que el gran cambio en las organizaciones es el desarrollo de Producto versus el de Proyecto. Pensar en las necesidades de los usuarios sobre acabar en fecha. Seguiremos aprendiendo en futuros eventos. ¿Qué opináis de estas técnicas?
