Alternativa a Asana para la planificación de proyectos

Dónde la línea de tiempo de Asana deja de ser un cronograma

La mayoría de los artículos sobre una alternativa a Asana para la planificación de proyectos abren afirmando que Asana no tiene diagrama de Gantt. No es cierto, y partir de una premisa falsa es una mala manera de ayudar a nadie a elegir una herramienta. Asana tiene una vista de línea de tiempo que dibuja barras en un eje horizontal, las enlaza con flechas, marca los hitos como rombos y, si se le pide, puede resaltar la ruta crítica. Para una campaña, el lanzamiento de un producto o un proceso de contratación, es una forma perfectamente razonable de planificar.

La pregunta honesta es otra. No si el diagrama existe, sino si detrás de él hay un modelo de planificación, es decir, un conjunto de reglas que el sistema aplica cuando algo se mueve. Un diagrama sin modelo es una imagen de un plan. Un diagrama con modelo es un plan. La diferencia solo se ve cuando la realidad empieza a empujar contra las fechas, lo que suele ocurrir en la tercera semana, no el día en que se aprueba el plan.

Lo que Asana hace bien

Asana es realmente buena haciendo visible el trabajo y logrando que la gente actúe sobre él. Las tareas tienen responsables, comentarios y fechas de entrega claras, la línea de tiempo es fácil de manipular y las tareas dependientes se desplazan cuando su predecesora se mueve. Las dependencias se describen con un lenguaje que nadie necesita aprender, bloquea y bloqueada por, por lo que los equipos adoptan la herramienta en una tarde. Para diez personas que llevan una campaña de ocho semanas, eso no es un compromiso, es la cantidad justa de herramienta para el trabajo. Cualquier comparación que finja lo contrario vende en lugar de aconsejar.

Lo que vale la pena notar es dónde se paga esa simplicidad. Cada capacidad que Asana deja fuera de la línea de tiempo es una que habría hecho el producto más difícil de aprender, y para la mayoría de sus usuarios ese es el intercambio correcto. La pregunta es qué pasa con los equipos para los que no lo es.

El momento en que el plan deja de recalcularse solo

El punto de inflexión llega en silencio. Un proveedor confirma la entrega dos semanas más tarde de lo previsto y el jefe de proyecto mueve una tarea en la línea de tiempo. La sucesora inmediata la sigue, porque ese enlace se entiende. Luego el jefe advierte que la prueba de aceptación programada tras un periodo obligatorio de curado de dos semanas ahora empieza demasiado pronto, porque el intervalo entre esas tareas nunca fue una regla, solo espacio vacío en un diagrama. La tarea del proyecto vecino que debía empezar tras esta entrega no se mueve en absoluto, porque los dos proyectos no saben el uno del otro. Media hora después el jefe está arrastrando barras a mano y cotejando fechas con una hoja de cálculo.

Ese es el momento en que un cronograma deja de ser un modelo. El plan ya no es algo que mantiene el sistema, es algo que mantiene una persona, y esa persona se convierte en el único punto de fallo. Cada replanificación cuesta horas, cada hora de replanificación es una hora no dedicada al problema real, y tras la tercera o cuarta iteración la gente deja de actualizar el plan por completo porque el esfuerzo ya no compensa. Un plan abandonado es peor que ningún plan, porque los informes se siguen generando a partir de él.

Cinco señales de que has superado la planificación de Asana

Ninguna de estas señales tiene que ver con el tamaño del equipo ni con el presupuesto. Tienen que ver con la forma del trabajo, por lo que un equipo de ingeniería de doce personas puede toparse con ellas mientras un departamento de marketing de sesenta nunca lo hace. Si dos o más describen tus proyectos, tu limitación es la capa de planificación, no el número de funciones.

Planificas en días laborables, no en días naturales. Una tarea de cinco días que empieza el jueves debería terminar el miércoles siguiente, y un festivo en medio debería empujar el final un día más. Si tus duraciones incluyen fines de semana en silencio, cada estimación carga un error incorporado que se acumula a lo largo de un plan de varios meses.

