Lycka Bonita

Los que trabajamos en informática nos pensamos que el proyecto arranca cuando creamos el proyecto en el repositorio. No es así, en ese momento "sólo" queda implementarlo, probarlo y entregarlo, jejeje, pero para llegar a este punto antes se han hecho un montón de cosas.

Pero empecemos por el principio. "En el principio creó Dios los cielos y la tierra. Y la tierra estaba desordenada y vacía, y las tinieblas estaban sobre la haz del abismo…" Bueno, un poco más adelante, en el principio del proyecto.

Un cliente detecta una necesidad, y por tanto busca candidatos a solucionarla entre cierto número de proveedores que entregan sus propuestas de proyecto. Es en este punto cuando tienes que convencer al cliente de que tu propuesta es la más destacada y adecuada entre las demás : lo que se entiende por preventa. Este momento es crucial ya que si no se supera se ha trabajado para nada, y nunca llegaremos a crear un nuevo proyecto en el Eclipse.

En nuestro caso, nos encontrábamos ya trabajando en el cliente cuando surgió la necesidad de construir un nuevo sistema al finalizar el desarrollo en el que nos encontrábamos, con la misma tecnología y el mismo grupo de personas. Se trataba de una necesidad de baja prioridad para el cliente que además se encontraba con restricciones presupuestarias debido al mes en curso (no es igual conseguir dinero extra en enero que en diciembre) y a la crisis.

Propuesta

La definición de proyecto más completa y exacta que está almacenada en mi memoria es algo como lo que sigue:

Un Proyecto es el conjunto de tareas (WBS, Work breakdown structure) planificadas necesarias para llevar a cabo unos objetivos (alcance) en unas fechas determinadas (plazo) con unos costes (presupuesto, que se utilizará entre los recursos materiales y los recursos humanos) predeterminados y con una determinada calidad (la gran olvidada habitualmente) y que pueden sufrir la materialización de unos determinados riesgos.

Lo habitual es que el propio cliente no tenga claro casi ningún punto, aunque sí suele imponer determinadas restricciones como una fecha impuesta o un presupuesto máximo. Por tanto se suele hablar de porcentajes de desviación en función del nivel de incertidumbre.

Te va a costar 100 euros más menos un 15 %

Por lo tanto la propuesta debería de especificar, con el menor margen de incertidumbre posible :

• El alcance. Es tan importante especificar qué se va a hacer como el qué no se va a hacer para luego no llegar a equívocos o sorpresas. En nuestro caso dentro del alcance no caían el 100% de las funcionalidades necesarias, en parte por indecisión del cliente y en parte por las restricciones presupuestarias.
• Tareas. Conocido el alcance, podemos definir un WBS. Lo habitual es limitarse a un primer nivel de desglose en el sistema (módulos y sus interacciones), propietario de la tarea (en nuestro caso se asignaron tareas al cliente por las restricciones presupuestarias), fases e hitos. Nos permite realizar una estimación de las horas necesarias para cada recurso.
• Plazo. Conocido el WBS podemos realizar una planificación de las tareas en función de los recursos disponibles y fechas de entrega previstas por parte de otros equipos y por tanto estimar fechas de entrega y cierre. En ocasiones es al revés, tengo que cumplir unas fechas de entrega y por tanto planifico las tareas para alcanzar esas fechas : suelen ser más costosos y difíciles de cumplir al reducir el margen de recuperación de la materialización de riesgos.
• Presupuesto. Conocido el alcance del proyecto y el WBS podemos establecer un presupuesto, o al menos un punto de partida para la negociación.
• Calidad. Se definen los requisitos de calidad que deben cumplir el producto entregado mediante un SLA (Service Level Agreement) : usuarios soportados, concurrencia, rendimiento, test unitarios, test funcionales, tiempos de resolución de incidencias en el mantenimiento…

En este caso se proponen 4 fases para el proyecto con sus respectivos hitos finales.

• Primero una fase de arranque para la toma de requisitos, análisis y diseño del sistema.
• Una segunda fase para construir los sistemas auxiliares.
• Una tercera fase para la construcción de sistema principal.
• Y una última fase de cierre para retoques, errores, documentación…

Negociación

En un lado de la mesa, el cliente (el departamento de informática de la empresa) y el usuario (el que va a utlizar el sistema); en el otro lado de la mesa el comercial de mi empresa (un monstruo) y yo. Omnipresentes en todo momento, las restricciones presupuestarias.

La verdad es que yo he participado poco en la negociación, aunque creo haber influido Yo me limitaba a escuchar, poner límites a los imposibles, presentar propuestas para solucionar estos imposibles aportando simplemente mis opiniones profesionales.

La mayor restricción del proyecto era el limitado presupuesto, no importaba si se alargaba o no se acometía el 100% de las funcionalidades.  

Una restricción importante es la imposición de realizar un proyecto a presupuesto cerrado : si no cumplimos palmamos pasta. Por eso es muy importante afinar al máximo las previsiones, ya que un alto margen en la estimación (tanto técnico como comercial) nos hacen perder el contrato, y uno bajo nos puede obligar a trabajar perdiendo dinero en espera de recuperar en el mantenimiento o con más proyectos en mejores tiempos.

Después de varias reuniones para clarificar y consensuar los objetivos, se realiza una primera propuesta de supongamos 100 jornadas de trabajo, que el comercial tradujo a dinero, pongamos que 100 €. Entenderéis que las cifras son inventadas únicamente con el objetivo de ilustrar un poco la negociación. 

Como eso estaba claramente por encima del presupuesto disponible, después de varias reuniones y negociaciones se sacaron del alcance funcionalidades que se realizarían por el propio cliente o más adelante en un segundo proyecto posterior y se apuraron al máximo los plazos aprovechando la experiencia (y gran calidad) del equipo de desarrollo.

Así llegamos a una propuesta final de 50 jornadas, que traducidas a dinero eran 50 € que ahora sí era asumible, aceptada y firmada por cliente. Por nuestra parte estaba en el límite de lo rentable, más pensando en futuros proyectos para este mismo cliente que en la rentabilidad del actual.

En este punto yo ya no estaba tan cómodo ya que el colchón de 50 jornadas es la mitad que el de 100, y además reduje este colchón hasta el mínimo posible cruzando los dedos para que no se materializasen muchos riesgos : somos chicos fuertes y sanos y nadie caerá enfermo, somos equilibrados así que nadie se pirará de la empresa sin avisar borrando su trabajo, no tenemos novia así que a nadie le dejará la novia (jejeje, esto no es cierto), no tenemos malos días… Al ser un sector "tradicional", el cliente lleva "toda la vida" haciendo a mano lo que nos piden que automaticemos, así que también rebajo el colchón de la incertidumbre.

Una apuesta arriesgada viniendo de un proyecto fracasado que salió bien : se llegaron a 5 proyectos (1 en mantenimiento, 3 en mantenimiento evolutivo, 1 nuevo desarrollo) con previsiones al alza (migraciones, nuevos productos y funcionalidades sobre los proyectos entregados, y nuevos proyectos como la Arquitectura y refactorización de los existentes), con más de 15 puestos de trabajo a tiempo completo. 

En resumen, habemus proyecto, pero habrá que afinar mucho en su ejecución.

Imágenes

• Modulor Arquitectura y Construcción.
• Abetas.

No se han encontrado entradas relacionadas.