26 de octubre 2006 AGSI Manejo de Factores Humanos en la Incorporación de la Tecnología en Forma Exitosa Silvio Szostak

Presentación del tema: "26 de octubre 2006 AGSI Manejo de Factores Humanos en la Incorporación de la Tecnología en Forma Exitosa Silvio Szostak"— Transcripción de la presentación:

1 26 de octubre 2006 AGSI Manejo de Factores Humanos en la Incorporación de la Tecnología en Forma Exitosa Silvio Szostak sbszosta@quilmes.com.ar

2 26 de octubre 2006 AGSI Agenda 1.Proyectos. Algunos datos interesantes 2.La toma de requerimientos 3.Metodologías y herramientas 4.Modelos Mentales. 5.Las percepciones. Es real la realidad? 6.Los conflictos 7.Las expectativas 8.Groupthink 9.Modalidades y patrones de comunicación 10.El usuario. Empatía 11.Reflexiones finales

3 26 de octubre 2006 AGSI Standish Group. Encuesta sobre proyectos de software (1994) 31% se cancelaron 53% tuvieron desvíos significativos de costos y tiempos 16% cumplieron en tiempo y dentro del presupuesto (para el caso de grandes empresas el resultado fue del 9.2%) $145 mil millones de dólares fue la suma invertida en proyectos fallidos

4 26 de octubre 2006 AGSI Proyectos de software Sobrecostos El costo promedio por proyecto “con problemas” fue del 189% sobre el estimado originalmente Fuente: The Standish Group

5 26 de octubre 2006 AGSI Proyectos de software Desvíos de tiempo El tiempo promedio en los proyectos “con problemas” fue del 222% sobre el estimado originalmente. Fuente: The Standish Group

6 26 de octubre 2006 AGSI Proyectos de software Funcionalidad Deficiente Los proyectos “con problemas” han entregado, en promedio, sólo el 61% de la funcionalidad comprometida Fuente: The Standish Group

7 26 de octubre 2006 7 Standish Group: Proyectos exitosos por tamaño (en u$s) La probabilidad de éxito de un proyecto disminuye a medida que el tamaño del proyecto aumenta

8 26 de octubre 2006 AGSI Evolución de los proyectos Standish Group Research

9 26 de octubre 2006 AGSI Sobrecostos promedio: 45% Promedio de desvío en tiempo: 63% Promedio de funcionalidad entregada: 67% Standish Group Qué hay de nuevo viejo?2000 28%23%49% Exitosos Con desvios de $ y tiempo Fracasos Fuente: The Standish Group International, Extreme Chaos, The Standish Group International, Inc., 2000 y 2004 2004 29%18%53%

10 26 de octubre 2006 AGSI Porque fracasan los proyectos de sistemas? 1.Poca participación y compromiso de usuarios 2.Requerimientos incompletos 3.Cambio de requerimientos 4.Falta de soporte de la dirección 5.Incompetencia tecnológica 6.Falta de recursos 7.Expectativas ilusorias 8.Objetivos poco claros 9.Cronogramas irreales 10.Nuevas tecnologías 11.Otros Fuente: The Standish Group

11 26 de octubre 2006 AGSI Costo de solución de Problemas 1 10 15-40 30-70 40-1000 0 100 200 300 400 500 600 700 800 900 1000 RequerimientosDiseñoDesarrolloTest en desarrolloTest de AcepraciónOperación Unidad de Costo 3-6 Costo de un error por fase Barry Bohem determinó el rango de costo por error generado por falsos supuestos en la fase de requerimientos y no detectados hasta fases posteriores (“Software Engineering Economics”) “Poor management can increase software cost more rapidly than any other factor”

12 26 de octubre 2006 AGSI La Ambigüedad ayuda a generar falsas expectativas Provoca enormes pérdidas de tiempo cuando lo que se implementa es la solución equivocada. Debemos minimizar el nivel de ambigüedad. Cuanto más temprano lo hagamos, mejor De acuerdo a la encuesta realizada por la Software Engineers Association surge que los requerimientos ambiguos son uno de los factores de stress más significativos Su resultado inevitable es el re-trabajo. “El re-trabajo de requerimientos defectuosos consume entre el 40% y el 50% del costo total de un proyecto”. Capers Jones Requerimientos Ambiguos

