Issuu on Google+

TESIS DE GRADO EN INGENIERÍA INFORMÁTICA:

MANEJO DE EXPECTATIVAS EN LOS PROYECTOS INFORMÁTICOS TESISTA: Ariel D. Schapiro (80.885) PROFESORES: Lic. Gustavo López y Lic. Ismael Jeder Septiembre de 2008


Manejo de expectativas en los proyectos informáticos Universidad de Buenos Aires - Facultad de Ingeniería

Ariel D. Schapiro Padrón 80.885

Agradecimientos A mi familia, por su apoyo inagotable y su ayuda en la revisión. A Jesica Baran, mi novia, por acompañarme siempre. Al Lic. Gustavo López, director de este trabajo, por su orientación y guía. A Southworks por la experiencia que nos hace crecer; y especialmente a Alejandro Jack, Matías Woloski, Angel López y Martín Salías por su ayuda y sus consejos. A los profesionales que se tomaron el tiempo y la dedicación de contestar la encuesta que forma parte de este trabajo de investigación. A los profesores, compañeros, colegas y amigos, por su colaboración de alguna u otra forma en este trabajo.

2


Manejo de expectativas en los proyectos informáticos Universidad de Buenos Aires - Facultad de Ingeniería

Ariel D. Schapiro Padrón 80.885

Resumen Según los datos arrojados por el Standish Group en el año 2004, el porcentaje de proyectos que resultan exitosos continúa siendo bajo (29%). A partir de esto, en el comienzo de este trabajo se plantea la hipótesis que consiste en que el rol del manejo de expectativas en el desarrollo de los proyectos informáticos, no está lo suficientemente privilegiado en el ámbito local (Argentina) y que la implementación de metodologías de desarrollo que lo incluyan como un aspecto fundamental, ayudará a disminuir la proporción de proyectos fracasados. Luego se expone el estado del arte del papel que cumple el manejo de expectativas en los proyectos informáticos, a través de aéreas de incumbencia, artefactos y prácticas concretas que lo alientan como una lista priorizada de requerimientos del producto, entrega frecuente y manejo de riesgos. Más tarde se presenta el trabajo de investigación que incluye un relevamiento realizado a través de una encuesta, que abarca una muestra de proyectos llevados a cabo por empresas del mercado informático local. Este relevamiento brinda datos prácticos acerca de puntos claves relacionados con el manejo de expectativas, como la percepción de los clientes, la medida y el seguimiento de la misma a lo largo de los proyectos, las herramientas que se usan a tal efecto, las metodologías o prácticas que se aplican y cómo éstos inciden en los supuestos que mantienen los clientes y sponsors a lo largo de los proyectos. La hipótesis planteada es más tarde verificada en base a la información obtenida en la investigación. También se realizan análisis adicionales de los resultados, donde se destaca el grado de éxito en base a la metodología de desarrollo de software seguida o la frecuencia de comunicación del avance con el cliente. A partir de la información recolectada y su análisis es que finalmente se construyen conclusiones acerca del papel del manejo de expectativas, la percepción de su importancia y el rol de ciertas metodologías y herramientas que lo alientan.

3


Manejo de expectativas en los proyectos informáticos Universidad de Buenos Aires - Facultad de Ingeniería

Ariel D. Schapiro Padrón 80.885

Abstract According to the data gathered by the Standish Group in 2004, the percentage of successful projects is still low (29%). Based on that, the hypothesis raised at the beginning of this thesis states that the role of expectation management in the development of software projects is not privileged enough in the local market (Argentina), and that the implementation of development methodologies that include expectation management as a fundamental aspect, will help on reducing the proportion of failed projects. After that, the state of the art of the role of expectation management in software projects is explained through areas, artifacts and concrete practices that encourage it, such as a list of prioritized product requirements, frequent delivery and risk management. The survey-based research that covers a sample of projects undertaken by local companies in the software market is then explained. This survey provides practical information on key points related to expectations management, such as the perception of customers, the measurement and monitoring of the expectations over the projects, the tools used for that purpose, methodologies or practices that are applied and how they affect the assumptions that customers and sponsors keep over the projects. The hypothesis is later verified based on the information obtained in the research. Further analysis of the results is also conducted, from where we can highlight the degree of success based on the software development methodology implemented or the frequency of communication with the customer regarding the project’s progress. That information and analysis leads to the final building of a set of conclusions about the role of expectation management, the perception of its importance and the role of the methodologies and tools that encourage it.

4


Manejo de expectativas en los proyectos informáticos Universidad de Buenos Aires - Facultad de Ingeniería

Ariel D. Schapiro Padrón 80.885

Contenido Agradecimientos ................................................................................................................................... 2 Resumen ............................................................................................................................................... 3 Abstract................................................................................................................................................. 4 1.

2.

Introducción.................................................................................................................................. 8 1.1.

El problema ........................................................................................................................... 8

1.2.

Preguntas Centrales ............................................................................................................ 10

1.3.

Hipótesis a comprobar........................................................................................................ 11

Estado de la cuestión: El manejo de expectativas ...................................................................... 12 2.1.

Definiciones ........................................................................................................................ 12

2.2.

El manejo de expectativas en los proyectos informáticos ................................................. 13

2.2.1.

2.3.

El manejo de expectativas escapa a la relación cliente-proveedor.................................... 22

2.4.

Manejo de expectativas como factor de continuidad ........................................................ 23

2.5.

Implementación .................................................................................................................. 25

2.5.1.

3.

Evolución de las diferencias entre las expectativas del cliente y las del proveedor ................ 17

El Manejo de Expectativas frente a los cambios de requerimientos ....................................... 25

Solución propuesta: Artefactos que ayudan en el Manejo de Expectativas .............................. 27 3.1.

Visión & Misión ................................................................................................................... 27

3.2.

Lista priorizada de requerimientos del producto (“Product Backlog”) .............................. 28

3.3.

Reuniones de planeamiento y reporte con el cliente......................................................... 30

3.3.1.

Planeamiento de la Iteración ................................................................................................... 31

3.3.2.

Sincronización diaria del equipo (planeamiento) .................................................................... 32

3.3.3.

Reporte diario del avance del equipo ...................................................................................... 33

3.3.4.

Revisión de la Iteración (reporte) ............................................................................................ 34

3.3.5.

Reuniones de retrospectiva de la iteración ............................................................................. 35

3.4.

Entrega Frecuente .............................................................................................................. 36

3.5.

Manejo de riesgos............................................................................................................... 37 5


Manejo de expectativas en los proyectos informáticos Universidad de Buenos Aires - Facultad de Ingeniería

4.

5.

Ariel D. Schapiro Padrón 80.885

Investigación ............................................................................................................................... 38 4.1.

Objetivos ............................................................................................................................. 38

4.2.

Criterios en los que se basan las preguntas de la encuesta ............................................... 39

4.3.

Encuesta aplicada ............................................................................................................... 41

4.3.1.

Metodologías de relevamiento ................................................................................................ 41

4.3.2.

Términos y Condiciones ........................................................................................................... 42

4.3.3.

Verificación de los datos .......................................................................................................... 43

4.3.4.

Preguntas Centrales ................................................................................................................. 44

4.3.5.

Muestra de empresas .............................................................................................................. 51

4.3.6.

Factores de la encuesta que se tienen en cuenta para medir el manejo de expectativas ...... 52

4.3.7.

Niveles de éxito planteados: diferencias entre el CHAOS Report y este estudio .................... 53

4.4.

Uso de la herramienta de análisis estadístico .................................................................... 55

4.5.

Planteo del Análisis de validez de la hipótesis (prueba de hipótesis) ................................ 56

4.5.1.

Análisis estadísticos que definen la validez de cada factor ..................................................... 57

4.5.2.

Diagrama de probabilidades .................................................................................................... 63

Resultados................................................................................................................................... 64 5.1.

Resultados del Análisis de validez de la hipótesis (prueba de hipótesis) ........................... 64

5.2.

Resultados desagregados por pregunta de la encuesta ..................................................... 66

5.2.1.

Contexto .................................................................................................................................. 66

5.2.2.

Detalles del proyecto ............................................................................................................... 69

5.2.3.

Relación con el Cliente ............................................................................................................. 73

5.2.4.

Resultados del Proyecto .......................................................................................................... 83

5.2.5.

Detalles de metodología .......................................................................................................... 92

5.2.6.

Opinión: metodología y factores de éxito/fracaso .................................................................. 93

5.3.

Otros estudios estadísticos y tendencias............................................................................ 98

5.3.1.

Grado de éxito en los proyectos en base al manejo de expectativas ...................................... 98

5.3.2.

Grado de éxito en los proyectos en base al plazo de entrega en meses ................................. 99

5.3.3.

Grado de éxito en los proyectos en base a la frecuencia de comunicación del avance con el

cliente

100 6


Manejo de expectativas en los proyectos informáticos Universidad de Buenos Aires - Facultad de Ingeniería

5.3.4.

Ariel D. Schapiro Padrón 80.885

Grado de éxito en los proyectos en base a la medición por parte del cliente de lo que se le

estaba entregando a lo largo del proyecto ............................................................................................. 102 5.3.5.

Manejo de expectativas en base a la metodología de desarrollo de software ..................... 103

5.3.6.

Grado de éxito en los proyectos en base a la metodología de desarrollo de software ......... 105

5.3.7.

Cumplimiento de las expectativas del cliente en base al grado de éxito del proyecto ......... 107

5.4. 6.

7.

8.

Diferencias con el Chaos Report ....................................................................................... 108

Conclusiones ............................................................................................................................. 109 6.1.

Sobre el papel del manejo de expectativas y su percepción ............................................ 109

6.2.

Sobre los artefactos que ayudan en el Manejo de Expectativas ...................................... 113

6.3.

Sobre la definición de éxito .............................................................................................. 114

Futuras líneas de investigación ................................................................................................. 115 7.1.

Prácticas implementadas a lo largo del proyecto............................................................. 115

7.2.

Información que soporte otras definiciones de éxito ...................................................... 116

Bibliografía ................................................................................................................................ 117

7


Manejo de expectativas en los proyectos informáticos Universidad de Buenos Aires - Facultad de Ingeniería

Ariel D. Schapiro Padrón 80.885

1. Introducción 1.1. El problema El desarrollo de proyectos informáticos es una disciplina joven, con menos de 50 años y como tal, está buscando distintas formas para perfeccionarse [Baskerville, 2005]. En este camino surgieron muchos marcos de trabajo, metodologías, modelos de procesos y estándares que persiguen la eficiencia en el desempeño de los proyectos. Algunos de aquellos están representados en la siguiente figura de SYSTEMATIC PROCESS IMPROVEMENT USING ISO 9001: 2000 AND CMMI de Mutafelija y Stromberg:

Figura 1: Relaciones entre los estándares más prominentes [Mutafelija, et al., 2003].

Sin embargo, estudios como el famoso CHAOS REPORT [The Standish Group, 1994] del Standish Group en el año 1994 arrojaron datos alarmantes: en EEUU solo el 16% de los proyectos era considerado un éxito. El 53% no llegaba a cumplir las metas definidas en su comienzo, a nivel de funcionalidad solicitada, estándares de calidad requeridos, presupuesto económico o fechas de entrega (proyectos desviados). Mientras que el 31% restante era cancelado antes de completarse. El reporte del año 2004 [InfoQ, 2006] informó acerca de un 29% de proyectos exitosos: éstos casi se duplicaron en 10 años, pero aún el porcentaje de proyectos desviados continúa siendo considerable:

8


Manejo de expectativas en los proyectos informáticos Universidad de Buenos Aires - Facultad de Ingeniería

Ariel D. Schapiro Padrón 80.885

Figura 2: Proyectos cancelados, desviados y exitosos según el Standish Group.

9


Manejo de expectativas en los proyectos informáticos Universidad de Buenos Aires - Facultad de Ingeniería

Ariel D. Schapiro Padrón 80.885

1.2. Preguntas Centrales En base a lo anterior, en el presente trabajo de Tesis se plantearán algunas preguntas o hilos conductores. Estas preguntas servirán de forma introductoria como una guía sobre lo que será el hilo conductor del trabajo: 

¿Es posible que el problema por el cual semejante cantidad de proyectos no resultan exitosos sea la percepción de los desvíos y no los desvíos en sí mismos?

¿De qué forma y en qué medida afecta una falta de atención al manejo de expectativas de los clientes en el fracaso de los proyectos?

¿Qué modelos o prácticas favorecen un buen manejo de expectativas de los clientes y qué inconvenientes se encuentran para implementarlos?

¿En qué medida favorecen los compromisos firmados entre las partes definidos en modelos orientados a características (“feature-based”) y en los enmarcados en plazos (“time-boxed”)?

En el presente trabajo de investigación se expondrá la teoría actual sobre estos temas para luego enriquecerla con un relevamiento similar al del “CHAOS Report” [The Standish Group, 1994], de alcance local y orientado a contestar entre otras, las preguntas ya expuestas. Este relevamiento abarcará una muestra de empresas del mercado informático local (ver Muestra de Empresas); que participarán en una encuesta que brindará datos prácticos acerca del rol e implementación del manejo de expectativas en sus proyectos. Puntos clave como la percepción de los clientes, la medida y seguimiento de la misma a lo largo de los proyectos, las herramientas que se usan a tal efecto, las metodologías o modelos que se aplican y cómo éstos inciden en los supuestos que mantienen los clientes y sponsors, a lo largo de los proyectos serán investigados partiendo de parámetros concretos y empíricos. Se obtendrán conclusiones que, complementadas por información teórica, mostrarán la incidencia del manejo de expectativas en el éxito de los proyectos, el papel que aquel ocupa en el mercado local y las prácticas y herramientas que lo promueven.

10


Manejo de expectativas en los proyectos informáticos Universidad de Buenos Aires - Facultad de Ingeniería

Ariel D. Schapiro Padrón 80.885

1.3. Hipótesis a comprobar La hipótesis a demostrar consiste en que el papel del manejo de expectativas en el desarrollo de los proyectos informáticos, no está lo suficientemente privilegiado en el ámbito local y que la implementación de metodologías de desarrollo que lo incluyan como aspecto fundamental, ayudarán a disminuir la cantidad de proyectos fracasados o desviados, aumentando por consiguiente el grado de éxito en los mismos. Por otro lado, quienes no incluyan al manejo de expectativas como aspecto fundamental, obtendrán resultados sensiblemente inferiores a quienes sí lo hagan. Con el fin de validar esta hipótesis, se planteará un análisis de validez de la hipótesis (prueba de hipótesis) a partir de parámetros fijos resultantes de las respuestas de la encuesta.

11


Manejo de expectativas en los proyectos informáticos Universidad de Buenos Aires - Facultad de Ingeniería

Ariel D. Schapiro Padrón 80.885

2. Estado de la cuestión: El manejo de expectativas “El mayor enemigo de la comunicación es la ilusión de la misma”, Pierre Martineau.

2.1. Definiciones Según Jens Egerland, [Egerland, 2003] el manejo de expectativas es el proceso de reunir, incorporar y medir las expectativas de los clientes durante la vida de un proyecto. Egerland explica que el manejo de expectativas es necesario durante las fases de construcción y entrega del producto y que las expectativas deben establecerse en el inicio del proyecto y ser parte de un acuerdo entre todas las partes intervinientes. También explica que las soluciones exitosas en el plano informático requieren una propuesta de negocio bien definida, un entendimiento de las capacidades tecnológicas y un entendimiento de las expectativas de los clientes. Egerland enmarca al manejo de expectativas como uno de los componentes del manejo de calidad (Quality Management), acompañándolo de la verificación de la calidad, manejo de procesos, métricas, mejora continua y reconocimientos y recompensas. Lo que rescatamos de esta definición como punto de partida es que el manejo de expectativas no parece estar restringido a la industria del software: esta definición se amolda generalmente a cualquier campo donde exista un proyecto con clientes definidos. Teniendo en claro la definición y habiendo especificado la pluralidad de la misma, dirijámonos al campo de los proyectos informáticos en particular, donde veremos el papel teórico y práctico del manejo de expectativas.

