GESTIÓN DE PROYECTOS Y ASIGNACIÓN DE RECURSOS

6. ASIGNACIÓN DE RECURSOS EN LOS PROYECTOS INFORMÁTICOS 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 pueda puedann real realizar izar.. Esta Esta es una una labor labor comp compli lica cada da y fund fundam amen enta tall 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 Druker,, haci hacien endo do refe refere renc ncia ia a las las empre empresa sass del del futuro futuro dice 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 organi organizac zacion iones es compuest compuestas as funda fundame menta ntalm lment entee por espec especia iali listas stas 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 o rganizació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 depen dependi dien endo do de los los datos datos histó históri ricos cos de la organ organiz izac ació ión, n, estim estimam amos os el esfue esfuerzo rzo que deberán deberán reali realizar zar las las personas personas encarga encargadas das de desarrol desarrollar lar 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 proyecto1. 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í resultaríaa oneroso oneroso manten mantener er a un empl emplead eado. o. En grandes grandes proyectos proyectos pueden llegar a suponer un importe similar al consumido por las personas que desarrollan desar rollan la aplicación. aplicación. Se puede argumentar argumentar que con un Hardwa Hardware re más efici eficiente ente,, con con unas oficinas oficinas mejor acondicionadas o que con herramientas de desarrollo más evolucionadas se podría realizar el proyecto en menos tiempo. Este tipo de cuestiones y otras que influyen en la duración y calidad del Software las trataremos en DPI' 1

71

PLANIFICACIÓN PLANIFICACIÓN DE PROYECTOS INFORMATICOS

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, Instal Instalac acione ioness y software software base. base. En grandes grandes proyectos, proyectos, que se alej alejen en 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 aport ación máxima. 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 proc proces esos os de desa desarro rrolllo. lo. Si se trata trata de comp compri rim mir la dura duracción ión o el pre presu supu pues esto to,, el perso persona nall que que traba trabaje je en el proy proyec ecto, to, no lo hará 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 "Ap "Aplicac icació iónn Obje Objeti tivo vo"" como como sinón nónimo moss y comp comple leme ment ntar ario ios, s, así, 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 72

ASIGNACIÓN DE RECURSOS EN LOS PROYECTOS INFORMÁTICOS

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. 2.1. IDEN IDENTI TIFI FICAC CACIÓ IÓN N DE LOS LÍMIT LÍMITES ES TEMPOR TEMPORALE ALESS DEL DEL PROYECTO VERSUS ASIGNACIÓN DE RECURSOS Una vez estim estimado ado el esfue esfuerzo rzo necesa necesario rio para realiza realizarr una una apli aplicac cación ión (Puntos de Función - Tareas) y antes de obtener una planificación definitiva con la asig asigna naci ción ón de recurs recursos, os, debe debemo moss conoce conocer, r, a grand grandes es rasgos rasgos las las lilimitacio mitaciones nes temporales tempor ales del proyecto. proyect o. Evidentemente si un proyecto requiere el esfuerzo de 165 meses/hombre si deci decidi dimo moss que una una perso persona na reali realice ce el proye proyecto, dentro dentro de 15 años 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 negoci negocios os actua actuale less son son mu muyy agres agresiv ivos os lo que imp mpllica ica que las las organi organizac zacion iones es que les les dan soporte han han de ser ágile ágiless y flex flexib ible les. s. Posib Posible leme ment ntee ning ningún ún siste sistema ma pueda pueda sobre sobrevi vivi virr 10 años años en una una empresa. 2) Una apli aplicac cación ión importante importante para la empresa empresa deberá deberá estar disponi disponible ble lo antes posible dados los costes de oportunidad que tendrá. 3) La tecnología tecnología evoluc evoluciona iona a tal velocida velocidadd que el lengu lenguaje aje o entorno de trabajo de la aplicación quedarán obsoletos mucho antes de estar dispon disponib ible le la aplic aplicac ación ión.. Imagi Imagine ne una aplica aplicació ciónn que comenz comenzóó a desarrollarse hace 15 años, con las últimas tecnologías. 4) El desa desarrol rrollo lo de apl aplicac icacio ione ness inform nformát átic icas as,, de ciert ciertaa enve enverg rgadu adura, ra, requiere requiere de especi especial alist istas as en divers diversas as áreas áreas como bases bases de datos, datos, tel telecomu comunnicaciones, diseño de inte nterfaces, obt obtenci nción de especificaciones, especificaciones, programación progr amació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 2. 2

