Desarrollo de software. Oficinas de calidad, ¿modelo obsoleto?
He tenido que escuchar muchas veces que el modelo de Oficinas de Calidad es obsoleto y cuando lo escucho siempre me hago la pregunta de si lo que está obsoleto es el concepto, el método que usan o ambas cosas.
El primer problema de las Oficinas de Calidad es tener precisamente ese nombre, me da miedo bautizarlas con otro nombre porque lo mismo es hasta peor, pero lo que está claro que ese término muy ligado a las consultoras no le hace ningún bien al equipo de profesionales que lo integran.
Se dice que el principal objetivo de las Oficinas de Calidad es certificar aplicaciones y se asocia en muchas ocasiones como estrategia de venta certificación a ausencia de errores y yo me pregunto, ¿de verdad se puede certificar una aplicación como libre de errores con los presupuestos que estamos manejando para la realización de tareas de testing y con la calidad media de los desarrollos que se realizan?, eso en mi opinión es otro error que si bien puede ayudar a vender este tipo de servicios, al final resulta perjudicial para los mismos.
Realmente lo que puedes certificar es que has realizado una serie de revisiones a lo largo del ciclo de vida del desarrollo siguiendo una determinada metodología y que tras una serie más que probable de vueltas a atrás de diferentes items del proyecto se ha superado el umbral de calidad definido para esa aplicación.
Supuestamente la superación de ese umbral debería garantizar la puesta en producción de una versión del producto adecuada a la naturaleza y criticidad del proyecto, si bien, pretender garantizar otra cosa resulta complicado salvo que los mecanismos de control de calidad del software sean muy férreos y realizados por personal muy experimentado, algo que solo nos encontraremos con proyectos especialmente críticos.
Soy de la opinión de que las Oficinas de Calidad (las voy a llamar así en este artículo) no son modelos obsoletos, lo obsoleto puede ser la forma en que funcionan muchas de ellas sobre todo cuando se invierte más esfuerzo del necesario en el continente que en el contenido.
¿Por qué pueden funcionar mal? Pues porque no aplican una metodología acorde con las necesidades de la organización a la que prestan servicio o porque simplemente no aplican ninguna metodología. Sobre esto quiero decir que en muchas ocasiones esa metodología está muy condicionada por el cliente que realmente enfoca el trabajo de la Oficina de Calidad a unos objetivos no necesariamente alineados y compatibles con la naturaleza y calidad del software que se desarrolla.
Creo que debe existir una metodología, unas herramientas que automaticen o den soporte a las tareas de testing, que la metodología debe ser adecuada a la naturaleza del software que se desarrolla en la entidad a la que prestan servicios, que cada aplicación debe tener su propio itinerario de testing y que exista un personal formado y motivado para realizar este tipo de trabajo.
Jummp 
nada es bueno o malo, sino todo lo contrario.
Las OdC son buenas, ya que hay revisiones externas. Como las auditorías. Son buenas.
Pero luego hay que ver como funciona la OdC.
Yo las he visto eficientes y eficaces. Que hacen que todo funcione de forma correcta.
Pero tb las he visto torpes y lentas.
Un gran simil es el de los árbitros. Si no se habla de ellos, es que lo han echo bien. Y si se habla, es que algo han echo mal.
Aparte, como los árbitros, creo que las OdC son necesarias para un desarrollo correcto (almenos en las formas).
Pero hay que controlarlas para que no se conviertan en un punto de poder (otro simil con los legisladores: deben controlar, pero no imponer por su posición dominante).
He visto casos en los que la OdC cree que está por encima del bien y del mal, y eso conlleva a retrasos absurdos que consiguen hacer que los proyectos sean más caros, «quemen» al proveedor, y sobre todo al cliente.
Has descrito estupendamente los puntos fuertes y debilidades que tienen las Oficinas de Calidad tanto si tienen un comportamiento adecuado como si se desvirtúa su funcionamiento.
Soy partidario de la existencia de Oficinas de Calidad pero con modelos donde se sientan integrados como parte de un departamento de desarrollo y que entiendan cómo es realmente un proyecto de desarrollo de software.
Creo que poco a poco las Oficinas de Calidad están entendiendo cómo pueden ser útiles realmente sin perder su enfoque principal que no debe ser otro que intentar que el producto software llegue a producción en las mejore condiciones posibles (con las menores desviaciones respecto a las especificaciones del usuario, con el menor número de errores posibles, eliminación de errores críticos, etc…).
Pingback: Desarrollo de software. Los testers son desarrolladores « Jummp