guia proyectos informaticos

Guia de Proyectos Informáticos I -1- Septiembre/12- Febrero/13

PROYECTOS INFORMÁTICOS I

CAPITULO I

1 INTRODUCCION

1.1 Definición de Proyecto.Cuando escuchamos el vocablo proyecto nos vienen a la mente diferentes acepciones tales como:

• Trabajo final de carrera,• Conjunto de documentos que conforman la especificación técnica de un bien o servicio a desarrollar.

Una vez construido se le conoce como planos o especificaciones.• Forma de organizar el trabajo, que consiste en planificar el curso de las tareas que se realizarán, con

el objetivo de obtener un bien o servicio determinado, y controlar el seguimiento de esta planificación, para evitar las desviaciones. Aun en el caso de haber desviaciones se deberá adaptar el plan de modo que se alcancen los objetivos propuestos.

La definición de proyecto que da el Project Management Institute (PMI) es: “Un proyecto es un esfuerzo temporal acometido para crear un único servicio o producto. Temporal quiere decir que todo proyecto tiene un comienzo claro y un final claro. Único significa que el producto o servicio es diferente de alguna forma clara de todos los productos o servicios similares.”

Rodríguez J, García J, Lamarca I (2007), “Un proyecto es un conjunto o una secuencia de actividades que desarrolla durante un tiempo un equipo de personas para obtener un resultado”.

Entre las principales características de un proyecto tenemos:

Para un objetivo concreto: normalmente el resultado u objetivo es también un proceso.

Con un principio y un final: no es mas que la temporalidad del proyecto y constituye en el elemento clave, que lo diferencia de otra clase de procesos.

Con recursos limitados: se hace referencia a una serie de costes, directos e indirectos y de oportunidad para la organización.

Por un equipo ad hoc: esta dirigido a un grupo interno o externo de personas que se dedican para su ejecución.

1.2 Proyecto Informático

Rodríguez J, García J, Lamarca I (2007), “Un proyecto informático es una secuencia de actividades que desarrolla durante un tiempo determinado y con unos recursos limitados un equipo de personas, informáticos y no informáticos, para obtener unos resultados sobre la organización y los proceso de trabajo. Una parte sustancia de estas actividad requieren conocimientos y habilidades en las materias de sistemas y tecnologías de la información”.

Son semejantes a los proyectos genéricos, pero tienen algunas peculiaridades entre las que podemos mencionar:

Son replicables: son muy parecidos por los productos en especial los de software, metodologías, debido a que la mayoría son estándar y resuelven determinadas clases de problemas.

Los especialistas son informáticos: profesionales que comparten pensamiento lógico, metodologías, herramientas y lenguajes en la solución de problemas.

Las características de productos : tanto de hardware como de software son la estabilidad, volatilidad, nivel y extensión del servicio; enmarcadas dentro de los cambios tecnológicos que son más rápidos que en otros entornos.


Los campos actuales en los que el informáticos presenta sus proyectos son:

• Desarrollo de aplicaciones a medida

• Construcción de bases de datos

• Adquisición e instalación de infraestructura

• Integración de sistemas

• Implantación de software estándar

• Despliegue de sus entorno de desarrollo

• Migración de aplicaciones

• Instalación de una red WI-FI

• Reingeniería de procesos y circuitos de información.

• Cabe recalcar que la mayoría de proyectos son presentados como proyectos mixtos.

1.3 El proyecto como forma de organizar el trabajo

1.3.1 Diferentes formas de organizar el trabajo.Los seres humanos nos caracterizamos entre otras cosas por que transformamos la realidad que nos rodea de forma drástica, y todo ello con nuestras manos e ingenio. Desde la antigüedad nos dimos cuenta de que para ser más productivos necesitábamos organizarnos ante los objetivos que pretendemos alcanzar, para ello es necesario dos aspectos clave: a) La tecnología a utilizar.b) La planificación y seguimiento, es decir:

- Tener los objetivos claros,- Tener preparada una estrategia a seguir,- Estar organizados,- Informar adecuadamente

En la actualidad las empresas tienen aprendida la lección, o la tienen que aprender, de forma acelerada. Es decir las empresas que se encuentran en un mercado competitivo, saben que los aspectos comentados anteriormente son piezas clave para su éxito.Dado que las empresas se dedican a producir bienes o servicios, es interesante observar que los diferentes tipos de sistemas productivos se adaptan a situaciones complementarias. En la actualidad nos encontramos con tres grandes grupos de sistemas productivos1:

• Los diseñados para la producción en masa. Se caracterizan por estar centrados en procesos específicos de ensamblaje de un producto. En esta situación se aplican las economías de escala, lo que permite la adquisición de maquinaria muy específica, a medida de los procesos. Ejemplos pueden ser la fabricación de coches o electrodomésticos.

• Los diseñados para la producción por lotes. Se caracterizan por ser sistemas flexibles que sirven para la producción de productos similares, pero en cantidades no suficientes como para tener un sistema productivo dedicado. Se debe poder cambiar y recomponer la planta de producción para las diferentes series. Un ejemplo típico es la fabricación de muebles.

• Los diseñados para producir o alcanzar objetivos no repetitivos. Aquí estamos pensando en un producto que se realizará una vez y que para producirlo, habrá que hacer una serie de tareas específicas, que antes no se habían realizado y que posiblemente no se vuelvan a realizar. Se le llama proyecto.

A ésta última situación es a la que le debemos prestar atención, de forma específica nos centraremos en el caso de querer alcanzar un producto informático, tal como una aplicación. Hay que hacer notar que la mayoría de conceptos y técnicas que veremos se pueden aplicar a otro tipo de proyectos, tales como realización de auditorías, selección e instalación de hardware, implantación de sistemas de información y un largo etc. Veremos en detalle, el desarrollo de software que dispone de técnicas específicas para cálculo de

1 A. Shutub en el punto 1.2


esfuerzo, identificación de tareas, etc.

1.3.2 ¿Que es la gestión?Podemos comenzar por ver lo que dice el diccionario de la Real Academia Española:gestión. Acción y efecto de gestionar. ...gestionar. Hacer diligencias conducentes al logro de un negocio o de un deseo cualquiera.Existen funciones de la gestión, que son:• Planificar. Determina que resultados ha de obtener la organización y establecer estrategias adecuadas para

su realización.• Organizar. Especifica como lograr los resultados planificados, asignado las tareas identificadas en la

planificación a los miembros y equipos de la organización para que se alcances dichos objetivos.• Controlar. Comprobar si se están alcanzando los resultados previstos, corrigiendo las desviaciones que se

detecten.• Dirigir. Liderar y motivar a los miembros de la organización, de modo que se alcancen los objetivos

marcados.

1.3.3 ¿Que es la gestión de proyectos?Se trata de articular el método para alcanzar un objetivo único y no repetitivo en un plazo con principio y fin claros, mediante las técnicas que nos proporciona la gestión. Es decir, se trata de un tipo de empresa especifica. En cierto modo todos ejercemos de directores de proyectos, al menos potencialmente, ya que solemos encontrarnos con cometidos que debemos cumplimentar en unos plazos. Desde un punto de vista menos formal, todos hemos tenido que organizar una fiesta de cumpleaños, la decoración de casa en Navidad o preparar unos exámenes. Quizás lo que no hayamos hecho es utilizar las herramientas disponibles para la organización del trabajo.

1.3.4 Fases de un proyecto.Todos los proyectos, que se gestionan como tales, tienen una serie de fases comunes, no tanto porque se realicen tareas iguales, sino porque el objetivo de cada fase con relación al producto a obtener es común a cualquier proyecto. Así tenemos dos grandes fases: Planeación y Ejecución. Estas fases se subdividen en otras menores. Veamos cada una de ellas por separado.

1. Planeación.

El objetivo de toda planeación es la de clarificar el problema a solucionar, definir el producto a obtener, o servicio a proporcionar, estimar los costes económicos en que se va a incurrir, así como los recursos humanos y de cualquier otro tipo que se requieran para alcanzar la meta.En la planeación se suelen distinguir dos grandes subfases: Definición del problema y Definición del plan de desarrollo. Mientras que la primera se centra en clarificar el producto a obtener, la segunda atiende a las necesidades que aparecerán a lo largo del desarrollo, anticipando el curso de las tareas a realizar, la secuencia en que se llevarán a cabo, los recursos y el momento en que serán necesarios.

a) Definición del problema.

El origen de un proyecto suele ser difuso. Normalmente alguien identifica un problema o una necesidad. Este problema-necesidad hace muy interesante el nacimiento de un proyecto, ya que podemos observar como ante el problema que se plantea unos gerentes lo ven como un impedimento para alcanzar sus metas, mientras otros, pensando que el mismo problema también la tienen sus competidores, lo ven como una oportunidad para dar una solución correcta y posicionarse mejor en el mercado.Ya sea visto como problema u oportunidad, lo primero que hay que hacer es obtener una descripción clara de éste. La pregunta clave a responder es: ¿Cuál es el problema, o dónde está la oportunidad? Evidentemente aquí hay que trabajar con los usuarios, directores de empresa y clientes, pues ellos son los que conocen su negocio y será de ellos de quien tendremos que obtener la información para responder a esta pregunta.La definición del problema suele ocupar muy poco tiempo, por esto muchas veces no se le da la importancia central que tiene. Hay que tener en cuenta que todo el proyecto se basará en esta definición y es mejor que quede clara. La definición del problema debe ser revisada por todos los


implicados en el problema: Usuarios, Directores de empresa y clientes.En este punto conviene aclarar la diferencia de roles en los implicados, así:

• Usuario: persona que utilizará el sistema a nivel operativo. Es el que nos da pistas sobre el problema a nivel de funcionamiento. Son responsables de que el sistema funcione de manera eficiente.

• Director de empresa: Los responsables de que el sistema funcione de manera eficaz. Tienen una visión de conjunto, es decir, no solo del sistema, sino que además la interrelación de éste con otros subsistemas de la empresa.

• Cliente: es el que arriesga su dinero en el desarrollo, es decir, el que pagará por el sistema.

Hay que evitar “las soluciones en busca de un problema”, es decir cuando alguien ha visto una aplicación en marcha, o un sistema, y quiere algo similar. Muchas veces se esconde la idea intuitiva de que aquello resolverá un problema o generará una oportunidad. Lo mejor es sacar a flote el problema o la oportunidad y entonces definirlo en términos claros.También es peligrosa la situación en la que los únicos interesados en el problema y su solución son los implicados en el proyecto. Muchas veces los técnicos desean aplicar nuevas técnicas o herramientas y organizan un proyecto entorno a éstas. En todo caso lo que se debe hacer es buscar en la empresa, identificando alguna aplicación que no sea compleja y que sea útil a los objetivos de la misma.Los siguientes puntos nos dan una idea de la forma de pensar, así como las tareas a realizar durante esta fase:

• Estudiar el sistema actual, • Discutir y analizar lo que se desea obtener,• Clarificar las áreas de la empresa que se verán afectadas,• Definir el problema y sus componentes, aclarando: que es fundamental, que es deseable y

que es opcional.• Visualizar el producto o sistema a proporcionar, así como su adaptación a la organización.• Identificar al responsable del proyecto.• Crear una declaración clara de lo que se va a hacer.• Obtener el sí de los implicados: “Sí, tenemos exactamente ese problema”

En todas las fases y en esta de forma especial se debe estimar los costes previsibles del proyecto y sobre todo el coste de la siguiente fase, la planificación.En muchas organizaciones, una vez definido el problema, éste se añade a la lista de los problemas pendientes de resolución. De modo que un comité de dirección selecciona el próximo problema a resolver, o sistema a desarrollar.

b) Planificación del proyecto.

La planificación del proyecto es la fase en la que se deberán identificar todas las cosas necesarias para poder alcanzar el objetivo marcado. En esta fase se han de concretar los tres cimientos sobre los que se apoyará el desarrollo de todo el proyecto, estos son:

• Calidad: viene dadas por las especificaciones.• Coste económico, valorado en el presupuesto.• Duración: asignada en el calendario de trabajo.

Así como en la fase anterior nos centrábamos en identificar el problema, aquí tendremos que identificar diferentes soluciones y los costes asociados a cada una de ellas.Aunque muchos autores separan el análisis de la aplicación de la propia planificación, por entenderse que la primera es una tarea técnica, mientras que la planificación es una tarea de gestión, cronológicamente se han de realizar de forma simultánea, aunque, se debería partir de una especificación seria del problema, antes de planificar las tareas, costes y recursos necesarios para desarrollar la aplicación.Otro asunto es que cada trabajo que se realiza se debe planificar antes de acometerlo. Así antes de realizar el análisis se deberá hacer una planificación de los trabajos asociados a éste, pero


difícilmente se podrá realizar la planificación de todo el proyecto.Las tareas a realizar para planificar el proyecto, las podemos agrupar en:

• Estimar el tamaño de la aplicación a desarrollar.• Estimar el coste en recursos humanos.• Identificar las tareas a realizar.• Asignar recursos a cada tarea.• Crear un calendario de las tareas.• Realizar un estudio económico.• Reunir todo en un documento, Estudio de viabilidad.