12


Manejo de expectativas en los proyectos informáticos Universidad de Buenos Aires - Facultad de Ingeniería

Ariel D. Schapiro Padrón 80.885

2.2. El manejo de expectativas en los proyectos informáticos Un hombre está volando en un globo de aire caliente y se da cuenta que está perdido. Decide reducir la altitud y divisa un hombre abajo. Baja el globo aún más y le grita: “Disculpe, ¿me podría decir dónde estoy?” El hombre de abajo le contesta: “Ud. está en un globo de aire caliente suspendido a unos 30 pies por encima de éste campo” A lo que el hombre en el globo le responde: “Ud. debe ser un desarrollador de software” El hombre debajo le contesta: “Lo soy, ¿cómo lo sabe Ud.?” “Bueno,” dice el hombre en el globo, “todo lo que Ud. me dijo es técnicamente correcto, pero no le es de utilidad a nadie” El hombre debajo le contesta,”Ud. debe ser un hombre de negocios o un gerente”. “Lo soy”, responde el hombre en el globo, “¿pero cómo lo sabe Ud. eso?” “Bueno,” dice el hombre, “Ud. no sabe donde se encuentra ni hacia donde se dirige, pero Ud. espera que yo lo ayude. Ud. está en la misma posición que estaba antes de conocernos pero ahora es mi culpa” [2007]

13


Manejo de expectativas en los proyectos informáticos Universidad de Buenos Aires - Facultad de Ingeniería

Ariel D. Schapiro Padrón 80.885

En las definiciones acerca del manejo de expectativas explicábamos como el manejo de expectativas aplica a cualquier campo donde exista un proyecto con clientes definidos; pero ¿qué tiene de especial el manejo de expectativas en el campo del desarrollo de proyectos informáticos? La siguiente descripción gráfica [2008] acerca del desarrollo de proyectos informáticos puede brindar de una sola mirada un principio de respuesta:

14


Manejo de expectativas en los proyectos informáticos Universidad de Buenos Aires - Facultad de Ingeniería

Ariel D. Schapiro Padrón 80.885

Figura 3: Distintas expectativas en un proyecto informático

Esta es una representación, que aunque de forma exagerada, describe las visiones que tienen los distintos actores en el desarrollo de un proyecto informático [Hord, 2005]: 

Como el cliente lo explicó: en muchos casos el cliente no tiene un entendimiento completo acerca de lo que necesita. En esos casos puede pensar que sí lo tiene pero también puede pensar acerca de funcionalidades extra que raramente llegue a usar.

Como el líder de proyecto lo entendió: la persona a cargo del proyecto lo puede entender con un detalle crítico errado. Este puede llegar a ser un detalle que lo hace inútil al producto.

Como el analista lo diseñó: el analista debe decidir como corregir el posible malentendido del líder del proyecto. Un “arreglo” común puede ser “romper” algo más para que funcione con el diseño existente.

Como el programador lo escribió: los programadores pueden no entender las funcionalidades esenciales en un proyecto. Ellos a veces implementan los requerimientos de forma muy literal.

Como el encargado del negocio lo describió: el equipo de Marketing puede transformarse en una pesadilla a los ojos de los ingenieros. Le pueden vender al cliente las funcionalidades más brillantes del proyecto, sin prestarle la merecida atención a la verdad o practicidad de la situación. 15


Manejo de expectativas en los proyectos informáticos Universidad de Buenos Aires - Facultad de Ingeniería

Ariel D. Schapiro Padrón 80.885

Cómo el proyecto fue documentado: la documentación puede ser usualmente pensada hacia el final, como si alguien más lo estuviera escribiendo a lo largo del desarrollo.

Qué se instaló: a menudo se invierten meses para que algunas funcionalidades marchen como era esperado, para luego darse cuenta que esas funcionalidades no fueron instaladas en el cliente porque A) no andaban, B) el instalador no entendía cómo funcionaban, o C) alguien temía que los arreglos no fueran buenos.

Cómo fue cobrado el cliente: el software es algo costoso.

Cómo el proyecto estaba soportado:” ¿esta funcionalidad está causando que el usuario llame a soporte? Tal vez debamos removerla” Eventualmente, se puede terminar con la funcionalidad básica del proyecto.

Lo que el cliente realmente necesitaba: todo sería mucho más simple si pudiéramos llegar a este punto. Pero difícilmente lo hacemos…

En base a ésta descripción de Hord, podemos extraer algunas características que tienen los proyectos informáticos que pueden no ser tan relevantes en proyectos de otros tipos: 

En muchos casos el cliente no tiene un entendimiento completo sobre lo que necesita.

Muchas veces el cliente no ve el producto hasta no haber terminado el proyecto.

Según Hord, aquella descripción, más allá de su exageración gráfica, no dista demasiado de la realidad sobre las percepciones que tienen los distintos participantes de un proyecto informático. Hacer que estas percepciones estén alineadas y llegar a contar con una apreciación del cliente que esté al alcance de lo que espera producir el equipo sería en este contexto el objetivo del manejo de expectativas.

16


Manejo de expectativas en los proyectos informáticos Universidad de Buenos Aires - Facultad de Ingeniería

Ariel D. Schapiro Padrón 80.885

2.2.1. Evolución de las diferencias entre las expectativas del cliente y las del proveedor En base a una adaptación de la evolución del la exposición al riesgo explicada en MANAGING ITERATIVE SOFTWARE DEVELOPMENT PROJECTS [Bittner, et al., 2007], podríamos establecer una variable δ (“delta”) que utilizaremos para simbolizar la diferencia entre las expectativas del cliente y aquellas del proveedor:

Figura 4: Áreas definidas para δ

Así como se ve en la Figura 4, podríamos establecer también distintas áreas en el estado de δ: 

Equilibrado: las diferencias entre las expectativas del cliente y las del proveedor son mínimas y/o despreciables. El cliente está al tanto regularmente sobre el avance del equipo de desarrollo y esto hace que las expectativas que se le generan en base a eso estén equilibradas. Todos los esfuerzos que realiza el equipo de desarrollo son como mínimo esperados por el cliente y no se realizan esfuerzos de más.

Manejable: hay notables diferencias entre las expectativas del cliente y el avance del proyecto. En el caso de detectarse esas diferencias pueden requerirse correcciones en los planes del equipo de desarrollo o bien en las expectativas del cliente. Aquellas correcciones pueden llegar a implicar retrocesos, es decir que el equipo realizó esfuerzos que luego no son aprovechados.

17


Manejo de expectativas en los proyectos informáticos Universidad de Buenos Aires - Facultad de Ingeniería

Ariel D. Schapiro Padrón 80.885

Riesgoso: Las diferencias entre lo que espera el cliente y el avance del equipo es importante. Al encontrarse el cliente con el cuadro de situación puede demandar explicaciones que fundamenten decisiones que impactarán en la continuidad del proyecto, como por ejemplo una cancelación.

En los casos donde no existan esfuerzos para manejar estas expectativas no podremos esperar que δ disminuya en algún lugar del ciclo de vida del proyecto. δ podría mantenerse constante por un período de tiempo y aumentaría ante cualquier desvío por parte del equipo de desarrollo de las expectativas del cliente. Si como dijimos anteriormente, no existieran esfuerzos para manejar las expectativas del cliente hasta el final del proyecto, el siguiente escenario es posible:

Figura 5: δ en un escenario donde no existen esfuerzos para manejar las expectativas

En este escenario, el avance del proyecto llega a un punto donde las expectativas del cliente distan significativamente del avance del equipo. Esto puede poner en riesgo la satisfacción del cliente junto con la continuidad del proyecto. Con el objetivo de forzar atenuaciones en δ, es posible incluir espacios en el desarrollo del ciclo de vida del software, donde el cliente se encuentre con el avance del proyecto y sus expectativas se acerquen a la realidad del mismo. Estos espacios pueden darse gracias a una mayor comunicación con el cliente que incluya reportes de avance, planes sobre los próximos pasos, demostraciones del 18


Manejo de expectativas en los proyectos informáticos Universidad de Buenos Aires - Facultad de Ingeniería

Ariel D. Schapiro Padrón 80.885

software que se está construyendo, etc. Si la metodología de desarrollo aplicable lo soporta, de estos espacios pueden surgir modificaciones en el plan corriente, que equilibran las expectativas del cliente con el estado actual del proyecto.

Figura 6: δ en un escenario donde existen esfuerzos para equilibrar las expectativas

Es importante aclarar que este manejo de expectativas no trata solamente de cumplir con las que tiene el cliente. Como dijimos anteriormente y como explica Dan Fleck en SOFTWARE LEADERSHIP [Fleck, 2007], en muchos casos, el cliente no cuenta con un entendimiento significativo sobre lo que quiere, y muchas veces menos acerca de lo que verdaderamente necesita. Si en los momentos que citamos anteriormente, donde se equilibran las expectativas del cliente, el equipo solamente se limita a obtener las opiniones del cliente para aplicarlas en el desarrollo del proyecto sin un análisis desde el punto de vista del desarrollo de software y una devolución constructiva al cliente, el proyecto puede dirigirse a una zona de δ riesgoso. Esto se debe a que factores como la expectativa del cliente en términos de fecha de finalización del proyecto tal vez no sean manejados si solamente se aplican los comentarios del cliente. En este sentido, el manejo de las expectativas en esos momentos no debería restringirse a una recolección de opiniones, sino también al análisis conjunto de las mismas y a una devolución en términos de cómo de aplicarse esas conclusiones el proyecto es afectado. Esta afectación incluirá factores a nivel de proyecto como la calidad de la entrega, los tiempos de la misma, tecnologías involucradas, presupuestos de implantación, etc. 19


Manejo de expectativas en los proyectos informáticos Universidad de Buenos Aires - Facultad de Ingeniería

Ariel D. Schapiro Padrón 80.885

Como se ve en la figura anterior, es posible que la frecuencia de dichos momentos posibilite equilibrar las expectativas luego de que δ entró en el terreno de lo manejable. Esto puede implicar cambios de rumbo en términos del avance del proyecto, replanteos en el diseño, etc. Ahora bien, ¿qué ocurre si aumentamos la frecuencia de dichos encuentros, forzando a que δ no se escape de la zona de equilibrio? La siguiente figura plantea ese escenario:

Figura 7: δ en un escenario donde los esfuerzos para equilibrar las expectativas se repiten con frecuencia

Este escenario implica lógicamente que el cliente se involucre significativamente y que haya canales de comunicación eficientes que posibiliten contar con sus comentarios en forma relativamente rápida y una devolución por parte del equipo que incluya información acerca de posibles alteraciones en factores del proyecto. Un efecto positivo que se obtiene como consecuencia de intentar minimizar δ, es que el cliente puede comenzar el proyecto pretendiendo algo como resultado y a lo largo del proyecto sus expectativas van cambiando, gracias al reporte frecuente por parte del equipo y a que en el proceso el cliente también puede ir dándose cuenta lo que verdaderamente necesita. En base a lo expuesto anteriormente, podemos llegar a la conclusión que el camino de equilibrar δ busca que el cliente reciba lo que estaba esperando; tal vez no lo que el cliente esperó desde un comienzo, pero seguramente se acerca a que reciba lo que estaba esperando en cada entrega del proyecto. 20


Manejo de expectativas en los proyectos informáticos Universidad de Buenos Aires - Facultad de Ingeniería

Ariel D. Schapiro Padrón 80.885

Es así como en un plano ideal, podríamos decir que a través de un cuidado manejo de las expectativas de los participantes de un proyecto, se podría transformar el pasado esquema a uno como el siguiente:

Figura 8: Luego de aplicar un cuidado manejo de expectativas el cliente recibe lo que estaba esperando

Donde lo que el cliente necesita está consensuado entre él y su proveedor y al tener esto en cuenta durante todo el proceso de desarrollo, se conoce perfectamente como satisfacer al cliente. Como vimos anteriormente, las expectativas de los clientes pueden cambiar a lo largo del proyecto. Como decía Dan Fleck [Fleck, 2007], en muchas oportunidades el cliente no sabe bien lo que quiere, y eso lo puede ir descubriendo, con la ayuda del equipo de desarrollo a lo largo del ciclo de vida del proyecto. Si el mecanismo de manejo de expectativas por parte del equipo soporta estos cambios como parte natural de su comportamiento, entonces podemos decir que estamos frente a un mecanismo ágil.

21


Manejo de expectativas en los proyectos informáticos Universidad de Buenos Aires - Facultad de Ingeniería

Ariel D. Schapiro Padrón 80.885

2.3. El manejo de expectativas escapa a la relación cliente-proveedor Se suele entender que las expectativas concernientes en el manejo de las mismas, se dan entre el cliente y el proveedor en un proyecto dado y se deja al margen las expectativas que se generan entre los demás involucrados en el proyecto. De la figura 3 se desprenden, no solamente diferencias entre las expectativas del cliente con las del proveedor en su conjunto (equipo de desarrollo), si no también dentro del equipo en sí. Por eso puede ser importante entender que el manejo de expectativas se da en un sentido amplio entre clientes y proveedores, no solamente entre el cliente del proyecto y el equipo de desarrollo. En base a esto tendremos múltiples relaciones, como la del analista con la del líder de proyecto, o la del líder de proyecto con los desarrolladores del equipo. Todas estas relaciones se pueden ver como clientes-proveedor y allí se debe salvaguardar el manejo de expectativas tanto como del equipo para afuera. El resultado de un estudio de Grady Booch, de IBM Rational arrojó que los desarrolladores usan en promedio el 30% de su tiempo productivo en escribir código, mientras que el resto del tiempo lo usan en comunicarse con otros miembros del equipo [The Economist, 2008]. Esto nos da indicios del papel de la comunicación dentro de un equipo y del papel de las expectativas que se presentan en esa comunicación. Aunque las relaciones tengan naturalezas distintas, es importante remarcar que muchos de los principios y herramientas que se aplican para manejar las expectativas del cliente a nivel de proyecto, se pueden atribuir también en niveles dentro del proyecto. Esto se puede tener en cuenta a la hora de implementar las prácticas explicadas en el capítulo Artefactos que ayudan en el Manejo de Expectativas: más allá que estén explicadas en un entorno de un proyecto y los beneficios que traen para con las expectativas del cliente externo, éstos artefactos recaen en el principio del manejo de expectativas y por eso son aplicables a relaciones internas al proyecto.

22


Manejo de expectativas en los proyectos informáticos Universidad de Buenos Aires - Facultad de Ingeniería

Ariel D. Schapiro Padrón 80.885

2.4. Manejo de expectativas como factor de continuidad Una vez que el manejo de expectativas haya cumplido el objetivo de obedecer a las expectativas del cliente y esto cause que el producto se entregue en tiempo y forma, podemos descubrir efectos colaterales positivos que se desprenden sin esfuerzo adicional. Tal es el caso de la confianza del cliente al haber resuelto positivamente los riesgos en un principio supuestos. Según Marco Antonio Jiménez [Jiménez, 2006], el manejo de expectativas es un “elemento adicional que cada vez toma más fuerza y que debemos observar si queremos tener éxito no sólo en el proyecto actual, sino pensando en proyectos y relaciones de negocios a largo plazo”. Esto podría deberse a que “en la actualidad las decisiones de tecnología dentro de la organización ocupan un espectro más amplio dentro del negocio y por lo tanto hay mas individuos involucrados.” [Jiménez, 2006] El hecho de que más personas intervengan en las decisiones, hace que tengamos que manejar más expectativas y esto puede resultar complejo debido a las distintas necesidades y aspiraciones que cada participante tiene con respecto a los resultados del proyecto. En el caso de la Gerencia de Proyectos, podríamos pensar en que los clientes no sólo estén conformes con que sus proyectos terminen a tiempo y en el costo convenido, sino que todas sus expectativas hayan quedado cubiertas. John Fleming y Jim Asplund, en su libro HUMAN SIGMA [Fleming, y otros, 2007], presentan los resultados de estudios que cubren el comportamiento de los clientes en general. Analizaron la satisfacción del cliente a lo largo de distintas industrias y encontraron que los clientes que se encuentran satisfechos pueden ser clasificados en dos grupos: los racionalmente satisfechos y los emocionalmente satisfechos. Fleming y Asplund reportan que los clientes racionalmente satisfechos aunque estén extremadamente satisfechos, pueden estar careciendo de un fuerte y emocional apego a la empresa. Y como podemos predecir, los clientes emocionalmente satisfechos se destacan de los racionalmente satisfechos en todas las dimensiones (gasto promedio, frecuencia de consumo, lealtad, tasa de defectos, etc.). Uno de los descubrimientos más fascinantes en este escenario es que los clientes racionalmente satisfechos se comportan de forma similar a aquellos que no están satisfechos. Esto se evidencia en MANAGE YOUR HUMAN SIGMA, un artículo de John Fleming, Curt Coffman y James Harter de Harvard Business Review [Manage your human sigma, 2005], donde se muestra que los clientes no satisfechos de una tarjeta de crédito internacional resultan virtualmente 23