13 26 de octubre 2006 AGSI La Toma de Requerimientos: Ciencia? Arte? Comunicación Lenquaje Negociación Resol. Problemas Conflictos Expectativas Interpretaciones Juicios Percepciones Cap. Escucha Cultura Educación Métricas Métodos Standards Técnicas Training Templates Ciencia Arte

14 26 de octubre 2006 AGSI La toma de requerimientos es más un arte que una ciencia 90% de la resolución de un problema tiene que ver con la percepción del problema La implantación de software será exitosa si los requerimientos fuesen bien conocidos y estáticos. Ninguna de las 2 condiciones se da en la realidad La capacidad de escucha activa es clave El desarrollo de los sistemas está basado en conocimiento incompleto. Los requerimientos de los usuarios tienen muchas ambigüedades, malos entendidos, inconsistencias y omisiones Toma de Requerimientos

15 26 de octubre 2006 AGSI Excusas para no tomar requerimientos “Sabemos lo que se necesita, especificarlo es una pérdida de tiempo” “Es muy difícil reunir a los usuarios. Además es un factor de conflicto” “No debemos molestar a los usuarios” “Toma mucho tiempo. Tenemos que empezar a codificar (parametrizar) para cumplir con el cronograma” Aceptando estos argumentos el gerente autodestruye su capacidad de comunicación y control. Por lo tanto se perderá una enorme cantidad de tiempo, los conflictos se generalizarán y difundirán, los usuarios serán molestados con frecuencia y el proyecto no cumplirá con los plazos. “Debemos apurarnos a codificar así nos sobra tiempo para corregir los errores que hemos cometido por apurarnos a codificar”

16 26 de octubre 2006 AGSI El objetivo equivocado Suponga que es un general que tiene que dirigir un bombardeo utilizando cámaras de video que le muestran el área objetivo. Suponga también que esas cámaras no le están mostrando ese área sino escenas pregrabadas de otras áreas. ¿Usted decidiría bombardear? Si la respuesta es SI estaría actuando como un Gerente de Sistemas que decide implementar una aplicación sin tener definido claramente el alcance y los requerimientos

17 26 de octubre 2006 AGSI El objetivo equivocado Hacer caer bombas sin un mapa de los blancos sólo nos permite afirmar cuantas bombas hemos tirado. No podremos decir nada sobre el efecto producido al enemigo Sin requerimientos definidos los llamados “informes de avance” son solo “informes de esfuerzos (dedicación)” que no nos indican nada sobre los progresos ni sobre los resultados logrados Esto tiene una gran ventaja: si un error sucede cuando se ejecuta el software podemos decir “NO ES UN BUG, ES UN FEATURE” Lo que suena muy parecido a: “LA GUARDERIA INFANTIL DESTRUIDA ERA UNA BASE ENEMIGA SECRETA”

18 26 de octubre 2006 AGSI Las herramientas no son suficientes NO son el Proyecto NO garantizan el éxito La mayoría de las veces se usan mal La mayoría tienen importantes limitaciones 70% de las herramientas compradas NUNCA se usan Y el 90% de las herramientas en uso son empleadas por una persona o un pequeño grupo. El ejemplo del exterminador de cucarachas Gerald Weinberg

19 26 de octubre 2006 AGSI Y las metodologías tampoco La calidad más importante de un modelo es que cada involucrado lo entienda Los modelos representan a los requerimientos. NO son requerimientos (El mapa no es el territorio) Los modelos son medios para ayudar a la comunicación Distinguir la Realidad fáctica de la Realidad interpretada Retomar y revisar los modelos/mapas Redundancia y refinamiento sucesivo

20 26 de octubre 2006 AGSI Modelos Mentales El lenguaje como herramienta de modelado Nuestra percepción del mundo está condicionada por nuestros “filtros ” “Nuestras teorías determinan lo que medimos” A. Einstein Nuestro modelo/mapa nunca tendrá un match perfecto con el del usuario Utilizar el modelo de precisión (PNL) Exploremos las diferencias sin perder el sentido del humor (estamos confrontando mapas)

