gestion_proyectos_con_exito.pdf

8/13/2019 gestion_proyectos_con_exito.pdf

1/34

GESTIONARPROYECTOSITCONXITO

Enero 2002

Copyright 2001 Advanced Quality Solutions


2/34

NDICE

NDICE 1

SUMARIO 3

ERRORES CLSICOS EN LA GESTIN DE PROYECTOS TI 4

UN EJEMPLO: MICROSOFT WORD 1.0 4 ERRORES RELACIONADOS CON EL FACTOR HUMANO 5 ERRORES RELACIONADOS CON EL PROCESO 9 ERRORES RELACIONADOS CON EL PRODUCTO 11 ERRORES RELACIONADOS CON LA TECNOLOGA 12 CONCLUSIONES 13 R ESUMEN DE LOS ERRORES CLSICOS 13

MOTIVACIN 14

FACTORES DE

MOTIVACIN TPICOS EN DESARROLLADORES

14

LOS CINCO FACTORES DE MOTIVACIN MAS IMPORTANTES 16 LOGRAR OBJETIVOS 16 POSIBILIDAD DE DESARROLLO PROFESIONAL 17 EL CONTENIDO DEL TRABAJO 17 V IDA PRIVADA 18 OPORTUNIDAD DE SUPERVISIN TCNICA 18 FACTORES QUE MATAN LA MOTIVACIN 19 FACTORES DE HIGIENE 19 OTROS FACTORES IMPORTANTES 19

CICLO DE VIDA DEL PROYECTO 22

MODELO EN CASCADA 22 VENTAJAS 22 I NCONVENIENTES 22 DESARROLLO EN ESPIRAL 23 VENTAJAS 23 I NCONVENIENTES 24 DESARROLLO EVOLUTIVO ORIENTADO A PROTOTIPOS 24 VENTAJAS 24 I NCONVENIENTES 24 EXTREME PROGRAMMING 25 VENTAJAS 27 I NCONVENIENTES 27

DESARROLLO ORIENTADO A HITOS 28


3/34

VENTAJAS 28 I NCONVENIENTES 28 MODELOS MIXTOS 29

CONCLUSIONES 30

BIBLIOGRAFA 31

R EFERENCIAS EN WEB 31 LIBROS & ARTCULOS IMPRESOS 31 LIBROS DE REFERENCIA 31 ARTCULOS Y FUENTES VARIAS 32


4/34

Sumario

Copyright 2001 Advanced Quality Solutions 3

SUMARIO

Cuando se observan las tasas de productividad de las compaas de desarrollo desoftware se observa un curioso fenmeno: hay aproximadamente un margen de diferencia del 1al 10, una tasa de diferencia difcil de encontrar en otras industrias. A qu se debe esto?

En resumidas cuentas hay que buscar la respuesta en el hecho que la industria delsoftware an es joven, se puede decir que hasta hace relativamente poco era ms bien unaactividad artesanal. Aunque la importante evolucin de la Ingeniera del Software ha aportadoen los ltimos aos una nueva generacin de metodologas y herramientas que hacen quepodamos hablar por fin de una industria basada en la ingeniera hoy por hoy el fracaso deproyectos de tecnologas de la informacin sigue siendo un fenmeno demasiado frecuente, yes que el uso de una metodologa adecuada y buenas herramientas son condicin necesariapero no suficiente para el xito de un proyecto.

Deben ir acompaadas de una cultura de trabajo adecuada, esto quiere decir de unaserie de prcticas y el saber hacer en las decisiones que se plantean ante los diversosproblemas que surgen en la gestin de un proyecto.

Este artculo aporta en gran medida este saber hacer y ayudar as al lector a colocarsems cerca del 10. Para ello no pretende plantear ideas revolucionaras, sino que se recopilany sintetizan las conclusiones a las que han llegado mltiples autores basndose en lo que elsentido comn les sugiere en base a sus experiencias en los proyectos que han vivido, es aqude donde parte el artculo: del sentido comn y la sensatez sobre una base de experiencia real.

De hecho una gran parte de las experiencias y conclusiones aqu expuestas le resultarnfamiliares al lector, quizs se anime as a poner en marcha algunas de las prcticas sugeridasen las que l posiblemente ya haba pensado, pero no se senta suficientemente respaldadopara aplicarlas. En este sentido el pblico al que va dirigido este artculo es amplio e implicatanto a desarrolladores, como gestores como a los clientes, a todos este artculo les tiene algo

que aportar, incluso para los profesionales de reas cercanas a las tecnologas de la informacincomo pueden ser la telecomunicaciones.En definitiva se trata de evitar decisiones estratgicas y tcticas errneas, poseer las

cualidades humanas para conseguir un mximo bienestar en el equipo, y con ello una mximamotivacin y productividad.

! Hay que recuperar un proyecto fuera de plazo? Aadamos ms gente!! Hay cambios sustanciales en los requisitos del proyecto? Bueno, como estamos

a la mitad del tiempo proyectado no es tan grave.! Acaba de salir una nueva tecnologa que promete reducir a la mitad del tiempo el

desarrollo de tres mdulos de los ms importantes de nuestra aplicacin, as queincorpormosla inmediatamente.

! ...Quien no ha vivido este tipo de situaciones y no ha sufrido sus consecuencias? Lo

peligroso su carcter seductor ante las presiones tpicas de un proyecto, por tanto, esimportante hacer un ejercicio de concienciacin y no dejarse seducir por el lado oscuro de lagestin de proyectos.

A lo largo del artculo se analizarn este tipo de errores clsicos y se discutir cmocorregirlos. Por otra parte se dar especial importancia al factor ms importante para laproductividad de un proyecto de desarrollo: el factor humano, y por fin se examinarn tambinalgunas de las principales estratgicas de cmo estructurar correctamente las actividades delciclo de vida de un proyecto.


5/34

Errores clsicos en la gestin de proyectos


ERRORES CLSICOS EN LA GESTIN DE PROYECTOSTISi bien disponer de un slido conocimiento de lo queno se debe hacer en un proyecto

supone un logro importante, hay que insistir en que no es suficiente con identificar losprincipales riesgos, que es lo que hace este documento a grandes rasgos,hay que afrontarlosde forma proactiva . Es decir, durante el desarrollo del proyecto hay que seguirmonitorizndolos, analizarlos, priorizarlos y resolverlos.

Muchos de los puntos aqu listados parecern evidentes, pero en la realidad se dandesgraciadamente con elevada frecuencia. En la mayora de los casos esto se debe a la lasubestimacin de la magnitud de su impacto sobre el proyecto y factores psicolgicos quehacen que las decisiones se toman ms por lo que pide el cuerpo en un momentodeterminado que por razones objetivas. Para ver las magnitudes de las que estamos hablando,he aqu un ejemplo real:

UN EJEMPLO: MICROSOFTWORD1.01 El ejemplo de Microsoft Word 1.0 (la versin de MS-DOS, incomparable a la actual en

complejidad) supone una buena leccin en lo que refiere a las consecuencias de una malaplanificacin. Esta aplicacin cost 5 aos de desarrollo, consumiendo 660 hombres/mes2 enesfuerzo y produjo un sistema de 249.000 lneas de cdigo. WinWord tuvo una planificacinextremadamente agresiva, la planificacin del mejor caso para un proyecto de estaenvergadura es de unos 460 das, la estimacin para ste del caso ms largo admitida era de395 das, una diferencia de 65 das.

La productividad ha sido finalmente de 377 lneas de cdigo por hombre/mes cuando unamedia de 1000-1500 lneas de buena calidad suele ser habitual. Esto da una idea del nivel dedegradacin que sufri el proyecto.

Cmo fue posible tal desmesura? El desarrollo de WinWord cumpli con una serie deejemplos tpicos de cosas que pueden ir mal cuando un proyecto software se planificademasiado agresivo:

Winword sufra objetivos inalcanzables. La directiva de Bill Gates para el equipofue hacer el mejor procesador de texto de todos los tiempos y hacerlo lo msrpido posible, preferiblemente en 12 meses, cualquiera de los dos objetivos eraun desafo, los dos juntos eran sencillamente imposibles.

Los tiempos agresivos impidieron una planificacin precisa. En los cinco aos sehicieron un total de 17 estimaciones de las cuales sola la segunda supero el ao(se hizo nueve meses despus de comenzar).

El proyecto sufri una rotacin de personal extrema, tuvo 4 lderes distintos a lolargo de los cinco aos, dos que abandonaron el proyecto por presin de tiempoexcesiva y uno por razones de salud.

Con la presin los desarrolladores descuidaron la calidad incluso de las partescrticas de la aplicacin, diciendo que estaban hechas, aun a sabiendas que notenan la calidad necesaria y estaban incompletas. El resultado fueron 12 mesesde estabilizacin, cuando este perodo se estimaba en 3 meses.

1 Fuente:Rapid Development . Microsoft Press 19962 Es decir, un equipo con un media de 11 miembros


6/34



El tiempo de desarrollo nominal (es decir, holgado) que se estim despus de un anlisisa posteriori eran 26 meses, un tiempo de desarrollo eficiente, 22 meses. Este tiempo hubierasido sustancialmente ms largo que el tiempo ms pesimista planificado, pero hubiese dado el

margen suficiente para evitar el grado de presin que degrad el proyecto por completo.Es doloroso asumir un plazo de 22 meses para un proyecto que se quiere obtener en 12,pero forzar el plazo deseado no es la solucin como este ejemplo demuestracontundentemente.El plazo ms corto es el que con mayor acierto se ha estimado.

Ejemplos de compaas que han aprendido estas lecciones incluyen Boeing, la NASA,Microsoft, Ericsson, etc. Ellos utilizan planificaciones sistemticas y realistas para evitar estosdesastres y asumen los tiempos que los tcnicos indican de cara a obtener un resultadodeterminado.

Ahora estamos en buenas condiciones para comprender la importancia de los siguientesprrafos:

ERRORES RELACIONADOS CON EL FACTOR HUMANO Motivacin insuficiente. Estudio tras estudio se ha demostrado que el factor

que ms afecta a la productividad y calidad del desarrollo probablemente sea lamotivacin del personal. Resulta fcil degradarla con presiones por calendariosexcesivas, y decisiones irracionales y por tanto hay que saber gestionarla. Este esun punto tan importante que le dedicamos un captulo aparte, pero adelantemosaqu ya algunas ideas:Hay tres factores principales en la motivacin de los desarrolladores:

