archivo

Archivos diarios: junio 2, 2010

No termina de sorprenderme que en ocasiones se pongan a determinados desarrollos de software dos precios, uno si se quiere un nivel de calidad “de serie” y otro si se quiere un nivel de calidad “mayor”. Lo pongo entre comillas porque generalmente pese a que se pone precios a uno y a otro, no se termina de precisar en la mayoría de los casos en qué consiste cada una de esas calidades y qué requisitos mínimos se deben cumplir en cada una de ellas.

Es cierto que suelen tener asociados una declaración de intenciones, pero en la mayoría de los casos no se llega a más de eso, entre otras cosas porque a la mayoría de las empresas de desarrollo de software les cuesta comprometerse a este tipo de aspectos, ya que si de por sí el desarrollo puede convertirse en algo complicado, todavía lo podría ser más si se comprometen a cumplir determinados objetivos en métricas de calidad del software (no me centro en este artículo en lo que son aspectos méramente funcionales) ya que puede convertirse en un factor de riesgo importante para que el proyecto incurra en pérdidas para el proveedor.

Pero una cosa es que no me sorprenda y otra cosa es que comparta totalmente este tipo de situaciones, ya que parece que se da por hecho que en el producto de serie no se van a controlar determinadas métricas de calidad y que si quieres que se empiecen a controlar algunas, entonces tienes que pasar por taquilla. Lo que puede permitir diferenciar a una empresa de otra en este aspecto es incorporar en sus procesos de desarrollo de software, en sus frameworks, en sus generadores de código (si tienen), etc…mecanismos para conseguir un nivel aceptable en métricas de calidad, de esta forma la empresa puede comprometerse de base a unos determinados umbrales en las métricas minimizando el riesgo de sobreesfuerzo y mayor coste en el proyecto (es razonable que estas tareas requieran más esfuerzo, pero también lo es que si forma parte de sus procesos de desarrollo el esfuerzo será mucho menor, ya que no será necesario una adaptación a una forma diferente de trabajar, sino que es la forma natural de hacer las cosas).

Si un cliente quiere calidad debe pagarla, eso está claro. Con presupuestos infravalorados conseguirla resulta muy complicado, salvo que el proveedor haga un esfuerzo importante (asuma las más que probables pérdidas), algo que hará o no según le convenga. La calidad, por tanto, y no descubro nada nuevo, vale dinero. La clave para los posibles proveedores es comprometerse a unos determinados niveles de calidad en sus desarrollos y que cada uno proponga unos precios en función de lo que les cueste conseguir esos valores. Como resulta razonable, la combinación calidad/precio es la que por regla general más adecuada va a ser para estos casos, aunque no tiene por qué ser un hecho determinante, ya que la criticidad de la aplicación puede hacer que sea necesario comprometer un mayor nivel de calidad o que el presupuesto del proyecto no permita hacer grandes dispendios.