Frederick P. Brooks comenta en su libro The mythical man-month: "Por lo tanto el meses-

73


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

por una parte adaptándose 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 comunicación y coordinación. coor dinació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. difundido. LA NEGOCIACIÓN. La negociación 3 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 especificaciones del cliente.

•

El usuario con ligeras nociones de las técnicas de desarrollo actuales, fund fundam amen enta talm lmen ente te basa basada dass en prese presenta ntaci cion ones es come comerc rcia iale less 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 nivel jerárquico.

•

El trabajo usual de muchos usuarios es el de contratar servicios a empresas externas y saben que siempre hay un margen que se puede disminuir.

Con todas estas circunstancias es normal que tras la negociación de los hombre como una unidad para medir el tamaño de un trabajo es un mito peligroso y engañoso. Implica que los meses y los hombres son intercambiables.". Ver Análisis Estructurado Moderno, E. Yourdon; pág. 536. o Assesment and Control of Software Risks, C. Jones; pág. 118.

3

74


plazos de entrega de la hipotética nueva aplicación se tengan: •

Fuertes niveles de compromiso personal del jefe del proyecto,

•

Escas Escasaa parti partici cipa paci ción ón en la fijaci jación ón de plaz plazos os de los los que van van a desarrollar la aplicación. aplicación.

Este Este marco arco es el idea ideall para para el fraca fracaso so de un proye proyect ctoo ya que que el desco desconoc nocim imie iento nto de las las nece necesi sida dade dess del del usuar usuario io suel suelee hace hacerr que se subestimen, por lo general. Además el compromiso unilateral del jefe, en estas condiciones, difícilmente será respaldado por sus subordinados. En cualquier caso la negociación es habitual en estas circunstancias, por lo que el planteamiento que se propone puede ser más aconsejable. Además, el espíritu comercial es imprescindible en las empresas. SELECCIÓN DE UNA ALTERNATIVA El segundo método es el seguido a lo largo de esta asignatura. Puede verse como una negociación en la que el director del proyecto ha preparado una serie de alternativas y se las ofrece al cliente. Se parte de la obtención de una especificación especificación de lo que desea el cliente cliente y sobre s obre ella se diseñan diferentes alternativas. Aplicando el historial productivo de la empresa, se estima el esfuerzo necesario para cada alternativa. En una reunión posterior los posibles implicados en el proyecto (analistas, programadores, etc.) llegan a consensos sobre las planificaciones y recursos necesarios. Si la empresa desea un presupuesto, éste se calcula basándose en las planificaciones realizadas. En cualquier caso se pueden obtener diferentes planificaciones, para un mismo sistema con distintos diseños e incluso un mismo mismo diseñ diseño, o, modif modific ican ando do los los recursos recursos asign asignados. ados. Los presupue presupuestos stos y planificaciones se presentan al usuario que selecciona el más apropiado al negocio. Este sistema tiene muchas probabilidades de alcanzar el éxito ya que, prim primero ero:: se basa basa en datos datos histó históri ricos cos de product productiv ivid idad, ad, y segu segundo ndo:: el compromiso de los desarrolladores es alto, ya que formaban parte del grupo que realizó r ealizó la estimación. MÉTODO EMPÍRICO DE PUTNAM Y NORDEN. El tercer método que hemos mencionado se basa en estudios empíricos que inicialmente realizó Norden (1963), basados en proyectos de IBM. Se basa en el estudio de la duración de los proyectos y la cantidad de personas asignadas cada mes. Éstos le llevaron a identificar la curva de desarrollo, que se muestra en la figura 1. Putnam estudió y refinó esta curva a partir de datos sobre grandes proyectos de la armada americana. En pequeños proyectos esta curva queda distorsionada. La fórmula a que obedece esta curva es: Esfuerzo_en_hombres(t) = 2K a t e -at² donde 75


•

Esfuerzo_en_hombres es la cantidad de meses hombre que se aplican en un momento determinado,

•

a es el factor de aceleración, indica el incremento incremento inicia iniciall de la curva, y