21 26 de octubre 2006 AGSI Modelos Mentales Están conformados en gran parte por prejuicios que restringen el pensamiento creativo. Son los responsables principales de las profecías autocumplidas. Son tan poderosos que afectan lo que estamos viendo. Son determinantes en la manera en que realizamos nuestras acciones Fuerte contradicción entre nuestras imágenes internas y la forma en que el mundo real trabaja Son incompletos y evolucionan constantemente. Son representaciones imprecisas de un fenómeno. Contienen errores y contradicciones Son restringidos y proveen explicaciones simplificadas de fenómenos complejos.

22 26 de octubre 2006 AGSI El mapa no es el territorio Cada modelo (mapa) enfatiza ciertos aspectos y disminuye el énfasis sobre otros Ese es el motivo por el que los usamos Si el mapa no concuerda con el territorio, créale al territorio En el caso de los procesos, el “territorio” es lo que la gente realmente hace, no lo que los gerentes creen o piensan que debieran estar haciendo

23 26 de octubre 2006 AGSI A no olvidar: Las personas son diferentes y por lo tanto, también lo son sus representaciones de la realidad

24 26 de octubre 2006 AGSI Compro la cena para esta noche DIFERENCIAS ENTRE EL MENSAJE Y LO PERCIBIDO

25 26 de octubre 2006 AGSI Algunas reflexiones “El hombre nunca puede percibir ni comprender nada completamente. Puede ver, escuchar, tocar, saborear, pero cuan lejos puede ver, lo bien que pueda escuchar, lo que le indique lo que el esté tocando y lo que saboree depende de la cantidad y calidad de sus sentidos”. “No interesa que instrumentos use, en un determinado punto encuentra el límite en donde su conocimiento consciente no puede seguir avanzando”. Carl Jung “Los brujos dicen que estamos dentro de una burbuja. Es el lugar en donde somos puestos al momento de nacer. Al principio la burbuja está abierta, pero luego empieza a cerrarse hasta que quedamos definitivamente encerrados”. “Esta burbuja es nuestra percepción. Y vivimos dentro de ella toda nuestra vida”. Carlos Castaneda

26 26 de octubre 2006 AGSI Es real la realidad? El ser humano no sufre por lo que pasa sino por lo que cree que pasa El esfuerzo se mueve hacia lo que se está midiendo Nunca se recibe el mensaje que se ha enviado. Se dejan de lado algunas partes y se le agregan otras El observador siempre elige que observar y que ignorar. Interpretar no es observar El verdadero viaje de descubrimiento no consiste en buscar nuevos paisajes sino en tener una mirada distinta La vida no es lo que suponemos que debe ser. Es lo que es. La manera en que la encaramos es lo que hace la diferencia. Virginia Satir

27 26 de octubre 2006 AGSI Administrando Conflictos. Quality Software Management. Gerald Weinberg Más del 25% de mi tiempo lo uso en el manejo de conflictos La corrección de errores requiere de habilidades interpersonales porque los sistemas son productos sociales y estas habilidades son cada vez más y más necesarias Enseñar habilidades sociales es una inversión no sólo para la resolución de conflictos sino también para su prevención Los gerentes se tientan frecuentemente en sacrificar la interacción humana pagando un alto precio tanto en la calidad como en el cumplimiento de sus compromisos.

28 26 de octubre 2006 AGSI La naturaleza del conflicto The magic of conflict. Thomas Crum El conflicto es natural. Ni positivo ni negativo Lo que importa no es el conflicto sino que es lo que hacemos con el Ganar o perder son objetivos de los juegos. No de los conflictos Resolver un conflicto no tiene que ver con quién tiene razón sino con el entendimiento y la apreciación de las diferencias Para cambiar nuestra perspectiva en un conflicto debemos movernos desde nuestro punto de vista a un punto de observación

29 26 de octubre 2006 AGSI Manejo de expectativas. Desafiando nuestros supuestos No asuma nada de “primera” (o “de una”) Formule preguntas: –aún cuando conozca la respuesta –para clarificar los requerimientos –que focalicen en el proceso Pregunte “¿Porqué?” con cuidado Obtenga información de múltiples fuentes (y analice la fuente) Soporte la imprecisión

