Design thinking para desarrollo de software final

1,817 views

Published on

Aplicación de Design Thinking al Desarrollo de Software - Webinar de Knowment

Design thinking para desarrollo de software final

  1. 1. en Desarrollo de Software Ezequiel Kahan – CSM, PMP
  2. 2. • Director y Fundador de Knowment. • Ingeniero y Magister en Psicología Cognitiva • Docente en la Universidad de Buenos Aires • Instructor y Coach en dirección de proyectos bajo enfoques tradicionales, Lean y Ágiles. • Más de 15 años de trabajo en Tecnología de Información. • Más de 10 años de experiencia en dirección de proyectos para empresas nacionales e internacionales • > 300.000 hs. entregados en proyectos y servicios • Miembro del PMI, PMIBA y de comunidad Agiles • Consultoría especializada en procesos de gestión de proyectos y del conocimiento • Cursos: Oferta regular, In-Company y a medida • Coaching y Mentoring a PM PMO • Facilitación www.knowment.net @knowment_la Ezequiel Kahan ar.linkedin.com/in/ekahan/ @soyezequiel
  3. 3. [ ¿Que es el diseño? ] http://www.flickr.com/photos/br1dotcom/5614565542/ http://www.flickr.com/photos/27620885@N02/2634223296 http://www.flickr.com/photos/27620885@N02/2652259246
  4. 4. [ ¿Que es el diseño? ]
  5. 5. [ ¿Que es el diseño? ] Diseño no sólo implica decisiones estéticas… también hay cálculo, ingeniería
  6. 6. El comienzo… http://www.flickr.com/photos/30247062@N03/8154631487/
  7. 7. [ Design Thinking ] “Design Thinking es un proceso para la resolución práctica y creativa de problemas que precisan un resultado futuro superior” Traducido de http://en.wikipedia.org/wiki/Design_thinking “Un acercamiento en equipo, iterativo para la innovación” SAP Presentation, Armin Heizl & Tobias Hildenbrand, 2012  Una forma de resolver problemas  Una manera de lidiar con la complejidad  Un método iterativo y empírico “Un conjunto de prácticas, acercamientos cognitivos y modos de pensar (mindset) ” Hassi & Lasko, 2011
  8. 8. Personas Espacio Proceso [ Design Thinking ] Innovación
  9. 9. Fuente: http://www.ideo.com/about/ [ Design Thinking ]
  10. 10. [ Design Thinking ] • Prácticas • Acercamiento Cognitivo • Mindset Hassi & Laasko (2011)
  11. 11. [ Design Thinking ] • Prácticas • Centrado en las personas • Pensar haciendo • Visualizar • Sintetizar • Estilo de trabajo Colaborativo • Acercamiento Cognitivo • Punto de vista Holístico • Pensamiento integrativo / Abductivo • Mindset • Orientado al futuro • Explorativo • Experimental Hassi & Laasko (2011)
  12. 12. [ Proceso de Design Thinking ] Definir alcance Investigar Sintetizar Idear Prototipar Testear Empatizar
  13. 13. [ DEFINIR ALCANCE ]  ¿Qué estamos tratando de lograr?  Conocernos como equipo  Fijar el objetivo común  Enfocarnos en la solución  Investigar rápido para validar  Planificar el proyecto, basándose en las etapas del proceso de D.T.
  14. 14. [ INVESTIGAR ]  Investigación, búsqueda, exploración  Entender a los interesados  Buscar a los usuarios  Expertos reales  Casos típicos  Casos extremos  Entender el mercado  Buscar situaciones análogas y adyacentes
  15. 15. [ INVESTIGAR ]  Empatizar es abrirse a la realidad del otro  Implica salir al mundo a relevar y ver los problemas/ oportunidades en acción  Somos empáticos cuando somos capaces de ver el problema con los ojos del usuario (Empatizar)
  16. 16. “salir al mundo a relevar” “Ver los problemas y oportunidades en acción”
  17. 17. Mapa de empatía
  18. 18. [ SINTETIZAR ]  El objetivo primordial de la etapa es lograr un entendimiento, obtener insight y definir claramente el problema.
  19. 19. [ SINTETIZAR: Story telling ] Detrás de cada necesidad hay una historia… …entender la historia nos ayuda a entender la necesidad
  20. 20. Interesado Describir la persona. Usar adjetivos (5). Agregar suficiente información como para asegurar que queda bien definido Problema / necesidad Usar verbos antes que sustantivos. Los sustantivos suelen apuntar directamente a una solución. Justificación La justificación suele provenir de la conexión de los diferentes elementos en el mapa de empatía ______ necesita un modo de ____________ porque _______ interesado problema / necesidad justificación POV – Punto de vista [ SINTETIZAR – POV ]
  21. 21. Interesado Describir la persona. Usar adjetivos (5). Agregar suficiente información como para asegurar que queda bien definido Problema / necesidad Usar verbos antes que sustantivos. Los sustantivos suelen apuntar directamente a una solución. Justificación La justificación suele provenir de la conexión de los diferentes elementos en el mapa de empatía Un jardinero profesional alérgico a los repelentes necesita protegerse de las picaduras para desarrollar sus actividaes laborales correctamente Profesional independiente necesita soluciones de movilidad para llegar a más clientes [ SINTETIZAR – POV ]
  22. 22.  Carácter ficcional que representa un usuario típico  Permite entender la motivación, objetivos y deseos de los usuarios para poder tomar decisiones de diseño [ SINTETIZAR: Personas ]  Es una forma de poner una “cara humana” a la abstracción típica de la información relevada.
  23. 23. [ SINTETIZAR: Personas - Ejemplo]  . Gustavo tiene 38 años Trabaja como jardinero hace 15 años Es fanático del fútbol Tiene 2 hijos, una nena y un varón Cuando sale toda la familia, les gusta ir al parque.
  24. 24. [ IDEAR ] Brainstorming Aplicar restricciones Exagerar las ideas Partir de algo existente
  25. 25. [ IDEAR ] Brainstorming  Reglas  Una conversación por vez  Cantidad  Títulos  Construir sobre las ideas de otros  Estimular las ideas locas  Ser visual  Mantenerse centrado en el tema  Diferir el juicio  No bloquear
  26. 26. [ PROTOTIPAR ] Se pueden construir prototipos por diferentes razones:  Explorar alternativas  Testear ideas  Generar empatía  Comunicar la visión
  27. 27. [ PROTOTIPAR ]  Lo más rápido posible … para poner a prueba las hipótesis.  Lo más económico posible … para no tener mayor costo en desechar.  El mínimo esfuerzo posible … Al estar inacabado, el creador tiene más apertura al feedback
  28. 28. [ PROTOTIPAR ] En software En productos El prototipo no tiene porque ser físico, pero sí tangible Tim Brown, Design Thinking
  29. 29. [ TESTEAR ] PASOS 1. Probar en el mundo real los prototipos 2. Obtener Feedback 3. Procesar la información obtenida 4. Iterar
  30. 30. [ TESTEAR ]  Desarrollar una cultura de crítica positiva  Estar presente durante las pruebas para ver las decisiones espontáneas que toman los usuarios al interactuar
  31. 31. [ ITERAR ]  Una vez testeado el prototipo puede ser necesario:  Re-empatizar  Re-definir  Re-idear  Re-prototipar  Re-testear … y repetir hasta solucionar el problema planteado
  32. 32. DESIGN THINKING EN DESARROLLO DE SOFTWARE http://www.flickr.com/photos/misterbenben/4277993087/
  33. 33. [ Ingeniería del Software ] Ingeniería del Software Ingeniería del requerimiento Ingeniría del Software “Acercamiento sistémico al desarrollo, operación, mantenimiento y retiro de Software” Glosario de la IEEE Ingeniería del requerimiento “El proceso sistémico de desarrollar un requerimiento a través de un proceso cooperativo e iterativo de analisis del problema, documentación de las observaciones, y control del entendimiento logrado”
  34. 34. [ D.T. y el desarrollo de Software ] (Ingeniería del requerimiento)
  35. 35. [ D.T. y el desarrollo de Software ] Los requerimientos son difíciles de relevar, interpretar y entender. Algunas de las razones:  Sólo podemos interpretar lo que observamos  Esas observaciones están sesgadas por nuestra propia realidad  Debemos obtener información de un dominio que nos es desconocido  Muchos POV, muchos sistemas, entorno dinámico, de alta complejidad Design Thinking como proceso puede ayudar (Ingeniería del requerimiento)
  36. 36. [ D.T. y el desarrollo de Software ] Ingeniería del requerimiento • Elicitar • Documentos • Estándares • Procedimientos • Contexto organizacional • Cultura • Modelos mentales • Prototipos • Especificar • Documentos • Prototipos • Validar • Experimentar • Testear (Ingeniería del requerimiento)
  37. 37. [ D.T. y el desarrollo de Software ] Ingeniería del requerimiento • Elicitar • Documentos • Estándares • Procedimientos • Contexto organizacional • Cultura • Modelos mentales • Prototipos • Especificar • Documentos • Prototipos • Validar • Experimentar • Testear Design Thinking • Empatizar • Definir • Idear • Prototipar • Testear (Ingeniería del requerimiento)
  38. 38. [ Ejemplo proceso RUP ] http://en.wikipedia.org/wiki/File:Development-iterative.gif Design Thinking
  39. 39. [¿Qué sucede con los enfoques tradicionales]  Muy efectivo como Mindset  Muy efectivo para entender requerimiento de negocio  Muy efectivo para análisis y diseño  Muy efectivo para generar y transmitir ideas  Efectivo para testear (algunas etapas)  Poco efectivo como herramienta de seguimiento  Poco efectivo como metodología de desarrollo
  40. 40. [ Desarrollo de Software ágil ] PA Agile Lean SCRUM LEAN “Hacer el flujo de valor más eficiente eliminando el desperdicio” AGILE “Ser más responsivo en ambientes de cambio constante”
  41. 41. [ D.T. + Desarrollo de Software ágil ] Desarrollo productoEntendimiento requisito, generación ideas SCRUM +
  42. 42. [ D.T. y el desarrollo de Software ] • Centrado en usuario • Visualización • Sintesis • Centrado en cliente • Back-log escrito • Eliminar desperdicio -> • Entregar más valor cada vez Colaborativo Basado en acciones (práctico) Design Thinking Lean Software Developement
  43. 43. [ D.T. + Desarrollo de Software ágil ] SCRUM +ISA Scrum Lean
  44. 44.  Empatía  Trabajo en equipo  Inmersión [ D.T. y el desarrollo de Software ] (Elementos del Design Thinking que suman al desarrollo) Definición más clara del problema a resolver Generación colaborativa de arquitectura / solución técnica Más entrega de valor en cada iteración
  45. 45. [ D.T. y el desarrollo de Software ] (Puntos a tener en cuenta y resolver)  Integrar al usuario final en todo el ciclo.  Permitir una definición conjunta del problema: PO, SM, EQUIPO.  Extender el valor incremental  Extender la visión empírica a todo el ciclo de desarrollo y construcción del producto.
  46. 46. [ Concluciones]  D.T. ofrece una forma diferente de mirar al mundo y sus interacciones -> Orientación al usuario final (human- centered) -> Resolución de problemas  D.T. no nace para Software … pero es adaptable a buena parte del ciclo  D.T. no es prescriptivo -> Incrementa el valor de otros estándares y Frameworks
  47. 47. ¿Preguntas? ¡Gracias!

×