Todas estas tareas se suelen realizar de forma secuencial o iterando entre ellas, otro asunto es la secuencia a seguir. En este libro organizaremos una secuencia lógica de modo que los temas enlacen unos con otros. La secuencia que seguiremos es la implícita en la lista anterior, aunque la realidad es más compleja y nos encontraremos ante diferentes secuencias y en procesos iterativos.En otras ingenierías se utiliza la siguiente secuencia:

• Descomposición del trabajo a realizar en tareas.• Asignación de recursos a cada tarea.• Cálculo del esfuerzo necesario• Creación de un calendario• Estudio económico.

2. Ejecución del proyecto.

En esta fase, se trata de llevar a cabo el plan previo. Se verá fuertemente influida por la planificación. Una mala planificación, llevará a una mala ejecución, ya que si se planifica que costará menos tiempo del real, los usuarios presionarán a los desarrolladores, con lo que éstos trabajarán en peores condiciones, del mismo modo, si se planifica un coste inferior, los administradores de la empresa presionarán al personal del proyecto, con lo que estos trabajarán con más estrés.En la ejecución del proyecto se identifican tres subfases: la puesta en marcha, la subfase productiva y la conclusión del proyecto.

a) Puesta en marcha.

Esta fase se caracteriza fundamentalmente porque en ella se ha de organizar el equipo de desarrollo, los mecanismos de comunicación, la asignación de roles y de responsabilidades a cada persona. Tareas fundamentales son:

• Identificar las necesidades de personal, que aunque ya venían de la fase de planificación, habrá que ajustarla a las disponibilidades actuales.

• Establecimiento de la estructura organizativa. • Definir responsabilidades y autoridad. • Organizar el lugar de trabajo. En muchas ocasiones el comienzo de un proyecto tiene tareas

como instalación de equipamientos, acondicionamiento de locales, …• Puesta en funcionamiento del equipo. Cuando las personas que van a trabajar en un proyecto

no se conocen, es oportuno el organizar reuniones más o menos informales para que se conozcan, esto evitará malentendidos y conflictos durante la ejecución del proyecto.

• Divulgación de los estándares de trabajo y sistemas de informes. Al comenzar el proyecto, las personas están más receptivas que cuando se encuentran en un trabajo rutinario o cuando el objetivo se transforma en algo obsesivo. Ésta es una razón de peso para introducir los nuevos métodos de trabajo. Es posible que sea el cliente el que marque los estándares.

b) Fase productiva.

En esta subfase, ya tenemos el proyecto con su calendario etc., las especificaciones claras, los recursos y personas en situación de trabajo. Las personas deben llevar a término cada una de las


tareas que se les ha asignado en el momento que se le haya indicado. En caso de que alguna persona piense que se pueden producir problemas que vayan a incrementar la planificación, deben informar lo antes posible al responsable del proyecto.Por su parte el responsable del proyecto debe:

• Tomar medidas del rendimiento,• Revisar los informes que le llegan de los empleados,• Mantener reuniones para identificar los problemas antes de que aparezcan,• En caso de desviaciones poner en práctica las acciones correctivas necesarias,• Coordinar las tareas,• Motivar y liderar a los empleados,• Recompensar y disciplinar

c) Conclusión del proyecto.

Ésta subfase es la opuesta a la de puesta en marcha. En ésta se trata de primero dar por finalizado el proyecto y entregar el producto, o dejar de producir el servicio encomendado. Ésta suele ser una fase muy alegre, se han alcanzado los objetivos propuestos, pero también algo triste, hay que separarse de los compañeros de trabajo.Las actividades a realizar son las siguientes:

• Hacer entrega definitiva del producto al cliente,• Revisar las desviaciones del proyecto, identificar causas e indicar formas diferentes de

actuación en futuros proyectos.• Reasignar el personal a los nuevos proyectos o reintegrarlos en los departamentos de partida.• Es interesante documentar las relaciones entre los empleados para futuros proyectos.

1.4 Dimensiones de un proyecto

Cliente: ya sea interno o externo, ya que es quien determina y aprueba en último lugar los objetivos, recursos, coste y duración del proyecto, asi como las modificaciones y revisiones del proyecto.

Objetivos: son los resultados que se desea alcanzar y deben estar bien definidos; en proyectos informáticos se definen en términos de entregables(productos, aplicaciones, documentación)

Calidad: corresponde a una dimensión objetiva(conformidad con las normas) y un dimensión subjetiva(satisfacción del cliente y usuario)

Alcance: corresponde a los contenidos detallados y limitaciones o exclusiones en los objetivos del proyecto; es decir poner en claro lo que se va hacer y lo que no se hará.

Coste: valor económico de los recursos humanos y materiales

Tiempo:limite temporal o de duración del proyecto desde su inicio hasta su terminación.

Riesgo:todo riesgo deriva de la incertidumbre de alcanzar los resultados en el tiempo, coste y niveles de calidad acordados.

Equipo: grupo de personas necesarias para el desarrollo del proyecto.

Jefe de proyecto: o gerente del proyecto, es el responsable último del éxito o del fracaso del proyecto.

Usuarios:los que finalmente utilizarán el proceso o sistema que se entregue al término del proyecto.


1.5 Ciclo de vida de un proyecto

1 Aprobación del proyecto: identificar un problema, interpretar o conceptual izar en forma de proyecto, analizar su viabilidad técnica y económica y los riesgos.

2 Definición: Luego de ser aprobado, en esta fase un grupo de trabajo interno o externo se encargará de analizar con más detalle los requerimientos del proyecto y los objetivos que se desean alcanzar y el contexto de la organización y sus sistemas, para proceder a la definición más precisa y su planificación inicial; aquí se realiza la identificación y análisis de los riesgos del proyecto.

3 Planificación: se requiere realizar la lista de tareas que hay que realizar, así como se documenta la organización de los roles y distribución de las cargas de trabajo dentro del equipo de trabajo.

4 Ejecución: es un ejercicio permanente de de preparación de planes más detallados, revisión de los planes elaborados y comprobación de su estado de avance, planificación de trabajos, etc.

5 Cierre: se debe incluir la realización de pruebas de rendimientos y robustez del sistema; así como la utilización por parte de los usuarios y el cumplimiento de los objetivos y estándares definidos al inicio; realizar la entrega de la documentación del proyecto.


CAPITULO II

2 ERRORES CLÁSICOS

2.1 Efectos de los errores en la programación de un desarrollo

“En un software una manzana podrida puede estropear el proyecto completo”

Lo que se muestra es que aun es necesario utilizar alguno de los métodos recomendables, no es suficiente obtener la máxima velocidad de desarrollo. Incluso si se hacen algunas cosas bien, como la utilización de técnicas de programación modernas, aun podemos cometer un error que anule las mejoras en la productividad.

Al pensar en el desarrollo rápido, resulta tentador pensar que todo lo que hay que hacer es identificar las causas iniciales de un desarrollo lento y eliminarlas, y después obtendremos un desarrollo rápido. El problema es que no hay solo unas pocas causas del desarrollo lento, y que al final no es muy útil intentar identificar todos los orígenes del desarrollo lento.

2.2 Relación de errores clásicos

Algunas técnicas de desarrollo ineficientes han sido elegidas con tanta frecuencia, por la gente con resultados tan malos y predecibles que son dignas de ser llamadas “errores clásicos”

Los desarrolladores, directivos y clientes normalmente tienen buenas razones para tomar las decisiones que toman, y la apariencia seductora de los errores clásicos es una de las razones de que esos errores se cometan tan a menudo. Pero debido a que se han cometido muchas veces, sus consecuencias se han hecho fáciles de predecir. Y los errores rara vez producen los resultados que la gente espera.

1. PERSONAS

A continuación aparecen algunos de los errores clásicos relacionados con las personas.

• Motivación débil. Estudio tras estudio ha mostrado que la motivación probablemente tiene mayor efecto sobre la productividad y la calidad que ningún otro factor.

• Personal mediocre. Después de la motivación, la capacidad individual de los miembros del equipo, así como sus relaciones como equipo, probablemente tienen la mayor influencia en la productividad. Contratar apurando el fondo del barril supondrá una amenaza al desarrollo.

• Empleados problemáticos incontrolados. Un fallo al tratar con personal problemático también amenaza la velocidad de desarrollo. Un fallo al tomar una decisión cuando se trata con un empleado problemático es una de las quejas más comunes que tienen los miembros del equipo respecto de sus responsabilidades.

• Hazañas Algunos desarrolladores de software ponen un gran énfasis en la realización de hazañas en los proyectos. Pero lo que hacen tiene más de malo que de bueno. El énfasis en los comportamientos heroicos fomenta correr un riesgo extremo, e impide la cooperación entre los múltiples elementos que contribuyen al proceso de desarrollo del software.

• Añadir más personal a un proyecto retrasado. Este es quizás el más clásico de los errores clásicos. Cuando un proyecto se alarga, añadir más gente puede quitar más productividad a los miembros del equipo existente de la que añaden los nuevos miembros.

• Oficinas repletas y ruidosas. La mayoría de los desarrolladores consideran sus condiciones de trabajo como insatisfactorias. Alrededor del 60 por 100 indican que no tienen suficiente silencio ni privacidad. Los trabajadores que están en oficinas silenciosas y privadas tienden a funcionar


significativamente mejor que aquellos que ocupan cubículos en salas ruidosas y repletas. Los entornos repletos y ruidosos alargan los planes de desarrollo.

• Fricciones entre los clientes y los desarrolladores. El principal efecto de esta fricción es la mala comunicación, y los efectos secundarios de la mala comunicación incluyen el pobre entendimiento de los requerimientos, pobre diseño de la interfaz de usuario y, en el peor caso, el rechazo del cliente a aceptar el producto acabado. Para remediar estas fricciones se consume tiempo y distraen tanto los desarrolladores como a los clientes del trabajo real en el proyecto.

• Expectativas pocos realistas . Una de las causas más comunes de fricciones entre los desarrolladores y sus clientes o los directivos son las expectativas poco realistas. Aunque por sí mismas las expectativas no alargan el plan. Contribuyen a la percepción de que el plan de desarrollo es demasiado largo.

• Falta de un promotor efectivo del proyecto.- sin un promotor ejecutivo efectivo, el resto del personal de alto nivel de la empresa pueden forzar a que se acepten fechas de entrega irreales o hacer cambios que debiliten el proyecto.

• Falta de participación de los invitados.- todos los principales participantes del esfuerzo de desarrollo de software deben implicarse en el proyecto

• La cooperación estrecha solo se produce si han implicado todos los participantes, permitiendo una coordinación precisa del esfuerzo para el desarrollo rápido, que es imposible conseguir sin una buena participación.

• Falta de participación del usuario.- la razón número uno de que los proyectos de Sistemas de Información tuvieran éxito es la implicación del usuario. Los proyectos que no implican al usuario desde el principio corren el riesgo de que no se comprendan los requerimientos del proyecto, y son vulnerables a que se consuma tiempo en prestaciones que más tarde retrasarán el proyecto

• Política antes que desarrollo.- primar la política en vez de los resultados para el desarrollo orientado a la velocidad.

• Ilusiones.- las ilusiones no son optimismo. Las ilusiones al comienzo llevan a grandes explosiones al final. Impiden llevar a cabo una planificación coherente y pueden ser la raíz de más problemas en el software que todas las otras causas combinadas.

2. PROCESO

• Planificación excesivamente optimista.- fijar un plan excesivamente optimista predispone a que el proyecto falle por infravalorar el alcance del proyecto minando la planificación efectiva y reduciendo las actividades criticas para el desarrollo, como el análisis de requerimientos o el diseño.

• Gestión de riesgos insuficiente.- son los llamados riesgos. Como con los errores clásicos, si no ejercemos una gestión activa de los riesgos, con que solo vaya mal una cosa se pasa a tener un proyecto con desarrollo rápido a un proyecto con desarrollo lento. El fallo de no gestionar uno solo de estos riesgos es un error clásico.

• Fallos de los contratados.- los contratados frecuentemente entregan su trabajo tarde, con una calidad inaceptable o que falla al no coincidir con la especificación.

• Si las relaciones con los contratados no se gestionan cuidadosamente, la utilización, la utilización de desarrolladores externos puede ralentizar el proyecto en vez de acelerarlo.

• Planificación Insuficiente.- sino planificamos para conseguir un desarrollo rápido, no podemos esperar obtenerlo.

• Abandono de la planificación bajo presión.- los equipos de desarrollo hacen planes y


rutinariamente los abandonan cuando se tropiezan con un problema en la planificación. El problema no está en el abandono del plan, sino más bien fallar al no crear un plan alternativo, y caer entonces el modo de trabajo de codificar y corregir.

• Pérdida de tiempo en el inicio difuso.- en inicio difuso es el tiempo que transcurre antes de comience el proyecto; este proyecto normalmente se pierde en el proceso de aprobar y hacer el presupuesto.

• Escatimar en las actividades iniciales.- los proyectos normalmente escatiman en sus actividades iniciales tendrán que hacer ese trabajo en otro momento, con un coste de 10 a 100 veces superior a haberlo hecho bien inicialmente.

• Diseño inadecuado.- un caso especial de escatimar las actividades iniciales es el diseño inadecuado. El énfasis en el diseño está más orientado a la conveniencia que a la calidad, por lo que se necesitara varios ciclos de diseño antes de poder finalizar completamente el sistema.

