Imagine una reunión de seguimiento cualquiera un lunes. Su equipo tiene decenas de incidencias en Redmine, y cada una tiene un responsable y una fecha de vencimiento.

.

Aun así, cuando el patrocinador pregunta si el lanzamiento sigue en plazo, la respuesta honesta es «depende». El seguimiento de tareas le dice qué está haciendo cada persona. No le dice si el proyecto en su conjunto llegará a tiempo.

Seguimiento de tareas vs. planificación de proyectos en Redmine

Redmine hace muy bien la primera parte del trabajo. Las incidencias se asignan, los estados cambian, se registra el tiempo y cualquiera puede ver quién es responsable de qué. Para un equipo pequeño con un horizonte corto, eso suele bastar.

A medida que los proyectos crecen, aparece otro tipo de preguntas que la lista de incidencias no puede responder:

  • ¿Vamos realmente según lo previsto?
  • ¿Qué tareas están bloqueando el avance?
  • ¿Qué pasa si un miembro del equipo no cumple un plazo?
  • ¿Afectará este retraso al lanzamiento final?
  • ¿Seguimos ajustándonos al plan original del proyecto?

Todas ellas son preguntas sobre relaciones: qué está esperando a una tarea retrasada, cuánto margen tiene el resto del plan y cuánto se ha alejado el cronograma de la versión que todos aprobaron. El seguimiento del avance por estado de las incidencias muestra lo que está hecho. La planificación del proyecto es lo que convierte eso en una fecha de entrega que pueda defender. Las secciones siguientes abordan estas preguntas una a una.

Redmine para la planificación de proyectos: lo que obtiene de serie

Antes de añadir nada, conviene tener claro lo que ya ofrece una instalación estándar de Redmine. Es más de lo que muchos equipos aprovechan:

  • Fechas y estimaciones en cada incidencia, con tareas padre e hijas para desglosar el trabajo.
  • Relaciones entre incidencias. Las relaciones de precedencia indican que una tarea no puede empezar antes de que termine otra, y se puede añadir un desfase. Cuando la incidencia anterior se retrasa, Redmine desplaza la siguiente con ella.
  • Versiones con fechas de vencimiento, que funcionan como hitos de lanzamiento y muestran el avance en la hoja de ruta.
  • El diagrama de Gantt, que dibuja incidencias y versiones sobre una línea de tiempo y muestra estas relaciones como flechas.
  • Consultas guardadas y exportación a CSV, suficientes para informes de estado y para una copia manual del plan.

Para un equipo pequeño, esto ya funciona como Redmine para la planificación de proyectos. Las carencias aparecen cuando el cronograma crece. Redmine no calcula la ruta crítica (una solicitud para mostrarla en el diagrama de Gantt lleva abierta en redmine.org desde 2013), no tiene una forma integrada de conservar el plan aprobado junto al actual y cada cambio de fecha pasa por el formulario de la incidencia.

Dónde se queda corto el diagrama de Gantt de Redmine

El diagrama de Gantt es el centro de ese conjunto de herramientas, y un diagrama de Gantt para la planificación de proyectos tiene que hacer algo más que mostrar fechas.

El diagrama de Gantt estándar ofrece una visión general útil de incidencias, fechas y relaciones. Sin embargo, no es un espacio de planificación interactivo: para cambiar fechas hay que editar las incidencias, y entender el impacto más amplio de un cambio propuesto exige un esfuerzo adicional. Un jefe de proyecto que mueve un hito una semana acaba abriendo una docena de incidencias, y leer las dependencias en una lista larga de tareas lleva tiempo. Además, quedan dos preguntas sin respuesta: qué tareas determinan la fecha de finalización y cómo se compara el cronograma de hoy con el que se aprobó.

Esa es la diferencia entre ver un cronograma y gestionarlo. Ver es una cuestión de visualización. Gestionar significa poder cambiar el plan, ver las consecuencias del cambio y acordarlo con el equipo. Planner lleva la edición del cronograma, la visibilidad de las dependencias y la revisión de cambios directamente al diagrama. Ese es el tipo de alternativa al Gantt de Redmine de la que trata este artículo: un diagrama que permanece dentro de Redmine pero que se puede editar, no una herramienta aparte.

