Gestión de Calidad


9
feb 12

Rumbo a la Gestión de Calidad – Proceso y Procedimiento

No Gravatar

Lo prometido es deuda, en la siguiente imagen se ilustra el proceso general que realiza QBit para el desarrollo de una aplicación de un cliente.

Los cuadros azules son procedimientos, los cuadros blancos son documentos, los cuadros verdes son productos y los rombos rojos son puntos de inspección. Interpretemos ahora el diagrama que ilustra este sencillo proceso:

  1. El Cliente debe de tener un procedimiento para elaborar un requerimiento para cierta funcionalidad que necesita implementar.
  2. En el punto de inspección, QBit debe tener claro los requerimientos.
  3. QBit elabora una propuesta de acuerdo a los requerimientos.
  4. El Cliente debe aprobar la propuesta y emitir una Orden de Trabajo.
  5. Qbit debe de encargarse de la Gestión del desarrollo de la aplicación en base a la propuesta.
  6. El Cliente debe de vivir feliz y contento con su nueva aplicación ya instalada y funcionando en sus instalaciones :D

Como les comentaba anteriormente, todos los cuadros azules dentro de un proceso deben de tener un procedimiento para su entendimiento. Dado que la Gestión de Calidad no es para el Cliente, es únicamente para el QBit, los procedimientos que se deben documentar son … piensen, piensen … los de la columna de QBit.

Ahora tomensen su tiempo (yo me tome el mio para desarrollarlo) para ver la siguiente imagen que representa el “Procedimiento Gestión de desarrollo de una Aplicación” y comenten sus dudas (quiero retroalimentación).

Compartir y Disfrutar

  • Facebook
  • Twitter
  • Delicious
  • Digg
  • StumbleUpon

26
ene 12

Rumbo a la Gestión de Calidad – Terminología

No Gravatar

Antes de continuar con el tema, seguramente los expertos en el rubro, tendrán muchos comentarios que realizar sobre el proceso o términos que estamos utilizando, esperando que nos lo hagan saber a través de este post.

Es necesario meternos poco a poco con cierta terminología sobre el tema que estamos tratando, esperando meter pocos términos en esta metodología y mas imágenes para fines de hacerla mas entendible y utilizable. Primero se debe entender que todo proceso, necesita una entrada y una salida (ver imágen Diagrama Proceso).

Podría sonar trivial para muchos de nosotros el diagrama anterior, pero cuando se inicia a plasmar las ideas un diagramas de flujo es donde uno puede entrar en confusiones. Definamos cada uno de los conceptos del diagrama anterior:

  • Materia Prima: cualquier recurso necesario para realizar el proceso. Puede ser personas, especificaciones, casos de uso, etc.
  • Proceso: conjunto de actividades que se realizan para generar un fin en común (el producto)
  • Producto: resultado del proceso. Puede ser personal capacitado, aplicaciones TI, caja de cerillos, etc.

En la siguiente imagen se ilustra la forma en que se constituye un proceso:

Creo que la imagen dice mas que 193 palabras, es decir, “un proceso esta constituido por uno o varios procedimientos y un procedimiento esta conformado por una o varias tareas, los procedimientos no se pueden repetir y las tareas si se pueden repetir”.

Una vez que hablamos el mismo idioma es momento de definir un proceso, pero eso … es otro tema :D

Compartir y Disfrutar

  • Facebook
  • Twitter
  • Delicious
  • Digg
  • StumbleUpon

19
ene 12

Rumbo a la Gestión de Calidad – Primeros Pasos

No Gravatar

