Los Magos de la Calidad con la Paradoja del Analista de Calidad: ¿Más Errores, Más Alegrías?"

Al dialogar con especialistas en calidad de software, como Analistas de Calidad, Analistas de Testing y Testers, se destaca su enfoque en la definición de casos de prueba, la ejecución de estos casos y la detección de errores en los productos.

Hace algún tiempo, planteé una pregunta a un grupo de 11 Analistas de Calidad: "¿Te sientes más satisfecho en tu trabajo al encontrar numerosos errores en las pruebas o cuando no los encuentras?"

Sin excepción, todos respondieron: "Cuando encuentro muchos errores". Este punto de vista refleja su objetivo de descubrir la mayor cantidad posible de fallos en los productos evaluados.

Sin embargo, este enfoque genera sentimientos opuestos en otros participantes del proyecto, como programadores, analistas funcionales, analistas técnicos, jefes de proyecto, gerentes de área y usuarios. Para ellos, la detección masiva de errores conlleva decepción, frustración y molestia, además del esfuerzo adicional por rehacer el trabajo, retrasos en la entrega, entre otros inconvenientes.

Es evidente que los Analistas de Calidad tienen una perspectiva diferente respecto al propósito del proyecto.

Si consideramos el objetivo del proyecto como la elaboración de un producto de calidad, el propósito del Analista de Calidad debería ser "no encontrar errores" o "asegurar la ausencia de errores en el producto", lo que les generaría satisfacción al cumplir su función.

No obstante, el problema radica en el momento en que se evalúa la calidad del producto: generalmente al final del proceso de fabricación. Muchos de los errores o defectos se originan a lo largo del proceso, desde el inicio con insumos deficientes, una ejecución deficiente de las actividades o especialistas con poco conocimiento y experiencia, lo cual impacta en la calidad del producto final.

Por ende, el enfoque del Analista de Calidad no debería limitarse a recibir un producto casi terminado para ejecutar pruebas y encontrar errores, sino centrarse en garantizar el cumplimiento de actividades y entregables con la calidad esperada. De esta manera, se previenen errores que podrían arrastrarse hasta el producto final.

Existen métodos adicionales para asegurar la calidad del producto a lo largo del proceso:

Identificar patrones de origen de errores en los entregables de cada fase del proceso y ajustar el proceso o asegurar su correcta ejecución.

Detectar patrones de comportamiento entre los colaboradores del proceso de fabricación para alinear y capacitar a fin de mejorar el cumplimiento de sus actividades.

Estas estrategias no solo mejoran la calidad en la fabricación del producto, sino que también elevan la calidad de los especialistas involucrados en el proyecto.

Los Magos de la Calidad ... algunos casos ...

En diferentes ocasiones nos cuesta revisar los entregables y los procesos que nuestros equipos de trabajo elaboran y ejecutan, pensamos que es engorroso y una pérdida de tiempo, siempre preferimos construir, desarrollar, crear cosas nuevas, en lugar de estar revisando y corrigiendo el trabajo de otras personas.

Alguna vez alguien me pregunto:  [[Para qué tanto control y metodología ...]], yo le respondí, "aun tenemos mucho por mejorar, porque aun perdemos mucho tiempo en retrabajos por los errores que detectamos en el producto.   Y porque esos retrabajos se realizaban a puertas de la entrega del producto, cuando ya no te quedaba mucho tiempo".

Si bien tenemos que corregir el producto antes de entregarlo, lo mejor es evitar generar estos errores en el momento que se elabora el producto.   Y se evita, ejecutando correctamente los procesos durante la elaboración.

Incluso el costo de la corrección del error es menor, en la medida que se detecte lo mas temprano posible.

Esta revisión que parece engorroso a lo largo del proceso de elaboración del producto, porque tenemos la idea de revisar todo el entregable o todo el documento para ver si no tiene ningún error.   No se trata de encontrar todos los errores, se trata de enfocarnos en la forma de trabajo del colaborador.    Es decir, asegurarnos que entienda el propósito de las actividades del proceso, de las políticas, de los artefactos, del producto final.   Si los comprende y los cumple, no debería existir problemas con los entregables y los productos.

