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.
Contenido7 secciones
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é un lector más rápido no era la respuesta
Bajo esta elección concreta hay una regla general que conviene separar de lo particular.
Una comprobación vale lo que vale el registro que lee. Si el registro dice que una máquina no está disponible mientras está en el patio, cualquier lector de ese registro, por rápido que sea, repite el error, y el cliente que pregunta por qué se le rechazó recibe una respuesta que no se apoya en nada cierto.
Así que primero fue el registro. Cuando un solo registro tuvo el estado real de cada máquina, el sistema pudo comprobar la disponibilidad contra él en tiempo real, en la consulta y otra vez en el momento de prometer la máquina. También cambió la entrada: las 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, las lee un modelo y las convierte en una petición estructurada. 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 en tiempo real pasó a hacerse también en el momento del compromiso y no solo en el 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.
Preguntas frecuentes
¿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.
¿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 cualquiera que lea esos datos, una persona o un modelo, reproduce el error, solo que más rápido y con más seguridad. El fallo estaba en el registro, no en quien lo leía, así que ningún lector puesto encima podía arreglarlo. El orden tenía que ser el inverso: primero un registro que acierte con el estado de cada máquina, y después comprobar la disponibilidad contra él en tiempo real. Eso es lo que hace el sistema terminado, y por eso la velocidad no se pagó con respuestas equivocadas.
¿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 de disponibilidad, ahora en tiempo real contra ese registro, pasó a hacerse también en el momento del compromiso y no solo en el 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.
¿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.