30 26 de octubre 2006 AGSI Naomi Karten: Managing expectations Comparta toda la información posible con sus clientes. Evite el uso de la jerga técnica Ayude a los clientes en la descripción de sus necesidades Si los requerimientos exceden los recursos ofrezca soluciones alternativas realistas. Sea proactivo con las “malas noticias” Responda rápidamente a las solicitudes y especialmente cuando hay que decir NO Mientras perseguimos lo inalcanzable hacemos imposible lo realizableMientras perseguimos lo inalcanzable hacemos imposible lo realizable – R. Ardrey

31 26 de octubre 2006 AGSI Naomi Karten: Managing Expectations Emplee una cuota de escepticismo Aclare las percepciones de sus clientes Dedique tiempo a entender a sus clientes (sus presiones, deadlines, necesidades) Construya sus relaciones. Negocie honestamente Explicite las limitaciones en forma honesta y de frente Ideas suicidas: –“Si el cliente se entera de esto, cancelará el proyecto. Pero una vez implementado le va a gustar tanto que quizás ni se de cuenta de esta falta” R. Tagore: “Si cierras la puerta a todos los errores, dejarás afuera a la verdad”

32 26 de octubre 2006 AGSI Groupthink. Irving Janis Un modo de pensar en el que los participantes se ven atrapados en un grupo que lucha por imponer la unanimidad, anulando la evaluación de alternativas Limitan el análisis a pocos cursos de acción No consultan a nadie que pueda poner en duda el curso de acción deseado Filtran nuevas informaciones No desarrollan planes de contingencia.

33 26 de octubre 2006 AGSI Groupthink: Ilusión de unanimidad Consenso asumido Silencio = consentimiento Presiones para uniformar Mentalidad Cerrada Racionalizaciones colectivas Nadie dice lo que piensa

34 26 de octubre 2006 AGSI Guardianes Mentales Asegurar que no surja algún argumento en contra Presiones sociales en contra de quienes tienen puntos de vista distintos Mantener a los “desviados” controlados, quietos o afuera. Eliminación de las dudas personales

35 26 de octubre 2006 AGSI El caso del Challenger Los frutos del GroupThink No existe ningún conocimiento absoluto, y quienes alegan tenerlo, sean científicos, técnicos o dogmáticos, abren la puerta a la tragedia

36 26 de octubre 2006 AGSI Previniendo el Groupthink Crear un clima abierto No aislar al líder. El líder no debe fijar muchas directivas (faltar a algunas reuniones, no sentarse en lugares destacados) Identificar y tomar con seriedad todas las señales de alerta Alentar las malas noticias Tomar en cuenta aquellas cosas que desmienten nuestras hipótesis favoritas Poner en duda lo que todo el mundo toma como hecho. Apreciar las diferencias. Poner cuidado en las interpretaciones de la realidad. Contar por lo menos con 3 hipótesis o supuestos. Tolerancia al error. Comunicaciones abiertas

37 26 de octubre 2006 AGSI Modalidades de Comunicación Los modalidades (canales) son 3 –Visual –Auditivo –Kinestésico En nuestra vida diaria utilizamos los 3, uno es el predominante Si el mensaje por un canal no llega, utilicemos otro No podemos ver, escuchar, sentir ni oler al software, pero si podemos captar su efecto en la gente Contraviniendo la teoría de la comunicación. Si el mensaje no se recibió o entendió: –La responsabilidad es del emisor –Volver a enviarlo hasta lograrlo. Probar con otros canales

38 26 de octubre 2006 AGSI La responsabilidad es del emisor 1.Les mandé un e-mail. Si no lo leyeron, no es mi problema 2.El síndrome “Tendrían que”: Saberlo Haberlo entendido Haber preguntado 3.Sé que me cuesta comunicarme, pero no creo que eso constituya un problema. 4.El problema está en el correo. 5.Este usuario es un plomo.

