Qué necesitas tener listo antes de empezar un desarrollo

Resumen:

• Una persona que decida, con horas reservadas en su agenda.
• Una exportación real de los datos, mirada antes de arrancar.
• Dominios, servidores y cuentas a nombre de tu empresa.
• Los trámites de terceros iniciados el día uno, no cuando hagan falta.
• La lista escrita de lo que NO entra en esta etapa.

Hay un patrón que se repite: el proyecto arranca con energía, la primera semana avanza bien, y en la semana dos se detiene. No por un problema técnico. Porque llegó la primera pregunta de negocio y no hay a quién preguntarle, o porque los datos que iban a migrar no existen en el formato que alguien prometió.

Todo lo que detiene un proyecto en la semana dos se puede tener listo antes de la semana uno. Esta es la lista.

1. Una persona que decida

No un comité, no un grupo de WhatsApp: una persona, con nombre, que pueda contestar «cuando un pedido se cancela después de facturado, hacemos esto» sin consultar a nadie.

Dos requisitos. Que conozca la operación de verdad —no cómo debería ser, cómo es— y que tenga tiempo reservado. Tres a seis horas por semana, en el calendario, antes de que empiece el proyecto. Si esas horas no están bloqueadas, van a desaparecer.

El error más común es nombrar a alguien de sistemas. Las preguntas que llegan no son técnicas: son de reglas de negocio. Quién autoriza un descuento, qué se hace con un cliente sin RFC, cómo se reparte una comisión cuando hay dos vendedores. Sistemas no puede contestar eso, y cada pregunta rebota.

¿Quién debe ser el responsable del proyecto del lado del cliente?

Alguien que conozca la operación de verdad y que pueda decidir sin consultar a tres personas. Suele ser el dueño en empresas chicas o el gerente del área en medianas. El error común es nombrar a alguien de sistemas que no tiene autoridad sobre las reglas del negocio: las preguntas que llegan son de negocio, no técnicas.

¿Cuánto tiempo del cliente consume un proyecto de software?

Entre tres y seis horas por semana del responsable, concentradas en decisiones y en revisar la demostración quincenal. Más de eso suele significar que el alcance no estaba claro; menos suele significar que el proyecto está avanzando a ciegas y que las correcciones vendrán al final.

2. Los datos, de verdad

Una exportación completa de lo que se va a migrar, no una muestra bonita de diez renglones. Clientes, productos, histórico, lo que aplique.

Y que alguien la mire antes de empezar. Dos días de revisión sobre datos reales cambian la estimación del proyecto completo, porque es ahí donde aparece lo que nadie sabía: los 400 clientes duplicados con variantes del nombre, las fechas capturadas como texto libre, el campo de precio que a veces trae el precio y a veces trae una nota.

Si no tienes manera de exportar porque el sistema anterior no lo permite, eso también es información crítica, y es mejor saberlo ahora. Suele significar una fase de extracción que nadie cotizó.

3. Accesos y dominios a tu nombre

• Dominio registrado por tu empresa, con tu correo como administrador.
• Cuenta de nube o servidor con tu facturación.
• Organización propia en el servicio de repositorios, donde el proveedor entre como colaborador.
• Correo corporativo para las cuentas del proyecto, no el personal de nadie.

Esto toma una tarde y es la diferencia entre un proyecto que es tuyo y uno que depende de la buena voluntad de alguien más. Hecho antes de empezar, no cuesta nada ni incomoda a nadie; pedido al final, parece desconfianza.

4. Los trámites de terceros, iniciados

Ninguno de estos depende de que el software exista. Todos se pueden iniciar el primer día. La causa del retraso nunca es que tarden: es que se piden cuando ya bloquean.

5. La lista de lo que no entra

La sección que nadie escribe. Cinco o diez líneas que dicen explícitamente qué queda fuera de esta etapa: «no hay aplicación móvil», «no se migra histórico de más de dos años», «la facturación sigue siendo manual», «no hay reportes personalizables».

Sirve para dos cosas. Primero, para que las cotizaciones sean comparables, porque elimina la interpretación. Segundo, y más importante, para que en el mes tres, cuando alguien pida la aplicación móvil, la conversación sea «eso es la siguiente etapa, lo cotizamos» en vez de «pero yo pensé que estaba incluido».

¿Necesito tener los requerimientos completos antes de empezar?

No, y querer tenerlos completos suele retrasar el arranque meses sin mejorar el resultado. Lo que sí necesitas completo es el problema que resuelves, quién lo va a usar y la frontera de lo que no entra. El detalle de cada pantalla se define mejor durante el proyecto, viendo el sistema funcionar.

¿Qué tengo que preparar antes de que empiece el desarrollo?

Cinco cosas: una persona con autoridad para decidir y tiempo en su agenda, una exportación real de los datos que se van a usar, los accesos y dominios a nombre de tu empresa, los trámites de terceros iniciados, y la lista escrita de lo que queda fuera de esta etapa. Las cinco se pueden tener en una semana.

Cuando no tienes claridad para escribir nada de esto

Pasa seguido y no es un problema: es un proyecto distinto. Si no sabes qué debe hacer el sistema, no contrates el desarrollo todavía. Contrata una fase corta de análisis, de dos a cuatro semanas, pagada, que entregue el documento con el que cualquier proveedor pueda cotizar.

Lo que esa fase debe entregar: el proceso actual mapeado, los datos revisados, el alcance de la primera versión con su frontera, y una estimación con rango. Con ese documento en la mano puedes pedir tres cotizaciones comparables, y puedes pedírselas a otros, no necesariamente a quien hizo el análisis.

¿Vale la pena pagar una fase de análisis antes del desarrollo?

Cuando el proyecto pasa de unos 150,000 pesos o toca datos de un sistema anterior, sí. Una fase corta y pagada que revisa los datos reales, define el alcance y entrega un documento con el que cualquiera pueda cotizar, reduce drásticamente la dispersión de precios y los sobrecostos posteriores.

La semana cero

Si tuvieras que hacer una sola cosa de esta lista, sería la primera: la persona que decide, con horas en el calendario. Es la que explica la mayor parte de los retrasos y la única que no se puede comprar después.

Las otras cuatro toman entre tres días y una semana, se pueden hacer en paralelo, y no cuestan dinero. Es la semana más rentable de cualquier proyecto de software.