Algunos intervalos de tu plan son física, no preferencia. El hormigón fragua, los recubrimientos secan, corre un periodo de validación, expira un plazo de preaviso, un regulador tiene treinta días para responder. No son tareas que alguien ejecute, son intervalos que deben transcurrir entre dos tareas. Los equipos sin forma de expresarlos inventan tareas de relleno llamadas «esperando aprobación», lo que contamina la lista de tareas y desorienta cada informe construido sobre ella.

El cronograma de un proyecto impulsa el de otro. En el momento en que una entrega del proyecto de infraestructura condiciona el inicio del proyecto de migración, y ambos se gestionan por separado, alguien mantiene esa dependencia en su memoria. La memoria no envía notificaciones y no sobrevive a las vacaciones.

Te preguntan cuánto se ha desviado el proyecto del plan original. No cuáles son las fechas actuales, sino cómo se comparan con lo que se aprobó, y por qué. Sin una línea base guardada la respuesta honesta es que nadie lo sabe, y la versión que circula en la presentación del comité de dirección es una reconstrucción.

El cronograma necesita más de dos niveles. Fases que contienen etapas que contienen tareas, con el progreso sumándose automáticamente hacia arriba y con fechas propias en cada nivel. Una lista plana con encabezados de sección parece similar en pantalla y se comporta de forma completamente distinta cuando el plan cambia.

Tipos de dependencia y por qué su semántica decide el plan

Una dependencia no es una línea trazada entre dos barras. Es una regla que el sistema aplica cada vez que se mueve cualquiera de los extremos, y el tipo de relación es el contenido de esa regla. Esta es la parte que la mayoría de las comparaciones de herramientas se salta, porque una tabla con una marca junto a «dependencias de tareas» oculta la diferencia entre un sistema que redibuja flechas y un sistema que recalcula fechas. Tanto FlexiProject como Asana admiten los cuatro tipos estándar, así que la pregunta interesante es qué los rodea.

Acertar con la semántica no es precisión por la precisión. Decide si un jefe de proyecto responde a la pregunta «si esto se retrasa una semana, ¿cuándo terminamos?» en tres segundos mirando el diagrama, o en tres horas reconstruyendo el plan. Donde varios proyectos compiten por las mismas personas, esa diferencia decide si la replanificación llega a ocurrir.

FS, SS, FF y SF en la práctica

Fin a inicio es el valor por defecto en todas partes y cubre la mayor parte del trabajo secuencial: hay que construir el muro antes de pintarlo. Inicio a inicio describe trabajo que corre en paralelo desde un disparador común, por ejemplo la documentación que empieza en el momento en que empieza el desarrollo y se mantiene más o menos a la par. Fin a fin describe trabajo que debe aterrizar junto, como la formación de usuarios que tiene que estar completa el día en que el sistema entra en producción, sin importar cuándo empezó. Inicio a fin es raro y aparece sobre todo en traspasos, donde el sistema antiguo solo puede apagarse una vez que el nuevo está funcionando.

Quien construye cronogramas en serio usará al menos los tres primeros, y las organizaciones de proyectos maduras usan los cuatro para modelar la realidad con precisión en lugar de forzarlo todo a una cadena de enlaces fin a inicio. Si quieres un recorrido más profundo con ejemplos trabajados, hemos escrito por separado sobre los tipos de dependencias de tareas en un diagrama de Gantt.

Retraso fijo: los días que simplemente deben pasar

En FlexiProject, cada relación puede llevar un retraso fijo expresado en días. La dependencia significa entonces «empieza esta tarea cuatro días después de que termine la anterior», y esos cuatro días forman parte de la regla en lugar de ser un intervalo que alguien calculó a ojo en el diagrama. Cuando la predecesora se mueve, el retraso se mueve con ella, de forma automática y sin que nadie recuerde que estaba ahí.

