Asignacion De Recursos

1. INTRODUCCIÓN.

La asignación de recursos consiste en asociar a cada una de las tareas, en el proyecto, las personas, equipos y materiales necesarios para que éstas se puedan realizar. Esta es una labor complicada y fundamental en la planificación del desarrollo de una aplicación informática.

La visión de las personas como recursos es errónea. Como dice Handy en “La era de lo irrazonable”: “Las personas no son recursos humanos. Son individuos vivos, con todo su derecho a ser diferentes.” De hecho, Peter Druker, haciendo referencia a las empresas del futuro dice que no se parecerán a lo que pueden imaginar empresarios y profesores, sino que serán similares a los hospitales, universidades o grandes orquestas sinfónicas. Al igual que estas tendrán en el conocimiento su principal recurso, pasando a ser organizaciones compuestas fundamentalmente por especialistas que trabajaran de acuerdo a las informaciones que reciban.

En cualquier caso esto no eximirá al director o coordinador de tener que enfrentarse al reparto de tareas y adscripción de las mismas a los miembros de la organización

Actualmente los recursos humanos son el componente económico más importante, en los proyectos informáticos, por encima de los recursos físicos como Hardware o instalaciones.

Como hemos visto, mediante la estimación con los Puntos de Función y dependiendo de los datos históricos de la organización, estimamos el esfuerzo que deberán realizar las personas encargadas de desarrollar la aplicación.

El no tener en cuenta, con estas estimaciones, los recursos físicos de instalaciones y hardware necesarios para el desarrollo parece deberse a que el precio del Hardware baja de forma continua y que en todo caso el consumo de estos recursos es función de la cantidad de meses-hombre que dure el proyecto .

Otro aspecto importante es el de los consultores, profesionales externos, que asesoran y dan soporte a tareas en donde la empresa no tiene experiencia o le resultaría oneroso mantener a un empleado. En grandes proyectos pueden llegar a suponer un importe similar al consumido por las personas que desarrollan la aplicación.

De forma general podemos afirmar que el coste del proyecto total es el doble del de los recursos humanos, el de los desarrolladores más el del HW, Instalaciones y software base. En grandes proyectos, que se alejen del proyecto típico de la organización habrá que añadir los servicios de empresas consultoras, que pueden significar una parte más en el coste (tres veces el gasto en recursos humanos). En cualquier caso, como vimos, la empresa mantendrá un registro del esfuerzo dedicado a los proyectos informáticos y su coste global.

En los recursos utilizados por el proyecto habría que incluir el consumo de tiempo dedicado a éste por parte de los usuarios. No se suele tener en cuenta y este puede suponer un esfuerzo considerable, aunque no se evalúe. Suele salir a la luz en las críticas del tipo: "¡Con el tiempo que nos han estado consultando y vaya aplicación han hecho!". También queda patente cuando un usuario justifica el no asistir a una reunión por tener mucho trabajo pendiente.

Desde un punto de vista global, además de las tareas propias del proyecto debemos tener en cuenta, que para que un grupo haga su trabajo, es necesario que:

 Se realicen las tareas en si mismas.

 Se realicen tareas de mantenimiento del equipo, esto es, lo que ayude a mantener su cohesión, su motivación y su voluntad general de dedicarse a la tarea.

 Se satisfagan las necesidades individuales, es decir, lo que ayuda al individuo a sentirse parte del grupo y le capacita para realizar su aportación máxima.

Las planificaciones forzadas artificialmente, para que duren o cuesten menos de lo previsible, condenan al proyecto independientemente de la calidad del personal o de la disponibilidad de herramientas, lenguajes y procesos de desarrollo. Si se trata de comprimir la duración o el presupuesto, el personal que trabaje en el proyecto, no lo hará eficientemente, no se forzaran si ven que es imposible alcanzar la meta. Peor aun, cuando los retrasos empiecen, sufrira la moral y el proyecto probablemente cueste más de lo que hubiera costado de haberse hecho de forma razonable.

Como se ve la asignación de recursos es complicada e implica a muchas personas.

2. DETERMINACIÓN DEL PLAZO DE ENTREGA DE LA APLICACIÓN.

A lo largo de la asignatura utilizamos los términos "Proyecto Informático" y "Aplicación Objetivo" como sinónimos y complementarios, así, determinamos los puntos de función de la "Aplicación", N, y decimos que se trata de un "Proyecto Informático" con N puntos de función.