Manejo de expectativas en los proyectos informáticos Universidad de Buenos Aires - Facultad de Ingeniería

Ariel D. Schapiro Padrón 80.885

indistinguibles de los clientes racionalmente satisfechos en cuanto a su comportamiento en las compras. Mientras que los clientes emocionalmente satisfechos por factores como el servicio, funcionalidades y la imagen de la marca, gastaron en promedio más que la gente en los otros grupos:

Figura 9: Gastos mensuales promedios de clientes de tarjeta de crédito, según MANAGE YOUR HUMAN SIGMA [Manage your human sigma, 2005]

Como explican John Fleming y Jim Asplund en HUMAN SIGMA [Fleming, y otros, 2007], con el objetivo de construir las conexiones con los clientes que producen un aumento en los beneficios para el proveedor, una vista más completa del cliente es necesaria; y ésta debe incorporar un entendimiento de las dimensiones emocionales del compromiso del cliente y de las expectativas involucradas. Esto no solamente nos ayudará a cumplir con las expectativas del cliente en términos de entregables (satisfacción racional), sino que además asegurará una buena relación con el cliente (satisfacción emocional) que funcionará de cimientos sólidos a la hora de que la organización del cliente encare nuevos proyectos. En el presente, las relaciones de negocios duraderas son codiciadas y es así como se habla de socios tecnológicos, e inclusive de socios en el camino del aprendizaje. Estos caminos solo son viables cuando conocemos bien a nuestros clientes, sabemos cuáles son sus expectativas y nos identificamos con sus metas. Según Jens Egerland, [Egerland, 2003], de esto se trata un conveniente manejo de expectativas.

24


Manejo de expectativas en los proyectos informáticos Universidad de Buenos Aires - Facultad de Ingeniería

Ariel D. Schapiro Padrón 80.885

2.5. Implementación 2.5.1. El Manejo de Expectativas frente a los cambios de requerimientos "Es un mal plan que no admite modificación", Publio Siro Según un artículo publicado por el Standish Group, CHAOS: A RECIPE FOR SUCCESS [The Standish Group, 1999], Los cambios de requerimientos suelen existir en la mayoría de los proyectos informáticos en sus etapas tanto de planeamiento como de desarrollo. El hecho de invertir un mayor esfuerzo en los ciclos de análisis de requerimientos puede favorecer a contar con una menor tasa de requerimientos cambiados en los pasos siguientes. Sin embargo estamos muy lejos de poder afirmar con certeza que no estaremos en presencia de alteraciones futuras en las especificaciones del sistema. Nuestros clientes son humanos: tienen visiones incompletas, otros asuntos en sus cabezas y una comunicación imperfecta [Fleming, y otros, 2007]. Y como si eso fuera poco, a veces las circunstancias del negocio cambian; en muchas oportunidades de forma rápida y en repetidas ocasiones. Es por eso que aunque se comuniquen requerimientos completos de forma perfecta; ellos podrían quedar obsoletos en semanas o un par de meses. Por lo general, el equipo de desarrollo puede establecer un límite en el ciclo de vida del proyecto desde donde no se aceptarán cambios en los requerimientos y cualquier pedido de cambio posterior está fuera de ser tenido en cuenta. Esto es un claro ejemplo de las expectativas propuestas por el equipo de desarrollo que muchas veces no se condicen con la realidad de los negocios. Según Robin Goldsmith, autor de DISCOVERING REAL BUSINESS REQUIREMENTS FOR SOFTWARE PROJECT [Goldsmith, 2004], estos cambios de requerimientos, propios de la mayoría de los proyectos, pueden tener un impacto negativo en el desarrollo si no se les da lugar en un principio dentro del esquema de trabajo conjunto entre el equipo de desarrollo y los clientes. Muchas estrategias y herramientas ayudan a que las expectativas del equipo se acomoden a la realidad del negocio, y por consiguiente los ciclos de vida de los proyectos de software muten para aceptar a los cambios de requerimientos como algo esperado y natural. Las metodologías de trabajo que contemplen estos cambios de requerimientos podrían en este sentido garantizar, por un lado que las expectativas sobre los cambios de requerimientos por 25


Manejo de expectativas en los proyectos informáticos Universidad de Buenos Aires - Facultad de Ingeniería

Ariel D. Schapiro Padrón 80.885

parte del equipo se cumplan y por el otro lado, que las que mantienen los clientes en cuanto a su libertad para agregar, modificar o quitar requerimientos también lo hagan. Cómo puede un proyecto soportar cambios en los requerimientos sin poner en jaque sus posibilidades de éxito será una cuestión que cada metodología de desarrollo se animará a responder o a desacreditar.

26


Manejo de expectativas en los proyectos informáticos Universidad de Buenos Aires - Facultad de Ingeniería

Ariel D. Schapiro Padrón 80.885

3. Solución propuesta: Artefactos que ayudan en el Manejo de Expectativas A continuación expondremos artefactos que surgieron de la investigación de la presente tesis y que forman parte de esfuerzos por manejar las expectativas de los involucrados en el proyecto. Varios de estos artefactos integran el conjunto de herramientas que se usan en metodologías de desarrollo de software de hoy día y exponen conceptos como el reporte frecuente o establecimiento de objetivos comunes.

3.1. Visión & Misión "Visión sin acción es un sueño. Acción sin visión es una pesadilla." Proverbio japonés. El hecho de contar con un estado aspirado (visión) y un plan para llegar allí (misión) es solo el primer paso en este sentido. Como se explica en MANAGING SOFTWARE REQUIREMENTS [Leffingwell, y otros, 1999], de poco sirve contar con un elaborado y distinguido cuadro de situación a futuro, que sea específico, medible, realizable, relevante y enmarcado en el tiempo, si éste no es compartido y consensuado por todos los involucrados en el desarrollo de un proyecto. Es decir, el hecho de contar con una visión y misión adecuadas, es un arma poderosa en el manejo de expectativas si se da el caso que el cliente comparte y defiende esa declaración. De esta manera una visión compartida es un buen puntapié inicial en el desarrollo de un proyecto, no solo porque plantea un horizonte en común si no porque desde el comienzo intenta que la diferencia en expectativas entre el cliente y el proveedor sea la mínima. De la visión compartida se puede extraer una misión también consensuada, donde se establezcan planes para llegar a esa situación descripta en la visión. Es así como se empiezan a trazar las primeras estrategias en el desarrollo del software, y si esto está consensuado por el cliente desde un comienzo, entonces también podemos decir que la diferencia entre las expectativas del cliente y el avance del proyecto apuntará al equilibrio. En el caso que la metodología de desarrollo aplicada al proyecto cuente con la posibilidad de ajustar la visión y/o la misión a lo largo del proyecto, es fundamental que en cada una de las oportunidades donde aquellas son modificadas, el cliente también esté involucrado en el cambio. Estas medidas apuntan a disminuir la diferencia entre las expectativas del cliente y el avance corriente del equipo, tendiendo a una zona de equilibrio como se describe en la Figura 7. 27


Manejo de expectativas en los proyectos informáticos Universidad de Buenos Aires - Facultad de Ingeniería

Ariel D. Schapiro Padrón 80.885

3.2. Lista priorizada de requerimientos del producto (“Product Backlog”) Básicamente el “Product Backlog” es una lista priorizada de ítems a resolver en un proyecto que muchas veces no incluye la complejidad de las estimaciones. Como explica Ken Schwaber en THE ENTERPRISE AND SCRUM [Schwaber, 2007], su valor proviene del orden estricto en sus elementos: el cliente puede llamar a varios requerimientos igualmente prioritarios, pero en esta lista no hay manera de colocar dos ítems a la misma altura. Como resultado de esto, el equipo puede tener el foco en lo que le representa más valor al cliente en cada momento. Esta lista no es estática, pues cambia con el tiempo: a medida que el equipo va completando los ítems más prioritarios, los ítems de más abajo en la lista se dividen en ítems más granulares, se remueven ítems y a veces se agregan ítems a media que se va ganando entendimiento en el área, tecnología o mercado. En base a todo esto, en cualquier punto del desarrollo en un proyecto donde se mantiene un “Product Backlog” actualizado y ordenado, es posible identificar la dirección del proyecto. Schwaber también explica que los “Product Backlogs” son un poco distintos de otras listas de tareas. Las diferencias provienen de detalles en la forma en la que se usa la lista: 

Un “Product Backlog” siempre enlista ítems que le agregan valor al cliente. Pueden ser ítems funcionales y no funcionales. Puede también incluir ítems requeridos por el equipo, pero solo los que eventualmente le traerán valor al cliente.

Un “Product Backlog” no debería incluir tareas de bajo nivel y requerimientos de construcción concretos de artefactos. Por ejemplo, no debería incluir requerimientos para producir documentación de diseño a menos que el cliente lo tenga que entregar en el futuro por algún propósito.

Cuanto más alto se ubican en el “Product Backlog” los ítems, lo más detallados deberían ser. Los ítems de menor prioridad deberían estar definidos en forma amplia e imprecisa.

En la investigación del presente trabajo, uno de los factores que se analizaron como posibles causas de fracasos de los proyectos es el hecho de no contar con requerimientos lo suficientemente completos al inicio del proyecto. Como dijimos anteriormente, muchas veces el cliente no tiene un entendimiento completo de lo que quiere al inicio del proyecto, mucho menos de lo que realmente necesita y por consiguiente los requerimientos iniciales pueden ser pobres e inconsistentes. El

28


Manejo de expectativas en los proyectos informáticos Universidad de Buenos Aires - Facultad de Ingeniería

Ariel D. Schapiro Padrón 80.885

Product Backlog no viene a ayudar en contar con una definición más completa y consistente de los requerimientos, si no en una definición de los mismos que se ajuste con el tiempo. En este sentido las metodologías que implementan esta lista priorizada de tareas, no esperan tener una lista de requerimientos definitiva si no una que solamente les permita empezar, para luego refinarla iteración a iteración [Schwaber, 2007]. En base a esto, es posible que el inconveniente de los requerimientos no resida en que no sean suficientes en el inicio, si no que no se renueven a lo largo del tiempo.

29


Manejo de expectativas en los proyectos informáticos Universidad de Buenos Aires - Facultad de Ingeniería

Ariel D. Schapiro Padrón 80.885

3.3. Reuniones de planeamiento y reporte con el cliente En el capítulo El manejo de expectativas en los proyectos informáticos, hemos indicado en la teoría como la creación de encuentros que equilibren la diferencia entre las expectativas del cliente y aquellas del proveedor pueden colaborar en mantener al proyecto lejos de una zona de riesgo. En proyectos que implementen un trabajo iterativo, dichos encuentros se repiten con una frecuencia de una iteración y por lo general suelen consistir en reuniones o bien enfocadas en el planeamiento o bien enfocadas en el reporte al cliente [Bittner, et al., 2007]. Al combinar este enfoque con un artefacto como una lista priorizada de requerimientos del producto (“Product Backlog”), dichas reuniones pueden incluir un planeamiento de la iteración corriente usando la lista de requerimientos del equipo, o bien una demostración del trabajo realizado a lo largo de la iteración, donde se apuntó a completar los requerimientos definidos para dicha iteración [Schwaber, 2007].

Figura 10: Reuniones como parte del proceso iterativo

Como se muestra en la figura anterior, podemos contar con los siguientes puntos de equilibrio de expectativas a lo largo del proceso:

30


Manejo de expectativas en los proyectos informáticos Universidad de Buenos Aires - Facultad de Ingeniería

Ariel D. Schapiro Padrón 80.885

3.3.1. Planeamiento de la Iteración Al principio de cada iteración, se planifica las metas y objetivos en conjunto con el representante del cliente. En base al backlog de producto que se encuentra priorizado por el representante del cliente, el equipo de producción estima hasta que ítem de esa lista se compromete a implementar en la iteración que comienza. El resultado de esta reunión será una porción del backlog de producto que será el backlog de la iteración. Este último puede ser desagregado en ítems más granulares dependiendo de la complejidad de los ítems originales. Dicho resultado de la reunión es una especie de “contrato” entre el equipo de desarrollo y el representante del cliente que se mantendrá intacto a lo largo de la iteración. En el caso de que del lado del cliente haya un deseo de alterar las prioridades, esto se deberá realizar una vez que la presente iteración haya finalizado; y el nuevo backlog de producto será tenido en cuenta en la próxima reunión de Planeamiento de Iteración.

31


Manejo de expectativas en los proyectos informáticos Universidad de Buenos Aires - Facultad de Ingeniería

Ariel D. Schapiro Padrón 80.885

3.3.2. Sincronización diaria del equipo (planeamiento) Como explica Peter Schuh en INTEGRATING AGILE DEVELOPMENT IN THE REAL WORLD [Schuh, 2004], el objetivo de esta reunión es que rápidamente y antes de ponerse a trabajar, el equipo se ponga de acuerdo en cuales van a ser las tareas del día para cada integrante en base a las realizadas en el día de trabajo anterior. Para esto, metodologías como Scrum implementan una estructura de reunión donde cada integrante del equipo responde a 3 simples preguntas: 

¿En qué he trabajado desde la reunión de ayer?

¿En qué trabajaré hoy?

¿Qué inconvenientes me bloquean para realizar mis tareas?

Estas reuniones no suelen durar más de 15 minutos y se suelen llamar reuniones de “stand up” por el hecho de que con el fin de que sean ágiles y rápidas, sus integrantes lo hacen de parados en vez de sentarse alrededor de una mesa como en otros reuniones más extensas.

32


Manejo de expectativas en los proyectos informáticos Universidad de Buenos Aires - Facultad de Ingeniería

Ariel D. Schapiro Padrón 80.885

3.3.3. Reporte diario del avance del equipo En algún momento del día, por lo general al final de la jornada laboral, el equipo se puede encargar de comunicar brevemente los resultados de lo que estuvo realizando durante el día. Según Julie Morgenstern, autora de MAKING WORK WORK [Morgenstern, 2004], esta comunicación le puede servir al cliente para ir teniendo un avance del equipo a lo largo de la iteración, sin necesidad de esperar hasta el fin de la misma para enterarse de lo que se avanzó, con el riesgo de que esto no sea lo que se estaba esperando.

33


Manejo de expectativas en los proyectos informáticos Universidad de Buenos Aires - Facultad de Ingeniería

Ariel D. Schapiro Padrón 80.885

3.3.4. Revisión de la Iteración (reporte) Al final de cada ciclo iterativo, se lleva a cabo una reunión que permite la evaluación del proceso por parte del cliente y de todos los involucrados. Como se explica en THE ENTERPRISE AND SCRUM [Schwaber, 2007], en esta instancia surgen las adaptaciones al producto y es en este momento cuando el equipo presenta al cliente el incremento en la funcionalidad del producto que construyó. El resultado de esta reunión puede ser una minuta que incluye la devolución por parte del cliente del avance en el producto y también puede derivarse en una re-priorización del backlog de producto.

34


Manejo de expectativas en los proyectos informáticos Universidad de Buenos Aires - Facultad de Ingeniería

Ariel D. Schapiro Padrón 80.885