El efecto de negocio es que las restricciones tecnológicas dejan de vivir en la cabeza de la gente. Un periodo de curado, una ventana de revisión regulatoria, una cuarentena obligatoria entre lotes de producción o un plazo de preaviso contractual pasa a formar parte de la lógica del plan. Nadie tiene que crear una tarea falsa para mantener el espacio abierto, nadie tiene que explicar a un colega por qué dos barras no deben juntarse, y ninguna replanificación puede eliminar en silencio una restricción que impone la física o un contrato. En proyectos donde una secuencia incumplida significa rehacer trabajo y no un correo tardío, esta es la diferencia entre un plan en el que puedes confiar y un plan que tienes que verificar dos veces.

Relaciones duras: cuando el enlace no debe romperse

FlexiProject distingue además las relaciones duras, marcadas en el panel de la tarea con dos anillos entrelazados. Una relación dura significa que el elemento enlazado no puede arrastrarse a mano lejos de su predecesor. El sistema no permitirá que un usuario rompa la secuencia en silencio moviendo una barra en el diagrama, lo que suena restrictivo hasta que has visto un cronograma degradarse a lo largo de seis meses de ajustes manuales bienintencionados.

Esto importa sobre todo donde un cronograma es un documento compartido y no el archivo de una sola persona. En un proyecto grande varias personas editan el plan, y cada una tiene un motivo local para mover algo. Una relación dura codifica la diferencia entre una secuencia que es un supuesto de planificación, y por tanto abierta a discusión, y una secuencia que es una restricción dura, y por tanto no. El jefe de proyecto deja de vigilar el plan a mano y empieza a confiar en él, que es todo el sentido de un software de planificación desde el principio.

Dependencias entre proyectos: la capa que Asana no tiene

Dentro de un solo proyecto, las dependencias son una comodidad. Entre proyectos, son la diferencia entre un programa y una carpeta de planes inconexos. En FlexiProject una relación puede conectar una tarea de un proyecto con una tarea de otro, de modo que la entrega de infraestructura que condiciona una migración es un enlace que el sistema conoce y no una nota en el acta de reunión de alguien. Cuando la fecha de un lado se mueve, las tareas dependientes del otro proyecto se recalculan y se notifica a sus responsables.

La consecuencia práctica se ve en la toma de decisiones, no en el diagrama. Antes de aprobar un cambio en un proyecto, un gestor de programa puede ver cómo ese cambio se propaga por los proyectos restantes, comparar el cronograma antes y después y juzgar el coste real de decir que sí. Sin eso, el coste aflora semanas después como una serie de sorpresas separadas, cada una de las cuales parece un problema local y se trata como tal. Los programas plurianuales son justo donde esto se acumula, porque una decisión de dos semanas tomada a la ligera en el tercer mes puede mover una fecha de puesta en marcha en el mes veinte.

Todas las tareas de un programa son además visibles en un único diagrama de Gantt compartido, de modo que un gestor de programa ve las conexiones en un solo lugar en vez de reconstruirlas a partir de informes de estado. Los equipos que necesitan esto suelen descubrirlo por las malas, tras haber intentado primero coordinar lo mismo con una reunión recurrente. Si tu organización va en esa dirección, nuestro software para gestionar programas de proyectos explica cómo se estructuran los programas.

El modelo bajo el diagrama de Gantt

Las relaciones son la parte más visible del modelo de planificación, pero no son todo el modelo. Otros cuatro mecanismos deciden si un diagrama se comporta como un plan, y son los que separan un software de diagrama de Gantt de un widget de línea de tiempo. Ninguno de ellos es exótico. Todos son de esas cosas que solo echas de menos cuando las necesitas.

EDT ilimitada y progreso que se suma solo

