top of page

¿Los Emprendedores, los Informáticos y los Diseñadores Nos Podemos Complementar o No?

Actualizado: 19 ene 2022



Hace casi un año me tenté en comprar por Amazon el libro: Lean vs. Agile vs. Design Thinking de Jeff Gothelf. Me llegó rápidamente pero al abrir la caja de envío me encontré con la sorpresa de que… TENÍA SOLO 62 PÁGINAS (todo esto lo cuento en el vídeo: https://www.youtube.com/watch?v=wlNJ8GtMapI&list=PL7Pu6zXV4tEexzskUS7E4ohMG3X6qUH5h&index=12 publicado en nuestro Canal de YouTube).


Sin embargo, pese a lo breve del texto descubrí que había valido la pena comprarlo ya que el autor (que según la biografía incluida en la última página ha estado más de 20 años aportando para la creación de un esquema basado en el cliente para la estrategia de producto, diseño y liderazgo) hace una excelente explicación de cómo se pueden complementar los Emprendedores (representados por Lean), los Informáticos (representados por la Agilidad) y los Diseñadores (representados por Design Thinking).


El motivo de compartir este comentario con ustedes es presentarles algunas valiosas ideas al respecto ya que en nuestro quehacer diario es bastante probable que tengamos contactos directo tanto con Emprendedores como Diseñadores. De hecho tenemos algunos Diseñadores en la Comunidad y espero que la mayoría de los afiliados hagan sus propios emprendimientos alguna vez.


Para comenzar quiero llamarles la atención respecto a la imagen incluida al inicio del comentario ya que en ella se plantea que: Design Thinking permite explorar el problema, Lean permite descubrir que es lo que se debe construir y la Agilidad permite construir lo que se necesita correctamente.


De hecho la primera conclusión evidente es que: Design Thinking, Lean y la Agilidad se complementan. Por lo tanto si asociamos a cada uno de los conceptos una diferente profesión resulta obvio que estas tres también lo hacen.


Habiendo dicho eso quisiera compartir una de las interesantes reflexiones que Jeff Gothelf incluye en el libro.


Lo primero a mencionar es que el libro comienza con una anécdota donde Jeff cuenta que en 2016 (un año antes de escribir el libro) estaba conversando con un cliente que le contó que “Nuestros equipos técnicos están aprendiendo métodos ágiles. Nuestros equipos de producto están aprendiendo métodos Lean, nuestros equipos de diseño están aprendiendo pensamiento de diseño (N del A: se refiere a Design Thinking). ¿Cuál de los tres es el correcto?” (Gothelf, Jeff, p. 4)


La respuesta lógica es que los tres temas se complementan… si parece tan obvio, ¿por qué el cliente sintió que se interponían unas a otras y había que quedarse con una sola?


La razón es porque el cliente siente que las tres técnicas iban a ritmos distintos.


¿Por qué? Porque la Agilidad se enfoca en entregar código sin errores cada ciertos períodos fijos (en el caso de Scrum estos son de 1, 2, 3 o 4 semanas). Lean por su parte tiene más que ver con eliminar los desperdicios de lo que se construye (no olvidar que el concepto Lean se refiere a realizar una mejora continua para eliminar todo aquello que no aporta) y por su parte Design Thinking se enfoca en incluir al usuario final del proyecto para validar el problema-solución definido.


El autor ofrece entonces una forma de ver el complemento de estas tres disciplinas y a partir de eso de los tres profesionales que las representan.


Luego de desarrollar esta lógica durante el texto (que además de la brevedad se lee muy fácil por la claridad de las ideas expuestas) el autor lo remata con la siguiente frase:


“Al final del día, a tus clientes/usuarios no les importa si practicas Agile, Lean o Design Thinking.


Lo que les importa son los buenos productos y servicios que resuelven de forma efectiva problemas significativos para ellos” (Gothelf, Jeff, p. 58)


Luego aconseja enfocar a los equipos de proyecto (independiente de los profesionales que los conformen) a satisfacer las necesidades de los consumidores mediante la colaboración.


Para terminar les comparto la lista de recomendaciones que hace Jeff Gothelf, las que desarrollo extensamente en el vídeo ya mencionado 😊:


1. Trabajo en ciclos cortos: el software es complejo e impredecible, al igual que las personas.

2. Haz retrospectivas regularmente: estas reuniones son el corazón de la mejora continua.

3. Pon a los consumidores en el centro de todo: es quien ocupa el producto, es tan sencillo como eso.

4. Ve y observa: concepto japonés de salir de la oficina y ver cómo trabaja el equipo.

5. Balancea el trabajo de descubrir sobre el producto con el trabajo de generar y entregar el producto: prueba únicamente hipótesis de alto riesgo.

6. Haz menos investigación pero más frecuentemente: toma lo que aprendas de cada prueba y repítela la siguiente semana.

7. Trabaja (y entrena) como un equipo balanceado: el equipo lo forman diseñadores, ingenieros de software y gerentes de productos.

8. Transparencia radical: retrospectivas abiertas para que todos sepan dónde están los problemas.

9. Revisa tu estructura de incentivos: los equipos optimizarán el trabajo gracias a incentivos.

10. Haz el trabajo de descubrimiento de producto “ciudadano de primera clase”: el trabajo que se visualiza es el que se hace.

46 visualizaciones2 comentarios

Entradas recientes

Ver todo

2 תגובות


Enrique Muñoz
Enrique Muñoz
19 בינו׳ 2022

Buenos los tips Gerardo, se agradece.

לייק
Gerardo Cerda Neumann
Gerardo Cerda Neumann
20 בינו׳ 2022
בתשובה לפוסט של

Me alegro que te haya gustado Enrique. Nos ayuda a saber, como Informáticos, la forma de interactuar con otros profesionales. Especialmente con los Diseñadores. Saludos😀

לייק
bottom of page