En esta nota (17 secciones)
Cuando contratás un desarrollo, comprás algo que no podés ver mientras se hace. No hay una obra que se recorre ni un producto que se prueba antes. Hay reuniones, un presupuesto y, meses después, un sistema.
Esa opacidad es la fuente de casi toda la desconfianza del rubro. Este artículo la abre: qué pasa adentro, quién hace qué, y qué deberías estar viendo cada semana para saber si va bien.
Las etapas, en orden
1. Descubrimiento
Antes de programar, alguien tiene que entender tu operación. Entrevistas con quien hace el trabajo, no sólo con quien lo supervisa. Salen distinto y el bueno es el primero.
Produce: un documento de alcance con pantallas, reglas de negocio, roles y criterios de aceptación.
Dura: entre una y tres semanas para un proyecto de pyme.
Lo que tenés que ver: ese documento, y tenés que poder leerlo y entenderlo sin ayuda. Si no lo entendés, no lo aprobés.
Un proveedor que cotiza cerrado sin haber hecho esto está adivinando. Va a poner un número alto para cubrirse, o uno bajo para ganar el trabajo y después discutir cada cambio como adicional.
2. Diseño
Cómo se van a ver las pantallas y cómo se navega entre ellas. En proyectos de gestión suele ser un prototipo navegable: pantallas que se pueden clickear, sin nada funcionando por atrás.
Lo que tenés que ver: ese prototipo, y probarlo vos. Es muchísimo más barato mover un botón acá que después.
3. Construcción
El desarrollo propiamente dicho, en ciclos de una o dos semanas. Al final de cada ciclo debería haber algo funcionando que puedas tocar.
Lo que tenés que ver, cada dos semanas: el sistema andando en un ambiente de prueba, con lo que se hizo en ese ciclo. No una presentación ni un porcentaje de avance: el software.
Si a las seis semanas nunca tocaste el sistema, algo está mal. No importa qué te muestre el informe de avance.
4. Pruebas
Dos capas: las del equipo —que idealmente incluyen tests automatizados— y las tuyas, con datos y casos reales.
Lo que tenés que hacer: designar a las personas que van a probar y darles tiempo asignado. La prueba del cliente es la parte del plan que más se subestima y la que más retrasa entregas.
5. Puesta en producción
La migración de datos, la capacitación y el corte. Es la etapa con más riesgo operativo y la que conviene planificar con más detalle.
6. Garantía y mantenimiento
Los errores que aparecen con uso real. El grueso sale en los primeros dos o tres meses y después baja fuerte, que es por lo que las garantías suelen ser de tres a seis meses.
Quién hace qué
En un equipo chico, una persona puede cubrir varios roles. Lo importante es que las funciones existan.
- Referente técnico. Decide cómo se construye. Es con quien tenés que poder hablar cuando algo no cierra.
- Desarrolladores. Escriben el código.
- Diseño de producto o UX. Define las pantallas y el flujo.
- QA. Prueba de forma sistemática. En equipos chicos suele estar repartido, y se nota cuando no está.
- Gestión del proyecto. Coordina, avisa de los desvíos, mantiene el alcance controlado.
- Referente del lado tuyo. No es opcional. Alguien de tu empresa con autoridad para decidir y tiempo asignado.
Ese último es el rol que más define el resultado y el único que el proveedor no puede cubrir. Los proyectos que se atrasan por decisiones pendientes del cliente son mayoría, y se arreglan poniendo a la persona correcta con horas reservadas.
Cómo se controla el alcance
Acá está la fuente número uno de conflictos.
Durante el proyecto van a aparecer pedidos nuevos. Es normal y es sano: significa que estás pensando el sistema. El problema no es pedirlos, es no registrarlos.
Lo que debería pasar con cada pedido: se anota, se estima, y se decide entre tres opciones —entra y corre la fecha, entra y sale otra cosa a cambio, o queda para una etapa siguiente—. Las tres son válidas. La que no lo es: que entre sin que nadie diga nada y aparezca después como un retraso sin causa.
Si tu proveedor no tiene un lugar donde se ven los pedidos de cambio con su estado, pedilo. Es la herramienta que más discusiones evita.
Las señales de que va bien
- Tocás el sistema cada dos semanas.
- Los cambios de alcance están anotados con su impacto.
- Te dicen los problemas cuando aparecen, no cuando ya no hay margen.
- Hay un referente técnico con nombre con el que podés hablar.
- El código está en un repositorio tuyo desde el principio.
Las señales de que va mal
- El avance se informa en porcentajes y nunca en software funcionando.
- Todo está "casi listo" durante varias semanas seguidas.
- Los cambios que pedís no aparecen anotados en ningún lado.
- Cada vez que preguntás algo técnico, la respuesta pasa por un intermediario que no entiende la pregunta.
- Nunca hay malas noticias. Todos los proyectos tienen problemas; el que no te los cuenta te los está guardando.
Esa última es la más importante de la lista. Un proveedor que te avisa temprano de un problema te está dando la única cosa que sirve para resolverlo: tiempo.
Preguntas frecuentes
¿Cuáles son las etapas de un proyecto de software?
Son seis: descubrimiento, diseño, construcción, pruebas, puesta en producción, y garantía y mantenimiento. El descubrimiento dura entre una y tres semanas para un proyecto de pyme y produce un documento de alcance con pantallas, reglas de negocio, roles y criterios de aceptación. La construcción se hace en ciclos de una o dos semanas.
¿Cada cuánto debería ver avances en mi sistema?
Cada dos semanas deberías poder tocar el sistema andando en un ambiente de prueba, con lo que se hizo en ese ciclo. No alcanza con una presentación ni con un porcentaje de avance. Si a las seis semanas nunca tocaste el sistema, algo está mal.
¿Qué tengo que aportar yo como cliente?
Un referente de tu lado, con autoridad para decidir y tiempo asignado, y personas con horas reservadas para probar. Es el rol que más define el resultado y el único que el proveedor no puede cubrir. Los proyectos que se atrasan por decisiones pendientes del cliente son mayoría.
¿Qué pasa cuando pido cambios durante el proyecto?
Es normal y sano que aparezcan. Cada pedido se anota, se estima y se decide entre tres opciones: entra y corre la fecha, entra y sale otra cosa a cambio, o queda para una etapa siguiente. Lo que no es válido es que entre sin que nadie diga nada y aparezca después como un retraso sin causa.
¿Cuánto dura la garantía y para qué sirve?
Las garantías suelen ser de tres a seis meses. Sirve para los errores que aparecen con uso real, que salen en su grueso en los primeros dos o tres meses y después bajan fuerte.