•

K es el esfuerzo total del proyecto, en meses/hombre (área de la curva).

15 10

Esfuerzo Asignado

5 0 0 2 4 6 8 10 1122 1144 1166 1188 20 2222 2244 Meses de Desarroll D esarrollo o figura 1. Curva para un proyecto de 165 meses hombre •

t es un instante de tiempo a lo largo de la realización del proyecto.

Ésta curva contiene la siguiente información: •

Al principio del proyecto aunque se asigne muchas personas, estas no pueden ser utili utilizadas zadas de forma eficiente. eficiente.

•

Al ir apar aparec ecie iend ndoo tare tareas as técn técniicas cas de progr program amac ació ión, n, diseñ iseñoo e implementación de bases de datos, preparación de pantallas, informes, etc. se puede utilizar más personal.

•

Una vez realizado el grueso del trabajo van quedando menos tareas y la cantidad de personas que se pueden asignar son menos.

La curva la podemos aplicar para estimar la duración de un proyecto con K esfuerzo en hombres/mes, teniendo unas perdidas mínimas. Dicho de otra manera, si aplicamos a un proyecto una cantidad fija de personas desde el inicio del proyecto, nos encontraremos en la situación descrita en la figura 2.

76


o o r a n d a d e a c c x t a r a i o u d l E N c a p r p a A t a o a r l z o r i o z o i b l e a r o o r e s t e r z i a u s a n ó n a d f u p o n f a l s f c e p e c i ó u e a s t a f E s i a e E s i s n a r e c N o m g E s e m D a c g C s i o r d h a n c i

o o r z t a d e f u g a s E s a l M 16 14

a n o s r e P

12 10 8 6 4 2 0 0

2

4

6

8

10

12 12

14 14

16 16

18 18

20 20

22 22

24 24

Meses de Desarrollo

figura 2 Otros usos de estas curvas se dan cuando podemos fijar la cantidad máxima de personas de las que podremos disponer en cualquier momento del desarrollo. En este caso nos podemos mover en una familia de curvas, como las de la figura 3 y seleccionar la que se adapte mejor a nuestra situación. 80 60 40 20 0 0

12

24

36

48

60

72

84

MESES DE DESARROLLO

figura 3 Algo similar a esto postulo Boehm, definiendo la región imposible en cuanto a la duración de un proyecto, en concreto, basándose en los recursos necesarios para realizar el proyecto, indica que desde la especificación a la entrega de un producto informático, no puede pasar menos de: T > 2,15 ∗ 3 PersonasMe s

Y el 99% de los proyectos cumplen esto.

3. TIPOS DE RECURSOS USUALES. Por recurso entendemos el trabajo de las personas o cosas necesarias para realizar alguna tarea. Podemos clasificarlos clasificarlos en: ⇒

Trabajo, puede realizarse por personas de la organización o externas; podemos descomponerlo en: ⇒ Equip Equipoo de desar desarrol rollo: lo: Direc Director tor del del proye proyecto, Anal Analis ista tas, s, Diseñadores y Programadores. ⇒ Soporte al desarrollo: Especialistas en Base de datos, en redes local locales es y comuni comunicac cacion iones, es, en int interf erface aces, s, en formac formación ión,, así así

77


como Operadores Oper adores y Administrativos Administrativos 4. ⇒ Cliente entess y Usua Usuari rios os:: Pers Person onaal de la alt ltaa dire direcc cció iónn (es (es recomendable que el liderazgo del proyecto recaiga en una per perso sona na de este ste tipo), po), Direct rector orees y perso ersona nall de los departamentos afectados. ⇒

Lugar de trabajo, espacio en donde los desarrolladores realizarán sus tareas, podemos clasificarlo en: ⇒ Salas de reu reuniones, en dond dondee usuarios, os, clientes y desarrolladores realizarán tareas conjuntas. ⇒ Entorno de desarrollo, donde los informáticos realizan trabajos indi indivi vidua dualm lment entee como documen documentar tar o programar programar.. Hay que hacer notar que muchas de las compañías y empleados más productivos disponen de oficinas silenciosas. Con teléfonos que se puede puedenn sile silenc ncia iarr o desv desvia iarr. Están Están aisl aislad ados os de las las interrupciones que no son propias del asunto. ⇒ Zona Zonass para para recog recogid idaa de datos, datos, luga lugare ress de traba trabajo jo de los los usuarios y zonas de archivos tanto actuales como futuros.