o Las relaciones humanas y personal adecuado en los equipos. El personalde la empresa no solamente se debe seleccionar por criterios puramentetcnicos, sino tambin humanos. Resulta tan fundamental que los jefesde proyecto sean competentes en el ejercicio de su funcin como quetengan una personalidad adecuada. Por otra parte resulta muyrecomendable buscar no solamente la cualificacin tcnica en losdesarrolladores, sino intentar contratar tambin a buena gente, unequipo que se lleva bien entre s siempre ser mucho ms productivoque un equipo con un ambiente fro o incluso enemistado. El buen estarentre las personas del equipo conllevar casi como efecto secundario unaalta productividad. Es fcil caer en la trampa de contratar a gente nuevapor el plazo de su disponibilidad en vez de contratarla por la aportacinal proyecto durante su tiempo de vida, hay que evitar este error a todacosta.

o La relacin entre la empresa y su personal. Decisiones aparentementeirracionales, promesas incumplidas y falta de comunicacin sonposiblemente los factores que ms enturbian la relacin de losempleados con la empresa. La empresa debe cuidar la comunicacin consus empleados y procurar que adquieran un poco de cultura de empresa.Si el equipo directivo logra de esta manera la confianza del personal serespetarn incluso aquellas decisiones que puedan parecer irracionales,para ello no es necesario ni operativo explicar cada una de las decisionesestratgicas que toma la empresa, pero s resulta recomendable escogerocasiones puntuales para hacerlo, mantener sesiones peridicas deinformacin sobre el estado de la empresa y conseguir que losdesarrolladores se sensibilicen ante los problemas de gestin y negociode la empresa. Cuanto ms se sientan implicados los desarrolladores con

la empresa, ms se implicarn con sus proyectos.


7/34



o La filosofa de trabajo. Varias estadsticas demuestran que la mayora delos desarrolladores con cierta vocacin ponen por encima de criterioseconmicos lo que les aporta su trabajo, hay dos facetas principales: A)Una forma de trabajo ordenada y participativa en la que cada uno de losmiembros se sienta partcipe. B) El desarrollo personal de cadatrabajador.Una gestin descontrolada del trabajo supone objetivos cambiantesconstantes, estrs, falta de sensacin de xito y con ello frustracin.Deteriora la moral de las personas y por tanto la calidad de su trabajoculminando en que tarde o temprano la persona se ir de la empresa.Esta situacin se produce por una combinacin de factores compleja yque se examinan uno a uno en los siguientes puntos del presentedocumento, limitmonos por ahora a decir, que una forma de trabajodesordenada es sencillamente, inadmisible.En cuanto al desarrollo personal resulta importante establecer unagestin en la que se den facilidades a cada empleado. Aqu no solamentecuentan las medidas costosas al alcance de las grandes compaas comoplanes de formacin, etc. sino que pueden ser incluso mucho mseficaces medidas ms creativas como institucionalizar simplementeun tiempo diario de investigacin para cada desarrollador, la organizacinde eventos de intercambio de know-how entre los proyectos (workshopsinternos), animar a que se redacten artculos especficos sobreexperiencias concretas en proyectos o nuevas tecnologas, tanto a nivelde gestin como tecnolgico, sern una valiosa aportacin a la gestinde conocimiento de la empresa y adems se puede plantear la posibilidadde publicarlos, etc.

Empleados conflictivos. No gestionar los problemas relacionados con personalproblemtico provoca tambin retrasos en el desarrollo de un proyecto. Es unproblema comn y se ha entendido bien desde que Gerald Weinberg publicPsychology of Computer Programming en 1971. No actuar ante una situacin ases la queja ms frecuente de los miembros de un equipo sobre sus lderes(Larson y LaFasto 1989). La solucin no tiene que pasar necesariamente pormedidas radicales, sino que se debe gestionar con cierta delicadeza, muchasveces se debe a una determinada situacin personal, falta de experiencia quelleva a malinterpretar la forma de actuar de su entorno, etc. Si se consiguenexplorar las razones de fondo del comportamiento de la persona en cuestinmuchas veces hay una solucin que resultar positiva tanto para la(s) persona(s)como para la empresa y que incluso puede fortalecer los vnculos entre ambos.

Herosmos. Algunos desarrolladores piensan que acciones heroicas puedenaportar alguna clase de beneficio al proyecto (Bach 1995). Pero las experienciasdemuestran que ms bien son actitudes negativas para la gestin fiable de unproyecto puesto que problemas potenciales no se comunican hasta el ltimominuto distorsionando as el seguimiento del proyecto y se tiende a asumirriesgos demasiado altos. Este error es tambin muy seductor porque paramuchos jefes de proyecto resulta tranquilizador que su equipo les transmitamensajes del tipo lo podemos hacer, el jefe de proyecto se limita a creerlo ydormir ms tranquilo, pero realmente est obviando la realidad y aplazandoenfrentarse a una problemtica que se agravar con el tiempo.


8/34



Aadir personal a un proyecto retrasado. Este es, sin duda, el fallo clsicoms clsico. Y es que el factor humano no escala fcilmente, generalmenteaadir gente a un equipo existente que se encuentra retrasado lo retrasa anms puesto que genera mucho trabajo de coordinacin adicional, adems elequipo no cuenta en ese momento con la calma necesaria para dar a laspersonas nuevas la formacin que necesitan del proyecto, con lo cual sta irlenta.

Al final, la combinacin de ms canales de comunicacin y necesidad deformacin hace que los nuevos miembros del equipo le restan ms tiempo deproductividad al proyecto del que aaden y generan as retrasos an mayores.

Aunque de todas las maneras hay que hacer notar que esto dependeevidentemente del perfil de cada proyecto, hay proyectos en los cuales s resultaeficaz introducir ms personal ante retrasos por requerir ste solamente unaforma mnima o poder tener una estructura de mdulos muy independientes. Loque resulta importante es comprender es que aadir ms gente a un proyecto noes ni mucho menos una frmula mgica para resolver problemas de calendario,sino que hay una muy alta probabilidad de que sea todo lo contrario.

Oficinas ruidosas y faltas de espacio. La mayora de los desarrolladoresvaloran sus condiciones de trabajo como insatisfactorias, aproximadamente el60% se queja adems de que no hay suficiente silencio ni suficiente intimidad(DeMarco y Lister 1987). Trabajadores que desarrollan su actividad en oficinassilenciosas y con espacio tienden a ser ms notablemente ms eficientes queaquellos que trabajan en condiciones de ruido y falta de espacio.

Friccin entre desarrolladores y clientes. Fricciones entre desarrolladores yclientes pueden surgir de varias maneras. Los clientes opinan que losdesarrolladores no cooperan cuando rechazan el calendario exigido por ellos ocuando no entregan en los tiempos prometidos. Los desarrolladores piensan quelos clientes insisten irracionalmente en calendarios irrealistas y cambios derequisitos imposibles despus de que stos hayan sido cerrados, laspersonalidades de ambos grupos pueden empeorar el conflicto an ms. Laconsecuencia principal es una comunicacin pobre y por tanto una comprensinpobre de los requerimientos, junto con interfaces de usuario poco adecuados alas necesidades del cliente. Resulta difcil superar esta friccin por lo que hay quemonitorizar este riesgo desde el principio detenidamente y emplear personal con

mano izquierda que sepa resolver los conflictos y restaurar una comunicacineficaz.

Expectativas irrealistas. Una de los causas ms frecuentes de friccin entredesarrolladores y clientes o gestores son expectativas irrealistas. Sensibilizar alcliente no es un proceso trivial y requiere tambin una postura suficientementerazonable de su parte. Una va de compromiso ante plazos que al cliente leparecen excesivos puede ser una cuidadosa negociacin de los requisitos. Si sesabe negociar bien se encontrarn en la mayor parte de los casos requisitos quepara el cliente resultan relativamente poco importantes pero s suponen unahorro de desarrollo que merece la pena. Otra va puede ser una planificacinorientada a prototipos o entregas sucesivas de mdulos que adelantenfuncionalidad importante aunque la versin completa se entregue en los plazosiniciales o incluso algo ms tarde. Con este tipo de medidas posiblemente sepuedan acercar posiciones en un principio alejadas.

Ausencia de apoyo efectivo de la direccin. Todos los principios para lagestin exitosa de proyectos valen de poco si no son apoyados por la direccinde la empresa y sta se deja llevar excesivamente por la presin de sus clientesforzando a los equipos a aceptar planificaciones irrealistas, etc. Segn elconsultor australiano Rob Thomsett esta falta de apoyo prcticamente garantizael fracaso de un proyecto con cierto grado de ambicin (Thomsett 1995).


9/34



Compromiso insuficiente de los participantes en el proyecto. Todos losparticipantes en un esfuerzo de desarrollo de software tienen que estarfuertemente comprometidos con el proyecto, tanto del lado del cliente como dellado del la empresa desarrolladora. Compromiso quiere decir fundamentalmentededicar el tiempo y la profundidad necesaria a las tareas que correspondan acada uno. Esto incluye tanto a los ejecutivos, como miembros del equipo dedesarrollo, interlocutores del clientes, usuarios finales y cualquiera que seencuentre relacionado con el proyecto. Solamente de esta manera ser posibleuna buena coordinacin y capacidad de maniobra ante problemas.

Falta del input de usuario. Resulta muy difcil para los no informticosimaginar hasta qu punto se necesita el detalle de los procesos paraimplementarlos bien. TODOS los clientes tienden a quedarse muy en la superficiede los requerimientos, si los responsables del desarrollo lo admiten, esto setraduce normalmente en desarrollos que estn lejos de cubrir las necesidades delcliente y con ello en retrasos para lograrlo, lo que a su vez provoca cdigo

sucio por los frecuentes cambios, mucho ms difcil de mantener y evolucionar.Por otra parte resulta difcil para los desarrolladores imaginar hasta qu punto losusuarios se quedan en la superficie, ya que muchos requisitos que para ellosresultan evidentes los usuarios ni son capaces de imaginrselos y viceversa3.Debe tenerse en cuenta este dato: la Standish Group concluy que la raznprincipal por la que los proyectos de software concluyen con xito es por laparticipacin comprometida de los usuarios.

