Proyecto anzuelo

Existe un tipo de proyecto al que deberéis temer sobremanera. Es lo que me gusta llamar "proyecto anzuelo".

El nombre no entraña ningún misterio y es todo lo directo que puede ser. La idea incluso puede parecer buena en un principio, y se resume así:

• Sea A un cliente potencial y D una empresa de desarrollo software.


• Sean P y Q dos proyectos que A quiere desarrollar próximamente.


• Sea pres(X) la función que a cada proyecto X le asigna su presupuesto.


• pres(Q) >> pres(P), pres(Q) > avg(pres(X)) para todo X perteneciente a {proyectos de D}

Bajo las condiciones anteriormente expuestas, el representante comercial de D se comprometerá a llevar a cabo P a un precio ridículamente bajo ante la promesa de obtener la contrata de Q

En lenguaje llano: "Vale, puede que pierda algo de pasta con este proyecto pequeñito, pero cuando llegue el grande, me voy a forrar".

¿Puntos flacos de la idea?

1. Suena un poco a cuento de la lechera


2. Piltrafilla... ¿tienes algún documento vinculante para eso?

Claro, esto para la idea original, pero el Mundo Real(TM) suele distanciarse ligeramente de nuestras expectativas:

1. El representante comercial suele tener de técnico lo que yo de morenaza macizorra. Cómo su trabajo es dejar al cliente contento el NO no formará parte de su vocabulario.


2. Consecuencia directa de lo anterior, el proyecto estará poco definido y constantemente abierto a llamaditas del cliente de "... donde dije digo digo Diego...". Cambios de requisitos a punta pala.


3. En una operación comercial de alto nivel como esa, un técnico sólo entorpece (ja, me parto con mi fina ironía) así que tú, pobre currito, sólo entrarás en el proyecto cuanto todo esté firmado, cerrado, y lo más importante, MAL.

Ahora vamos a intentar sumar 2+2 (duro ejercicio intelectual, alcanzáos un tentempié).

1. Tenemos un proyecto que, viento en popa a toda vela, va a cubrir costes.


2. Todos sabemos que, gracias al cabrito de Murphy, el viento no suele venir de la popa.


3. Se ha dejado a gente de capacidad técnica mínima decidir cuestiones técnicas.


4. Los requisitos están cerrados sólo en una dirección: se pueden añadir funcionalidades, pero no quitar.

Es fácil ver que todas estas circunstancias propiciarán un desvío de tres tipos: coste, tiempo y calidad. Estas tres magnitudes están relacionadas, de forma que reducir tiempo implica aumentar coste y/o disminuir calidad. O reducir coste se consigue a costa de la calidad. El coste es la medida del impacto del proyecto P para la empresa D. La empresa A tiene un precio ya convenido, por lo que su mayor preocupación es el tiempo. La calidad del producto es uno de los factores que no se han tenido en cuenta y que provocan el fallo del modelo "anzuelo".

El resultado directo de tener en cuenta todas circunstancias tiene varias consecuencias:

• El coste del proyecto será con seguridad mayor de lo estimado, provocando pérdidas.


• El producto entregado al cliente irá fuera de plazo y con una calidad cuestionable.


• El personal implicado en el desarrollo alcanzará cotas de frustración elevadas, tanto por la presión como por la certeza de estar desarrollando una chapuza.

Ciñéndonos al segundo punto... Si el cliente recibe una chapuza y fuera de plazo, ¿vosotros creéis que encargará el proyecto caro a quién le ha presentado semejante bazofia? Tendría que estar un poco tonto, ¿no? Entonces las pérdidas del primer proyecto no se podrán arreglar con el segundo, y sólo habremos conseguido un agujero presupuestario y un puñado de trabajadores descontentos.

¡Viva el proyecto anzuelo!