⇒

Equipa Equipami mient ento, o, mu mueb eble less necesa necesario rioss para poder reali realizar zar el trabajo. trabajo. podemos clasificarlo clasificarlo en: ⇒ Mobiliario de oficina, mesas, sillas, lámparas, teléfono, fax, etc. ⇒ Material Material para presentacione presentaciones, s, proyectores, pantalla pantallas, s, mesas mesas apropiadas, etc. ⇒ Ordenadore Ordenadores, s, Infraest Infraestructu ructura ra de red, estacio estaciones nes de trabajo, trabajo, Hardware específico del sistema de desarrollo, etc.

⇒

Material básico para el desarrollo, Software y Manuales: ⇒ S.O., Lengu Lenguaj ajes es de desarrol desarrollo, lo, Herrami Herramient entas as de desarrol desarrollo lo (CASE). ⇒ Manuales del software: iniciac iniciación, ión, manual de usuario, lilibrerías, brerías, etc.. ⇒ Libro Libross con refe referen renci ciaa a técni técnica cass de desa desarrol rrollo: lo: ejem ejempl ploo "Análisis Estructurado Moderno de Edward Yourdon", etc.

⇒

Material fungible, es el material que se consume durante el desarrollo. Son ejemplos: ejemplos: ⇒ el material de escritorio: bolígrafos, clips, grapas, barras de pegamento, líquido corrector, etc.. ⇒ el mater ateria iall nece necesa sari rioo para para los los equi equipo pos: s: ti tint ntaa o tone tonerr de impre impresora, sora, papel papel de impres impresora, ora, transpar transparenc encias ias,, disqu disquetes, etes, cintas de back-up, etc.

El haber descrito con tanto detalle algunos de los materiales se debe a que en la práctica se pierde mucho tiempo, de personal de desarrollo, por no estar disponibles cosas que aparentemente tienen poca importancia.

4. DURACIÓN DE LAS TAREAS. Ver falta de especialización en el libro de C. Jones " Assesment and Control of Software Risks" pág. 409-18 4

78


Por lo visto hasta ahora, las tareas ya tienen asignado un esfuerzo, ahora hay que decidir cuántos recursos se le asignan a cada tarea, de modo que obtengamos la duración en tiempo de cada una de ellas. 4.1. ESFUERZO Y DURACIÓN DE LAS TAREAS. Normalmente se suele confundir el esfuerzo necesario para desarrollar una tarea (meses/hombre) con el tiempo necesario para llevar a cabo la misma. Una tarea que tenga asignado un esfuerzo de 10 días, puede llevarse a cabo en el plazo de 5 semanas, aplicando un esfuerzo de 2 días a la semana. También nos podemos encontrar con el caso contrario en que una tarea que necesita el esfuerzo de 10 días se lleve a cabo en una semana, empleando a dos personas a tiempo completo en su ejecución. El esfuerzo aplicado puede verse afectado por interferencias externas. Por ejemplo, teniendo que realizarse un esfuerzo de una semana - hombre, y asignando una persona a esta tarea durante una semana, puede no finalizar a causa de las interferencias. Thomsett dice que hay muchas razones para esto y en concreto menciona algunas como: ⇒

Es necesario necesario repetir repetir trabajos o corregir defectos defectos de tareas previas, previas, que se suponían terminadas, para poder realizar la tarea actual.

⇒

Hay que tener tener en cuenta cuenta las las vacac vacacion iones, es, fiest fiestas, as, fiestas iestas local locales, es, puentes, etc. que puedan afectar al proyecto tanto en los lugares de trabajo como en las zonas de clientes o usuario.

⇒

Otros equipos de la empresa pueden realizar consultas al personal del proyecto actual sobre temas ajenos a éste.

⇒

La falta de administrativos puede implicar que los programadores tengan tengan que reali realizar zar todos sus papel papeleos eos que deberí deberían an haber haber sido sido delegados.

⇒

Falta de formación Falta formación y adiestrami adiestramiento ento adecuada en el personal personal del proyecto.

⇒

Falta de reuniones del equipo.

⇒

