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

...