• Escatimar el control de calidad.- en los proyectos que se hacen con prisa se suelen cortar por lo sano, eliminando las revisiones del diseño y del código, eliminado la planificación de las pruebas y realizando solo pruebas superficiales. Acortar en un día las actividades de control de calidad al comienzo del proyecto probablemente supondrá de 3 a 10 días de actividades finales.

• Control insuficiente de la Directiva.- antes de encarrilar un proyecto, en primer lugar debemos ser capaces de decir si va por buen camino.

• Convergencia prematura o excesivamente frecuente.- en proyectos hechos con prisa hay que forzar prematuramente la convergencia. Puesto que no es posible forzar la convergencia del producto cuando se desea, algunos proyectos de desarrollo rápido intentan forzar la convergencia media docena de veces o más antes que finalmente se produzca. Los intentos finales de convergencia no benefician al producto. Solo son una pérdida de tiempo y prolongan el plan.

• Omitir tareas necesarias en la estimación.- si la gente no guarda cuidadosamente datos de proyectos anteriores, olvida las tareas menos visibles pero son tareas que se han de añadir. El esfuerzo omitido suele aumentar el plan de desarrollo en un 20 a 30 por 100.

• Planificar ponerse al día más adelante.- otro tipo de error en la reestimación de debe a cambios en el producto. Si el producto que estamos construyendo cambia, la cantidad de tiempo necesaria para construirlo cambia también.

• El crecimiento de las nuevas prestaciones.- sin ajustar el plan garantiza que no se alcanzará la fecha de entrega.

3. PRODUCTO

• Programación a destajo.- algunas organizaciones creen que la codificación rápida, libre, tal como salga, es el camino al desarrollo rápido. Piensan que si los desarrolladores están lo suficientemente motivados pueden solventar cualquier obstáculo.

• Exceso de requerimientos.- algunos proyectos tiene más requerimientos de los que necesitan, desde el mismo inicio. La

eficiencia se fija como requisito más a menudo de lo necesario, y puede generar una planificación de software innecesariamente larga.

• Cambio de las Prestaciones.- los proyectos sufren como media sobre un 25 por 100 de cambios en los requerimientos a lo largo de su vida

• Desarrolladores meticulosos.- el esfuerzo requerido para diseñar, implementar, probar, documentar o mantener estas prestaciones innecesarias alargan el plan.

• Tiras y aflojas en la negociación.- cuando un directivo aprueba un retraso en el plan de un proyecto


que progresa más lento de lo esperado, y entonces añade tareas completamente nuevas después de un cambio se produce una situación curiosa.

• Desarrollo orientado a la investigación.- si el proyecto fuerza los límites de la informática porque necesita la creación de nuevos algoritmos o de nuevas técnicas de computación, no estamos desarrollando en software, estamos investigando en software. Los planes de desarrollo de software son razonablemente predecibles; los planes de investigación sobre software ni siquiera son predecibles teóricamente.

4. TECNOLOGÍA

• Síndrome de la panacea.-cuando el equipo de proyecto se aferra solo a una nueva técnica, una nueva tecnología o un proceso rígido y espera resolver con ello sus problemas de planificación esta inevitablemente equivocado.

• Sobreestimación de las ventajas del empleo.- aprender a utilizar nuevas técnicas para aprovecharlas al máximo lleva su tiempo. Las técnicas

también suponen nuevos riesgos, que solo descubriremos usándolas.

• Un caso especial de sobrestimaciones de las mejoras se produce cuando se reutiliza código de proyectos anteriores. Este tipo de reutilización puede ser una técnica muy efectiva, pero el tiempo que se gana no es tan grande como se espera.

• Cambiar de herramienta a mitad del proyecto.- cuando estamos a la mitad de un proyecto,, la curva de aprendizaje, rehacer el trabajo y los inevitables errores cometidos con una herramienta totalmente nueva, normalmente anulan cualquier posible beneficio.

• Falta del control automático del código fuente.- un fallo en la utilización del control automático del código fuente expone a los proyectos a riesgos innecesarios. Sin él, si dos desarrolladores están trabajando en la misma parte del programa deben coordinar su trabajo manualmente.


CAPITULO III

7. PLANIFICACIÓN DE PROYECTOS INFORMÁTICOS

7.1 Planificación excesivamente optimista

“Todos los problemas significativos se vuelven urgentes.” Gene Bylinsky 1967

“Hay más proyectos de software que han salido mal por falta de tiempo que por todas las otras razones combinadas.” Fred Brooks 1970

“La presión de la fecha límite es el principal enemigo de la ingeniería del software.” Scott Costello 1984

Causas fundamentales de las planificaciones demasiado optimistas

• Hay un plazo límite externo e inmutable

• Los responsables o clientes se niegan a aceptar un rango de estimación

• Proyecto Subestimado por la directiva, etc.

7.2 Efectos de la planificación excesivamente optimista

• Exactitud de la planificación

La primera razón por la que la planificación optimista no funciona es porque el uso de una planificación excesivamente optimista reduce la exactitud de la planificación.

• Calidad de la planificación del proyecto

Una planificación demasiado optimista disminuye la efectividad de la planificación al suministrar suposiciones erróneas en la fase de planificación.

• Apego al plan

Incluso cuando la planificación está bien echa inicialmente, muchas organizaciones olvidan sus planes y trabajan a su aire, por realizar una planificación excesivamente optimista.

• Reducción del alcance el proyecto

Una planificación demasiado excesivamente optimista puede hacer que se dedique poco tiempo en actividades iniciales de análisis de requerimientos y diseño.

• Dispersión de actividades

Una planificación demasiado optimista puede desviar la atención de los responsables hacia actividades distintas de las que hacen avanzar al proyecto.

• Relaciones con el cliente

A largo plazo la planificación optimista desgasta la relación con el cliente, porque los clientes pierden confianza en los responsables y desarrolladores excesivamente optimistas.

• Convergencia prematura

Cualquier desarrollador de software dirá que no está interesado en crear una versión para entregarla hasta que el producto tenga todas las prestaciones y sea estable.

7.3 Presión excesivamente en la Planificación

La primera reacción de los responsables y de los clientes cuando descubren que


no están cumpliendo una planificación sobre los desarrolladores e insistir en que realicen más horas extras. La presión excesiva en la planificación ocurre aproximadamente en un 75% de los proyectos grandes, y cerca del 100% en todos los proyectos muy grandes, ya que el nivel de tensión aumenta

La planificación excesivamente optimista perjudica la planificación de desarrollo real de muchas formas, pero la presión excesiva en la planificación la perjudica más.

• Calidad: Se ha determinado que alrededor de un 40% de los errores son causa de la tensión, los cuales pudieron ser evitados con una planificación apropiada y no provocando tensión en los desarrolladores. Cuando la presión en la planificación es extrema, se detectan cuatro veces más errores en el producto respecto a productos desarrollados con una presión menos extrema.

También se ha descubierto que la presión excesiva en la planificación es el factor más significativo entre los que contribuyen a la creación de módulos extremadamente costos y propensos a errores

• Azar: Como una planificación excesivamente optimista es imposible de alcanzar con los métodos de desarrollo eficiente normales, los directivos y desarrolladores del proyecto sienten la tentación de apostar al azar en vez de correr riesgos calculados.

En un proyecto de desarrollo rápido, habría que hacer todo lo posible por reducir los riesgos. La presión en la planificación contribuye a una gestión deficiente de los riesgos y a errores que ralentizan el desarrollo

• Motivación: Un poco de presión en la planificación resultante de una planificación ligeramente optimista pero factible puede motivar. Pero en algún momento la planificación optimista cruza el umbral de la credibilidad, y en ese punto la motivación decae.

Alguien que intente motivar forzando la aceptación de la planificación irrealizable, logrará todo lo contrario.

• Creatividad: Muchos aspectos del desarrollo del software requieren ideas creativas. La creatividad requiere pensar mucho y una gran persistencia cuando la solución deseada no aparece inmediatamente. La motivación externa excesiva (estrés) reduce la motivación interna, y a su vez reduce la creatividad.

• Agotamiento: Si abusa de las horas extras en un proyecto, sus desarrolladores, se verán afectados en el próximo proyecto. Los programadores se ocuparán de cosas de poca importancia durante unos meses después de darle un gran empujón al proyecto principal. Si la planificación presiona demasiado a los desarrolladores, puede experimentar este agotamiento.

• Cambio de personal: La planificación excesivamente optimista y la presión resultante en la planificación tienden a causar cambio voluntario del personal, y las personas que dejan el proyecto tienen a ser las más competentes, con las mejores características de rendimiento. Encontrar y formar a sus sustitutos prolongan la planificación.

• Desarrollo rápido a largo plazo: Las horas extras excesivas eliminan el tiempo libre que los desarrolladores invertirían en su desarrollo profesional. Los desarrolladores que no progresan, no aprenden métodos nuevos, y eso perjudica a la capacidad de desarrollo rápido a largo plazo en la organización.

• Relación entre desarrolladores y directivos: La presión en la planificación aumenta las diferencias entre desarrolladores y directivos. Alimenta la tendencia existente entre los desarrolladores de creer que los directivos nos los respetan, no se preocupan por ellos, y no saben lo suficiente sobre el desarrollo del software como para saber cuándo están pidiendo algo que es imposible. Las malas relaciones llevan a bajar la moral, perder la comunicación y otras situaciones enemigas de la productividad.

7.4 Desarrollo orientado al cliente

Métodos orientados al cliente

Los métodos orientados al cliente se pueden dividir en varias categorías.


A continuación se muestran las categorías para alcanzar un desarrollo rápido:

• Planificación: Los métodos orientados al cliente le ayudan a crear la satisfacción del cliente respecto a su proyecto

• Análisis de requerimientos: Los métodos orientados al cliente le ayudan a comprender los requerimientos reales y evitan tener que volver a repetir el trabajo

• Diseño: Los métodos orientados al cliente le ayudan a incorporar la flexibilidad necesaria para responder rápidamente a los cambios solicitados por el cliente.

• Construcción: Los métodos orientados al cliente le ayudan a que el cliente tenga confianza en el progreso del proyecto.

Planificación: Se pueden utilizar varios métodos para incorporar la satisfacción del cliente en su proyecto:

✔ Seleccione un modelo de ciclo de vida apropiado: Ofrézcale a su cliente signos tangibles de progreso

✔ Identifique al cliente: A la persona que debe mantener contenta es a su jefe.

✔ Establezca un método eficiente para interactuar con el cliente: Tratar de mantener la comunicación directamente con el cliente

✔ Cree un proyecto satisfactorio para todos: Utilizar una gestión de proyectos que permita identificar las condiciones para todas las parte implicadas.

✔ Gestión de riesgos: Prestar atención especial a los riesgos relacionados con los clientes en la planificación de gestión de riesgos y el monitoreo de riesgos.

Análisis de Requerimientos: Tiene como objetivo recopilar los requerimientos reales. Los métodos de recopilación de requerimientos orientados al cliente le ayudan a descubrir más sobre los requerimientos reales y a maximizar su comprensión de todos los requerimientos.

Cabe recalcar que cuanto más tiempo dedique a trabajar en los requerimientos reales, perderá menos tiempo trabajando sobre requerimientos extraños, y podrá entregar el software de acuerdo a la planificación.

• La participación del cliente puede ayudar a acelerar la velocidad de desarrollo, pero no es suficiente para mejorar la productividad.

Un estudio realizado (Vosburgh et al., 1984) ha encontrado que la productividad aumenta con la alta participación de los clientes, pero también ha encontrado que la productividad disminuye cuando los clientes escriben la especificación.

Algunos métodos que se emplean para que los clientes participen en la recopilación de requerimientos:

• Utilización de métodos de recopilación de requerimientos que ayuden a los clientes a representar qué es lo que quieren (prototipado de interfaz de usuario).

• Creación de distintos grupos que expongan los distintos puntos de vista sobre lo que quiere el cliente.

• Grabación en video de los clientes utilizando el software.

• Realización de encuestas sobre la satisfacción del cliente.

Diseño:

Lo más productivo para mantener una orientación al cliente es:

• Utilizar métodos de diseño que permitan a los clientes cambiar de opinión ocasionalmente (flexibilidad).

La pérdida de la flexibilidad puede ser grave en el desarrollo de software.

Construcción :


Luego de haber pasado por los requerimientos y el diseño, los clientes estarán involucrados totalmente en el desarrollo. Dentro de los métodos orientados al cliente tenemos:

• Empleo de métodos de implementación que creen un código legible y modificable (responder a cambios solicitados por el cliente).

• Utilizar métodos de monitorización del progreso, que permitan informar al cliente sobre el progreso.

• Seleccionar un modelo de ciclo de vida que ofrezca al cliente signos de progreso tangibles (permite realizar entregas frecuentes de software operativo a los clientes).

Gestión de las expectativas del cliente

La gran mayoría de problemas en el desarrollo de software, se derivan de la falta de cumplimento de expectativas no realistas.

Una de las expectativas poco realistas puede surgir en la planificación, puesto que los clientes establecen la planificación antes de conocer en su totalidad los requerimientos.

• El comprender las expectativas del cliente pueden ahorrar muchas fricciones y trabajo extra.

