Metodología de Resolución de Problemas

Muchos de los profesionales de Microsoft necesitan una metodología para solucionar los problemas de los clientes y muchas veces se necesita una metodología que como algunos de los frameworks de Microsoft , estén basados en las mejores practices basadas en la experiencia y del método científico para la resolución de problemas. Por lo cuál hoy el Dr.Microsoft les quiere mostrar el trabajo realizado por los Support Escalation Engineers Viviane Lopes y Andre Teixeira que nos cuentan los beneficios que se obtienen al utilizer una metodología para solucionar los problemas y claro está , entre ellos llegar a una solución lo más rápido possible para alcanzar con éxito los SLA pactados con el Cliente.

La siguiente metodología no solo aplica en caso de Microsoft sino en general en cualquier scenario de solución de Problemas Técnicos.

El método científico parte de la definición de un problema, crea una hipótesis, recolecta los datos necesarios, analiza estos datos, entrega un reporte de lo que en los datos se encontró y valida o rechaza la hipótesis.

Estos mismos conceptos los podemos aplicar como metodología para la solución de los problemas de soporte técnico. De esta manera surgieron las cuatro etapas utilizadas por los
ingenieros del grupo de soporte de Microsoft de Latinoamérica.

Estas cuatro etapas son:

· Defining. (Definir)

· Gathering. (Recopilar)

· Analyzing. (Analizar)

· Fixing. (Arreglar)

Su representación es cíclica
porque el proceso de resolución se mueve a través de las cuatro fases en
secuencia con el objetivo de que en cada interacción el problema sea acotado
más y más hasta llegar a la solución.

La recomendación del
Dr.Microsoft es seguir las fases en secuencia y no omitir ninguna , ya que el
omitir Alguna podría llevar a la resolución no óptima o correcta de algún
problema técnico.

Es muy difícil llegar al
lugar a donde queremos ir si no definimos cual es dicho lugar. El proceso de
resolución de problemas debe siempre comenzar con la definición del problema. A
continuación vamos a hablar de cada una de las etapas en detalle.

Fase 1: Defining
(Definición)

El primer paso es elaborar
una buena definición del problema. Depende de cómo definamos el problema, va a
ser más fácil o más difícil solucionarlo exitosamente. La definición del
problema nos ayuda a definir también el criterio de solución del mismo. Esto es
lo que llamamos scope del problema.

A menos que el problema este
correctamente definido, es poco probable que sea encontrada una solución
satisfactoria.

Existen varias técnicas que
pueden ser utilizadas durante esta etapa y que ayudan a nuestros ingenieros a
definir un problema, entre ellas tenemos:

· Escuchar activamente.

· Realizar preguntas
precisas.

· Parafrasear.

Para quien ha interactuado
anteriormente con nuestro grupo de soporte, seguramente estas técnicas les son
familiares. El objetivo es capturar la mayor cantidad de detalles e información
que nos ayude a definir el problema de una manera precisa.

Con base en la definición
del problema y el conocimiento de cómo el producto debería funcionar, el
siguiente paso que realiza el ingeniero es crear una hipótesis acerca de que
podría ser la causa del problema.

Recordemos que una hipótesis
es una declaración que aún no se ha establecido como cierta. En el caso de los
ingenieros de soporte, diríamos que es una aproximación
educada basada en
experiencia, conocimiento, habilidades e intuición.

El crear una hipótesis nos
ayuda a darle un enfoque a nuestro pensamiento y continuar con las siguientes
fases.

La fase de defining o definición, nos debe dar como
resultados:

· Una definición clara del
problema.

· El criterio bajo el cual
se define la solución del problema.

· Una o más hipótesis.

Fase 2: Gathering
(Recolección)

Con base en la hipótesis
creada, ahora sí podemos comenzar a recolectar los datos que son necesarios
para comprobar o refutar la hipótesis. Muchas veces tendemos a capturar
información sin antes haber definido el problema y puede ser frustrante
invertir tiempo en recolectar información que no será usada. El primer objetivo
de esta fase es definir un plan de acción efectivo para la recolección de los
datos de tal manera que todos los datos necesarios sean recolectados en la
primera vez. El segundo objetivo de esta fase es garantizar que la calidad de
los datos es óptima antes de pasar al análisis.

Un buen plan de acción debe
ser detallado, incluir información específica de lo que se necesita y si es el
caso, incluir explicaciones detalladas de como recolectar la información.
Actualmente existen herramientas de soporte remoto que facilitan esta labor,
caso que se necesite de ayuda para recolectar los datos.

Después de definir el plan
de acción de cuales datos se necesitan y cómo van a ser recolectados, el
siguiente paso es recolectar dicha información siguiendo el plan creado. Una
buena práctica es tomar una pequeña muestra de los datos para estar seguros que
se está recolectando correctamente. Un ejemplo de este escenario son los logs
del performance monitor. Se puede tomar una muestra por un periodo corto de
tiempo para garantizar que los contadores están trabajando como se espera.

Antes que los datos sean
analizados deben ser validados. La validación consiste en responder las
siguientes preguntas:

· ¿Es leíble la información?
Por ejemplo un dump de memoria. El cliente puede revisar que es válido antes de
enviarlo al ingeniero usando herramientas como el dumpchk.exe.