Los proyectos de una organización varían enormemente en escala, desde una victoria rápida de dos semanas hasta una inversión de capital de varios años, y una única estructura rígida no puede servir a ambos. FlexiProject no pone límite a la profundidad de la estructura de tareas, así que un proyecto puede dividirse en fases, etapas, tareas e hitos tan abajo como haga falta. Un proyecto pequeño puede quedarse plano con un puñado de tareas, mientras que un proyecto de inversión puede llevar una estructura de descomposición del trabajo de varios niveles, y ambos usan la misma interfaz.

El progreso se introduce solo a nivel de tareas individuales. El progreso de etapa y el progreso general del proyecto se calculan automáticamente a partir de las tareas que hay debajo, así que nadie tiene que acordarse de actualizar los agregados antes de que salga un informe. Suena a comodidad menor y en realidad es un mecanismo de calidad de datos: el estado a nivel de cartera se deriva de los mismos números que el equipo mantiene a diario, y no de un resumen que alguien tecleó con prisas la víspera de un comité de dirección.

Un calendario laboral en lugar de fechas naturales sin más

Un cronograma que cuenta los fines de semana como tiempo de trabajo produce fechas equivocadas desde el primer día. FlexiProject calcula las duraciones contra un calendario laboral, así que una tarea expresada en días laborables aterriza donde realmente aterriza una vez tenidos en cuenta los fines de semana y los festivos. La misma lógica sustenta las plantillas reutilizables: las tareas de una plantilla guardan una duración en días laborables y un conjunto de dependencias en lugar de fechas fijas, así que introducir una fecha de inicio del proyecto genera todo el cronograma automáticamente.

Para una organización que ejecuta proyectos similares de forma repetida, aquí es donde el tiempo de planificación se desploma. En lugar de reconstruir un plan desde cero y volver a derivar cada fecha, un jefe de proyecto parte de una estructura aprobada y ajusta lo que de verdad es distinto en este caso. Nuestro módulo de plantillas de proyecto existe justo para este patrón, y también es la razón por la que las plantillas creadas por una PMO experimentada conservan su valor durante años.

Línea base y desviación respecto al plan

Una vez aprobado un plan, FlexiProject lo guarda como línea base. El diagrama de Gantt muestra entonces el plan original junto al cronograma actual, de modo que cada desviación es visible de inmediato en vez de deducirse. El sistema también pronostica la fecha de finalización del proyecto frente a la aprobada, que suele ser el único número que un consejo de dirección quiere de verdad.

El valor aquí tiene menos que ver con la medición que con la calidad de la conversación. Un jefe de proyecto que puede mostrar qué se aprobó, cuál es la situación ahora y qué decisión causó la brecha está en una posición distinta que uno que solo puede informar de las fechas actuales. La discusión pasa de si el proyecto va tarde a qué hacer con la causa concreta, que es la única versión de esa conversación que termina en una decisión.

Ruta crítica y holgura

FlexiProject identifica la ruta crítica automáticamente y la marca en rojo en el diagrama de Gantt, así que un jefe de proyecto sabe de inmediato qué tareas merecen atención. El uso práctico está en el triaje. Un desliz de dos días en una tarea crítica es un desliz de dos días para todo el proyecto, mientras que un desliz de dos días en una tarea con diez días de holgura es ruido. Sin esa distinción cada retraso se escala con la misma urgencia, lo que enseña a todos a ignorar los escalados.

Con varios flujos en paralelo, por ejemplo obra corriendo junto a montaje y documentación, la ruta crítica es lo que impide a un gestor optimizar la equivocada. Si el concepto es nuevo para tu equipo, hemos cubierto con más profundidad qué es la ruta crítica y cómo gestionarla.

Recursos en el diagrama de Gantt: tiempo y capacidad planificados juntos

Un cronograma que ignora quién está disponible es una lista de deseos. FlexiProject muestra la carga de recursos directamente desde el diagrama de Gantt, así que un jefe de proyecto ve de un vistazo qué personas están sobrecargadas en un periodo dado y cuáles aún tienen capacidad. Las tareas pueden moverse a lo largo de la línea de tiempo mientras se observa cómo cambia la carga, lo que convierte la replanificación en una simulación en vez de una conjetura: el plan se optimiza antes de aprobarse, no después de que alguien se queje.