Con este enfoque, donde nos aseguramos que se comprenda y se cumpla los procesos y entregables con calidad, la estrategia es revisar puntualmente una actividad o parte de una actividad, un entregable del proceso o parte de un entregable, con una frecuencia razonable y cubriendo la mayor cantidad de colaboradores del equipo, tipos de actividad o tipos de entregables.

En un ejemplo de desarrollo de software, sabemos que en la etapa de Análisis, necesitamos elaborar el Documento de Análisis, para ello, la revisión pueden realizarse de la siguiente manera:

Teniendo una política : "Todo avance de documento debe colocarse en el repositorio del proyecto", por lo que la revisión no implica reunirse con el Analista para revisar el documento, sino únicamente revisar el repositorio para buscar el documento de Análisis.  En caso no se encuentre se anotará una observación.   Por lo que esta actividad toma menos de un minuto.

En el caso de encontrarse el documento en el repositorio, el siguiente paso puede ser la revisión del cumplimiento del formato (en una primera instancia), sin necesidad de revisar (aun) la coherencia del contenido, si observamos que no cumple con el formato, o no completa el formato adecuadamente, también se anotará una observación.   Esto tomará menos de 5 minutos por documento.

En otro momento, se revisará la coherencia del contenido de un documento análisis, donde posiblemente, no se comprenda a cabalidad lo descrito.   O simplemente no sigue el formato previamente establecido que describe el flujo de una funcionalidad.   Ante ello, se registra una observación respecto a la deficiente descripción del contenido.  Posiblemente esto tomará aproximadamente 5 minutos por funcionalidad.

Estas observaciones permitirá al colaborador que elaboró el documento, buscar alinearse al procedimiento establecido para esta actividad, con lo cual se evitará arrastrar nuevos errores o incumplimientos posteriormente en otros documentos.   Asimismo, deberá corregir todos los documentos anteriores, no revisados.

De manera que se irán incluyendo nuevos temas de revisión a lo largo del proceso, sin necesidad la actividad o el entregable completo, sino mas bien, esto permitirá generar una cultura de calidad dentro del cumplimiento de los procesos, políticas y entregables del proyecto o servicio.

Los Magos de la Calidad con encantamientos y estrategias para potenciar proyectos y servicios

En el ámbito de los proyectos o servicios, nos enfrentamos a una serie de desafíos relacionados con la calidad, muchos de los cuales derivan del desempeño de los colaboradores. ¿Cómo podemos asegurarnos de que los colaboradores cumplirán con las expectativas del proyecto o servicio? Esta incertidumbre se agudiza cuando se trata de nuevos integrantes en el equipo. A pesar de las entrevistas y evaluaciones a los recién llegados, persiste la pregunta sobre cómo garantizarán el cumplimiento de las expectativas. Algunos incluso pueden pensar que cumplen con su tarea simplemente por hacerla a tiempo, sin considerar si lo entregado es útil para la siguiente fase o si los insumos recibidos están adecuadamente preparados.

Generalmente, se asume que cada colaborador cumplirá con su responsabilidad. Sin embargo, aunque se realice un seguimiento, este suele limitarse a la finalización de la actividad, sin asegurar que el entregable esté completo según lo especificado.

Así, los incumplimientos o errores se descubren en fases posteriores, cuando estos entregables se utilizan como insumos para actividades posteriores. Esta situación, bastante tardía, puede postergar el proyecto al requerir correcciones.

Los motivos de incumplimiento y errores pueden ser diversos:

- Desconocimiento del proceso operativo.

- Falta de comprensión del alcance.

- Ignorancia del nivel de calidad esperado.

- Bajo compromiso del colaborador.

- Insuficiente preparación técnica.

- Desconocimiento de los objetivos sobre su participación.

¿Cómo asegurarnos de que estos problemas no surjan o se minimicen durante el desarrollo del proceso?

