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.

Desarrollo de software. El miedo a las decisiones

Hay que tomar decisiones, la mayoría de las veces no sabremos si hemos tomado el camino adecuado hasta que nos estrellemos o hayamos conseguido el objetivo, otras veces serán decisiones que no nos gustan tomar desde el punto de vista personal pero que son necesarias de realizar desde el punto de vista profesional.

Soy de la opinión que un gestor de proyectos, un gestor de equipos, un gerente, etc… que no toma decisiones en el momento adecuado o que no las toma por no molestar, no puede ser un profesional adecuado para ese perfil. Lo mismo es un excepcional profesional asumiendo otro rol, pero no lo es en un puesto donde la toma de decisiones es crucial.

Por este motivo soy de la opinión de que las organizaciones deben permitir carreras profesionales en horizontal y no solo en vertical porque muchas veces talentos en un área no lo son tanto cuando se les saca del hábitat donde mejor rinden.

Por supuesto que esto no trata solo de tomar decisiones, hay que intentar acertar en la mayoría de ellas y saber rectificar lo antes posible cuando se detecta un error, pero lo segundo es consecuencia de lo primero y, por supuesto, si te equivocas mucho corres también ciertos riesgos, si bien es algo con lo que hay que convivir porque son de los errores donde se aprende más.

Desarrollo de software. Los desarrolladores y el valor de las personas

Para unos perfiles eminentemente técnicos como es el que tenemos los desarrolladores de software resulta complicado entender que por mucha tecnología que hayamos aprendido o aprendamos, que por muchas asignaturas técnicas que hayamos tenido en la Universidad o en los Ciclos Formativos, lo más importante al final en el proceso de desarrollo de software son las personas.

Y son importantes no solo en el hecho de que son personas las destinatarias de nuestros productos sino que también es fundamental la participación efectiva de las mismas a lo largo del proceso de desarrollo. Personas componen el equipo de proyecto, la dirección de la organización, otros compañeros, los usuarios, los responsables técnicos del cliente, sus directivos, etc…

Ya he comentado en algunos artículos que buena parte del éxito de un proyecto se dirime antes de contratar el trabajo, cuando se negocia un alcance inicial, un esfuerzo y unos plazos necesarios. Si esta negociación ha ido mal o si bien no hay negociación sino que se acepta unas condiciones unilateralmente especificadas por la otra parte (que en la mayoría de los casos serán lo suficientemente abiertas para tenerte siempre pillado) y esas condiciones no son realistas con el trabajo a realizar, el proyecto nacerá condenado a tener problemas o a ser un Death March Project.

Es decir, sin haber realizado un trabajo de ingeniería o un trabajo técnico (salvo que se haya realizado un trabajo previo de preventa) se han marcado las cartas y se ha condicionado buena parte del trabajo que se realiza después.

Después, una vez iniciado el proyecto tenemos bastantes personas que tienen cosas que decir en el mismo (mejor eso que nadie), con distintas percepciones, objetivos, necesidades, implicación, etc… y que hay que intentar que alinear hacia una solución concreta.

¿No es importante entonces el factor técnico? Sí que lo es y mucho ya que el software no se desarrolla solo. La técnica es la que permite no solo ejecutar un producto con la mayor calidad posible (dentro de los márgenes que las condiciones iniciales del proyecto hayan permitido) sino es la que permite llevar a cabo de manera adecuada una metodología de desarrollo y obtener de las personas la información necesaria para realizar el proyecto y trasladarlo a un lenguaje inteligible y con las menores fisuras e incongruencias para el equipo de programadores.

No se entiende un correcto manejo de las interrelaciones personales sin una buena ejecución técnica como tampoco se entiende una buena ejecución técnica sin entender que el factor clave en los proyectos de desarrollo de software son las personas.

Desarrollo de software. Delimitar el alcance del proyecto

Tanto si vamos a trabajar con metodologías ágiles, como con otras metodologías como RUP y sobre todo, en ciclos de vida clásicos o en cascada, resulta fundamental delimitar cuanto antes el alcance del proyecto.

Como mínimo hay que llegar a una primera aproximación en la negociación del contrato con el cliente (cuanto mejor sea la misma, más variables se tendrán a favor para hacer una correcta valoración en esfuerzo y plazos del proyecto) y es más que recomendable hacer otra aproximación al inicio del proyecto.

Acotar el alcance no debe ser entendido como poner límites al proyecto, al menos en el sentido estricto, ya que a través de la propia evolución del software, la aplicación tenderá a ir hacia donde van las expectativas del usuario. Pero sí se debe entender como un marco hacia donde enfocar el desarrollo, ya que no todas las funcionalidades que se quieren implementar son iguales de prioritarias o críticas.

El proyecto debe centrarse en lo verdaderamente importante, dejando para más adelante aquello que no lo es. Probablemente no habrá presupuesto (por lo menos en primera instancia) para todo, por lo que lo primordial es cubrir lo que resulta necesario.

Si no delimitamos el alcance, se quedarán demasiadas puertas abiertas por detrás, con el riesgo de que el cliente o usuarios quieran volver a ellas. Es cierto que al final el proyecto va hacia donde quiere el cliente o los usuarios, pero no es lo mismo tener pactado por escrito un alcance que no tenerlo y no es lo mismo hacer pedagogía desde el inicio del proyecto que no hacerla.

Desarrollo de software. La información debe fluir dentro del equipo de proyecto

No hay peor síntoma en el funcionamiento de un equipo de proyecto cuando información importante que debe conocer un determinado perfil no le llega o le llega tarde.

Soy de la opinión de que la comunicación en un equipo de proyecto debe ser fluida, de manera que las problemáticas y contingencias sean conocidas por todos, así como los plazos y expectativas del cliente.

Habrá veces que por el bien del proyecto sea conveniente que determinado tipo de información no llegue a todos pero eso debe ser siempre excepciones, debidamente justificadas.

Si la información no fluye, empiezan los malos entendidos ya que cada cual tendrá a rellenar lo que quiere saber y no conoce con lo que está percibiendo y como nadie interpreta lo mismo de igual forma, se crea una brecha que no produce ningún beneficio al proyecto.