Palabras que todo LSIA ya TI-TU-LA-DO deberia conocer para vender un proyecto.

El negocio del desarrollo de software, aceptemoslo, jamás ha sido un negocio que pague bien. Y no me refiero al dinero sino que la satisfacción de sacar un producto a producción no marca el final de un ciclo si no más bien el inicio donde empezaras a trabajar en detalles que jamás salieron a la luz durante una etapa de analisis o cosas que al cliente le parecio oportuno omitir para que asi no te diera pánico entrarle al proyecto.

Además, los nuevos gerentes e inversionistas ya no se contentan con una aplicación con botoncitos bonitos y reportes cuadraditos: quieren resultados el primer mes. Y bueno, ellos tienen control sobre la llave de los dineros. Y esa llave se tarda en abrir bastante. Dicen. Yo estoy del otro lado de la interfaz en ese tipo de proyectos. Pero no soy ajeno a las peripecias que deben hacer para afanarse el dinero para un proyecto de desarrollo de software porque me ha tocado participar en algunas juntas donde se discute ese tipo de menesteres y la verdad es que las pseudo razones que dan para iniciar el desarrollo son casi razones para olvidarse del asunto.

Por ello y en afán de apoyar a todos esos compañeros egresados que navegan con bandera de gurus de RUP (ese método de las ballenitas) y que dominan a la perfección el google y wikipedia he intentado crear una lista de conceptos que deslumbraran a cualquier PM (project manager) entendido y hara que suelten el billete sin pensarla mucho.

Top ten de los conceptos que todo LSIA titulado debe saber.


10. Compromiso. Ante todo el cliente debe quedarse con la idea de que tu, como proveedor, no sientas que le estás haciendo el megafavor de ayudarles a solucionar sus problemas. El Cliente quiere pensar que al momento de firmar el contrato tu equipo se pondrá la camiseta de la empresa - les quede como les quede - y sudaran sangre hasta terminar el proyecto. Es muy importante repetir la palabra compromiso con una entonacion mesurado y dirigiendo la mirada en forma pasiva a los tipos de jerarquía mas baja.. porque serán ellos quienes se pongan una chinga y es mejor tener su simpatía.

9. Vida promedio. Esto es un concepto que ya ha caido en desuso, fue muy de moda en los 80's y 90's para ser ya casi ha sido sustituido por el de ROI ( me parece escuchar el tintineo de muchos dientes de LSIA solo de recordar las clases de Ingeniería Económica) . Al cliente le interesa saber cuanto va durar su sistema productivo, más aún al cliente estarámuy interesado en saber cuando tendra que invertir en mantenimiento de su sistema y cuanto va costar, aqui es de vital importancia no hablar mas de la cuenta y evitar que las letritas chiquitas no digan absolutamente nada de estos y ya como quiera despues se le pasan al cliente como...

8. Costos ocultos. Este obviamente no es un término que se pueda andar diciendo en todas las reuniones. No. Este solo lo pueden decir cuando el cliente ya este comprometido, o por decirlo coloquialmente: cuando el cliente sepa que ya se la dejaron caer. En un tono conciliador y de forma que al cliente le quede claro que todos sabemos que siempre hay costos ocultos, de esta forma se transforma en su problema y lo toma como afrenta personal malversarunos cuantos billetes de por ahi para salir al paso.

7. Entregables. En un proyecto ideal - no he estado en ninguno aún- lo normal sería que la documentación fuera entregada en tiempo y forma, pero jamás es así. En muchos de los casos se comete el error de poner a documentar un sistema a la misma persona que lo creo lo cual obviamente es una mala decisión. Como sea, como proveedor, es mala idea levantar una expectativa mayor sobre los entregable porque para cuando el proyecto este en su etapa final la relacion con tu cliente estarátan desgastada que lo unico que querras sera largarte de ahi.

6. Requerimientos. Este termino es básico y puede resolverte muchos problemas si lo empleas bien. En un sentido estrictamente etimologico quiere decir todos aquellas solicitudes o necesidades de tu cliente que DEBISTE recabar durante la fase de apertura del sistema. Lo importante es hacerle creer al cliente que si no puso en claro algo en esa fase no se puede ya incluir en el proyecto por riesgo a causar costos (ocultos obviamente) o por alterar los

5. Alcance del proyecto. Este término te va servir de mucho lograr que tu cliente se muerda el izquierdo cuando le digas que no se puede incluir tal o cual funcionalidad por no estar dentro del alcance del proyecto. En menor medida tambien puede servir para justificar que el cliente invierta en agregar modulos a un sistema, aun cuando quizas esa funcionalidad debio ser descubierta y documentada por tu analista de sistemas.

Obviamente el cliente quiere saber que tiene respaldo técnico por parte del proveedor mas si va invertir una buena cantidad de lana en equipo. Es por ello que se deben dominar un par de conceptos que abren con facilidad las carteras.

4. Outsourcing. O Subcontratación. Esto es generalmente cuando se contratan los servicios de un tercero para realizar una tarea que a) Es tediosa y/o riesgosa, b) Es demasiado costosa para que tu absorbas los costos o c) Jamás la consideraste y ahora ya es un factor critico de exito. Obviamente lo ideal es aqui sugerir el outsourcing como la salvacion y ademas proponer a un tercero que nos pueda dar parte de la ganacia.

3. Performance. Esta palabra es de las mas socorridas a lo largo del proyecto, es casi como una wildcard que abre puertas y códigos presupuestales con una facilidad pasmosa. No hay mas que decir que '... el performance se vera afectado posivitivamente sí se invierte en modernizar los servidores..' para que las cajas registradoras empiecen a sonar. Casi al parejo las cejas de la gente de TI se empieza a levantar. Son signos que hay que leer para saber que un par de patadas en el culo vienen en camino.

2. Infraestructura tecnológica. Aqui las alarmas deben estar encendidas siempre, porque cualquier cosa que digas provocara la ira o miradas aprobadoras del area de TI. Y es de todos sabidos que aunque pocas veces son escuchados proyectos enteros se han venido abajo por falta de su apoyo. Aunque no por eso vas a parecer un estupido aldeano? Puedes citar este termino siempre y cuando en la reunion haya no más de un integrante del área de TI, asi las posibilidades de que quiera presentar resistencia será nula.

Y por último la joya de todos los técnicismos, algo con lo que todo mundo cae y que creanlo o no, me ha tocado escuchar en una reunión con un consultor que se pensaba que esta tratando con un grupo de agricultores tratando de montar un tractor.

1. Control de redundancia ciclica. Obviamente el término tiene poco o nada que ver con la justificación de proyectos de software, pero nombrar otros pudiera causar que te pidieran dar mas explicaciones. Por eso es mejor decir una frase elaborada cuando te pidan explicaciones de porque los resultados no son los esperados tu podrias dar una respuesta del tipo: 'Hemos observado que no hemos llegado a los niveles de servicio esperados debido a que el performance de la infraestructura tecnologica se ha visto afectado por el factor de perdida de estabilidad en el control de redundancia ciclica de los servidores lo que nos forzará a realizar cambios drásticos en nuestros desarrollo y esto, obviamente, afectará los tiempos de entrega de nuestro proyecto.' Directo y no tanto a la vez, pero nadie lo entendera y es posible - creanlo, lo es - de que se lo traguen.

Estoy seguro, tu lector LSIA, que de ahora en adelante podrás abrirte paso con más facilidad en las juntas y hacerte respetar por tus compañeros. Te lo dice alguien que estuvo ahi, se rió, mucho. Y se sigue riendo aún.

Paz.