La gestión de proyectos informáticos se refiere al conjunto de actividades que permiten transformar una necesidad empresarial en un entregable técnico, dentro de un marco de costos, plazos y calidad definidos de antemano. Dirigir un proyecto informático en una empresa supone dominar tanto el alcance funcional, las dependencias técnicas como la coordinación de los equipos. Tres dimensiones que, mal articuladas, son suficientes para desviar un proyecto mucho antes de la primera línea de código.
Ciberseguridad y cumplimiento NIS2: un riesgo de proyecto a integrar desde el encuadre
La mayoría de las guías de gestión de proyectos informáticos abordan los riesgos desde la perspectiva del presupuesto o del calendario. La directiva europea NIS2 añade una restricción regulatoria directa: las organizaciones afectadas deben tener en cuenta la seguridad de sus proveedores y prestadores, incluidas sus propias vulnerabilidades.
En la práctica, esto significa que un proyecto de TI que recurre a un editor SaaS, un proveedor de alojamiento o un integrador debe mapear estas dependencias desde la fase de encuadre. Los requisitos de seguridad se incluyen entonces en los contratos, y la verificación de las pruebas de cumplimiento se convierte en un hito del proyecto, no en una auditoría puntual realizada después.
El calendario francés de transposición de NIS2 aún no está completamente estabilizado, pero las organizaciones que podrían verse afectadas tienen interés en anticiparse. Determinar el estado de la entidad, documentar los riesgos y probar la detección y notificación de incidentes constituyen un trabajo en sí mismo en la gestión de un proyecto informático. Recursos especializados permiten profundizar en estos desafíos de gestión: https://www.projets-informatiques.fr/ centraliza, entre otras cosas, experiencias sobre la conducción de proyectos de TI.
Un punto a menudo subestimado: NIS2 puede combinarse con otros marcos como DORA o el Cyber Resilience Act. Un mismo incidente puede entonces dar lugar a varias notificaciones, con plazos y criterios diferentes. El proyecto debe definir de antemano quién califica el incidente y quién decide notificar, bajo pena de confusión operativa en el peor momento.
Gestión del alcance del proyecto: la deriva silenciosa que más cuesta
El alcance de un proyecto informático se refiere al conjunto de funcionalidades, entregables y restricciones aceptados por todas las partes interesadas al inicio. Cualquier modificación no formalizada de este alcance constituye lo que se llama scope creep.
El scope creep no se manifiesta a través de una solicitud espectacular. Toma la forma de micro-adiciones: un campo adicional en un formulario, una integración con una herramienta externa “que solo tomará dos días”, un informe solicitado en una reunión de seguimiento. Tomados individualmente, cada uno parece inofensivo. Acumulados durante varios meses, desplazan el cronograma varias semanas y movilizan recursos no previstos.
Formalizar el proceso de solicitud de cambio
Para contener esta deriva, cada modificación del alcance debe pasar por un proceso explícito. Este proceso incluye tres elementos concretos:
- Una ficha de solicitud de cambio (change request) redactada por el solicitante, describiendo la necesidad, el impacto estimado en el cronograma y el presupuesto, y la justificación empresarial.
- Un comité de dirección o un responsable designado que valide o rechace la solicitud sobre la base de criterios objetivos, no durante una discusión informal.
- Una actualización del referente del proyecto (cronograma, presupuesto, documentación funcional) con cada cambio aceptado, para que el equipo siempre trabaje sobre una versión actualizada del alcance.
Sin este mecanismo, el jefe de proyecto absorbe las solicitudes por defecto, y el alcance real diverge del alcance contractual. La trazabilidad de los cambios protege tanto al equipo técnico como al patrocinador.
Comunicación entre equipos técnicos y de negocio: estructurar los intercambios
La comunicación en un proyecto informático no se limita a enviar un informe semanal. El problema recurrente radica en la asimetría de lenguaje entre los equipos técnicos y las partes interesadas de negocio. Un desarrollador habla de API, de deuda técnica y de sprints. Un director comercial quiere saber si la funcionalidad estará disponible para el próximo trimestre.
Esta asimetría genera dos tipos de disfunciones. La primera: los equipos de negocio validan especificaciones que no han comprendido, lo que produce entregables conformes al pliego de condiciones pero inutilizables. La segunda: los equipos técnicos subestiman la importancia de una necesidad empresarial porque ha sido formulada de manera vaga.
Rituales de sincronización adaptados al contexto
La frecuencia y el formato de los intercambios deben variar según la fase del proyecto. En la fase de encuadre, talleres de co-diseño con soportes visuales (maquetas, recorrido del usuario) reducen los malentendidos. En la fase de ejecución, un breve punto diario o quincenal entre el jefe de proyecto y los referentes de negocio es suficiente para detectar las desviaciones antes de que se conviertan en bloqueos.
Un tablero compartido, actualizado en tiempo real a través de una herramienta de gestión de tareas, reemplaza útilmente los largos correos electrónicos de informes. El objetivo no es multiplicar las reuniones, sino hacer que la información sea accesible al nivel adecuado de detalle para cada interlocutor.
Indicadores de gestión de proyectos informáticos: medir lo que importa
Dirigir un proyecto sin indicadores es como conducir sin tablero de mando. Dos categorías de indicadores merecen ser seguidas en paralelo: los indicadores de avance y los indicadores de salud.
Los indicadores de avance miden la progresión respecto al plan: porcentaje de tareas terminadas, cumplimiento de hitos, consumo del presupuesto. Responden a la pregunta “¿estamos a tiempo?”.
Los indicadores de salud miden la calidad del proceso en sí: número de errores abiertos, tasa de cobertura de pruebas, tiempo medio de resolución de anomalías, tasa de participación en los rituales de comunicación. Un proyecto puede estar “a tiempo” mientras acumula una deuda técnica que explotará después de la puesta en producción.
- El seguimiento de la velocidad (en método ágil) o de la desviación planificada/realizada (en método secuencial) permite ajustar los recursos antes de que el retraso se vuelva irrecuperable.
- El número de solicitudes de cambio aceptadas por sprint o por fase proporciona una medida objetiva de la estabilidad del alcance.
- La tasa de disponibilidad de los entornos de prueba señala los cuellos de botella técnicos que a menudo son invisibles en los informes clásicos.
Seguir estos indicadores requiere rigor, pero también discernimiento. Un tablero de mando sobrecargado de métricas pierde su función de alerta. Tres a cinco indicadores bien elegidos, revisados en cada comité de dirección, aportan más valor que una veintena de gráficos que nadie lee.
El éxito de un proyecto informático depende menos de la elección de un método ágil o secuencial que de la capacidad del equipo para mantener un alcance estable, intercambios legibles entre negocio y técnica, y indicadores que desencadenen la acción antes de la crisis. El cumplimiento regulatorio, especialmente con NIS2, añade ahora una cuarta dimensión que la gestión de proyectos ya no puede tratar al margen.
