En esta nota (17 secciones)
El día que te entregan un desarrollo, la conversación suele ser sobre si funciona. Es la pregunta correcta y es insuficiente.
Un sistema puede funcionar perfecto y dejarte igual de atado a un proveedor que si no lo tuvieras. La diferencia entre comprar un activo y alquilar una dependencia se define en cosas que se piden en la entrega, y que después son incómodas o imposibles de conseguir.
Esta es la lista.
1. El código, en un repositorio tuyo
No un ZIP por mail. Un repositorio —GitHub, GitLab, el que sea— a nombre de tu empresa, donde vos sos el dueño de la organización y el proveedor es un colaborador al que podés dar de baja.
Esto tiene que estar así desde el primer commit, no al final. Si te lo entregan recién en la entrega, perdiste todo el historial, que es la mitad del valor: sin él, nadie puede entender por qué las cosas se hicieron como se hicieron.
Verificá: entrá al repositorio con tu usuario y confirmá que podés administrar los permisos.
2. Las cuentas de infraestructura a tu nombre
Servidor, base de datos, dominio, certificados, almacenamiento, servicios de terceros, cuentas de las tiendas si hay app.
Todo con tu mail corporativo y tu tarjeta. El proveedor debe tener acceso, no titularidad.
Esta es la que más cuesta arreglar después y la que más gente descubre tarde, casi siempre en el peor momento: cuando quiere cambiar de proveedor, o cuando el proveedor desaparece.
Verificá: entrá a cada panel con tu usuario. Si tenés que pedirle la clave a alguien, no es tuyo.
3. Las credenciales, entregadas y rotadas
La lista completa de usuarios, claves y tokens, entregada por un canal seguro. Y después de la entrega, rotalas: las claves que conoce un proveedor con el que terminaste la relación no son tus claves.
4. Cómo se levanta el proyecto de cero
Un documento corto que explique cómo hacer funcionar el sistema en una máquina nueva: qué hay que instalar, qué variables configurar, cómo se corre.
Esta es la prueba de fuego de si otro equipo puede tomar el proyecto. Pedí que lo pruebe alguien que no lo escribió. Si no puede levantarlo siguiendo el documento, el documento no sirve.
5. Cómo se despliega
Cómo pasa un cambio de la computadora del desarrollador a producción. Idealmente automatizado, y en cualquier caso escrito.
Si el despliegue es "Juan se conecta al servidor y copia archivos", el sistema depende de Juan.
6. Los backups, probados
No alcanza con que existan. Preguntá tres cosas:
- Con qué frecuencia se hacen y cuánto se retienen.
- Dónde están, y si están en una cuenta tuya.
- Cuándo se probó una restauración, y cuánto tardó.
La tercera es la que importa. Un backup que nunca se restauró es una suposición, no un respaldo. Pedí que hagan una restauración de prueba delante tuyo.
7. El detalle de la garantía
Por escrito: cuánto dura, qué entra y qué no.
La distinción que evita todas las discusiones: un botón que no guarda es un error y entra. Un reporte que ordena por fecha cuando lo querías por cliente, si el pedido decía fecha, es un cambio y no entra.
También: en qué horario se atiende y en cuánto tiempo se responde.
8. Qué pasa después de la garantía
Cuál es el esquema de mantenimiento, qué cuesta, y —la pregunta incómoda— qué pasa si querés que lo mantenga otro.
La respuesta a esa última te dice mucho sobre con quién trabajaste. Un proveedor que dejó todo lo de esta lista en orden puede contestarla sin problema.
9. Las dependencias y sus versiones
Qué librerías y servicios de terceros usa el sistema, en qué versión, y hasta cuándo tienen soporte.
Es lo que te permite saber si el sistema nace con deuda: un desarrollo hecho sobre tecnología que ya estaba de salida cuando se construyó va a necesitar una actualización grande mucho antes de lo que esperás.
10. La capacitación, grabada
Que las sesiones de capacitación queden grabadas. Cuesta cero y resuelve el problema de la persona que entra a la empresa seis meses después.
Las tres pruebas que conviene hacer vos
Antes de firmar la conformidad:
- Levantá el proyecto siguiendo el documento, con alguien ajeno al desarrollo. Si no se puede, no está terminado.
- Restaurá un backup en un ambiente aparte y verificá que los datos están.
- Sacale el acceso al proveedor por un día —en un ambiente de prueba— y confirmá que todo sigue funcionando y que podés entrar a todo.
La tercera suena hostil y no lo es. Es exactamente la situación en la que vas a estar el día que la relación termine, sea por el motivo que sea, y es mejor descubrir los faltantes mientras todavía hay alguien del otro lado para resolverlos.
Nada de esta lista es una desconfianza hacia el proveedor. Es lo que hace que el sistema sea tuyo. Un proveedor que trabajó bien va a poder tildar los diez puntos sin esfuerzo, y uno que se incomoda con la lista te está diciendo algo importante.
Preguntas frecuentes
¿Qué tengo que pedir cuando me entregan un desarrollo?
Diez cosas: el código en un repositorio a tu nombre, las cuentas de infraestructura a tu nombre, las credenciales entregadas y rotadas, cómo se levanta el proyecto de cero, cómo se despliega y los backups probados. También el detalle de la garantía, qué pasa después de ella, las dependencias con sus versiones y la capacitación grabada. Es lo que hace que el sistema sea un activo tuyo y no una dependencia alquilada.
¿Por qué el código tiene que estar a mi nombre desde el principio?
Porque si te lo entregan recién al final perdés todo el historial, que es la mitad del valor. Sin él nadie puede entender por qué las cosas se hicieron como se hicieron. El repositorio tiene que estar a nombre de tu empresa, con vos como dueño de la organización y el proveedor como colaborador al que podés dar de baja.
¿Cómo verifico que el sistema realmente es mío?
Con tres pruebas antes de firmar la conformidad: levantar el proyecto siguiendo el documento con alguien ajeno al desarrollo, restaurar un backup en un ambiente aparte y sacarle el acceso al proveedor por un día en un ambiente de prueba. Esa última es exactamente la situación en la que vas a estar el día que la relación termine. Es mejor descubrir los faltantes mientras todavía hay alguien del otro lado para resolverlos.
¿Qué cubre la garantía?
Tiene que estar por escrito cuánto dura, qué entra y qué no. Un botón que no guarda es un error y entra, y un reporte que ordena por fecha cuando lo querías por cliente, si el pedido decía fecha, es un cambio y no entra. También conviene dejar fijado en qué horario se atiende y en cuánto tiempo se responde.
¿Qué hago con las claves que conoce el proveedor?
Rotalas después de la entrega. Las claves que conoce un proveedor con el que terminaste la relación no son tus claves. La lista completa de usuarios, claves y tokens se entrega por un canal seguro.