La diferencia entre estos conceptos, para los informáticos, es que mientras la aplicación es el objetivo, el proyecto es el medio para alcanzarlo. Los clientes y usuarios suelen percibirlo de forma distinta, la aplicación es el producto que les hace falta para poder alcanzar sus objetivos empresariales, y cuanto antes esté disponible mejor. Mientras que el proyecto lo perciben como algo "oscuro", que siempre consume más de lo que se dijo en dinero y tiempo.

De modo que al determinar el plazo de entrega de la aplicación hay dos variables importantes, que responden a:

• ¿Cuánto tiempo y dinero consumirá este proyecto? y

• ¿Cuándo deberíamos tener disponible la aplicación para optimizar el trabajo de los usuarios?

2.1. IDENTIFICACIÓN DE LOS LÍMITES TEMPORALES DEL PROYECTO VERSUS ASIGNACIÓN DE RECURSOS

Una vez estimado el esfuerzo necesario para realizar una aplicación (Puntos de Función - Tareas) y antes de obtener una planificación definitiva con la asignación de recursos, debemos conocer, a grandes rasgos las limitaciones temporales del proyecto.

Evidentemente si un proyecto requiere el esfuerzo de 165 meses/hombre si decidimos que una persona realice el proyecto, dentro de 15 años entregaremos la aplicación al usuario, si la empresa existe y el usuario o su departamento siguen teniendo interés en esta aplicación.

Hay varias razones que hacen absurdo el planteamiento anterior:

1) Los negocios actuales son muy agresivos lo que implica que las organizaciones que les dan soporte han de ser ágiles y flexibles. Posiblemente ningún sistema pueda sobrevivir 10 años en una empresa.

2) Una aplicación importante para la empresa deberá estar disponible lo antes posible dados los costes de oportunidad que tendrá.

3) La tecnología evoluciona a tal velocidad que el lenguaje o entorno de trabajo de la aplicación quedarán obsoletos mucho antes de estar disponible la aplicación. Imagine una aplicación que comenzó a desarrollarse hace 15 años, con las últimas tecnologías.

4) El desarrollo de aplicaciones informáticas, de cierta envergadura, requiere de especialistas en diversas áreas como bases de datos, telecomunicaciones, diseño de interfaces, obtención de especificaciones, programación de sistemas, etc.

Éstas son razones suficientes para pensar que es imposible el que una sola persona lleve a cabo el desarrollo de una aplicación como ésta.

Lo opuesto es pensar en desarrollar la aplicación en un sólo día con (165*20 =) 3.300 personas en el desarrollo. Esto no es viable técnicamente dado que unas tareas no se pueden iniciar antes de la finalización de otras. Alguien puede pensar que asignando muchas personas a una tarea, esta se podrá finalizar en digamos una hora, cosa que como veremos también resulta técnicamente imposible .

Así pues los proyectos informáticos deberán ajustar su duración:

 por una parte adaptándose a los aspectos del negocio que nos indican unas fechas a partir de las cuales ya no resulta interesante el disponer de la aplicación o tener unos costes de oportunidad elevados,

 por otra parte a los aspectos técnicos del desarrollo que indican la cantidad máxima de recursos que se pueden asignar a cada tarea,

 además los aspectos de gestión hacen aconsejable tener un equipo de desarrollo lo más pequeño posible, con el fin de evitar problemas de comunicación y coordinación.

Evaluando estos aspectos, y otros que veremos en la asignatura, se deberá llegar a un consenso sobre la duración total del proyecto y el consumo de recursos a realizar.

2.2. DETERMINACIÓN DEL PLAZO.

Para determinar el plazo de entrega se puede seguir tres caminos, uno se basa exclusivamente en la negociación y dos de ellos siguen un método técnico. Empezaremos por el menos recomendable y más difundido.

LA NEGOCIACIÓN.

La negociación es una de las técnicas más extendidas para fijar los plazos de entrega de aplicaciones informáticas. Esta técnica puede ser muy peligrosa si se producen ciertas circunstancias como:

• Se comienza a negociar sin tener claras las especificaciones del cliente.

• El usuario con ligeras nociones de las técnicas de desarrollo actuales, fundamentalmente basadas en presentaciones comerciales de distribuidores de herramientas fuerza a que el plazo negociado sea lo menor posible.

• El usuario tiene la necesidad de disponer de la aplicación lo antes posible.

• El director del CPD o jefe de proyecto tiene que negociar con un usuario de mayor nivel jerárquico.

...