• Los clientes no entienden lo que supone el desarrollo de software.

• Nuestro trabajo, como desarrolladores de software, es educar a nuestros clientes para que comprendan mejor el desarrollo de software, lo que hará que se mantengan en sus expectativas.

• Cuando los clientes son educados, la productividad aumenta (Jones, 1991)

Para concluir, cabe recalcar que la gente que aumenta sus expectativas daña su credibilidad y deteriora sus relaciones con los clientes. Por lo tanto nuestro trabajo, como desarrolladores, es establecer expectativas realistas.


CAPITULO IV

8. GESTION DE RIESGOS Para una eficiente estimación de riesgos, es necesario realizar:

• La identificación de riesgos: que consiste en generar una lista de riesgos capaces de romper la planificación del proyecto.

• El análisis del riesgo: permite medir la probabilidad y el impacto de cada riesgo y los niveles de riesgo de los métodos alternativos.

• La asignación de prioridades a los riesgos: generar un listado de riesgos ordenados por su impacto.

8.1 Identificación de riesgos

Los principales riesgos consiste en cometer uno de los errores clásicos, y fallar en la gestión activa de los riesgos.

Una de las formas más fáciles de identificar riesgos es comprobar su proyecto frente a una lista de riesgos de la planificación.

Los riesgos mas comunes en la planificación:

◦ Cambio de requisitos

◦ Meticulosidad en requerimientos o desarrolladores

◦ Escatimar en la calidad

◦ Planificaciones optimistas

◦ Diseño inadecuado

◦ Síndrome de la panacea

◦ Personal mediocre

8.2 Análisis de riesgos

Analizar cada riesgo para determinar su impacto. Elegir entre varias alternativas de desarrollo, o para gestionar los riesgos asociados con una alternativa que ya haya elegido. La estimación de riesgos de planificación suele ser más sencilla.

• Exposición a los riesgos (ER)

La exposición a riesgos es igual a la probabilidad de pérdida no esperada multiplicada por la magnitud de la pérdida.

Se puede expresar las pérdidas en semanas o meses para su fácil comparación.

Tabla de estimación de riesgosRiesgo Probabilidad

de pérdidaMagnitud de la pérdida (S)

Exposición a riesgo (S)

Planificación demasiado optimista 50% 5 2,5Añadir un requisito para la actualización automática desde mainframe

5% 20 1,0

Añadir nuevas características desde marketing (sin conocer las características específicas)

35% 8 2,8

Interfaz del subsistema de formato de gráficos inestable

25% 4 1,0

Diseño inadecuado (hay que volver a diseñar) 15% 15 2,25La aprobación del proyecto tarda más de lo esperado

25% 4 1,0

Los recursos no están disponibles en su momento

10% 2 0,2


Los informes de estado a nivel de directiva necesitan más tiempo del previsto

10% 1 0,1

El personal contratado se retrasa en la entrega del subsistema encargado de formatear los gráficos

10-20% 4 0,4 – 0,8

Las nuevas herramientas de programación no producen ahorro prometido

30% 5 1,5

• Estimación de la magnitud de la pérdida

Muchas veces es más fácil estimar la magnitud de la pérdida que la probabilidad. En los casos que la magnitud no es fácil de estimar directamente, se puede dividir la pérdida en pérdidas más pequeñas, estimarlas, y combinar las pérdidas pequeñas en una estimación más exacta.

• Estimación de la probabilidad de pérdida

✔ Disponer de la persona que esté mas familiarizada con el sistema para que estime la probabilidad de cada riesgo, y luego realizar una revisión de la estimación.

✔ Usar técnicas de consenso en grupo. Se discute o escribe el origen de cada estimación, especialmente en la que haya mayores diferencias. Continuar con el procesos hasta hace converger las estimaciones.

✔ Realizar analogías con apuestas.

✔ Utilice la “Calibración mediante objetivos”. Primero cada persona elige el nivel de riesgo entre una serie de frases como muy probable, bastante probable, probable, improbable, muy improbable. Después convertirlas en estimaciones cuantitativas.

• Retraso total del proyecto y margen de retraso

Como solo estamos hablando de riesgos en la planificación, se pueden sumar todas las exposiciones a riesgos y obtener el retraso total del proyecto.

La magnitud del retraso total esperado permite intuir el nivel global de riesgo del proyecto.

En un proyecto se podría cambiar la planificación para controlar el retraso esperado. Se añade a la planificación del proyecto un margen de retraso. Otra manera sería crear una planificación con signas más o menos para cada riesgo, y ajustar la planificación cuando ocurra un riesgo.

8.3 Priorización de riesgos

Priorizar los riesgos para saber donde centrar los esfuerzos para la gestión de riesgos. Ordene los riesgos según la exposición a riesgos en la tabla de estimación de riesgos.

Tabla de estimación de riesgosRiesgo Probabilidad

de pérdidaMagnitud de la pérdida (S)

Exposición a riesgo (S)

Añadir nuevas características desde marketing (sin conocer las características específicas)

35% 8 2,8

Planificación demasiado optimista 50% 5 2,5Diseño inadecuado (hay que volver a diseñar) 15% 15 2,25Las nuevas herramientas de programación no producen ahorro prometido

30% 5 1,5

Añadir un requisito para la actualización automática desde mainframe

5% 20 1,0

Interfaz del subsistema de formato de gráficos inestable

25% 4 1,0

La aprobación del proyecto tarda más de lo esperado

25% 4 1,0

El personal contratado se retrasa en la entrega del subsistema encargado de formatear los gráficos

10-20% 4 0,4 – 0,8

Los recursos no están disponibles en su momento 10% 2 0,2Los informes de estado a nivel de directiva necesitan más tiempo del previsto

10% 1 0,1


Esta forma de ordenación genera una lista de riesgos ordenada aproximadamente por prioridades. Si se consigue controlar los primeros se consigue mayor reducción en el retraso que controlando los últimos.

Tener en cuenta que esta tabla está ordenada aproximadamente.

La exactitud de los números de la exposición de riesgos y el orden de las prioridades depende de la precisión de las estimaciones de la probabilidad y de la magnitud del riesgo.

La priorización de riesgos es un proceso crítico en el que hay que tener cuidado de no dedicar todo el esfuerzo a la gestión de riesgos en si.

8.4 Control de riesgos

En esta sección se describe los tres aspectos de control de riesgos, planificación de gestión de riesgos, resolución de riesgos y monitorización de riesgos.

1. Planificación de riesgos.

El objetivo de la planificación de la gestión de riesgos es desarrollar un plan que controle cada uno de los riesgos.

Un plan de gestión de riesgos puede ser tan sencillo como un párrafo para cada riesgo también debe contener previsión para la monitorización de riesgos, descartando los riesgos que se han resuelto e identificado los riesgos que aparecen.

2. Resolución de riesgos

La resolución de un riesgo depende mucho del riesgo específico. Los métodos que controlan el riesgo de un diseño inadecuado no se adaptan bien al riesgo de que el equipo sea expulsado de sus oficinas. Riesgos del diseño y lugar de trabajo.

Evite el riesgo. No realice actividades arriesgadas.

Un ejemplo de esto es: En el diseño no tomar todo el trabajo solo las partes que se conoce. Y en lo concerniente al lugar de trabajo convencer a los del grupo para no cambiar el lugar.

Traslado el riesgo de una parte del sistema a otra. A veces lo que es un riesgo en una parte del proyecto no lo es en otra parte del proyecto por lo que se puede trasladar a otra parte.

Planificar bien el proyecto de forma que si ocurre un riesgo, el proyecto no se retrase.

Consiga información acerca del riesgo. Si no conoce el autentico peligro, averiguelo.

Elimine el origen de los riesgos. Si el diseño de una parte del sistema es demaciada arriesgada, cambie la parte del sistema a un proyecto de investigación y elminelo de la versión que esta desarrollando.

Asuma el riesgo. Acepte que el riesgo puede ocurrir, pero no piense demasiado en ello. Si las consecuencias son pequeñas y el esfuerzo que se requiere para evitarlo es mucho, hacer caso omiso puede ser la mejor estrategia.

Comunique el riesgo. Haga saber al personal de la dirección y de marketin y a los clientes las presencias de riesgos y sus consecuencias. Intente suavizar el suceso si llegase a ocurrir.

Controle el riesgo. Acepte que el riesgo puede ocurrir y desarrolle planes de contingencia para controlar el riesgo si no puede resolverlo.

Recuerde el riesgo. Cree una colección de planes de gestión de riesgos que pueda utilizar en proyectos futuros.

Métodos de control de riesgos más habituales en la planificación.

Cambio de prestaciones

Uso de técnicas orientadas al cliente.

Uso de técnicas de descarrilo incremental.

Controle el conjunto de prestaciones.


Diseño para el cambio requerimientos

Superfluos o personal de desarrollo meticuloso

Filtrado de requerimientos.

Desarrollo con ventanas temporales.

Control del conjunto de prestaciones.

Uso de entrega por etapas.

Uso de prototipos de desechables.

Diseño por planificación.

Recorte de la calidad.

Deje tiempo a las actividades del control de calidad y preste atención a las bases del control de calidad.

Planificación demasiado optimista.

Utilice las varias técnicas de estimulación y herramientas de estimulación planificación.

Utilización de negociaciones convenientes.

Diseño para planificación.

Uso de técnicas de desarrollo incremental.

Diseño inadecuado.

Tener tiempo suficiente para una actividad de diseño y planificación explícitos.

Tener inspecciones de diseño.

Síndrome de panacea.

Ser escéptico sobre los problemas de productividad.

Configurar un programa de medidas de software.

Configurar un grupo de herramientas de software.

Desarrollo orientado a la investigación.

No intente investigar y maximizar la velocidad de desarrollo al mismo tiempo.

Utilice un ciclo de vida orientado al riesgo.

Gestione los riesgos con atención.

Personal mediocre.

Personal con talento.

Contratar y planificar los miembros clave del equipo mucho antes de que comience el proyecto.

Preparación.

Definición del equipo.

Problemas con el personal contratado

Pedir referencias.

Estimular la capacidad del personal controlado antes de contratarlo.

Tener buenas relaciones con el personal contratado.

Problemas entre el personal de desarrollo y el cliente

Utilizar las técnicas orientadas al cliente.


3. Monitorización de riesgos

Los riesgos aparecen y desaparecen en el desarrollo de un proyecto por lo que se necesita una monitorización de riesgos para comprobar como progresa el control de un riesgo e identificar como aparecen los nuevos riesgos.

Lista de los 10 riesgos más importantes.

1 Riesgo cambio de prestaciones.

Utilizar técnica de entrega por etapas; explicación de la técnica al personal de marketing y usuarios finales.

2 Diseño inadecuado, se necesita volver a diseñar.

Diseño en marcha, Identificación y selección de revisores expertos.

3 Responsable de pruebas no encontrado.

Oferta de trabajo a un candidato adecuado, y estamos a la espera.

4 Inestabilidad de la Interfaz del subsistema de formato de gráficos.

Tratar ahora el diseño de la interfaz de formato de gráficos; no se ha terminado el diseño.

5 Entrega con retraso del subsistema de formato de gráficos encargado.

Negociar la coordinación de contratados expertos. Petición al contratado de que designe un coordinador oficial; todavía no ha respondido.

6 Retraso en la entrega de las herramientas de desarrollo.

Han llegado 5 de las 7 herramientas. El grupo de adquisición de herramientas Ha informado sobre la necesidad inmediata del resto de las herramientas.

7 Ciclo de revisión de la dirección lento.

En evaluación

8 Ciclo de revisión del cliente lento.

En evaluación.

9 Planificación demasiado optimista.

Se ha terminado a tiempo el primer hito.

10 Añadir el requisitos de la actualización automáticamente desde el mainframe.

Estudio de la viabilidad de la actualización manual. Ver el riesgo de cambio de prestaciones.

11 El responsable de diseño pierde tiempo dando soporte a un proyecto anterior.

El proyecto anterior se ha trasladado a Alaska.

El administrador de proyectos y el jefe de administrador de proyectos deben revisar semanalmente la lista de los 10 riesgos principales.

12 Comprobación intermedias.

Un proyecto acelerado también debería incluir comprobaciones intermedias durante todo el proyecto. Estas comprobaciones se realizan para una mayor efectividad.


CAPITULO V

9. ESTIMACIÓN

9.1 Introducción al proceso de estimación

El proceso para crear una planificación de desarrollo exacto consta de tres pasos:

1. Estimar el tamaño del producto: se necesita estimar el tamaño del software para poder construirlo. Siendo el paso más difícil y es esta la razón por la cual suelen obviarlo.

2. Estimar el esfuerzo: si se tiene la estimación exacta del tamaño es fácil realizar la estimación del esfuerzo.

3. Estimar la planificación: para obtener la aceptación de una estimación de la planificación realista puede ser la parte más difícil del proyecto.

Los pasos mencionados se pueden englobar en un metapaso:

Dar un intervalo de estimación e ir refinando ese intervalo, para aumentar la precisión a medida que avanza el proyecto.

9.2 Estimación del tamaño

La forma de estimación del tamaño del software es utilizar un software de estimación, a partir de la descripción de las prestaciones del programa. Pues estimar el tamaño total del sistema nuevo sumando los tamaños estimados de cada una de las partes.