3.3.5. Reuniones de retrospectiva de la iteración Según Esther Derby y Diana Larsen, las autoras de AGILE RETROSPECTIVES: MAKING GOOD TEAMS GREAT [Derby, y otros, 2006], estas reuniones suelen ser una pieza clave dentro del proceso de mejora del equipo de desarrollo. Al finalizar la iteración, el equipo evalúa su desempeño: analiza en qué aspectos tuvo éxito y en cuáles falló. Esto se hace con el objetivo de que, iteración a iteración, el equipo conozca en qué áreas debe esforzarse más y así lograr una mejora continua de su trabajo. El resultado de esta reunión es una lista de ítems evaluados como “buenos”, “malos” y “a mejorar”. Dentro de las claves del éxito de las reuniones de retrospectiva podrían incluirse los siguientes puntos: 

Que las conclusiones de una reunión de retrospectiva reflejen las opiniones profundas y reales de los integrantes del equipo sobre el nivel de performance del mismo, tanto a nivel técnico como no técnico.

Que las conclusiones de una reunión de retrospectiva de una iteración sean tenidas en cuenta en las iteraciones sucesivas con el objetivo de mejorar la performance del equipo.

Esta herramienta en particular puede ayudar a equilibrar las expectativas internas del equipo, haciendo que sus integrantes estén de acuerdo sobre lo que se espera del nivel con que el equipo realiza sus tareas y por otro lado que colaboren en los puntos que ellos mismos identifican como débiles.

35


Manejo de expectativas en los proyectos informáticos Universidad de Buenos Aires - Facultad de Ingeniería

Ariel D. Schapiro Padrón 80.885

3.4. Entrega Frecuente George Stepanek, autor de SOFTWARE PROJECT SECRETS: WHY SOFTWARE PROJECTS F AIL [Stepanek, 2005], explica que un error crítico que un miembro de un equipo puede llegar a cometer es asumir que el cliente no necesita interactuar con el software hasta que esté “listo”. En un proyecto administrado tradicionalmente, esto puede implicar esperar meses o incluso años antes de que los usuarios puedan revisar el software. Un malentendido normal puede implicar meses de esfuerzo desperdiciado, sin mencionar los costos aparejados. Inclusive cuando los requerimientos han sido bien interpretados, un período muy largo antes de que el usuario pueda revisar, puede implicar resistencia por parte del equipo de desarrollo a los cambios propuestos por el usuario. A pesar de que la funcionalidad o aplicación pueden ser aceptables, es posible que sea más compleja o menos robusta que lo que el usuario estaba esperando y eso puede resultar muy tarde o muy costoso de cambiar. Según Stepanek, un enfoque más ágil propone en tener una respuesta rápida del usuario que pueda mitigar problemas como la mala comunicación, requerimientos mal interpretados y decisiones pobres sobre la interfaz de usuario. Cuanto más el usuario pueda tocar el producto de software en desarrollo, más claro será en clarificar requerimientos y encaminar el proyecto. Antes de comenzar a escribir el software, pequeñas pruebas de concepto o prototipos pueden ayudar en comunicar las intenciones de forma efectiva. Un enfoque consiste en dibujar las pantallas en un papel o en un pizarrón y recorrerlas junto con el usuario a través de casos de uso típicos de la aplicación. Siguiendo la misma línea, podríamos decir que durante el proyecto, es conveniente liberar el software en desarrollo para revisión por lo menos al final de cada iteración, dándole al cliente la oportunidad de revisar el progreso y verificar el entendimiento del equipo. Es posible, inclusive, recibir una devolución aún más valiosa si además de liberar el software en desarrollo para que el cliente lo pueda usar, se realizan presentaciones por parte del equipo de desarrollo del mismo. El hecho de contar con devoluciones frecuentes, uno de los elementos que subrayamos de la práctica del manejo de expectativas, puede convertirse en uno de los elementos claves en el éxito de un proyecto.

36


Manejo de expectativas en los proyectos informáticos Universidad de Buenos Aires - Facultad de Ingeniería

Ariel D. Schapiro Padrón 80.885

3.5. Manejo de riesgos Los riesgos son factores externos que amenazan la habilidad del proyecto de alcanzar los entregables deseados [Bittner, et al., 2007]. Según Bittner y Spence, para controlar esos riesgos, es necesario identificarlos y luego evaluar su probabilidad de ocurrencia e impacto. Inicialmente, esto puede incluir los riesgos y limites generales del proyecto como su plazo, recursos, estándares, procesos, etc. A medida que el proyecto avanza, riesgos más detallados pueden ser agregados a la lista. Esta lista puede convertirse en una buena herramienta a la hora de manejar las expectativas de los clientes: el hecho de mantener abierta esa lista por parte del equipo de desarrollo promueve el involucramiento de los clientes y por otro lado afirma la idea de que el equipo tiene el control sobre el proyecto. Según Kurt Bittner [Bittner, et al., 2007], un error común es que los líderes de proyectos escondan los riesgos de otros involucrados, como si el hecho de exponer esos riesgos diera la impresión de que ellos no tienen el control del proyecto o que ellos no son buenos líderes. En la misma línea, Bittner afirma que esta es una de las prevalentes, peligrosas y poco profesionales práctica en la industria del software. La lista a mantener con los riesgos del proyecto puede contener una descripción de los riesgos, su probabilidad de ocurrencia, su impacto, exposición y plan de mitigación. Si esta lista es actualizada y comunicada de forma frecuente al cliente, estaremos entonces manejando las expectativas de los clientes por lo menos en cuanto a los riesgos que aparecen a lo largo del proyecto.

37


Manejo de expectativas en los proyectos informáticos Universidad de Buenos Aires - Facultad de Ingeniería

Ariel D. Schapiro Padrón 80.885

4. Investigación 4.1. Objetivos La investigación se realizó con el objetivo de brindar datos empíricos acerca del rol e implementación del manejo de expectativas en los proyectos, que permitan elaborar piezas de información tendientes a: 1. Verificar o refutar la hipótesis planteada. 2. Agregar información relacionada al papel del manejo de expectativas en los proyectos de desarrollo de software locales. Este último objetivo pretende añadir un valor agregado, con el fin de enriquecer aún más el estado del arte de la industria del software.

38


Manejo de expectativas en los proyectos informáticos Universidad de Buenos Aires - Facultad de Ingeniería

Ariel D. Schapiro Padrón 80.885

4.2. Criterios en los que se basan las preguntas de la encuesta Las preguntas de la encuesta que cubre la presente investigación están orientadas a cubrir los objetivos propuestos. A continuación se detallarán los criterios específicos para cada una de las secciones de las preguntas: 4.2.1. Contexto El manejo de expectativas, así también como la complejidad en las comunicaciones puede variar según el tamaño de la empresa o el grado de riesgos involucrados en proyectos, en base a pautas establecidas por implementaciones certificadas de los procesos. 4.2.2. Detalles del proyecto Esta sección cubre información acerca de los criterios básicos en el manejo de proyectos: alcance, plazo, medida del equipo y presupuesto. A la hora de medir el manejo de expectativas y el resultado final del proyecto, estas dimensiones nos proporcionarán la información básica para comparar un proyecto con otro. 4.2.3. Relación con el Cliente Algunas de las preguntas que definen el grado en que se midieron las expectativas a lo largo del proyecto figuran en esta sección. Se trata de la comunicación con el cliente, su percepción, el tratamiento de sus expectativas y algunos datos de contexto como la ubicación del cliente con respecto a la del equipo de desarrollo. 4.2.4. Resultados del Proyecto Esta sección nos permite medir el grado de éxito obtenido en el proyecto, el grado de cumplimiento de las expectativas del cliente y algunos datos de contexto como la cantidad de recomienzos en el proyecto. Estas mediciones otorgan la información necesaria para corroborar la hipótesis planteada en base a la información recolectada en las secciones anteriores. 4.2.5. Detalles de metodología Dado que muchas prácticas y herramientas en el desarrollo de software se encuentran circunscriptas en metodologías de desarrollo de software en particular, el hecho de obtener información acerca de las metodologías seguidas en proyectos con distinto tipo de resultados en el manejo de expectativas, nos hará extraer patrones y conclusiones que vinculen los resultados con las metodologías implementadas. 39


Manejo de expectativas en los proyectos informáticos Universidad de Buenos Aires - Facultad de Ingeniería

Ariel D. Schapiro Padrón 80.885

4.2.6. Opinión Metodología y factores de éxito/fracaso: esta sección brinda información acerca de la percepción de la audiencia sobre los factores que influyen en los resultados de los proyectos. De aquí se podrán extraer conclusiones que agreguen información acerca de la relación que existe entre los hechos demostrados en el resto de las secciones y las percepciones de la audiencia.

40


Manejo de expectativas en los proyectos informáticos Universidad de Buenos Aires - Facultad de Ingeniería

Ariel D. Schapiro Padrón 80.885

4.3. Encuesta aplicada 4.3.1. Metodologías de relevamiento Con el fin de relevar los datos empíricos acerca del papel del manejo de expectativas en los proyectos en la industria informática local, se planteó una serie de preguntas de tipo “multiple choice” en versión impresa para encuestas presenciales y en una versión online publicada en Internet. Se utilizó el sitio web http://www.reportesoftware.com.ar/ con el fin de presentar el objetivo de la investigación, los términos y condiciones, datos sobre la encuesta y una entrada a la encuesta en sí. La siguiente figura muestra el sitio web en cuestión:

Figura 11: http://www.reportesoftware.com.ar/ como página de inicio a la encuesta 41


Manejo de expectativas en los proyectos informáticos Universidad de Buenos Aires - Facultad de Ingeniería

Ariel D. Schapiro Padrón 80.885

4.3.2. Términos y Condiciones Los términos y condiciones que se firmaron antes de contestar cada instancia de la encuesta fueron los siguientes: Ariel Schapiro tomará los datos relevados con el fin de realizar un estudio acerca del papel del manejo de expectativas en los proyectos informáticos en la República Argentina. Los resultados de ese estudio se publicarán como parte de una Tesis de grado de la carrera Ingeniera en Informática de la facultad de Ingeniera, Universidad de Buenos Aires. La información resultante de los datos recabados sólo será revelada de forma agregada; por ejemplo "el 30% de los proyectos realizados en total por las empresas encuestadas resultaron exitosos". No se revelará información de ningún tipo que identifique directamente su origen.

42


Manejo de expectativas en los proyectos informáticos Universidad de Buenos Aires - Facultad de Ingeniería

Ariel D. Schapiro Padrón 80.885

4.3.3. Verificación de los datos La encuesta requirió datos de identificación a los participantes que sirvieron para luego corroborar: 

La existencia de la empresa en cuestión

El vínculo de la empresa con la industria

La participación de la persona en la encuesta

El cargo de la persona en la empresa

Cabe destacar que la validación se realizó para cada empresa encuestada, a partir de los datos de validación incluidos en la encuesta: 

Razón Social de la empresa en cuestión

Dirección física

Teléfono/s de contacto

Horarios de atención

Sitio web

Email de contacto

Industria y rubro

Años en el mercado

Nombre de la persona que llena la encuesta

Cargo dentro de la empresa

43


Manejo de expectativas en los proyectos informáticos Universidad de Buenos Aires - Facultad de Ingeniería

Ariel D. Schapiro Padrón 80.885

4.3.4. Preguntas Centrales La encuesta se expuso de una forma que posibilitó responder acerca de un proyecto informático como referencia. La siguiente lista de preguntas conforma la muestra de lo que fue la encuesta que relevó los datos necesarios sobre el grado de éxito en los proyectos, las metodologías usadas y el papel del manejo de expectativas en las mismas: 1. Contexto 1. Industria/rubro 2. Años de la empresa en el mercado 3. ¿Aproximadamente con cuántos empleados cuenta la empresa? a. Hasta 10 b. De 11 a 30 c. De 31 a 50 d. De 51 a 100 e. De 101 a 300 f. Más de 300 4. ¿La empresa cuenta con algún tipo de certificación? ¿Cuál? 2. Detalles del proyecto 1. El entregable consistía o estaba relacionado mayoritariamente con (marque más de una opción si aplica): a. Aplicación de línea de negocio b. Bases de datos c. Actualización de sistema d. Sitio Web e. Servicios Web f. Documentación 44


Manejo de expectativas en los proyectos informáticos Universidad de Buenos Aires - Facultad de Ingeniería

Ariel D. Schapiro Padrón 80.885

g. Otra (especifique) 2. ¿Cuál fue el plazo de entrega previsto inicialmente? 3. ¿Qué medida tenía el equipo que se encargó del proyecto? 4. ¿Cuál fue el presupuesto aproximado del proyecto? 3. Relación con el Cliente 1. ¿Se compartió con el cliente un detalle acerca del criterio de éxito del proyecto? 2. ¿En promedio, con qué frecuencia se ponía al tanto al cliente acerca del avance del proyecto? 3. ¿En caso de haberse detectado desvíos durante la ejecución del proyecto, qué acciones se llevaban a cabo? a. Ninguna en particular b. Se registraban y se comunicaban internamente c. Se tenía en cuenta para la próxima revisión/contacto con el cliente d. Se comunicaba inmediatamente al cliente e. Otra (especifique) 4. Durante el desarrollo del proyecto, el entendimiento de lo que esperaba el cliente era: a. Alto: estaba todo claro, no hubo dudas b. Medio: la mayoría de los puntos esperados estuvieron claros c. Bajo: un alto porcentaje de lo esperado no estuvo claro d. Nulo: prácticamente no se sabía que esperaba el cliente 5. ¿Se midió la percepción por parte del cliente de lo que se le estaba entregando a lo largo del proyecto? 6. En caso de contestar que si en la pregunta anterior, ¿se tuvo en cuenta esa medición en lo que siguió de desarrollo del proyecto? 45


Manejo de expectativas en los proyectos informáticos Universidad de Buenos Aires - Facultad de Ingeniería

Ariel D. Schapiro Padrón 80.885

7. En general la comunicación con el cliente fue: a. Muy fluida b. Medianamente fluida c. Poco fluida 8. Con respecto al lugar de desarrollo del proyecto, los clientes se ubicaban físicamente: a. A menos de 10 km. b. Entre 10 km. y 100 km. c. Entre 100 km. y 1000 km. d. A más de 1000 km. 9. ¿De qué forma se realizaban las reuniones con los clientes? a. Personalmente b. Telefónicamente c. Virtualmente d. Otra forma (especifique): e. No hubo reuniones con clientes 10. ¿Cómo considera la magnitud en los cambios de requerimientos? a. Nula b. Irrelevante c. Baja d. Media e. Alta f.

Muy Alta 46


Manejo de expectativas en los proyectos informáticos Universidad de Buenos Aires - Facultad de Ingeniería

Ariel D. Schapiro Padrón 80.885

4. Resultados del Proyecto 1. ¿Qué grado de éxito se logró? a. Éxito: se cumplieron favorablemente las metas definidas en un comienzo sobre plazos, costos, funcionalidad, recursos y calidad. b. Desviación: No se llegó a cumplir las metas definidas en un comienzo a causa de desvíos negativos en (marque más de una si aplica): 1. Nivel de funcionalidad solicitada. Se cumplió con el ______ % de lo provisto 2. Estándares de calidad requeridos. Se cumplió con el ______ % de lo provisto 3. Presupuesto económico. Se usó el ______ % de lo provisto 4. Plazo de entrega. Se usó el ______ % de lo provisto 5. Recursos (HH). Se usó el ______ % de lo provisto c. Fracaso: se canceló antes de completarse. 2. ¿En qué medida considera que las expectativas del cliente fueron cumplidas? a. En gran medida b. En mediana medida c. En baja medida 3. ¿Cuántos recomienzos hubo en el proyecto? a. 0 b. 1 c. 2 d. 3 e. 4 o más 47


Manejo de expectativas en los proyectos informáticos Universidad de Buenos Aires - Facultad de Ingeniería

Ariel D. Schapiro Padrón 80.885

5. Detalles de metodología 1. ¿Qué metodología de desarrollo de software se siguió? a. En cascada b. Prototipos c. Evolutivo d. Incremental e. En espiral f.

