Qué te tiene que entregar quien te hace software

Al terminar un proyecto de software, sea una web, una tienda o una integración, te tienen que quedar cinco cosas: las cuentas a tu nombre, la lista de accesos, un manual para usarlo, qué hacer si algo falla y una explicación de cómo está armado. Si falta alguna, dependés de quien lo hizo, aunque no lo sepas.

Por qué importa (y por qué casi nunca se hace)

Nos tocó hacernos cargo de dos sistemas de facturación de una empresa que vende online en varios países. Funcionaban, pero no había una sola línea escrita sobre cómo. Para hacer el primer arreglo tuvimos que entender todo desde cero, y eso le costó a la empresa horas que no tendría que haber pagado.

No es un caso raro. La documentación es lo primero que se recorta cuando un proyecto viene apurado, y el problema no aparece el día de la entrega. Aparece meses después, cuando algo falla, cuando quien lo hizo no contesta o cuando querés cambiar de proveedor.

Las cinco cosas que te tienen que quedar

1. Las cuentas, a tu nombre

El dominio, el hosting, la tienda, el servicio de mails, el repositorio del código. Todo eso tiene que estar en cuentas de tu empresa, con tu mail y tu tarjeta.

Es lo más importante de la lista. Si el dominio está en la cuenta personal de quien te hizo la web y un día deja de contestar, recuperarlo puede ser un problema serio. Quien trabaja para vos debería entrar con un acceso que le das y que podés sacarle cuando quieras.

2. Una lista de qué es tuyo y cuánto cuesta

Una tabla simple con cada servicio: para qué sirve, a nombre de quién está, cuánto cuesta y cuándo vence. Así no te enterás de que el dominio venció porque la web dejó de andar.

3. Un manual para usarlo

Escrito para la persona de tu equipo que lo va a usar, no para un programador. Cómo publicar un artículo, cómo cargar un producto, cómo ver si una factura salió bien. Con capturas o un video corto, mejor.

La prueba es simple: ¿alguien nuevo en tu equipo podría hacer la tarea leyendo el manual, sin llamar a nadie?

4. Qué hacer si algo falla

Las fallas más probables y qué hacer en cada una: "si una venta no se facturó, entrá acá y tocá reprocesar". Y cuándo hay que llamar, a quién y por dónde.

Un buen sistema además avisa solo cuando algo sale mal, por ejemplo con un mail. Preguntá si el tuyo lo hace y a quién le llega ese aviso.

5. Cómo está armado

Esta parte no es para vos: es para el próximo que lo toque. Qué piezas tiene, dónde corre, cómo se conecta con otros sistemas y dónde está el código. Si mañana cambiás de proveedor, esto le ahorra días a quien siga.

Y después de la entrega: un registro de cambios

Un sistema no termina el día que se entrega. Se ajusta, se le suman cosas, se arreglan detalles. Pedí que cada cambio quede anotado: qué se pidió, qué se hizo, cómo se probó y cómo volver atrás si hace falta. Un año después, ese registro es la única memoria de por qué el sistema hace lo que hace.

Cómo lo hacemos nosotros

Al cerrar cada proyecto entregamos lo que llamamos un kit de entrega: un manual con estas cinco partes, más los tutoriales y una lista de lo que conviene revisar en los próximos meses. Lo armamos antes de la última llamada, para repasarlo juntos.

Lo hacemos porque queremos que puedas operar lo que hicimos sin depender de nosotros. Si seguimos trabajando juntos, que sea porque querés, no porque no te queda otra.

Preguntas para hacer antes de contratar

• ¿A nombre de quién van a quedar las cuentas y el dominio?

• ¿Qué documentación entregan al final? ¿Puedo ver un ejemplo?

• ¿Cómo me entero si algo deja de funcionar?

• Si mañana quiero que lo siga otra persona, ¿qué necesita?

Si la respuesta a alguna es vaga, preguntá de nuevo.

¿Tenés un sistema que nadie sabe cómo funciona?

Si heredaste una web, una tienda o una integración sin documentación y no sabés bien qué tenés, agendá una llamada de media hora. Te ayudamos a entender qué hay, qué es tuyo y qué conviene ordenar primero.