En este proceso de preparación para preparar a la empresa en su incursión al área de Gestión de Calidad hemos identificado 3 puntos:

  • Dedicar una persona que conozca el proceso y que este de tiempo completo (el cual lo llamaremos Gestor de Calidad – que originales).
  • Que todo personal del proyecto (analistas, desarrolladores, usuarios, clientes, etc.) se involucre en el proceso de gestión (los cuales le llamaremos Actores). Sobre todo se requiere mucho de la intervención de los directivos.
  • Iniciar con un solo proyecto (el cual lo identificaremos como Proceso). Seguramente se podría empezar con la administración de la empresa para iniciar nuestro proceso de gestión, pero al no tener claros los recursos (económicos y tiempos) que implica la adquisición del proceso, preferimos enfocarlos en el tema que conocemos.

Por donde empezar

Los primeros pasos que debe de seguir antes de iniciar con el proceso son:

  1. Conciliar con todas las áreas el Manual  de Codificación de Documentos.
  2. Generar el organigrama de los participantes del proceso.
  3. Establecer el procedimiento de comunicación donde se debe establecer los mecanismos que permitan la adecuada comunicación entre las partes interesadas con relación al proyecto.

Codificación de Documentos

En este punto es necesario involucrar a todas las áreas de la empresa (ojo, no del proyecto en cuestión) debido a que este sistema de codificación va a ser adoptada como una norma en la empresa.

En este punto seguramente le van a dedicar mucho tiempo, porque sabemos lo difícil que es conciliar la codificación entre las diversas áreas (si a veces es difícil ponerse de acuerdo con tu espos@, imaginen con otras tantas personas).

Compartimos con ustedes la codificación que hemos adoptado (ojo, de acuerdo a nuestras necesidades) ya que como es costumbre, hemos iniciado el desarrollo de un Sistema de Codificación de Documentos (SCD):

EM-AR-TD-YYYY-CC/rrr

donde:

  • EM: empresa que emite el documento.
  • AR: área de la empresa que emite el documento.
  • TD: tipo de documento (minutas, oficios, etc.).
  • YYYY: año en el que se emitió el documento.
  • CC: consecutivo por año de acuerdo a los primeros tres campos.
  • rrr: numero de revisiones que ha tenido el documento.
Bueno, por el momento tienen bastante chamba que hacer (y yo también). Espero que les sea de utilidad y ojala publiquen sus comentarios.

 

 

 

Compartir y Disfrutar

  • Facebook
  • Twitter
  • Delicious
  • Digg
  • StumbleUpon

12
ene 12

Rumbo a Gestion de Calidad – Contexto Inicial II

No Gravatar

El problema no termino en este punto.  Sabíamos que nuestro cliente quedo satisfecho con el producto recién entregado, pero quedan varios huecos en el proceso que a continuación los enumero:

  1. El cliente nos llamada y exigía garantía del producto por errores.
  2. No teníamos métricas que nos indicaran que el proyecto desarrollado daba una ganancia para la empresa.

Para el primer caso y con la finalidad de que el cliente nos siguiera contemplando para futuros proyectos,  les solucionábamos el problema sin importar que el costo lo absorbiera la empresa, aunque en la mayoría de los casos el error se derivaba de una mala o por una omisión a la definición del proyecto por parte de nuestro cliente.

Para el segundo punto, y como buenos desarrolladores, nuevamente el equipo de QBit inicio con el análisis y desarrollo de Celestic, una nueva aplicación que nos diera una visión mas cercana de los costos que tiene el desarrollo del proyecto llevando un control de las actividades que tiene cada uno de los involucrados del proyecto.

Hasta este momento, todo parecía que marchaba bien, pero unos de nuestros principales clientes nos exige tener un proceso de Control de Calidad del producto que le estamos desarrollando y como buenos samaritanos iniciamos con el proceso.

Compartir y Disfrutar

  • Facebook
  • Twitter
  • Delicious
  • Digg
  • StumbleUpon

5
ene 12

Rumbo a Gestion de Calidad – Contexto Inicial I

No Gravatar

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.

 

Compartir y Disfrutar

  • Facebook
  • Twitter
  • Delicious
  • Digg
  • StumbleUpon

Qbit Mexhico Blog is using WP-Gravatar