Demasiados interlocutores o interlocutores ineficaces. Normalmente seda este problema ms de parte del cliente debido a que la participacin en elproyecto para l supone una actividad con la que debe compaginar su trabajodiario, normalmente los responsables del lado del cliente prometen que laspersonas designadas se podrn alejar de su responsabilidad habitual paracentrarse en el proyecto, pero en la realidad pocas veces se cumple, al finaltienen que abordar todo su trabajo habitual ms el trabajo del proyecto. Elproyecto muchas veces se convierte en la segunda prioridad porque ante suempresa se les valora por su trabajo habitual, esto sencillamente resulta nefastopara cualquier proyecto. Otra faceta en la comunicacin es el nmero deinterlocutores, debera ser mnimo, con reas de responsabilidad muy biendefinidas y acotadas y con una dedicacin plena. Aunque esto es difcil deconseguir resulta muy recomendable presionar al mximo al cliente paraacercarse lo ms posible a este ideal, el cliente lo agradecer cuando el proyectose haya realizado con xito.

3 Steve McConell pone un ejemplo muy ilustrativo de la distancia que separa los puntos de vista de usuarios ydesarrolladores: propone que el lector se imagine un cliente experto en coches (pero no en ingeniera) que debeespecificar la construccin de un coche a medida a un ingeniero que no es un especialista en la construccin de cochesporque construye igualmente aviones, barcos, etc. El cliente hablar del motor, chasis, lunas, volante, etc. Peroimaginemos que se le olvid especificar que al dar marcha atrs se deben encender unas luces blancas en la partetrasera del coche (algo evidente para l).

El ingeniero va hacer su trabajo y vuelve a los seis meses, cuando el experto ve el coche exclama Vaya, me heolvidado especificar las luces de marcha atrs. El ingeniero se lleva las manos a la cabeza: sabe usted lo que va acostar hacer esta modificacin? Tenemos que redisear la parte posterior del coche para incluir los faros nuevos,

modificar la circuitera electrnica e incluir un sensor en el cambio! Esto llevar semanas como mnimo. Porqu no melo ha dicho antes? El experto se resigna: Pareca una peticin tan sencilla...


10/34



Intereses polticos. Este punto se refiere tanto a conflictos de interesesentre los participantes en el proyecto, tpicamente departamentos o responsablescon malas relaciones, como miembros del proyectos cuyas pautas de actuacinderivan ms de la imagen hacia sus jefes y situacin coyuntural que los interesesdel proyecto o la empresa. Esta problemtica resulta habitualmente invisible paralos cargos ms altos, debida a su falta general de tiempo que les hace recibirpoca informacin la cual adems fcilmente desvirta la realidad (o puede serdesvirtuada intencionadamente). Sin embargo, es interesante observar que latasa de xito de las estrategias trepa es considerablemente inferior de lo quecomnmente se piensa (Constantine 1995a).

Wishful thinking. Esto es bsicamente el fenmeno de ponerse la venda enlos ojos ante la voluntad que querer cumplir de cualquier manera undeterminado objetivo por imposible que sea, pero no hay que confundirlo conoptimismo, el optimismo de por s es sano para un proyecto! Cuantas veces sehabrn escuchado frases como estas:

o Ninguno de los miembros del equipo realmente aceptada los plazos del

proyecto, pero pensaron que trabajando duro y si las cosas salan bien,podran ser capaces de sacarlo adelante.o No ha hecho falta coordinar mucho los interfaces entre los mdulos del

producto, hemos estado hablando bastante y son relativamente simples,as que no debera haber muchos problemas en la integracin.

o Al final hemos tenido que subcontratar un equipo de menor cualificacinde lo especificado para el mdulo de acceso a base de datos, pero songente joven y muy motivados, seguro que lo sacan adelante a tiempo.

o No hace falta ensear al cliente los ltimos cambios al prototipo, ya leconocemos bien y le encantar como haremos la versin final.

o El equipo dice que va hacer un esfuerzo extraordinario para cumplir el

plazo, se retrasaron en el primer hito el otro da, pero yo creo que a esono hay que darle mucha importancia.o ...

Este fenmeno es muy frecuente y extremadamente peligroso, resulta frecuentetanto del lado del cliente que tiende a ignorar las valoraciones de los tcnicospensando que ya habr una manera de hacer lo que necesita en el plazo quenecesita como del lado de los desarrolladores que se ponen a trabajar duro paraalcanzar como sea la fecha lmite sin plantearse si es posible.

Confianza ciega en referencias establecidas. Esto es bsicamente elfenmeno de confiar hasta tal punto en grandes nombres que no se contrasta lacualificacin que ofrecen. Es decir, contratar el equipo de una gran marca por sisolo no implica en absoluto una garanta de calidad, hay que contrastar siemprela calidad del equipo que aportan.

ERRORES RELACIONADOS CON EL PROCESO Planificacin excesivamente optimista. Una planificacin excesivamente

optimista impide una planificacin eficiente y genera presiones que acabandegradando al equipo y proyecto en la mayora de los casos. Una facetaposiblemente peor an de una planificacin excesivamente optimista es que nosolamente no se llega a tiempo a los objetivos, sino que la dinmica en la queentra un proyecto en estas condiciones por la presin del tiempo hace que laproductividad del trabajo sea sensiblemente menor que en un proyectocorrectamente planificado.


11/34



Gestin de riesgos insuficiente. Resulta muy fcil llegar a un punto en el cualno queda capacidad de maniobra si se detecta que el proyecto va mal cuando nohay una gestin de riesgos activa. Este hecho es especialmente relevante si setiene en cuenta que muchas veces un solo factor de los aqu expuestos puededegradar el proyecto por completo.

Fallos debidos a la subcontratacin. A veces se subcontratan partes de unproyecto que por presiones del calendario y falta de personal especializado. Perolas empresas subcontratadas con frecuencia entregan el trabajo tarde, con unnivel de calidad inaceptable o no conforme a los requisitos (Boehm 1989).

Abandonar la planificacin ante la presin del tiempo. El problema no estanto el abandono de la planificacin en s como el hecho de que casi todos losequipos de desarrollo caen en la trampa psicolgica de entrar en el code-and-fix (programar y arreglar a toda velocidad sin demasiada meditacin) antepresiones de tiempo altas. El trabajo a partir de ese punto se convierte endescoordinado y ms ineficiente que antes.

Prdida de tiempo en la fase preparativa de un proyecto. La fasepreparativa de un proyecto es el tiempo que transcurre entre su aprobacin y supresupuestado. No es raro que este proceso dure meses, a veces incluso aos yluego plantee, sin embargo, una planificacin de la ejecucin del proyecto muyagresiva. Es mucho menos arriesgado acortar la fase preparativa y disponer detiempo para la ejecucin.

Plantear demasiados objetivos a la vez. Este error es otro de los muyfrecuentes, tanto a nivel microscpico como macroscpico. El punto de vistamicroscpico se refiere al da a da de la gestin del proyecto, es decir, losobjetivos a corto plazo que el jefe de proyecto va planteando al equipo. Planteardemasiados objetivos en paralelo es uno de los factores que en mayor medidaimpiden que un equipo trabaje de forma efectiva. El punto de vista macroscpicose refiere a los objetivos que se plantean para el producto, vase el punto

Plantear demasiados objetivos a la vez de la seccin de errores relacionadoscon el producto. Cortar actividades fundamentales ante un retraso. En muchos proyectos

acciones de recorte de actividades han sido, por ejemplo, no dedicar el tiemponecesario a la especificacin de requisitos, anlisis y diseo. Recortar actividadesfundamentales como stas desde luego empeora con garantas an ms lasituacin.

Diseo inadecuado. Este es un caso particular del punto anterior, peroespecialmente delicado por el alto grado de creatividad y por tanto de ciertacalma que requiere para ser realizado con xito. Muchas veces la presinconvierte las decisiones de diseo en decisiones oportunistas frente a lasnecesidades del momento que provocan la necesidad de uno o ms rediseos delsistema antes de entregar el proyecto. Finalmente los rediseos suman mstiempo del que hubiese requerido un diseo bueno desde el principio.

Control de calidad insuficiente. Otro punto tpico de recorte es el control decalidad, es decir, eliminar actividades como la revisin del diseo y el cdigo,planes de pruebas, etc. Estudios demuestran que recortar un da de actividadesQA (Quality Assurance) en las fases tempranas de un proyecto es probable quecueste entre 3 a 10 das de actividad posterior (Jones1994). Es decir, al final sealarga el proyecto.


12/34



Control de gestin insuficiente. Es importante llevar a cabo un control de laevolucin del desarrollo para ver si los hitos planteados se van cumpliendo ydiagnosticar las causas de los posibles problemas puesto que esto permitereaccionar a tiempo y tomar decisiones razonables dentro de la situacin delproyecto.

Convergencia prematura. Poco antes del momento planificado para la entregade un producto, hay una fase frentica para pulir la velocidad, la documentacinfinal, incorporar ayuda en lnea, rematar el programa de instalacin, etc. Enproyectos bajo presin existe la tendencia de entrar en esta fase demasiadopronto, lo que repercute en repetirla media docena o ms de veces hasta querealmente se concluye.

Omitir tareas necesarias de las estimaciones. En todos los proyectos hayun alto porcentaje de tareas y requisitos poco evidentes, pero necesarios. Aquentran puntos como tiempos de respuesta del sistema, determinados aspectosergonmicos del interfaz de usuario, procesos secundarios (como backups)derivados de los procesos especificados, etc. Su omisin se penaliza

frecuentemente con desviaciones entre un 20% y un 30% sobre el tiempo totaldel proyecto. Planificar para recuperar retrasos dentro de la planificacin inicial. Una

manera muy frecuente de corregir estimaciones ante un retraso frente a un hitodeterminado es planificar una compensacin posterior sin alterar los tiemposglobales del proyecto. Es decir, cuando sobre un proyecto de 6 meses se llega alhito del mes 2 en el mes 3 es habitual decir ya lo recuperaremos en lo quequeda de proyecto, tenemos an 3 meses por delante y ya sabemos ms delproyecto. Aunque es cierto que la productividad de por s crece conforme seconoce mejor al producto desarrollado, la mayora de los proyectos no recuperannunca de esta manera sus retrasos iniciales.

Programacin code-like-hell. Algunas compaas creen que unacodificacin rpida con gente motivada es lo que hace falta realmente parafinalizar los proyectos en el menor tiempo y que de esa manera se superacualquier obstculo. Los riesgos expuestos en este captulo y sus razonamientosdeberan dejar claro que estn muy equivocados. Recientemente han aparecidopropuestas como el Extreme Programming (XP) que no se deben confundir conen esta filosofa.

ERRORES RELACIONADOS CON EL PRODUCTO Exceso en los requerimientos. Muchos proyectos tienden a incluir ms