La medida exacta de los proyectos anteriores es la clave para obtener el éxito a largo plazo, utilizando cualquier tipo de estimación.

Estimación de los puntos de fusión.

Un punto de función es una medida sintética del tamaño del programa, que se suele utilizar en los primeros estados del proyecto. Los puntos de función son más fáciles de determinar a partir de la especificación de los requerimientos que las líneas de código, y proporcionan una medida más exacta sobre el tamaño del programa.

El número de puntos de función en un programa se basa en el número y la complejidad de cada uno de los elementos siguientes:

• Entradas: a través de los cuales un usuario final o cualquier otro programa pueda añadir, borrar o cambiar datos del programa.

• Salidas: que el programa genera para el usuario final o cualquier otro programa.

• Consultas: combinaciones de entrada/salida, en las que cada entrada genera una salida simple e inmediata, las consultas recuperan datos directamente de una base de datos y muestran sólo el formato elemental.

• Archivos lógicos internos: podría constar de un único archivo plano o de una sola tabla en una base de datos relacional.

• Archivos de interfaz externos: archivos controlados por otros programas, con los que el programa va a interactuar.

Multiplicadores de los puntos de la función

Puntos de fusiónCaracterísticas del programa

Complejidad baja

Complejidad media

Complejidad Alta

Número de entradas x3 x4 x6Número de salidas x4 x5 x7Consultas x3 x4 x6Archivos lógicos internos

x7 x10 x15


Archivos de interfaz externos

x5 x7 x10

Ejemplo del cálculo del número de puntos de función

Puntos de fusiónCaracterísticas del programa Complejidad

bajaComplejidad media

Complejidad Alta

Número de entradas 6 x 3 = 18 2 x 4 = 8 3 x 6 =18Número de salidas 7 x 4 = 28 7 x 5 = 35 0 x 7 = 0Consultas 0 x 3 = 0 2 x 4 = 8 4 x 6 = 24Archivos lógicos internos 5 x 7 = 35 2 x 10 = 20 3 x 15 = 45Archivos de interfaz externos 9 x 5 = 45 0 x 7 = 0 2 x 10 = 20Total de puntos de función sin ajustar

304

Multiplicador 1,15Total de puntos de función ajustados

350

Consejos sobre estimaciones

Directrices generales para realizar la estimación del tamaño:

• Evite las estimaciones de improviso: los desarrolladores son atrapados por estimaciones de improviso.

• Reserve tiempo para la estimación, y planifíquela: si esta estimando un proyecto grande, trate la estimación como si fuera un miniproyecto.

• Use datos de proyectos anteriores: la comparación con proyectos similares realizados anteriormente, basándose únicamente en la memoria personal. Este método está asociado con el retraso de la planificación y el incremento del coste.

• Use estimaciones basadas en el desarrollador: cuando los desarrolladores estimadores realizan la estimación y el trabajo, cumplir su propia estimación se refleja positivamente en su estimación y su capacidad de trabajo.

• Estime por consenso: se asigna un tamaño fijo a cada una de las categorías, y luego se suman esos tamaños.

• Estime a un bajo nivel de detalle: se debe basar la estimación en el examen detallado de las actividades del proyecto.

• No omita tareas comunes: la gente no suele omitir las tareas a propósito, pero cuando se tiene que desarrollar un producto en el menor tiempo posible, nadie se entretiene en buscar tareas extras.

• Use herramientas de estimación de software: las herramientas de este tipo pueden generar estimaciones precisas. En grandes proyectos, proporcionan una planificación más precisa y una menor incidencia en los retrasos del coste.

• Use varias técnicas distintas para la estimación y comparación de los resultados: los productores de software comercial tienden a utilizar como mínimo tres herramientas de estimación y a buscar la convergencia o dispersión entre las estimaciones de planificación.

• Cambie de métodos de estimación conforme avanza el proyecto: en los primeros estados del proyecto, será más precisa la estimación con algoritmos o las tablas de consultas.

Estilos de presentación de estimaciones

La forma en que inicialmente se presente la estimación influye enormemente en lo que suceda cuando posteriormente se necesite modificar esa estimación. La estimación de software generalmente conlleva un gran riesgo e incertidumbre, y una buena estimación capta ese riesgo e incertidumbre.

A continuación se muestran las técnicas para presentar la estimación de un plan de desarrollo.


Modificadores más-o-menos.

Utilice este estilo para indicar tanto la cantidad como la tendencia de la incertidumbre de la estimación. Una estimación de 6 meses, + ½ mes, - ½ mes, indica que la estimación es bastante precisa y que hay bastante probabilidad de conseguirla. Una estimación de 6 meses, + 3 meses, - 2 meses, indica que la estimación no es muy precisa y que es menos probable de conseguirla.

Rangos.

Uno de los problemas de la estimación con estilo más o menos es que solo se difunde la parte nominal de la estimación. Se eliminan los factores más o menos, cuyo resultado pierde información significativa. La alternativa es utilizar un intervalo de estimación, si la estimación es de 6 meses, + 3 mese, -1 mes, se podría presentar la estimación como de 5 a 9 meses.

Cuantificación de riesgos

Una extensión de la estimación mas-o-menos consiste en explicar lo que representan los signos más y menos. En vez de decir simplemente <<6 meses, +3 meses, -2 meses >>, se puede añadir información con el formato que se muestra en la siguiente tabla:

Estimación: 6 meses, + 3 meses, - 2 meses

+ 1 mes por el retraso en la entrega del - 1 mes por menos retraso del que se Subsistema de gráficos. esperaba en la contratación de nuevos Desarrolladores.+ 1 mes por las nuevas herramientas de -1 mes por las nuevas herramientas deDesarrollo que no están funcionando desarrollo que funcionaban mejor de lo Como se planificó. que se planificó.

+ 0,5 mes por baja de personal.

+ 0.5 mes por subestimación del tamaño

Casos.

Con este estilo se presenta la estimación para el mejor y peor caso, así como el caso más real. Hay que estar preparado para explicar a los clientes lo que tendría que haber ocurrido para conseguir el “mejor caso” o caer en el “peor caso” ; los clientes desearán tener la información de las dos posibilidades.

Caso EstimaciónMejor caso 1 abrilCaso mas real 30 mayoPeor caso 15 julio

Fechas poco precisas y periodos de tiempo

Si las estimaciones son aproximadas, es mejor usar números poco precisos que números precisos engañosos

Factores de Confianza

Una de las preguntas que la gente se suele hacer sobre su plan de desarrollo es “¿ Qué probabilidad hay de terminar en esta fecha ?”. Si se utiliza un enfoque con factores de confianza, se puede responder a la pregunta proporcionando una estimación como la siguiente

Fecha de entrega Probabilidad de entregar a la fecha planeada

1 de abril 5%1 de mayo 50%1 de junio 95%


9.3 Estimación del esfuerzo

Es necesario estimar el esfuerzo para poder saber cuantas personas hay que incorporar en el proyecto, además teniendo una estimación del esfuerzo se facilita la estimación de la Planificación .A continuación se presentan algunas formas para convertir r la estimación del tamaño en la del esfuerzo.

• Utilización de software de estimación para crear la estimación del es fuerzo a partir de la del tamaño

• Utilización de datos anteriores de la organización para estimar cuanto esfuerzo se realizo en proyectos anteriores del tamaño estimado.

• Utilización de un método algorítmico de aproximación.

9.4 Estimación de la planificación

Es el tercer paso en la estimación de un proyecto de software. Una regla es calcular la planificación a partir de la estimación del esfuerzo utilizando la siguiente ecuación

Planificación en meses= 3,0 x personas -

Métodos alternativos para calcular la planificación del software a partir de la estimación del esfuerzo:

• Utilización de un software de estimación para calcular la planificación, a partir de la estimación del esfuerzo.

• Utilización de datos anteriores de la organización.

• Utilización del paso de la estimación de l a planificación a partir de uno de los enfoques algorítmicos.

Uno de los problemas con los que se encuentra la estimación de la panificación es que generalmente se real iza tan fríamente que se completa asignándole un margen de error

Planificación basada en compromisos

Algunas organizaciones se saltan el paso intermedio que consiste en estimar el esfuerzo, pasando directamente de lo requerimientos a la planificación. Normalmente lo hacen basándose en el compromiso, en donde se conversa con los desarrolladores para realizar mas bien un compromiso de planificación que una estimación. Este método asigna a los desarrolladores la responsabilidad de crear las estimaciones de tamaño y esfuerzo.

Tiene la ventaja de incrementar la implicación de los desarrolladores en la planificación, ti ende aumentar la moral en el periodo inmediato al compromiso y ayuda a que los desarrolladores hagan bastantes horas extras totalmente voluntarias

Método de estimación de primer orden de Jones

• Carpers Jones propone una ecuación derivada del análisis de su base de datos de cientos de proyectos.

• Este es también un modelo empírico de estimación.

• Con la suma total de puntos de función , se puede realizar a partir de ellos un cálculo aproximado de la planificación.

• La ecuación de Jones tiene la forma:

TDEV = #PF n

Donde TDEV = Tiempo de planificación ( meses )

#PF = No. de Puntos de Función

n = Exponente según la tabla siguiente


Clase de software Mejor Caso Media(Nominal) Peor CasoAplicación 0.39 0.42 0.45Gestión 0.41 0.43 0.46Sistemas 0.43 0.45 0.48

Ejemplo: Si #PF = 350 en un proyecto de software de Aplicación:

TDEV = 350 0.42 = 12 meses aprox. Estimación Nominal

Si el equipo de desarrollo fuera sumamente organizado, están motivados, conocen y se apegan a las metodologías de ingeniería para el desarrollo, etc. entonces podría considerar lograr un menor tiempo, si aplica el Mejor Caso:

TDEV = 350 0.39 = 10 meses aprox. Estimación Mejor Caso

Este no es el mejor método de estimación de la planificación, pero ayuda o obtener una aproximación, lo cual es mejor que hacerlo a ojo . Si cree que puede desarrollar un proyecto de software de Aplicación de los mismos 350 puntos de función en 7 meses, tendría que pensarlo muy bien. Como se vio anteriormente la planificación en el mejor de los casos es de 10 meses.

9.5 Refinamiento de las estimaciones

Una pregunta que los directivos y clientes se hacen es:<<Si se le da otra semana para trabajar sobre las estimación, ¿se puede refinar, de forma que contenga menos incertidumbre?>>. Es una pregunta razonable, pero desafortunadamente no es posible actuar de la forma que nos gustaría. La calidad de la estimación del software depende del nivel de refinamiento de la definición del software (Laranjeira, 1990). Cuando más refinada sea la definición, la estimación será de mayor calidad. Esto es lógico, ya que cuanto mejor definido está el sistema, hay menos incertidumbre en la estimación.

La investigación de Laranjeira implica que el trabajo que hay que realizar para refinar la definición del software es el trabajo del propio proyecto software: especificación de requerimientos, diseño del producto y diseño detallado.

Es posible refinar la estimación de un producto a medida que va avanzando, y además sería conveniente hacerlo. El proceso típico que sigue cualquier persona es dejarse forzar a hacer una estimación con valores puntuales y luego responsabilizarse de eso.

Cuando el responsable de un equipo usa este enfoque con valores puntuales, el cliente considerará que el proyecto se ha salido del presupuesto y de lo planificado después de la primera estimación (Cuando aumenta de 100 a135 personas-mes).

Compare esta situación con una en la que el responsable del equipo proporciona la estimación con rangos, los cuales se van estrechando conforme el proyecto avanza. Estas estimaciones contienen una gran cantidad de imprecisión y todos los clientes (excepto los más sofisticados) intentarán reducir los rangos.

La imprecisión no es signo de una mala estimación; es parte de la naturaleza del desarrollo del software, cuando se falla al intentar reconocer la imprecisión, hay signos de una mala estimación.

La aceptación de una estimación puede verse afectada por el número de veces que se haya revisado. Si se expone la historia de la estimación a lo largo del tiempo y se promete proporcionar estimaciones cada vez más refinadas en hitos regulares, se contribuirá a generar un proceso ordenado y respetable.

Ejemplo de estimación con valores puntualesPunto del Proyecto Estimación

(personas-mes)Concepto inicial del Producto 100Concepto del producto aprobado 100Especificación de requerimientos 135Especificación del diseño del Producto 145Especificación del diseño detallado 160


Final 170

Ejemplo de Estimación con Rangos

Puntos del Proyecto Estimación (Personas-mes)

Concepto inicial del producto 25-400Concepto del producto aprobado 50-200Especificación de Requerimientos 90-200Especificación del diseño del Producto 120-180Especificación del diseño detallado 145-180Final 170

Recalibración

Cuando no se cumple con una fecha planificada, hay que ver como recalibrar la planificación. Tenemos estas alternativas:

1. ¿Podemos suplir posteriormente esta semana perdida en la planificación?

2. ¿Añadimos la semana a la planificación total?

3. ¿Multiplicamos la planificación total por la magnitud del retraso?

La propuesta que se suele tomar es la primera. El razonamiento que normalmente se sigue es éste: <<Los requerimientos han tardado más tiempo del que esperábamos, pero ahora que son sólidos; estamos obligados a ahorrar tiempo después. Supliremos el déficit durante la codificación y la prueba.>>