Esto cierra una brecha que aparece constantemente en organizaciones que llevan varios proyectos con las mismas personas. Planificar un proyecto nuevo significa saber si los especialistas que necesita ya están comprometidos en otro sitio, y en la mayoría de las empresas esa comprobación se hace a mano, en una hoja de cálculo, con un retraso lo bastante largo como para dejar la respuesta obsoleta. Cuando la capacidad está en la misma vista que las fechas, el intercambio entre terminar antes y sobrecargar a un equipo deja de ser invisible hasta que alguien dimite.

Los retrasos afloran con la misma franqueza. Las tareas que se han quedado atrás se resaltan en rojo, así que abrir el proyecto basta para ver dónde hace falta intervenir, sin generar antes un informe. Para organizaciones que quieren ir más allá y gestionar la disponibilidad en toda la cartera, nuestro software de gestión de recursos maneja la carga más allá de un solo proyecto.

FlexiProject y Asana: comparación de las capacidades de planificación

La tabla siguiente es deliberadamente estrecha. Cubre solo la planificación y le concede a Asana cada capacidad que realmente tiene, porque una comparación que subestima a un competidor es inútil para quien la lee. La colaboración, la automatización de flujos y las integraciones son otra conversación, y en varias de ellas Asana es el producto más fuerte.

Lee la tabla como una descripción de intención y no como un marcador. Asana está construida para que cualquiera pueda planificar sin formación, y cada capacidad de arriba que omite es una que haría el producto más difícil de aprender. FlexiProject acepta un arranque algo más empinado a cambio de un cronograma que mantiene su forma bajo presión. Qué intercambio es el correcto depende por completo de si tus proyectos castigan un plan impreciso.

Sacar un cronograma de Asana sin perder el plan

La parte mecánica de una migración lleva menos tiempo del que la gente espera. Un cronograma se importa desde un archivo de Excel o un archivo de Microsoft Project, trayendo tareas, responsables, atributos disponibles y, cuando existe, la estructura de dependencias, así que las organizaciones sentadas sobre años de planes históricos no tienen que reteclearlos. Las exportaciones van en sentido contrario a Excel, Microsoft Project XML, PDF y PNG, lo que importa cuando un contratista o un auditor insiste en un formato concreto.

La parte que merece verdadera reflexión es la remodelación. Un plan construido en Asana se construyó bajo las restricciones de Asana, lo que significa que los periodos de espera son probablemente tareas falsas, la secuencia es probablemente una cadena de enlaces fin a inicio y la estructura de fases son probablemente encabezados de sección. Copiar eso con fidelidad reproduce la limitación en un sistema que ya no la tiene. El mejor enfoque es tomar un proyecto representativo, reconstruir su lógica como es debido con los tipos de relación adecuados, retrasos fijos donde los intervalos son obligatorios y relaciones duras donde la secuencia no es negociable, y usar el resultado como plantilla para todo lo que venga.

Para la primera pasada hay un atajo que conviene conocer. FlexiProject puede generar un borrador de cronograma a partir de una descripción de los objetivos y requisitos del proyecto, produciendo tareas, hitos, dependencias y un diagrama de Gantt que un jefe de proyecto edita después en vez de construir desde cero. No sustituirá el criterio de un planificador experimentado, pero elimina el problema de la página en blanco, donde encallan la mayoría de los esfuerzos de replanificación. Para un recorrido estructurado, hemos escrito sobre cómo construir un cronograma de proyecto paso a paso.

Preguntas frecuentes

¿Admite Asana los cuatro tipos de dependencia?

Sí. Asana admite fin a inicio, fin a fin, inicio a inicio e inicio a fin, con fin a inicio por defecto. Las afirmaciones de que Asana solo ofrece un tipo de dependencia aparecen en varios artículos de comparación y están desactualizadas. Las carencias relevantes en la planificación de Asana están en otro sitio: en los retrasos fijos, las relaciones duras, los calendarios laborales, las líneas base y los enlaces entre proyectos.