requerimientos de los que realmente necesitan, requisitos complejos aadentiempos de desarrollo desproporcionados con respecto a los requisitosfundamentales. Luego hay analizar muy bien cuales quiere realmente el clientepara su negocio y priorizarlos correctamente.

Plantear demasiados objetivos a la vez. Relacionado con el producto serefiere al nivel macroscpico, es decir, a los objetivos globales del proyecto delproyecto. Pedir que un proyecto justo en plazos sea adems ptimo en el uso dela memoria, ptimo en velocidad de respuesta, ptimo en facilidad de uso ytenga una legibilidad del cdigo perfecta ser un conjunto de objetivosprcticamente imposible de alcanzar. Asumir un consumo relativamente elevadode memoria (es un recurso muy barato hoy en da) a cambio de una mximavelocidad de respuesta, junto con una facilidad de uso buena (si el perfil deusuarios lo permite) y una legibilidad de cdigo aceptable puede ser una sabiarectificacin en virtud del xito del proyecto y producir una calidad del resultadoprcticamente similar.


13/34



Requerimientos inestables. El enemigo ms feroz de la calidad del productoes el constante cambio de los requerimientos puesto que hacen sencillamenteimposible un buen diseo, de hecho es uno de los factores principales en elfracaso de los proyectos. Es muy importante concienciar al usuario de esto, hade tenerse en cuenta que la informtica es una ingeniera de tecnologa puntera,con un alto grado de dificultad que requiere diseos cuidadosos.

Desarrollo no centrado en los objetivos del proyecto por parte demiembros del equipo de desarrollo. Muchos programadores tienden afascinarse con los nuevos avances tecnolgicos y con la implementacin de

virgueras, tanto por disfrute personal como por la ambicin de superar ciertosretos. Esta tendencia tiene que ser controlada porque puede degenerar en unaprdida de tiempo importante, aunque tambin se debe respetar algo de libertadpara mantener la motivacin a un buen nivel. Aqu el criterio personal del jefe deproyecto es la clave.

Negociacin tira y afloja. Un tipo de negociacin estrafalaria sucede cuandoun responsable que aprueba un retraso en la planificacin de un proyecto que

transcurre ms lento de lo esperado aade a la vez tareas completamentenuevas despus de la aprobacin de los nuevos plazos. Muchas veces haymotivos psicolgicos de presin ante superiores que hacen que el responsable sesienta forzado a compensar el retraso con ms funcionalidad (muchas vecespoco til, adems), pero este alivio a corto plazo es traidor porque realmentecontribuir a alargar el proyecto an ms y el enfrentamiento con sus superioresser peor.

Desarrollo orientado a investigacin. El estar en la cresta de la tecnologaconvierte la planificacin en pura especulacin, hay que encontrar el puntointermedio ptimo entre los beneficios de las nuevas tecnologas y las reas deaplicacin de stas en el desarrollo. En este sentido un apoyo I+D externo alproyecto es de gran utilidad, ya que con su ayuda se podr calibrar la fiabilidad y

potencial de mejora de la nueva tecnologa y decidir as con criterio si la relacinentre beneficio y riesgo hace recomendable utilizarla o no en un determinadoproyecto.

ERRORES RELACIONADOS CON LA TECNOLOGA El sndrome de la panacea. La creencia ciega en tecnologa y herramientas

que no han sido probadas y se consideran la solucin mgica a todos losproblemas, la tendencia a esto es elevada en muchas personas.

Ahorros sobreestimadas por herramientas o mtodos nuevos. Losbeneficios de nuevas herramientas o mtodos de trabajo se ven anulados acorto/medio plazo por la curva de aprendizaje que supone su dominio correcto.Eso hace difcil que dentro de un proyecto se consigan resultados espectaculares,sobre todo, teniendo en cuenta que el tiempo disponible para aprendizaje setiende a minimizar. Por otra parte el uso de nuevas herramientas o mtodosimplica nuevos riesgos que solamente se descubren con el tiempo.

Cambio de herramientas en medio del proyecto. Resulta muy arriesgadocambiar la herramientas de desarrollo durante el proyecto puesto que los fallosen su uso y una curva de aprendizaje ms costosa de lo esperado pueden anularfcilmente lo beneficios esperados e incluso descompensarlos. El entornotecnolgico ha de ser escogido con calma antes del proyecto y ser mantenidodurante su realizacin.


14/34



Ausencia de sistemas de control de versiones de cdigo fuente. Esto esbsico, pero desgraciadamente resulta increblemente frecuente que sedestruyan partes importantes de cdigo y recursos por la ausencia de sistemasde control de versiones y backup.

CONCLUSIONES Desarrollar productos software es una tarea complicada. Concebir un sistema de

informacin complejo ya es de por s un reto, si unimos este hecho a que por lo general latecnologa empleada es muy sofisticada (y ms hoy en da) queda claro que solamente sepuede afrontar con xito si se gestiona con cuidado y los medios de ingeniera adecuados.

En los prrafos anteriores hemos relacionado los errores ms comunes y msimportantes, pero hay muchos ms. Resulta muy recomendable actualizar esta listacontinuamente con los errores que se detecten en cada uno de los proyectos abordados.

Resumen de los errores clsicos

Factor humano Proceso Producto Tecnologa1. Motivacin insuficiente 1. Planificacin

excesivamente optimista1. Exceso en losrequerimientos

1. El sndrome de lapanacea

2. Empleados conflictivos 2. Gestin de riesgosinsuficiente

2. Plantear demasiadosobjetivos a la vez

2. Ahorros sobreestimadospor herramientas o mtodosnuevos

3. Herosmos 3. Fallos debidos a lasubcontratacin

3. Requerimientosinestables

3. Cambio de herramientasen medio del proyecto

4. Aadir personal a unproyecto retrasado

4. Abandonar laplanificacin ante la presindel tiempo

4. Desarrollo no centrado enlos objetivos del proyectopor parte de miembros delequipo de desarrollo

4. Ausencia de sistemas decontrol de versiones decdigo fuente

5. Oficinas ruidosas y faltasde espacio

5. Prdida de tiempo en lafase preparativa de unproyecto

5. Negociacin tira y afloja

6. Friccin entredesarrolladores y clientes

6. Cortar actividadesfundamentales ante unretraso

6. Desarrollo orientado ainvestigacin

7. Expectativas irrealistas 7. Plantear demasiadosobjetivos a la vez

8. Ausencia de apoyoefectivo de la direccin

8. Diseo inadecuado

9. Compromiso insuficientede los participantes en elproyecto

9. Control de calidadinsuficiente

10. Falta de input deusuario

10. Control de gestininsuficiente

11. Demasiadosinterlocutores ointerlocutores ineficaces

11. Convergenciaprematura

12. Intereses polticos 12. Omitir tareas necesariasde las estimaciones

13. Wishful thinking 13. Planificar para recuperarretrasos dentro de laplanificacin inicial

14. Confianza ciega enreferencias establecidas

14. Programacin code-like-hell


15/34

Motivacin


MOTIVACIN

Dentro de las reas que hemos identificado anteriormente con relacin a los errores quese pueden cometer en un proyecto de desarrollo, el factor humano tiene el mayor potencialpara acelerar un proyecto si se gestiona adecuadamente. Gestionar aqu no significa presionar,sino encontrar los factores que hagan que los desarrolladores alcancen su mximo nivel deproductividad y que lo hagan a gusto, en definitiva: encontrar la forma de motivarlos al mximoy mantener ese alto nivel de motivacin de una forma continuada.

La motivacin es sin lugar a dudas el factor ms importante con diferencia en cuanto a laproductividad de las personas, son muchos los estudios que avalan esta afirmacin (Boehm1981).

La trascendencia de este factor queda clara desde la siguiente perspectiva: Variosinvestigadores han identificado en sus estudios diferencias de productividad entredesarrolladores con la misma experiencia en rdenes de magnitud entre 1 y 10, e inclusomayores en casos determinados (Sackman, Erikson, y Grant 1968; Curtis 1981; Mills 1983;DeMarco y Lister 1985; Curtis et al. 1986; Card 1987; Valet y McGarry 1989).

Aunque estas cifras pueden parecer extremas cualquiera con algo de experiencia en laindustria del software sabe que las diferencias entre desarrolladores malos, mediocres ybrillantes son muy elevadas. No se producen tanto por diferencias en inteligencia o talento(aunque estos son indudablemente dos factores de mucho peso), sino mucho ms por laactitud de trabajo: mantenerse al da o no con la evolucin tecnolgica, conformarse con laprimera solucin que se encuentra ante un problema o tener la voluntad de investigar unproblema a fondo y encontrar la solucin ms adecuada, disear pensando en resolverexclusivamente los problemas del corto plazo o proyectar una solucin teniendo en mente laproblemtica futura de las siguientes etapas del proyecto, etc., etc., etc. en definitiva: trabajarcon ganas o no.

Es precisamente el potencial de efecto palanca que las soluciones tecnolgicas ptimastienen sobre los tiempos de desarrollo el que marca estas diferencias tan pronunciadas entre laproductividad de los desarrolladores, por eso es clave conseguir que los desarrolladores tenganla voluntad de conseguir resultados ptimos y para ello deben estar motivados. Ni falta hacedecir que la desmesura en este punto tampoco es buena, volveramos al error que identificamoscon respecto a la tendencia de crear virgueras y no centrarse realmente en los objetivos delproyecto.

F ACTORES DEMOTIVACIN TPICOS EN DESARROLLADORES Para encontrar la manera de motivar a un determinado tipo de personalidad es

importante hacerse primero una idea de sus rasgos ms relevantes, en este sentido soninteresantes datos como los obtenidos en el test Myers-Briggs Type Indicator (MBTI). Estetest divide la personalidad de un profesional en cuatro dimensiones:

! Extrovertido (E) o introvertido (I)! Sensitivo (S) o intuitivo (N)! Pensativo (T) o impulsivo (F)! Juzgador (J) o perceptivo (P)

De aqu salen 16 combinaciones de cuatro letras, lo que significa que se consideran 16tipos de personalidad.


16/34

Motivacin


Resulta curioso con qu claridad se identifica una personalidad tpica de desarrollador,la cual se caracteriza por los siguientes rasgos:

! Aproximadamente el 50-66% de los desarrolladores son introvertidos frente a un25-33% de la poblacin general. Es decir los desarrolladores tienden en general

