archivo

Archivo de la etiqueta: orientación al producto

En el caso de un equipo QC, su funcionamiento se puede orientar perfectamente a un procedimiento: recibo una entrega en un formato determinado, hago las tareas de verificación y devuelvo unos resultados. Se puede ser ajeno al conocimiento del producto y del proyecto (se trabaja sobre la documentación escrita por el equipo de desarrollo). Por eso muchas organizaciones que se dedican a prestar este servicios, tienden a crear factorías de testing, ya que el modelo encaja perfectamente, y de esta forma pueden ofrecer precios todavía más competitivos porque “da igual” que la persona que vaya a trabajar sobre la entrega conozca el producto.

Después la pericia de los técnicos QC les puede hacer llegar más lejos, ya que pueden hacer testing exploratorio y aplicar otro tipo de técnicas que les permitan que la detección de defectos sea más efectiva.

Un aspecto a tener en cuenta en el QC es que parte de su ahorro de costes es provocado por un incremento de los costes de desarrollo del producto porque el nivel de detalle de la documentación entregada (sobre todo la relativa a las pruebas) tiene que ser superior al necesario para suplir el desconocimiento del negocio y del producto por parte de los técnicos QC.

Este aspecto no se tiene en cuenta generalmente a la hora de implantar este tipo de servicios y es muy importante porque para valorar la efectividad de la implantación de un QC es necesario evaluar sus resultados frente a los costes directos (los del propio equipo del QC) como los indirectos (los que ocasiona en los proyectos).

¿Por qué es más frecuente encontrarnos con QC que con QA (pese a que a ese QC se le llame de manera equivocada QA)? Por motivos económicos, ya que el QA requiere una mayor implicación en el proyecto por parte de los técnicos que realizan este tipo de tareas (salvo que se haya elegido el camino de validar procesos en cuyo caso ese trabajo se simplifica), por lo que la definición de un equipo QA+QC requiere una mayor inversión.

Sin embargo, lo que nos vamos a encontrar con más frecuencia es la combinación de QA y QC pero con una orientación reactiva: entrega y validación.

Como veremos en el artículo de mañana que está centrado en lo que sería el QC (pero que es perfectamente extensible a un QA+QC reactivo), se llega a esa circunstancia principalmente por dos motivos: es lo más cómodo, ya que permite definir un modelo con un interfaz definido, desapegado de la realidad de los proyectos que se están ejecutando (al no formar parte de ellos) y por otro lado, por la errónea convicción de que son los procesos, procedimientos y metodologías los que mandan y los que hacen buenos o no el resultado final del proyecto.

¿Pero no es lo ideal que los equipos de calidad y desarrollo sean distintos? Mi propuesta no es incompatible con eso, ya que lo que estoy indicando es que un grupo de personas dentro o no del equipo de calidad colaboren con el equipo de desarrollo (incluso siendo parte de él si las circunstancias lo permiten) para que tanto los trabajos que se realicen en el mismo como los propios artefactos que se vayan a entregar al QC sean lo más efectivos posibles.

El control de la calidad (QC) es reactivo. Se ha llegado hasta el final y se realiza una entrega del producto y otros artefactos documentales asociados. En este punto, a lo más que se puede llegar es a la detección de defectos antes de su puesta en producción.

Estos defectos pueden ser de mayor calado, como por ejemplo, que alguno de los casos del plan de pruebas no funcione adecuadamente (se entiende que el plan de pruebas responde a la verificación de funcionalidades que implementadas adecuadamente y que, en conjunción con las demás, satisfarían las expectativas del usuario) o bien defectos de menor gravedad (alguna lista de valores no ordenada, algún enlace roto, algún mensaje de error demasiado críptico, etc…).

No es malo disponer de esta última línea de defensa, antes al contrario, puede ser muy interesante, pero su efectividad está muy condicionada por el trabajo del equipo de desarrollo, es decir, si se considera que una aplicación es válida porque cumple el plan de pruebas entregado por el desarrollador, estamos dejando toda la responsabilidad en ese plan de pruebas y todos sabemos que, salvo honrosas excepciones, los desarrolladores no somos expertos en eso.

Una cosa es que el desarrollador sepa qué es lo que tiene que hacer el sistema y otra que consiga plasmarlo en un documento, incluso con la mejor de las intenciones y dedicando el tiempo necesario.

Ante esta situación, lo más interesante resulta combinar ambos enfoques: QA y QC, porque cada uno, bien aplicado tienen repercusión en la calidad y valor del producto final.

Esto es así, siempre y cuando el QA, como he ido insistiendo en artículos anteriores, no se convierta en un simple verificador del cumplimiento de determinados procesos de desarrollo.

No digo que no haya que trabajar sobre algún aspecto del proceso, ya que estamos trabajando en una organización que requerirá unos ciertos mínimos para armonizar los desarrollos y estar informada sobre el estado de ejecución y presupuestario del proyecto.

La carga de trabajo y las contingencias de los proyectos en los que estamos trabajando provocan que los desarrolladores tengamos una visión muy acotada. Es lo que tiene estar en las trincheras, la preocupación es el presente y el corto plazo (a veces un poco más allá) de los proyectos en los que estamos trabajando.

