Reservar un tren en Japón puede costar ¥560 por persona antes siquiera de subir al tren. JR, la red ferroviaria del país, está dividida en seis compañías regionales con plataformas de reserva separadas, y esa estructura interna se filtra hasta la pantalla del usuario. Un ingeniero de software lo comprobó en carne propia: compró su boleto online con una tarjeta de crédito virtual y descubrió, después de confirmar la compra, que necesitaba la tarjeta física para retirar el ticket en la estación.
Para cualquier founder que construye producto, la anécdota es un caso de estudio sobre qué pasa cuando el organigrama se convierte en la interfaz.
¿Por qué reservar un tren en Japón es tan complicado?
Japón tiene una de las redes ferroviarias más eficientes del mundo, pero su sistema de reservas online no acompaña esa reputación. La red de JR está dividida en seis compañías regionales de pasajeros: JR Hokkaido, JR East, JR West, JR Central, JR Shikoku y JR Kyushu. Cada una tiene su propia plataforma de reservas, con coberturas que se superponen y reglas distintas.
¿Y esto cómo se aplica en tu negocio?
Dueños de negocio de Latinoamérica y España usan un agente de IA para ganar más y recuperar su tiempo. El Kit «tu mano derecha con IA» te muestra cómo en un video de 11 minutos, con una ficha para armar el tuyo. CAR está cerrada por ahora; al anotarte, te avisamos cuando abra.
👥 Quiero el Kit →El resultado es predecible: quien quiere ir de un punto A a un punto B tiene que averiguar primero qué compañía opera ese trayecto. El sistema no lo resuelve por él.
A eso se suma una lógica de tarifas que no existe en la mayoría de los mercados. Al comprar un asiento en un tren expreso, el mensaje del sistema es explícito: "When boarding the train, you will need basic fare ticket or IC card such as Suica in addition to Super (Limited) Express Train ticket." Es decir, el boleto que acabas de comprar no alcanza para abordar: necesitas además la tarifa básica o una tarjeta IC.
Para un usuario que cree que está comprando "un ticket", el modelo mental se rompe en el segundo paso.
¿Qué es la Ley de Conway y qué tiene que ver con una web de reservas?
La Ley de Conway sostiene que una aplicación refleja los límites sociales de la organización que la produjo. Melvin Conway la formuló en su paper "How Do Committees Invent?" con una frase que sigue vigente: "Any organization that designs a system will produce a design whose structure is a copy of the organization's communication structure."
La documentación de Microsoft sobre arquitectura de microservicios lo resume en los mismos términos: la ley de Conway "indica que una aplicación reflejará los límites sociales de la organización que lo produjo". Y agrega un matiz que suele pasarse por alto: a veces ocurre lo contrario, y es la organización la que termina formada por el software.
En el caso del tren japonés, la ley se ve directamente en la pantalla. El usuario quiere un ticket de A a B; el sistema le pregunta qué compañía ferroviaria opera esa ruta. La estructura organizacional —seis empresas con plataformas separadas— se convirtió en un campo más del formulario.
¿Es un problema de diseño o una diferencia cultural?
Vale la pena resistir la conclusión fácil de que "las interfaces japonesas son malas". El propio autor del artículo original propone otra lectura: preferencia por lo conocido antes que por lo nuevo, evitar errores, preferencia por la certeza, atención al detalle y resistencia al cambio. Bajo esa lógica, la estética de los 90 de Yahoo Japan o la densidad de información de Rakuten no son descuidos: son decisiones que priorizan familiaridad y previsibilidad.
El problema aparece cuando esas preferencias chocan con un usuario externo —un turista, un cliente nuevo, un comprador internacional— que no comparte el contexto. Ahí la fricción deja de ser cultural y se convierte en un costo de conversión.
¿Qué significa esto para tu startup?
Tu producto probablemente no tiene seis compañías regionales, pero sí tiene equipos. Y cada límite entre equipos es un lugar donde puede aparecer una fricción innecesaria para el usuario.
Tres señales de que tu organigrama se está filtrando a la interfaz:
- El usuario tiene que elegir algo que no le importa. Si tu checkout pregunta por la unidad de negocio, la sucursal o el tipo de contrato cuando el cliente solo quiere pagar, ese campo existe por una razón interna, no por una razón de usuario.
- Dos equipos, dos flujos. Cuando una misma persona debe crear dos cuentas, subir el mismo documento dos veces o repetir datos entre productos de la misma empresa, el problema no es visual: es que nadie es dueño del recorrido completo.
- Reglas que solo entiende quien las escribió. El mensaje de la tarjeta física es el ejemplo perfecto: una condición operativa real, comunicada en el peor momento posible, después de pagar.
Dos acciones concretas para esta semana:
- Mapea tu flujo crítico contra tu organigrama. Toma el recorrido de mayor valor (registro, compra, activación) y anota qué equipo es dueño de cada paso. Cada vez que el usuario tenga que saltar de un equipo a otro, tienes un candidato a rediseño.
- Mueve las restricciones operativas al inicio, no al final. Si hay una condición que puede invalidar la compra —verificación de identidad, método de pago aceptado, documentación requerida—, muéstrala antes de que el usuario pague. Una penalidad de ¥560 por persona es barata comparada con un cliente que no vuelve.
¿Cómo se corrige la Ley de Conway?
No se corrige ignorándola. La estrategia conocida es la Maniobra Inversa de Conway: en lugar de dejar que la estructura de los equipos dicte el diseño del software, se reorganizan los equipos para que coincidan con la arquitectura que quieres ofrecer.
Un análisis del blog CTO Fraccional sobre estructura de equipos y delivery de producto lo ilustra con un caso típico: si contratas cuatro equipos separados de frontend y backend más un administrador de base de datos centralizado, la arquitectura resultante tenderá a capas separadas y a una base de datos compartida. Si tu objetivo era que cada equipo fuera dueño de sus propios datos, esa estructura juega en contra.
El mismo análisis advierte algo relevante para startups en etapa temprana: no conviene arrancar con microservicios. Lo recomendable es un monolito modular —un solo despliegue con límites internos claros— para entender primero qué partes del negocio pertenecen juntas. Los límites entre módulos se convierten después en puntos de extracción naturales.
Para una startup hispanohablante con equipo chico, la lectura práctica es simple: la arquitectura y la organización son la misma decisión tomada dos veces. Si quieres que el usuario vea un solo producto, alguien tiene que ser dueño de la experiencia completa.
Conclusión
Japón construyó trenes extraordinarios y, al mismo tiempo, un sistema de reservas que obliga al pasajero a entender cómo está organizada la compañía ferroviaria. La infraestructura es de primer nivel; la capa que la conecta con el usuario, no.
Esa brecha es exactamente la que la Ley de Conway predice. Y es la razón por la que, en tu startup, revisar el organigrama es también una tarea de producto.
Fuentes
- Japan's trains are great. Why is booking one so hard? (fuente original)
- Identificación de los límites del modelo de dominio para cada microservicio - Microsoft Learn
- Estructura de equipos: comunicación y delivery de producto - CTO Fraccional
¿Y esto cómo se aplica en tu negocio?
Dueños de negocio de Latinoamérica y España usan un agente de IA para ganar más y recuperar su tiempo. El Kit «tu mano derecha con IA» te muestra cómo en un video de 11 minutos, con una ficha para armar el tuyo. CAR está cerrada por ahora; al anotarte, te avisamos cuando abra.
👥 Quiero el Kit →
