Resolución de Problemas y Gestión de Incidentes

Asumir responsabilidades – Resolución de problemas (Técnicas)

Posted on 16 febrero 2009. Filed under: Plan de Acción, Resolución de problemas, Resolución de Problemas y Gestión de Incidentes, Trabajo en Equipo | Etiquetas: , , , |

La evolución del concepto de calidad aplicado a la industria, y ahora a los servicios, muestra claramente que se ha pasado de una etapa, en donde la calidad era aplicada totalmente al control realizado al final de las líneas de producción, a otra donde aplicamos calidad total a todo dentro de la organización. Por ende, ya se habla de calidad de vida en el trabajo, calidad de vida en los servicios y calidad ambiental.
Recordemos que el concepto de calidad hoy en día, es aplicado en el ámbito industrial, como el logro de hacer las cosas bien la primera vez. Y se aplica control de calidad sobre las operaciones desde el diseño. Hasta que se obtiene el producto final e inclusive se habla de la calidad en la atención al cliente.
El camino que nos lleva hacia la Calidad Total crea una nueva cultura, establece y mantiene un liderazgo, desarrolla al personal y lo hace trabajar en equipo, además de enfocar los esfuerzos de calidad total hacia el cliente y a planificar cada uno de los pasos para lograr la excelencia en sus operaciones.
El hacer esto exige vencer obstáculos que se irán presentando a lo largo del camino. Estos obstáculos traducidos en problemas se deben resolver conforme se presentan evitando con esto las variaciones del proceso. Para esto es necesario basarse en hechos y no dejarse guiar solamente por el sentido común, la experiencia o la audacia. Basarse en estos tres elementos puede ocasionar que al momento de obtener un resultado contrario al esperado nadie quiera asumir responsabilidades.
De allí la importancia de basarse en hechos reales y objetivos, además de que surge la necesidad de aplicar herramientas de solución de problemas adecuadas y de fácil comprensión.
Las herramientas y técnicas cualitativas y no cuantitativas son las siguientes:
1. Recolección de datos.
2. Lluvia/Tormenta de ideas (Brainstorming).
3. Diagrama de Paretto.
4. Diagrama de Ishikawa.
5. Diagrama de flujo.
6. Matriz de relación.
7. Diagrama de comportamiento
8. Diagrama de Gantt.
9. Entrevistas.
10. Listas checables.
11. Presentación de resultados.
La experiencia de los especialistas en la aplicación de estas herramientas señala que bien utilizadas y aplicadas, con la firme idea de estandarizar la solución de problemas, los equipos pueden ser capaces de resolver hasta el 95% de los problemas.

RECOLECCIÓN DE DATOS
CONCEPTO
Es una recolección de datos para reunir y clasificar las informaciones según determinadas categorías de un evento o problema que se desee estudiar. Es importante recalcar que este instrumento se utiliza tanto para la identificación y análisis de problemas como de causas.

USO
Hace fácil la recopilación de datos y su realización de forma que puedan ser usadas fácilmente y ser analizadas automáticamente. Una vez establecido el fenómeno que se requiere estudiar e identificadas las categorías que lo caracterizan, se registran los datos en una hoja indicando sus principales características observables.

Una vez que se ha fijado las razones para recopilar los datos, es importante que se analice las siguientes cuestiones:
· La información es cuantitativa o cualitativa.
· Cómo se recogerán los datos y en que tipo de documentos se hará.
· Cómo se utilizará la información recopilada.
· Cómo se analizará.
· Quién se encargará de recoger los datos.
· Con qué frecuencia se va a analizar.
· Dónde se va a efectuar.

OTROS NOMBRES
· Hoja de recogida de datos
· Hoja de registro
· Verificación
· Chequeo o Cotejo

PROCEDIMIENTO
1. Identificar el elemento de seguimiento
2. Definir el alcance de los datos a recoger.
3. Fijar la periodicidad de los datos a recolectar.
4. Diseñar el formato de la hoja de recogida de datos, de acuerdo a la cantidad de información a escoger, dejando espacio para totalizar los datos, que permita conocer: las fechas de inicio y termino, las probables interrupciones, las personas que recoge la información, la fuente etc.

LLUVIA DE IDEAS
CONCEPTO
Técnica que consiste en dar oportunidad, a todos los miembros de un grupo reunido, de opinar o sugerir sobre un determinado asunto que se estudia, ya sea un problema, un plan de mejoramiento u otra cosa, y así se aprovecha la capacidad creativa de los participantes.
USO
Se pueden tener dos situaciones ante la solución de un problema:
1. Que la solución sea tan evidente que sólo tengamos que dar los pasos necesarios para implementarla, y
2.  Que no tengamos idea de cuáles pueden ser las causas, ni las soluciones.
Es aquí donde la sesión de tormenta de ideas es de gran utilidad. Cuando se requiere preseleccionar las mejores ideas.

OTROS NOMBRES
· Brain Storming
· Tormenta de ideas

PROCEDIMIENTO
1. Nombrar a un moderador del ejercicio.
2. Cada miembro del equipo tiene derecho a emitir una sola idea por cada turno de emisión de ideas.
3. No se deben repetir las ideas.
4. No se critican las ideas.
5. El ejercicio termina cuando ya no existan nuevas ideas.
6. Terminada la recepción de las ideas, se les agrupa y preselecciona conforma a los criterios que predefina el equipo.

DIAGRAMA DE PARETTO
CONCEPTO
Gráfico cuyas barras verticales están ordenadas de mayor a menor importancia, estas barras representan datos específicos correspondientes a un problema determinado, la barra más alta esta del lado izquierdo y la más pequeña, según va disminuyendo de tamaño, se encuentra hacia la derecha.

USO
Ayuda a dirigir mayor atención y esfuerzo a problemas realmente importantes, o bien determina las principales causas que contribuyen a un problema determinado y así convertir las cosas difíciles en sencillas. Este principio es aplicable en cualquier campo, en la investigación y eliminación de causas de un problema, organización de tiempo, de tareas, visualización del antes y después de resuelto un problema, o en todos los casos en que el efecto final sea el resultado de la contribución de varias causas o factores.

