Al final, aparezca por medio o no el taxímetro o se enfoquen los trabajos orientados al servicio, siempre estará de fondo el coste por hora de los proyectos de desarrollo de software.
En este artículo me voy a centrar en el proveedor. El objetivo del mismo será obtener el máximo beneficio posible al proyecto. Además, desde mi punto de vista no debería conformarse sólo con eso, por lo que el objetivo debería ser algo así como obtener el máximo beneficio posible al proyecto, consiguiendo en el cliente el máximo grado de satisfacción posible.
Como satisfacción del cliente y máximo beneficio no van siempre de la mano es necesario intentar alcanzar el mayor equilibrio posible en esa situación y para conseguirlo, además de personas que sepan desarrollar el proyecto (gestión, análisis y construcción) y de tratar y negociar con el cliente de la mejor forma posible, se necesitará que internamente los costes de producción del producto sean los menores posibles, ya que de esta forma el margen será mayor, por lo que se cumplirá el objetivo de obtener un beneficio (incluso importante) en el proyecto, se podría considerar que conseguir un beneficio por encima de un umbral esperado o de un umbral medio de beneficios es equivalente a conseguir los máximos beneficios posibles en el proyecto, es decir, no se trata tanto de alcanzar la cima, como de saber que te encuentras cerca de la misma.
Sobre esto es interesante añadir que dado que todos los proyectos no se venden igual, ni todos los proyectos son iguales y cada cliente es un mundo, mantener unos umbrales de beneficio iguales en todos los proyectos, puede ser considerado incluso una salvajada, ya que existirán proyectos donde para acercarse a esos umbrales o incluso para intentar que las pérdidas sean las menores posibles, habrá que hacer un sobreesfuerzo descomunal por parte de quienes participen en los mismos. No digo que no sea interesante fijar un umbral a partir del cual el beneficio se considere aceptable, ya que sin referencias todos nos perdemos, sino que en determinados proyectos que se sabe a ciencia cierta desde que se ganan o desde que suceden unos determinados eventos en el mismo que no se va a poder conseguir, se planteen unos objetivos realistas a su naturaleza que incluso puedan ser complicados de cumplir, pero por lo menos que no sean imposibles. El problema estará si esto que debería ser una excepción se convierte en la norma, en este caso hay un problema y muy serio.
Volviendo a la reducción de los costes de producción se puede conseguir de diversas maneras, como por ejemplo: utilización de generadores de código, reutilización de código (incluso de bloques enteros de software) y documentación, subcontratar partes del proyecto a otras empresas que tienen menores costes de producción y por supuesto utilizando de la forma más adecuada los recursos humanos de la organización, de manera que el personal asignado al proyecto sea el más apropiado acorde a las tareas que hay que realizar. Esto por supuesto no es fácil, ya que no sólo requiere de la capacidad de acertar con el personal, sino que además éstos estén liberados de un proyecto, puedan ser compartidos con otro proyecto o se puedan desasignar de aquel o aquellos en los que esté trabajando. Por tanto, es más realista indicar que hay que saber elegir lo mejor posible de aquellos que en cada momento sean elegibles (más tarde lo mismo quedan liberados recursos que pueden ser de utilidad, por lo que no se trata de una elección estática, ya que de la misma forma que los proyectos son algo vivo, también lo puede ser el equipo de personas que trabaja en el mismo).
Uno de los aspectos, que desde mi punto de vista debe ser tenido en cuenta a la hora de elegir el equipo es tener conocimiento de las tareas que hay que realizar en el proyecto y de las exigencias a nivel de calidad del cliente. Supongamos que el proyecto es técnicamente simple, si el proyecto es así, no se requirirá de personal con una altísima cualficación para realizarlo, ya que lo mismo este personal es capaz de realizar las tareas dos veces más rápido, pero lo mismo, su coste por hora es demasiado alto y es más interesante tenerlo en proyectos más complejos o en proyectos donde se puedan obtener mejores márgenes. Incluso si se decide para un desarrollo de esas características contar con personal de altísima productividad en la codificación (y por ello, supuestamente con un salario acorde a esas características y por tanto con un mayor coste por hora), no querrá decir que algunas tareas consideradas más simples o triviales no puedan ser desarrolladas por personal que todavía no tiene esa cualificación y por tanto con un coste por hora menor, de manera que ese recurso se centre en los aspectos más problemáticos o pueda ser compartido por más proyectos.
Sin embargo, si para la realización del proyecto se hubiera optado por personal de la organización con altos costes por hora o que la dedicación de estos al mismo fuese mayor que la necesaria, salvo que el proyecto estuviera muy bien vendido y/o que la productividad del equipo hubiera alcanzado cotas muy altas, conseguir el umbral de beneficio esperado podría considerarse como algo quimérico y de esta forma al esfumarse el margen que podría permitir cierta flexibilidad con el cliente y un esfuerzo para intentar conseguir un producto con la mayor calidad posible, empezaría a peligrar ese equilibrio entre beneficios y satisfacción del cliente, hasta el punto de que no haya ni lo uno ni lo otro.
Jummp 