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

AGSI 26 de octubre 2006

Manejo de Factores Humanos en la Incorporación de la Tecnología

en Forma Exitosa

Silvio [email protected]


Agenda

1. Proyectos. Algunos datos interesantes2. La toma de requerimientos3. Metodologías y herramientas4. Modelos Mentales. 5. Las percepciones. Es real la realidad?6. Los conflictos7. Las expectativas8. Groupthink9. Modalidades y patrones de comunicación10.El usuario. Empatía11.Reflexiones finales


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

Successful16%

Challenged53%

Cancelled31%


Proyectos de softwareSobrecostos

• El costo promedio por proyecto “con problemas” fue del 189% sobre el estimado originalmente

< 20% 15.5%

21 - 50% 31.5%

51 - 100% 29.6%

101 - 200% 10.2%

201 - 400% 8.8%

> 400% 4.4%

Fuente: The Standish Group


Proyectos de softwareDesvíos de tiempo

• El tiempo promedio en los proyectos “con problemas” fue del 222% sobre el estimado originalmente.


< 20% 13.9%

21 - 50% 18.3%

51 - 100% 20.0%

101 - 200% 35.5%

201 - 400% 11.2%

> 400% 1.1%


Proyectos de softwareFuncionalidad Deficiente

• Los proyectos “con problemas” han entregado, en promedio, sólo el 61% de la funcionalidad comprometida


< 25% 4.6%

25 – 49% 27.2%

50 – 74% 21.8%

75 – 99% 39.1%

100% 7.3%

726 de octubre 2006

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

0

20

40

60

80

100

Less than$750K

$750K to$1.5M

$1.5M to $3M $3M to $6M $6M to $10M Over $10M

Project Size (in dollars)

Pro

ject

Su

cces

s R

ate

(%)

)

0

20

40

60

80

100

Less than$750K

$750K to$1.5M

$1.5M to $3M $3M to $6M $6M to $10M Over $10M

Project Size (in dollars)

Pro

ject

Su

cces

s R

ate

(%)

)


Evolución de los proyectos

Standish Group Research

16% 53% 31%

27% 33% 40%

26% 46% 28%

28% 49% 23%

29% 53% 18%

0% 50% 100%

1994

1996

1998

2000

2004

Exitoso

Desvíos

Fracaso


Sobrecostos promedio: Sobrecostos promedio: 45%45%Promedio de desvío en tiempo: Promedio de desvío en tiempo: 63%63%Promedio de funcionalidad entregada: Promedio de funcionalidad entregada: 67%67%Standish GroupStandish Group

Qué hay de nuevo viejo?

20002000 28%28%23%23% 49%49%

ExitososExitososCon Con desvios de $ y desvios de $ y tiempotiempo

FracasosFracasos

Fuente: The Standish Group International, Fuente: The Standish Group International, Extreme Chaos, The Standish Group Extreme Chaos, The Standish Group International, Inc., 2000 y 2004International, Inc., 2000 y 2004

20042004 29%29%18%18% 53%53%


Porque fracasan los proyectos de sistemas?

1. Poca participación y compromiso de usuarios2. Requerimientos incompletos3. Cambio de requerimientos4. Falta de soporte de la dirección5. Incompetencia tecnológica6. Falta de recursos7. Expectativas ilusorias8. Objetivos poco claros9. Cronogramas irreales10.Nuevas tecnologías11.Otros



Costo de solución de Problemas

110 15-40

30-70

40-1000

0

100

200

300

400

500

600

700

800

900

1000

Requerimientos Diseño Desarrollo Test en desarrollo Test de Acepración Operación

Uni

dad

de

Cos

to

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”


• 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


La Toma de Requerimientos: Ciencia? La Toma de Requerimientos: Ciencia? Arte?Arte?

Comunicación Lenquaje NegociaciónComunicación Lenquaje NegociaciónResol. Problemas Conflictos ExpectativasResol. Problemas Conflictos ExpectativasInterpretaciones Juicios PercepcionesInterpretaciones Juicios PercepcionesCap. Escucha Cultura EducaciónCap. Escucha Cultura Educación

Métricas Métodos Métricas Métodos Standards Técnicas Standards Técnicas TrainingTraining Templates Templates

Ciencia

ArteArte


• 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


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”


El objetivo equivocadoSuponga que es un general que tiene que dirigir un bombardeo utilizando cámaras de video que le muestran el área objetivo. Suponga también queesas 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 alcancey los requerimientos


El objetivo equivocadoHacer 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”


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


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


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)


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.


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


A no olvidar: • Las personas son diferentes y por lo tanto, también lo son sus representaciones de la realidad

“Buenísimo.Empecemos ya.Estoy apuradaPor tenerla.”

“2 años enterosPara construirUna casa aquí?

NingúnProblema.”


Compro la cena para esta noche

DIFERENCIAS ENTRE ELMENSAJE Y LO PERCIBIDO


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


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


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.


La naturaleza del conflictoThe 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


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


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 Mientras perseguimos lo inalcanzable

hacemos imposible lo realizablehacemos imposible lo realizable – R. Ardrey


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”


Groupthink. Irving JanisUn modo de pensar en el que los participantes se Un modo de pensar en el que los participantes se ven atrapados en un grupo que lucha por imponer la ven atrapados en un grupo que lucha por imponer la unanimidad, anulando la evaluación de alternativasunanimidad, 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.


Groupthink: Ilusión de unanimidad

• Consenso asumido• Silencio =

consentimiento• Presiones para

uniformar• Mentalidad Cerrada• Racionalizaciones

colectivas• Nadie dice lo que

piensa


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


El caso del Challenger

Los frutos del GroupThink

No existe ningún conocimiento No existe ningún conocimiento absoluto, y quienes alegan tenerlo, absoluto, y quienes alegan tenerlo, sean científicos, técnicos o sean científicos, técnicos o dogmáticos, abren la puerta a la dogmáticos, abren la puerta a la tragediatragedia


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


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


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.


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)


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


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


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”


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


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.


MIT: Improving Business Value from ITNov 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. – The human dimension, change in individuals’

behavior and for large-scale change the entire culture for an organization, is the critical path to is the critical path to exploiting new IT capabilityexploiting new IT capability


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


MUCHAS GRACIAS!!!

PREGUNTAS?

Documents

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