Este documento presenta a Ezequiel Kahan, director y fundador de Knowment, una empresa de consultoría especializada en gestión de proyectos y conocimiento. Kahan tiene más de 15 años de experiencia en tecnología de la información y más de 10 años de experiencia dirigiendo proyectos para empresas nacionales e internacionales. El documento resume sus credenciales y experiencia relevante para el desarrollo de software.

1. en Desarrollo de Software
Ezequiel Kahan – CSM, PMP

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. [ ¿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. [ ¿Que es el diseño? ]

5. [ ¿Que es el diseño? ]
Diseño no sólo implica decisiones estéticas… también hay cálculo, ingeniería

6. El comienzo…
http://www.flickr.com/photos/30247062@N03/8154631487/

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. Personas
Espacio
Proceso
[ Design Thinking ]
Innovación

9. Fuente: http://www.ideo.com/about/
[ Design Thinking ]

10. [ Design Thinking ]
• Prácticas
• Acercamiento Cognitivo
• Mindset
Hassi & Laasko (2011)

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. [ Proceso de Design Thinking ]
Definir
alcance
Investigar Sintetizar Idear Prototipar Testear
Empatizar

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. [ 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. [ 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. “salir al mundo a relevar”
“Ver los problemas y
oportunidades en acción”

17. Mapa de empatía

18. [ SINTETIZAR ]
 El objetivo primordial de la
etapa es lograr un
entendimiento, obtener insight
y definir claramente el
problema.

19. [ SINTETIZAR: Story telling ]
Detrás de cada
necesidad hay
una historia…
…entender la
historia nos
ayuda a entender
la necesidad

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. 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.  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. [ 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. [ IDEAR ]
Brainstorming
Aplicar
restricciones
Exagerar
las ideas
Partir de algo
existente

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. [ PROTOTIPAR ]
Se pueden construir prototipos por
diferentes razones:
 Explorar alternativas
 Testear ideas
 Generar empatía
 Comunicar la visión

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. [ PROTOTIPAR ]
En software En productos
El prototipo no tiene porque
ser físico, pero sí tangible
Tim Brown, Design Thinking

29. [ TESTEAR ]
PASOS
1. Probar en el mundo real los
prototipos
2. Obtener Feedback
3. Procesar la información obtenida
4. Iterar

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. [ 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. DESIGN THINKING
EN DESARROLLO DE SOFTWARE
http://www.flickr.com/photos/misterbenben/4277993087/

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. [ D.T. y el desarrollo de Software ]
(Ingeniería del requerimiento)

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. [ 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. [ 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. [ Ejemplo proceso RUP ]
http://en.wikipedia.org/wiki/File:Development-iterative.gif
Design Thinking

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. [ 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. [ D.T. + Desarrollo de Software ágil ]
Desarrollo productoEntendimiento requisito, generación ideas
SCRUM
+

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. [ D.T. + Desarrollo de Software ágil ]
SCRUM
+ISA
Scrum
Lean

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. [ 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. [ 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. ¿Preguntas?
¡Gracias!