Interrupciones de todo tipo como llamadas telefónicas etc..

⇒

Tiempo de espera en reuniones.

⇒

Tiempo que tarda el personal en cambiar de tarea, no se puede esperar que sea instantáneo.

Estos factores se pueden llevar entre el 30% y el 50% del esfuerzo realizado. No sería extraño que para una reunión en otra ciudad, de dos días de duración, a una persona dedique cuatro días de esfuerzo si no tiene soporte administrativo y tiene que gestionarse los billetes, las reservas de hotel, etc. Otro ejemplo lo dan los retrasos a la hora de comenzar una 79


reunión por falta de personas. Aunque parezca paradójico, por culpa de estos factores, las personas con mayor nivel de experiencia y responsabilidad en la empresa son los mas afectados. Pues: ⇒

⇒ ⇒

debe debenn ense enseña ñarr y adie adiestr strar ar al person personal al del del proyec proyecto to en tema temass no previstos; son consultados consultados por otros o tros proyectos, y se les suele pedir que asistan a reuniones, presentaciones, etc. que en principio no tienen relación con el proyecto actual.

4.2. ASIGNACIÓN DE PERSONAS PERSON AS A TAREAS. TAREAS. La experiencia indica que es mejor disponer de un equipo pequeño de buenos profesionales que uno mayor de personas no tan capacitadas. De hech hechoo la gente gente correct correctaa aun aun con herra herram mienta ientas, s, leng lengua uaje jess y proceso procesoss insuficientes, pueden tener éxito. Lo contrario parece imposible. Por otra parte si confiamos todo a unas pocas personas nos podemos encontrar con problemas: ¿Qué ocurre si se van? De modo que tendremos equilibrar al personal. A la hora de asignar personas a cada tarea nos encontramos con un grupo de tareas y otro de personas. Al comienzo del tema ya digimos que las personas no pueden verse como un recurso más. Los enfoques actuales relativos a esta asignación pasan por evaluar de cada empleado y tarea los siguientes aspectos: 



El conativo o KAS (Knowledge, Abilities, Skills), se puede ver como la capacidad técnica. Es decir:  Los conocimientos para realizar la tarea  La capacidad de realizarla, y  La experiencia sobre la materia. El cognitivo o MAC (Motivation, Attachment, Confidence), se puede ver como la voluntad de realizar la tarea. Es decir:  La motivación de la persona,  El compromiso que asumirá, y  La seguridad que tiene en si para realizarla

Da la impresión, de que basándose en esto, Fergus O'Connel l5 compara a un proyecto con un puzzle e indica que se ha de asignar las piezas (tareas) a las personas. Dice que eres una persona con suerte si encuentras la persona aprop apropia iada da a cada cada piez pieza. a. Por pers person onaa hace hace refe refere renc ncia ia al con conjunt juntoo de personalidad, habilidades, experiencia, motivación, metas personales, puntos fuertes y puntos débiles que nos hacen como somos. Además asocia los aspectos conativos al que la persona pueda realizar la tarea desde el punto de vista técnico. Los aspectos cognitivos los asocia a si la persona quiere realizar la tarea. Dado que tenemos una lista de tareas y una lista de personas, se trata de 5

En su libro "How to Run Successful Projects"

80


reali realizar zar la mejor mejor asig asignac nación ión posibl posible. e. O'Conn O'Connel elll propone propone la sigui siguient entes es posibilidades para cada par tarea - persona: Puede realizar el trabajo y quiere realizarlo.

◊

◊

Esto es lo ideal.

Puede realizar el trabajo y accede a realizarlo.

◊

◊

Esta bien para el proyecto, habría que motivar a ésta persona y buscar, a largo plazo, trabajos que se le ajusten.

Puede realizar el trabajo pero no esta dispuesto a realizarlo.

◊

◊

Tenem enemos os probl problem emas as,, hay hay que ver ver cuál cuál es el proble problema ma y resol resolve verl rloo o nos nos encon encontra trarem remos os realm realmen ente te en la últi última ma categoría.

Puede ser formado para realizar el trabajo.

◊

Si estás dispuesto a: gastar dinero y tiempo en formación, modificar la programación del proyecto con la formación, soportar una sobrecarga en la dirección, y a afrontar el riesgo de que no funcione bien,

