planificación

Planificación de un proyecto de implantación y certificación de un SGC según ISO 9001

jmartinmateo, , 1 Comment

Ya he hablado en este blog sobre la metodología y los principios a seguir en un proceso de implantación de un Sistema de Gestión de la Calidad (SGC) según ISO 9001.

Ahora me gustaría tratar con algo más de detalle las fases a seguir en un proyecto de este tipo. En concreto, me voy a centrar en la fase de Planificación (la P del ciclo PDCA).

Bajo mi punto de vista, los hitos más relevantes son:

1. Diagnóstico de la situación.

2. Obtención del compromiso de la Dirección con la implantación. Definición de la política de la calidad

3. Elaboración de un plan de actuación para la implantación y la certificación.

Vamos a verlos ahora con más detalle.

Diagnóstico

En esta fase es conveniente revisar la forma como se está (o no se está) gestionando actualmente la calidad en la organización.

Cuando actuamos como consultores externos, es importante dedicarle el tiempo necesario a esta fase. Se trata de comprender lo mejor posible la forma como actualmente está trabajando la organización. Hay que preguntar mucho y escuchar de forma activa, hacer participar al máximo de personas que vayan a estar afectadas por el proyecto y ser muy empático.

En esta fase, y de acuerdo con la Dirección, podremos definir el alcance más adecuado para el sistema, el tiempo que se le va a dedicar y los recursos necesarios.

Pero también, mediante el diálogo con todos los implicados, deberemos ser capaces de detectar posibles elementos de resistencia al cambio y también  posibles riesgos que puedan dificultar la consecución de los objetivos del proyecto. Como consecuencia, uno de los resultados de esta fase será un listado de alto nivel de los riesgos del proyecto junto con posibles acciones a realizar en relación a ellos.

Compromiso de la Dirección

Para empezar, se debe obtener un compromiso formal de la Dirección en relación a la implantación. Ésto es básico y si no se logra es razón suficiente para no continuar con el proyecto. Uno de los primeros entregables debe ser la definición junto a la Dirección de una Política de Calidad.

También es necesario hacer un análisis de las necesidades de los clientes, establecer métodos para medir su nivel de satisfacción y planear cómo se va evaluar a proveedores (si no se estaba haciendo ya) y analizar cómo se tratan las incidencias y/o reclamaciones de los clientes.

Acabaremos esta fase fijando los objetivos de la calidad, de acuerdo con la Dirección y con los implicados en conseguirlos.

5222966685_92f9cdc084_o

Strategic Plan – cortesía de Alper Çuğun mediante licencia CC by 2.0

Elaboración de un plan de actuación

La implantación de un sistema de gestión de la calidad debe enfocarse como un proyecto. Debe tener un alcance definido, un presupuesto y un calendario.

Al igual que es fundamental obtener el compromiso de la Dirección, también es básico designar un responsable de dirigir este proyecto. Es conveniente que sea una persona de dentro de la organización, que sea buen conocedor de su cultura y de su estructura.

También es importante que este persona tenga un perfil que le permita liderar el proyecto y ser capaz de comunicarlo adecuadamente dentro de la organización. De hecho, probablemente la actividad a la que tenga que dedicar más tiempo dentro del proyecto sea la comunicación.

Es posible que internamente dispongamos de personas con este perfil pero que no tengan conocimientos sobre gestión de la calidad. Eso no es invalidante, bajo mi punto de vista. En caso de encontrarnos en esta situación será conveniente formar adecuadamente a la persona escogida y ayudarla con un consultor externo que aporte el conocimiento sobre la gestión de la calidad y la experiencia en su aplicación en otras organizaciones.

Doy por supuesto que la persona escogida está completamente comprometida con el proyecto y dispuesta a asumir el rol de agente de cambio en la organización, en complicidad con el consultor externo. Bajo mi punto de vista, tan importante es la aptitud como la actitud.