39 26 de octubre 2006 AGSI Patrones de Comunicación Hay patrones incongruentes y patrones congruentes Los incongruentes son 5: –Culpógeno (“es por culpa de ustedes”) –Culposo (“soy el culpable de todo”) –Hiper-razonable (“hemos cumplido con las normas y los estándares”) –Intrascendente (“hace calor no?”) –Amor-Odio (“a este no me lo banco”) Los patrones congruentes son los que nos llevan a balancear nuestras necesidades y expectativas con las de los otros y las de nuestro contexto –“Hay salud mental cuando mantenemos coherencia entre lo que sentimos, decimos y hacemos” (Pichon Riviere)

40 26 de octubre 2006 AGSI La entrevista con empatía Nos damos cuenta que necesitamos del otro? Usuarios y analistas son interdependientes Identifique el comportamiento (acción, proceso) que necesita entender Acérquese al entrevistado sin culpa. El objetivo es tomar información “Por favor, enséñeme cómo lo hace” Fíjese si entendió repitiendo el comportamiento ante la observación y correcciones de su usuario El analista promedio tiene las habilidades interpersonales de un boxeador

41 26 de octubre 2006 AGSI El usuario Quiere lo mejor, para ayer y al mínimo costo. Sería más fácil desarrollar nuestras ideas “creativas” en el vacío sin tener que exponerlas a la crítica o al cambio Para evitar esto comencemos por poner foco temprano y continuamente en la comunidad de usuarios, sus deseos y necesidades. Encaremos las siguientes acciones: –Decidir quienes son (los usuarios) –Conversar con ellos –Trabajar con ellos en sus oficinas –Observar cómo trabajan –Ensayar el trabajo de ellos –Involucrarlos en el diseño

42 26 de octubre 2006 AGSI Habilidades En mis 4 décadas de experiencia he aprendido que hay 3 habilidades imprescindibles para realizar un trabajo de calidad en el gerenciamiento de proyectos: 1.La habilidad de ENTENDER situaciones complejas 2.La habilidad de OBSERVAR que está pasando 3.La habilidad de ACTUAR en situaciones interpersonales dificultosas, aún estando uno confundido, enojado o temeroso a tal punto que nos gustaría huir y escondernos Gerald Weinberg “Quality Software Management”

43 26 de octubre 2006 AGSI Exito o Fracaso de los proyectos El éxito o fracaso de los proyectos depende enormemente de: –La organización del equipo –El tamaño del mismo –Cómo esta conformado –Cómo trabajan juntos para cumplir con su misión –Y del esfuerzo heroico de un equipo dedicado (más que de los métodos y herramientas) Las relaciones humanas tiene un impacto directo tanto en la productividad como en la calidad. Una vez que la buena comunicación quedó establecida dentro del team, los analistas y los usuarios pueden trabajar productivamente. Para tener éxito en la implementación de un software, se debe tomar en cuenta el objetivo, no las herramientas disponibles. Lowell Jay Arthur

44 26 de octubre 2006 AGSI Manifesto for Agile Software Development We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: –Individuals and interactions over processes and tools –Working software over comprehensive documentation –Customer collaboration over contract negotiation –Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more.

45 26 de octubre 2006 AGSI MIT: Improving Business Value from IT Nov 29-30, 2006 The Human Dimension: Implementation and Change Management –Business value form IT comes not from the technology itself but from new or improved business processes. –Successful process change demands work behavior change. is the critical path to exploiting new IT capability –The human dimension, change in individuals’ behavior and for large-scale change the entire culture for an organization, is the critical path to exploiting new IT capability

46 26 de octubre 2006 AGSI Referencias y Lecturas Recomendadas Jim Johnson (Standish Group) My Life is Failure Gerald Weinberg –Exploring Requirements. Quality before design –Quality Software Management. Volumen 2 y 3 Paul Watzlawick Es Real la Realidad? Joseph O’Connor. Introducción a la PNL Thomas Crum. The Magic of Conflict Naomi Karten. –Managing Expectations –Communications Gaps And How To Close Them Virginia Satir. The New in Peoplemaking Lowell Jay Arthur. Rapid Evolutionary Development

47 26 de octubre 2006 AGSI MUCHAS GRACIAS!!! PREGUNTAS?