hacia su interior, el mundo de las ideas, su desarrollo personal, dan menosimportancia a cuestiones exteriores como la imagen, status, etc.! El 80% de los profesionales informticos tienden a un perfil reflexivo frente al

50% de la poblacin general. Es decir, tienen una clara preferencia hacia la tomade decisiones basadas en la lgica y razonamientos claros y no tanto en valoressubjetivos o emocionales.

! En consonancia con este hecho est la preferencia por juzgar (66%) frente apercibir, es decir, los desarrolladores tienden a vivir de una manera ordenada yplanificada cuando los perfiles perceptivos tienen a adaptarse ms a lascircunstancias de cada momento.

Para ver un ejemplo de cmo se deben tener en cuenta estos rasgos de personalidadbasta con plantear la forma de actuar ante la frecuente situacin de retos ambiciosos en unproyecto: ms vale utilizar argumentos lgicos y crebles para motivar a los desarrolladores queutilizar frmulas emotivas, sin argumentos convincentes. Raramente un grupo dedesarrolladores responder positivamente a objetivos imposibles.

A continuacin aportamos una tabla con unos datos ms detallados4, aunque estos datosya tienen ms de 20 aos y dependen tambin de circunstancias coyunturales como la situacineconmica, etc., siguen siendo muy vlidos y merece la pena tenerlos en cuenta a la hora degestionar equipos de desarrollo.

Concluyendo podemos afirmar que:! Comparado con la poblacin en general, a los desarrolladores les motivamucho

ms la posibilidad de desarrollo personal, vida privada, oportunidad desupervisin tcnica, y relacin personal con sus compaeros.Les motivan menos factores de status, relacin personal con subordinados,responsabilidad y reconocimiento.

! Comparados con sus gestores, a los desarrolladores les motivaalgo ms laposibilidad de desarrollo personal, vida privada, y oportunidades de supervisintcnica. Les motivan menos factores de status, relacin personal consubordinados, responsabilidad y reconocimiento.

Esta ltima comparacin entre desarrolladores gestores y tcnicos resulta especialmenteinteresante ya que indica que los gestoresno deben motivar a su equipo con los criterios queaplicaran a si mismos. El hecho de la responsabilidad en si misma que para un gestor es elfactor fundamental, para un desarrollador tiene poco peso frente la posibilidad de enfrentarse a

retos tcnicos, evolucionar en conocimientos, tomar su propias decisiones dentro de su rea ensu trabajo, etc.

4 Fuente: Software Engineering Economics (Boehm 1981) y Who is the DP Profesional? (Fitz-enz 1978).


17/34

Motivacin


Veamos ahora los datos en detalle:

Analista programador Jefe de proyecto Poblacin general1. Lograr objetivos 1. Responsabilidad 1. Lograr objetivos

2. Posibilidad de desarrolloprofesional

2. Realizacin personal 2. Reconocimiento

3. El contenido del trabajo 3. El contenido del trabajo 3. El contenido del trabajo

4. Vida privada 4. Reconocimiento 4. Responsabilidad

5. Oportunidad de supervisin tcnica 5. Posibilidad de desarrolloprofesional

5. Progreso

6. Progreso 6. Relaciones interpersonales consubordinados

6. Salario

7. Relaciones interpersonales concompaeros


7. Posibilidad de desarrollo personal

8. Reconocimiento 8. Progreso 8. Relaciones interpersonales consubordinados

9. Salario 9. Salario 9. Status

10. Responsabilidad 10. Relaciones interpersonales consuperiores

10. Relaciones interpersonales consuperiores

11. Relaciones interpersonales consuperiores

11. Polticas corporativas y deadministracin


12. Seguridad laboral 12. Seguridad laboral 12. Oportunidad de supervisintcnica

13. Relaciones interpersonales consubordinados

13. Oportunidad de supervisintcnica



14. Status 14. Condiciones de trabajo

15. Condiciones de trabajo 15. Vida privada 15. Vida privada

16. Status 16. Condiciones de trabajo 16. Seguridad laboral

LOS CINCO FACTORES DE MOTIVACIN MAS IMPORTANTES Trabajar en los cinco factores principales de motivacin puede ser de gran ayuda para

lograr acercarse ms al deseable factor 10 de rendimiento, se trata de crear un ambiente detrabajo en el cual los desarrolladores puedan realizar sus inquietudes. Cuando las personasdisfrutan, ellos mismos se comprometern y responsabilizarn de cumplir los objetivos detrabajo, y si es necesario echar horas extra, lo harn sin mayores inconvenientes.

Lograr objetivosLos desarrolladores de software disfrutan generalmente de su profesin. Por tanto, la

mejor motivacin para ellos es proporcionarles un entorno de trabajo que les permita hacer loque ms les gusta: desarrollar software.Un pilar fundamental para que los desarrolladores se encuentren motivados para lograr

sus objetivos es hacer que se sientan plenamente partcipes del proyecto, para ello resultafundamental que desde el principio se impliquen en las decisiones como lo son la depuracin delos objetivos y la planificacin de los plazos. Que los desarrolladores participen en estasactividades hace que los resultados sean sensiblemente ms realistas, al fin y al cabo hay queasumir que ellos tendrn en la mayora de los casos un mejor criterio que los gestores paraestimar los esfuerzos que les suponen unas tareas concretas.

El efecto psicolgico del hecho de participar de esta manera es enormemente beneficiosopara su motivacin, son ellos quienes se comprometen a lograr los plazos y objetivos con locual se sentirn de verdad partcipes y comprometidos con el proyecto, ser realmente suproyecto y saldr de ellos hacer todo lo que est en su poder para cumplir con su palabra.


18/34

Motivacin


Un argumento en contra de esta estrategia puede ser que los desarrolladores tendern aaprovechar su participacin para lograr unos plazos y objetivos lo ms cmodos posibles, peroafortunadamente la experiencia demuestra que esto no es as, algo que resulta lgico sirecordamos que el perfil tpico del profesional del desarrollo es un perfil al que le gusta sutrabajo y alcanzar metas ambiciosas. De hecho, los desarrolladores tienden ms bien a estimarplazos y objetivos excesivamente ambiciosos, un buen jefe de proyecto deber incluso tomarlosen este sentido con cierta cautela.

Los objetivos que se plantean deben ser claros y no excesivos en nmero, estdemostrado que cuando se definen claramente los principales objetivos/prioridades de unproyecto y estos no son excesivos en el nmero, hay muy buenas posibilidades de lograrlos. Lacuestin no est tanto en el nmero en s de objetivos, aunque evidentemente tambin debetender a ser pequeo, sino en que estos se puedan compaginar, vanse los puntos Planteardemasiados objetivos a la vez en el captulo anterior.

Posibilidad de desarrollo profesionalPosiblemente la faceta ms atractiva del desarrollo de software es el gran dinamismo del

campo, es decir, hay que aprender y avanzar constantemente para mantenerse al da, no esmuy sorprendente que las personas que hayan decidido trabajar en una profesin de estascaractersticas pongan peso en la faceta de las posibilidades de desarrollo profesional que lesofrece 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 creacin de una buena biblioteca tcnica Asignar los desarrolladores a proyectos que amplen sus conocimientos tcnicos Asignar a desarrolladores individuales o a grupos tareas de I+D para fines

concretos (probar una nueva tecnologa para la encriptacin de datos, seleccinde un nuevo entorno de desarrollo, etc.) Asignar mentores a cada nuevo desarrollador (lo cual demuestra a ambos que la

compaa se compromete con el desarrollo profesional de sus empleados) Evitar excesiva presin de calendarios para que haya un mnimo tiempo que se

pueda dedicar a actividades como las mencionadas anteriormente Mantener una buena comunicacin para monitorizar la consecucin de los

objetivos profesionales de cada desarrollador

El contenido del trabajo

Segn Richard Hackman y Greg Oldham (Hackman y Oldman 1980), la motivacin de losprofesionales procede de tres fuentes principales: Que encuentren sentido en el trabajo que estn 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 estasfuentes de motivacin:


19/34

Motivacin


Variedad de conocimientos aplicados. Se refiere a la variedad de conocimientoque han de aplicarse en la ejecucin de una tarea. Las personas encuentran mssentido en las tareas que exigen una variedad de conocimientos ms amplia,incluso en tareas que no son muy importantes. Adems el trabajo resulta msdivertido de esta manera.

Identidad de la tarea. Se refiere hasta qu punto la tarea requiere abordar untrabajo por completo. Las personas se responsabilizan ms de su trabajo cuandoperciben el trabajo como suyo o no se sienten solamente contribuidores a untrabajo en comn.

Importancia de la tarea. Es importante que el trabajo realizado se perciba comola creacin de valor, como dicen Hackman y Oldham: los trabajadores queaprietan tuercas en un Boeing perciben su trabajo ms importante que los queaprietan tuercas en un escaparate comercial.

Autonoma. Este aspecto se refiere al grado de control del que se disfruta alrealizar el trabajo, la sensacin de ser su propio jefe dentro de su rea deresponsabilidad. Cuanto mayor sea esta sensacin ms responsabilidad se asumeen el trabajo.

Realimentacin del trabajo. La realimentacin del trabajo realizado es otro factorde motivacin importante ya que aporta informacin directa de la efectividad dela persona que lo ha realizado. Es importante resaltar que no se trata tanto delos comentarios recibidos de un supervisor, sino lo que el trabajador ve por simismo, el caso de un desarrollador de software es especialmente claro, ya quelos programas creados proveen una realimentacin inmediata cuando seejecutan.

Vida privadaEl respeto hacia la vida privada, es decir, el impacto de las jornadas laborales y el nivel

de estrs sobre sta tienen un peso muy alto para los desarrolladores. Cabe resaltarespecialmente en este punto la diferencia de prioridades entre desarrolladores y jefes deproyectos, la vida privada ocupa el cuarto lugar para los primeros cuando para los ltimosocupa el puesto 15, esto puede provocar ciertos fallos en la gestin de un equipo, por ejemplo:ante una situacin continuada de exceso de trabajo un jefe de proyecto puede pensar que losdesarrolladores le darn poca importancia porque para l la tiene, pero se confunde al suponerque miden las cosas con su mismo criterio.

Lo mismo ocurre con la responsabilidad, ocupa el primer puesto para un jefe deproyecto, pero es de relativamente poca importancia para un desarrollador, por tanto asignaruna alta responsabilidad a un desarrollador le puede parecer al jede de proyecto un premioque concede al desarrollador cuando para este supone quizs en un momento determinado msbien un factor de agobio por restarle tiempo de su vida privada.