· ¿Los datos contienen
información relevante? Por ejemplo en una captura de red. El cliente puede
revisar con en Network Monitor que la captura incluye tráfico entre las
maquinas relevantes al problema.

Estas pequeñas acciones
evitan invertir tiempo innecesario tanto del cliente como del ingeniero.

La fase de gathering o recolección, nos debe dar como
resultados:

· Un plan de acción
detallado para recolectar los datos necesarios.

· Validación de los datos
recolectados.

Fase 3: Analyzing
(Analisis)

El objetivo de esta fase es
analizar la información recolectada en la fase anterior. Esta información es
estudiada para confirmar o rechazar la hipótesis o hipótesis generadas en la
primera fase.

Analizar el problema implica
aprender sobre el mismo lo más que se pueda. En esta fase la experiencia en el
tema es crítica así como también las herramientas usadas para el análisis.

Dentro de las acciones que
un ingeniero de soporte realiza durante esta fase de análisis están:

· Separar los datos que son
relevantes para el análisis basado en la definición del problema y en el
conocimiento y experiencia sobre el tema.

· Buscar por evidencia obvia
primero antes de invertir tiempo en un análisis más profundo. Para clarificar
este punto, un ejemplo es revisar los logs de Event Viewer antes de tomar un
dump completo de la máquina.

· Buscar por contenido ya
existente en las bases de datos de conocimiento. Nuestros clientes podrían
realizar este paso buscando en el sitio de soporte de Microsoft y también revisando sus bases de datos
de problemas internos.

· Realizar un análisis más
profundo. Esto es, investigar los datos recolectados en detalle, intentar
reproducir el problema, comparar los datos recolectados con relación a un
ambiente que esté trabajando normalmente.

Como resultado de este
análisis, debemos ser capaces de confirmar la hipótesis, hay suficiente
evidencia que confirme la hipótesis y soporte un diagnostico; o por el
contrario tenemos que rechazar la hipótesis.

En caso que la hipótesis sea
rechazada, tendremos que comenzar un ciclo, esto es, ir a la fase de definición
nuevamente. En este punto se debe considerar colaboración o escalación del
problema al siguiente nivel.

La fase de analyzing o análisis, nos debe dar como
resultados:

· Hipótesis confirmada por
el análisis de los datos.

· Resultado del análisis de
los datos.

· Posible causa raíz
identificada.

· Comunicación a nivel de
las personas involucradas informando el progreso.

Fase 4: Fixing (
Solución)

En esta fase con base al
análisis realizado previamente, necesitamos elaborar un plan de acción para
solucionar el problema. Este plan de acción de solución debe considerar el
impacto y los riesgos de las acciones sugeridas. De ser necesario se recomienda
probar el plan de acción en un ambiente de pruebas y de no ser posible, incluir
las medidas necesarias tales como tener un respaldo (backup), planes de
contingencia, en caso que el plan de acción deba ser aplicado directamente a
producción.

Como mejores prácticas para
la solución de problemas técnicos, la experiencia nos enseña a:

· Si hay varias maneras de
solucionar el problema o una solución involucra varios pasos, aplicar un cambio
cada vez y observar los resultados.

· Seguir los pasos de
acuerdo a las instrucciones dadas y al orden recomendado.

· En caso de dudas sobre el
plan de acción, preguntar antes de ejecutar.

Aquí podemos tener varias
situaciones, que veremos a continuación.

· Si después de aplicar el
plan de acción, los síntomas desaparecen, podemos considerar el problema como
resuelto.

· Si el problema original
está resuelto pero aparece un problema diferente, esto se debe manejar como un
nuevo incidente de soporte e iniciar nuevamente con el ciclo de solución.

· Si el problema continúa,
no hay cambio en los síntomas, debemos retornar a la fase de definición y
comenzar nuevamente. Escalación al siguiente nivel debe ser considerara en esta
situación.

· Si el problema empeora
(esta condición es la menos deseada por supuesto!), escalación al siguiente
nivel debe ser considerada a este punto.

La fase de fixing o solución, nos debe dar como
resultados la solución al problema originalmente definido o la decisión de
volver a la fase de defining o definición nuevamente; obviamente
considerando la posibilidad de involucrar recursos adicionales que nos ayuden a
llegar a una solución.

Esperamos que este contenido
les sea de utilidad y les ayude a solucionar los problemas siguiendo esta
metodología que hemos compartido con ustedes y si tienen Alguna duda pueden
revisar más material acerca de la resolución de problemas en los diversos
cursos y carreras que Microsoft pone a tu alcance en : www.microsoftvirtualacademy.com
, donde encontrarás capacitación gratuita en diversas tecnologías Microsoft.

Agradecemos la aportación de Viviane Lopes y Andre Teixeira que son Support Escalation Engineers y que sin ellos y sus experiencias  , está metodología de resolución de Problemas , no nos haría mas Fácil la vida.

Comments

• Anonymous
  January 01, 2003
  Hola Vero , muchas gracias por tu comentario ¡¡¡ Próximamente se estarán publicando + metodologías y artículos de interes , el Dr. Microsoft te receta suscribirte al Blog y estar pendiente de todas las publicaciones. Saludos Cordiales.

• Anonymous
  July 18, 2012
  Es una metodología sencilla y seguramente practica, me pareció interesante y seguramente de utilidad. Saludos