Cuando termina una construccion

Checklist de traspaso de software: que deberias recibir cuando termina una construccion

Un traspaso limpio significa que puedes operar, cambiar y entregar el software a cualquiera, sin llamar al constructor original. Eso requiere el codigo y todo su historial, documentacion, tests, un CI/CD funcionando, tus propios secretos y credenciales, y acceso de administrador a cada pieza de la infraestructura. Si algo de eso se queda con el proveedor, no eres dueno de tu software, lo alquilas. Usa el checklist de abajo para confirmar que de verdad lo tienes todo antes de dar la construccion por terminada.

Reservar una call de treinta minutos

Respuesta corta

Un traspaso limpio te da el codigo, el historial, la documentacion, los tests, el CI/CD, los secretos y acceso completo a la infraestructura, para que cualquier equipo competente pueda asumirlo sin el constructor original.

Ideal para

  • Fundadores que terminan un encargo con una agencia o un freelance
  • Equipos que llevan un proyecto a interno
  • Compradores que quieren evitar la dependencia de un proveedor
  • Cualquiera que se prepare para una due diligence o una auditoria
  • Productos que deben sobrevivir a su primer equipo de construccion

No es para

  • Prototipos desechables que nunca piensas mantener
  • Construcciones donde a proposito has retenido al mismo proveedor de por vida
  • Scripts internos sin huella en produccion
  • Trabajo que aun no ha llegado a un estado entregable
// 01

Compara las opciones

Como distinguir un traspaso limpio de una trampa de dependencia.

Dimension Traspaso limpio Senales de dependencia del proveedor
Propiedad del codigo

Repos en tu organizacion, con todo el historial de git.

El codigo vive en la cuenta del proveedor, o un zip sin historial.

Credenciales

Todos los secretos y cuentas son tuyos y estan rotados.

Las claves y los accesos se quedan con el proveedor.

Infraestructura

Tienes acceso de administrador en hosting, DNS y observabilidad.

El proveedor es el unico administrador en produccion.

Documentacion

Arquitectura, configuracion y runbooks estan por escrito.

El conocimiento vive en la cabeza del desarrollador original.

Tests y CI/CD

Tests automatizados y un pipeline que puedes ejecutar tu mismo.

Sin tests, o despliegues que solo el proveedor puede disparar.

Dependencia

Cualquier equipo competente puede asumirlo.

Solo el constructor original puede cambiar algo.

// 02

La postura de Wavect

Deberias poder despedirnos y mantener tu software funcionando. Si no puedes, el traspaso no fue limpio.

Traspasamos el codigo en tus propios repositorios con todo el historial, la documentacion y los runbooks para operarlo, los tests y el pipeline para entregarlo, y acceso de administrador a cada cuenta y servidor en el que corre. Los secretos son tuyos y estan rotados, no nuestros.

Cero dependencia del proveedor es lo predeterminado, no un extra premium. El objetivo de un traspaso es que cualquier equipo competente, incluido el tuyo, pueda llevar el trabajo adelante sin nosotros. Eso es lo que significa de verdad ser dueno de tu software.

// 03

Coste, riesgo y plazos

Coste Parte de la construccionUn traspaso limpio esta incluido, no es un extra al final.
Riesgo Dependencia si se omiteUn elemento que falte te deja dependiente del constructor original.
Plazo Verificado en la entregaPasa el checklist antes de dar el visto bueno, no semanas despues.
// 04

Dónde suele salir mal

  • Recibir un zip de codigo sin historial de git, asi que pierdes el porque de cada decision.
  • Descubrir que los secretos y las cuentas de produccion aun pertenecen al proveedor.
  • Encontrar que el proveedor es el unico administrador en hosting, DNS o la base de datos.
  • Heredar una base de codigo sin tests y sin un pipeline ejecutable.
  • Depender de conocimiento que vive solo en la cabeza del desarrollador original.
  • Dar la construccion por terminada antes de que nadie verifique los elementos del traspaso.
// 05

La lista de verificación

Confirma cada uno de estos antes de aceptar el traspaso.

  • Codigo fuente en repositorios de los que eres dueno, con todo el historial de git intacto.
  • Documentacion escrita: resumen de arquitectura, configuracion local y pasos de despliegue.
  • Una suite de tests automatizados que puedes ejecutar, con los resultados actuales documentados.
  • Un pipeline de CI/CD funcionando que puedes disparar tu mismo, no solo el proveedor.
  • Todos los secretos y credenciales transferidos a ti y rotados fuera de las cuentas del proveedor.
  • Acceso de administrador a cada pieza de la infraestructura: hosting, DNS, base de datos y observabilidad.
  • Runbooks para las operaciones habituales: desplegar, revertir, restaurar y responder a incidentes.
  • Confirmacion de cero dependencia del proveedor, para que cualquier equipo competente pueda asumirlo sin el constructor original.
// 06

Cómo se ve esto en nuestro trabajo

Construcciones entregadas a produccion y en propiedad del cliente.

// 07

Cuándo encaja, y cuándo no

// 01

Cuando Wavect es el encaje adecuado

  • Quieres ser dueno de tu software por completo, no alquilarlo a un proveedor.
  • Puede que lleves el proyecto a interno o a otro equipo mas adelante.
  • Esperas documentacion, tests y acceso como algo predeterminado.
  • Quieres un constructor que planifique el traspaso desde el dia uno.
// 02

Cuando no somos el encaje

  • Quieres un proveedor del que nunca puedas irte.
  • Ves la documentacion y los tests como extras opcionales.
  • Estas construyendo un prototipo desechable sin futuro.
  • No vas a asumir la propiedad de tus propias credenciales e infraestructura.

Si no puedes operar tu software sin las personas que lo construyeron, aun no eres su dueno.

// 08
// 09

Preguntas frecuentes

El codigo en repositorios de los que eres dueno, con todo el historial de git. El historial lleva el razonamiento detras de cada cambio, y un archivo zip sin el lo tira a la basura. Todo lo demas se construye sobre eso.
Si los secretos y las cuentas de produccion se quedan con el proveedor, ellos controlan si tu software sigue funcionando. Las credenciales deberian transferirse a ti y rotarse para que nada dependa de los accesos del constructor original.
Cualquier cosa que signifique que solo el constructor original puede cambiar, desplegar u operar el software. Codigo en su cuenta, sistemas sin documentar o acceso de administrador que no quieren entregar son todo dependencia.
Si. Sin una suite de tests automatizados y un pipeline que puedas ejecutar tu mismo, cada cambio futuro es arriesgado y lento. Son lo que permite a un equipo nuevo moverse con seguridad despues de que asumas el control.
Antes de dar el visto bueno a la construccion, no semanas despues. Pasa el checklist mientras el equipo original sigue implicado, para que cualquier hueco pueda cerrarse de inmediato.
No. Cero dependencia del proveedor es lo predeterminado. Los elementos del traspaso son parte de la construccion, no un extra al final.
Última revisión: porKevin Riedl wiki ↗
Reservar una call de treinta minutos