¿Qué opináis sobre la fase de planificación? ¿Cuál es vuestra experiencia al abordar este tipo de proyectos en vuestras organizaciones?

Planificación de un proyecto de implantación y certificación de un SGC según ISO 9001

El proceso de test en el desarrollo de software

jmartinmateo, , , , , Leave a comment

La calidad del software que generamos para nuestras organizaciones es muy dependiente del esfuerzo y tiempo dedicados a su testeo.

No obstante, ese esfuerzo debe ser objeto de un análisis crítico que asegure que los resultados obtenidos compensan el coste dedicado. Por otra parte se debe ser consciente de los riesgos asumidos al limitar el esfuerzo de test. Como en muchas otras situaciones de la vida, se trata de buscar el equilibrio.

De acuerdo con el ISTQB el proceso de test debe seguir las siguientes fases:

  • Planificación y control
  • Análisis y diseño
  • Implementación y ejecución
  • Evaluación y reporte
  • Cierre

 

Estas fases se suceden secuencialmente, si bien el control debe seguirse durante todas las fases del proceso, no sólo en la planificación inicial.

1. Planificación y control

Debe iniciarse, idealmente, lo antes posible dentro del ciclo de desarrollo del software. Es preciso completar un plan de test que incluya:

  • recursos necesarios,
  • tiempo estimado,
  • servicios, medios adicionales,
  • herramientas, …

El testeo exhaustivo es, por lo general, imposible. Es preciso, por tanto, definir prioridades y analizar los riesgos de omitir determinados tests o de limitar su intensidad o alcance.

2. Análisis y diseño

En esta fase se determinan las técnicas de test a seguir, alineadas con la estrategia definida en el paso anterior, se definen los casos de test y el calendario o secuencia. En paralelo se deberá poner en marcha la infraestructura necesaria para realizar los tests.

3. Implementación y ejecución

A partir de los casos de test definidos de forma lógica en la fase anterior se derivarán y ejecutarán casos de test concretos.

En esta fase es preciso seguir un protocolo de test que incluya las partes a testear, las personas asignadas, los tiempos y calendarios, la extensión de cada test a realizar y los resultados esperados.

Además, es fundamental realizar un registro de los resultados.  Éstos nos pueden llevar a plantearnos si los posibles errores encontrados están dentro o fuera del objeto del test y, consecuentemente, a replantearnos el protocolo diseñado y seguido.

Al mismo tiempo, los errores encontrados deben ser documentados, priorizados y asignados a los desarrolladores para solucionarlos.

En otra entrada entraré en mayor detalle pero aquí quiero comentar la importancia de agrupar los casos de test en secuencias y/o escenarios y de realizar primero los llamados “smoke tests” que permitan verificar la bondad de las funciones principales antes de entrar en  casos más detallados y completos (que no tienen sentido si los tests básicos no han sido superados).

4. Evaluación y reporte

En esta fase empezaremos por evaluar si los criterios de finalización de los tests han sido alcanzados.

En caso negativo será preciso analizar si se ha debido a que algunos casos de tests han tenido que ser bloqueados o si es preciso añadir más casos de test.

Para tomar una decisión razonada, como siempre, habrá que tener en cuenta tanto los riesgos asociados con no añadir más casos de test como los costes (dinero y tiempo) de hacerlo.

En cualquier caso, finalizaremos esta fase con un informe que incluya todos los resultados y las conclusiones y decisiones tomadas.

5. Cierre

Esta fase, desgraciadamente, suele ser olvidada en, muchos proyectos.

La experiencia obtenida durante el proceso de test debe ser analizada y puesta a disposición de otros proyectos. En otro post de este mismo blog ya he hablado sobre ello dentro del contexto de la gestión de proyectos en general.

La documentación y aplicación de los resultados de una evaluación crítica de las actividades realizadas durante el proceso de test, considerando esfuerzo en relación a resultados, nos llevará a la mejora continua.