Otra conclusin interesante de este hecho es que como medio de compensar las jornadasde trabajo en exceso puede ser ms interesante conceder vacaciones extra quecompensaciones econmicas.

Oportunidad de supervisin tcnicaTener la oportunidad de realizar una supervisin tcnica desde el punto de vista de un

desarrollador supone un avance en el tipo de objetivos que debe lograr ya que ofrece laoportunidad de que sus decisiones tcnicas trasciendan a un nivel mayor que el de susresponsabilidades personales en sus propias tareas. Sin embargo, para un jefe de proyectosupone casi un paso atrs porque esta acostumbrado a una supervisin de mayor nivel y notener que preocuparse de los detalles tcnicos, una supervisin tcnica supone generalmentereducir su mbito de accin y con ello la importancia de la tarea que percibe.


20/34

Motivacin


F ACTORES QUE MATAN LA MOTIVACIN No solamente es importante saber cmo motivar, sino igualmente como no desmotivar.

En ese sentido debemos hacer obligatoriamente una reflexin sobre las prcticas que debemosevitar en nuestra poltica de gestin de personal.

Factores de higieneLos factores de higiene se refieren a aquellas condiciones ambientales que un

trabajador necesita para poder realizar su trabajo de forma efectiva, su ausencia degradaconsiderablemente la motivacin. Para los desarrolladores de software (y en general) estos sonlos principales factores:

Iluminacin y temperatura adecuada Suficiente espacio de mesa y armarios Suficiente silencio para permitir una buena concentracin (incluida la posibilidad

de apagar telfonos) Suficiente intimidad para evitar interrupciones indeseadas Fcil acceso al equipo de oficina (fotocopiadora, fax, etc.) Disponibilidad de material de oficina (papel, bolgrafos, etc.) Acceso sin restricciones al ordenador Equipo informtico razonablemente actualizado Buen soporte ante averas en el equipo informtico Buena calidad de comunicaciones (telfonos, email, Internet, ...) Disponibilidad de las herramientas software necesarias Disponibilidad del hardware necesario (por ejemplo, una impresora de color para

un proyecto en el cual sea importante la impresin en color) Disponibilidad de manuales de referencia y otras publicaciones relevantes Un soporte mnimo de formacin para nuevas herramientas, metodologas, etc. Uso de copias legales de software Flexibilidad horaria razonable (es decir, no se trata de condiciones anrquicas,

sino mrgenes razonables como entrar entre las 8:00 y las 10:00 horas, o que nohaya impedimentos para tomarse ocasionalmente una tarde libre que secompensar en otra ocasin, etc.)

Otros factores importantes Manipulacin de parte de la direccin. A los desarrolladores les gustan las cosasclaras, como se ha visto anteriormente, son especialmente alrgicos a intentos

de engao (dramatizar en exceso la importancia de una fecha lmite, intentar convencer a los desarrolladores de la viabilidad de un plazo claramenteinviable, etc.) o presin irracional con calendarios imposibles. Si no se transmitenrazones claras y no hay una flexibilidad de negociacin mnima (para modificaralgunos requisitos por ejemplo) los desarrolladores percibirn la sensacin deque estas actuaciones como por que s. La cuestin no es tanto si se trata deun intento de engao real o no, sino lo que los desarrolladores perciben. Si nohay una mnima comunicacin con ellos, es fcil que sientan una sensacin deengao incluso cuando hay razones slidas para las decisiones tomadas.


21/34

Motivacin


Presiones excesivas de calendario. Una de las maneras ms efectivas de afrontarun proyecto con una motivacin nula es partir desde el principio de fechas lmiteimposibles. Muy poca gente se motivar ante una situacin semejante a trabajarduro para sacar el proyecto adelante, para estar motivado hace falta una femnima en los objetivos. En el caso del perfil de un desarrollador de nuevo lafaceta de alta racionalidad es la clave: una persona con un fuerte talante racionalser incapaz de creer en la posibilidad de conseguir los objetivos y por tanto, sedesmotiva.

Presiones innecesarias. Una forma especialmente nefasta de gestin ocurrecuando los desarrolladores descubren en el desarrollo de un proyecto con muchapresin que sta no proviene tanto del cliente, sino que ha sido la propiaempresa quien ha generado la presin en un intento de conseguir una ventarpida y que el cliente hubiese estado dispuesto a esperar ms tiempo a pagarms dinero ante la justificacin adecuada de estos esfuerzos.

Falta de apreciacin del esfuerzo de los desarrolladores. Un fenmeno frecuentees la falta de apreciacin ante los esfuerzos de los desarrolladores en un

proyecto, esto se debe al hecho de que tanto para los clientes como para losgestores internos de alto nivel es difcil ver cuanto trabajo se est realizandorealmente. Muchas veces se juzga desde fuera que determinada funcionalidad esfcil cuando en realidad no es as y se insina que los desarrolladores estntrabajando poco o son poco productivos. Pero recordemos que los profesionalesdel desarrollo de software son gente muy con mucha motivacin propia a la queles gusta trabajar en lo suyo, por tanto, acusarles o insinuarles que no seesfuerzan les resultar especialmente desmoralizante.

Direccin tcnica incompetente. Desarrolladores pueden ser motivados por jefesde proyecto tcnicamente incompetentes siempre que estos asuman suslimitaciones tcnicas y limiten sus decisiones a las no puramente tcnicas. Peroun jefe que imponga de forma incompetente decisiones tcnicas se convertir en

la burla del equipo. Un equipo no puede ser motivado por alguien a quien norespeta. No implicar a los desarrolladores en decisiones que les afectan. Un factor

especialmente negativo, tanto para la moral de los desarrolladores como para elfuncionamiento de la empresa es no implicar a estos en decisiones que lesafectan. Esto se da con frecuencia, muchas veces simplemente por motivos de laorganizacin de la empresa y no es solamente un factor de desmotivacin, sinotambin una forma absurda de empeorar la eficacia de la empresa ya que confrecuencia son los desarrolladores quienes poseen los mejores criterios paraestas decisiones. He aqu una lista de cuestiones en las que siempre se deberanimplicar a los desarrolladores si se quiere mantener alta su moral:

o Compromisos y ajustes de calendarios o Compromisos sobre nuevas funcionalidades, modificaciones o recortes. o Contratacin de nuevos miembros para un equipo o Diseo del producto o Bsqueda de soluciones de compromiso ante plazos demasiado elevados,

retrasos, etc. o Cambio o reestructuracin de oficinaso Cambios en las herramientas utilizadas, tanto hardware como software o Compromisos imprevistos a lo largo de la ejecucin de un proyecto, por

ejemplo, un versin prerelease del producto o un prototipo reducido o Cambios organizativos y metodolgicos


22/34

Motivacin


Barreras a la productividad. Un aspecto particularmente positivo del perfil dedesarrollador son sus ganas de trabajar, algo envidiable para los responsables demuchas otras profesiones. Por eso resultan an ms flagrantes aquellos casos enlos cuales los desarrolladores trabajan en entornos en los cuales se encuentrancon constantes trabas para alcanzar una alta productividad, en estos casos esseguro que su motivacin bajar sustancialmente.

Baja calidad. Como personas a las que les gusta trabajar y con buenas dosis decreatividad una gran parte de su autoestima profesional deriva de la calidad desus creaciones, por tanto impedir que los desarrolladores puedan hacer buenosproductos es otro factor muy desmoralizante. Evidentemente no se puedenignorar los condicionantes de la realidad del desarrollo de proyectos, pero comosiempre se trata de una cuestin de mano izquierda para tener la sensibilidad degestionar lo mejor posible esta problemtica en un proyecto. As, si esteproblema se plantea ante problemas de plazos un jefe de proyecto no deberaforzar a los desarrolladores a implementar todas las funcionalidades conalfileres, una alternativa adecuada puede ser buscar con ellos la manera desimplificarlas para que se puedan hacer con un aceptable nivel de calidad ydefender estas propuestas con habilidad ante cliente.

Campaas de motivacin mal enfocadas. Cuidado con las campaas demotivacin que insulten la inteligencia de los desarrolladores, una vez ms hayque insistir en que son muy susceptibles a la falta de lgica y no responden biena estrategias de motivacin puramente emocionales. Es ms efectivo un talantems moderado y realista.


23/34

El ciclo de vida


CICLO DE VIDA DEL PROYECTO

La eleccin del ciclo de vida ms apropiado para un proyecto es una cuestinfundamental en la estrategia con la que se afronta, ya que incide muy decisivamente en lavelocidad con la que se llevar a cabo el proyecto y la satisfaccin que generar al cliente. Elciclo de vida claramente dominante hasta hace relativamente poco era el modelo en cascadadonde existen las fases de recogida de requisitos, anlisis, diseo, codificacin, pruebas ymantenimiento del producto. Todas ellas se ejecutan en secuencia, lo que le ha dado a estetipo de ciclo de vida su nombre.

Sin embargo, la evolucin de la tecnologa y los campos de aplicacin y la altaheterogeneidad que presentan los proyectos hoy en da han creado la necesidad de afrontar losproyectos con ciclos de vida personalizados para el perfil de cada proyecto. Por tanto, sediscutirn las principales alternativas, exponiendo sus ventajas e inconvenientes.

MODELO EN CASCADA El modelo en cascada es el ciclo de vida clsico, su principal caracterstica es la

naturaleza estrictamente secuencial de la ejecucin de sus fases. Al aprobar cada una de ellasse genera la documentacin adecuada que permite comenzar con la siguiente, ante defectosque se detectan en la ejecucin de una fase determinada posiblemente haya necesidad devolver a la fase inmediatamente anterior y corregir/modificar algunos de sus contenidos, peroes algo que debe evitar en la medida de lo posible. Esta naturaleza se explica con el carcterms homogneo de las aplicaciones y la plataforma tecnolgica mucho ms simple de haceunas dcadas (las aplicaciones eran prcticamente siempre aplicaciones de gestin sobre hostcon un nivel de complejidad relativamente simple frente a las actuales).

Este modelo resulta adecuado cuando los requisitos estn bien definidos, son establesdesde el comienzo del proyecto y se dominan las metodologas y herramientas utilizadas en elproyecto, ya que minimiza el tiempo dedicado a cada una de las tareas.

Ventajas! Minimiza las tareas de desarrollo repetidas y por tanto el esfuerzo de desarrollo

invertido en total! Minimiza la carga de planificacin de los ciclos iterativos de otros ciclos de vida! Permite afrontar la complejidad de proyectos grandes de una manera muy

