Cuando se habla de gestionar un proyecto se tratan habitualmente tres dimensiones: el tiempo disponible para realizarlo, los recursos (materiales y humanos) con los que contamos, y los requisitos o alcance que tiene el proyecto: qué tiene que hacer. Siempre que hablo de un proyecto pienso automáticamente en uno informático, es decir, cuyo resultado será un portal web, o un programa, o un plan de formación técnico o algo así, aunque también vale pensar en la organización de una boda o de un viaje, como ahora veremos.
Para ilustrar estos tres aspectos y su relación se pinta casi inevitablemente un triángulo en la pizarra. La situación ideal es que el triángulo sea equilátero, que todos los lados estén equilibrados (nota a los malos traductores: balanced no se traduce por balanceado, sino por equilibrado). Si alguno de los tres lados crece, los otros se ajustan para mantener el triángulo.
Ejemplo 1: Desarrollo de un portal web.
Si nos fijan una fecha de entrega, y los requisitos no están claros (lo que, por la primera ley Freniche del Software hace que no paren de crecer) tenemos dos posibilidades. La primera, huir del proyecto rápido, rápido y sin mirar atrás. La segunda, la más habitual (bueno, ahora que lo pienso…) es aumentar los recursos: contratar a más gente.
Ejemplo 2: La boda
Si los requisitos cambian, por ejemplo, porque no coincidan las fechas en que está disponible el cura y el lugar donde vamos a celebrar el enlace, ya que los recursos son limitados (la organización de una boda siempre recae en la novia que acaba al borde del histerismo) el plazo de entrega debe variar: se mueve la ceremonia a mejores fechas.
En todas estas situaciones se supone que no hay problemas, ni errores. Al planificar, todo va a ir bien. Pero en los proyectos informáticos (como en todos los demás, por cierto) hay que contar con el nivel de calidad que debemos entregar. Podemos pensar en que nuestro sistema no tendrá ni un sólo error, lo que es en sí mismo un error. No tiene sentido resolver un problema cuyo coste supera al beneficio que aporta.
Luego hay que tener siempre presente la tasa de errores con la que queremos vivir. Si nuestro programa debe ser perfecto, los recursos para control de calidad, test y comprobaciones aumentarán. Necesitaremos más tiempo para hacerlo todo con calma. Y el alcance no puede crecer y crecer, ya que con cada requisito nuevo la probabilidad de introducir un error nuevo, o de que el sistema no funcione bien debido a las interacciones entre componentes aumenta.
¿Aburrido?
La verdad es que hablar de gestión de proyectos le resulta un ladrillo a mucha gente. Y encima es algo que no puedes ver. Bueno, no exactamente. Hoy me he topado con un pequeño applet que ilustra perfectamente (y, en parte, ha inspirado) este post. Está en www.basilv.com/psd/software-files/launchManagementDiamond.html.
Juega con él fijando el tiempo, aumentando el ámbito y tratando de disminuir los recursos: verás que no es posible. Como en la vida real. Sólo en las mentes de algunos gestores cabe tener listo “para ayer” ese portal que integra LDAP, SingleSingOn, un CMS, WorkFlow y dos huevos duros contando con un equipo formado por dos becarios y el chaval de prácticas en empresas.
Post original tomado de http://blog.freniche.com/2007/05/03/los-cuatro-aspectos-de-la-gestion-de-proyectos-vistos-graficamente/
Ahorros en promedio de un 50% en costos de licenciamiento en la suite de Microsoft Office