archivo

Archivos diarios: noviembre 5, 2010

Debería ser algo habitual, aunque no lo es, que existiera en cada empresa de desarrollo de software unos procedimientos internos de control de calidad de todo el proceso (puede que en muchos casos existan, otra cosa bien distinta es que se apliquen) y por otro que el cliente tuviera otros controles más específicos y orientados tanto a las características de su negocio, como de su arquitectura y tecnología.

De esta manera se podría responder a la pregunta, ¿cuánto es suficiente? indicando que tanto como determine la unión de los procesos de control de calidad internos y del cliente que te ha encargado el proyecto.

Por tanto, resultaría de interés para las empresas proveedoras de desarrollo de software conocer las características en cuanto a los procesos de calidad del proceso de desarrollo de los posibles clientes con los que estuviera interesado en colaborar ya que permitirá tener en cuenta el coste adicional que tienen dichos procedimientos en el desarrollo y además los tendría en cuenta a la hora de realizar la posible oferta.

El problema nos lo encontramos cuando el proveedor, el cliente o ambos no tienen procedimientos de control de la calidad en el proceso de desarrollo. Analicemos algunas de las posibles consecuencias de estas carencias:

– Carencias en el proveedor y no en el cliente: Salvo que se lleve trabajando mucho tiempo con clientes con procedimientos de calidad establecidos, la ausencia de procesos de calidad internos en el proveedor provocará que no se dé la importancia que se merece a los procedimientos impuestos en el cliente ya que no existe costumbre en los procedimientos de trabajo de los equipos de proyecto en seguir una serie de pautas que les obliguen a hacer las tareas de una determinada manera.

Si los procesos del cliente son rígidos provocarán, en la mayor parte de los casos, devolución de entregables y la repetición de determinadas tareas por parte del proveedor que podrían haberse evitado con la existencia de una mayor conciencia en el trabajo orientado a procesos. Existen clientes que ya sea a través de acuerdos de nivel de servicio o a través de determinadas cláusulas contractuales penalizan estas vueltas a atrás, ya que les supone un esfuerzo en la realización de estas tareas que es responsabilidad del proveedor y por tanto repercutirá negativamente sobre su facturación.

Si los procesos del cliente son más suaves, el proveedor no acostumbrado a estos procesos se sentirá más cómodo, pero igualmente existirán siempre unos mínimos que deberá cumplir cuyo incumplimiento darán lugar a situaciones como las descritas en el párrafo anterior.

En ambos casos, el listón sobre la calidad del proceso de desarrollo lo coloca el cliente y en términos contractuales debería ser suficiente, no obstante, soy de la opinión de que toda empresa que se dedica a prestar este tipo de servicios debe tener (cumplirlos y ser verificados) unos procedimientos internos que rijan el proceso de desarrollo y que sean comunes, salvo circunstancias especiales, para los diferentes proyectos que se ejecuten, ya que eso permitirá dar a la calidad de los desarrollos unos mínimos comunes a todos los proyectos que podrían servir como seña de identidad.

– Carencias en el cliente y no en el proveedor: En este caso el cliente estará a expensas del nivel de calidad interno del proveedor en el proceso de desarrollo, lo cual conllevaría a un escenario de calidad no uniforme en los proyectos, ya que normalmente cada proveedor tendrá unos procesos diferentes.

Si se quiere dar uniformidad a los desarrollos que se realizan para una organización es necesario la existencia de unas normas de calidad, de lo contrario se llega a una situación de descontrol donde la realización de mantenimientos se hace más costosa, donde existe una mayor cautividad respecto a los proveedores y donde la variedad de frameworks, tecnologías y componentes pintan un paisaje tremendamente complicado de gestionar a todos los niveles (afectando no solo a los departamentos de desarrollo, sino a los de sistemas, explotación, etc…).

– Carencias en el cliente y el proveedor: El escenario es similar al anterior, con el agravante de que ni siquiera el proveedor tiene unos procesos para controlar la calidad de su proceso de desarrollo, lo que dará lugar, por regla general a resultados por debajo de las expectativas y a que no se pueda tener una completa confiabilidad en los trabajos del proveedor ya que la responsabilidad de la calidad de las entregas repercute sobre el interés que tenga el equipo de proyecto en la realización de determinadas actividades en ese sentido, lo que implica que en unos proyectos el resultado puede ser mejor y en otros peor.

Anuncios