Un núcleo, dieciocho entradas en el registro y una en producción
Qué comparten nuestros productos sectoriales, qué hay que escribir de nuevo cada vez y por qué publicamos un registro de estados y no un contador.
Qué hay debajo de todos los productos a la vez
En cualquier sistema con empleados y clientes se repite lo mismo. Alguien entra con su propia cuenta. Tiene un rol. El rol permite unas cosas y prohíbe otras. A alguien le llegan avisos, a otro una factura, la correspondencia vive en un sitio y se encuentra buscando, y un registro recuerda quién cambió qué.
Son cinco entidades obligatorias: usuario, empresa, el rol entre ambos, la clave de acceso y la excepción de permisos para una empresa concreta, más diecinueve paquetes de capacidades y tres servicios: acceso, facturas y asistente. Escrito una vez, sin reescribirse para ningún sector.
La quinta entidad no salió de un plan sino de un caso. En el alquiler, el responsable de una sucursal necesitaba acceso a los informes destinados a los copropietarios de la flota, y el rol habitual de responsable no lo concede. La tabla de roles no sabía expresarlo. El motivo era sectorial, la solución resultó general, y ahora la heredan todos.
Cuánto se transfiere en realidad
Aquí se acostumbra a citar una parte grande. Nosotros medimos dos veces, y las dos cifras salieron incómodas.
El CRM de alquiler que pasamos a la base común son 318 757 líneas y cuatro años de reglas acumuladas. De 1872 líneas de esquema, 1650 eran del sector, es decir el 88%. El andamiaje común eran 220 líneas.
La segunda medición es más dura. Hicimos una plataforma de alquiler, luego una de inmobiliaria. Sectores vecinos, los dos sobre un objeto que se entrega a alguien por un tiempo o para siempre. De 113 conceptos de negocio de ambos productos, siete resultaron comunes. Cerca del 6%, y esa cifra merece una lectura aparte.
De ahí sale una consecuencia útil mucho más allá de nuestra cocina. "Esto ya lo tenemos, solo hay que configurarlo" es una frase sobre el andamiaje, no sobre tu negocio. De dónde salen las cuatro semanas recorre lo mismo desde el lado de quien elige proveedor.
Con qué se sostiene esto
El traslado del alquiler llevó cuatro semanas, y los operarios trabajaban en la aplicación reconstruida desde la tercera, gestionando reservas reales a través de ella.
El cuello de botella no fueron los plazos de desarrollo. Tres veces ocurrió que los datos reales del alquiler contradecían la especificación de la base, y cada vez reescribimos la especificación y no los datos. Una base que no aguanta el contacto con un producto que lleva cuatro años funcionando todavía no es una base.
Un resultado colateral importó más que los planificados. Reglas de negocio como "no hay entrega de vehículo hasta que el contrato esté firmado y la fianza ingresada" las escribimos directamente en la capa que llaman los agentes de IA externos. Ahora el agente no puede saltarse la regla ni siquiera sin saber que existe: la capa devuelve una negativa señalando la condición incumplida. Cada producto siguiente lo recibe gratis.
El marcador, sin adornos
| Estado | Cantidad |
|---|---|
| En producción | 1 |
| Piloto | 2 |
| Esperando migración | 4 |
| Desviados de la especificación | 4 |
| Sin pasar a la base | 2 |
| Nombrados, sin empezar | 3 |
| Sustituidos por otro | 2 |
| Conformidad plena con la especificación | 0 |
Dieciocho entradas. Una en producción. Y el estado que la especificación fija como meta no lo ha alcanzado todavía ninguna.
El contador de productos es un número de marketing, el registro de estados es de ingeniería, y solo el primero puede equivocarse sin que nadie lo note. "Dieciocho productos sobre una base común" sobrevive a cualquier desviación por debajo. "Uno en producción, ninguno en conformidad plena" genera trabajo.
A quien construya una familia de productos propia, de aquí no se le transfiere nuestro código sino la costumbre: decidir antes del primer producto qué capa tiene permiso para tener opinión, poner la base común detrás de una versión y llevar el registro con la honestidad suficiente para que resulte incómodo mirarlo. Un registro que no hace torcer el gesto a nadie es un registro que nadie actualiza.
Cómo se ve esto desde el lado del cliente y no del que construye está en qué automatizar primero.
01¿Qué es exactamente lo común y qué se escribe de nuevo cada vez?+
Común es lo que funciona igual en cualquier sistema con empleados y clientes: quién ha entrado con su propia cuenta, qué rol tiene, qué permite y qué prohíbe ese rol, a quién le llegan los avisos, a quién se le factura, dónde vive la correspondencia y quién cambió qué. Aquí entran también el cifrado de datos personales y las traducciones. Nada de eso depende de si alquilas excavadoras o vendes pisos, así que se escribe una vez. De nuevo se escribe la materia propia: los objetos del sector y las reglas de paso entre etapas. Un negocio de alquiler tiene una máquina, una reserva y una entrega. Una agencia inmobiliaria tiene un inmueble, un anuncio y una operación. Las palabras se parecen, las reglas de dentro no, y el tiempo lo cuestan las reglas.
02¿Cómo de grande es la parte que hay que escribir de cero?+
Mayor de lo que casi todo el mundo espera, nosotros incluidos al principio. Dos cifras, ambas medidas. La primera: en el CRM de alquiler que pasamos a la base común, 1650 de 1872 líneas de esquema resultaron ser del sector, es decir el 88%, y solo 220 líneas eran el andamiaje que aporta la base. La segunda es más dura. Al construir un segundo producto en un sector vecino, de los 113 conceptos de negocio de ambos productos se compartieron 7. Cerca del 6%. De ahí sale una consecuencia simple para quien elige proveedor: la frase esto ya lo tenemos, solo hay que configurarlo describe el andamiaje, no tu negocio. Ese segundo caso lo contamos aparte, porque la cifra es incómoda y merece detalle.
03¿Para qué construir una base común si se transfiere tan poco?+
Porque el ahorro no viene de donde se lo busca. Antes de que un producto nuevo pueda ocuparse de su sector, necesita accesos, empresas, roles y permisos, facturas conectadas a un proveedor de pago real, entrada de mensajes de clientes, avisos, traducciones, un registro de cambios y cifrado de datos personales. La primera vez esa lista lleva meses, es idéntica para cualquier sector, y cualquier error silencioso en ella aparece no en una demostración sino en una auditoría de seguridad. Construida una vez, permite que el siguiente producto empiece donde empieza el negocio de verdad. Las reglas sectoriales habrían sido distintas de todos modos, y la ganancia nunca estuvo ahí.
04¿Por qué publicáis un registro de estados y no un número de productos?+
Porque un contador de productos es un número de marketing y un registro de estados es uno de ingeniería, y solo el primero puede equivocarse sin que nadie lo note. La frase dieciocho productos sobre una base común sobrevive a cualquier desviación por debajo: sigue siendo cierta mientras algo funcione. La línea uno en producción, dos en piloto, ninguno en conformidad plena genera trabajo, porque cada estado es algo que alguien tiene que mover. El registro se lleva a mano y se actualiza en cada publicación de la especificación justamente para no deslizarse en silencio hacia la primera formulación. Por el mismo motivo el repositorio de la especificación se mantiene libre de código ejecutable: una especificación que entrega un runtime deja de ser comprobable contra nada.