El rol correspondiente debe inspeccionar el trabajo de cada colaborador, especialmente al inicio del proyecto cuando se está conociendo el mismo. A menudo se cree que debe esperar que se termine el entregable para revisar todo el contenido, lo cual requiere "mucho" tiempo. Pero el cambio necesario en los colaboradores no es tanto una revisión exhaustiva, sino un cambio cultural. Es crucial que comprendan que la mala calidad o los problemas en el servicio no son aceptables. Necesitan entender el proceso operativo, las políticas, el nivel de calidad esperado, el conocimiento técnico necesario y el propósito de su labor, para lograr cumplir con las expectativas.

Para lograrlo, solo se requieren revisiones puntuales y periódicas sobre el avance de la actividad, sin necesidad de que este terminado, verificando cualquier punto del proceso en el que se encuentra, cualquier política o nivel de calidad, sin necesidad de revisar todo.  Es esencial fomentar que los colaboradores estén comprometidos con entender y cumplir lo establecido. Además se evalúa el  nivel de conocimiento y experiencia técnica. Estas revisiones puntuales y breves de manera periódica, abarcando a la mayor cantidad de colaboradores en distintas etapas, permitirá alinearlos con los procesos y la calidad esperada, identificando deficiencias que corregirán y buscarán mejorar constantemente.

Asimismo, los colaboradores estarán más atento con cumplir con lo especificado en el proceso y las políticas, de manera que presentarán menos observaciones al momento de la revisión periódica.

A medida que se alineen y mejoren la calidad de su trabajo, el tiempo destinado a las revisiones disminuirá progresivamente.  Generando además, confianza entre los colaboradores del equipo.

¿Para qué tanto control y metodología?

Un día al término de la jornada laboral, antes de retirarme, un colaborador analista de testing, me pide una reunión, y entre diversos temas que conversamos resaltaron dos preocupaciones que tenía de los cambios que estabámos ejecutando.

La primera de ellas, "¿para qué tantos controles en el proceso?"

Para responder, recordé qué el colaborador tenía un negocio familiar, un restaurante.  Antes de responderle la pregunta, le formule una cuestión respecto a su negocio, "cuando tienes un cambio de turno de personal, y ellos salen con bolsas o maletines, ¿les revisan el contenido?", la respuesta fue afirmativa, entonces le hice una nueva pregunta, "¿por qué?", "porque en ocasiones se llevaban insumos, comidas o utensilios sin autorización".  Es decir, tuvo un problema y decidió aplicar un control para evitar que siga ocurriendo.   Adicionalmente los controles no siempre es por alguna ilegalidad que esté ocurriendo, sino simplemente para asegurar el cumplimiento de la actividad, así como, no se aplica en todos los casos sino a una muestra.   Y dependerá de la madurez del proceso y de las personas que la ejecutan, la necesidad de mantener el control.

La segunda pregunta, fue "¿para qué tanta metodología?", igualmente haciendo referencia a su negocio familiar, le pregunté, "¿cuál es el plato de bandera del restaurante?", "el lomo saltado", me respondió.  Adicionalmente le pregunté, "¿cuantos cheff tienen durante la semana? ", "tres cocineros", me respondió.  Le comenté que tenía mucha suerte, porque para tener tres cocineros, el sabor del lomo saltado era igual durante todos los días de la semana.  Y me comentó su secreto, "los platos tienen descrito un paso a paso que todos los cocineros lo deben seguir, para asegurar el sabor", entonces le dije, "esa es tu metodología".   La metodología te permite estandarizar la ejecución de las actividades, que permite en un primer momento asegurar el mismo producto en todo momento, con la misma calidad, característica, costos, etc., y adicionalmente te permite mejorar, optimizar y madurar el proceso y producto.

