Monogamia VS Poligamia

Dejando a un lado el Hype del Clickbait del título, en mi primera entrada en el blog me gustaría hablar sobre las dos corrientes que yo encuentro a la hora de trabajar con metodologías ágiles, la monogamia y la poligamia. Y para entender mejor qué significan estas dos palabras tan presentes hoy en día, vamos a empezar entendiendo el significado de cada una de ellas y adaptándolas al contexto que nosotros necesitamos para comprender estos dos tipos de corrientes.

MONOGAMIA: (del griego mónos, ‘uno’, y gamos, ‘unión’), puede ser definida como aquella forma de relación o costumbre de una determinada persona de establecerse con una SOLA pareja, rechazando desarrollar la misma clase de unión o las mismas acciones con otras personas.

Y ahora traduzcamos este significado al tema que nos concierne. En el ámbito del uso de las metodologías ágiles, una empresa monógama sería aquella que solo usa una metodología en su día a día y hace todo aquello que viene establecido se adapte o no a la organización. En estos casos la empresa se adaptaría a la metodología.

POLIGAMIA: (del griego «Polis» que significa «Muchos» y «Gamos» referente a «Unión”), es un tipo de relación en la cual se permite a una persona estar con VARIOS individuos al mismo tiempo.

Y haciendo el símil a nuestro objetivo, se podría decir de aquella compañia que usa una metodología como base y va cogiendo de otras los procesos que más les interesan, haciendo un mix que se adapta a la empresa y a lo que mejor le beneficia en la gestión de los proyectos. En estos casos la empresa adapta la metodología a la organización.

Y una vez explicadas cada palabra en el ámbito del uso de las metodologías ágiles, nos será más sencillo entender las dos corrientes que yo encuentro.

Desde que se puso de moda la transformación digital, y si, digo moda, porque para llevar a cabo una transformación digital en una empresa hay que entender que no es un cambio al uso, sino más bién una forma de entender la gestión del trabajo y para eso hay estar predispuesto al cambio desde la caballeria de la compañía hasta el soldado raso, es un cambio transversal, de cultura. Y es en ese momento, en el que se dividen las empresas entre la Monogamia y la Poligamia a la hora de usar metodologías ágiles.

Podríamos decir de una empresa monógama aquella que se sube a la ola de la transformación digital usando metodologías ágiles sin tener claro qué significa, sin un cambio en la gestión, sin un cambio de la estructura y sin entender lo que conlleva esta transformación siempre irán a contrapié y se centrarán en lo que hacen los demás sin pensar si esa metodología que están implantando les ayuda o en cambio, le está perjudicando. El problema recae cuando la empresa se adapta a la metodología, ya que hay que entender que algunos procesos nos ayudaran pero habrá otros que no se adapten a la forma de trabajar de nuestra organización. Y si queremos poner como ejemplo una de ellas, en mi opinión sería SCRUM, un marco de trabajo con unos procesos muy definidos y claros pero difícil de llevarlos a cabo si toda la organización no rema en la misma dirección.

En cambio, encontramos empresas polígamas comprometidas con su transformación, las que dedican tiempo a analizar tanto su organización como las demás, analizando el mercado, comprenden el cambio que conlleva pasar de una gestión tradicional al uso de metodologías ágiles. Por ese motivo, son organizaciones que se centran en analizar todas las opciones posibles y llegan a la conclusión, que según mi opinión es la acertada, de usar tantas metodologías ágiles como les convengan en sus procesos. Porque hay que entender, que para procesos creativos, procesos de ideación son mucho mejores metodologías como Design Thinking o Design Sprint, pero en cambio, para la gestión del desarrollo del propio producto/servicio usar Scrum hace la gestión mucho más sencilla pero siempre adaptandolas a los procesos de la empresa.

Y la conclusión a la que quiero llegar a la hora de clasificar las empresas entre la Monogamia y la Poligamia en el uso de metodologías ágiles, es la importancia que tiene analizar tanto la propia empresa como los procesos de trabajo ya que nos ayudará a elegir qué metodologías ágiles nos convienen y aquellos procesos que no, ya que usar algo solo porque es lo que hacen los demás o por no quedarse atrás, solo puede conllevar a que la gestión de los proyectos se vuelva mucho más complicada.

Y si hay alguna clave a la hora de utilizar metodologías ágiles, a mi modo de ver, es que siempre tenemos que lograr que la metodología se adapte a nuestra organización y no al revés.

Los 10 libros imprescindibles para los PRODUCT MANAGER

Hace hoy exactamente 25 años que celebramos el día internacional del libro con el objetivo de fomentar la cultura. Como dato interesante de por que lo celebramos el 23 de Abril, es porque coincide con el fallecimiento de dos de lo escritores más importantes de la historia: Miguel de Cervantes, William Shakespeare.

Cada vez que voy a alguna charla de Products Managers de empresas en las que me gustaría trabajar o veo como crean productos digitales excelentes, siempre me viene a la mente una pregunta: ¿Cuál será su libro preferido para aprender de producto o cuál es el que más le ha influido?.

