Ponerse de acuerdo en el problema que se está resolviendo
Una de las formas más sencillas de acordar la definición del problema es escribirlo y ver si todos están de acuerdo.
Pregunte al grupo: ¿cuál es el problema?
-
Es muy normal precipitarse a definir la solución, en lugar de dedicar tiempo a entender primero el problema.
Escriba el problema y compruebe si todos están de acuerdo con la definición.
A continuación, pregunte de nuevo al grupo: ¿cuál es el problema realmente?
-
Busque causas raíces o el "problema subyacente al problema". El problema real a menudo se oculta detrás de lo que
se percibe como un problema.
No acepte la primera definición de un problema. Continúe preguntándose "por qué". Explore la naturaleza del problema.
A veces, el grupo está tan centrado en un visualizar una solución, que no puede formular cuál es realmente el problema
subyacente. En tales casos, explore las ventajas de la solución y, a continuación, intente encontrar los problemas que
se solucionan gracias a ellas. Puede analizar si esos problemas son problemas "reales" en la organización. Las técnicas
más comunes utilizadas para encontrar el problema subyacente son la tormenta de ideas, los diagramas de
espina de pescado y los diagramas de
Pareto.
|
Identificar los interesados
Dependiendo de la experiencia en el dominio del equipo de desarrollo, la identificación de los interesados puede ser un
paso trivial o no. A menudo, sólo implica entrevistar a los encargados de tomar las decisiones, a los usuarios
potenciales y a otras partes interesadas. Las siguientes preguntas son muy útiles:
-
¿Cuáles son los usuarios del sistema?
-
¿Quién es el comprador del sistema?
-
¿Quién más se verá afectado por los resultados del sistema?
-
¿Quién evaluará y dará el visto bueno al sistema cuando se entregue y se despliegue?
-
¿Existen otros usuarios internos o externos del sistema cuyas necesidades se deban cubrir?
-
¿Quién mantendrá el nuevo sistema?
-
¿Hay alguien más?
-
Repetimos, ¿hay alguien más?
Empiece a desarrollar perfiles de los usuarios potenciales (o reales) del sistema. La información inicial sobre
los usuarios clave y su entorno se debe documentar en el documento Visión.
|
Definir los límites del sistema
Los límites del sistema definen el marco que separa la solución del mundo real que rodea a la solución. En otras
palabras, los límites del sistema describen un sobre en el que está contenida la solución. Se pasa información, en
forma de entradas y salidas, del sistema a los usuarios que se encuentran fuera del sistema. Todas las interacciones
con el sistema se producen a través de interfaces entre el sistema y el mundo exterior.
En muchos casos, los límites del sistema son obvios. Por ejemplo, los límites de un gestor de contactos personales de
'shrinkwrap' de un único usuario que se ejecuta en Microsoft Windows® están relativamente bien definidos. Hay sólo un
usuario y una plataforma. Las interfaces entre el usuario y la plataforma están formadas por diálogos de interfaz de
usuario a los que accede el usuario para entrar información en el sistema, y los informes de salida y las vías de
comunicación que utiliza el sistema para documentar o transmitir la información resultante.
|
Identificar las restricciones que se imponen en el sistema
Se debe considerar una amplia variedad de orígenes de restricciones. A continuación, se proporciona una lista de los
orígenes potenciales y las preguntas que se deben realizar:
-
Políticos: ¿Existen cuestiones políticas internas o externas que afecten a las posibles soluciones? ¿Entre
departamentos?
-
Económicos: ¿Qué restricciones financieras o presupuestarias se aplican? ¿Existen consideraciones de costes de
ventas o de precios de productos? ¿Hay problemas de licencia?
-
Medioambientales: ¿Existen restricciones normativas o medioambientales? ¿Legales? ¿Restricciones de otros
estándares?
-
Técnicos: ¿Existe alguna restricción en la elección de la tecnología? ¿Estamos restringidos a trabajar con las
plataformas o tecnologías existentes? ¿Está prohibido el uso de nuevas tecnologías?
-
Viabilidad: ¿Se ha definido la planificación? ¿Estamos restringidos a los recursos existentes? ¿Se puede utilizar
mano de obra externa? ¿Podemos ampliar los recursos? ¿Temporalmente? ¿Permanentemente?
-
Sistema: ¿La solución se debe crear en nuestros sistemas existentes? ¿Debemos mantener la compatibilidad con las
soluciones existentes? ¿Qué sistemas operativos y entornos deben estar soportados?
|
Formular sentencias del problema
Con todo el grupo, trabaje en los gráficos sobre caballetes y rellene la siguiente plantilla para cada problema
identificado:
El problema de <describir el problema>
afecta a <los interesados afectados por el problema>.
El impacto del problema es <¿cuál es el impacto del problema?>.
Una solución satisfactoria sería <enumerar algunas ventajas clave de una solución satisfactoria>.
El objetivo de esta plantilla es ayudarle a distinguir las soluciones/respuestas de los problemas/preguntas.
Ejemplo:
El problema de: la resolución tardía e incorrecta de los problemas de soporte al cliente
afecta a: nuestros clientes, los representantes de soporte al cliente y los técnicos de servicio.
El impacto del problema es: insatisfacción del cliente, disminución de la calidad percibida, empleados
descontentos y pérdida de ingresos.
Una solución satisfactoria sería: proporcionar acceso en tiempo real a una base de datos de localización de
problemas para los representantes de soporte y facilitar el envío de técnicos de servicio, de manera puntual, sólo a
aquellas ubicaciones que necesiten realmente su asistencia.
|
Definir las características del sistema
A partir de las ventajas enumeradas en las sentencias del problema, desarrolle una lista de características que desee
en el sistema. Descríbalas brevemente y proporcióneles atributos que permitan definir el estado general y su prioridad
en el proyecto.
|
Evaluar los resultados
Debe comprobar la visión en esta fase para verificar que el trabajo está al día, pero no la revise en detalle. Tenga en
cuenta la lista de comprobación del documento Visión (Lista de comprobación:
Visión).
|
|