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.
· Gathering.
· Analyzing.
· Fixing.
Fig. 1. Metodología de resolución de problemas
Estas
están representadas en la figura 1. 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 es seguir
las fases en secuencia y no omitir ninguna.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.
