Especifica la operación antes de especificar el stack
El software operacional que falla suele nacer como conversación tecnológica. El que dura nace como conversación de orden de trabajo.
Cuando una planta, una organización de campo o una oficina de calidad pide software, el primer impulso sigue siendo nombrar herramientas: un CMMS, low-code, un agente, un módulo de ERP. Ese impulso es caro. El stack es una consecuencia. El trabajo es la especificación.
Qué implica construir software para una operación específica
Significa que la unidad de diseño no es una pantalla. Es un ciclo cerrado: quién genera la demanda, qué evidencia se exige, quién puede cambiar el estado, qué ocurre si faltan refacciones y cómo se leerá el registro en una auditoría seis meses después.
Si no puedes recorrer una orden de trabajo desde la solicitud hasta el histórico sin salir del sistema, no tienes un sistema. Tienes un formulario con base de datos.
Las preguntas útiles son operacionales, no de arquitectura. Qué llega tarde esta semana, y por qué. Quién puede iniciar un trabajo, y quién puede cerrar uno crítico. Qué cuenta como registro: el activo, la mano de obra, las partes, la firma — no un correo reenviado.
| Pregunta | Mala respuesta | Respuesta útil |
|---|---|---|
| Qué llega tarde? | “Todo” | “OT correctivas esperando sellos, Planta Norte” |
| Quién decide? | “El supervisor” | “El turno inicia; confiabilidad cierra lo crítico” |
| Cuál es el registro? | “Guardamos correos” | “Activo + mano de obra + partes + firma” |
Una secuencia práctica
Discovery no es un taller para recolectar deseos. Es una lectura estructurada de la operación actual: acompaña un turno, muestrea las últimas cincuenta excepciones y escribe la máquina de estados que ya existe — aunque hoy viva en WhatsApp y una hoja compartida.
- Nombra el activo, la cuadrilla y la restricción antes de nombrar el framework.
- Dibuja permisos como parte del flujo, no como un apéndice en configuración.
- Trata las integraciones como contratos: evento, payload, fallo.
- Mantén a una persona en el loop cuando el cambio de estado tenga peso de seguridad o legal.
Solo entonces el stack se vuelve una decisión. A veces la respuesta correcta es un producto que ya operamos. A veces es un sistema a medida. En ambos casos, el software es una especificación del trabajo — no un catálogo de módulos esperando ser configurados.