¿Se puede fijar un tiempo de retraso entre tareas en Asana?

No. Asana no permite adjuntar un retraso fijo a una dependencia, así que un intervalo obligatorio entre dos tareas hay que representarlo de otro modo, normalmente con un hueco vacío en la línea de tiempo o una tarea de relleno. Ambos apaños se rompen en cuanto la predecesora se mueve, porque ninguno lleva el retraso consigo. En FlexiProject el retraso es una propiedad de la propia relación y se expresa en días.

¿Tiene Asana una línea base de proyecto?

No. Asana no guarda una versión aprobada del cronograma para comparar, así que no hay forma integrada de ver cuánto se ha desviado el plan actual de lo que se acordó al principio. Los equipos que lo necesitan suelen guardar una instantánea en una hoja de cálculo, que responde la pregunta una vez y luego queda obsoleta. FlexiProject conserva el plan aprobado como línea base y lo muestra junto al cronograma actual en el diagrama de Gantt.

¿Se pueden enlazar tareas de dos proyectos distintos?

En Asana no. Las dependencias se quedan dentro de un solo proyecto, así que una secuencia entre proyectos tiene que coordinarla la gente en lugar de mantenerla el sistema. FlexiProject permite una relación entre tareas que pertenecen a proyectos distintos, recalcula las fechas dependientes cuando cualquiera de los lados se mueve y notifica a los responsables afectados, que es el requisito básico para gestionar un programa y no un conjunto de proyectos en paralelo.

¿Es FlexiProject más difícil de usar que Asana?

Pide más al principio y menos después. Asana está diseñada para que alguien pueda planificar en su primer día, en parte dejando fuera los conceptos descritos en este artículo. FlexiProject espera que un jefe de proyecto entienda los tipos de relación, los calendarios laborales y las líneas base, y a cambio mantiene el plan en vez de pedirle a una persona que lo mantenga. Los equipos con proyectos sencillos encontrarán Asana más rápida. Los equipos cuyos proyectos castigan un plan inexacto suelen encontrar lo contrario.

Elegir una alternativa a Asana para la planificación de proyectos no es en realidad una elección entre dos herramientas. Es una decisión sobre si tus proyectos necesitan un plan que mantiene una persona o un plan que mantiene un sistema, y eso depende de lo caro que resulte que las fechas estén mal. Si una fecha corrida significa una reunión reprogramada, Asana es una buena respuesta y añadir maquinaria de planificación solo frenaría al equipo. Si una fecha corrida significa contratistas parados, una ventana regulatoria perdida, rehacer trabajo en una línea de producción o una cláusula de penalización, entonces el modelo bajo el diagrama no es un detalle. Es el producto.

Lo que cambia con un modelo de planificación completo es más pequeño de lo que sugiere una lista de funciones y más grande de lo que parece. Las relaciones llevan retrasos fijos, así que los intervalos obligatorios forman parte del plan en vez de la memoria de alguien. Las relaciones duras sostienen secuencias que no están abiertas a negociación. Las dependencias alcanzan varios proyectos, así que un programa se comporta como un programa. Un calendario laboral hace que las duraciones signifiquen lo que dicen, una línea base hace visible la desviación y la ruta crítica dice qué retrasos importan de verdad. Por separado parecen refinamientos. Juntos son la diferencia entre replanificar en minutos y replanificar durante un fin de semana.

Si quieres ver los dos productos uno al lado del otro en todo su alcance y no solo en el cronograma, incluyendo presupuestos, riesgos, actas de constitución de proyecto y gobernanza de cartera, hemos preparado una comparación detallada de FlexiProject y Asana. Y si tus proyectos ya están empujando contra los límites descritos aquí, el paso siguiente más útil es tomar uno de ellos, reconstruir su cronograma como es debido y ver cuánto trabajo manual desaparece.