La mayoría de las guías tratan de cómo elegir un socio de software. Pocas tratan de cómo dejarlo, aunque a menudo esa es la decisión más difícil. Hay un sistema ya en producción, hay personas que dependen de él cada día y el único equipo que lo entiende por completo es precisamente aquel del que usted ya no está seguro. Heredamos proyectos así con regularidad, y los que salen bien tienen algo en común: el cliente planificó la salida antes de anunciarla.
Señales de que ha llegado el momento de cambiar de socio
Todo encargo tiene un mes malo. Lo que importa es si los problemas se explican y se resuelven, o simplemente se repiten. Estos son los patrones que, a lo largo de dos o tres trimestres, suelen indicar que la relación no se va a recuperar:
Fechas incumplidas sin motivo. Un retraso con una causa clara y un plan nuevo es normal. Los retrasos que llegan por sorpresa, sin que cambie nada en cómo se gestiona el trabajo, son un problema de gestión que el proveedor no está resolviendo.
Solo el proveedor sabe desplegar. Si publicar un cambio exige a una persona concreta del proveedor, usted no es del todo dueño de su sistema - y cuanto más dure esa situación, más caro será marcharse.
Cada cambio cuesta más que el anterior. Las estimaciones crecientes para trabajos parecidos son la señal más clara de una base de código cada vez más difícil de modificar, y de un equipo que no está amortizando esa deuda.
El equipo no deja de rotar. Caras nuevas cada trimestre y ninguna documentación significan que el conocimiento se va con cada persona. Pregunte quién sigue trabajando en su proyecto desde el primer mes.
Si se cumplen dos o más, aplique a su proveedor actual la lista de comprobación para elegir un socio de desarrollo de software como si lo conociera por primera vez. A veces una conversación honesta y una organización distinta lo arreglan. A menudo confirma lo que usted ya sospechaba.
Qué asegurar antes de decírselo a nadie
El orden importa más que el nuevo proveedor. Antes de anunciar el cambio - incluso antes de hablar en serio con un sustituto -, asegúrese de que su empresa tiene lo siguiente, a su propio nombre:
- Acceso de administrador a todos los repositorios de código, incluidos los que solo usa el CI del proveedor
- La titularidad de las cuentas en la nube, los dominios, el DNS y las fichas en las tiendas de apps - a nombre de su empresa
- Todos los secretos y credenciales: claves de API, contraseñas de bases de datos, certificados de firma, accesos a servicios de terceros
- Copias de seguridad de la base de datos que usted mismo haya restaurado al menos una vez
- Toda la documentación que exista - notas de arquitectura, runbooks, pasos de despliegue -, por escasa que sea
- Una lista de todos los servicios de terceros de los que depende el sistema, y de quién los paga
Casi todo esto ya debería ser suyo según su contrato. Revise las cláusulas de propiedad intelectual, obligaciones de traspaso y plazos de preaviso, y mantenga un tono profesional: va a necesitar la colaboración del equipo saliente durante semanas después de la decisión.
El momento más barato para asegurar el acceso a su propio sistema es antes de que nadie sepa que se marcha.
Un plan de traspaso por etapas
La forma más arriesgada de cambiar de socio es una única fecha de corte. Un traspaso por etapas mantiene el sistema en marcha y da al nuevo equipo tiempo para aprenderlo mientras el antiguo todavía puede responder preguntas.
Semanas 1-2: observación. El nuevo equipo lee el código, monta sus propios entornos y observa cómo el equipo saliente despliega y gestiona incidencias. El objetivo es un mapa escrito del sistema: componentes, flujos de datos, integraciones y las partes que nadie entiende.
Semanas 3-4: cambios supervisados. El nuevo equipo hace cambios pequeños y reales y los despliega, con el equipo antiguo revisando. Es aquí donde afloran la documentación que falta y los pasos de compilación frágiles - mejor ahora que durante una caída.
Semanas 5-8: traspaso por áreas. La responsabilidad pasa de área en área - primero las partes con mejor cobertura de pruebas, al final las de más riesgo. El proveedor saliente sigue localizable, a ser posible con una pequeña iguala, hasta que se haya traspasado la última área.
Resista la tentación de reescribir en cuanto llegue el nuevo equipo. Un socio nuevo que propone reconstruirlo todo antes de entender el sistema está repitiendo el error del que usted intenta escapar. Primero estabilice, después mejore de módulo en módulo - el enfoque que describimos en modernización de sistemas heredados sin la gran reescritura.
Cómo elegir al siguiente socio
La segunda elección debería ser más exigente que la primera. Pregunte al candidato cómo se ha hecho cargo de sistemas antes y pídale un plan de traspaso anonimizado de un proyecto real. Acuerde una facturación por hitos en lugar de un contrato por horas sin límite, y haga de la documentación un entregable, no un favor. Sobre todo, compruebe que dejar al nuevo socio sería fácil - porque la mejor protección para no tener que volver a leer este artículo es una relación a la que podría poner fin con poco coste.
Preguntas frecuentes
¿Cuándo debería cambiar de socio de desarrollo de software?
Cuando los problemas dejan de explicarse y empiezan a repetirse: fechas incumplidas sin motivo, un sistema que solo el proveedor sabe desplegar, un coste por cambio que no deja de subir y una rotación constante del equipo. Un mes malo es normal; un patrón a lo largo de dos o tres trimestres es una señal.
¿Cómo se cambia de proveedor de software sin perder el proyecto?
Asegure el código, la infraestructura, las credenciales y las copias de seguridad antes de anunciar el cambio, y después haga el traspaso por etapas: el nuevo equipo observa, luego despliega bajo supervisión y por último asume un área cada vez mientras el proveedor saliente sigue localizable.
¿Cuánto dura el traspaso de un software?
Para un sistema de negocio típico, de cuatro a ocho semanas de solapamiento entre el equipo saliente y el nuevo. Los sistemas sin documentación o sin pruebas tardan más, porque el nuevo equipo primero tiene que reconstruir ese conocimiento.
¿Hay que reescribir el software al cambiar de socio?
Casi nunca como primer paso. Un socio nuevo debería estabilizar y entender el sistema antes de proponer cambios. Sustituya partes solo cuando haya un motivo claro, de módulo en módulo.