La decisión que dio forma a una obra de tres semanas
Había tres opciones plausibles sobre la mesa y dos llevaban meses. La diferencia fue decidir qué registro tiene derecho a estar en lo cierto sobre una reserva.
Con qué nos dejó la medición
La semana de recuento produjo un hallazgo que cambió el proyecto: máquinas físicamente paradas en el patio figuraban como no disponibles con frecuencia suficiente para explicar tanto las dobles reservas como parte de los rechazos.
Esa es una frase sobre datos, no sobre personas. Si el recuento hubiera dado cerca de cero, la conclusión honesta sería que el personal estaba sobrecargado y la respuesta era capacidad o enrutado. No dio, así que la respuesta estaba en cómo se registraba la disponibilidad.
Siguieron tres opciones. Dos de ellas eran meses.
Las tres opciones
| Opción | Plazo | Por qué se rechazó o se eligió |
|---|---|---|
| Sustituir el sistema de alquiler | Meses | Arregla un campo migrando todo, en plena temporada |
| Poner un modelo sobre las hojas | Semanas | Responde sobre datos erróneos, más rápido y sin rastro |
| Un registro autoritativo y estados reales | 3 semanas | Arregla exactamente lo que estaba mal |
La primera es la opción que más se propone cuando el culpable es el modelo de datos, y suele ser la escala equivocada de respuesta. Una sustitución migra histórico, reforma a todos y mantiene dos sistemas de media confianza en paralelo, todo para corregir un campo. En un negocio estacional, hacerlo en los meses en que la operación ya va al límite no es un detalle.
La segunda habría sido la más fácil de vender. Un modelo leyendo las hojas existentes y respondiendo preguntas de disponibilidad demuestra bien y falla exactamente como la medición ya predecía: los datos dicen que la máquina no está disponible mientras está en el patio, y el modelo repite eso con más seguridad y menos trazabilidad de la que tenía la hoja.
Por qué el modelo no recibió ese trabajo
Bajo esta elección concreta hay una regla general que conviene separar de lo particular.
Una comprobación de disponibilidad debe devolver la misma respuesta a la misma pregunta todas las veces, y debe explicarse después cuando un cliente pregunte por qué se le rechazó. Una respuesta probabilística a una pregunta determinista es un defecto, y ninguna mejora del modelo cambia eso.
Así que el modelo recibió exactamente un trabajo en el sistema terminado: leer consultas que llegan en texto libre a las once de la noche, nombrando la máquina con las palabras del cliente y con fechas en un formato que ningún campo espera. Eso es genuinamente difícil para una regla y genuinamente fácil para un modelo. El reparto completo está en adónde se van las cuatro horas.
Qué cambió el diseño elegido
Dos cosas, y la segunda pesó más.
La disponibilidad dejó de ser un campo verdadero o falso y pasó a ser siete estados explícitos, de modo que la máquina devuelta pendiente de revisión, la que está en tránsito y la reservada sin confirmar dejaron de aparecer como libres.
Después un registro pasó a ser autoritativo sobre lo reservado, y la comprobación se movió al momento del compromiso en lugar del momento de la consulta. Ese segundo cambio terminó con las dobles reservas, porque los conflictos vivían en la ventana entre que alguien miraba una hoja compartida y alguien prometía una máquina.
Ninguno de los dos cambios es exótico. Ninguno necesitó tecnología nueva. Ambos necesitaron una decisión que alguien tenía que tomar y que nadie había tomado.
El coste que no aparece en ninguna propuesta
Hacer un registro autoritativo significa que alguien tiene que dejar de llevar su propia copia.
Toda operación de este tipo tiene una o dos personas con una hoja privada, y no están obstruyendo. Empezaron a llevarla porque en algún momento el sistema oficial se equivocó y su hoja acertó, y desde entonces ha estado sosteniendo el negocio en silencio.
Pedirles que confíen en un sistema que ya les falló es el trabajo de verdad, y cae de forma muy distinta según se haya escuchado antes su objeción. Esta es la parte que más cerca estuvo de descarrilar el proyecto. No aparece en ninguna propuesta que hayamos visto, incluidas las nuestras antiguas, y por eso la decisión de fuente de verdad se nombra ahora al principio en lugar de descubrirse en la segunda semana.
Qué produjo
La reserva a despacho pasó de 4 horas a 3 minutos. Las dobles reservas se acabaron. La capacidad de temporada alta subió 2,5x con el equipo que ya estaba, y la obra cupo en 3 semanas. El conjunto completo está en la página del caso.
Las tres semanas son consecuencia de la decisión y no de la velocidad. Las dos opciones rechazadas no eran versiones más lentas del mismo proyecto; eran proyectos distintos, y uno de ellos habría terminado más o menos cuando acabara la temporada.
La parte transferible
Antes de aceptar nada, encuentra el hecho sobre el que dos de tus sistemas discrepan y decide cuál gana.
Esa decisión cuesta cero, lleva una tarde y determina el tamaño de todo proyecto posterior. La medición que lo saca a la luz está en la semana previa, y es por la misma razón que los datos contradictorios son el único tipo alrededor del cual no conviene automatizar mientras la pregunta no tenga respuesta.
01¿Por qué no sustituir el software de alquiler, si el modelo de datos era el problema?+
Porque el modelo de datos estaba mal de una forma concreta y no mal en todas partes, y sustituir un sistema para arreglar un campo es un proyecto de meses que arrastra riesgos que nada tienen que ver con el problema original. Una sustitución implica migrar histórico, reformar a todo el mundo y hacer convivir dos sistemas en paralelo durante un periodo en que ambos reciben media confianza. También pone la operación entera sobre una herramienta nueva justo en los meses en que ya va apretada, y en un negocio estacional el momento de eso no es un detalle. El arreglo más estrecho fue dejar al sistema existente sosteniendo lo que sostenía bien y hacer un registro autoritativo sobre lo único en lo que se equivocaba, que son las reservas contra activos. Eso son semanas en vez de meses, y deja abierta la opción de sustituir el sistema más adelante en lugar de gastarla ahora.
02¿Qué tenía de malo poner un modelo de lenguaje sobre las hojas existentes?+
Habría respondido a la pregunta de disponibilidad más rápido e igual de mal, que es peor que responder despacio. La medición ya había establecido que los datos de base marcaban máquinas como no disponibles mientras estaban en el patio, y un modelo que lee esos datos reproduce el error con más seguridad y menos trazabilidad. Hay además un problema más sutil que conviene nombrar, porque se repite en la mayoría de proyectos donde se propone un modelo como atajo: una comprobación de disponibilidad debe devolver la misma respuesta a la misma pregunta todas las veces, y debe ser explicable después cuando un cliente pregunte por qué se le rechazó. Una respuesta probabilística a una pregunta determinista es un defecto por bueno que sea el modelo. El modelo se ganó su sitio en el sistema terminado, pero en la puerta de entrada, sobre consultas no estructuradas, que es trabajo que una regla realmente no hace.
03¿Qué cambió realmente el diseño elegido?+
Dos cosas, y la segunda es la que importó. Primero, la disponibilidad dejó de ser un único campo verdadero o falso y pasó a ser un conjunto explícito de estados, de modo que una máquina devuelta pendiente de revisión, una en tránsito y una reservada sin confirmar dejaron de aparecer como libres. Segundo, un registro pasó a ser autoritativo sobre lo reservado, y la comprobación se movió al momento del compromiso en lugar del momento de la consulta. Ese segundo cambio es lo que acabó con las dobles reservas, porque los conflictos vivían en la ventana entre que alguien miraba una hoja compartida y alguien prometía una máquina. Ninguno de los dos cambios es exótico y ninguno requirió tecnología nueva. Requirieron una decisión que alguien tenía que tomar y que nadie había tomado, que es la forma habitual de estos proyectos.
04¿Qué costó esa decisión?+
Alguien tuvo que dejar de llevar su propia copia, y ese es un coste político y no técnico. En la práctica toda operación de este tipo tiene una o dos personas con una hoja privada, normalmente porque en algún momento el sistema oficial se equivocó y su hoja acertó. Esas personas no están obstruyendo; sostienen el apaño que ha mantenido el negocio en pie. Hacer un registro autoritativo es pedirles que confíen en un sistema que ya les falló, y esa petición cae de forma muy distinta según se haya escuchado antes su objeción o no. Esta es la parte que más cerca estuvo de descarrilar el proyecto, no aparece en ninguna propuesta que hayamos visto, incluidas las nuestras antiguas, y por eso hoy nombramos la decisión de fuente de verdad al principio en lugar de descubrirla en la segunda semana.