XP

g. Crystal h. Scrum i.

Otra/s (especifique)

j.

Ninguna en particular

6. Opinión: metodología y factores de éxito/fracaso 1. ¿En qué grado Ud. opina que las entregas parciales favorecen al resultado de la entrega? 2. ¿Cuáles de los siguientes Ud. opina que son los 3 factores más importantes en el éxito de un proyecto? a. Usuarios involucrados b. Soporte ejecutivo c. Requerimientos completos d. Planeación adecuada e. Expectativas realistas f.

Hitos pequeños

g. Gente competente 48


Manejo de expectativas en los proyectos informáticos Universidad de Buenos Aires - Facultad de Ingeniería

Ariel D. Schapiro Padrón 80.885

h. Equipo involucrado i.

Visión clara de los objetivos

j.

Trabajo duro

k. Otros (especifique) 3. ¿Cuáles de los siguientes Ud. opina que son los 3 factores más importantes en el desvío desfavorable de un proyecto? a. Usuarios poco involucrados b. Requerimientos y especificaciones incompletas c. Cambios frecuentes en los requerimientos y especificaciones d. Falta de soporte ejecutivo e. Incompetencia tecnológica f.

Falta de recursos

g. Expectativas no realistas h. Objetivos poco claros i.

Cronogramas irreales

j.

Nuevas tecnologías

k. Otros (especifique) 4. ¿Cuáles de los siguientes Ud. opina que son los 3 factores más importantes que causan que un proyecto se cancele? a. Requerimientos/especificaciones incompletas b. Usuarios poco involucrados c. Falta de recursos d. Expectativas irreales 49


Manejo de expectativas en los proyectos informáticos Universidad de Buenos Aires - Facultad de Ingeniería

Ariel D. Schapiro Padrón 80.885

e. Falta de soporte ejecutivo f.

Requerimientos/especificaciones cambiantes

g. Falta de planeamiento h. “No se necesitaba más” i.

Falta de gerencia de IT

j.

Incompetencia tecnológica

k. Otros (especifique) 5. Con respecto a 5 años atrás, su opinión acerca de la cantidad de proyectos fallidos es que: a. Disminuyó considerablemente b. Disminuyó c. Es similar a la actual d. Aumentó e. Aumentó considerablemente

50


Manejo de expectativas en los proyectos informáticos Universidad de Buenos Aires - Facultad de Ingeniería

Ariel D. Schapiro Padrón 80.885

4.3.5. Muestra de empresas Las siguientes empresas pequeñas, medianas y grandes formaron parte de la audiencia de la encuesta. Se trata de empresas que desarrollan aplicaciones informáticas a través de su principal unidad de negocio o bien a través de su departamento de IT. Accenture (Outsourcing de Productos) Accusys Adexus S.A. América Software Artware Autologica AXG Tecnonexo BeyondIT technology Bracketmedia C & S Informática Cargill SACI Carriers Intrerconnect S.A CDA Cubika Dimnetcorp ED Soft EDS Epexo Eukinetos e-volution Digital Margeting Finnegans Focus Marketing Group G & L Group Globant Grupo Hasar Grupo Most Heinsohn Hexacta HP Argentina Intelap La Caja de Seguros

Latin 3 Latinvia Lenovo Argentina Level Extreme Mapfre Mastersoft Mercap Software MoebiusIT Neoris Argentina Novamens Oikoss S.A. Pan American Energy LLC Plenitas Pragmind S.A. Procom S.R.L. Quadion Technologies Repsol YPF RMyA Southworks Synapsis Team Quality S.A Tecnosoftware S.A Telesoft CRM Ten Roses Thales Three Melons Unitech Vanward IT Verizon Business Argentina Xioma Consultores S.A

51


Manejo de expectativas en los proyectos informáticos Universidad de Buenos Aires - Facultad de Ingeniería

Ariel D. Schapiro Padrón 80.885

4.3.6. Factores de la encuesta que se tienen en cuenta para medir el manejo de expectativas Como se explicará más en detalle en el Planteo del Análisis de validez de la hipótesis (prueba de hipótesis), se parte de una serie de respuestas de la encuesta a la hora de construir una imagen sobre el privilegio que se le da al manejo de expectativas en cada caso. Esta serie de respuestas que se utiliza para alimentar dicho indicador, está compuesta por las siguientes métricas: 1. Detalle compartido con el cliente acerca del criterio de éxito del proyecto 2. Frecuencia con la que en promedio se ponía al tanto al cliente acerca del avance del proyecto 3. Acciones que se llevaban a cabo en caso de haberse detectado desvíos durante la ejecución del proyecto 4. Entendimiento de lo que esperaba el cliente durante el desarrollo del proyecto 5. Medición de la percepción por parte del cliente de lo que se le estaba entregando a lo largo del proyecto 6. Consideración de esa medición en lo que siguió de desarrollo del proyecto 7. Comunicación con el cliente en general 8. Forma en la que se realizaban las reuniones con los clientes

52


Manejo de expectativas en los proyectos informáticos Universidad de Buenos Aires - Facultad de Ingeniería

Ariel D. Schapiro Padrón 80.885

4.3.7. Niveles de éxito planteados: diferencias entre el CHAOS Report y este estudio Como parte del CHAOS REPORT [The Standish Group, 1994] del Standish Group, se plantearon 3 posibles niveles de éxito para los proyectos investigados: 1. Exitoso: el proyecto es completado en plazo y en el presupuesto dado, con toda la funcionalidad que se planeó inicialmente 2. Desafiado: el proyecto es completado y está operativo pero se superó el presupuesto, el plazo y ofrece menor funcionalidad que la prevista inicialmente 3. Afectado: el proyecto es cancelado en algún punto de su ciclo de desarrollo Por otro lado, en la encuesta que formó parte de la investigación realizada para la corriente tesis, se plantearon 4 posibles grados de éxito en el proyecto: 1. Éxito: se cumplieron favorablemente las metas definidas en un comienzo sobre plazos, costos, funcionalidad, recursos y calidad 2. Desviación manejada: No se llegaron a cumplir las metas definidas en un comienzo a causa de desvíos negativos que fueron identificados, tratados y reportados al cliente. Esto generó un cambio en las metas que finalmente llegaron a cumplirse 3. Desviación negativa: No se llegaron a cumplir las metas definidas en un comienzo a causa de desvíos negativos 4. Fracaso: el proyecto se canceló antes de completarse Al analizar el CHAOS REPORT [The Standish Group, 1994], se identificó que el caso de “desviación manejada” podía representar un grado de éxito en el manejo de expectativas del cliente y por consiguiente del proyecto. Supongamos el caso de un proyecto donde los requerimientos iniciales son completos y suficientes, pero a lo largo del proyecto, el cliente se da cuenta que sus necesidades son otras. Si la metodología de desarrollo seguida a lo largo del proyecto lo soporta, el avance del equipo se puede ajustar a dichos requerimientos con la posibilidad de que se termine por cumplir con la necesidad del cliente que fue representada en requerimientos posteriores a los iniciales. Podremos decir que

53


Manejo de expectativas en los proyectos informáticos Universidad de Buenos Aires - Facultad de Ingeniería

Ariel D. Schapiro Padrón 80.885

estamos entonces frente a un caso de “desviación manejada” donde las expectativas del cliente fueron manejadas y el proyecto resultó relativamente exitoso. Definición del éxito Este caso en particular nos puede hacer reflexionar acerca de la definición misma de éxito. Desde un punto de vista clásico, como el manejado por el Standish Group al formular su CHAOS REPORT [The Standish Group, 1994], el éxito equivale a que el proyecto es completado en plazo y en el presupuesto dado, con toda la funcionalidad que se planeó inicialmente. En una entrevista realizada a Tom y Mary Poppendieck [Poppendieck, y otros, 2008], autores de IMPLEMENTING LEAN SOFTWARE DEVELOPMENT entre otros, Mary Poppendieck afirma que el éxito tiene que ver con los términos de negocio. Por ejemplo si se trata de un producto comercial, que éste logre una buena porción del mercado o signos interesantes de rentabilidad. En base al caso recién expuesto y a las definiciones de Mary Poppendieck, podríamos decir que el éxito se podría correlacionar con el estado al cual se llega luego de cumplir con las expectativas del cliente, donde la devolución consiste en valor agregado al negocio. Aquellos cuatro grados de éxito planteados en la encuesta, intentan representar un “continuo” en el grado de logros de un proyecto informático.

54


Manejo de expectativas en los proyectos informáticos Universidad de Buenos Aires - Facultad de Ingeniería

Ariel D. Schapiro Padrón 80.885