Todo empieza con una buena visión general. Cuando responsables, fechas y duraciones están en una misma línea de tiempo del proyecto, puede leer el proyecto de un vistazo en lugar de reconstruirlo a partir de listas de incidencias. Este es un plan de lanzamiento de diez tareas en RedmineUP Planner, el plugin al que volveremos más adelante en este artículo.

Diagrama de Gantt de Redmine con la línea de tiempo del proyecto, las tareas y los miembros del equipo asignados

Obtenga una visión clara del cronograma, las tareas y las responsabilidades de su proyecto en un único diagrama de Gantt de Redmine.

Dependencias entre tareas: cómo un retraso desplaza todo el proyecto

La mayoría de los retrasos en los proyectos no se deben a un gran fallo. Se deben a un pequeño desvío en una tarea de la que otras dependen sin que nadie lo note.

Tomemos un lanzamiento de software habitual: Desarrollo backend → Integración → Pruebas de QA → Lanzamiento. El trabajo de backend estaba previsto para dos semanas y lleva tres. La integración no puede empezar hasta que el backend esté terminado, así que se desplaza. QA no puede empezar hasta que la integración esté completa, así que también se desplaza. La fecha de lanzamiento, prometida a un cliente el mes pasado, se mueve con ellas. Nadie cometió un error después del primer desvío. El cronograma simplemente hizo lo que las dependencias le obligan a hacer.

El daño es mayor cuando el desvío se descubre tarde. Si solo se entera de que la integración está bloqueada cuando el desarrollador de backend informa de que ha «terminado» con una semana de retraso, las opciones son limitadas. Si puede ver la cadena con antelación, puede sumar a una persona, recortar el alcance o ajustar las expectativas mientras todavía cuesta poco.

Por eso un jefe de proyecto debería entender las dependencias antes de cambiar un plazo o comprometerse con una entrega. Pregúntese «¿qué está esperando a esta tarea?» cada vez que se mueva una fecha. Las relaciones de Redmine le permiten registrar la respuesta, y un diagrama visual hace que se lea rápido.

En la captura de abajo, las flechas conectan cada tarea con las que dependen de ella. Una de ellas está dibujada en rojo. Aquí las pantallas de frontend están programadas de forma que entran en conflicto con la tarea de integración que les sigue. Un conflicto así es fácil de pasar por alto en una lista y evidente en una línea de tiempo, de modo que puede resolverse en una reunión de planificación en lugar de descubrirse en las pruebas.

Diagrama de Gantt de Redmine para la planificación de proyectos con dependencias entre tareas y conflictos de programación

Entienda cómo dependen unas tareas de otras e identifique los conflictos de programación antes de que afecten a la entrega del proyecto.

Ruta crítica en Redmine: qué tareas determinan la fecha de finalización

En cuanto puede ver las dependencias, surge una segunda pregunta. Si todo está conectado, ¿qué retrasos importan más?

La respuesta la da el método de la ruta crítica (CPM, Critical Path Method), una técnica estándar de programación de proyectos. La ruta crítica es la secuencia de tareas dependientes de mayor duración, que determina la fecha más temprana posible de finalización del proyecto. Las tareas de esta ruta tienen una holgura total de cero: un retraso en cualquiera de ellas desplazará la fecha de finalización del proyecto, a menos que el equipo actúe para recuperar el tiempo. Las tareas fuera de la ruta tienen algo de margen.

Ese margen se llama holgura (float), y hay dos tipos:

  • Holgura total (total float) es cuánto puede retrasarse una tarea sin retrasar la fecha de finalización del proyecto.
  • Holgura libre (free float) es cuánto puede retrasarse una tarea sin retrasar el inicio de la tarea que la sigue.

La holgura se cuenta en días laborables. Una tarea con 12 días de holgura total puede retrasarse 12 días laborables antes de que la fecha de finalización se vea afectada, siempre que no se mueva nada más en su cadena. Un valor negativo significa que el plan, tal como está programado, no puede cumplir su fecha de fin, o que se ha violado una dependencia, por ejemplo cuando una tarea termina más tarde de lo que permite su sucesora.