A continuación, comparto con vosotros un listado de los libros imprescindibles que deberiamos leer todos los Product Manager, o al menos tenerlos en el radar por si algún dia tenemos un huequecillo para ellos.

1. El método Lean Startup

2. The Lean Product Playbook

3. Hooked: How to Build Habit-Forming Products

4. Inspired: How to Create Tech Products Customers Love

5. Growth Hacking: Supera el reto de crear productos digitales exponenciales

6. No me hagas pensar

7. Sprint: El método para resolver problemas y testar nuevas ideas en solo 5 días

8. CRO. Diseño y desarrollo de negocios digitales

9. User Story Mapping

10. Product Roadmaps Relaunched

DESIGN SPRINT para el desarrollo de productos digitales

¿Por que están utlizando tanto las empresas la metodologia Design Sprint a la hora de lanzar sus nuevos productos / Servicios?

Pues la razón es muy sencilla, están reduciendo al máximo la incertidumbre que puede conllevar lanzar un producto/servicio al mercado. Y ya no solo la incertidumbre, el uso del Design sprint hace que sepas con mayor certeza que es lo que están demandando los usuarios. Y que tiene Design Sprint que le hace especial o diferente, pues que todo se hace en 5 días, y el ultimo dia tendrás un MVP con el que poder testear y medir el producto desarrollado, para comprobar si es lo que están pidiendo los usuarios o si en contrario tienes que pivotar.

Esta metodología de diseño esta pensada para adaptarse a las fechas límite o deadlines del mercado laboral y por tanto hay que acortar el proceso para llegar lo mas rápido posible a una solución no desarrollada para prototiparla y poder testarla con usuarios reales. De esta forma, si el producto o servicio no funciona, se podrá reiterar lo antes posible y volver a empezar. Para usar de forma correcta la metodología hay que tener en cuenta los siguientes puntos:

• Que queremos validar, cual es el obejtivo: Debe ser claro y conciso
• El equipo: debe estar formado por personas de todos los departamentos que pueda afectar. Pero nunca debería ser mayor de 7 personas.
• 5 dias: Ni un dia mas, ni un dia menos. Es muy importante seguir todas las fases.

PERO, ¿POR DONDE EMPIEZO?

1. Comprender

El Lunes es el día del conocimiento, en el que con la ayuda del equipo deberéis detectar cuáles son los principales problemas que posan sobre la mesa, elegir solo uno en el que centrarse y recopilar toda la información que vayáis a necesitar y la que ya tengáis. Todos deben estar alineados y partir de la misma base de conocimiento para que el resto de pasos funcionen. Es importante que cada miembro pueda hablar durante algunos minutos sobre su enfoque y punto de vista. De este modo, todos tendremos el mismo conocimiento. Esta primera fase debe terminar con un documento en el que se definan sobre qué se actuará.

2. Esbozar

Después de tener claro cuál es el reto hay que empezar a enfocarse en las soluciones rápidamente Cada miembro del equipo tendra que trabajar de forma individual.Y deberá crear sus bocetos y después vendrá el momento de compartirlos con los demás. Se trata de bocetos rápidos para transmitir una idea por lo que no son necesarios conocimientos de diseño.

3. Decidir

En esta fase se determinará qué es lo que se va a prototipar para ello se tendrán que colar todos los bocetos de todos los participantes en la pared. Con esto se podrán visualizar todos los bocetos en conjunto y poder comparar unas con otros. De esta forma podremos someter las propuestas a votación y elegir una para el reto planteado el primer dia. Para poder votar las ideas de forma justa, se reparten un número de votos a cada miembro del equipo (pegatinas) que tendrá que colocar en las funciones o partes de las propuestas que más le interese, la más votada sale elegida. Esta parte del Design Sprint se llama Mapa de calor. Después de esto, hay que crear un storyboard, que básicamente consiste en un paso a paso del usuario por el prototipo que hemos decidido hacer en la siguiente fase.

4. Prototipar

Una vez ya tenemos una idea de cómo va a ser nuestra propuesta para validar el objetivo que nos marcamos el primer es el momento de prototiparla. En esta etapa todo ya estaría todo bien definido y todas las decisiones ya la habriamos tomado en el storyboard. Lo mejor para esta fase es dividir el equipo y asignar tareas especificas a cada uno de ellos. Es muy importante que alguien del equipo se centre en desarrollar la entrevista que se le hará a los usuarios cuando se les presente la solución que hemos desarrollado.

5. Testar

En esta estapa nos centraremos en observar a los usuarios como interactuan con el prototipo y coger todo el feedback que podamos de sus acciones y comentarios. Veremos si nuestro producto es viable o si por el contrario hay que modificarlo y pivotar de la idea incial que tuvimos.

Conclusión

Al llegar al último día del reto, veremos si nuestro producto es viable o si por el contrario hay que pivotar de la idia inicial que tuvimos. Entrevistaremos a los usuarios despues de haber utilizado el prototipo para entender sus sensaciones y concer si hemos logrado satisfacer sus necesidades o si en cambio, tenemos que hacer cambios.