ordenada y aumenta as las posibilidades de xito! Ayuda a trabajar mejor con equipos de desarrollo de relativamente baja

cualificacin por el alto control de cada actividad y sus resultados

Inconvenientes! Es muy inflexible, por tanto solamente resulta adecuado cuando hay

requerimientos muy bien definidos y muy estables, algo que es difcil deencontrar

! Retroceder en las fases para corregir errores que se han cometido en fasesprevias o adaptar el proyecto a cambios resulta muy difcil y costoso en esfuerzo


24/34

El ciclo de vida


! Aunque la documentacin elaborada permite un seguimiento bueno del proyectopara una persona cualificada, los resultados tangibles para el cliente aparecenprcticamente al final del proyecto, algo que muchas veces no aceptan losclientes

Definicin derequisitos

Anlisis

Diseo

Codificacin

Pruebas

Mantenimiento

Ilustracin 1 El modelo en cascada. Este modelo es estrictamente secuencial, est permitido retroceder, peroresulta muy costoso y se debera evitar al mximo. Por estas caractersticas resulta solamente eficaz en aquellos casos

en los cuales los requisitos estn muy definidos.

DESARROLLO EN ESPIRAL El desarrollo en espiral es un ciclo de vida muy orientado a la eliminacin progresiva de

los riesgos, es un ciclo de vida iterativo en cuyas iteraciones se enfocan uno o ms riesgosobjetivos que han de superarse hasta que el nivel de riesgo sea suficientemente bajo paracontinuar con un ciclo menos complejo.

En cada iteracin se realizan los siguientes pasos:! Planificacin: Determinar objetivos, alternativas y restricciones! Anlisis de riesgo: Anlisis de riesgos y evaluacin de alternativas! Ingeniera: Desarrollo de los entregables o prototipos de la iteracin! Evaluacin del resultado: Evaluacin y validacin del resultado

Ventajas! Puesto que se trata de un modelo orientado a los riesgos del proyecto da un

nivel de seguridad muy elevado al proyecto, los riesgos se eliminan al principioque es cuando mejor se puede reaccionar a ellos y en el caso negativo extremode detectar la inviabilidad del proyecto, minimiza la inversin realizada en l.

! Una mayor inversin en esfuerzo (y con ello tiempo y dinero) se traducedirectamente en mayor seguridad del proyecto, ya que permite gestionar con

mayor dedicacin los riesgos


25/34

El ciclo de vida


! El cliente dispone mediante los prototipos de resultados tangibles en cadaiteracin y participa de una manera muy interactiva en la evolucin del proyectocon lo cual se mejoran mucho las posibilidades de satisfaccin del resultado

Inconvenientes! El nico inconveniente es la complejidad y carga de gestin de este modelo.

DESARROLLO EVOLUTIVO ORIENTADO A PROTOTIPOS El desarrollo orientado a prototipos que evolucionan progresivamente no se debe

confundir con el modelo en espiral, aunque tienen bastante parecido en cuanto a su carcteriterativo en el modelo en espiral se trata de enfocar los mayores riesgos desarrollando primerolas facetas relacionadas con ellos y eliminarlos as cuanto antes, es decir, los riesgosdeterminan la evolucin del proyecto. En el desarrollo evolutivo de prototipos se parte de unconcepto inicial de la aplicacin y es este concepto el que evoluciona.

Es decir, en este modelo se desarrolla un primer prototipo relativamente completo,frecuentemente destinado a ser ya utilizado por cliente. El cliente aporta realimentacin y conella se desarrolla la siguiente versin, y as sucesivamente hasta que se alcance una versinque le satisface.

Resulta til cuando el cliente tiene prisa en desarrollar la aplicacin, pero no es capaz dedefinirla con exactitud y el mismo tiene que aprender ms de la problemtica que debe resolvercon la aplicacin. Tambin resulta adecuado cuando se prev que los requerimientos van atener una tasa de cambio alta durante el desarrollo del proyecto.

Ventajas! El caso de requerimientos cambiantes e incapacidad de parte del cliente para

definirlos con el suficiente detalle se da con frecuencia, abordar el proyecto deesta manera es una solucin muy natural ante este problema y evita en granmedida los conflictos con el cliente

! El cliente participa muy activamente en el desarrollo, por tanto, las posibilidadesde alcanzar un producto que haga lo que el quiere son altas

! Aporta resultados tangibles que permiten al cliente medir el progreso delproyecto

! En muchas ocasiones el cliente gana tiempo en el sentido que ya le resultantiles los primeros prototipos y amortiza la inversin desde un punto muytemprano mientras que se sigue mejorando el resultado final. Esta facetafrecuentemente hace que el cliente est dispuesto a asumir una inversin globalalgo mayor a la que estara dispuesto hacer si tuviera que esperar hasta laentrega final del producto, aade por tanto mucha flexibilidad a la negociacindel proyecto

Inconvenientes! En proyectos de cierta envergadura es prcticamente imposible saber cuando se

llegar al producto final, ni cuantos prototipos intermedios sern necesarioshasta entonces

! No es fcil convencer al cliente de la necesidad de tirar determinados prototipos a la basura, hay una gran tentacin de no llegar al final con las iteracionesnecesarias


26/34


27/34

El ciclo de vida


! Aplicar tcnicas de refactoring siempre que sea aconsejable. Refactoring significala reconstruccin o reestructuracin de cdigo de una manera disciplinada con elfin de eliminar cdigo obsoleto de un proyecto. Es fundamental en una filosofaque parte de una indefinicin tan alta como el XP, ya que el diseo detallado y elcdigo tiende a quedarse obsoleto con el tiempo y evolucionarlo significacomplicarlo cada vez ms. Llegado un momento, resulta ms econmico empezardesde cero.

! El cliente debe estar siempre disponible.! Programar antes el cdigo de las pruebas unitarias que el cdigo del producto en

s.! Propiedad colectiva del cdigo. Esto se refiere a que todo el mundo debe

contribuir en la medida de lo posible con ideas en todas las reas del proyecto.Incluso se concibe que modifiquen cdigo. Esto va unido al hecho de rotar losdesarrolladores entre reas

! Dejar las optimizaciones para el final!

No trabajar en exceso. El razonamiento es que las implicaciones negativas sobrela motivacin del equipo descompensan las posibles ganancias de tiempo! Todo el cdigo debe tener sus pruebas de unidad y no podr ser puesto en

produccin hasta pasarlas todas! Uso intensivo de tests de aceptacin

Ilustracin 2 - Ciclo de vida de un proyecto al que se aplica la metodologa de Extreme Programming.


28/34

El ciclo de vida


Ilustracin 3 Detalle del trabajo en una iteracin en el Extreme Programming. Se aprecia que est orientado aciclos muy cortos, de das.

La polmica est servida y se centra en dos aspectos principalmente: los costes dedesarrollo que genera este modelo de trabajo y la viabilidad de la idea del cdigo colectivo.

Ventajas! Parte de una visin muy realista en el sentido que considera la realidad en los

desarrollos con los clientes. As, por ejemplo, tiene en cuenta la dinmica con losclientes en la cual disponer de una definicin razonablemente completa defuncionalidad del producto suele ser pura ficcin

! Extreme Programming enfatiza especialmente la importancia el diseo simple y laimportancia de las pruebas, un punto especialmente descuidado en el desarrollo

! Aporta algunas ideas refrescantes que son tiles como principios incluso sinaplicar la metodologa en s. La programacin en parejas es un buen ejemplo, olos stand up meetings

Inconvenientes! La metodologa no es escalable, solamente puede tener sentido en proyectos

relativamente pequeos, segn XP proyectos de entre 2 y 12 desarrolladores! Algunos de los principios parecen demasiado extremos y no gozan de unrespaldo con argumentos slidos por los defensores de esta metodologa. Por

ejemplo, el principio de la programacin colectiva, es decir, que en definitivatodos puedan tocar en todas partes, un punto que genera mucho debate porqueel peligro de una evolucin anrquica de las funcionalidades de los mdulosparece alta y muy difcilmente controlable. Otro ejemplo es el refactoring, lamisma metodologa pide cierta estabilidad en el diseo base, pero a la vezenfatiza la necesidad de refactoring, dos principios que entran fcilmente enconflicto, pero no aporta criterios claros para saber dnde situar punto deequilibrio entre ambos.

! La metodologa no responde con soluciones o con sugerencias a muchos losproblemas que plantean sus principios, lo cual da una impresin de encontrarsean en un estado relativamente hipottico


29/34

El ciclo de vida


DESARROLLO ORIENTADO A HITOS Con frecuencia se da el caso que el factor limitante es el tiempo ms que el presupuesto

o el detalle de la funcionalidad. En estos casos puede ser muy oportuno aplicar este ciclo devida que asume ciertas indefinicin en la envergadura final de las funcionalidadesimplementadas, pero fija claramente un punto final en el tiempo. En un desarrollo grandepuede ser adems muy til para gestionar el desarrollo de mdulos individuales no crticos conel fin de que no retrasen el progreso global del proyecto.

En este ciclo de vida bsicamente se trabaja secuencialmente en la base estable delproducto que incluye llegar hasta el diseo de la arquitectura, pero a partir de ah se trabaja enciclos iterativos sobre el diseo detallado, codificacin y pruebas. Los contenidos de estos ciclosse priorizan para optimizar segn la relevancia de las funcionalidades implementadas.

Ventajas! Es una estrategia relativamente ptima ante una situacin de fecha lmite rgida!

Permite reducir mucho el riesgo en proyectos grandes si se gestionan susmdulos de menor prioridad con esta tcnica

Inconvenientes! Si se consiguen implementar relativamente pocas funcionalidades de las previstas

se habr perdido mucho tiempo en la especificacin y diseo de funcionalidadesno implementadas al final, por tanto hay que medir bien la ambicin del trabajoprevio a los ciclos iterativos

Definicin derequisitos

Anlisis

Diseoarquitectura

Requisitos alta prioridad: Diseo detallado,codificacin, depuracin y pruebas

Requisitos alta/media prioridad: Diseo detallado,codificacin, depuracin y pruebas

Requisitos prioridad media: Diseo detallado,codificacin, depuracin y pruebas

Requisitos baja prioridad: Diseo detallado,codificacin, depuracin y pruebas

Entrega final

Lm ite en el t i empo

