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.