4.4. Uso de la herramienta de análisis estadístico La herramienta de análisis estadístico que (http://www.spss.com/la/productos/base/base.htm).

se

utilizó

fue

SPSS

Base

15.0

Como primer paso, en la solapa de “Vista de Variables”, se cargaron las variables correspondientes a las preguntas de la encuesta. Fueron cargadas las respuestas posibles para las preguntas con un set de respuestas definidas, como los resaltados en la siguiente figura:

Figura 12: Variables cargadas en SPSS

Una vez hecho esto, en la solapa de “Vista de Datos” en SPSS se aplicaron las respuestas recolectadas desde la aplicación web donde los participantes respondieron la encuesta. Nota: los detalles de estos datos no se muestran en esta sección por razones de confidencialidad explicados en los Términos y Condiciones de la encuesta.

55


Manejo de expectativas en los proyectos informĂĄticos Universidad de Buenos Aires - Facultad de IngenierĂ­a

Ariel D. Schapiro PadrĂłn 80.885

4.5. Planteo del AnĂĄlisis de validez de la hipĂłtesis (prueba de hipĂłtesis) Se darĂĄ como vĂĄlida la hipĂłtesis en el caso que se den como vĂĄlidos tres factores. De esta forma tenemos:

đ??ť = đ??´ ∊đ??ľâˆŠđ??ś Donde: H. Expresa la validez de la hipĂłtesis A. Expresa la validez de la afirmaciĂłn: “El papel del manejo de expectativas en el desarrollo de los proyectos informĂĄticos no estĂĄ lo suficientemente privilegiado en el ĂĄmbito localâ€? B. Expresa la validez de la afirmaciĂłn: “La implementaciĂłn de metodologĂ­as de desarrollo que lo incluyan (al manejo de expectativas) como aspecto fundamental ayudarĂĄn a disminuir la cantidad de proyectos fracasados o desviados, aumentando por consiguiente el grado de ĂŠxito en los mismos.â€? C. Expresa la validez de la afirmaciĂłn: “Quienes no incluyan al manejo de expectativas como aspecto fundamental obtendrĂĄn resultados sensiblemente inferiores a quienes si lo haganâ€?

A continuación estableceremos los criterios de validez para cada uno de los factores. Éstos constituirån las reglas de decisión de la prueba de hipótesis.

56


Manejo de expectativas en los proyectos informáticos Universidad de Buenos Aires - Facultad de Ingeniería

Ariel D. Schapiro Padrón 80.885

4.5.1. Análisis estadísticos que definen la validez de cada factor 4.5.1.1. Análisis estadístico que definirá la validez del factor A (regla de decisión A) El análisis estadístico que servirá para investigar en qué medida es válido este factor consistirá en que menos del 30% de los casos de la muestra cuentan cada uno con las respuestas satisfactorias (marcadas en verde y negrita) para demostrar que la empresa privilegia el manejo de expectativas. El valor del 30% proviene de los datos del CHAOS REPORT [The Standish Group, 1994]: éste establece que dentro de los factores que la audiencia valoró en vista al éxito en los proyectos, el involucramiento de los usuarios representa un 15,9%, mantener expectativas realistas un 8,2% y una corta frecuencia en los hitos del proyecto un 7,7%. Estos tres parámetros están muy relacionados con los factores de la encuesta que se utilizarán para medir el manejo de expectativas y suman el 31,8% de los casos. El CHAOS REPORT [The Standish Group, 1994] es una fuente confiable de datos y no contamos actualmente con una estadística precisa, actualizada y local acerca del manejo de expectativas como se entiende y expone en el presente trabajo. En base a esto utilizaremos la suma de aquellos tres parámetros como límite aproximado para establecer que menos del 30% de la muestra privilegia el manejo de expectativas. Las respuestas satisfactorias (marcadas en verde y negrita) para demostrar que la empresa privilegia el manejo de expectativas son: 1. ¿Se compartió con el cliente un detalle acerca del criterio de éxito del proyecto? SI… 2. ¿En promedio, con qué frecuencia se ponía al tanto al cliente acerca del avance del proyecto? MÁXIMO DE 15 DÍAS 3. ¿En caso de haberse detectado desvíos durante la ejecución del proyecto, qué acciones se llevaban a cabo? a. Ninguna en particular b. Se comunicaba inmediatamente al cliente c. Se tenía en cuenta para la próxima revisión/contacto con el cliente

57


Manejo de expectativas en los proyectos informáticos Universidad de Buenos Aires - Facultad de Ingeniería

Ariel D. Schapiro Padrón 80.885

d. Otra (especifique) 4. Durante el desarrollo del proyecto, el entendimiento de lo que esperaba el cliente era: a. Alto: estaba todo claro, no hubo dudas b. Medio: la mayoría de los puntos esperados estuvieron claros c. Bajo: un alto porcentaje de lo esperado no estuvo claro d. Nulo: prácticamente no se sabía que esperaba el cliente 5. ¿Se midió la percepción por parte del cliente de lo que se le estaba entregando a lo largo del proyecto? SI… 6. ¿Se tuvo en cuenta esa medición en lo que siguió de desarrollo del proyecto? SI… 7. En general la comunicación con el cliente fue: a. Muy fluida b. Medianamente fluida c. Poco fluida 8. ¿De qué forma se realizaban las reuniones con los clientes? a. Personalmente b. Telefónicamente c. Virtualmente d. Otra forma (especifique): e. No hubo reuniones con clientes

58


Manejo de expectativas en los proyectos informáticos Universidad de Buenos Aires - Facultad de Ingeniería

Ariel D. Schapiro Padrón 80.885

4.5.1.2. Análisis estadístico que definirá la validez del factor B (regla de decisión B) El análisis estadístico que servirá para investigar en qué medida es válido este factor consistirá en que como mínimo el 82% de los casos de la muestra donde sí se privilegió el manejo de expectativas (ver regla de decisión A), cuentan cada uno con las respuestas satisfactorias (marcadas en verde y negrita) que demuestran un grado satisfactorio de éxito en sus proyectos. El valor de 82% proviene de los últimos resultados que se tienen por parte del Standish Group acerca del grado de éxito en los proyectos: dado que nuestra intención es demostrar que en los casos donde se privilegió el manejo de expectativas se obtuvo resultados altamente exitosos, tomaremos como referencia la porción de proyectos exitosos (29%) y la porción de proyectos que resultaron desviados (53%) según el Standish Group. Si sumamos ambos, obtenemos un 82%, que básicamente representan todos los proyectos que no fueron cancelados. Dentro de la porción de proyectos desviados se encuentran, según los niveles de éxito a manejar en esta investigación, los casos de “desviaciones manejadas” y “desviaciones negativas”. Debido a que todavía no contamos con los datos de la encuesta que proporcionará cuantas son “desviaciones manejadas” y cuantas “desviaciones negativas”, usaremos la cota máxima resultante de los datos del Standish Group para proponer que el 82% de los casos de la muestra donde sí se privilegió el manejo de expectativas obtienen un grado satisfactorio de éxito en sus proyectos. Las respuestas satisfactorias (marcadas en verde y negrita) que demuestran un grado satisfactorio de éxito en sus proyectos son: 1. ¿Qué grado de éxito se logró? a. Éxito: se cumplieron favorablemente las metas definidas en un comienzo sobre plazos, costos, funcionalidad, recursos y calidad. b.Desviación manejada: No se llegó a cumplir las metas definidas en un comienzo a causa de desvíos negativos que fueron identificados, tratados y reportados al cliente. Estos desvíos consistieron en (marque más de una si aplica): 1. Nivel de funcionalidad solicitada. Se cumplió con el ______ % de lo previsto

59


Manejo de expectativas en los proyectos informáticos Universidad de Buenos Aires - Facultad de Ingeniería

Ariel D. Schapiro Padrón 80.885

2. Estándares de calidad requeridos. Se cumplió con el ______ % de lo previsto 3. Presupuesto económico. Se usó un ______ % más de lo previsto 4. Plazo de entrega. Se usó extendió un ______ % de lo previsto 5. Recursos (HH). Se usó un ______ % más de lo previsto c. Desviación negativa: No se llegó a cumplir las metas definidas en un comienzo a causa de desvíos negativos en (marque más de una si aplica): 1. Nivel de funcionalidad solicitada. Se cumplió con el ______ % de lo previsto 2. Estándares de calidad requeridos. Se cumplió con el ______ % de lo previsto 3. Presupuesto económico. Se usó el ______ % de lo previsto 4. Plazo de entrega. Se usó el ______ % de lo previsto 5. Recursos (HH). Se usó el ______ % de lo previsto d. Fracaso: se canceló antes de completarse. 4. ¿En qué medida considera que las expectativas del cliente fueron cumplidas? a. En gran medida b. En mediana medida c. En baja medida

60


Manejo de expectativas en los proyectos informáticos Universidad de Buenos Aires - Facultad de Ingeniería

Ariel D. Schapiro Padrón 80.885

4.5.1.3. Análisis estadístico que definirá la validez del factor C (regla de decisión C) El análisis estadístico que servirá para investigar en qué medida es válido este factor consistirá en que dentro de los casos de la muestra donde no se privilegió el manejo de expectativas (ver regla de decisión A), el porcentaje correspondiente a los casos donde se logró el éxito en los proyectos es sensiblemente menor al porcentaje de éxito logrado por quienes si privilegiaron el manejo de expectativas (ver regla de decisión B). Este porcentaje deberá ser inferior por lo menos en un 25% con respecto a los casos exitosos de quienes sí privilegiaron el manejo de expectativas. Este valor proviene de que se está buscando una diferencia sensible entre el grado de éxito entre dos poblaciones (la que maneja las expectativas en sus proyectos y la que no). Tomaremos como “sensible” a la máxima diferencia de proporciones de proyectos detectados como no fracasados (o sea exitosos o desviados) por el Standish Group entre 1994 y 2004. Ésta diferencia es del 25% y la encontramos entre los resultados del año 1996 (60% de proyectos no fracasados) y los del año 2002 (85% de proyectos no fracasados). De confirmarse esta regla de decisión, podríamos afirmar que el privilegio del manejo de expectativas estaría proporcionando una mejoría mayor que la detectada a lo largo de 10 años por el Standish Group. El conjunto de respuestas necesarias para esta regla de decisión es el mismo que para la regla de decisión B, donde se mide el mismo parámetro de éxito (respuestas marcadas en verde y negrita): 1. ¿Qué grado de éxito se logró? a. Éxito: se cumplieron favorablemente las metas definidas en un comienzo sobre plazos, costos, funcionalidad, recursos y calidad. b. Desviación manejada: No se llegó a cumplir las metas definidas en un comienzo a causa de desvíos negativos que fueron identificados, tratados y reportados al cliente. Estos desvíos consistieron en (marque más de una si aplica): 1. Nivel de funcionalidad solicitada. Se cumplió con el ______ % de lo previsto 2. Estándares de calidad requeridos. Se cumplió con el ______ % de lo previsto 3. Presupuesto económico. Se usó un ______ % más de lo previsto

61


Manejo de expectativas en los proyectos informáticos Universidad de Buenos Aires - Facultad de Ingeniería

Ariel D. Schapiro Padrón 80.885

4. Plazo de entrega. Se usó extendió un ______ % de lo previsto 5. Recursos (HH). Se usó un ______ % más de lo previsto c. Desviación negativa: No se llegó a cumplir las metas definidas en un comienzo a causa de desvíos negativos en (marque más de una si aplica): 1. Nivel de funcionalidad solicitada. Se cumplió con el ______ % de lo previsto 2. Estándares de calidad requeridos. Se cumplió con el ______ % de lo previsto 3. Presupuesto económico. Se usó el ______ % de lo previsto 4. Plazo de entrega. Se usó el ______ % de lo previsto 5. Recursos (HH). Se usó el ______ % de lo previsto d. Fracaso: se canceló antes de completarse. 5. ¿En qué medida considera que las expectativas del cliente fueron cumplidas? a. En gran medida b. En mediana medida c. En baja medida

62


Manejo de expectativas en los proyectos informĂĄticos Universidad de Buenos Aires - Facultad de IngenierĂ­a

Ariel D. Schapiro PadrĂłn 80.885

4.5.2. Diagrama de probabilidades El siguiente diagrama de probabilidades resume estas reglas:

Figura 13: Diagrama de probabilidades que resume los factores de la validez de la hipĂłtesis

Donde cada uno de los factores de la validez de la hipótesis define: 

Ă&#x2014; < 30% (Regla de decisiĂłn A)

ď&#x201A;ˇ

đ?&#x2018;Ľ â&#x20AC;˛ > 82% (Regla de decisiĂłn B)

ď&#x201A;ˇ

đ?&#x2018;Ś â&#x20AC;˛ + 25% â&#x2030;¤ đ?&#x2018;Ľ â&#x20AC;˛ (Regla de decisiĂłn C)

Y ademĂĄs, por tratarse de porcentajes: ď&#x201A;ˇ Ă&#x2014; + đ?&#x2018;Ś = 100 ď&#x201A;ˇ

đ?&#x2018;Ľ â&#x20AC;˛ + đ?&#x2018;Ľ â&#x20AC;˛â&#x20AC;˛ = 100

ď&#x201A;ˇ

đ?&#x2018;Śâ&#x20AC;˛ + đ?&#x2018;Śâ&#x20AC;˛â&#x20AC;˛ = 100

63


Manejo de expectativas en los proyectos informáticos Universidad de Buenos Aires - Facultad de Ingeniería

Ariel D. Schapiro Padrón 80.885

5. Resultados 5.1. Resultados del Análisis de validez de la hipótesis (prueba de hipótesis) Una vez que establecimos como será el análisis de validez de la hipótesis y la utilización de la herramienta, pasaremos a mostrar los resultados de aplicar la prueba de hipótesis al lote de datos recaudados en la encuesta.

Figura 14: Diagrama de resultados del Análisis de validez de la hipótesis

El siguiente gráfico explica los mismos datos mediante las proporciones de sus partes:

64


Manejo de expectativas en los proyectos informĂĄticos Universidad de Buenos Aires - Facultad de IngenierĂ­a

Ariel D. Schapiro PadrĂłn 80.885

Figura 15: Diagrama de resultados del AnĂĄlisis de validez de la hipĂłtesis

En base a lo anterior, verificaremos cada uno de los factores de la validez de la hipĂłtesis: ď&#x201A;ˇ

Ă&#x2014; = 24,59% â&#x2020;&#x2019; Ă&#x2014; < 30% â&#x2C6;´ se verifica la regla de decisiĂłn A.

ď&#x201A;ˇ

đ?&#x2018;Ľ â&#x20AC;˛ = 86,67% â&#x2020;&#x2019; đ?&#x2018;Ľ â&#x20AC;˛ > 82% â&#x2C6;´ se verifica la regla de decisiĂłn B.

ď&#x201A;ˇ

đ?&#x2018;Ś â&#x20AC;˛ = 36,96% â&#x2020;&#x2019; đ?&#x2018;Ś â&#x20AC;˛ + 25% â&#x2030;¤ đ?&#x2018;Ľ â&#x20AC;˛ â&#x2C6;´ se verifica la regla de decisiĂłn C.

Dado que los factores de validez de la hipĂłtesis (A, B y C en la siguiente ecuaciĂłn) resultaron vĂĄlidos, daremos por vĂĄlida la hipĂłtesis H:

đ??ť = đ??´ â&#x2C6;Šđ??ľâ&#x2C6;Šđ??ś

65


Manejo de expectativas en los proyectos informáticos Universidad de Buenos Aires - Facultad de Ingeniería

Ariel D. Schapiro Padrón 80.885

5.2. Resultados desagregados por pregunta de la encuesta A continuación se presentan los resultados de cada una de las preguntas de la encuesta agrupados por sección:

5.2.1. Contexto Industria/rubro La siguiente figura muestra que el rubro de la industria de mayor cobertura es el del Software a medida (54%), seguido por el de consultoría (25%).

Figura 16: Resultados sobre la Industria/Rubro de las empresas de la audiencia

66


Manejo de expectativas en los proyectos informáticos Universidad de Buenos Aires - Facultad de Ingeniería

Ariel D. Schapiro Padrón 80.885

Años de la empresa en el Mercado La siguiente figura expone que la mayoría de las empresas encuestadas (57%) cuentan con 3 a 5 años en el mercado; seguidas por las empresas que cuentan con menos de 2 años (18%).

Figura 17: Resultados sobre la edad de las empresas encuestadas en el mercado

67


Manejo de expectativas en los proyectos informáticos Universidad de Buenos Aires - Facultad de Ingeniería

Ariel D. Schapiro Padrón 80.885

¿La empresa cuenta con algún tipo de certificación? ¿Cuál? La siguiente figura muestra que la mayoría (61%) de las empresas encuestadas no cuentan con ningún tipo de certificación, mientras que el mayor grupo de empresas certificadas (26% del total) lo está bajo la norma ISO 9001:2000.

Figura 18: Resultados sobre tipos de certificaciones con los que cuentan las empresas encuestadas

68


Manejo de expectativas en los proyectos informáticos Universidad de Buenos Aires - Facultad de Ingeniería

Ariel D. Schapiro Padrón 80.885

5.2.2. Detalles del proyecto El entregable consistía o estaba relacionado mayoritariamente con… La siguiente figura expone que la mayoría (54%) de los proyectos de la muestra consistía en entregables de “Aplicaciones de líneas de negocio”, mientras que el segundo grupo (25%) estaba formado por sitios Web.

Figura 19: Resultados sobre los tipos de entregables de los proyectos involucrados en la muestra

69


Manejo de expectativas en los proyectos informáticos Universidad de Buenos Aires - Facultad de Ingeniería

Ariel D. Schapiro Padrón 80.885

¿Cuál fue el plazo de entrega previsto inicialmente (meses)? La siguiente figura muestra que la mayoría de los proyectos de la muestra (62%), estaba prevista para entregarse en el plazo de 3 a 5 meses, mientras que el segundo grupo, que solamente consistió en el 13% de los casos, estaba previsto a entregarse en un plazo de 0 a 2 meses.

Figura 20: Resultados sobre los plazos de entrega previstos inicialmente para los proyectos de la muestra

70


Manejo de expectativas en los proyectos informáticos Universidad de Buenos Aires - Facultad de Ingeniería

Ariel D. Schapiro Padrón 80.885

¿Qué medida tenía el equipo que se encargó del proyecto (cantidad de personas)? La siguiente figura muestra que el 28% de los proyectos relevados contaban con un equipo de 2 personas, el 23% con un equipo de 3 personas y el 20% con un equipo de 4 personas. Al agruparlos, podríamos decir que en los proyectos relevados, el 71% de los casos fueron de equipos de entre 2 y 4 integrantes.

Figura 21: Resultados sobre la medida del equipo que se encargó de cada proyecto de la muestra

71


Manejo de expectativas en los proyectos informáticos Universidad de Buenos Aires - Facultad de Ingeniería

Ariel D. Schapiro Padrón 80.885

¿Cuál fue el presupuesto aproximado del proyecto (en pesos argentinos)? La siguiente figura muestra que el mayor grupo de proyectos relevados (18%), contaba con presupuestos inferiores a $10.000. Por otro lado, podemos decir que casi la mitad de los proyectos relevados (48%) contaba con presupuestos inferiores a $50.000.

Figura 22: Resultados sobre el presupuesto aproximado de los proyectos de la muestra

72


Manejo de expectativas en los proyectos informáticos Universidad de Buenos Aires - Facultad de Ingeniería

Ariel D. Schapiro Padrón 80.885

5.2.3. Relación con el Cliente ¿Se compartió con el cliente un detalle acerca del criterio de éxito del proyecto? La siguiente figura muestra que en el 99% de los proyectos se compartió con el cliente un detalle acerca del criterio de éxito del proyecto. Solo en el 38% de los casos, esto se hizo por escrito.

Figura 23: Resultados sobre criterios de éxito del proyecto compartidos con el cliente

73


Manejo de expectativas en los proyectos informáticos Universidad de Buenos Aires - Facultad de Ingeniería

Ariel D. Schapiro Padrón 80.885

¿En promedio, con qué frecuencia se ponía al tanto al cliente acerca del avance del proyecto? La siguiente figura muestra que en el 66% de los proyectos se ponía al tanto al cliente acerca del avance del proyecto de forma semanal. Por otro lado, el 13% de los proyectos usó un reporte de avance de forma diaria para con el cliente.

Figura 24: Resultados sobre frecuencia de comunicación con el cliente acerca del avance del proyecto

74


Manejo de expectativas en los proyectos informáticos Universidad de Buenos Aires - Facultad de Ingeniería

Ariel D. Schapiro Padrón 80.885

¿En caso de haberse detectado desvíos durante la ejecución del proyecto, qué acciones se llevaban a cabo? La siguiente figura muestra que en casi la mitad de los casos (48%), los desvíos detectados se tenían en cuenta para la próxima revisión o contacto con el cliente, mientras que en el 36% de los casos estos desvíos eran comunicados inmediatamente al cliente.

Figura 25: Resultados sobre acciones tomadas al detectar desvíos

75


Manejo de expectativas en los proyectos informáticos Universidad de Buenos Aires - Facultad de Ingeniería

Ariel D. Schapiro Padrón 80.885

Durante el desarrollo del proyecto, el entendimiento de lo que esperaba el cliente era… La siguiente figura muestra que en la gran mayoría de los casos, el entendimiento de lo que esperaba el cliente a lo largo del proyecto era medio, es decir que la mayoría de los puntos esperados estuvieron claros. Solo el 8% de los casos relevados se manifestaron por un alto o bajo grado de entendimiento.

Figura 26: Resultados sobre el entendimiento de lo que esperaba el cliente a lo largo del proyecto

76


Manejo de expectativas en los proyectos informáticos Universidad de Buenos Aires - Facultad de Ingeniería

Ariel D. Schapiro Padrón 80.885

¿Se midió la percepción por parte del cliente de lo que se le estaba entregando a lo largo del proyecto? La siguiente figura muestra que prácticamente en la mitad de los proyectos, se midió la percepción por parte del cliente de lo que se le estaba entregando a lo largo del proyecto y en la otra mitad no.

Figura 27: Resultados sobre la medición de la percepción por parte del cliente de lo que se le estaba entregando a lo largo del proyecto

77


Manejo de expectativas en los proyectos informáticos Universidad de Buenos Aires - Facultad de Ingeniería

Ariel D. Schapiro Padrón 80.885

En caso de contestar que si en la pregunta anterior, ¿se tuvo en cuenta esa medición en lo que siguió de desarrollo del proyecto? La siguiente figura muestra que dentro de los casos donde sí se midió la percepción por parte del cliente de lo que se le estaba entregando a lo largo del proyecto, el 90% de los casos tuvo en cuenta esa percepción en lo que siguió del desarrollo del proyecto.

Figura 28: Resultados sobre si se tuvo en cuenta la medición de la percepción por parte del cliente de lo que se le estaba entregando a lo largo del proyecto en lo que siguió del proyecto

78


Manejo de expectativas en los proyectos informáticos Universidad de Buenos Aires - Facultad de Ingeniería

Ariel D. Schapiro Padrón 80.885

En general la comunicación con el cliente fue… La siguiente figura muestra que casi la mitad de los casos relevados mantuvo una comunicación con el cliente muy fluida, mientras que solamente el 11% de los casos mantuvo comunicaciones poco fluidas con sus clientes.

Figura 29: Resultados sobre la calidad en la comunicación con el cliente

79


Manejo de expectativas en los proyectos informáticos Universidad de Buenos Aires - Facultad de Ingeniería

Ariel D. Schapiro Padrón 80.885

Con respecto al lugar de desarrollo del proyecto, los clientes se ubicaban físicamente… La siguiente figura muestra que la mayoría (51%) de los casos registraron a clientes que se ubicaron a más de 1.000 km. del equipo de desarrollo. Este grupo puede corresponder a desarrollos realizados para clientes en el exterior. Por otro lado, el segundo grupo en importancia (38%) pertenece a aquellos proyectos donde el cliente se ubicaba a menos de 10 km.

Figura 30: Resultados sobre distancias de los clientes a los equipos de desarrollo

80


Manejo de expectativas en los proyectos informáticos Universidad de Buenos Aires - Facultad de Ingeniería

Ariel D. Schapiro Padrón 80.885

¿De qué forma se realizaban las reuniones con los clientes? La siguiente figura muestra que el medio telefónico se usó para casi la mitad de los casos (47%), mientras que las reuniones personales correspondieron el 28% de los casos.

Figura 31: Resultados sobre la forma en la que se realizaban las reuniones con los clientes

81


Manejo de expectativas en los proyectos informáticos Universidad de Buenos Aires - Facultad de Ingeniería

Ariel D. Schapiro Padrón 80.885

¿Cómo considera la magnitud en los cambios de requerimientos? La siguiente figura muestra que la mayoría de los casos de la muestra (51%), representan una magnitud media en cuanto a los cambios de requerimientos. Aproximadamente los otros dos cuartos representan a magnitudes bajas y altas.

Figura 32: Resultados sobre la magnitud en los cambios de requerimientos en los proyectos de la muestra

82


Manejo de expectativas en los proyectos informáticos Universidad de Buenos Aires - Facultad de Ingeniería

Ariel D. Schapiro Padrón 80.885

5.2.4. Resultados del Proyecto ¿Qué grado de éxito se logró en el proyecto? La siguiente figura muestra que sólo el 36% de los casos relevados registra un resultado exitoso en su proyecto, mientras que la mayoría de los casos (52%) registra una desviación manejada del proyecto.

Figura 33: Resultados sobre el grado de éxito logrado en el proyecto

83


Manejo de expectativas en los proyectos informáticos Universidad de Buenos Aires - Facultad de Ingeniería

Ariel D. Schapiro Padrón 80.885

¿En que consistieron los desvíos? La siguiente figura muestra la distribución de los desvíos en los proyectos que resultaron desviados: el mayor grupo consiste en el nivel de funcionalidad solicitada (33%) y el plazo de entrega (30%). En cuanto a la dependencia de estas proporciones, cabe destacar que los desvíos en el presupuesto económico pueden ser consecuencia de desvíos en la funcionalidad, el plazo de entrega o los recursos involucrados.

Figura 34: Resultados sobre causales de desvíos en los proyectos de la muestra

84


Manejo de expectativas en los proyectos informáticos Universidad de Buenos Aires - Facultad de Ingeniería

Ariel D. Schapiro Padrón 80.885

Desvíos en el nivel de funcionalidad solicitada La siguiente figura muestra la distribución de los desvíos para los proyectos que terminaron con una mayor funcionalidad que la solicitada: los grupos de 41%-60%, 61%-80% y 81-100% resultaron los más grandes, cada uno con el 24% de los casos.

Figura 35: Resultados en detalle sobre los desvíos en nivel de funcionalidad solicitada

85


Manejo de expectativas en los proyectos informáticos Universidad de Buenos Aires - Facultad de Ingeniería

Ariel D. Schapiro Padrón 80.885

Desvíos en estándares de calidad requeridos La siguiente figura muestra la distribución de los desvíos para los proyectos que resultaron desviados en los estándares de calidad requeridos: los grupos de 61%-80% y 81-100% resultaron los más grandes, cada uno con el 33% de los casos.

Figura 36: Resultados en detalle sobre los desvíos en estándares de calidad requeridos

86


Manejo de expectativas en los proyectos informáticos Universidad de Buenos Aires - Facultad de Ingeniería

Ariel D. Schapiro Padrón 80.885

Desvíos en presupuesto económico La siguiente figura muestra la distribución de los desvíos para los proyectos que resultaron desviados en el presupuesto económico: el grupo más grande (41%) obtuvo desvíos de entre 41% y 60% en sus presupuestos. El grupo que le sigue es el de desvíos menores al 20% con el 35% de los casos.

Figura 37: Resultados en detalle sobre los desvíos en presupuesto económico

87


Manejo de expectativas en los proyectos informáticos Universidad de Buenos Aires - Facultad de Ingeniería

Ariel D. Schapiro Padrón 80.885

Desvíos en plazo de entrega La siguiente figura muestra la distribución de los desvíos para los proyectos que resultaron desviados en el plazo de entrega: el grupo más grande (46%) tuvo desvíos de entre 41% y 60% en su plazo de entrega. El grupo que le sigue es el de desvíos menores al 20% con el 38% de los casos.

Figura 38: Resultados en detalle sobre los desvíos en los plazos de entrega

88


Manejo de expectativas en los proyectos informáticos Universidad de Buenos Aires - Facultad de Ingeniería

Ariel D. Schapiro Padrón 80.885

Desvíos en recursos La siguiente figura muestra la distribución de los desvíos para los proyectos que resultaron desviados en el uso de sus recursos: el grupo más grande (56%) tuvo desvíos de entre 41% y 60% en la utilización de sus recursos.

Figura 39: Resultados en detalle sobre los desvíos en los recursos consumidos a lo largo del proyecto

89


Manejo de expectativas en los proyectos informáticos Universidad de Buenos Aires - Facultad de Ingeniería

Ariel D. Schapiro Padrón 80.885

¿En qué medida considera que las expectativas del cliente fueron cumplidas? La siguiente figura muestra que las expectativas de los clientes fueron cumplidas en gran medida para casi la mitad de los casos (49%). Solamente el 5% de los casos registra que las expectativas fueron cumplidas en baja medida.

Figura 40: Resultados sobre el cumplimiento de las expectativas del cliente

90


Manejo de expectativas en los proyectos informáticos Universidad de Buenos Aires - Facultad de Ingeniería

Ariel D. Schapiro Padrón 80.885

¿Cuántos recomienzos hubo en el proyecto? La siguiente figura muestra que la amplia mayoría de los casos (76%) no registró un recomienzo en el proyecto, mientras que el 18% de los casos registro un recomienzo.

Figura 41: Resultados sobre la cantidad de recomienzos que hubo en el proyecto

91


Manejo de expectativas en los proyectos informáticos Universidad de Buenos Aires - Facultad de Ingeniería

Ariel D. Schapiro Padrón 80.885

5.2.5. Detalles de metodología ¿Qué metodología de desarrollo de software se siguió? La siguiente figura muestra que la metodología de software más elegida fue la evolutiva, con el 23% de los casos. Sin embargo las proporciones de ésta junto con las de XP, cascada y Scrum resultaron muy similares (entre 23% y 19%). Nota: Cabe destacar que la audiencia tenía la posibilidad de contestar con más de una metodología de desarrollo de software.

Figura 42: Resultados sobre la metodología de software que se siguió en el proyecto relevado

92


Manejo de expectativas en los proyectos informáticos Universidad de Buenos Aires - Facultad de Ingeniería

Ariel D. Schapiro Padrón 80.885

5.2.6. Opinión: metodología y factores de éxito/fracaso ¿En qué grado Ud. opina que las entregas parciales favorecen al resultado de la entrega? La siguiente figura muestra que la opinión de la audiencia con respecto a las entregas parciales, refleja que en su mayoría (56%) su impacto es muy alto.

Figura 43: Resultados sobre la opinión acerca del papel de las entregas parciales en el resultado favorable de la entrega total

93


Manejo de expectativas en los proyectos informáticos Universidad de Buenos Aires - Facultad de Ingeniería

Ariel D. Schapiro Padrón 80.885

¿Cuáles de los siguientes Ud. opina que son los 3 factores más importantes en el éxito de un proyecto? La siguiente figura muestra que la opinión de la audiencia con respecto a los 3 factores de mayor importancia en el éxito de un proyecto refleja que la planeación adecuada es el factor más valorado.

Figura 44: Resultados sobre la opinión acerca de los 3 factores de mayor importancia en el éxito de un proyecto

94


Manejo de expectativas en los proyectos informáticos Universidad de Buenos Aires - Facultad de Ingeniería

Ariel D. Schapiro Padrón 80.885

¿Cuáles de los siguientes Ud. opina que son los 3 factores más importantes en el desvío desfavorable de un proyecto? La siguiente figura muestra que la opinión de la audiencia con respecto a los 3 factores de mayor importancia en el desvío de un proyecto refleja que los cambios frecuentes en los requerimientos y especificaciones suele ser el factor más valorado.

Figura 45: Resultados sobre la opinión acerca de los 3 factores de mayor importancia en el desvío de un proyecto

95


Manejo de expectativas en los proyectos informáticos Universidad de Buenos Aires - Facultad de Ingeniería

Ariel D. Schapiro Padrón 80.885

¿Cuáles de los siguientes Ud. opina que son los 3 factores más importantes que causan que un proyecto se cancele? La siguiente figura muestra que la opinión de la audiencia con respecto a los 3 factores de mayor importancia en la cancelación de un proyecto refleja que los usuarios poco involucrados (18%) junto con los requerimientos o especificaciones cambiantes (17%) suelen ser los factores más valorados.

Figura 46: Resultados sobre la opinión acerca de los 3 factores de mayor importancia en la cancelación de un proyecto

96


Manejo de expectativas en los proyectos informáticos Universidad de Buenos Aires - Facultad de Ingeniería

Ariel D. Schapiro Padrón 80.885

Con respecto a 5 años atrás, su opinión acerca de la cantidad de proyectos fallidos es que… La siguiente figura muestra que la opinión de la audiencia con respecto a la cantidad de proyectos fallidos con respecto a 5 años atrás, es en su mayoría (54%) que esta cantidad disminuyó.

Figura 47: Resultados sobre la opinión acerca de la cantidad de proyectos fallidos con respecto a 5 años atrás

97


Manejo de expectativas en los proyectos informáticos Universidad de Buenos Aires - Facultad de Ingeniería

Ariel D. Schapiro Padrón 80.885

5.3. Otros estudios estadísticos y tendencias A continuación se plantean otros estudios estadísticos y tendencias basados en la información recabada de las preguntas de la encuesta:

5.3.1. Grado de éxito en los proyectos en base al manejo de expectativas En la siguiente figura podemos ver como el grado de éxito en los proyectos es sensiblemente mayor (casi 3 veces) en los casos donde se manejaron las expectativas que donde no se hizo esto. Además de eso, los casos de fracasos o desviaciones negativas se produjeron solo en donde no se manejaron las expectativas.

Figura 48: Resultados sobre el grado de éxito en los proyectos en base al manejo de expectativas

98


Manejo de expectativas en los proyectos informáticos Universidad de Buenos Aires - Facultad de Ingeniería

Ariel D. Schapiro Padrón 80.885

5.3.2. Grado de éxito en los proyectos en base al plazo de entrega en meses La siguiente figura nos muestra como los proyectos exitosos tienen su mayor repetición en los proyectos que duran de 3 a 5 meses y luego con el aumento en la duración de los mismos, los resultados exitosos disminuyen.

Figura 49: Resultados sobre el grado de éxito en los proyectos en base al plazo de entrega en meses

99


Manejo de expectativas en los proyectos informáticos Universidad de Buenos Aires - Facultad de Ingeniería

Ariel D. Schapiro Padrón 80.885

5.3.3. Grado de éxito en los proyectos en base a la frecuencia de comunicación del avance con el cliente Las siguientes figuras nos muestran como varía el grado de éxito con respecto a la frecuencia de comunicación del avance del proyecto con el cliente. La frecuencia con mayor proporción de éxito es la diaria (75%). Cabe destacar como esta proporción va disminuyendo acorde crece la frecuencia de comunicación de avance con el cliente: en los casos de comunicaciones semanales el grado de éxito es del 37%, luego en los casos con comunicaciones quincenales éste es del 9% y finalmente no se registraron casos exitosos con comunicaciones mensuales.

Figura 50: Resultados sobre el grado de éxito en los proyectos en base a la frecuencia de comunicación del avance con el cliente (porcentual)

100


Manejo de expectativas en los proyectos informáticos Universidad de Buenos Aires - Facultad de Ingeniería

Ariel D. Schapiro Padrón 80.885

Figura 51: Resultados sobre el grado de éxito en los proyectos en base a la frecuencia de comunicación del avance con el cliente

101


Manejo de expectativas en los proyectos informáticos Universidad de Buenos Aires - Facultad de Ingeniería

Ariel D. Schapiro Padrón 80.885

5.3.4. Grado de éxito en los proyectos en base a la medición por parte del cliente de lo que se le estaba entregando a lo largo del proyecto La siguiente figura pone en evidencia el papel que juega la medición de las percepciones de los clientes con respecto al grado de éxito obtenido finalmente en el proyecto. Ocurre algo similar con respecto al grado de éxito según el manejo total de expectativas: la cantidad de proyectos que resultan exitosos donde sí se midió dicha percepción es aproximadamente 3 veces mayor a la cantidad donde esto no ocurrió.

Figura 52: Resultados sobre el grado de éxito en los proyectos en base a la medición por parte del cliente de lo que se le estaba entregando a lo largo del proyecto

102


Manejo de expectativas en los proyectos informáticos Universidad de Buenos Aires - Facultad de Ingeniería

Ariel D. Schapiro Padrón 80.885

5.3.5. Manejo de expectativas en base a la metodología de desarrollo de software Las siguientes figuras exponen el cumplimiento del manejo de expectativas que implementan las distintas metodologías de software. Se puede observar como Scrum es la metodología que en promedio tuvo un cumplimiento del manejo de expectativas sensiblemente más alto que el resto (79%). Mientras que las metodologías de cascada y evolutivo fueron las que menos lo hicieron (6% y 5% respectivamente). Scrum es la única que posee más casos de manejo de expectativas que donde no se manejaron las expectativas.

Figura 53: Resultados sobre el grado de manejo de expectativas en base a las metodologías de desarrollo de software implementadas en el proyecto (porcentual)

103


Manejo de expectativas en los proyectos informáticos Universidad de Buenos Aires - Facultad de Ingeniería

Ariel D. Schapiro Padrón 80.885

Figura 54: Resultados sobre el grado de manejo de expectativas en base a la metodología de desarrollo de software implementadas en el proyecto

104


Manejo de expectativas en los proyectos informáticos Universidad de Buenos Aires - Facultad de Ingeniería

Ariel D. Schapiro Padrón 80.885

5.3.6. Grado de éxito en los proyectos en base a la metodología de desarrollo de software En base a lo expuesto anteriormente sobre la influencia del manejo de expectativas en el grado de éxito de los proyectos y por otro lado la incidencia de la implementación de las distintas metodologías de desarrollo de software en el manejo de expectativas, podríamos inferir que las metodologías influyen indirectamente en este sentido en el grado de éxito en los proyectos. Las siguientes figuras muestran dicha inferencia de las metodologías elegidas sobre el grado de éxito resultante en el proyecto. Los proyectos que implementaron Scrum y/o XP fueron los que tuvieron un mayor grado de éxito.

Figura 55: Resultados sobre el grado de éxito en base a la metodología de desarrollo de software implementadas en el proyecto

105


Manejo de expectativas en los proyectos informáticos Universidad de Buenos Aires - Facultad de Ingeniería

Ariel D. Schapiro Padrón 80.885

Figura 56: Resultados sobre el grado de éxito en base a la metodología de desarrollo de software implementadas en el proyecto (porcentual)

106


Manejo de expectativas en los proyectos informáticos Universidad de Buenos Aires - Facultad de Ingeniería

Ariel D. Schapiro Padrón 80.885

5.3.7. Cumplimiento de las expectativas del cliente en base al grado de éxito del proyecto La siguiente figura expone el cumplimiento del manejo de expectativas que se logró en los proyectos con distintos tipos de grados de éxitos alcanzados. Se puede observar como los proyectos que resultaron exitosos cumplieron en su mayoría en gran medida con las expectativas de los clientes. Cabe destacar que casi el 30% de los casos que obtuvo desviaciones manejadas, cumplió en gran medida las expectativas de los clientes, mientras que el 70% restante la cumplió en mediana medida. Según la definición clásica del Standish Group [The Standish Group, 1994], aquel 30% no sería visto como parte de los proyectos exitosos, sino más bien como parte de los desafiados. Ahora bien, en base a las sugerencias de Mary Poppendieck [Poppendieck, y otros, 2008] acerca de la definición del éxito, podríamos afirmar que aquel 30% que sería clasificado por el Standish Group como “desafiados” y por la presente tesis como “desviados manejadamente”, pudo haber tenido posibilidades de ser catalogado como “exitoso”. En este sentido, restaría entre otros, evaluar los resultados de negocio logrados por aquellos proyectos.

Figura 57: Resultados sobre el cumplimiento de las expectativas del cliente en base al grado de éxito del proyecto

107


Manejo de expectativas en los proyectos informáticos Universidad de Buenos Aires - Facultad de Ingeniería

Ariel D. Schapiro Padrón 80.885

5.4. Diferencias con el Chaos Report Como se explica en el capítulo Niveles de éxito planteados: diferencias entre el CHAOS Report y este estudio, el presente estudio plantea una diferenciación entre desviaciones “manejadas” y “negativas”. Sin embargo, si hacemos un mapeo de los proyectos con desviación manejada o negativa contra los desviados en el CHAOS REPORT en el año 2004, los resultados no difieren mucho entre sí. El grado de proyectos exitosos en el presente registra un 7% más de casos que el del CHAOS REPORT del año 2004. Si consideramos los proyectos que resultaron en desviaciones tanto manejadas como negativas junto con los desviados del CHAOS REPORT, contamos con un 4% de diferencia. Por último, llegamos a estar a un 11% por debajo de los proyectos cancelados del CHAOS REPORT.

Figura 58: Mapeo de los resultados del Chaos Report con respecto a los de la presente Tesis

Estas diferencias no son abundantes pero aún así reflejan cierta mejoría en cuanto al grado de éxito en los proyectos entre los detectados en el 2004 por el CHAOS REPORT y los de la presente Tesis.

108


Manejo de expectativas en los proyectos informáticos Universidad de Buenos Aires - Facultad de Ingeniería

Ariel D. Schapiro Padrón 80.885

6. Conclusiones En base a la información expuesta en las secciones anteriores, plantearemos las conclusiones generales del presente estudio.

6.1. Sobre el papel del manejo de expectativas y su percepción La hipótesis plantea básicamente que el grado de éxito de los proyectos donde se manejan adecuadamente las expectativas es considerablemente mayor que donde esto no ocurre. Como se explica en el capítulo Resultados del Análisis de validez de la hipótesis (prueba de hipótesis), podemos afirmar que los resultados del presente estudio han validado esa hipótesis.

Figura 59: Diagrama de resultados del Análisis de validez de la hipótesis

Esto nos dejaría en un lugar donde podríamos contar con bases empíricas sobre el posicionamiento del manejo de expectativas en los proyectos informáticos y lógicamente la conclusión constaría básicamente de la afirmación de la hipótesis formulada anteriormente. Sin embargo, en base a piezas de información accesorias también contenidas en el mismo relevamiento, encontramos información que nos puede llevar a enriquecer la conclusión recién mencionada. El siguiente gráfico (también contenido en el capítulo Resultados desagregados por pregunta de la encuesta) nos muestra que solo el 7% de los encuestados incluyó el factor de contar

109


Manejo de expectativas en los proyectos informáticos Universidad de Buenos Aires - Facultad de Ingeniería

Ariel D. Schapiro Padrón 80.885

con expectativas realistas como parte de los 3 factores más importantes en el éxito de un proyecto. En este sentido, una planeación adecuada fue tenida en cuenta tres veces más.

Figura 60: Resultados sobre la opinión acerca de los 3 factores de mayor importancia en el éxito de un proyecto

En cuanto a la percepción de la audiencia acerca de los factores que desvían desfavorablemente un proyecto, también podemos observar una posición no privilegiada para el manejo de expectativas (9%).

110


Manejo de expectativas en los proyectos informáticos Universidad de Buenos Aires - Facultad de Ingeniería

Ariel D. Schapiro Padrón 80.885

Figura 61: Resultados sobre la opinión acerca de los 3 factores de mayor importancia en el desvío de un proyecto

Algo parecido ocurre con la percepción por parte de la audiencia de la encuesta acerca de los factores que causan que un proyecto se cancele. Como se observa en el siguiente gráfico, el 12% de la audiencia eligió ubicar a las expectativas irreales como parte de los 3 factores que ayudan a cancelar un proyecto. En este caso este factor se encuentra en cuarto lugar de preferencia:

111


Manejo de expectativas en los proyectos informáticos Universidad de Buenos Aires - Facultad de Ingeniería

Ariel D. Schapiro Padrón 80.885

Figura 62: Resultados sobre la opinión acerca de los 3 factores de mayor importancia en la cancelación de un proyecto

En base a estas últimas piezas de información, podríamos decir que el manejo de expectativas en los proyectos informáticos resulta ser un factor diferenciador en el resultado de los proyectos, sin embargo el manejo de expectativas no es percibido de esta forma. Por el contrario, el hecho de contar con cambios frecuentes en los requerimientos suele ser uno de los factores más temidos por la audiencia a la hora de elegir los factores de cancelación (17%) o desvíos (21%). El 75% de los casos relevados obtuvieron una magnitud en los cambios de requerimientos media o alta y en esos escenarios, los únicos proyectos que fracasaron fueron aquellos donde no se privilegió el manejo de expectativas. Esto habla de un papel del manejo de expectativas que trae beneficios en entornos de requerimientos cambiantes. En este sentido podríamos extraer una conclusión adicional: el foco puesto en intentar evitar o disminuir los cambios de requerimientos no trajo beneficios claros en los proyectos relevados, por el contrario, los proyectos donde se implementaron metodologías que incluyeron a los cambios de requerimientos como una parte natural del desarrollo de los proyectos, han obtenido resultados relativamente sobresalientes. 112


Manejo de expectativas en los proyectos informáticos Universidad de Buenos Aires - Facultad de Ingeniería

Ariel D. Schapiro Padrón 80.885

6.2. Sobre los artefactos que ayudan en el Manejo de Expectativas En el capítulo Artefactos que ayudan en el Manejo de Expectativas, se presentó una serie de herramientas que desde un punto de vista teórico proponen fomentar un adecuado manejo de expectativas, tanto para con el cliente como interno al equipo de desarrollo. Algunas de esas herramientas, como la lista priorizada de requerimientos del producto (“Product Backlog”), las reuniones de planeamiento, el trabajo iterativo, las reuniones de reporte al cliente, la entrega frecuente y las reuniones de retrospectiva del equipo; son prácticas claves de metodologías ágiles como Scrum y XP. En base a esto y a los resultados privilegiados que lograron obtener los proyectos que implementaron dichas metodologías (como se observa en la próxima figura), podríamos afirmar que las herramientas citadas en la sección Artefactos que ayudan en el Manejo de Expectativas, resultan ser útiles a la hora de promover el éxito del proyecto.

Figura 63: Resultados sobre el grado de éxito en base a la metodología de desarrollo de software implementadas en el proyecto

113


Manejo de expectativas en los proyectos informáticos Universidad de Buenos Aires - Facultad de Ingeniería

Ariel D. Schapiro Padrón 80.885

6.3. Sobre la definición de éxito Variabilidad de los objetivos en el tiempo En el capítulo Niveles de éxito planteados: diferencias entre el CHAOS Report y este estudio, se explicó porque a la hora de clasificar el éxito de los proyectos en el presente estudio se usó una escala distinta a la del CHAOS REPORT [The Standish Group, 1994]. La escala implementada por el CHAOS REPORT se basa en el grado de cumplimiento del plazo, presupuesto y funcionalidad planteados al inicio del proyecto. En base al hecho de que los requerimientos, necesidades y entendimientos del problema planteados al inicio del proyecto pueden (y suelen) cambiar a lo largo del mismo es que se especificó otro grado de éxito al que se llamó “desviación manejada” que implica el estado que alcanza un proyecto desviado que termina por cumplir con las metas planteadas en sus desvíos. Impacto en los términos de negocio Por otro lado, en el capítulo Definición del éxito, Mary Poppendieck [Poppendieck, y otros, 2008] sugiere que la definición de éxito establecida por el Standish Group al formular su CHAOS REPORT [The Standish Group, 1994], es errónea puesto que el éxito tiene en realidad que ver con los términos de negocio. Por ejemplo si se trata de un producto comercial, que éste logre una buena porción del mercado o signos interesantes de rentabilidad. Cumplimiento de las expectativas de los clientes En el capítulo Cumplimiento de las expectativas del cliente en base al grado de éxito del proyecto, hemos descripto como casi el 30% de los casos que obtuvo desviaciones manejadas, cumplió en gran medida las expectativas de los clientes. Sin embargo este grupo no sería visto como parte de los proyectos exitosos según el Standish Group, sino más bien como parte de los desafiados. Si nos guiáramos por el contrario por el cumplimiento de las expectativas, este grupo hubiera resultado exitoso. En base a estos factores podríamos sugerir que el criterio de éxito establecido en el CHAOS REPORT [The Standish Group, 1994] resulta incompleto a la hora de definir el grado alcanzado en un proyecto. Es posible que la inclusión de componentes como la variabilidad de los objetivos en el tiempo, el impacto en los términos de negocio y el cumplimiento de las expectativas de los clientes pueda aproximar dicha definición, a un esquema más aplicable a la realidad.

114


Manejo de expectativas en los proyectos informáticos Universidad de Buenos Aires - Facultad de Ingeniería

Ariel D. Schapiro Padrón 80.885

7. Futuras líneas de investigación 7.1. Prácticas implementadas a lo largo del proyecto En el presente trabajo de investigación se llegó hasta un punto en cuanto a las prácticas que implementó la audiencia durante el desarrollo del proyecto: se recaudó información acerca de las metodologías de desarrollo de software usadas, plazos de control de progreso con los clientes, tipos de entregables, relación con el cliente, resultados del proyecto, etc. Al mismo tiempo se plantearon de forma teórica distintas herramientas y prácticas que favorecen en el manejo de expectativas a lo largo del desarrollo de un proyecto de software. En este sentido, lo que no formó parte del presente trabajo que sí puede ser tenido en cuenta en otra investigación sería la corroboración de la implementación de las herramientas y prácticas planteadas en las secciones teóricas de este trabajo. De esta forma se podría llegar a contar con resultados granulares acerca de los efectos concretos de la implementación de herramientas como una específica visión y misión del proyecto, una lista priorizada de requerimientos del producto (“Product Backlog”), reuniones de planeamiento y reporte con el cliente, una clara definición y manejo de riesgos, etc.

115


Manejo de expectativas en los proyectos informáticos Universidad de Buenos Aires - Facultad de Ingeniería

Ariel D. Schapiro Padrón 80.885

7.2. Información que soporte otras definiciones de éxito En base a la conclusión extraída acerca de la definición de éxito en los proyectos informáticos, en una futura línea de investigación empírica, podría incluirse información acerca de una clara definición de métricas de éxito para el proyecto en cuestión, que evolucione con el tiempo a medida que crece el entendimiento de lo que se necesita construir. Estas métricas se usarían para establecer el grado de éxito alcanzado al finalizar el proyecto. Por otro lado, se podría buscar evidencia acerca del grado de cumplimiento del proyecto, en términos del valor agregado al negocio o bien el retorno de la inversión. En base a lo anteriormente dicho, podríamos medir el grado de éxito de un proyecto dado en base a una combinación de los siguientes parámetros: 

Cumplimiento de plazos, costos, funcionalidad, recursos y calidad definidos en un comienzo y luego actualizados a lo largo del proyecto

Cumplimiento del valor agregado del producto/servicio (retorno de la inversión) a los ojos del cliente y/o de otros involucrados

Cumplimiento de otras métricas de éxito definidas en un comienzo y que evolucionan con el tiempo

De esta forma, el éxito de un proyecto podría representarse mediante una métrica más compleja que la escala de 4 valores propuesta en el presente trabajo o la de 3 valores propuesta por el Standish Group.

116


Manejo de expectativas en los proyectos informáticos Universidad de Buenos Aires - Facultad de Ingeniería

Ariel D. Schapiro Padrón 80.885

8. Bibliografía

Baskerville, Richard L. 2005. Business Agility and Information Technology Diffusion. s.l. : Springer, 2005. Bittner, Kurt and Spence, Ian. 2007. Managing iterative software development projects. 2007. Derby, Esther and Larsen, Diana. 2006. Agile Retrospectives: Making Good Teams Great. 2006. Egerland, Jens. 2003. Expectation Management - Key to Project Success. [Online] February 20, 2003. [Citado: Junio 23, 2007.] http://www.pmisvc.com/assets/govt_archive/Feb03%20Presentation.ppt. Fleck, Dan. 2007. Software Leadership. [Online] 2007. cs.gmu.edu/~dfleck/classes/cs421/fall07/slides/techlead.ppt. Fleming, John H. and Asplund, Jim. 2007. Human Sigma: Managing the Employee-Customer Encounter. s.l. : Gallup Press, 2007. Goldsmith, Robin F. 2004. Discovering Real Business Requirements for Software Project. 2004. Hord, Phil. 2005. What the customer really needed. [Online] Abril 11, 2005. http://www.philhord.com/phord/what-the-customer-needed/. InfoQ. 2006. Interview: Jim Johnson of the Standish Group. InfoQ. [Online] August 25, 2006. http://www.infoq.com/articles/Interview-Johnson-Standish-CHAOS. Jiménez, Marco Antonio. 2006. Gerencia de proyectos: una alternativa para generar nuevos negocios. Asociación Colombiana de Ingenieros de Sistemas. [Online] Noviembre 17, 2006. http://www.acis.org.co/index.php?id=864. Leffingwell, Dean and Widrig, Don. 1999. Managing Software Requirements. s.l. : Addison-Wesley, 1999. Manage your human sigma. Fleming, John, Coffman, Curt and Harter, James. 2005. 2005, Harvard Business Review. Morgenstern, Julie. 2004. Making Work Work. s.l. : Simon & Schuster, 2004. 117


Manejo de expectativas en los proyectos informáticos Universidad de Buenos Aires - Facultad de Ingeniería

Ariel D. Schapiro Padrón 80.885

Mutafelija, Boris and Stromberg, Harvey. 2003. Systematic Process Improvement Using Iso 9001: 2000 and CMMI. s.l. : Artech House, 2003. Online, Phil. 2005. [Online] Abril 11, 2005. http://www.philhord.com/phord/what-the-customerneeded/. Poppendieck, Tom and Poppendieck, Mary. 2008. Lean Software Development. [Entrev.] Scott Hanselman. 2008. 2008. Project Cartoon. Project Cartoon. [Online] 2008. http://www.projectcartoon.com/cartoon/7515/new. Schuh, Peter. 2004. Integrating Agile Development In The Real World. s.l. : Charles River Media, 2004. Schwaber, Ken. 2007. The enterprise and Scrum. s.l. : Microsoft Press, 2007. 2007. Software Requirements . hubpages. [Online] 2007. http://hubpages.com/hub/Software_Requirements. 2008. Software that makes software better. The Economist. Marzo 8, 2008, p. 2. Stepanek, George. 2005. Software Project Secrets: Why Software Projects Fail. s.l. : Apress, 2005. The Standish Group. 1999. Chaos: a recipe for success. 1999. —. 1994. The Chaos Report. http://www.standishgroup.com. [Online] 1994. http://www.standishgroup.com/sample_research/PDFpages/chaos1994.pdf.

118


Manejo de expectativas de proy informaticos