--- title: "Software que depende de una sola persona" description: "Qué hacer si tu software depende de una sola persona: riesgos, primeros treinta días, documentación mínima y cómo se traspasa sin parar la empresa." canonical: https://caricalia.com/notas/software-depende-de-una-persona last-updated: 2026-09-29 --- # Software que depende de una sola persona > Cuando una sola persona sabe tocar el sistema, el riesgo no se resuelve cambiando de persona. Se resuelve sacando el conocimiento de su cabeza, en treinta días y sin parar nada. Publicado: 2026-09-29 Autor: carlos Temas: legacy, dependencia, traspaso --- ## Qué hacer si tu software depende de una sola persona Si tu software depende de una sola persona, el riesgo no se arregla sustituyéndola sino sacando lo que sabe de su cabeza. Consigue los accesos a nombre de la empresa, escribe lo mínimo que solo ella sabe y comprueba que otra persona puede hacer un cambio real con solo el repositorio. En treinta días se puede dejar de depender de su memoria, con ella dentro y sin parar nada. Esta es una de las situaciones que más veces encontramos en los sistemas en producción de [software a medida](/software-a-medida): funciona, nadie se queja, y el día que esa persona no está, nadie sabe qué pasaría. Aquí va qué mirar, qué hacer cada semana y cómo se traspasa, sin promesas de que salga en un día. ## Por qué es un riesgo aunque hoy todo funcione Un sistema que solo una persona sabe tocar es un activo que se puede perder sin avisar. No hace falta que la persona se enfade: se pone enferma, la contrata otra empresa, se jubila, o simplemente deja de contestar los fines de semana. Lo que cambia entonces no es el código, sino que nadie puede leerlo con criterio. | Riesgo | Cómo se ve desde dentro | Qué cuesta | |---|---|---| | Se va o falta | Nadie sabe cómo se despliega un cambio ni dónde están las claves | Semanas parado o cambios a ciegas | | Accesos a su nombre | El repositorio, el servidor o el dominio están en su cuenta personal | No puedes ni pedir presupuesto a otro | | Conocimiento oral | Las reglas raras del negocio están en su cabeza, no en el código | Cada cambio empieza por averiguar por qué está así | | Poder de negociación | Cada petición depende de su disponibilidad y de su tarifa | El precio deja de negociarse | | Revisión externa | Un cliente grande o un inversor pregunta quién más puede tocarlo | La respuesta honesta baja el valor de la operación | El último punto es el que suele poner fecha. Cuando alguien de fuera va a mirar por dentro, «depende de una persona» es lo primero que pregunta, y está en la lista de lo que mira una [auditoría técnica antes de una inversión](/notas/auditoria-tecnica-antes-de-una-inversion). ## Cómo saber si te pasa a ti Contesta estas cinco preguntas sin consultarlo con nadie. Si dos respuestas son «solo ella», tu sistema depende de una persona. - ¿Quién puede desplegar un cambio en producción? - ¿Quién sabe dónde están las claves y los accesos, y a nombre de quién están? - ¿Quién entiende la parte por la que pasa el dinero? - ¿Qué pasaría si mañana no contestara el teléfono durante un mes? - ¿Hay algo escrito que explique por qué el sistema está hecho así? ## De quién es el código que escribió Antes de nada, comprueba de quién es lo que se ha construido. Depende de cómo trabaje esa persona. Si es una empleada y creó el programa en el ejercicio de sus funciones o siguiendo las instrucciones de la empresa, la titularidad de los derechos de explotación corresponde a la empresa, salvo pacto en contrario. Lo dice el [artículo 97.4 de la Ley de Propiedad Intelectual](https://www.boe.es/buscar/act.php?id=BOE-A-1996-8930). Si es una autónoma o trabaja a través de una agencia, no funciona igual. Los derechos de explotación solo pasan a quien encarga el trabajo si hay una cesión por escrito, y esa cesión se limita a lo pactado: a las modalidades de explotación, al tiempo y al ámbito. Si el contrato no dice el plazo, la cesión se limita a cinco años (artículos 43 y 45 de la misma ley). En ese caso, lo primero es revisar el contrato. La nota sobre [cambiar de proveedor de software sin perder el sistema](/notas/cambiar-de-proveedor-de-software) lo cuenta con lo que hay que pedir. ## Los primeros treinta días, semana a semana El orden importa. Se empieza por lo que puede perderse ya, los accesos, y se termina con la prueba que demuestra que el riesgo ha bajado. | Semana | Qué se hace | Cómo sabes que está hecho | |---|---|---| | Primera | Se pasan a nombre de la empresa el repositorio, los entornos, el dominio, las cuentas de servicios y las claves. Se anota quién tiene acceso a qué | Una persona de la empresa, que no es la que programa, puede entrar en cada cuenta y ver quién más tiene acceso | | Segunda | Se hace el inventario: qué servicios externos usa el sistema, qué cuesta cada uno, cuándo caducan certificados y contratos | Existe una lista con titular, coste y fecha de renovación de cada pieza | | Tercera | Se escribe la documentación mínima (la lista de abajo), preguntando a la persona y anotando lo que dice | Alguien que no programa puede leerla y entender cómo está montado el sistema | | Cuarta | Se hace la prueba de relevo: una persona que no ha visto el proyecto hace un cambio real, con el repositorio y esa documentación | El cambio llega a producción sin preguntar nada a la persona de siempre | Si la prueba de la cuarta semana falla, no es un fracaso: dice qué falta en la documentación. Se escribe eso y se repite. ## La documentación mínima No hace falta un manual. Hace falta lo que permite a un extraño hacer un cambio concreto sin romper nada. Seis piezas cortas: 1. **Cómo está montado.** Una página con las partes del sistema, dónde vive cada una y qué habla con qué. 2. **Cómo se despliega.** Los pasos exactos para llevar un cambio a producción y cómo se vuelve atrás si sale mal. 3. **Dónde están los accesos.** La lista de cuentas y claves, guardadas en un gestor de contraseñas de la empresa, nunca en un documento suelto. 4. **Las decisiones que explican el sistema.** Tres o cuatro decisiones con su fecha, lo que se eligió y lo que se descartó. 5. **Las reglas de negocio raras.** Las que existen porque un cliente concreto lo pidió, o porque la ley lo exige. Mejor si están convertidas en pruebas que se ejecutan solas. 6. **Quién responde de qué.** Contratos, proveedores y a quién se llama cuando falla cada pieza. Esto es lo mismo que pide un auditor y lo mismo que necesita quien herede el sistema. Cómo se comporta el sistema cuando el proveedor no está está contado en [un sistema legacy es código sin dueño](/notas/sistema-legacy-codigo-sin-dueno). ## Cómo se traspasa sin parar la empresa El traspaso se hace con la persona dentro, no contra ella. Quien sabe cómo funciona el sistema es quien más rápido puede dejarlo escrito. La forma que mejor funciona es invertir los papeles: la persona nueva hace el cambio y la de siempre mira. Cada vez que la nueva se atasca, se anota lo que faltaba y se añade a la documentación. Al cabo de unos cambios, lo que falta ya casi no aparece. Conviene cerrar el traspaso con una condición concreta, no con una sensación: una persona que no ha visto el proyecto hace un cambio real que elige la empresa, con el repositorio y nada más, y sabe por las pruebas si ha roto algo. Es la condición de entrega que ponemos en nuestros propios proyectos. Mientras tanto, el trabajo del día a día sigue con quien lo llevaba. Nadie necesita parar la empresa para que otra persona aprenda, pero sí acordar cuánto tiempo de la persona de siempre se dedica a explicar. ## Cómo hablar con la persona de la que dependes La conversación es la parte que más se pospone, y es la que decide si el plan funciona. La persona que lleva el sistema no es el problema: el problema es que todo esté en su cabeza, y eso casi nunca lo ha decidido ella. Suele ser el resultado de años de resolver urgencias sin que nadie pidiera dejarlo escrito. Plantéalo como lo que es, una mejora que la protege también a ella. Con el sistema documentado, puede coger vacaciones sin que la llamen, enfermar sin que la empresa se pare y cambiar de proyecto sin que su salida sea un problema. Dile qué necesitas (accesos a nombre de la empresa, una lista de cuentas, unas horas a la semana para explicar), en qué plazo y cómo sabrás que está hecho. Dos cuidados. Reserva tiempo real en su agenda: si la documentación se hace «cuando haya un hueco», no se hace. Y no ligues el traspaso a una amenaza, porque quien se siente reemplazada deja de contar lo que sabe, y lo que sabe es justo lo que necesitas. Si la dependencia es de una agencia o de un autónomo con contrato mercantil, la conversación es distinta y empieza por el contrato. Está tratada en [cambiar de proveedor de software sin perder el sistema](/notas/cambiar-de-proveedor-de-software). ## Cómo se ve un sistema que ya no depende de una persona Cuatro señales que puedes comprobar sin ser programador: - Hay al menos dos personas que pueden desplegar un cambio, y las dos lo han hecho este trimestre. - Los accesos están en un gestor de contraseñas de la empresa, y cuando alguien se va, se retiran el mismo día. - Existe una página que explica cómo está montado el sistema, y alguien que no lo escribió ha dicho que se entiende. - Cuando algo falla, hay un aviso automático. No hace falta que llame un cliente. No son un lujo de empresas grandes. Son lo que pide cualquier revisión externa, y lo que evita que una baja de una semana se convierta en una crisis. ## Qué no hacer - **No lo resuelvas reescribiéndolo.** Un sistema nuevo escrito por otra persona tiene el mismo problema, y mientras tanto el viejo sigue recibiendo cambios. Cuándo sí compensa está en [reescribir o refactorizar](/notas/reescribir-o-refactorizar). - **No contrates a otra persona sola y con eso des el tema por cerrado.** Pasas de depender de una a depender de dos, con el mismo conocimiento oral. - **No pidas los accesos a escondidas.** Es una conversación con la persona, con un motivo claro: que la empresa no dependa de nadie, ni de ella. - **No esperes a que haya una fecha externa.** Preparar esto con dos semanas de aviso, antes de una ronda o una auditoría, sale mal. ## Cuándo pedir ayuda de fuera Si la persona ya se ha ido, si no colabora o si el sistema es tan grande que treinta días no alcanzan, hace falta que alguien de fuera lea el código y te diga qué hay. Es lo que hace un [diagnóstico](/diagnostico): tres semanas leyendo el sistema y hablando con quien lo usa, y un informe con qué se rompe primero, qué cuesta arreglarlo y en qué orden. Cuesta 2.900 € + IVA, y si sale pequeño, lo decimos y no hay proyecto. ## Preguntas frecuentes ### ¿Qué hago si el programador se ha ido y nadie entiende el código? Consigue primero los accesos: repositorio, entornos, dominio y cuentas. Sin eso nadie puede trabajar. Después necesitas a alguien que lea el sistema por donde duele el negocio y reproduzca los fallos fuera de producción. Ese es el trabajo de la primera semana de un diagnóstico. ### ¿Cuánto se tarda en dejar de depender de una persona? Con la persona colaborando y un sistema de tamaño normal, cuatro semanas bastan para tener accesos, inventario, documentación mínima y una prueba de relevo. Si el sistema es grande o la persona ya no está, se tarda más y conviene un diagnóstico para saber cuánto. ### ¿Hace falta reescribir el software si solo una persona lo entiende? Casi nunca. El problema es que el conocimiento no está escrito, no que el código sea malo. Reescribir tiene sentido cuando lo que el negocio necesita ya no se parece a lo que el sistema hace. ### ¿De quién es el código que escribió un empleado o un autónomo? Si es un empleado y lo creó en el ejercicio de sus funciones, es de la empresa salvo pacto en contrario (artículo 97.4 de la Ley de Propiedad Intelectual). Si es un autónomo o una agencia, solo pasa a la empresa con una cesión escrita, que se limita a lo pactado. ### ¿Se puede documentar un sistema sin parar la empresa? Sí. Se hace en paralelo al trabajo diario y con la persona que lo conoce. Lo que no se puede es hacerlo sin dedicarle tiempo: hay que acordar cuántas horas a la semana de esa persona se dedican a explicar. Si tu sistema encaja en lo que has leído y quieres saber cuánto cuesta arreglarlo, [pide un diagnóstico](/diagnostico).