El temeroso y audaz colaborador que se atrevió (para bien...) a cuestionar los últimos cambios que veníamos aplicando, cambió en su perspectiva de cambios, logrando entender el propósito de las actividades.   Este cambio le permitió entender el resto de cambios, con lo que en el tiempo, asumió las responsabilidades de liderar el equipo de testing, luego la responsabilidad de calidad de los procesos, hasta el último reto asumido del equipo de desarrollo de software.

¿Pará qué tanto control y metodología?...

Comprar o desarrollar software

Muchas veces las empresas evalúan la posibilidad de desarrollar internamente o comprar un software que automatice cualquiera de los procesos de su negocio.

También hemos escuchado malas experiencias tanto en la compra de un software porque no se ajustaba a las necesidades del negocio; o malas experiencias en el desarrollo por el tiempo que tomó construirlo.

Antes que nada, considero que debemos tener claro que todo software estaba basado en un modelo de procesos o negocio. Por tanto, el software se adaptará a "mi proceso o mi negocio" en la medida que el modelo de "mi proceso o mi negocio" se asemeje en parte o gran parte del modelo de negocio o proceso sobre el cual se ha basado el software. Además todo proceso o negocio tiene un modelo definido, correcto o incorrecto, documentado o no, ordenado o no, pero al final es un modelo.

Para este evaluación sin considerar los factores económicos, políticos, culturales dentro de las empresas, únicamente nivel de modelo de negocio. Las pregunta que debemos hacernos son las siguientes, ¿tengo claro cual es el modelo de "mi proceso o mi negocio"?, si la respuesta es negativa, tendremos aterrizar todo el procesos involucrados o el negocio hasta conocer con claridad el modelo.

¿Considero que mi modelo es el adecuado para el soporte de mi negocio o mi proceso?, si la respuesta es afirmativa, iremos en busca de softwares cuyo modelo se asemeje al modelo de "mi proceso o mi negocio". Si la respuesta es negativa, tendríamos la oportunidad de buscar software cuyo modelo sea el adecuado para "mi proceso o mi negocio".

Cuando adquirimos un software más allá de obtener el paquete o la funcionalidad del software, obtenemos un modelo de procesos o un modelo de negocio para nuestra compañía, que se encuentra automatizada y que nos permitirá realizar nuestro trabajo de forma más productiva.

Es una errada decisión intentar adaptar el software adquirido con el modelo de "mi proceso o mi negocio" muy diferente a la del software, con ello estaríamos modificando el modelo de procesos o negocios del software adquirido.

Posiblemente no encontraremos un software cuyo modelo sea exactamente al modelo de "mi proceso o mi negocio", para ello, tendremos que considerar cuáles son las actividades o procesos críticos que deben estar automatizados y sobre el resto soportarlo manualmente o si los procesos o actividades no representan la parte crítica del modelo podemos realizar un desarrollo complementario al software. Que tan cerca al modelo de "mi proceso o mi negocio" debe estar el modelo del software para tomar la decisión de comprar, dependerá mas bien de que tan cuan crítica es la parte que no coincide con el modelo.

Si no encontramos un software cuyo modelo no se adapta al modelo de "mi proceso o negocio", la opción principal será desarrollar.

Adicionalmente, algunas consideraciones a tener en cuenta en una compra o desarrollo de software.

Ventajas de Desarrollar

• Se establece la funcionalidad del software acorde al modelo de procesos o de negocio de la compañía.

Desventajas de Desarrollar

• Demasiado tiempo para la implementación de la solución de software.
• Proceso de estabilización del software

Ventajas de Comprar

• Funcionalidad probada y estable
• Posibilidad de comprobar la calidad de la solución en implementaciones existentes.
• Menor costo total de implementación
• Menor tiempo de implementación

Desventajas de Comprar

• Funcionalidad cerrada, limitadas posibilidades de modificaciones, por riesgo a cambiar el modelo del Software.
• Normalmente adquisición sin código fuentes.
• Necesidad de recursos especializados en el software para el mantenimiento.

Organicémonos...

