System Design
Descubrimiento del problema
Explica cómo descubrir el problema real mediante evidencia, procesos actuales, impacto, causas e hipótesis antes de comprometer una solución técnica.
- Última actualización
- Actualizada
- Nivel
- Fundamentos
System Design
Explica cómo descubrir el problema real mediante evidencia, procesos actuales, impacto, causas e hipótesis antes de comprometer una solución técnica.
El primer riesgo de un proyecto no es implementar mal una solución; es implementar correctamente una solución para el problema equivocado.
El descubrimiento del problema busca comprender qué ocurre hoy, a quién afecta, con qué frecuencia, por qué importa y qué evidencia permite distinguir causas de síntomas.
Una solicitud como “necesitamos una aplicación de inventario” ya contiene una solución. El trabajo de descubrimiento retrocede hasta la necesidad real:
solución solicitada
→ síntoma observado
→ proceso actual
→ impacto
→ causas confirmadas
→ hipótesis pendientes
→ resultado deseadoSin descubrimiento, el equipo suele diseñar desde percepciones aisladas:
El descubrimiento reduce estas distorsiones antes de comprometer datos, interfaces y arquitectura.
Ejemplo:
Síntoma
→ algunos pedidos llegan incompletos
Problema observable
→ no existe una fuente central ni validación del pedido
Causas posibles
→ mensajes dispersos
→ información opcional
→ responsabilidades ambiguas
→ stock desactualizado
Impacto
→ retrabajo, devoluciones y pérdida de confianzaUna causa no debe declararse confirmada solo porque parece lógica. Puede requerir observación, métricas o experimentos.
Permiten conocer objetivos, decisiones y excepciones. Deben pedir ejemplos concretos:
Lo que las personas hacen puede diferir de lo que recuerdan o del procedimiento oficial. Observar revela hojas auxiliares, mensajes, esperas y retrabajo.
Tickets, métricas, logs, hojas de cálculo, correos y reportes permiten medir frecuencia e impacto.
Formularios, manuales, contratos, esquemas y sistemas anteriores muestran reglas y dependencias, pero pueden estar obsoletos.
Una estructura útil:
Contexto:
Personas afectadas:
Proceso actual:
Problema observable:
Frecuencia o volumen:
Impacto:
Evidencia:
Causas confirmadas:
Hipótesis pendientes:
Resultado deseado:
Preguntas abiertas:Ejemplo:
Las sucursales reciben pedidos por WhatsApp y teléfono.
Operaciones transcribe manualmente la información.
En promedio 8 % de pedidos pierde dirección o producto.
Esto genera llamadas, retrasos y cancelaciones.
La dispersión de canales está confirmada; todavía debe validarse cuánto aporta el stock desactualizado.
Se busca reducir pedidos incompletos y obtener trazabilidad del estado.Ayuda a profundizar, pero no garantiza una única causa raíz. Sistemas reales suelen tener varias causas interactuando.
Visualiza pasos, actores, handoffs, esperas y puntos de dolor.
Ayudan a descubrir eventos, decisiones y lenguaje compartido. No deben convertirse en ceremonia sin participantes del negocio.
Confirma magnitud, distribución y segmentos. Un promedio puede esconder que el problema ocurre solo en ciertas sucursales.
Cuando la incertidumbre está en el comportamiento del usuario, una prueba pequeña produce más evidencia que una discusión prolongada.
Petición:
“Necesitamos notificaciones automáticas.”Preguntas:
Resultado posible:
El problema no es ausencia de notificaciones.
El estado de preparación no se registra de forma confiable,
por lo que ningún canal puede avisar correctamente.La solución cambia: primero modelar y capturar estados; después decidir el canal.
No elijas silenciosamente. Registra objetivos y conflictos; busca evidencia y autoridad de decisión.
Define un baseline temporal o mecanismo de medición antes de inventar porcentajes.
La frecuencia baja no elimina importancia si el impacto legal, financiero o de seguridad es alto.
La ausencia de documentación no significa ausencia de reglas. Las reglas pueden vivir en experiencia tácita.
Investiga qué trabajo resuelve la hoja, no solo qué columnas tiene.
Empuja al stakeholder a diseñar la solución sin explorar el problema.
Una percepción puede ser válida, pero debe distinguirse de una medición.
Problemas sociotécnicos suelen combinar proceso, datos, incentivos y herramientas.
Discovery también necesita límites. Cuando el riesgo principal está comprendido, conviene prototipar y aprender.
El equipo puede:
Stakeholders y actores identifica quién aporta necesidades, quién decide, quién opera y quién interactúa con el sistema.