Por qué los proyectos de software se retrasan, y la parte que te toca a ti
Los retrasos en software son casi una ley física. Parte es culpa de quien construye, y una parte importante depende del cliente. Esta es la verdad incómoda.
Hay una broma vieja entre desarrolladores: coge la estimación, multiplícala por dos y sube a la siguiente unidad de tiempo. Dos días pasan a ser cuatro semanas. Es exagerado, pero esconde algo cierto sobre lo mal que se nos da calcular cuánto tarda construir algo nuevo.
Una parte del retraso es responsabilidad de quien hace el software, y conviene decirlo sin rodeos. Estimamos mal lo que no hemos hecho antes. Aparecen problemas que nadie podía prever hasta meterse dentro. A veces se promete una fecha para cerrar la venta sabiendo que es optimista. Todo eso es real y nos toca a nosotros.
Pero hay otra parte que depende del cliente, y de esa se habla menos. El proyecto se para porque llevas tres semanas sin contestar una pregunta clave. Cambias lo que querías a mitad de camino, lo cual es legítimo, solo que cada cambio mueve la fecha. La persona que tenía que dar el visto bueno está siempre de viaje. Nada de esto sale en el contrato, pero pesa igual.
En la mayoría de los proyectos que se retrasan, el cuello de botella son las decisiones que nadie toma a tiempo. Un equipo parado esperando que alguien decida entre dos opciones cuesta lo mismo que un equipo trabajando, solo que sin avanzar. Y esas esperas se acumulan en silencio.
Como cliente puedes hacer dos cosas que cambian el resultado más que ninguna otra. Contestar rápido cuando te preguntan, aunque la respuesta sea 'dame un día'. Y cerrar el alcance de cada tramo antes de empezarlo, resistiendo la tentación de añadir 'una cosita más' a media construcción.
Un retraso casi nunca tiene un solo culpable. Sale de la suma de optimismo por un lado y decisiones lentas por el otro. La buena noticia es que la mitad de esa ecuación está en tu mano, y es la mitad más barata de arreglar.