Muchas veces nos encontramos abrumados con la cantidad de requerimientos de sistemas que recibimos de nuestros usuarios, adicionales a la cantidad de problemas que nos reportan día a día, todo el equipo, toda el área de sistemas, esta abocada a atender las diferentes necesidades de nuestros usuarios, pero aún así, faltan manos para atenderlos todos. Finalmente, la situación conlleva a incumplimiento de fechas, postergación de la atención del requerimiento, insatisfacción del usuario, mala calidad del producto, estrés en el equipo de trabajo, etc.

En principio, debemos establecer una organización adecuada para la atención en el área de sistemas, si bien es obvio y la teoría lo dice, en la práctica, debido a nuestra desesperación, los roles en la organización no están definidos o no se cumplen. Tener claridad en cada uno de los servicios que el área de sistemas ofrece o es responsable, por ejemplo, soporte en la atención de incidentes tecnológicos de la compañía, atención de requerimientos de hardware y software, atención de requerimientos funcionales de las aplicaciones, desarrollo de proyectos tecnológicos, etc. Para cada uno de estos servicios tendremos definidos los procesos, perfiles, funciones y responsabilidades. Estos perfiles serán cubiertos por personas a quienes se les asignarán las funciones y responsabilidades para cumplir con la atención de los servicios del área. Debemos definir las responsabilidades para cada uno de los integrantes de nuestro equipo de trabajo, evitando que todos cubran todas las funciones o que todos realicen todas las tareas.

Ante la abrumadora cantidad de requerimientos, un punto muy importante, es establecer el procedimiento y las políticas de atención de cada uno de los servicios, donde se establece, quién debe solicitarlos, a través de que canal, como por ejemplo,

1. La atención de requerimientos, que corresponden a pedidos de nuevo hardware, software o funcionalidad adicional para las aplicaciones, en estos casos, debe ser solicitado o aprobado por el dueño del presupuesto del área solicitante, en vista que debe asumir el costo de la inversión o el gasto de la atención.
2. Para la atención de un requerimiento de funcionalidad adicional para una aplicación, deberá tener la aprobación del usuario dueño responsable de la aplicación, quien debe mantener el modelo conceptual definido para la aplicación, si no es así, cualquier persona solicitaría alguna funcionalidad sin los criterios del modelo conceptual.
3. Todos las solicitudes deben quedar registradas en una fuente de información o en todo caso a través de un solo canal de comunicación, o integrándolos, como Sistema de Mesa de Ayuda, a una cuenta de correo mesadeayuda@... o un número telefónico o anexo de la empresa que permita registrar la solicitud, eliminando cualquier pedido a través de un canal informal.
4. La solicitud debe ir acompañado de una prioridad o un orden de atención respecto a las solicitudes pendientes anteriormente ingresadas.
5. Toda atención completada debe tener la conformidad de la atención por parte del solicitante.

Para los servicios habrá un procedimiento de solicitud y atención que permitirá establecer el orden de los pasos a seguir, mientras que las políticas establecerán los principales requisitos para la atención.

Finalmente el registro centralizado permite no sólo tener la información en un sólo punto para hacer seguimiento a las atención, sino también permitirá explotar la información mediante estadísticas, para detectar y analizar los patrones de comportamiento, por ejemplo,

1. Incidentes por errores en las aplicaciones. Detectar patrones para priorizar la corrección del problema, en función al número de errores producidos y/o al impacto funcional del problema.
2. Requerimientos de hardware y software. Analizar compras periódicas para concentrarlos en compras por volumen.
3. Tiempos de atención de incidentes y requerimientos, que permitirá optimizar el número de personas para el área, así como definir el estándares de niveles de servicios para con el usuario cliente.
4. Estrategia de implementación de soluciones. La relación de los requerimientos de hardware y software priorizados, permitirá una adecuada planificación de la implementación y de inversión.

En resumen, organicémonos... de acuerdo a las funciones y responsabilidades por los servicios que brindamos, con ayuda de políticas y procedimientos, que son mejorados de acuerdo al análisis de estadísticas e indicadores, para identificar patrones y priorizar soluciones.