Para acabar, otro punto a tener en cuenta en esta fase final es la necesaria conservación del “testware” (casos de test, protocolos, infraestructura, herramientas) para su uso posterior cuando nuestro cliente nos pida cambios o cuando encontremos nuevos errores ocultos en nuestra aplicación.

El proceso de test en el desarrollo de software

Una reunión ineficiente

jmartinmateo, , , , 2 Comments

Esta semana he participado en una multiconferencia con el objeto de resolver un problema.

La eficacia de la reunión está por ver. Tras la reunión se decidió la realización de una serie de acciones con objeto de resolver el problema. Si hemos acertado en diagnosticar la causa (raíz) del problema probablemente éste desaparecerá. En caso contrario, volveremos a tener la misma reunión dentro de 3 o 4 meses …

Sin embargo el título de esta entrada no era “una reunión ineficaz” sino una “reunión ineficiente”. ¿Causas? Probablemente estaba convocada demasiada gente (13 o 14 personas), en 4 ubicaciones diferentes y con una agenda poco definida.

La multiconferencia acabó durando 2 horas. Problemas:

  • Tiempo excesivo para mantener la atención de todo el mundo. No hubo ni un descanso.
  • Nadie ha calculado el coste de toda esa gente durante 2 horas, pero sería muy positivo calcularlo.

¿Qué nos falló? Hay varias fases en una reunión. En nuestro caso probablemente falló la ejecución de la reunión, aunque la preparación también sería mejorable.

Fotografía de noii's con licencia Creative Commons

Preparación

En una reunión con tantos participantes, creo que el convocante debería haber mantenido reuniones exploratorias previas para conocer las posiciones de cada grupo, de forma que en la multiconferencia final hubiesemos podido ir al grano sobre una propuesta ya consensuada.

Por otra parte, en lugar de partir de una duración preestablecida probablemente habría sido más efectivo un enfoque bottom-up, en el que se asigna un tiempo (más o menos agresivo) a cada punto y por agregación se obtiene la duración prevista de la reunión.

Ejecución

Como consecuencia de la mala preparación, los diferentes puntos del orden del día se iban sucediendo tal y como estaba previsto en  la agenda, pero sin límite de tiempo definido. Al cabo de una hora, los asistentes que estaban en mi misma ubicación llevaban ya un buen rato resoplando. Tras una hora de reunión, nos estábamos entreteniendo en temas menores y aún no habíamos llegado a tratar el problema central.

Finalmente llegamos a él, al cabo de 80 minutos. Todo el mundo estaba ya cansado y con más ganas de acabar la reunión que de resolver la cuestión. Hubo gente presente las 2 horas que duró la reunión y que, en realidad, sólo tenía que haber participado durante 5 minutos concretos en la parte final. Nuevamente, con una buena agenda y tiempos acotados para cada punto se les podría haber hecho participar sólo el tiempo preciso, cuando su aportación era necesaria.

Conclusión

Esta experiencia debe pasar a formar parte de nuestras lecciones aprendidas.

Ante una reunión, debemos primero plantearnos si es o no necesaria, si es el mejor medio para conseguir muestro propósito. En caso afirmativo, hay que prepararla bien, no sólo enviando la convocatoria sino discutiendo previamente los puntos a tratar, el orden y el tiempo a dedicarles. También hay que hacer participar sólo a aquella gente que es necesaria y durante el tiempo preciso.

Durante la ejecución se debe seguir el guión de forma estricta y, al acabar, no debemos olvidar el seguimiento. Si no se sale de la reunión con acciones concretas, con responsables concretos de ejecutarlas y con fechas límite para ello la reunión no habrá servido de nada.

Además, luego se debe verificar el cumplimiento del plan de acciones y, finalmente, comprobar si el plan ha sido efectivo y ha servido para solucionar el problema.

Y tú, ¿te enfrentas con frecuencia a reuniones inefectivas y/o ineficientes? Puedes explicar tus experiencias en un comentario. Compartiendo aprendemos todos.

Una reunión ineficiente