La resolución de problemas es una forma de resolver problemas que se aplica a menudo para reparar productos o procesos defectuosos en una máquina o un sistema. Es una búsqueda lógica y sistemática de la fuente de un problema para resolverlo y hacer que el producto o proceso vuelva a funcionar. La resolución de problemas es necesaria para identificar los síntomas. Determinar la causa más probable es un proceso de eliminación : eliminar las causas potenciales de un problema. Por último, la resolución de problemas requiere la confirmación de que la solución restablece el producto o proceso a su estado de funcionamiento.
En general, la resolución de problemas es la identificación o el diagnóstico de un "problema" en el flujo de gestión de un sistema causado por un fallo de algún tipo. El problema se describe inicialmente como síntomas de mal funcionamiento y la resolución de problemas es el proceso de determinar y remediar las causas de estos síntomas.
Un sistema puede describirse en términos de su comportamiento esperado, deseado o previsto (normalmente, en el caso de los sistemas artificiales, su finalidad). Se espera que los eventos o las entradas del sistema generen resultados o salidas específicos (por ejemplo, al seleccionar la opción "imprimir" en varias aplicaciones informáticas se pretende que surja una copia impresa de algún dispositivo específico). Cualquier comportamiento inesperado o indeseable es un síntoma. La resolución de problemas es el proceso de aislar la causa o las causas específicas del síntoma. Con frecuencia, el síntoma es una falla del producto o proceso para producir resultados (por ejemplo, no se imprimió nada). A continuación, se pueden tomar medidas correctivas para evitar más fallas de un tipo similar.
Los métodos de ingeniería forense son útiles para rastrear problemas en productos o procesos, y existe una amplia gama de técnicas analíticas disponibles para determinar la causa o causas de fallas específicas . Luego se pueden tomar medidas correctivas para evitar fallas futuras de un tipo similar. Es posible tomar medidas preventivas utilizando el modo de falla y efectos (FMEA) y el análisis del árbol de fallas (FTA) antes de la producción a gran escala, y estos métodos también se pueden utilizar para el análisis de fallas .
Hay dos elementos principales necesarios para permitir que se realice un diagnóstico de resolución de problemas: el conocimiento del dominio a priori y las estrategias de búsqueda [1] . Estos son interdependientes, y aquí es donde podemos identificar fundamentalmente dos tipos diferentes de problemas, con enfoques coincidentes para su diagnóstico. Rasmussen [2] sugirió que existe una estrategia guiada por las características del funcionamiento correcto del dispositivo (estrategia topográfica) y una estrategia guiada por las características del funcionamiento anormal (estrategia sintomática). La segunda es realmente preguntar "¿qué está mal?" La primera es preguntar "¿qué está pasando?"
Una estrategia es un conjunto organizado de actividades que expresan una forma plausible de alcanzar un objetivo. Las estrategias no deben considerarse algoritmos que se siguen inflexiblemente para obtener soluciones. Quienes resuelven problemas se comportan de manera oportunista, ajustando las actividades dentro de una estrategia y cambiando las estrategias y las tácticas en respuesta a la información y las ideas. [3]
Una estrategia sintomática (también conocida como razonamiento basado en casos o razonamiento superficial) requiere un conocimiento a priori del dominio que se obtiene de la experiencia pasada que estableció conexiones entre los síntomas y las causas. Este conocimiento se conoce como conocimiento superficial, compilado, evidencial, basado en la historia y basado en casos. Esta es la estrategia más asociada con el diagnóstico por parte de expertos. El diagnóstico de un problema se produce como un proceso de reconocimiento rápido en el que los síntomas evocan categorías de situación apropiadas. [4] Un experto conoce la causa en virtud de haber encontrado previamente casos similares. El razonamiento basado en casos es la estrategia más poderosa y la que se usa con más frecuencia. Sin embargo, la estrategia no funcionará de forma independiente con problemas verdaderamente nuevos o cuando se busca una comprensión más profunda de lo que está sucediendo. Una estrategia topográfica cae en la categoría de razonamiento profundo. Con el razonamiento profundo, se utiliza un conocimiento profundo de un sistema. La topografía en este contexto significa una descripción o un análisis de una entidad estructurada, que muestra las relaciones entre sus elementos. [5] También conocido como razonamiento a partir de los primeros principios, [6] el razonamiento profundo se aplica a fallas nuevas cuando los enfoques basados en la experiencia no son viables. Por lo tanto, la estrategia topográfica está vinculada al conocimiento del dominio a priori que se desarrolla a partir de una comprensión más fundamental de un sistema, posiblemente utilizando el conocimiento de los primeros principios. Este conocimiento se conoce como conocimiento profundo, causal o basado en modelos. [7]
Hoc [8] señaló que los enfoques sintomáticos pueden necesitar ser respaldados por enfoques topográficos porque los síntomas pueden definirse en diversos términos. Lo inverso también es cierto: el razonamiento superficial puede usarse de manera abductiva para generar hipótesis causales y de manera deductiva para evaluar esas hipótesis en una búsqueda topográfica.
Por lo general, la resolución de problemas se aplica a algo que ha dejado de funcionar de repente, ya que su estado de funcionamiento anterior forma las expectativas sobre su comportamiento continuo. Por lo tanto, el enfoque inicial a menudo se centra en los cambios recientes en el sistema o en el entorno en el que existe (por ejemplo, una impresora que "estaba funcionando cuando la enchufaron allí"). Sin embargo, existe un principio bien conocido de que la correlación no implica causalidad (por ejemplo, la falla de un dispositivo poco después de haber sido enchufado a una toma de corriente diferente no significa necesariamente que los eventos estuvieran relacionados. La falla podría haber sido una cuestión de coincidencia ). Por lo tanto, la resolución de problemas exige pensamiento crítico en lugar de pensamiento mágico .
Es útil considerar las experiencias comunes que tenemos con las bombillas. Las bombillas se "queman" más o menos al azar; con el tiempo, el calentamiento y enfriamiento repetidos de su filamento y las fluctuaciones en la energía que se le suministra hacen que el filamento se agriete o se vaporice. El mismo principio se aplica a la mayoría de los demás dispositivos electrónicos y principios similares se aplican a los dispositivos mecánicos. Algunas fallas son parte del desgaste normal de los componentes de un sistema.
El primer principio básico en la resolución de problemas es poder reproducir el problema, si se desea. El segundo principio básico en la resolución de problemas es reducir el "sistema" a su forma más simple que aún muestre el problema. El tercer principio básico en la resolución de problemas es "saber qué se está buscando". En otras palabras, comprender completamente la forma en que se supone que debe funcionar el sistema, para poder "detectar" el error cuando ocurre.
Un solucionador de problemas podría revisar cada componente de un sistema uno por uno, sustituyendo los componentes que sabe que funcionan bien por cada uno que pueda ser sospechoso. Sin embargo, este proceso de "sustitución en serie" puede considerarse degenerado cuando se sustituyen los componentes sin tener en cuenta una hipótesis sobre cómo su falla podría provocar los síntomas que se diagnostican.
Los sistemas simples e intermedios se caracterizan por listas o árboles de dependencias entre sus componentes o subsistemas. Los sistemas más complejos contienen dependencias o interacciones cíclicas ( bucles de retroalimentación ). Dichos sistemas son menos susceptibles a las técnicas de resolución de problemas de "bisectrices".
También es útil empezar desde un estado conocido y correcto, siendo el mejor ejemplo el reinicio de la computadora . También es bueno probar un tutorial cognitivo . La documentación completa producida por redactores técnicos competentes es muy útil, especialmente si proporciona una teoría de funcionamiento del dispositivo o sistema en cuestión.
Una causa común de problemas es el mal diseño , por ejemplo, un mal diseño de factores humanos , donde un dispositivo podría insertarse al revés o al revés debido a la falta de una función de forzamiento adecuada ( restricción de modelado de comportamiento ) o una falta de diseño tolerante a errores . Esto es especialmente malo si va acompañado de habituación , donde el usuario simplemente no nota el uso incorrecto, por ejemplo, si dos partes tienen funciones diferentes pero comparten una carcasa común de modo que no es evidente en una inspección casual qué parte se está utilizando.
La resolución de problemas también puede adoptar la forma de una lista de verificación sistemática , un procedimiento de resolución de problemas, un diagrama de flujo o una tabla que se elabora antes de que se produzca un problema. El desarrollo de procedimientos de resolución de problemas con antelación permite pensar con suficiente antelación en los pasos que hay que seguir para solucionar el problema y organizarlo de forma que el proceso sea lo más eficiente posible. Las tablas de resolución de problemas se pueden informatizar para que resulten más eficaces para los usuarios.
Algunos servicios de resolución de problemas informáticos (como Primefax, que más tarde pasó a llamarse MaxServ) muestran inmediatamente las 10 soluciones principales con la mayor probabilidad de solucionar el problema subyacente. El técnico puede responder preguntas adicionales para avanzar en el procedimiento de resolución de problemas, y cada paso reduce la lista de soluciones, o implementar inmediatamente la solución que cree que solucionará el problema. Estos servicios ofrecen un reembolso si el técnico da un paso adicional después de solucionar el problema: informar sobre la solución que realmente solucionó el problema. La computadora utiliza estos informes para actualizar sus estimaciones de qué soluciones tienen la mayor probabilidad de solucionar ese conjunto particular de síntomas. [9] [10]
Una solución metódica y eficaz de problemas comienza con una comprensión clara del comportamiento esperado del sistema y de los síntomas observados. A partir de ahí, el solucionador de problemas formula hipótesis sobre las posibles causas y diseña (o quizás hace referencia a una lista de verificación estandarizada de) pruebas para eliminar esas posibles causas. Este enfoque se suele denominar " dividir y vencer ".
Dos estrategias comunes que utilizan los solucionadores de problemas son verificar primero las condiciones que se encuentran con frecuencia o que se pueden probar fácilmente (por ejemplo, verificar que la luz de la impresora esté encendida y que su cable esté firmemente asentado en ambos extremos). Esto a menudo se conoce como "ordeñar el panel frontal". [11]
Luego, "dividir" el sistema (por ejemplo, en un sistema de impresión en red, verificar si el trabajo llegó al servidor para determinar si existe un problema en los subsistemas "hacia" el extremo del usuario o "hacia" el dispositivo).
Esta última técnica puede ser particularmente eficiente en sistemas con largas cadenas de dependencias serializadas o interacciones entre sus componentes. Es simplemente la aplicación de una búsqueda binaria a lo largo del rango de dependencias y a menudo se la denomina “división por la mitad”. [12] Es similar al juego de las “ veinte preguntas ”: cualquiera puede aislar una opción entre un millón dividiendo el conjunto de alternativas por la mitad 20 veces (porque 2^10 = 1024 y 2^20 = 1.048.576).
Uno de los principios básicos de la resolución de problemas es que los problemas reproducibles se pueden aislar y resolver de manera confiable. A menudo, en la resolución de problemas se hace un esfuerzo y un énfasis considerables en la reproducibilidad... en encontrar un procedimiento para inducir de manera confiable la aparición del síntoma.
Algunos de los problemas más difíciles de solucionar están relacionados con síntomas que se producen de forma intermitente . En electrónica, esto suele deberse a componentes que son sensibles al calor (ya que la resistencia de un circuito varía con la temperatura de los conductores que lo componen). Se puede utilizar aire comprimido para enfriar puntos específicos de una placa de circuito y una pistola de calor para elevar las temperaturas; por lo tanto, la solución de problemas de los sistemas electrónicos con frecuencia implica la aplicación de estas herramientas para reproducir un problema.
En programación informática, las condiciones de carrera a menudo conducen a síntomas intermitentes que son extremadamente difíciles de reproducir; se pueden utilizar varias técnicas para forzar que una función o un módulo en particular se llame más rápidamente de lo que se haría en una operación normal (de manera análoga a "calentar" un componente en un circuito de hardware), mientras que se pueden utilizar otras técnicas para introducir mayores demoras o forzar la sincronización entre otros módulos o procesos que interactúan.
Los problemas intermitentes pueden definirse así:
Un intermitente es un problema para el cual no existe un procedimiento conocido para reproducir consistentemente su síntoma.
—Steven Litt, [13]
En particular, afirma que existe una distinción entre la frecuencia de ocurrencia y un "procedimiento conocido para reproducir consistentemente" un problema. Por ejemplo, saber que un problema intermitente ocurre "dentro" de una hora de un estímulo o evento particular... pero que a veces sucede en cinco minutos y otras veces lleva casi una hora... no constituye un "procedimiento conocido" incluso si el estímulo aumenta la frecuencia de las exhibiciones observables del síntoma.
Sin embargo, a veces los solucionadores de problemas deben recurrir a métodos estadísticos... y sólo pueden encontrar procedimientos para aumentar la incidencia del síntoma hasta un punto en el que sea posible la sustitución en serie o alguna otra técnica. En tales casos, incluso cuando el síntoma parece desaparecer durante períodos significativamente más largos, hay poca confianza en que se haya encontrado la causa raíz y que el problema esté realmente resuelto.
También se pueden realizar pruebas para estresar ciertos componentes y determinar si han fallado. [14]
Aislar fallas de componentes individuales que causan síntomas reproducibles es relativamente sencillo.
Sin embargo, muchos problemas sólo ocurren como resultado de múltiples fallas o errores. Esto es particularmente cierto en el caso de los sistemas tolerantes a fallas o aquellos con redundancia incorporada. Las características que agregan redundancia, detección de fallas y conmutación por error a un sistema también pueden estar sujetas a fallas, y una cantidad suficiente de fallas de componentes diferentes en cualquier sistema lo "derribarán".
Incluso en sistemas simples, el solucionador de problemas debe tener siempre en cuenta la posibilidad de que haya más de una falla. (Reemplazar cada componente, mediante la sustitución en serie y luego cambiar cada componente nuevo por el antiguo cuando se detecta que el síntoma persiste, puede no resolver estos casos. Más importante aún, el reemplazo de cualquier componente por uno defectuoso puede, en realidad, aumentar la cantidad de problemas en lugar de eliminarlos).
Tenga en cuenta que, si bien hablamos de "reemplazar componentes", la resolución de muchos problemas implica ajustes o puesta a punto en lugar de "reemplazarlos". Por ejemplo, es posible que sea necesario limpiar o apretar simplemente los conductores que se rompen de forma intermitente o que los "contactos sucios o sueltos". Todo lo que se diga sobre "reemplazar" debe entenderse como "reemplazo, ajuste u otra modificación".