Por eso cambian las prioridades. Imagine dos incidencias, ambas marcadas como «Alta» en Redmine. Una es el trabajo de integración en la ruta crítica. La otra es la configuración de un entorno de staging del que no depende nada urgente. Si la integración se retrasa dos días, el lanzamiento se mueve dos días, salvo que el equipo recupere el tiempo en otro lugar. Si el entorno de staging se retrasa una semana, la fecha de lanzamiento no cambia. Las etiquetas de prioridad no pueden decirle esto, pero la ruta crítica sí. Sin ella, los equipos tienden a poner a sus mejores personas en las tareas más ruidosas o en las de vencimiento más próximo, en lugar de en las que controlan la entrega.

Redmine estándar no incluye análisis de ruta crítica, así que muchos equipos o bien prescinden del análisis o lo mantienen en una herramienta aparte que se queda desactualizada. En la captura, la cadena crítica aparece resaltada en rojo y cada tarea muestra un valor de holgura. Backend, integración, QA y el lanzamiento están en cero. El entorno de staging y el webinar para clientes tienen 12 días laborables de holgura. Las pantallas de frontend muestran un valor negativo: terminan más tarde de lo que permite la tarea siguiente, el mismo conflicto señalado en la captura anterior, y requiere atención.

Diagrama de Gantt de Redmine con la ruta crítica y la holgura de las tareas resaltadas

Identifique las tareas críticas que afectan directamente a la fecha de finalización de su proyecto y concentre los esfuerzos del equipo donde más importan.

Baselines del proyecto: una ejecución del plan medible

Incluso un plan bien construido tiene fecha de caducidad. Los requisitos cambian, las personas pasan a otros trabajos, un proveedor se retrasa. Cada cambio es pequeño y razonable, y cada uno se hace en su propia incidencia, en su propio día.

Al cabo de unos meses, el plan original ha desaparecido. Nadie recuerda cuáles eran las fechas aprobadas, y valorar cómo va la ejecución del plan se convierte en una cuestión de opinión. Uno dice que el proyecto va «una semana por detrás», otro dice «dos», y un responsable que tiene que explicar a un cliente por qué se ha movido la fecha de entrega no tiene una forma clara de mostrar dónde se fue el tiempo.

Una baseline (línea base) del proyecto resuelve esto. Una baseline es una instantánea guardada del cronograma aprobado. Registra las fechas de inicio y de vencimiento previstas, no las estimaciones, los asignados ni ninguna otra propiedad de la incidencia. Se mantiene sin cambios, y puede comparar el cronograma actual con ella en cualquier momento. En lugar de una vaga sensación de deriva, obtiene información concreta: qué tareas se movieron, en qué dirección y cuántos días.

Esto aporta tres cosas que a los equipos suelen faltarles:

  • Responsabilidad. El plan con el que todos se comprometieron queda registrado y no puede reescribirse discretamente.
  • Previsiones realistas. Un patrón de pequeños desvíos en un área es una señal temprana, y es más honesto que añadir un «colchón» al final.
  • Comunicación transparente. «El lanzamiento va cuatro días por detrás del plan aprobado, y estas son las tres tareas que lo han causado» es una conversación mejor con un patrocinador que «hemos tenido algunos problemas».

En la captura, el equipo guardó una baseline llamada «Initial plan» al inicio del proyecto. Una línea fina bajo cada barra marca la posición planificada originalmente, y una columna muestra cuántos días laborables se ha movido cada tarea. El entorno de staging está exactamente donde se planificó. La landing page va cinco días laborables más tarde, las pantallas de frontend seis y el despliegue del lanzamiento cuatro. Ese es el estado real del proyecto, en cifras, antes de que nadie tenga que adivinar.

Comparación con la baseline del proyecto en Redmine que muestra el cronograma de tareas previsto y el actual

Compare el cronograma actual de su proyecto con el plan original e identifique los retrasos antes de que se conviertan en problemas mayores.

Planificación colaborativa de proyectos: revise los cambios antes de aplicarlos

Planificar no es algo que un jefe de proyecto haga solo, por muy ordenado que se vea el diagrama. Un cambio en el cronograma rara vez es una edición privada. Cuando una tarea se mueve, afecta al desarrollador responsable, pero también a quien depende de ella, al tester que espera la build y al líder de equipo que asignó personas a esa semana.

Sin embargo, en muchos equipos los cambios de cronograma se producen como ediciones sin previo aviso. Alguien ajusta las fechas, se envían las notificaciones y todos los demás se enteran del nuevo plan por su bandeja de entrada. Es una mala forma de tomar una decisión que afecta a varias personas.