◊ ◊ ◊ ◊

Entonces todo está bien. En el futuro es posible que tengas una persona en tus proyectos de la primera categoría mencionada. ◊

No puede realizar el trabajo. ◊

Tienes problemas serios, tendrás que identificar otras tareas para esta persona.

4.3. 4.3. TIPO TIPO Y DURA DURACI CIÓN ÓN DE TAREA AREASS EN FUNC FUNCIÓ IÓN N DE LA CANTIDAD DE PERSONAS ASIGNADAS. En principio el asignar muchas personas a una tarea no quiere decir que la tarea forzo forzosa same mente nte dure dure menos menos ti tiem empo. po. Es decir decir,, la gente gente y la duración no son intercambiables. Frederick P. Brooks en su libro “The mythical man-month” ofrece cuatro tipos posibles de tareas. En cada una de ellas la relación existente entre meses y hombres es diferente. Las posibles situaciones son: 1) Las Las tareas tareas se se puede puedenn repart repartir ir de forma perfecta, sin necesidad de comunicación entre las personas. Cuando más personas se asi asignen nen a una tare tarea, a, ésta ésta tendrá una duración proporcionalmente menor.

9 8 7

n 6 ó i 5 c a r 4 u D 3 2 1 0 0

1

2

3

4

5

Personas

6

7

8

81


2) La tarea tarea no se pued puedee part partir ir (Para (Para que que nazc nazcaa un niño niño se requ requie iere renn nueve meses, no importa cuantas mujeres se asignen). Éste tipo de 9 tare tareaas suelen darse arse cua cuando 8 tenemos tenemos li lim mitacio itaciones nes en algún algún 7 recurso. Así por ejemplo, si para n 6 ó i 5 c realizar las pruebas me hace falta a r 4 u un dispositivo Hw especial, del D3 que tan solo se dispone de una 2 1 unid unidad ad,, no tendr tendráá sent sentid idoo que 0 asig asigne ne mu much chas as personas personas a esta 0 1 2 3 4 5 6 7 8 tarea. Personas

9 8 9 7 8 n 6 ó7 i 5 c a6 n r 4 ó i u5 c D a 3 r 4 u 2 D3 1 2 0 1 0

0

1 0

1

2 2

3

4

5

Personas 3 4 5 Personas

6 6

7 7

8 8

3) La tarea tarea se se puede puede part partir ir,, pero se requiere comunicación entre las perso persona nas. s. En prin princi cipi pioo es la situación más habitual dado que de contener subtareas independientes, esto se hubiera tenido en cuenta en la desc descom ompo posi sicción ión en tare tareas as y tendría tendríamos mos varia variass tareas tareas bien bien def definid inidas as en el proyecto proyecto.. Por otra otra part partee es hab habit itua uall tene tener r tareas grandes que son criticas requiri requiriend endoo mu mucho cho esfue esfuerzo rzo y

que necesitamos que tengan un duración limitada. 4) La tarea se puede puede partir pero pero las interrela interrelacio ciones nes son tan complej complejas as que cuesta más tiempo realizar la tarea con muchas personas. Son las tareas en que habitualmente alguien dice: “mira prefiero hacerlo solo, por que entre varios no terminaremos nunca”.

5. Asignación consistente de las tareas Uno de los problemas clásicos que se producen al asignar las tareas es que estas no son vistas de la misma forma por el director y los subordinados. Es muy usual que si preguntamos a un director que es lo que espera de un subor subordi dina nado do y lo escr escrib ibim imos os en un pape papell y hace hacemo moss lo propio propio con el subordinado, obtengamos dos pedazos de papel, cuyo único parecido sea el hecho de que son de papel. Otro problema clásico es que aun cuando hacemos la asignación de tareas de forma cautelosa, muchos trabajadores sienten que alguna de las tareas que se han asignado a otro, le correspondía a el, por lo que la suele reclamar y puede llegar a suponer un conflicto que se encone, según se va desarrollando el proyecto. Una forma de evitar ambos problemas consiste en dar a conocer el plan, de forma más o menos completa a todos los trabajadores, luego se elabora una lista de objetivos y tareas junto a cada trabajador. De este modo se evita el primer problema, además de sernos útil para verificar que el trabajador este conforme con la asignación. Esta lista no debería ser superior a una pagina, legible en menos de un minuto (El ejecutivo al minuto, Blanchard). 82


