Desarrollo de software. Planificación. Llegan los retrasos
Partamos de la base de que la mayor parte de los sistemas de información que desarrollamos no tienen que estar de manera obligatoria en una fecha concreta en producción. El cliente te lo podrá exigir, pero realmente en la mayoría de los casos se tratan de fechas de referencia y no están ligadas a un hito especial.
Esto es simplemente estadística, ya que también todos hemos trabajado en desarrollos que sí tenían que estar en un día o semana concreta y existían razones de peso que lo justificaban.
Lo que quiero expresar en el inicio de este artículo es que hay que relativizar las fechas de entregas y tener en cuenta que hay aspectos más importantes que pueden justificar un retraso (siempre dentro de unos términos razonables).
No quiero decir que las fechas no estén para cumplirlas, ya que si se fijan y se pactan es para algo, entre otras cosas para no perder el enfoque del proyecto (enfoque que se diluye cuando no se cierra la fecha de entrega de un producto), lo que quiero decir es que cuando haya un retraso hay que estudiar los motivos, ¿es causa exclusiva del proveedor?, ¿de los usuarios?, ¿del director técnico del cliente?, ¿todos han tenido que ver en una determinada proporción?, ¿ha sido provocada porque los plazos exigidos al equipo de desarrollo son incumplibles ya que no están acordes al alcance del proyecto y los recursos disponibles?.
Una vez determinada la causa es posible tomar decisiones para intentar evitar nuevos retrasos o incluso intentar recuperar parte del camino perdido, sin embargo en la mayoría de los casos resulta muy complicado recuperar los retrasos, entre otras cosas porque no siempre se informa al cliente a tiempo y porque los plazos suelen ser bastante ajustados.
Si la fecha final del proyecto se puede retrasar, mi consejo es que se haga. Si el retraso es responsabilidad del proveedor, ya habrá tiempo de ajustar cuentas (cada palo que aguante su vela), pero no se debe caer en el riesgo de poner en marcha de manera precipitada un producto, ya que por cada paso que se de hacia adelante en este sentido probablemente se tengan que dar varios para atrás.
Si el retraso es lo suficientemente importante como para la fecha objetivo no sea admisible, es conveniente aplicar las prioridades que se hayan establecido sobre los requisitos (si se está desarrollando siguiendo metodologías ágiles, habrá sido el camino adoptado desde el principio del proyecto) y afrontar varios hitos de entrega.
Jummp 