Los errores de la estimación tienden a ser imprecisos de forma sistemática, extendiéndose a toda la planificación, como la presión por parte de la directiva para utilizar hipótesis optimistas. Es poco probable que la planificación completa sea precisa, excepto en la parte con la que se ha tenido una experiencia real.

Con pocas excepciones, la respuesta correcta a un hito fallido es la opción 3. Esta opción tiene mayor sentido analíticamente. También coincide con la experiencia. Si no esta preparado para aumentar la planificación en esa extensión y por regla general las personas no suelen estarlo, entonces se puede retrasar la decisión y obtener más datos controlando la forma de alcanzar el segundo hito.

Evidentemente, cambiar la estimación después de no alcanzar un hito no es la única opción. Se puede cambiar el valor del <<producto>> en el triángulo planificación/producto/coste, o se puede cambiar el valor del <<coste>>. Se puede modificar la especificación para ahorrar tiempo. Se puede gastas más dinero. Lo único que no se puede hacer para seguir con la planificación es hacer la especificación y el coste sean iguales y esperar que el proyecto mejore.

Un <<retraso>> será algo que esté completamente fuera del rango de la estimación y será un fenómeno extraño.


CAPITULO V

10. MOTIVACIÓNLa motivación es indudablemente la mayor influencia individual sobre como trabajan las personas. La mayoría de los estudios de productividad han encontrado que la motivación tiene mayor influencia en la productividad que cualquier otro factor(Boehm, 1981).

10.1 Motivaciones típicas del desarrollador

Personas diferentes se motivan con factores diferentes, y los desarrolladores no se motivan siempre con los mismos factores que las personas en general. La siguiente tabla es una lista ordenada de factores motivacionales para desarrolladores, directivos y personas en general. Es un resumen estadístico, cualquier desarrollador podría coincidir realmente con cualquiera de las otras columnas. Son datos antiguos, algunos factores han cambiado debido a variaciones en las condiciones económicas. Pero lo principal es que la tabla recoge ideas importantes sobre las diferencias entre desarrolladores, sus directivos y las personas en general.

10.2 Cinco factores de motivación más importantes

Trabajar en los cinco factores principales de motivación puede ser de gran ayuda para lograr acercarse más al deseable factor 10 de rendimiento, se trata de crear un ambiente de trabajo en el cual los desarrolladores puedan realizar sus inquietudes. Cuando las personas disfrutan, ellos mismos se comprometerán y responsabilizarán de cumplir los objetivos de trabajo, y si es necesario echar horas extra, lo harán sin mayores inconvenientes.

7. Lograr objetivos

Los desarrolladores de software disfrutan generalmente de su profesión. Por tanto, la mejor motivación para ellos es proporcionarles un entorno de trabajo que les permita hacer lo que más les gusta: desarrollar software.

Un pilar fundamental para que los desarrolladores se encuentren motivados para lograr sus objetivos es hacer que se sientan plenamente partícipes del proyecto, para ello resulta


fundamental que desde el principio se impliquen en las decisiones como lo son la depuración de los objetivos y la planificación de los plazos.

Que los desarrolladores participen en estas actividades hace que los resultados sean sensiblemente más realistas, al fin y al cabo hay que asumir que ellos tendrán en la mayoría de los casos un mejor criterio que los gestores para estimar los esfuerzos que les suponen unas tareas concretas. El efecto psicológico del hecho de participar de esta manera es enormemente beneficioso para su motivación, son ellos quienes se comprometen a lograr los plazos y objetivos con lo cual se sentirán de verdad partícipes y comprometidos con el proyecto, será realmente “su” proyecto y saldrá de ellos hacer todo lo que esté en su poder para cumplir con su “palabra”.

Los objetivos que se plantean deben ser claros y no excesivos en número, está demostrado que cuando se definen claramente los principales objetivos/prioridades de un proyecto y estos no son excesivos en el número, hay muy buenas posibilidades de lograrlos.

2. Posibilidad de desarrollo profesional Posiblemente la faceta más atractiva del desarrollo de software es el gran dinamismo del campo, es decir, hay que aprender y avanzar constantemente para mantenerse al día, no es muy sorprendente que las personas que hayan decidido trabajar en una profesión de estas características pongan peso en la faceta de las posibilidades de desarrollo profesional que les ofrece su trabajo.

Algunas medidas oportunas pueden ser las siguientes:

• Incentivar y remunerar los cursos internos

• Conceder tiempo o jornadas laborales flexibles para asistir a clases o estudiar

• Dedicar presupuesto a la creación de una buena biblioteca técnica

• Asignar los desarrolladores a proyectos que amplíen sus conocimientos técnicos

• Asignar a desarrolladores individuales o a grupos tareas de I+D para fines

concretos (probar una nueva tecnología para la encriptación de datos, selección

de un nuevo entorno de desarrollo, etc.)

• Asignar mentores a cada nuevo desarrollador (lo cual demuestra a ambos que la

compañía se compromete con el desarrollo profesional de sus empleados)

• Evitar excesiva presión de calendarios para que haya un mínimo tiempo que se

pueda dedicar a actividades como las mencionadas anteriormente

• Mantener una buena comunicación para monitorizar la consecución de los

objetivos profesionales de cada desarrollador

3. El contenido del trabajo

Según Richard Hackman y Greg Oldham (Hackman y Oldman 1980), la motivación de los

profesionales procede de tres fuentes principales:

• Que encuentren sentido en el trabajo que están realizando

• Deben sentir responsabilidad sobre los resultados de su trabajo

• Deben conocer los resultados reales de sus actividades

Hackman y Oldham identificaron cinco factores en el trabajo que contribuyen a estas

fuentes de motivación:

• Variedad de conocimientos aplicados. Se refiere a la variedad de conocimiento que han de aplicarse en la ejecución de una tarea. Las personas encuentran más sentido en las tareas que exigen una


variedad de conocimientos más amplia, incluso en tareas que no son muy importantes. Además el trabajo resulta más

divertido de esta manera.

• Identidad de la tarea. Se refiere hasta qué punto la tarea requiere abordar un trabajo por completo. Las personas se responsabilizan más de su trabajo cuando perciben el trabajo como suyo o no se sienten solamente contribuidores a un trabajo en común.

• Importancia de la tarea. Es importante que el trabajo realizado se perciba como la creación de valor, como dicen Hackman y Oldham: los trabajadores que aprietan tuercas en un Boeing perciben su trabajo más importante que los que aprietan tuercas en un escaparate comercial.

• Autonomía. Este aspecto se refiere al grado de control del que se disfruta al realizar el trabajo, la sensación de ser su propio jefe dentro de su área de responsabilidad. Cuanto mayor sea esta sensación más responsabilidad se asume en el trabajo.

• Realimentación del trabajo. La realimentación del trabajo realizado es otro factor de motivación importante ya que aporta información directa de la efectividad de la persona que lo ha realizado. Es importante resaltar que no se trata tanto de los comentarios recibidos de un supervisor, sino lo que el trabajador ve por si mismo, el caso de un desarrollador de software es especialmente claro, ya que los programas creados proveen una realimentación inmediata cuando se ejecutan.

4. Vida privada

El respeto hacia la vida privada, es decir, el impacto de las jornadas laborales y el nivel de estrés sobre ésta tienen un peso muy alto para los desarrolladores. Cabe resaltar especialmente en este punto la diferencia de prioridades entre desarrolladores y jefes de proyectos, la vida privada ocupa el cuarto lugar para los primeros cuando para los últimos ocupa el puesto 15, esto puede provocar ciertos fallos en la gestión de un equipo, por ejemplo: ante una situación continuada de exceso de trabajo un jefe de proyecto puede pensar que los desarrolladores le darán poca importancia porque para él la tiene, pero se confunde al suponer que miden las cosas con su mismo criterio.

Lo mismo ocurre con la responsabilidad, ocupa el primer puesto para un jefe de proyecto, pero es de relativamente poca importancia para un desarrollador, por tanto asignar una alta responsabilidad a un desarrollador le puede parecer al jede de proyecto un “premio” que concede al desarrollador cuando para este supone quizás en un momento determinado más bien un factor de agobio por restarle tiempo de su vida privada.

Otra conclusión interesante de este hecho es que como medio de compensar las jornadas de trabajo en exceso puede ser más interesante conceder vacaciones extra que compensaciones económicas .

5. Oportunidad de supervisión técnica

Tener la oportunidad de realizar una supervisión técnica desde el punto de vista de un desarrollador supone un avance en el tipo de objetivos que debe lograr ya que ofrece la oportunidad de que sus decisiones técnicas trasciendan a un nivel mayor que el de sus responsabilidades personales en sus propias tareas. Sin embargo, para un jefe de proyecto supone casi un paso atrás porque esta acostumbrado a una supervisión de mayor nivel y no tener que preocuparse de los detalles técnicos, una supervisión técnica supone generalmente reducir su ámbito de acción y con ello la importancia de la tarea que percibe.

10.3 Destructores de la moral

Tan importantes como los factores de motivación son los factores que desmotivan. A continuación se explican algunos de los más importantes y de mayor incidencia negativa en la motivación.

Factores de HigenieLos factores de higiene son las condiciones básicas que un trabajador necesita para trabajar


efectivamente. En el mejor caso, los factores de higiene no crean descontento. En el peor caso, su ausencia crea descontento.Los buenos desarrolladores tienden hacia organizaciones que proporcionan un entorno de trabajo en el que se puede ser productivo.A continuación se exponen una serie de factores de higiene para los desarrolladores de software:

Iluminación, calefacción y aire acondicionado apropiados. Espacio adecuado para la mesa de despacho y la estantería. Tranquilidad suficiente para poder concentrarse.Intimidad suficiente para evitar interrupciones no deseadas.Acceso a equipamiento de oficina.Acceso rápido a los suministros de oficina. Acceso no restringido al ordenador.Equipo informático actualizado.Reparación inmediata o casi inmediata de los equipos informáticos averiados.Soporte actualizado de comunicaciones. Herramientas de software pertinentes. Periféricos adecuados.Manuales de referencia y variedad de publicaciones.Libros de consulta auxiliares y ayudas de referencia en línea. Formación mínima.Copias legales del software utilizado.Libertad al establecer el horario de trabajo, tanto general como específicamente.

10.4 Otros destructores de la moral

7. Manipulación de la directiva. Los desarrolladores son susceptibles a ser manipulados por los directivos. Tienden a enfrentarse a temas importantes, y desean que la directiva trate a los desarrolladores de forma sincera.

Cualquier directivo podría tener buenas razones para pedir una fecha límite o una petición similar, sin tener que dar explicaciones. Los directivos de un nivel inferior podrían no entender las razones por las que se ha establecido la fecha límite. Razones que podrían parecer ser evasivas y manipuladoras (y los desarrolladores responden mal a esto).Salvo circunstancias extremas cualquier directivo que pida a los desarrolladores que realicen trabajo extra en un proyecto les debe dar una clara explicación.Los directivos que se esfuerzan por no proporcionar detalles sobre porqué una fecha límite es importante, deberían recordar que sus explicaciones probablemente resulten desalentadoras para los desarrolladores.

7. Presión excesiva de la planificación. Como se vio en el capítulo 3, si la fecha límite es real, podría no ser realista. Una de las formas más rápidas de bajar la motivación a cero es presentar a los desarrolladores una fecha límite imposible. Pocas personas trabajarán duro para alcanzar una fecha límite que saben que es imposible, especialmente si son del tipo T MBPI (aquellos que responden más a la lógica que a las emociones).

8. Falta de apreciación de los esfuerzos de desarrollo. En ocasiones los directivos no ven la cantidad de trabajo que los desarrolladores están realizando, de forma que piensan que no están haciendo mucho y, por tanto, deben obligarlos. En realidad, los desarrolladores están extremadamente automotivados, trabajan duro y muchas horas, y encontrarse acusados de “holgazanear” es muy desalentador. Si se desea que los desarrolladores hagan más de lo que realmente ponen de manifiesto en la oficina, nunca jamás hay que decirles que no están


trabajando duro cuando si lo están haciendo.

9. Participación de directivos sin preparación técnica. Los desarrolladores pueden ser motivados por directivos técnicamente incapaces, siempre que esos directivos reconozcan que no tienen preparación técnica y limiten el control del proyecto a las decisiones de índole no técnica. Intentar meterse en decisiones técnicas que no se comprende, significa convertirse en el blanco de las bromas del equipo de desarrollo, y la mayoría de las personas no pueden ser motivadas por alguien a quien no respetan.

10. No involucrar a los desarrolladores en decisiones que les afectan . No involucrar a los desarrolladores en decisiones que les afectan da la impresión de que el responsable no presta atención al equipo de desarrollo, o que ese directivo no lo respeta lo suficiente como para desear su participación. A continuación se muestran algunos ejemplos clásicos en donde la directiva debe comprometer a los desarrolladores si desea mantener alta su motivación:

Compromiso con las nuevas planificaciones.Compromiso con las nuevas prestaciones o con modificaciones de las mismas.Contratar a nuevos miembros del equipo.Designar a desarrolladores para tareas a corto plazo dentro del proyecto.Diseñar el producto.Tomar decisiones de equilibrio técnico. Cambiar la oficina.Cambio de periféricos.Cambiar las herramientas de programación.Comprometerse a entregar productos que podrían o no haber sido planificados por el equipo.Comprometerse a nuevos proyectos de desarrollo.

A un directivo, podría parecerle necesario realizar el compromiso o el cambio descrito en cada uno de los casos anteriores. Un directivo tiene derecho a hacer eso. También tiene derecho a convertir en nula la motivación de su equipo. Si se desea que el equipo tenga una motivación menor de cero, hay que intentar solicitar las ideas del equipo para encubrir una decisión, después de haberla tomado. Esa combinación de fallos y de manipulación para comprometer a los desarrolladores es especialmente desmotivante. Si se desea mantener alta la motivación, hay que involucrar al equipo de desarrollo en la decisión antes de comprometerse o de aprobar el cambio.

11. Barreras de la productividad. Si el entorno se establece de forma que se frustra el esfuerzo del mejor desarrollador para ser productivo, se puede estar seguro de dañar su motivación. Hay que intentar eliminar las barreras de la productividad, de forma que el equipo pueda centrarse en el trabajo en vez de en salvar las distracciones.

12. Baja calidad. Los desarrolladores derivan parte de su amor propio a partir de los productos que desarrollan. Si desarrollan un producto de gran calidad se sienten bien y al revés. Para que un desarrollador se motive por orgullo de propiedad, hay que ser propietario del trabajo, y hay que estar orgulloso del mismo. Pocos desarrolladores pueden sentir orgullo como respuesta al reto de desarrollar un producto de baja calidad en el menor tiempo posible. Porque la mayoría de los desarrolladores están más motivados por la calidad que por la producción total.

Si un directivo insiste en que los desarrolladores disminuyan la calidad para tener una planificación más corta está reduciendo a la mitad la motivación. Con un producto de baja calidad algunos desarrolladores se sentirán realmente mal, aunque entreguen en las fechas límite y reciban bonificaciones.Si no parece posible que los desarrolladores construyan un producto de alta calidad en el tiempo disponible, hay que dejar que los desarrolladores saquen sus propias conclusiones. Podrían


escoger entre diseñar un producto menos absorbente, o desarrollar un producto de menor calidad en el tiempo establecido. A menos que ellos decidan, no se conseguirá nada nuevo intentando forzarlos a desarrollar un producto de baja calidad. Eso no es motivación, y no funciona.

13. Campañas cargantes de motivación. Con lemas, arengas y otros métodos de motivación es más fácil insultar la inteligencia del desarrollador que motivarlo. Con los desarrolladores de software, funciona mejor un ligero toque.


CAPITULO VII

7. EQUIPOS DE TRABAJO

7.1 Usos de los equipos de trabajo en el softwareUn equipo de trabajo es algo más que un conjunto de personas que desean trabajar juntas para formar un equipo.Un equipo es un número de personas pequeño, con habilidades complementarias, que están comprometidas en un propósito, objetivos de rendimiento y con un enfoque comunes, en el que todos sean responsables ante todos. [Katzenbach y Smith, 1993]El equipo de trabajo en los proyectos software puede entrar en juego en cualquier número de tareas específicas:

Desarrollo y revisión de requisitos del proyecto.Desarrollo de la arquitectura y las directrices del diseño del proyecto. Definición de aspectos del entorno técnico.Desarrollo de los estándares de codificación del proyecto.Coordinar el trabajo en las partes relacionadas del proyecto. Diseño de las partes complicadas del sistema.Revisión del diseño y código de los desarrolladores individuales. Depuración de las partes más complicadas.Prueba de requisitos, diseño y código.Auditoría del avance del proyecto. Mantenimiento del software, una vez construido.

Aunque algunas de las tareas anteriores las podría realizar una sola persona, se pueden beneficiar de la participación de dos o más mentes, lo cual requiere la interacción entre los miembros del proyecto. Si las mentes trabajan juntas, a veces el total puede ser mayor que la suma de las partes. Si hay desacuerdo, puede ser menor. Un “equipo” existe siempre que dos cabezas juntas funcionan mejor que cada una por separado. 7.2 Importancia del equipo de trabajo

Los proyectos pequeños pueden pasar sin estudiar cuestiones sobre equipos de trabajo, pero se beneficiarán de su tratamiento. Los proyectos grandes son esfuerzo de grupos, y las características de los grupos juegan un papel muy importante en el éxito.Variaciones en la productividad del equipo. Los investigadores han encontrado diferencias del orden de 10 a 1 en la productividad individual. Los investigadores también han encontrado diferencias importantes en los niveles de productividad de los equipos. Después de analizar 69 proyectos, Barry Boehm llegó a la conclusión de que los mejores equipos eran al menos 4 veces más productivos que los peores [Boehm, 1981]. De Marco y Lister identificaron diferencias de productividad de 5, 6 a 1 en un estudio de 166 programadores de 18 empresas [De Marco y Lister, 1985].La diferencia en la productividad se mantenía incluso entre grupos de desarrolladores con niveles de experiencia similares en un factor de 3 a 1 y 4 a 1. Valett y Mc Garry informaron de diferencias de 2 a 1 y 3 a 1 en la productividad entre diferentes proyectos del Laboratorio de Ingeniería de Software de la NASA [Valett y Mc Garry, 1989].La conclusión es que entre grupos con diferentes conocimientos y diferentes niveles de experiencia, hay una diferencia de 5 a 1 en la productividad. Entre grupos con similares conocimientos y niveles de experiencia, hay una diferencia en la productividad de 2’5 a 1.Cohesión y rendimiento. Los miembros de los grupos unidos trabajan duro, se divierten con su trabajo, y emplean gran parte de su tiempo centrándose en los objetivos del proyecto.Los participantes en proyectos con malas dinámicas de equipo normalmente no están centrados y están desmoralizados, y emplean gran parte de su tiempo trabajando en objetivos opuestos.Lakhanpal [1993] descubrió que la unión del grupo contribuía más a la productividad que las capacidades o


experiencia individuales de los miembros del proyecto. Lakhanpal apuntó que los directores normalmente escogen a los miembros del proyecto basándose en el nivel de experiencia y en las posibilidades individuales. Lakhanpal sugiere que los directivos deberían designar a los desarrolladores basándose en sus posibilidades para contribuir primero a formar un equipo unido, y solo luego basarse en sus posibilidades individuales.

7.3 Creación de un equipo de alto rendimiento

Los equipos productivos a veces se caracterizan por ser equipos que se han ido formando o equipos con una gran unión. Un equipo con una gran cohesión, un alto rendimiento y que se ha ido moldeando a sí mismo, tiene una serie de características comunes:

Una alta visión u objetivo compartidos. Un sentido de identidad de equipo.Una estructura dirigida a los resultados. Miembros del equipo competentes.Un compromiso con el equipo.Confianza mutua.Interdependencia entre miembros del equipo. Comunicación efectiva.Un sentido de autonomía.Un sentido de enriquecimiento. Tamaño del equipo pequeño. Un alto nivel de disfrute.

En 1989, Larson y La Fasto publicaron un estudio en el que encontraron una consistencia poco usual entre los atributos de los equipos altamente efectivos [Larson y La Fasto, 1989]. 7.4 Fallo de los equipos de trabajo.

• Falta de visión común. Es difícil que los equipos se formen si no comparten una visión común. Las organizaciones impiden a veces la cohesión de los equipos echando abajo sus ideas. Cuando la idea se viene abajo, el equipo también.

• Falta de identidad. Los miembros del equipo podrían estar dispuestos, pero ninguno desempeña la función de soporte, y si nadie cuida del equipo, éste no se puede formar. Cada equipo necesita tener a alguien que se responsabilice de mantener la salud del equipo.Los equipos también pueden tener falta de identidad si uno o más miembros estuvieran trabajando de forma individual en vez de formar parte del equipo. Hay muchos sitios apropiados para personas que trabajan de esta forma, pero su presencia puede ser fatal para la formación de un equipo.

• Falta de reconocimiento. Algunas veces los miembros de un proyecto participan en el equipo de un proyecto en el que ponen su corazón y su alma, y sólo sienten que su esfuerzo no se aprecia. Si una organización desea crear un equipo de gran rendimiento en más de una ocasión, debería asegurarse de reconocer el esfuerzo extraordinario la primera vez de forma apropiada.

• Barreras de la productividad. A Veces los equipos fallan porque creen que no pueden ser productivos. Los equipos no pueden sobrevivir si se les impide realizar su trabajo. Algunos expertos dicen que la primera función de un director de software es eliminar las barreras de la productividad, de forma que los desarrolladores que estén motivados por sí mismos puedan ser productivos [De Marco y Lister, 1987]

• Comunicación ineficiente. Los equipos no se forman si no se pueden comunicar regularmente.

• Falta de confianza. La falta de confianza puede destrozar la moral de un equipo. Una razón por la que normalmente los equipos no se forman dentro de organizaciones


burocráticas es porque las organizaciones (en diversa medida) están basadas en la falta de confianza. La falta de confianza en los empleados suele estar institucionalizada.Los directivos que prestan más atención a los detalles de administración del equipo que a los resultados que consiguen, demuestran una falta de confianza. Los directivos que gestionan poco las actividades de sus equipos, que no les permiten reunirse con sus clientes o que les dan fechas límite falsas, están dando signo de que no confían en ellos.

• Personas problemáticas. Algunos programadores intimidan a sus compañeros utilizando sus planteamientos de diseño. Sus compañeros, en vez de enfrentarse, se conforman con sus demandas de diseño, aumentando su contacto con ellos.Si un responsable tolera a un solo desarrollador al que sus compañeros consideran como un problema, se estará influyendo en la moral de los buenos desarrolladores.Las reclamaciones más intensas y consistentes de los miembros del equipo eran que los responsables del equipo no estaban dispuestos a enfrentarse y resolver los problemas asociados al mal cumplimiento individual por parte de algunos miembros del equipo [Larson y La Fasto, 1989]. Los desarrolladores consideran esta conducta del responsable como un punto negro muy significativo de la directiva, ya que los directivos casi siempre piensan que sus equipos van mejor de lo que creen sus miembros.Los problemas personales suelen ser fáciles de identificar si se sabe dónde buscarlos:

Ocultan su ignorancia en vez de intentar aprender de sus compañeros de equipo.Tienen un deseo excesivo de intimidad. Son reservados.Se quejan de las decisiones de los equipos y continúan revisando antiguas discusiones después de que el equipo haya terminado.Los otros miembros del equipo se ríen o se quejan de la misma persona.Los desarrolladores de software no suelen quejarse directamente, de forma que hay que preguntar si tienen problemas cuando se oye mucho ruido.No se ponen a trabajar en las actividades del equipo.

Enseñar a la persona problemática a trabajar en equipo a veces funciona, pero normalmente es mejor que lo haga el equipo en lugar de que intenten resolverlo los directivos o los responsables. Habría que preparar al equipo sobre cómo manejar al miembro problemático del equipo.Si la preparación no produce resultados rápidamente, no tema echar a una persona que no tiene el menor interés por el equipo. He aquí las tres razones principales:

Es raro ver un problema importante provocado por la falta de experiencia. Es casi siempre cuestión de actitud, y las actitudes son difíciles de cambiar.Cuanto más tiempo se mantiene una persona que causa problemas, esta persona adquirirá más legitimidad a través de contactos casuales con otros grupos y directivos, un crecimiento de la base del código que la persona tiene que mantener, etc.Algunos directivos comentan que nunca se han lamentado de expulsar a alguien. Sólo lamentan no haberlo hecho antes.Un directivo se podría preocupar por la pérdida de la base si se sustituye a un miembro del equipo, pero en un proyecto de cualquier tamaño, se compensará la pérdida de base por la eliminación de una persona que esté trabajando en contra del resto del equipo. Hay que cortar la pérdida, y entonces la moral del resto del equipo mejorará.

7.5 Configuración de equipos a largo plazo.A continuación se muestran algunas de las razones por las que es necesario mantener unidos a los equipos estables.

1. Mayor productividad. Con una estrategia de equipo estable, un grupo se mantiene unido si se crea dentro de un equipo, y se disuelve si no lo hace. Si se mantienen unidos a los equipos productivos, se consiguen grandes ganancias. El efecto total que genera es una


“media superior” del nivel de rendimiento en la organización.2. Costes iniciales menores. Manteniendo juntos a los equipos efectivos, se mantiene parte

de la visión, identidad del equipo, comunicación, confianza, y el depósito de buena voluntad derivados de la finalización de un buen proyecto juntos. También se mantienen los métodos técnicos específicos y el conocimiento de herramientas específicas dentro de un grupo.

3. Menor riesgo de problemas con el personal. Los problemas personales que surgen por personas que no trabajan bien juntas cuestan al proyecto tiempo y dinero. Estos problemas se pueden evitar completamente manteniendo al equipo unido una vez formado.

4. Menos cambios de personal. DeMarco y Lister estiman que el 20 por 100 de la medida del gasto total de la compañía se va en cambios de personal [DeMarco y Lister, 1987].Resulta menos probable que las personas que se han integrado en grupos unidos abandonen la compañía que las que no lo han hecho [Lakhanpal, 1993]. Los desarrolladores han encontrado un entorno en el que se divierten y pueden sentirse productivos.

