26 de octubre 2006 AGSI Manejo de Factores Humanos en la Incorporación de la Tecnología en Forma...
-
Upload
lucas-rojo-salas -
Category
Documents
-
view
213 -
download
0
Transcript of 26 de octubre 2006 AGSI Manejo de Factores Humanos en la Incorporación de la Tecnología en Forma...
AGSI 26 de octubre 2006
Manejo de Factores Humanos en la Incorporación de la Tecnología
en Forma Exitosa
Silvio [email protected]
AGSI 26 de octubre 2006
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
AGSI 26 de octubre 2006
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%
AGSI 26 de octubre 2006
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
AGSI 26 de octubre 2006
Proyectos de softwareDesvíos de tiempo
• El tiempo promedio en los proyectos “con problemas” fue del 222% sobre el estimado originalmente.
Fuente: The Standish Group
< 20% 13.9%
21 - 50% 18.3%
51 - 100% 20.0%
101 - 200% 35.5%
201 - 400% 11.2%
> 400% 1.1%
AGSI 26 de octubre 2006
Proyectos de softwareFuncionalidad Deficiente
• Los proyectos “con problemas” han entregado, en promedio, sólo el 61% de la funcionalidad comprometida
Fuente: The Standish Group
< 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
(%)
)
AGSI 26 de octubre 2006
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
AGSI 26 de octubre 2006
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%
AGSI 26 de octubre 2006
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
Fuente: The Standish Group
AGSI 26 de octubre 2006
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”
AGSI 26 de octubre 2006
• 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
AGSI 26 de octubre 2006
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
AGSI 26 de octubre 2006
• 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
AGSI 26 de octubre 2006
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”
AGSI 26 de octubre 2006
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
AGSI 26 de octubre 2006
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”
AGSI 26 de octubre 2006
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
AGSI 26 de octubre 2006
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
AGSI 26 de octubre 2006
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)
AGSI 26 de octubre 2006
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.
AGSI 26 de octubre 2006
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
AGSI 26 de octubre 2006
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.”
AGSI 26 de octubre 2006
Compro la cena para esta noche
DIFERENCIAS ENTRE ELMENSAJE Y LO PERCIBIDO
AGSI 26 de octubre 2006
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
AGSI 26 de octubre 2006
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
AGSI 26 de octubre 2006
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.
AGSI 26 de octubre 2006
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
AGSI 26 de octubre 2006
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
AGSI 26 de octubre 2006
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
AGSI 26 de octubre 2006
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”
AGSI 26 de octubre 2006
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.
AGSI 26 de octubre 2006
Groupthink: Ilusión de unanimidad
• Consenso asumido• Silencio =
consentimiento• Presiones para
uniformar• Mentalidad Cerrada• Racionalizaciones
colectivas• Nadie dice lo que
piensa
AGSI 26 de octubre 2006
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
AGSI 26 de octubre 2006
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
AGSI 26 de octubre 2006
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
AGSI 26 de octubre 2006
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
AGSI 26 de octubre 2006
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.
AGSI 26 de octubre 2006
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)
AGSI 26 de octubre 2006
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
AGSI 26 de octubre 2006
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
AGSI 26 de octubre 2006
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”
AGSI 26 de octubre 2006
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
AGSI 26 de octubre 2006
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.
AGSI 26 de octubre 2006
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
AGSI 26 de octubre 2006
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
AGSI 26 de octubre 2006
MUCHAS GRACIAS!!!
PREGUNTAS?