Un hábito más sano tiene cuatro partes:

  1. Un cambio se propone, no se aplica sin más.
  2. Las personas afectadas pueden ver exactamente qué cambiaría, incluidos los efectos en cadena sobre otras tareas.
  3. El jefe de proyecto revisa las consecuencias antes de aprobarlo.
  4. Solo entonces el nuevo cronograma pasa a ser el plan de trabajo.

Los equipos que trabajan así dedican menos tiempo a correcciones y reprogramaciones inesperadas. También construyen una comprensión compartida del plan actual, algo muy valioso cuando las personas trabajan en distintas zonas horarias o en distintos proyectos.

La captura muestra esta idea en la práctica. Planner dibuja flechas de dependencia y resalta las violaciones de programación. Cuando un cambio propuesto afecta a incidencias sucesoras, la tabla Review muestra los cambios de fecha resultantes antes de aplicarlos en Redmine. Aquí, un cambio propuesto en las pantallas de frontend espera en un Draft compartido, con las fechas antiguas y nuevas lado a lado y el nombre del autor. El diálogo también indica que, como resultado, Redmine movería la tarea de integración a final de mes. Todavía no se ha escrito nada en las incidencias reales, y el equipo puede decidir qué aplicar.

Interfaz de Draft compartido de Redmine Planner para revisar cambios en el cronograma del proyecto

Revise los cambios de cronograma propuestos y su impacto antes de aplicarlos a su proyecto de Redmine.

RedmineUP Planner: una alternativa al Gantt de Redmine para planificar proyectos

Todo lo anterior se puede hacer con disciplina, hojas de cálculo y mucha paciencia. RedmineUP Planner es un software de planificación de proyectos que reúne estas prácticas en un único flujo de trabajo dentro de Redmine, sobre las incidencias con las que su equipo ya trabaja. Planifica en un diagrama de Gantt editable donde las dependencias se dibujan como flechas y las violaciones se señalan. Los cambios propuestos esperan en un Draft compartido hasta que alguien los revisa y los aplica, y la ruta crítica, las baselines y los hitos de versión están en el mismo diagrama.

La ventaja práctica no es una función concreta. Los cambios de cronograma se vuelven más fáciles de discutir, revisar y gestionar en un solo lugar, y Redmine sigue siendo la fuente de verdad del trabajo en sí.

Planner combina el diagrama de Gantt editable, el Draft compartido con Review y Apply, las dependencias y Undo/Redo con funciones de planificación avanzadas: análisis de la ruta crítica con holgura total y libre, baselines con la columna de desviación, agrupación, columnas de consulta adicionales, colores de barras e hitos de versiones. Encontrará más detalles en la página de Planner y en la documentación.

Planner también funciona junto con el resto de la suite de RedmineUP. Los equipos que trabajan por sprints pueden mantener sus tableros en el plugin Agile, y los responsables que necesitan equilibrar la carga de las personas entre proyectos pueden añadir el plugin Resources. Para una visión más amplia de las opciones, consulte nuestra guía de los mejores plugins de Redmine para la gestión de proyectos o explore el directorio completo de plugins de Redmine.

Integre la planificación con Gantt en su flujo de trabajo de Redmine

Redmine es donde su equipo ya gestiona su trabajo. Con mejores prácticas de planificación, también puede ser el lugar donde planifique el cronograma, entienda las dependencias y siga la ejecución del plan, sin trasladar el plan a una herramienta aparte que nadie actualiza.

Si quiere empezar sin instalar nada, comience con un pequeño hábito. Elija un proyecto en curso y hágase las cinco preguntas del principio de este artículo. Cada una que no pueda responder con su configuración actual es una carencia en su planificación de proyectos. Esa lista es un buen punto de partida para hablar de lo que su equipo necesita a continuación.

Para los equipos que quieren ir más allá del simple seguimiento de tareas, RedmineUP Planner es el siguiente paso. Abra la demo en vivo, elija Planner y pruebe la ruta crítica, las baselines y la revisión del Draft con datos de ejemplo. Cuando esté listo, instale Planner en su propio Redmine (5.0 a 7.0).

Obtener RedmineUP Planner