PROCEDIMIENTO
1. Decidir qué problemas se van a investigar y cómo recoger los datos.
2. Diseñar una tabla de conteo de datos (totales).
3. Elaborar una tabla de datos.
· Lista de ítems
· Totales individuales
· Totales acumulados
· Composición porcentual
· Porcentajes acumulados
4. Organizar los ítems de mayor a menor.
5. Dibujar dos ejes verticales y uno horizontal
6. Construir un diagrama de barras.
7. Dibujar la curva acumulada (curva de Pareto).
8. Escribir cualquier información necesaria.

DIAGRAMA DE ISHIKAWA
CONCEPTO
Técnica de análisis de causa y efectos para la solución de problemas, relaciona un efecto con las posibles causas que lo provocan.

USO
Se utiliza para cuando se necesite encontrar las causas raíces de un problema. Simplifica enormemente el análisis y mejora la solución de cada problema, ayuda a visualizarlos mejor y a hacerlos más entendibles, toda vez que agrupa el problema, o situación a analizar y las causas y subcausas que contribuyen a este problema o situación.

OTROS NOMBRES
· Diagrama de espina de pescado
· Diagrama Causa Efecto

PROCEDIMIENTO
1. Ponerse de acuerdo en la definición del efecto o problema
2. Trazar una flecha y escribir el “efecto” del lado derecho
3. Identificar las causas principales a través de flechas secundarias que terminan en la flecha principal
4. Identificar las causas secundarias a través de flechas que terminan en las flechas secundarias, así como las causas terciarias que afectan a las secundarias
CAUSA MAYOR
CAUSA MAYOR
DEFECTO
CAUSA MAYOR
CAUSA MAYOR
5. Asignar la importancia de cada factor
6. Definir los principales conjuntos de probables causas: materiales, equipos, métodos de trabajo, mano de obra, medio ambiente (4 M`s)
7. Marcar los factores importantes que tienen incidencia significativa sobre el problema
8. Registrar cualquier información que pueda ser de utilidad

MATRIZ DE RELACIÓN
CONCEPTO
Gráfico de filas y columnas que permite priorizar alternativas de solución, en función de la ponderación de criterios que afectan a dichas alternativas.

USO
· Cuando se requiere tomar decisiones más objetivas.
· Cuando se requiere tomar decisiones con base a criterios múltiples.

OTROS NOMBRES
· Matriz de priorización
· Matriz de selección

PROCEDIMIENTO
1. Definir las alternativas que van a ser jerarquizadas
2. Definir los criterios de evaluación
3. Definir el peso de cada uno de los criterios
4. Construir la matriz
5. Definir la escala de cada criterio
6. Valorar cada alternativa con cada criterio (usando la escala definida anteriormente)
7. Multiplicar el valor obtenido en el lado izquierdo de las casillas, por el peso de cada criterio y anotarlo a la derecha de cada casilla
8. Sumar todas las casillas del lado derecho y anotar el resultado en la casilla Total
9. Ordenar las alternativas de mayor a menor

DIAGRAMA DE COMPORTAMIENTO
CONCEPTO
Herramienta que permite graficar los puntos del comportamiento de una variable, de acuerdo a como se van obteniendo.

USO
· Para representar visualmente el comportamiento de una variable
· Evaluar el cambio de una proceso en un período

OTROS NOMBRES
· Diagrama de Tendencias

PROCEDIMIENTO
1. Decidir qué problema se va a monitorear y cómo se van a recoger los datos
2. Mantener el orden de los datos, tal como fueron recolectados
3. Dibujar un eje vertical y uno horizontal (Eje X Tiempo – Eje Y Medida)
4. Marcar los puntos. Un punto marcado indica ya sea la medición o cantidad observada en un tiempo determinado
5. Unir las líneas de puntos
6. Escribir en el diagrama cualquier información necesaria

DIAGRAMA DE GANTT
CONCEPTO
Gráfico que establece el orden y el lapso en que deben ejecutarse las acciones que constituyen un proyecto.

USO
· Permite vigilar el cumplimiento de un proyecto en el tiempo.
· Permite determinar el avance en un momento dado.

OTROS NOMBRES
· Cronograma de actividades

PROCEDIMIENTO
1. Identificar y listar todas las acciones que se deben realizar para cumplir con un proyecto
2. Determinar la secuencia de ejecución de las acciones
3. Definir los responsables de ejecutar cada acción
4. Escoger la unidad de tiempo adecuada para trazar el diagrama
5. Estimar el tiempo que se requiere para ejecutar cada acción
6. Trasladar la información anterior a las ubicaciones correspondientes en el diagrama

ENTREVISTAS
CONCEPTO
Técnica que permite reunir información directamente con el involucrado en el proceso.

USO
Obtener información de clientes o proveedores de un proceso.

PROCEDIMIENTO
1. Planear la entrevista. Determinar que información se necesita recopilar.
2. Elaborar una guía para la entrevista (introducción, preguntas relacionadas con el tema). Elaborar una prueba piloto.
3. Seleccionar las personas que más conozcan sobre el tema.
4. Programar la entrevista. Planear el tiempo necesario para realizar la entrevista.
5. Ubicar un lugar apropiado para realizar la entrevista sin interrupciones.
6. Invitar al entrevistado, informarle del objetivo, fecha y lugar donde se realizará la entrevista.
7. Realizar la entrevista (sea puntual, cordial y desarrolle la guía para la entrevista, luego resuma y permítale al entrevistado hacer comentarios. Dele las gracias.)

LISTAS CHECABLES
CONCEPTO
Método, lista u hoja de información para lograr que nada se nos olvide ni se omita, en la cual la información consignada es de fácil análisis y verificación. Las podemos encontrar con diferencias sencillas y de tres tipos:
· Guías para la realización secuencial de operaciones, observaciones o verificaciones.
· Tablas o formatos para facilitar la recolección de los datos.
· Dibujos o esquemas para señalar la localización de puntos de interés.

USO
· Muestra una secuencia sistemática de hacer las cosas.
· Facilita la recolección de datos.
· Relaciona pasos o elementos que constituyen el todo de un proyecto o de una preparación.
· Proporciona un medio de seguimiento y control del avance de un proyecto.


Anuncios
Leer entrada completa | Make a Comment ( 3 so far )

Gestión de Incidentes & Help Desk – cadena de atención de incidentes

Posted on 19 enero 2009. Filed under: Consultoría IT, Gestión de Soporte y Mesa de Ayuda, Herramientas Colaborativas, IT, IT Management, Plan de Acción, Resolución de Problemas y Gestión de Incidentes, Technical Leader, Trabajo en Equipo | Etiquetas: , , , , , |

Los actuales modelos colaborativos, permiten que la organización entera tenga visibilidad de los incidentes, problemas y fallos de los productos y servicios que ofrecen. Estos modelos hoy incluyen a los usuarios/clientes como
parte fundamental del motor de soluciones.

En el ámbito del soporte y mesa de ayuda de nuestras organizaciones, existen herramientas que han sido diseñadas con obejtivos precisos y claros. Tales herramientas pueden estar modularmente divididas y así, en módulos externos permitir a un grupo de usuarios realizar pedidos en base a categorías que la organización puede atender.

En la mayoría de las situaciones estos pedidos de los usuarios no se hace de manera directa, es decir utilizando puntos de accesos directos a quienes desarrollan los productos y las soluciones.
Esto naturalmente es así, puesto a que sus pedidos suelen ser ponderados incialmente por analístas de negocios y comerciales, quienes no solo tienen facultades especiales para dar peso a los distintos requisitos, sino que entienden las necesidades organizacionales y cuidan intereses que ciertas áreas desconocen.

De manera tal que generar puntos de accesos directos a los desarrolladores es posible pero con ciertas precauciones fundamentales.

Por ejemplo, implementar formularios de registración de incidente del usuarios, donde el mismo cliente/usuario puede dejar su inquietud, es parte de una estrategia de obtención de información, la cual será convenientemente registrada, evaluada y tratada.  Otros sistemas tal vez requieren de la activa participación de terceros, como operadores humanos o automáticos que transfieren los pedidos a otras áreas donde se desmenuza el requerimiento, se lo analiza, se detecta y reconoce el problema, se estima la solución, se pondera el tiempo y se desarrolla dicha solución.

Mientras tanto es posible que el usuario no tengo una resolución inmediata y deba esperar o insistir con su inconveniente.

Aún en pequeñas organizaciones, es crítico definir una cadena de atención de incidentes que considere un cierto orden en la registración de los incidentes, una categorización que indique su tipo, una categoría que indique su importancia e inmediatéz, un reconocimiento incial del problema,  alternativas de solución técnicas, una estimación del tiempo de resolución, su correspondiente verificación de calidad, la implantación de las soluciones y su validación.

No debemos olvidar que estos son elementos únicos de nuestra base de conocimientos.

Es por lo tanto en extremo relevante la utilización de un lenguaje común, estándar y unificado, para sostener un hilo conductor comunicacional de principio a fin.

Esta visibilidad justamente lo que exige es, que las acciones sean perfectamente encadenadas desde un principio
hasta un fin óptimo tanto para el usuario/cliente, como para la organización.

Esta es una de las causas por la cual no es bueno que las áreas de desarrollo y operaciones tengan capacidad de acción directa sobre los incidentes y se justifique el que otras personas deban intervenir previamente.

Es así como las herramientas potencian la visibilidad del contexto global para cada uno de los ítems registrados y puden evitar que inicidentes se transformen en problemas y que problemas lleguen a nuestros clientes y que aquellos que ya existen, puedan ser solucionados eficientemente.

Leer entrada completa | Make a Comment ( Comentarios desactivados en Gestión de Incidentes & Help Desk – cadena de atención de incidentes )

LOGS de errores reflejan el funcionamiento del nucleo de nuestras aplicaciones

Posted on 2 enero 2009. Filed under: Calidad del Software, Entorno de Pruebas, Herramientas Colaborativas, Herramientas, Métodos y Procesos, Resolución de Problemas y Gestión de Incidentes, Soporte de Aplicaciones, Testing | Etiquetas: , , , , , , |

Algunas estrategias de detección de errores en nuestras aplicaciones pueden parecer demasiado sencillas o desactualizadas, sobre todo con el auge y advenimiento de herramientas potentes, con cientos de reportes, gráficas y métricas para analizar.

Sin embargo prácticamente ninguna herramienta permite a desarrolladores, analistas funcionales y testers de aplicaciones, reconocer la causa raíz de los problemas que aquejan a nuestros desarrollos.

Una técnica sencilla y pronta a aplicar, es la generación de logs de errores en formato TXT. A partir de allí mejorar el proceso de construcción en base a información obtenida del núcleo de funcionamiento de nuestras aplicaciones, es cuestión de solo dejar volar la imaginación.

Aunque un conjunto de nuevas herramientas podrían ser la solución para el ahorro de tiempo y dinero en la resolución de defectos, estas herramientas principalmente deben tener la capacidad de generar reportes que permitan aislar los problemas raíces, haciendo mucho más sencillo el diagnóstico y resolución, sin tener que invertir en costosos ambientes de aislamiento ni tiempos de reproducción.

Estas soluciones no están del todo presente en las actuales herramientas disponibles, ni diseñadas para el comportamiento dinámico de los defectos y solo se permite un análisis estático basado en la mayoría de los casos, en pruebas orientadas de “caja negra”.

Pero tal vez la productividad se vería acelerada exponencialmente si no solo pudiéramos introducir herramientas con estas características dinámicas, sino que a su vez tuviéramos la capacidad de darle a nuestras aplicaciones la capacidad de resguardo y notificación de errores.

Desde el análisis y diseño y bajo un planteo de pruebas que orienten la construcción de los componentes, es posible introducir ciertos niveles de detalles que serían plasmados en “logs de errores”, los cuales pudieran ser de gran utilidad para el diagnóstico de problemas raíces y resolución temprana, es decir en fases de pruebas tempranas.

Al finalizar cada ciclo de prueba, testers y desarrolladores pueden interactuar con mejor foco en las causas raíces de los bugs, errores de construcción e inclusive errores de interpretación de requisitos o detección de requisitos mal formados.

La verdadera potencia de tales “logs de errores” se manifestarán solo si esta solución es diseñada y aplicada en forma armonizadas para que no se entorpezca el trabajo y los resultados sean positivos y bien significativos.

Un beneficio central es que los “tiempo ventana” demasiados cortos para la resolución de defectos, sean mejor aprovechados y el proceso se optimice significativamente.

Hay quienes opinan que se deben modificar significativamente los requerimientos para incorporar estos elementos a los procesos de desarrollo, pero yo creo que el esfuerzo no es tan grande como para evitarlo y los beneficios son tremendos como para dejar de hacerlo.

No piensen en tecnificar demasiado ni en agregar complejidad, orienten esta solución a la simplicidad y facilidad de lectura y comprensión y bastará con utilizar un notepad o archivo tabulado para comenzar a obtener resultados que mejoren la visibilidad del comportamiento erróneo de nuestras aplicaciones.

Potenciar la solución  es cuestión de imaginación.

Leer entrada completa | Make a Comment ( Comentarios desactivados en LOGS de errores reflejan el funcionamiento del nucleo de nuestras aplicaciones )

Testing Exploratorio – Cuando faltan elementos en las evidencias de resolución

Posted on 16 septiembre 2008. Filed under: Calidad del Software, Ingeniería del Software, Procesos Ágile, Pruebas de Integración, Pruebas Unitarias, Resolución de problemas, Resolución de Problemas y Gestión de Incidentes, Trabajo en Equipo |

Las verificaciones funcionales tuvieron una tónica un poco desagradable el día de hoy, ya que para la ejecución de las pruebas de sistemas requirieron mucho esfuerzo en el levantamiento de elementos que me permitan formar un concepto de cómo realizar el Testing y que resultados esperar.

La mayoría de las verificaciones no pudieron ser ejecutados por aspectos relacionados a elementos faltantes del despliegue, los cuales no son mencionados en ninguna de las evidencias de resolución. Sin embargo, al revisar la evidencia de cada una de las resoluciones encuentro que tales evidencias no tienen elementos que permitan formar con cierta normalidad los conceptos de Testing Funcional.

De esta manera solo se consigue dilatar los tiempos de Testing, se tienen más rechazos de soluciones (inclusive por desentendimiento), no cumplir con la entrega planificada y el re trabajo que implica en todas las áreas involucradas. Ni hablar si se aprueba un resolución y luego la rechazan en Despliegue al detectarla como fallida.

Creo que las evidencias tienen que tener el foco funcional que hace falta, principalmente por que en situaciones como la de hoy, se hace “testing forzado”, sin planificación, sin anticipación.
Las evidencias no deberían simplemente tener las sentencias SQL que se usan o los valores booleanos que adoptan las variables o los nombres de formularios ocultos, entre otros elementos de bajo nivel, que muchas veces es interpretable y sirve solo en el contexto adecuado, pero fuera de el no es de utilidad.

Tal como mencioné varias veces, estoy convencido que para ciertos artefactos, no es necesario intentar recurrir a prácticas de Pruebas Unitarias sin el framework adecuado, pero se pueden plantear juegos de pruebas de caja negra, en la cual es posible definir aspectos relacionado a las interfaces, totalizadores, los comandos de acción, etc.

Dicho de otra manera, las pruebas del desarrollador tal vez deberían declarar el juego mínimo de pruebas de funcionales (caja negra) que indiquen un estado previo, el proceso ejecutado y el estado posterior del juego de datos.

O en su defecto hay que darnos el tiempo para que luego de notificada la resolución, se asuma “un tiempo de estudio” para generar los conceptos de pruebas funcionales, pero así no se garantiza nada.

Por otro lado, el día de hoy se vio una debilidad en el traspaso al darnos cuenta que falta la especificación de la corrida de agentes y también el momento de la corrida, lo cual parece ser estratégico para que no se presenten los fallos que se presentaron en Testing.

En definitiva me doy cuenta de la debilidad que hay en los traspasos y posiblemente tenga que ver con la estrategia que se deba plantear antes de iniciar las resoluciones.

A mi me sigue costando enterarme con anticipación de que bloques serán entregados y según la experiencia que tengo en nuestra interacción cotidiana (Desarrollo – Testing / Testing – Desarrollo), aún las correcciones más sencillas nos cuesta un esfuerzo muy importante tanto a Desarrollo como a Testing y las verificaciones se demoran de manera no convenientemente, como es lógico.

Si estos elementos se siguen presentando con tanta dificultad, las estimaciones del esfuerzo de Testing van a quedar subestimadas por la necesidad de estudio de los Testers para cada uno de los artefactos de software, siempre que se efectúen pruebas exploratorias.

Leer entrada completa | Make a Comment ( Comentarios desactivados en Testing Exploratorio – Cuando faltan elementos en las evidencias de resolución )

Cualquier solución que elijas será sin duda la incorrecta

Posted on 19 agosto 2008. Filed under: Resolución de Problemas y Gestión de Incidentes, Trabajo en Equipo | Etiquetas: , |


En este blog se ha planteado en algunas ocasiones, Tecnicas de Resolución de Problemas, sin embargo creo no haber mencionado nunca que los problemas lo son cuando los idetificamos como tal, mientras tanto no lo son. Esto tiene sentido puesto a que normalmente estamos parados en un punto que solo nos permite ver en un determinado espectro y con la influencia del ángulo que esa posición nos permite visualizar.
A sabiendas de que algo no puede ocupar el lugar de otro algo jamás, es imposible que existan dos puntos de vistas totalmente iguales para reconocer un problema como tal, o para solucionarlo.
Queda claro que un problema no existe sino hasta que se identifica como tal y también que un problema para unos no es un problema para otros. Una vez identificado el problema y reconocido como tal, se lo debe dimensionar e identificar su impacto, reconocer las opciones que tenemos frente al mismo y de esa manera
es posible trabajar juntos en vista del horizonte que nos brindan las alternativas de solución.
En este punto podremos escoger la mejor solución.
Distingir un problema de un “no problema” es también cuestión de entreno en distintos enfoques y de lenguaje adquirido.
Los guío a la página de pnlnet y presten atención al párrafo que dice “es precisamente la propia normalidad la que nos dificulta solucionar un problema…
Leer entrada completa | Make a Comment ( Comentarios desactivados en Cualquier solución que elijas será sin duda la incorrecta )

Análisis de Causas de Problemas

Posted on 24 julio 2008. Filed under: Resolución de problemas, Resolución de Problemas y Gestión de Incidentes | Etiquetas: , |

La importancia de reconocer los problemas que se manifiestan de distintas maneras en nuestras organizaciones, nos permiten realizar una recolección de los mismos identificándolos mínimamente en cuanto a “que”, “cuando”, “donde” y “bajo que circustancias” se presentan.
Es necesario contar con algunos conocimientos que nos ayuden hacer buenas recolecciones, análisis y determinación certeras de las causas que generan los problemas. Estos conocimientos nos ayudan a disminuir los factores reactivos típicos en la naturaleza humana e introducir de manera científica a nuestros procesos de trabajo, soluciones duraderas que incrementan la productividad. Así la reactividad de la organización ante inconvenientes que bloquean el flujo de trabajo, disminuye para ser reemplazada en gran medida por proactividad que da limpieza y fluidez al proceso corregido.

Puede descargar un Template básico para hacer Analisis de Causa Raíz, o puede visitar estos artículos interesantes o ver los siguientes Videos de Técnicas de Resolución de Problemas – introductorios –  (requiere de registración gratuita)

Leer entrada completa | Make a Comment ( 3 so far )

Por favor páseme esto al español

Posted on 22 julio 2008. Filed under: Resolución de Problemas y Gestión de Incidentes, Trabajo en Equipo, Uncategorized | Etiquetas: |

Como parte de nuestro trabajo, el equipo de Gestión de Proyectos envía cotidianamente “reportes diarios” a La Gerencia donde expresa su evolución en las actividades del día, las actividades planificadas y un resumen de problemas que cada uno pudo haber detectado y para lo que se necesita hacer algún tipo de enfoque.

Lo cierto es que esta gestión puede ser un arma de doble filo si no se le da la utilidad adecuada y si no se modula correctamente la sintaxis del lenguaje utilizado. Normalmente nosotros utilizamos un lenguaje simple donde identificamos los siguientes elementos:

sujeto + situación (deseada) + acción + calendario
Con esta sencilla fórmula nos acoplamos a la teoría del PDCA y la podemos utilizar no solo para reportar la situación deseada sino que al factor “situación” se lo puede alterar para ingresar un valor “no deseado”.
De este modo:
sujeto + situación (no deseada) + acción + calendario
puede ser utilizado para indicar un problema vigente o potencial.

Para ejemplificar, quiero mostrar una situación real presentada en mis reportes diarios y como debí modificar el lenguaje para que finalmente se entendiera:

Situación No Deseada:

  • Catálogo de casos y/o requisitos inexistente con las correspondientes derivaciones a Desarrollado.
    Esto implica que no hay visibilidad para todo el equipo de lo que se está trabajando en el momento. Intenté localizar la información a modo de “enterarme” vía emails del Arquitecto de Sistemas pero no encontré una referencia clara.
    Igualmente accedo a los Entregables plasmados en la “herramienta de incidentes”, pero allí hay cientos de incidentes y al menos a mi no me queda del todo claro que revisar en algún orden específico. Imagino que puedo darle prioridad de revisión a las fechas de entregables vencidas.

a las pocas horas vino la respuesta:

Javier,
por favor páseme esto al español.

Gracias.

a los minutos la contra respuesta:

Estimado,

es un poco complicado y requiere de mucho esfuerzo comunicacional estar al tanto de que hay pendiente, con que prioridad y con que fechas de fin esperada. Es difícil obtener con anticipación, información de los pasajes a Testing.
Creo que puedes darte cuenta por los últimos emails que envié al Arquitecto de Sistemas informando los incidentes existentes en mi Sprint de pruebas y solicitando fecha de entregables a Testing e incidentes que aún desconozco por que se dieron de alta recientemente. Los emails de esta naturaleza son bastante regulares.
En el mismo sentido, la Responsable de Despligues me pregunta al respecto de que cosas hay en Testing y cuando finalizan, o el estado de un incidente en particular inclusive varios días después de haberse rechazado el mismo.
La diferencia es que ella siempre pregunta verbalmente y en instancias tardías.
Lo que quiero expresar es que los “bloques” no viajan con la claridad, visibilidad y simpleza que nos hace falta y que las idas y vueltas del mailing  complican mucho las gestiones tanto del Arquitecto de Sistemas como las mías. Siempre sugiero que se mire el Sprint de pruebas para tener más claro el paquete, pero imagino que es una complicación en la gestión individual del otro. Insisto en que debemos centralizar la gestión de alguna manera y con las premisas de claridad, visibilidad y simpleza.

Espero haber sido más claro.

Saludos.

Entonces podrán ver que de dos maneras diferentes dije lo mismo, pero fue necesario ampliar aduciendo a los conceptos fundamentales del problema y nuestro método de comunicación sencilla no sirvió. En ocasiones simplemente por que no se quiere escuchar. Otras veces por que no se comprende el contexto operacional, y muchas veces por que no se acepta el problema.

Leer entrada completa | Make a Comment ( Comentarios desactivados en Por favor páseme esto al español )

Cronograma de proyectos, agendas de trabajo, dependiencias y criterios de completitud

Posted on 30 abril 2008. Filed under: Organización del Trabajo Personal, Resolución de Problemas y Gestión de Incidentes, Trabajo en Equipo |

Resulta importante no hacer recortes en las actividades que tienen relación con el aseguramiento de calidad y las fechas de entrega no pueden poner en riesgo el aseguramiento de calidad, y los esfuerzos correctivos deben realizarse durante el proyecto y no al final cuando es prácticamente imposible.

Esto implica que debe plantearse una estrategia que sea sostenida durante todo el ciclo de vida del proyecto y que se apliquen las tácticas adecuadas para evitar desplazamientos que pongan en riesgo tanto la fecha de entrega como la calidad en si.

Es fácil observar que las agendas particulares que genera el cronograma del proyecto, tienen fuerte dependencias con otros integrantes del equipo y no es aceptable romper esas dependencias sin considerar los impactos de esas rupturas (básicamente cambio en la agenda de algún integrante). Este tipo de ruptura implica una falta al compromiso con el recurso dependiente y principalmente con la actividad planificada, lo cual quiere decir que alguien deberá realizar mayores esfuerzos para lograr cumplir con los elementos satisfactores que darán completitud a la actividad.

Es cierto que la mayoría de las veces no son intencionales tales incumplimientos, sobre todo en algunas personas con roles específicos, que reciben pedidos en carácter de urgente. Sin embargo, si existe una planificación y se crea una agenda personal que incluye actividades con dependencias hacia otras actividades de otros recursos (agenda global), todo esto debería anteponerse a la fuerte necesidad de responder a las necesidades instantáneas de los superiores del organigrama.

De no ser posible, debe consensuarse con los involucrados y modificar las condiciones de cumplimiento y aceptación (negociación), pero esto idealmente, no debería ser una constante hacia adentro, que implosione, sino que es mucho más saludable sostener un carácter de cumplimiento con las actividades con dependencias y el carácter negociador con los que generan nuevos pedidos en forma constante.

En definitiva si permanecemos en la actitud de modificar nuestras actividades rompiendo dependencias sin negociar, vamos en contra de los principios de Completitud, que pertenecen a los axiomas del aseguramiento de calidad. ¿No es completitud la palabra más utilizada por los superiores de la organización a la hora de una refriega por incumplimiento?

Ahora que estamos obligados a trabajar con agendas visibles para La Gerencia y el resto de los integrantes de la compañía, logremos que no se nos vuelva en contra y aprendamos a manejar todos los elementos que implica llevar una “agenda de compromisos”. Que cada ítem que ingresamos deje de ser un elemento de reclamo y acusaciones constantes.

Leer entrada completa | Make a Comment ( Comentarios desactivados en Cronograma de proyectos, agendas de trabajo, dependiencias y criterios de completitud )

Mi rol, mi evolución, mis quedos, mi dejos

Posted on 28 abril 2008. Filed under: Calidad del Software, Metodologías de Desarrollo, Procesos Ágile, Pruebas de Integración, Pruebas Unitarias, Resolución de Problemas y Gestión de Incidentes, Trabajo en Equipo |

 

Como Responsable SQA y QAC, sostengo mi crecimiento permanente basándome en la vida misma de los proyectos, en las interdependencias profesionales y en la relevancia de nuestras soluciones para el usuario. 

La formación de un proceso particular y nuestra adaptación no ha sido fácil. Principalmente nos ha sido imposible automatizar las pruebas para un entorno de desarrollo basado en la API de Lotus Note, de IBM y todo lo que pueda existir para automatizar pruebas a cualquier nivel nos resultó bastante costoso, en lo que a tiempo y esfuerzo se refiere.

Es así que me he puesto en la tarea de mejorar todos los procesos intrínsecos, previos a cualquier desarrollo.

La estrategia global implicó lograr alertar fallos utilizando un símil  AMFE en los requerimientos, también en fases de Análisis y Diseño. Posteriormente establecer una cadena de revisiones para las soluciones técnicas propuestas, mas estudios de viabilidad y factibilidad de Despliegues de Productos, tratando de detectar y minimizar cualquier merma de la calidad que impacten en los eslabones finales de la cadena de producción.

Como estrategia para pruebas, generamos la cantidad de ambientes de Testing que fueran necesarios, basándonos primariamente en los ciclos que dimos de alta en el cronograma del proyecto.

Nuestra táctica implica la formación de una alta cantidad ciclos con una gran cantidad de Pruebas de Integración, que no son coincidentes con Versiones Candidatas del producto, sino que en cada integración nos vamos acercando a dichas versiones. Al lograr integrar todos los componentes que conforman un módulo testeable a nivel de pruebas funcionales, versionamos el producto y ejecutamos el ciclo funcional correspondiente.

Esto esta lejos de ser una Integración Continua, pero es la aproximación mínima que he podido idear para que la mayoría de los defectos se detecten con bastante antelación.

Conformamos un equipo chico de desarrollo, con un Responsable que hace las gestiones de seguimiento de avances de los componentes y determina en base al cronograma, el hito de integración de componentes, del mismo modo la conformación de los módulos y notificaciones al LP y SQA, de los módulos que están disponibles para pruebas de funcionales.

La envergadura del equipo exige que los mismos desarrolladores ejecuten los ciclos de pruebas integradoras y lo hacen bajo un esquema de revisiones cruzadas. SQA asigna también un equipo de Testeadores que ejecutan pruebas integrales ayudando a acelerar el proceso.

Previo a esto, sin duda alguna tuvimos que elevar el Skill de los Desarrolladores de esta tecnología tan particular, en lo que respecta a técnicas de pruebas y detección de fallos.

Todos los fallos, defectos y errores son registrados y puestos a consideración de SQA y el LP quienes en un solo lote hacen las derivaciones para resoluciones, en base a la severidad y prioridad determinada en un análisis exhaustivo.

Este accionar nos ha llevado rápidamente a una disminución significativa de fallos detectados en ciclos de pruebas funcionales de versiones candidatas y a una desaparición del 100% de fallos del tipo Invalidante y del 80% de fallos del tipo Grave.

Las actividades de Despliegue en si mejoraron y garantizaron mejores funcionamiento cuando se comenzó a utilizar el elemento "Pruebas de Campo" y finalmente nuestro equipo de Soporte cuenta con una gran biblioteca de fallos detectados los cuales alimentan su base de conocimientos a cerca de como se podría presentar un fallo y como se orienta a su rápida resolución.

Poco a poco trataré de mostrar los procesos aunque no pueda dar demasiados detalles, lo haré genérico.

Leer entrada completa | Make a Comment ( Comentarios desactivados en Mi rol, mi evolución, mis quedos, mi dejos )

Fallos y defectos. Su persistencia y estrategia para mitigarlos.

Posted on 16 abril 2008. Filed under: Calidad del Software, Resolución de Problemas y Gestión de Incidentes |

Al respecto de los defectos reportados, su persistencia y/o mutación, sucede que los defectos reportados por Testing en algunos casos fueron persistentes hasta tres (3) ciclos y en algunas situaciones más. El defecto es tratado normalmente según el  proceso normal establecido. Lo cierto es que nunca tienen el mismo comportamiento ni los mismos síntomas y por lo general no se reportan como nuevos defectos sino que se le aumenta la persistencia y en el mismo defecto se reportan las No Conformidades. Así hasta que definitivamente se obtiene un resultado satisfactorio.

Inicialmente puede decirse que el fallo es reportado por Testing con un bajo análisis de los defectos que lo provocan, lo cual dentro de un ciclo de pruebas de sistemas es correcto, inclusive sin ningún análisis sino la mera detección y reporte.

El o los defectos puede/n escalar a otros niveles, como por ejemplo a las prueba de campo (producción), sin ser necesariamente un fallo y ser detectado/s allí con cierto grado de mutación.
Se asume que el fallo persiste y se lo reconoce como si se tratara del mismo que alguna vez se detectó en fases anteriores de las pruebas, pero en realidad puede tener otra naturaleza. Un ejemplo son las fechas con formato invertido en algunos campos, las cuales no representan necesariamente un fallo salvo una incomodidad visual, pero que en algunas situaciones especiales pueden llevar a la toma de una decisión incorrecta si no se percibe por parte del usuario. 

Es importante notar que esta mutación de defectos se va dando a medida que se hicieron correcciones sobre los fallos reportados y es aquí mismo donde uno se detiene a pensar en el por que de la persistencia.

Me interesa analizar el contexto para reconocer esos motivos:

Motivo 1

Otro motivo importante es la falta de definición de los requerimientos, la esencia del concepto que da vida a los mismos para lograr tangibilizarlo como una funcionalidad.
Este motivo podría tener muchos frentes para atacar, sin embargo yo me centro en que se debería aumentar el análisis que nos permita conocer la mecánica de uso involucrada y como se puede agregar valor funcional.

Esto puede implicar pactar una interacción fluida con el Cliente o un Usuario Líder de modo tal que se involucre en el proyecto y valide la evolución de los requerimientos. Este mismo usuario en un esquema de validaciones y verificaciones, puede ayudarnos en gran medida a la detección temprana de cambios y principalmente al planteamiento de las estrategias para afrontarlos y establecer un criterio de fin en base a la completitud necesaria del requisito.

Motivo 2

También la falta de Estimación de Riesgos posibles para cada uno de los requisitos impacta en la aparición (formación diría yo) de los fallos y defectos, puesto a que es posible iniciar las fases de construcción sin tener conciencia de los problemas que debemos evitar para generar un componente completo. Este aspecto también favorece a la mutación de los defectos una vez que los fallos fueron detectado, reportados y "solucionados", debido que las resoluciones son encaradas del mismo modo en que se construyeron los componentes.

Se puede considerar como muy valioso reconocer en que fase impactarían los riesgos detectados y de ese modo establecer la estrategia que mejor se ajuste a la mitigación, eliminación o aceptación del riesgo.
Teniendo en cuenta que se debe evitar un impacto desfavorable, se pone en conocimiento de los riesgos detectados a los responsables de cada fase y luego al equipo involucrado en la fase. Para esto es posible que se deba tener un nombre claro del riesgo, una descripción de que lo produce y como se manifiesta (síntomas), los antecedentes de ocurrencia en caso de que los tuviera, y la cantidad de veces que se podría presentar según los antecedentes. Es importante que cada uno pueda realizar una lectura inteligente, simple y tienda a la estrategia correcta.

Motivo 3

Una vez que los fallos y/o defectos escalaron a un Ambiente de Producción, los mismos son reportados por los Usuarios Finales bajo algún esquema de "Mesa de Entrada al Soporte del Sistema". Allí mismo se incurre en una grave falencia al dar de alta los fallos y/o defectos, pues se lo hace sin un Subjet claro que exprese en forma simplificada del problema ("sujeto2+"situación no deseada"). Así mismo el cuerpo del reporte no es más que una descripción del incidentes sufrido por  usuario y por ende no involucra ningún análisis ni apunta a ninguna alternativa de solución.
En este sentido es prácticamente imposible diagramar próximos pasos y coordinar acciones efectivas y eficientes (teniendo en cuenta un Calendario)

Motivo 4

Un importante motivo a considerar es la falta de análisis del fallo y los defectos que lo provocan. Así mismo no reconocer su impacto en el requerimiento del cliente y en su entorno de trabajo a nivel del negocio y no solo del sistema.

El análisis de los fallos y defectos, tiene que tener al menos un responsable. Típicamente se imputa la responsabilidad a SQA, el cual debe reconocer los factores mencionados a nivel de impacto y riesgos, detectar la naturaleza de los fallos y posteriormente emitir el reporte de los mismos. Esto podría implicar también que el mismo equipo SQA es responsable de categorizar no solo el carácter de Severidad, sino también la Prioridad con la que se debe dar resolución a cada uno de los fallos.

Una estrategia de este tipo puede denotar ciertas demoras en el proceso relentizandolo por no hacerse el reporte de fallos y/o defectos en forma instantánea, una vez que son detectados en los ciclos de pruebas. Sin embargo, puede por otro lado acelerar la calidad de las resoluciones disminuyendo la persistencia de los defectos y su mutación, como también garantiza en mayor grado que se resuelven en un orden que agrega valor al proceso en general.

 

Es necesario crear una conciencia general para todos los involucrados en la Gestión de Problemas para propender a la generación de Soluciones Técnicas definidas correctamente según el propósito de cada resolución y que tomen como entrada los Subjetcs y Descripciones correctamente formados.
Esta formación impactará directamente en la mejora del trabajo proactivo evitando el trabajo en solitario y aumentando las capacidades de seguimientos anticipados. Aunque parezca contradictorio, su vez genera un buen grado de independencia de trabajo para el resto del equipo de trabajo en base a la mejora sustancial que implica en nuestra base de conocimientos.
También estimula la limpieza del proceso de la organización y facilita el conocimiento individual para fortalecer el conocimiento grupal.

Leer entrada completa | Make a Comment ( Comentarios desactivados en Fallos y defectos. Su persistencia y estrategia para mitigarlos. )

QC STORY

Posted on 4 enero 2008. Filed under: Resolución de Problemas y Gestión de Incidentes |

El método de solución de problemas, llamado por los japoneses "QC STORY", es una pieza fundamental para ejercer el control de calidad por el método PCDA gerencial

EL CONTROL DE CALIDAD Y LA QC STORY

el control de calidad consta de etapas para su aplicación, la solución de problemas "QC STORY" es aplicable en el sentido de:

  • Planeación de la calidad: Consiste en el establecimiento de los estándares de calidad para la satisfacción de las personas.
  • Mantenimiento de la calidad: Consiste en la conservación de los estándares de la calidad con el fin de establecer una "Calidad estándar", un "costo estándar", una "Atención estándar", una "moral estándar" y una "Seguridad estándar", es aquí donde se utiliza la "QC STORY" para eliminar los desvíos crónicos de calidad.
  • Mejoras de calidad: Consiste en el establecimiento  de nuevos estándares de calidad con el objeto de obtener un producto o servicio mejor. En este caso la "QC STORY" para redireccionar el proceso.

LA SOLUCIÓN DE PROBLEMAS COMO MÉTODO GERENCIAL

La gran mayoría de las decisiones gerenciales se basan en el sentido común y en la experiencia de los responsables del manejo empresarial. El análisis que se haga del problema es justamente lo que hace que se tomen las decisiones correctas y se encuentre una solución viable.

PCDA: Es el modelo gerencial de solución de problemas para todos los recursos de la empresa

Cualquier decisión que se tome en cualquier nivel, frente al gerenciamiento de la organización , debe estar orientada para la solución de problemas y por ende precedida por un análisis de proceso conducido de manera secuencial, recurriendo a todas las personas que entren dentro del proceso exigiendo un análisis completo de las tareas que cada uno realiza, siguiendo el método de manera fiel.

ANÁLISIS DE PROCESOS

Las organizaciones tienen problemas frecuentes que afectan la productividad y la calidad de los productos perjudicando así su posición frente a la competencia, si no se pone especial atención a esto la empresa tenderá a desaparecer en un corto plazo. Los gerentes deben alimentar constantemente el conocimiento y experiencia que tienen con hechos y datos que les hagan tomar las decisiones adecuadas para ejercer una dirección correcta, por ello es que surge el "Análisis de procesos" como una herramienta para la solución de problemas.

Método y herramientas del análisis de procesos

El análisis de procesos es una secuencia de procedimientos lógicos basado en hechos y datos que tiene como objetivo localizar la causa fundamental de los problemas y es utilizado en el gerenciamiento interfuncional de la empresa para hallar soluciones definitivas y alcanzar las metas directivas.

El análisis de procesos debe ser practicado por todas las personas de la empresa y es una de las actividades mas importantes del "Control Total de Calidad". En este análisis deben intervenir también todos los recursos científicos y tecnológicos de los que la empresa disponga.

Las decisiones gerenciales no deben ser tomadas sin que sean fundamentadas en un análisis de procesos, basados en hechos y datos, a través del método de solución de problemas.

APLICACIÓN DEL MÉTODO

MODELO DE SOLUCIÓN DE PROBLEMAS "QC STORY"  

PCDA
FASE
OBJETIVO

P
Identificación del problema
Definir claramente el  problema y reconocer su importancia.

P
Observación
Investigar las características específicas del problema con una visión amplia y desde diferentes puntos de vista.

P
Análisis
Descubrir las causas fundamentales.

P
Plan de acción
Concebir un plan para bloquear las causas fundamentales.

D
Acción
Bloquear las causas fundamentales.

C
Verificación
Verificar si el bloqueo fue efectivo.

A
Estandarización
Prevenir la reaparición del problema.

A
Conclusión
Recapitular todo el proceso de la solución del problema para futuros trabajos.

Comentario final

El método de solución de problemas "QC STORY" descrito anteriormente, es el método japonés de la JUSE (Union of Japanese Scientists and Enginers) y ha tenido una buena aceptación en el mercado latinoamericano y se le dio el nombre de "molino de viento". Para su aplicación el profesor Falconni recomienda para su aplicación las siguientes normas:

  1. Utilizar el método en problemas pequeños y simples a nivel de cada sección.

  2. Seguir el método fielmente.

  3. Durante la presentación del problema se debe destacar la etapa del método que está siendo analizada.

  4. Deben hacerle las observaciones necesarias a cada etapa del proceso.

Contexto del control de calidad: Debe garantizar la calidad de los productos, controlando los procesos para conseguir la satisfacción de los clientes .

 

Copia fiel de Gestipolis

Leer entrada completa | Make a Comment ( Comentarios desactivados en QC STORY )

Liked it here?
Why not try sites on the blogroll...