Una vez terminada la asignación de objetivos y tareas, recibiremos una serie de solicitudes, quejas y aclaraciones, sobre: las tareas que una persona cree que deberí deberíaa tener tener asign asignada adas, s, dado que están están mu muyy relac relacion ionada adass con sus objetivos y que han sido asignadas a otro; tareas que alguien piensa que no han han sido ido asig asigna nada das; s; e incl ncluso uso asi asignac gnacio ione ness que que comp compart arten en vari varios os part partic icip ipan ante tess del del proye proyect cto, o, pero pero que que pare parece cenn incom ncompa pattible ibless por por la personalidad de los estos. Pasados un par de días de las quejas, se hace una reunión con todos los partic participa ipantes ntes,, se habl hablaa sobre sobre los proble problema mass surgido surgidos. s. Sé reescri reescribe benn las las asignaciones y se entregan de nuevo a los participantes. Este proceso puede requerir un par de iteraciones y las reuniones puede que sean tensas. Pero habrá valido la pena, ya que tendremos una descripción clara y compartida de los objet objetivo ivos, s, respons responsab abil ilid idade adess y tareas tareas asig asignad nadas as a cada miemb iembro ro del del equipo. equipo. Ademá Ademáss las las tareas tareas no se superpon superpondrán drán y compl completara etarann todas las las necesidades del proyecto. (Managing a Programming Project, Metzger).

6.CONSIDERACIONES FINALES. Como se ve habrá que buscar la situación en que se optimicen cualquiera o todas estas condiciones: ⇒

⇒

Coste Mínimo de desarrollo ⇒

En tiempo (Especialistas ya formados en cada área de trabajo. Tantos como se pueda, siempre y cuando no se tengan que rela relaci cion onar ar de form formaa comp comple leja ja por razó razónn de las tare tareas as asignadas).

⇒

En dinero (Utilizar el personal necesario para que se lleven a cabo las tareas de modo que se deban de comunicar lo mínimo posible y que ya conozcan las áreas que se les asignan).

Coste mínimo a largo plazo (pensar en el mantenimiento y en otros proyectos) ⇒

Hacer Hacer que el personal personal menos menos experi experime mentad ntadoo trabaje trabaje en el desarrollo, dando formación en caso necesario.

⇒

Hacer que el personal se sienta promocionado. Detectar los objetivos de cada empleado y hacer que cada nuevo proyecto sea un paso en la consecución de su objetivo.

Conviene recordar, al asignar personas a tareas, que la productividad de los programadores es muy variable, en un estudio se dio el mismo programa a desarrollar a varios programadores obteniéndose diferencias de 1 a 26 en los niveles de productividad. Esto quiere decir que en las tareas críticas convendrá poner al personal con mayor experiencia y reputación, ya que se espera que estos sean los más productivos.

6. BIBLIOGRAFÍA 83


1. Blanchard Blanchard,, K., Johnson, Johnson, S. “El ejecut ejecutivo ivo al minuto”. minuto”. Grijal Grijalbo bo Mandadori, Mandadori, S.A. 1983. 2. Brooks, Frederick Frederick P. P. ”The ”The myth mythica icall man-m man-month” onth” DeMarco, Tom. Controll Controllin ingg Software Software Projects. Projects. Prentice Prentice Hall, Hall, 1982. 1982. 3. DeMarco, (Biblioteca UPV) O'Connell. "How to run successful successful projects". Prentice Hall, Hall, 1994. 4. Fergus O'Connell. (Biblioteca UPV) 5. Metzger, P. Boddie, J. “Managing a programming project: people and processes” 3 ed. Prentice Hall, 1996. “Third Wave Wave Project Manageme Management”. nt”. Prentice Prentice Hall, Hall, 1993. 6. Thomsett, R. “Third (Biblioteca UPV) 7. Yourdon, ourdon, Edward. Edward. Análi Análisi siss Estructurado Estructurado Moderno. Moderno. Prentice Prentice Hall, Hall, 1993. (Biblioteca UPV)

84

GESTIÓN DE PROYECTOS Y ASIGNACIÓN DE RECURSOS

Recommend Documents