La Pregunta Que Nadie Quiere Responder
Todo equipo de software conoce el bus factor. Pocos lo toman en serio.
El bus factor mide cuantas personas necesitan ser atropelladas por un autobus antes de que un proyecto se detenga. Para la mayoria de las startups, es uno. Para la mayoria de los equipos empresariales, son dos o tres. Todos coinciden en que esto es un problema. Nadie hace nada al respecto.
No podiamos darnos ese lujo.
Nuestro software — De Novo xGrid — funciona en dispositivos Raspberry Pi en zonas de desastre. Hospitales de campana. Refugios comunitarios despues de terremotos. Lugares donde "llamar al proveedor" no es una opcion porque no hay senal telefonica, no hay internet y posiblemente ya no hay proveedor.
Asi que formulamos una version mas dificil de la pregunta del bus factor:
Si todo el equipo de desarrollo desaparece manana, pueden los sistemas desplegados seguir funcionando indefinidamente?
No "por unos dias hasta que contratemos reemplazos". Indefinidamente.
Cinco Pruebas, Sin Excepciones
Formalizamos esto en el Walkaway Test — cinco criterios de aceptacion que cada lanzamiento debe cumplir. El nombre es deliberado: no "prueba de recuperacion ante desastres" ni "revision del plan de continuidad", sino walkaway (abandono). Como en: los desarrolladores se van, y el sistema sigue funcionando.
WK01: Sin conexion por defecto. El sistema debe operar con cero conectividad de red. No "degradacion elegante" — operacion completa. Cada una de nuestras mas de 15 aplicaciones web progresivas funciona sin conexion. Registro de pacientes, dispensacion de medicamentos, gestion de banco de sangre, programacion quirurgica. Todo. La red es un bonus, no un requisito.
WK02: Recuperacion del Hub desde el Edge. Si el Raspberry Pi central es destruido fisicamente, cualquier telefono o tableta sobreviviente debe poder reconstruirlo. Lo llamamos el Protocolo Bote Salvavidas (Lifeboat Protocol). Una enfermera escanea dos codigos QR desde su telefono a un Raspberry Pi nuevo de 80 dolares. Los datos fluyen de regreso. La estrella de mar regenera su brazo. Lo validamos en una prueba de 12 pasos el 26 de enero de 2026. Tasa de aprobacion: 100%.
WK03: Cero Dependencia de TI. Si un sistema requiere acceso SSH, intervenciones por linea de comandos o analisis de logs para funcionar, falla esta prueba. Nuestros operadores son enfermeras y personal de logistica, no ingenieros. Toda operacion ocurre a traves de la interfaz del navegador.
WK04: Sin Bloqueo de Licencia. Sin verificacion remota. Sin validacion de suscripcion. Sin fecha de expiracion. Una vez desplegado, el software pertenece al equipo de campo. Si nuestra empresa desaparece, al software no le importa.
WK05: Datos Auditables por Humanos. Si ya no confia en el software, aun puede verificar los datos. Las bases de datos se abren en cualquier herramienta. Cada registro tiene marcas de tiempo e identificadores de operador. No necesita nuestro software para leer sus propios datos.
Lo Que "Bus Factor Tendiendo a Infinito" Realmente Significa
El 27 de enero de 2026, despues de pasar las cinco pruebas, escribimos una linea en nuestro registro interno:
Bus factor approaching infinity.
Esto suena a bravuconeria. No lo es. Es una declaracion de ingenieria precisa.
El bus factor tradicional cuenta personas. Si tres personas se van y el proyecto muere, su bus factor es tres. Nuestra version cuenta dependencias de la organizacion misma. Despues de WK01-WK05, el sistema desplegado tiene cero dependencias de De Novo Orthopedics — sin servidores, sin licencias, sin credenciales, sin mantenimiento continuo. El bus factor no se trata de cuantas personas pueden irse. Se trata de si toda la empresa puede irse.
La respuesta es si.
La Filosofia de Diseno Incomoda
La mayoria de los negocios de software se construyen sobre la dependencia. Los ingresos recurrentes dependen de que los clientes lo necesiten el proximo mes. El alojamiento en la nube significa que el proveedor tiene las llaves. Los servidores de licencias aseguran el cumplimiento — y aseguran que usted no pueda irse.
El Walkaway Test invierte esto. Cada decision de diseno se evalua a traves de una lente: esto hace al usuario mas o menos dependiente de nosotros?
Esto suena como mal negocio. En realidad es el unico enfoque honesto cuando sus usuarios estan operando un hospital de campana en una zona de desastre. "Nos necesitan pero no pueden contactarnos" es funcionalmente identico a "no tienen el software". Una dependencia que no puede satisfacerse es peor que ninguna dependencia. Al menos sin el software, las personas saben usar papel.
Tres Preguntas para Sus Propios Sistemas
No necesita construir software de medicina de desastres para beneficiarse del pensamiento walkaway. Comience aqui:
-
Cuanto tiempo funciona su sistema sin red? Si la respuesta es cero, cada interrupcion de red es una interrupcion total. Esa es una decision que usted esta tomando.
-
Donde viven sus datos, y quien puede acceder a ellos? Si la respuesta es "una cuenta en la nube controlada por una persona", ha centralizado su riesgo exactamente de la manera que la nube supuestamente debia prevenir.
-
Pueden sus usuarios exportar todo sin su ayuda? Si no, usted no esta vendiendo un producto. Esta vendiendo acceso a un producto. Esas son cosas diferentes con implicaciones eticas diferentes.
El Walkaway Test no es una metodologia de pruebas. Es una filosofia de diseno que pregunta: que construiria usted si asumiera que no va a estar disponible para mantenerlo?
La respuesta, resulta ser, es mejor software.
Relacionado: Cuando el Muro Cae — Diseno de Sistemas Medicos con Safety-II