Ilustracin 4 Modelo orientado a hitos. Ntese que se combina en cierta manera el enfoque clsico con el modeloen espiral dividiendo la parte ms gruesa del desarrollo en fase priorizadas que permiten optimizar la relevancia deltrabajo realizado dentro de unos lmites de tiempo, obsrvese especialmente el matiz que la fase de diseo no iterativase limita al diseo de la arquitectura ya que no vara con las iteraciones.


30/34

El ciclo de vida


MODELOS MIXTOS

Los modelos presentados solo son algunos de los existentes, ante un proyecto concretocabe la posibilidad de combinar modelos diferentes si el perfil del proyecto lo hace aconsejable,es decir, los modelos presentados no se deben interpretar con un espritu excesivamentepurista, sino tomarlos como estrategias de base ante una serie de caractersticas de unproyecto.

Lo importante es que se haga el ejercicio de plantear una estrategia de desarrollo queresponda de una manera coherente a la situacin previsible del proyecto al que se aplica. Losmodelos aqu presentados pueden ser vlidos para muchas ocasiones, y si no lo fueranconstituirn una inspiracin para disear un modelo a medida ms adecuado.

Para ayudar a realizar este ejercicio aportamos una serie de preguntas:! Cmo de bien entendemos el cliente y yo los requisitos al comienzo del

proyecto? Es probable que cambien a lo largo del proyecto?! Entiendo la arquitectura del sistema? Necesitar realizar cambios significativos

en la arquitectura del sistema durante el desarrollo del proyecto?! Qu nivel de fiabilidad necesito?! En qu medida tengo que planificar y disear en vista de las futuras versiones?! Cul es el nivel de riesgo del proyecto?! Debo tener en cuenta fechas lmite?! Ser necesario disponer de capacidad de maniobra para realizar correcciones en

la mitad del proyecto?! Me va a exigir la direccin resultados intermedios tangibles?


31/34

Conclusiones


CONCLUSIONES

En proyectos de desarrollo de software habitualmente se dan desvos sobre laplanificacin inicial de entre un 25 y 50%, la forma de responder a ello no suele pasar ms allde medidas de mayor presin de calendarios, horas extra y aadir personal a un proyecto.Estudios demuestran que el estrs que los desarrolladores crece continuamente y que, engeneral, la satisfaccin laboral ha bajado comparado con 20 aos atrs.

Sin embargo, aunque la situacin descrita hoy por hoy an es una realidad en la mayorade las empresas, afortunadamente existen ejemplos contrarios que sorprenden por el grado enel que multiplican la productividad de las primeras.

Qu es entonces lo que las diferencia? La diferencia que el modo de actuar de lasprimeras ignoran tanto las caractersticas del desarrollo del software en s como lascaractersticas de las personas que lo desarrollan. Para las segundas, sin embargo, estos sonlos puntos de partida para definir su modelo de trabajo y de gestin. Es decir, una empresa dedesarrollo que quiere ser efectiva debe tener en cuenta una serie de factores:

! El capital ms importante de una empresa de desarrollo son sus recursoshumanos, por tanto la gestin debe tener muy en cuenta las caractersticas deestos para lograr una mxima productividad

! La tecnologa es compleja, por tanto, lo es tambin el trabajo y las decisionesque se deben tomar en su desarrollo. La correcta gestin supone un reto que noes fcil de alcanzar y en el cual simples decisiones de martillazo sern altamentecontraproducentes

! La tecnologa tiene un fuerte efecto palanca sobre la productividad, por tantoresulta muy rentable mantener la cualificacin de los recursos humanos a unmximo nivel

! Es un trabajo fuertemente creativo, hay que lograr que el entorno de trabajopermita desarrollar la creatividad necesaria

! La actitud ante el trabajo de los desarrolladores es envidiable para muchos otrossectores. Son personas a las que les gusta trabajar y superar retos, por tanto,tienen unos niveles de automotivacin muy altos, un punto de partida excelentepara lograr una mxima productividad. La empresa que crea un entorno detrabajo que no sea capaz de rentabilizar estas caractersticas habr fracasado ensu gestin y modelo de trabajo

! Es realmente sencillo dar a los desarrolladores lo que necesitan para estarmotivados, pero exige la sensibilidad suficiente para comprender cmo piensan

En resumen, para enfrentarse con xito a las exigencias del desarrollo de software hayque conocer muy bien tanto las caractersticas del proceso como el perfil psicolgico de laspersonas que realizan esta labor y actuar en consecuencia. Si no es as, an las mejoresherramientas de Ingeniera no servirn de nada.

La clave est en saber explotar la alta motivacin que tienen habitualmente de por s losdesarrolladores y gestionar cada proyecto con la estratgica ms adecuada a sus caractersticasespecficas. Tener en cuenta las ideas y principios expuestos en este documento ayudarnsustancialmente a conseguir esta meta, nacen de experiencias contrastadas, tanto en lo que serefiere a xitos como a fracasos y son por tanto una gua fiable.


32/34

Bibliografa


BIBLIOGRAFA

A continuacin un breve listado de bibliografa interesante relacionada con los contenidosde este documento.

R EFERENCIAS EN WEB Advanced Quality Solutions.Seccin de downloads en la web,

http://www.aqs.es/downloads - En esta seccin se publican peridicamentedocumentos que reflejan las experiencias, opiniones y resultados de I+D de estaempresa en temas tecnologa, gestin y negocio dentro del sector de lastecnologas de la informacin.

http://www.cetus-links.org - Excelente coleccin de todos tipo de enlacesrelacionado con la Ingeniera del software modera. Tanto a nivel de desarrollocomo a nivel de gestin, es el punto de partida perfecto para llegar a todo lorelevante de las tecnologas relacionadas con el software actuales y para estar ala ltima en la evolucin del campo del desarrollo del software.

American Management Association.http://www.amanet.org/index.htm - En estesitio se encontrarn artculos interesantes sobre todo tipo de temas relacionadoscon la gestin de proyectos, referencias bibliogrficas sobre temas especficos,calendarios de eventos, etc.

Eric Raymond. The Cathedral an the Bazaar .http://www.openresources.com/documents/cathedral-bazaar/ - Un clsico de

obligada lectura para cualquiera que tenga inters en la gestin de proyectos,para dos estilos opuestos de desarrollo, el modelo que el llama el modelo decatedral, propio de la mayora de los desarrollos con el modelo de bazarpropio del mundo Linux. Como figura importante en el mundo del Open Sourcees evidente hacia qu modelo se inclina, y lo hace con un argumento de partidacontundente: si ha sido posible desarrollar un sistema operativo de la categorade Linux con participantes en todos los lugares del mundo el modelo del bazardebe tener algo de sentido.

Extreme Programming.http://www.extremeprogramming.org/ - Sitio dereferencia para conocer ms sobre este curioso modelo que ha aparecidorecientemente, incluimos esta referencia sobre todo por la actualidad de lapolmica sobre esta metodologa.

Refactoring. http://www.refactoring.com/ - Sitio web sobre esta tcnicareestructuracin disciplinada de cdigo.

LIBROS& ARTCULOS IMPRESOS

Libros de referencia Ian Sommerville.Software Engineering, 6 th Edition. Addison Wesley 2000.


33/34

Bibliografa


Kent Beck.Embrace Change. Addsion Wesley 1999 Este libro es unaintroduccin a esta metodologa polmica que ha surgido con fuerza en losltimos dos aos, de hecho aporta una manera de pensar alternativa con algunosaspectos muy interesantes. El libro est dividido en tres apartados que explicanen qu consiste esta metodologa, expone cmo aplicarla y el ltimo se centra encmo introducir esta metodologa en una empresa.

Roger S. Pressman.Software Engineering A Practioneers Approach, 5 th Edition.McGraw Hill 2000.

Steve MCConnell.Rapid Development . Microsoft Press 1996 Excelente libro quese centra en como conseguir desarrollos de aplicaciones lo ms eficientes y portanto rpidos posibles. La frmula propuesta y plenamente acertada es buenagestin a todos los niveles: planificacin, riesgos, personal, etc. Expone cmollevar esta gestin a la prctica aportando la experiencia de ms de 20 aos desu autor en este campo. No en vano es la fuente de inspiracin principal de estedocumento.

Artculos y fuentes varias Barry W. Boehm.Software Engineering Economics. Englewood Cliffs, N.J.:

Prentice Hall 1981 Barry W. Boehm.Software Risk Management. Washington, D.C.: IEEE Society

Press 1989. Bill Curtis et al.Software Psychology: The Need for an Interdisciplinary Program.

Proceedings of the IEEE 1986, vol. 74, no. 8 (August): 1092-1106 Bill Curtis.Substantiating Programmer Variability. Proceedings of the IEEE 1981,

vol. 69, no. 7 (July): 846 Capers Jones. Assesment and Control of Software Risks. Englewood Cliffs, N.J.

Yourdon Press 1994. Carl E. Larson, Frank M.J. LaFasto.Teamwork: What Must Go Right; What Can

Go Wrong. Newbury Park, Calif.: Sage. 1989. David N. Card. A Software Technology Evaluation Program. Information and

Software Technology 1987, vol. 29, no. 6 (July/August): 291-300 Gerald M. Weinberg.The Psychology of Computer Programming. New York: Van

Nostrand Reinhold. H. Sackman, W.J. Erikson, E.E. Grant.Exploratory Experimental Studies

Comparing Online and Offline Programming Performance. Communications of the ACM 1968, vol. 28, no. 3 (Fall): 403-424

Harlan D. Mills.Software Productivity. Boston, Mass. 1983: Little Brown. 71-81. J. Richard Hackman, Greg R. Oldham.Work Redesign. Reading, Mass. 1980:

Addison Wesley. J. Valet, F.E. McGarry. A Summary of Software Measurement Experiences in the

Software Engineering Laboratory. Journal of Systems and Software 1989, 9 (2):137-148

James Bach.Enough About Process: What We Need Are Heroes. IEEE Software,Marzo 1996-98.

Larry L. Constantine.Constantine on Peopleware. Englewood Cliffs, N.J.: YourdonPress 1995

Rob Thomsett. Project Pathology: A Study of Project Failures. AmericanProgrammer. Julio 1995, 8-16.


34/34

Bibliografa

Tom DeMarco, Timothy Lister. Peopleware: Productive Projects and Teams. New York: Dorset House. 1987

Tom DeMarco, Timothy Lister.Programmer Performance and the Effects of theWorkplace. Proceedings of the 8 th International Conference on Software

Engineering. Washington, D.C.: IEEE Computer Society Press 1985, 268-272

gestion_proyectos_con_exito.pdf

Documents