Guía
Gestión de proyectos informáticos: lo que realmente cambia
Los proyectos informáticos fracasan menos por la técnica que por tres rasgos del terreno: producto invisible, equipos compartidos y un sistema que debe seguir vivo.
La gestión de proyectos informáticos sigue los mismos fundamentos que cualquier otro proyecto: alcance, plazo, coste, riesgo. Lo que cambia no es el método sino el terreno, y tres características de ese terreno explican lo esencial de la dificultad: lo que se construye no se ve, quienes lo construyen están compartidos con otros proyectos, y el sistema existente debe seguir funcionando durante todo el tiempo.
El avance no es observable
En una obra, todo el mundo ve subir las plantas. En un proyecto informático, la única señal visible es lo que alguien declara. Por eso el avance anunciado sobre un software deriva hacia una cifra cómoda y se queda ahí: el famoso último 10 % que dura tres meses. La contramedida es hacer observable el avance: software que funciona a ritmo fijo, integración continua en lugar de al final, y criterios de aceptación escritos antes del desarrollo y no negociados después.
El equipo nunca es dedicado
Los informáticos están compartidos: el mismo arquitecto sirve a cuatro proyectos, el mismo DBA está en la ruta crítica de todos, y el soporte de producción pasa por delante en cuanto se abre una incidencia. Un plan construido sobre la disponibilidad nominal es, por tanto, falso desde el principio. Hay que planificar sobre la capacidad neta de soporte, vacaciones y los demás proyectos, lo cual es una cuestión de cartera y no de proyecto, y la principal razón por la que los calendarios informáticos se deslizan sin que ningún proyecto aislado haya hecho nada mal.
Lo existente forma parte del alcance
Muy pocos proyectos informáticos parten de una página en blanco. Las interfaces con los sistemas instalados, la migración de datos, la convivencia de dos versiones durante la transición y la reversibilidad si el arranque sale mal rara vez se estiman con seriedad en el encuadre, y suelen pesar más que la funcionalidad nueva. Un pliego que solo describe el objetivo y no dice nada de la transición ha omitido la mitad del proyecto.
Agilidad y planificación no se oponen
La mayoría de las direcciones informáticas funcionan en híbrido, lo asuman o no: ágil dentro de los equipos, fechas y presupuestos comprometidos fuera. Pretender lo contrario produce dos verdades desconectadas: un backlog que dice una cosa y un comité de dirección que oye otra. El enfoque practicable consiste en planificar la bolsa y los hitos, iterar dentro, y rearbitrar el alcance en lugar de mover la fecha en silencio.
Pilotar proyectos informáticos con FoxPlan
FoxPlan sostiene los dos niveles a la vez: un Gantt planificado con hitos y presupuesto para los compromisos, tableros ágiles y sprints para el trabajo en sí, y una capacidad de recursos consolidada sobre todos los proyectos, de modo que un arquitecto compartido aparezca como una sola persona y no como cuatro. El tiempo introducido por los equipos alimenta a la vez el avance y el coste, lo que permite rendir cuentas de una cartera informática sin hoja de cálculo paralela.
