Firmaste el contrato un jueves. El lunes siguiente llega una invitación a "kickoff" para las 10:00, con siete personas del proveedor que no conoces y una pregunta en el correo que nadie de tu equipo sabe responder: ¿quién va a aprobar las historias de usuario? Recién ahí te das cuenta de que contrataste un proyecto, pero no sabes muy bien qué te toca hacer a ti durante los próximos cuatro meses.
Trabajar con una empresa de desarrollo de software no se parece a comprar un producto y esperar que llegue. Es más parecido a una obra en la que el dueño visita el terreno cada semana: hay reuniones fijas, cosas que revisar y decisiones que solo tú puedes tomar. Si sabes de antemano cómo se ve una semana normal, el proyecto avanza más rápido y con menos sorpresas en la factura.
Este artículo describe ese día a día desde el lado del cliente. No entra en cómo elegir proveedor (para eso están las 10 preguntas antes de firmar) ni en el detalle técnico de cada fase, que tratamos en etapas y entregables del desarrollo de software.
La primera semana: kickoff y acuerdos que conviene dejar por escrito
El kickoff es la reunión de arranque. Dura entre una y dos horas y su objetivo es que ambos equipos salgan sabiendo lo mismo: qué se va a construir primero, quién decide qué y cómo se van a comunicar.
Al terminar esa primera semana deberías tener:
- Un responsable de producto en tu empresa con nombre y apellido. En Scrum este rol se llama Product Owner, y la Guía de Scrum es explícita: es una persona, no un comité. Si tres gerentes pueden cambiar prioridades por separado, el equipo de desarrollo va a recibir instrucciones contradictorias.
- El calendario de reuniones fijas, con día y hora.
- El canal oficial de comunicación (Teams, Slack, correo) y qué tipo de tema va por cada uno.
- Los accesos que el proveedor necesita: ambientes, APIs del ERP, usuarios de prueba, VPN. Este punto suele atrasar el inicio más que cualquier problema técnico.
- Una primera versión del backlog, es decir, la lista priorizada de funcionalidades.
Si el sistema va a tratar datos personales de clientes o trabajadores, en esta semana también se revisa el contrato de encargo de tratamiento. La Ley 21.719 pide en su artículo 15 bis que ese contrato fije el objeto, la duración, la finalidad, el tipo de datos y las categorías de titulares.
Cómo se ve una semana normal del proyecto
Pasado el arranque, el proyecto entra en ciclos cortos. La Guía de Scrum fija los sprints en un mes o menos; muchos equipos trabajan con sprints de dos semanas, que es el ritmo que usamos en este ejemplo.
| Momento | Qué pasa | Qué se espera de ti |
|---|---|---|
| Inicio del sprint (lunes) | Planificación: el equipo toma historias del backlog | Confirmar prioridades y aclarar dudas de negocio |
| Durante el sprint | Desarrollo, preguntas puntuales por el canal acordado | Responder en 24 a 48 horas |
| Mitad del sprint | Revisión corta de avance (opcional, 30 min) | Avisar si algo cambió en el negocio |
| Cierre del sprint (viernes de la segunda semana) | Demo de lo terminado en ambiente de pruebas | Probar, comentar y aceptar o rechazar |
| Entre sprints | Refinamiento del backlog | Detallar las próximas historias con criterios de aceptación |
En la práctica, el compromiso del lado del cliente es de unas pocas horas a la semana para el Product Owner y algo más en las semanas de prueba. El cuello de botella más común no está en el proveedor. Está en la pregunta que queda tres días sin respuesta porque la persona que sabe la regla de negocio estaba en terreno.
Las demos de cada dos semanas
La demo al cierre de cada sprint es la reunión más importante para ti. La Guía de Scrum la llama Sprint Review y la describe como una sesión de trabajo donde el equipo y los interesados revisan lo logrado y deciden qué hacer después. Agrega una advertencia que vale la pena tomar en serio: no debería limitarse a una presentación. Para un sprint de un mes dura como máximo cuatro horas; con sprints de dos semanas suele bastar una o dos.
Pide que te muestren el sistema funcionando en el ambiente de pruebas, el mismo que vas a usar después, y no en diapositivas. Invita a uno o dos usuarios reales además de las jefaturas: el operario de bodega detecta en cinco minutos cosas que en la sala de reuniones nadie ve. Y antes de cerrar, anota las decisiones: qué se aprueba, qué se corrige y qué cambia de prioridad.
Si llevas dos o tres demos donde todo "se ve bien" pero nadie lo ha probado con sus propias manos, conviene detenerse y preguntar por qué.
Ambientes de prueba y aprobación de entregables
Un proyecto ordenado tiene al menos tres ambientes: desarrollo, donde trabaja el equipo; pruebas (a veces llamado QA o staging), donde tú validas; y producción, donde opera el negocio. Tu equipo solo debería necesitar acceso al segundo.
Aprobar un entregable significa revisarlo contra criterios que se acordaron antes de construirlo. Si la historia decía "dado un cliente con deuda vencida, cuando se ingresa un pedido, entonces el sistema lo bloquea", la prueba consiste en hacer exactamente eso. Si aparece algo que no estaba en los criterios, eso es un cambio y se trata como tal: se agrega al backlog y se prioriza.
Dos recomendaciones prácticas:
- Deja la aprobación por escrito, aunque sea un comentario en la herramienta de gestión o un acta breve. Seis meses después nadie recuerda qué se aceptó en la demo del sprint 4.
- No uses copias de la base de producción con datos reales en el ambiente de pruebas. Si hacen falta datos realistas, hay que anonimizarlos; lo explicamos en datos reales en ambientes de prueba y la Ley 21.719.
Sobre esa ley: hoy su entrada en vigencia está fijada para el 1 de diciembre de 2026. Hay un proyecto para moverla al 15 de octubre de 2027. El Senado ya lo aprobó, y el 5 de noviembre la Comisión de Constitución de la Cámara lo aprobó en general y lo envió a Hacienda. Mientras no se publique, la fecha vigente no cambia. Y un sistema que se construye ahora va a operar años con la ley en régimen.
Comunicación y cambios de alcance
Los cambios van a llegar. El mercado se mueve, la gerencia ve la primera demo y se le ocurre algo mejor, aparece una excepción que nadie había contado. Es normal. El problema aparece cuando los cambios entran por el pasillo, en una conversación que nadie anotó.
Un esquema que funciona:
- Toda solicitud nueva pasa por el Product Owner, que la agrega al backlog.
- El proveedor estima su impacto en plazo y costo antes de comprometerla.
- Tú decides qué sale para que entre lo nuevo, si el presupuesto es fijo.
Pide también un informe corto de estado cada dos semanas: qué se terminó, qué viene, riesgos abiertos y horas consumidas frente a lo presupuestado. Si ese informe no existe, lo más probable es que te enteres de los problemas cuando ya cuesten caro.
Si en vez de un proyecto con alcance definido estás pensando en sumar desarrolladores a tu propio equipo, la dinámica es otra; la comparamos en staff o proyecto.
Lo que la empresa de desarrollo te va a pedir
Casi cualquier proveedor serio te va a pedir lo siguiente durante el proyecto. Tenerlo resuelto antes de partir ahorra semanas:
- Una persona con tiempo y autoridad para decidir sobre el producto.
- Accesos técnicos a los sistemas que hay que integrar, con alguien de tu TI que responda.
- Usuarios disponibles para probar en las semanas de demo y en la prueba de aceptación final.
- Reglas de negocio documentadas, o al menos alguien que las conozca y pueda explicarlas.
- Decisiones a tiempo. Una semana sin respuesta sobre una prioridad es una semana de equipo pagada que avanza a ciegas.
Preguntas frecuentes
¿Cuánto tiempo tengo que dedicarle al proyecto como cliente?
Depende del tamaño, pero el Product Owner suele necesitar varias horas por semana, más en las semanas de demo y de pruebas de aceptación. Si nadie en tu empresa puede dedicar ese tiempo, el proyecto se va a atrasar.
¿Qué pasa si en la demo veo algo que no me gusta?
Lo dices en ese momento. Si contradice los criterios de aceptación, es un defecto y se corrige. Si es algo nuevo, se agrega al backlog como cambio y se prioriza contra lo que ya está planificado.
¿Tengo que entender de metodologías ágiles para trabajar con una empresa de software?
No. Basta con entender el ritmo: planificación, desarrollo, demo y ajuste, cada dos semanas. El proveedor debería explicarte en el kickoff cómo trabaja y qué espera de ti.
Antes de arrancar tu próximo proyecto
Si estás por contratar desarrollo y quieres saber cómo sería trabajar juntos, semana a semana, conversemos. En Disrupsoft diseñamos y desarrollamos aplicaciones web y móviles a medida, y trabajamos en comunicación constante con tu equipo durante todo el proyecto. Revisa nuestro servicio de desarrollo de software a medida.