5. El tema de la inactividad. En ocasiones, las organizaciones se muestran recelosas de mantener a los equipos juntos, ya que tendrían que estar pagando a un equipo que no está haciendo nada hasta que llegue un proyecto apropiado para empezar a trabajar. Ésta es una objeción válida, pero la mayoría de organizaciones, en el fondo, no lo consideran últimamente como un fuerte inconveniente.Las organizaciones que miran exclusivamente el coste del tiempo perdido no tienen en cuenta los costes de reconstrucción de los equipos para cada proyecto nuevo. El coste de construcción de un equipo nuevo incluye el coste de unir al equipo y el de intentar que el equipo funcione conjuntamente.Las organizaciones tienden a no tener en cuenta el dinero que se pierde separando un equipo de alto rendimiento.Algunas organizaciones se preocupan de que si se mantienen a los equipos juntos, no les será posible conseguir equipos para trabajar en ciertos proyectos. Pero otros han descubierto que si dan a la gente la oportunidad de trabajar con las personas que les gusten, trabajarán en cualquier proyecto [DeMarco y Lister, 1987].Finalmente, aún está por ver una organización de desarrollos de software con grandes períodos de inactividad. Por el contrario, la mayoría de los proyectos comienzan tarde porque el personal no está disponible hasta que han finalizado otros proyectos anteriores.Ahora sabemos que entre grupos de personas con características equivalentes, los equipos más productivos son 2 ó 3 veces como los equipos menos productivos. Son una y media o dos veces tan productivos como la media de los equipos. Si se tiene un equipo que se sabe está a la cabeza del rango, hay que ser suficientemente inteligente como para permitirles perder el tiempo, durante hasta un tercio e incluso la mitad de su vida labora, para evitar el riesgo de que el equipo se divida y tenga que sustituirlo simplemente por un equipo medio.

7.6 Modelos de equipoAlgunos de los modelos sólo afectan al modo interno de funcionamiento del equipo, y pueden ser implementados por el responsable técnico o el propio equipo. Otros afectan a la relación entre el equipo y la directiva, y generalmente requerirán la aprobación por parte de la misma.

• EQUIPO DE NEGOCIOS: La estructura de equipo más común es la de un grupo de iguales encabezado por un jefe técnico. Aparte del jefe técnico, todos los miembros del equipo tienen el mismo estatus, diferenciándose en su ámbito de experiencia. El jefe técnico contribuye de forma activa.El jefe es responsable de tomar las decisiones finales sobre cuestiones técnicas.


Desde el exterior, la estructura del equipo de negocios parece una estructura jerárquica típica. Concentra la comunicación con la directiva, identificando una persona como responsable principal del trabajo técnico del proyecto. Permite a cada miembro del equipo trabajar en su área de experiencia, y permite que el propio equipo decida en que va a trabajar cada uno de sus miembros. Funciona bien con grupos pequeños y con grupos que llevan juntos mucho tiempo, y pueden estructurar sus relaciones con el tiempo.Es bastante adaptable para trabajar en todos los tipos de proyectos. Pero generalmente ésta es su debilidad, y en muchos casos hay otra estructura que puede funcionar mejor.

• EQUIPO CON PROGRAMADOR JEFE O QUIRÚRGICO: Esta idea de equipo fue concebida por IBM a finales de los sesenta y popularizada por Fred Brooks [1975, 1995], él se refiere al equipo como quirúrgico, ambos términos son intercambiables. El equipo con programador jefe saca partido del hecho de que algunos desarrolladores son 10 veces más productivos que otros.En el concepto de equipo quirúrgico, la persona más cualificada se identifica con el cirujano, o programador jefe. Esta persona realiza la especificación completa, hace todo el diseño, escribe la mayoría del código de producción, y es el responsable final de prácticamente todas las decisiones del proyecto. El resto de los miembros del equipo son libres para especializarse.Los miembros del equipo se distribuyen alrededor del cirujano con funciones de apoyo, y el equipo con programador jefe saca partido del hecho de que los especialistas tienden a rendir más que los generalistas [Jones, 1991]. Hay un programador de reserva que apoya al cirujano como crítico, ayudante de investigación, contacto técnico con grupos externos y cirujano de reserva. Otra persona gestiona cuestiones administrativas. Aunque el cirujano tiene la última palabra en estas cuestiones, el administrador libera al cirujano de tener que tratarlas de forma diaria. Alguien será el responsable de crear herramientas personalizadas solicitadas por el programador jefe. El equipo está arropado por un “especialista del lenguaje”, que apoya al cirujano respondiendo a preguntas específicas y peculiares sobre el lenguaje de programación que está usando el programador jefe.Varios de los papeles de apoyo sugeridos en la propuesta original de equipo con programador jefe son desempeñados actualmente por personas que no son programadores.Esta estructura sigue siendo adecuada cuando se usa de forma oportunista. Este equipo resulta adecuado para proyectos creativos, en los que tener un cerebro al frente ayudará a proteger la integridad conceptual del sistema. También resulta adecuado para proyectos de ejecución táctica, en los que el programador jefe puede ser una especie de dictador que diseñe los medios más expeditivos para lograr la culminación del proyecto.

• EQUIPO EN LA SOMBRA: Un equipo en la sombra (skunworks) es una parte integral de la herencia del mundo de la ingeniería. Un equipo en la sombra aglutina un grupo de desarrolladores de productos creativos y con talento, les pone en una situación en la que son liberados de las restricciones burocráticas habituales de la organización, y les da libertad para desarrollar e innovar.Los equipos en la sombra son tratados generalmente como cajas negras por sus directivos. La directiva no quiere conocer los detalles sobre como realizan el trabajo, sino que sólo quieren saber lo que están haciendo. Así, el equipo es libre de organizarse como mejor le parezca. Con el paso del tiempo, puede aparecer un líder natural, o el equipo podría designar uno desde el principio.Los proyectos en la sombra tienen la ventaja de crear una sensación de intensa propiedad y compromiso por parte de los desarrolladores implicados. El efecto motivacional puede ser impresionante. Tienen la desventaja de no ofrecer mucha visibilidad del progreso del equipo. Parte de esto puede ser un efecto inevitable de la impredecibilidad inherente en un


trabajo altamente creativo. También se debe a un equilibrio explícito: pérdida de visibilidad a costa de incrementar la motivación. Los equipos en la sombra resultan más adecuados para proyectos exploratorios en los que la creatividad es absolutamente importante. Los equipos en la sombra son raramente la estructura más rápida cuando se necesita resolver un problema claramente definido o cuando se necesita ejecutar un plan bien entendido.

• EQUIPO DE PRESTACIONES: En un equipo de prestaciones, el desarrollo, el control de calidad, la documentación, la gestión del programa y el marketing están organizados con las estructuras jerárquicas tradicionales de responsabilidad.Con esta organización tradicional se encuentran los equipos que toman uno o más miembros de cada uno de los grupos implicados y les asignan la responsabilidad de una parte de la funcionalidad del producto [Mc Carthy, 1995].Los equipos de prestaciones presentan las ventajas de potenciación, facilidad de seguimiento y equilibrio. El equipo puede potenciarse sensiblemente porque incluye representantes de desarrollo, control de calidad, documentación, gestión del programa y marketing; es decir, de todas las partes implicadas. El equipo considerará todos los puntos de vista necesarios en sus decisiones, y por ello en raras ocasiones dará pie a que estas sean cuestionadas. Por la misma razón, resulta fácil llevar el seguimiento del equipo. Tienen acceso a todas las personas que necesitan para tomar buenas decisiones. Si no toman buenas decisiones, sólo pueden echarse la culpa a ellos mismos. El equipo está equilibrado.Los equipos de prestaciones resultan adecuados para proyectos de resolución de problemas, ya que ofrecen el refuerzo y la facilidad de seguimiento necesarios para resolver las cuestiones planteadas de forma expeditiva. También son adecuados para proyectos de creatividad, ya que la composición interdisciplinar del equipo puede estimular las ideas. La gestión adicional generada por los equipos de prestaciones se desperdicia en los proyectos de ejecución táctica: si todas las tareas están claramente identificadas, los equipos de prestaciones tienen poco que aportar.

• EQUIPO DE EMERCENCIAS O DE BUSQUEDA Y RESCATE: Este tipo de equipo se centra en resolver un problema específico. Hay que combinar un conocimiento especializado de herramientas software y hardware específico con un conocimiento igualmente especializado sobre un entorno comercial determinado. Este equipo necesita un conocimiento íntimo del terreno en el que va a buscar, la capacidad de responder inmediatamente, y un excelente conocimiento sobre el modo de estabilizar el sistema en poco tiempo, controlando el problema de inmediato.Esta estructura de equipo es la más apropiada para equipos que necesitan centrarse en la resolución de un problema. Está demasiado dirigido a problemas básicos como para soportar mucha creatividad, y está demasiado orientado a corto plazo como para soportar la ejecución táctica.

• EQUIPO DE ESPECIALISTAS (G.E.O.): En este tipo de equipo, cada miembro está especialmente entrenado en algún tema. Los equipos se “entrenan” constantemente, para que cuando estalle una crisis puedan trabajar conjuntamente como un bloque sin fisuras.La idea básica es coger un grupo de personas con una sólida formación en una herramienta o método determinado, y dedicarlas a un problema que se adapta perfectamente a ser resuelto con esta herramienta o método.Generalmente son equipos permanentes, están habituados a trabajar juntos, y tienen papeles bien definidos.Resultan especialmente adecuados en proyectos de ejecución táctica. Su trabajo no consiste en ser creativos, sino en implementar una solución dentro de los límites de una herramienta o metodología que conocen perfectamente. También funcionan bien en proyectos de resolución de problemas. Los miembros del equipo tienen confianza mutua, y su


concentración en una fase determinada del proyecto les permite tratar la realización de esa fase como un único problema que pueden superar rápidamente.

• EQUIPO DEPORTIVO: Los desarrolladores son seleccionados como mínimo tan cuidadosamente como los directivos, y probablemente resultan más críticos para el éxito del proyecto.El presidente de un equipo deportivo gestiona las decisiones, entre bastidores, que son importantes estratégicamente pero no es el que golpea la bola.El responsable de software también es importante, pero no por ninguna de las capacidades de desarrollo. El papel del responsable es despejar el camino de obstáculos y permitir que los desarrolladores trabajen de forma eficiente. Los desarrolladores podrían desarrollar un producto sin el responsable,pero el responsable no podría sin los desarrolladores. No tiene sentido ver al responsable como una persona mejor o que está jerárquicamente por encima de los desarrolladores.Los equipos deportivos también tienen papeles altamente especializados. El responsable del proyecto puede contratar a un especialista, por ejemplo en bases de datos, pero no debe esperar de él otra cosa.Este modelo específico se aplica mejor a los proyectos de ejecución táctica, que hacen énfasis en los papeles altamente especializados que desarrollan las personas individuales.

• EQUIPO DE TEATRO: Se caracteriza por una fuerte dirección y una gran negociación de los papeles del proyecto. El papel central del proyecto es ocupado por el director, que mantiene la visión del producto y asigna a la gente responsabilidades en áreas individuales. Los participantes individuales pueden adaptar sus papeles, sus partes del proyecto, como les dicten sus propios instintos artísticos. Pero no pueden llevar demasiado lejos sus propias ideas, evitando colisionar con la visión del director. Si sus ideas chocan con la visión del director, la visión del director tiene que prevalecer para la buena marcha del proyecto. En el modelo de teatro, no se está asignado simplemente a un proyecto. Se participa en una audición, y se acepta un papel. Antes de poder aceptar un papel hay una larga negociación.La fuerza del modelo de teatro consiste en que proporciona una vía para integrar importantes contribuciones individuales junto con una fuerte visión central en proyectos de creatividad. Como afirma Fred Brooks, la integridad conceptual es la consideración más importante en el diseño de un sistema, y si un sistema necesita tenerla, hay una persona que tiene que controlar los conceptos [Brooks, 1975].El modelo de teatro resulta particularmente apropiado para equipos software dominados por fuertes personalidades.Es un modelo adecuado para proyectos multimedia modernos. Mientras anteriormente los proyectos software necesitaban integrar las contribuciones de varios desarrolladores de software, ahora tienen que integrar las contribuciones de varias personas pertenecientes a distintas especialidades.


BIBLIOGRAFÍA1. Shtub, A., Bard, J. Et Sholomo, G. “Project Management Engineering, Technology and

Implementation”, Prentice-Hall, 1994.2. Haynes, M. E. “Administración de proyectos” Grupo editorial Iberoamerica, 1992.3. Weiss, J. W., Wysocki, R.K. “Dirección de proyectos, las 5 fases de su desarrollo”. Addison-

Wesley Iberoamericana.4. Davis, W. S. “Herramientas Case” Editorial Paraninfo, 1992.5. Universidad de Castilla-La Mancha, Escuela Superior de Informática, Planificación y Gestión

de Sistemas de Información, Francisco Ruiz González Miguel Angel Molina Tejedor Ciudad Real, 15 de Mayo del 2000.

guia proyectos informaticos

Documents