Rumbo a Gestion de Calidad – Contexto Inicial I

Al finales del año pasado QBit inicio un proceso de Gestión de Calidad para uno de nuestros principales productos desarrollados para la Navegación Tridimensional (3D) sobre un inmueble, obra o equipos. Desafortunadamente para la empresa, no es posible mostrar imágenes sobre dicho producto por derechos de autor (Personalmente estoy en contra de algunos de los puntos ya que trunca la creatividad de las personas).

Volviendo al tema de Gestión de Calidad y situándolos en mi contexto, como Líder de Proyecto basaba  la calidad de nuestros productos en 3 puntos:

1. Apegarse a los requerimientos del cliente y plasmarlos en la aplicación.
2. Tratar de reducir los errores que pudiesen generar la aplicación.
3. Entregar los diversos módulos en el tiempo pactado con el cliente.

Para cada uno de los puntos el criterio y metodología que tomaba ha ido modificándose conforme ha crecido la empresa. Por ejemplo, inicialmente nosotros mismos realizábamos todas las actividades plasmadas en los 3 puntos. Es decir, yo como programador tomaba un requerimiento, lo diseñaba, lo desarrollaba y lo probaba. Que metodología utilizaba, sencillamente era la experienza.

Posteriormente, de los 3 puntos se modico el 1er y pasaron a ser 5, ya que nuestros clientes tuvieron la confianza en nosotros y nos delegaron la tarea de análisis y diseño de sistemas:

1. Apegarse a las necesidades del cliente y plasmarlas en la aplicación.
2. Hacer una interfaz intuitiva (en caso de que hubiera).
3. Tratar de reducir los errores que pudiesen generar la aplicación.
4. Entregar los diversos módulos en el tiempo pactado con el cliente.
5. Instalar y probar el producto en las instalaciones del cliente.

Entonces hubo la necesidad de que nosotros mismos acudiéramos a las reuniones para entender las necesidades y poderlas plasmas en algún documento. En aquel entonces, recuerdo que contratamos los servicios de una persona para que nos asesorara en la redacción de los Casos de Uso, leímos un par de documentos de UML y empezamos a levantar requerimientos. Al principio nos percatamos de que nuestros clientes  se les complicaba el entendimiento de algunos de los diagramas de UML, así que procedimos a solo elaborar diagramas de flujo con sus variantes y un documento mas o menos estandarizado de Casos de Uso.

Una vez terminado el Caso de Uso nuestro Analista capturaba las tareas en nuestra primer aplicación ToDo, y una o varias personas  se dedicaba a tomar una de las tareas y se dedicaba a hacer las actividades  restantes (los 3 puntos iniciales)  nuevamente de acuerdo a su propia experiencia.

Por último, nuestro Líder de Proyecto y Analista regresaba con la aplicación a las oficinas del cliente y realizaba el tortuoso proceso de instalar y probar el producto de la mano con el cliente.

Hasta este último punto, ya teníamos dos cosas que nos ayudaba a nuestro proceso de calidad:

1. Una plantilla estandarizada que nos ayudaba a plasmar las necesidades de nuestros clientes y lo mejor es que nuestros clientes entendían.
2. Una herramienta que nos ayudaba a saber el estado de las tareas ToDo y que el propio cliente podia ver.