En esta nota (10 secciones)
Todo el mundo sabe que los desarrollos se estiran. Lo que casi nadie explica es por qué, y sin eso la conversación se queda en pedirle al proveedor que se comprometa más, que nunca funcionó.
Los plazos no se estiran por falta de compromiso. Se estiran por causas identificables, y la mayoría no están del lado del que programa.
Los plazos típicos
Para tener una referencia de orden de magnitud:
- Herramienta interna acotada —un ABM, un formulario, un reporte—: 1 a 3 semanas.
- MVP o primera versión de un producto: 3 a 6 semanas.
- Sistema de gestión de pyme: 2 a 4 meses.
- Sistema con varias integraciones y roles: 4 a 8 meses.
- Reemplazo de un sistema legacy en producción: 6 meses a 2 años, y depende más de la migración que del desarrollo.
Un dato que ordena la expectativa: el tiempo de calendario no es el tiempo de trabajo. Un proyecto de 200 horas no sale en cinco semanas si el equipo trabaja en paralelo con otros dos clientes, y tampoco sale en una si le ponés cinco personas.
Las cinco causas reales de que se estire
1. El alcance creció y nadie lo anotó
La causa número uno, lejos.
No aparece como un pedido grande. Aparece como veinte pedidos chicos: "ya que estás, agregale el campo", "sería bueno que también mande un mail", "¿no podría filtrar por fecha?". Cada uno es media hora. Veinte de esos son dos semanas.
El problema no es pedirlos. Es que no se registran como lo que son. Un cambio que no se anota se convierte en un retraso sin causa visible, y a fin de mes nadie entiende por qué se atrasó.
2. Las decisiones del cliente tardan
Esta es la que más sorprende a quien contrata, y es la más fácil de arreglar.
El desarrollo se frena esperando: cuál es la lógica de descuentos, quién autoriza qué, cómo se numeran los comprobantes, cuál de los tres circuitos es el bueno. Cada pregunta sin responder es un día parado.
Poné una persona con autoridad para decidir y con tiempo asignado. No alguien que tenga que consultar y volver en tres días. Es la intervención más barata y más efectiva que existe sobre un plazo.
3. Los datos viejos estaban peor de lo que se pensaba
Nombres escritos de cinco formas, fechas como texto, registros duplicados, saldos que no cierran. Limpiar eso no estaba en el plan y siempre lleva más de lo previsto.
Y no se puede saltear: un sistema nuevo con datos malos nace desconfiado y no se recupera.
4. El otro sistema no cooperó
Si el proyecto integra contra algo de un tercero, el plazo depende parcialmente de un tercero. Documentación incompleta, ambientes de prueba que no funcionan, soporte que tarda una semana en contestar.
Es la parte del plan con más varianza y la que menos control tiene cualquiera de las dos partes.
5. Se probó tarde
Si la primera vez que un usuario real toca el sistema es en la semana de entrega, ahí van a aparecer los casos que nadie contó. Y aparecen todos juntos, en el peor momento.
Lo que no acelera un proyecto
Sumar gente. Un proyecto atrasado con más desarrolladores se atrasa más al principio: hay que explicarles el contexto y coordinarlos. Sirve para trabajo genuinamente paralelo, no para apurar lo que ya está en marcha.
Saltear el descubrimiento. Ahorrás dos semanas al principio y las pagás con intereses en el medio, cuando se descubre que el circuito era otro.
Pedir que trabajen fines de semana. Compra días, no semanas, y baja la calidad de lo que viene después.
Sacar las pruebas. Es la forma más rápida de llegar a la fecha y la más segura de no terminar nunca, porque lo que se entrega vuelve.
Lo que sí acelera
Definir bien antes de empezar. Un documento de alcance con pantallas y reglas de negocio es la inversión que más plazo ahorra.
Un solo interlocutor con autoridad. Ver la causa 2.
Entregas parciales cada dos semanas. No para mostrar avance: para descubrir temprano lo que está mal. Un error detectado en la semana 2 cuesta horas; el mismo error detectado en la semana 10 cuesta días.
Sacar cosas. La única palanca que funciona de verdad sobre una fecha. Si la fecha no se mueve, tiene que moverse el alcance. Cualquier otra combinación es una promesa que alguien va a incumplir.
Cómo leer un plazo en un presupuesto
Tres señales de que el número es serio:
- Está atado a un alcance escrito, no a una charla.
- Dice qué necesita de vos y cuándo: decisiones, datos, accesos, gente para probar.
- Tiene entregas intermedias, no una sola fecha final.
Y una señal de que no lo es: un plazo agresivo ofrecido sin haber preguntado casi nada. Quien promete rápido antes de entender el problema no está siendo veloz, está estimando a ciegas, y esa diferencia la vas a pagar vos en el mes tres.