Muchas veces se nos critica: “improvisáis, no tenéis un plan” (y muchas veces con razón), sin embargo, si hacemos las cosas bien, salvo excepciones (que ocurran hechos inesperados) no se improvisa, se trabaja con lo que hay y desde donde estamos, teniendo en cuenta la situación o contexto actual, siempre con intención.

Esta visión hace que en muchos casos no entendamos algunos procesos o los consideremos excesivos. A veces estaremos en lo cierto, otras veces equivocados.

Lo realmente importante es que exista una comunicación fluida entre todos los implicados con el objeto de buscar soluciones a los problemas y de esta forma conseguir de manera efectiva una mejora continua.

No se trata, por tanto, de eliminar los procesos, sino de que sean racionales y ajustados a lo que la organización necesita y puede soportar y nunca de espalda a la realidad de los proyectos de desarrollo de software que se realizan y el presupuesto con el que se puede contar en los mismos.

El término aseguramiento de la calidad se ha extendido a tareas de prevención en el momento en que se está desarrollando (detección de defectos, adecuado seguimiento de un proceso y/o una metodología) y a las tareas que se realizan una vez que se entrega una determinada versión de un producto o de un artefacto (que puede ser un determinado documento exigido por el proceso de desarrollo).

Y es que aseguramiento de la calidad (QA) vende más que control de la calidad (QC), porque asegurar resulta más rotundo que controlar.

El aseguramiento de la calidad está orientado a la prevención, pretende ser, por tanto, proactivo, lo que requiere que sea una parte más dentro del proyecto y suele centrarse en aspectos relacionados con el proceso de desarrollo y testing.

El hecho de que se considere que el QA está orientado al proceso, en mi opinión, ha restado efectividad a su aplicación porque el producto nunca debe quedar en segundo plano y en el momento en que se transmite el mensaje (aún con la mejor de las intenciones) de que la calidad está en el proceso empieza a interpretarse por los responsables del QA de que lo valioso es el procedimiento y que si se sigue probablemente el proyecto tenga éxito.

Curiosamente si se falla, será culpa de las personas por no haber seguido adecuadamente el proceso. Este doble rasero: las personas son secundarias porque quien asegura la calidad es el proceso, pero si todo falla los culpables son las personas, no lleva a nada bueno porque crea una espiral que irá separando a los equipos de desarrollos de los encargados del QA y que por regla general, si no se corta, agudizará el problema porque la respuesta del QA será hacer todavía más rígidos los procesos, hacer más severos los controles y si se siguen sin conseguir objetivos seguirá siendo culpa de las personas y así hasta el infinito.

Producto, siempre el producto, por encima de los procesos, sin que estos deban obviarse o dejarse de lado.

Se ha enfocado y asociado de manera errónea la calidad del producto a la calidad del proceso, lo que ha provocado que los esfuerzos se hayan centrado en el proceso, de tal forma que en muchos casos se considera un fin y no un medio para conseguir el verdadero objetivo que es desarrollar software de calidad.

Y todavía peor que eso, se asocia en muchos casos la calidad del proceso a la cantidad del papel generado y por tanto, de manera transitiva, el producto software era tan bueno como kilos de papel se hubieran generado en el desarrollo.

Por ese motivo, la realización de análisis o conclusiones finales sobre proyectos que se centren exclusivamente o principalmente en aspectos procedimentales me parece un error, entre otras cosas porque incluso en aquellas circunstancias en las cuales el proyecto haya ido bien y haya sido a nivel de proceso ejemplar nos podemos encontrar con que el producto final es muy costoso de mantener por tener una deuda técnica alta o por tener una arquitectura no escalable.

El proceso debe estar al servicio del producto y a las necesidades que se tengan en su proceso de desarrollo, las cuales estarán muy condicionadas por las circunstancias y contexto en que se realiza.

Cuando estamos desarrollando o manteniendo un producto es fundamental que todos los que participan en el proyecto lo conozcan. Esto puede parecer evidente, pero no lo es tanto en perfiles altos que tienen que repartir su tiempo entre más proyectos y no tienen en cuenta tanto el detalle como en perfiles que se encargan tareas muy concretas.

Pues bien, tanto en un caso como en otros es esencial conocer en profundidad en qué se está trabajando, tener tu mismo la sensación de utilizar el producto, probablemente coincidas en bastantes aspectos con el usuario y termines por comprender muchas de sus demandas.

Si para ti el producto no es agradable de utilizar no lo será para el usuario, si a ti te falla, también lo hará para el usuario.

En el caso de organizaciones orientadas al desarrollo y ventas de productos finales o de servicios sobre esos productos finales y los mismos pueden encajar perfectamente en su gestión interna, da muy mala imagen cuando se intentan vender y no los usas, ¿por qué me quieres vender algo que tu ignoras o desprecias?. A lo anterior se le suma la oportunidad de tener una experiencia de usuario interna que te ayude a reconocer mejor los puntos fuertes del producto y a corregir sus debilidades.

El beneficio viene a través del producto y de la satisfacción del usuario. El que se obtiene a espaldas de ambos es efímero, flor de un día y en lugar de dejar un campo sembrado dejas solo desierto.