EGA Futura » Capacitación y Soporte
Un hito es un punto de control dentro de un proyecto, y no una tarea más de la lista.
Marca que algo importante quedó terminado, como el cierre de una etapa o la aprobación de un entregable.
Su rasgo distintivo es que no consume tiempo ni recursos, porque representa un instante y no un trabajo.
Una tarea tiene duración, esfuerzo y alguien que la ejecuta.
Un hito tiene solo una fecha y un criterio de cumplimiento.
Por eso se cumple o no se cumple, sin estados intermedios ni porcentajes de avance.
Esa dureza es justamente su utilidad, porque obliga a definir de antemano qué significa terminado.
El primer uso es partir un proyecto largo en tramos verificables, que es lo que evita descubrir el retraso al final.
El segundo es sincronizar, porque un hito le avisa a otro equipo que ya puede arrancar.
El tercero es de comunicación hacia afuera, ya que un cliente entiende cinco hitos mucho mejor que doscientas tareas.
En proyectos contratados, buena parte de los hitos coincide con una condición de facturación.
Ahí el criterio de cumplimiento deja de ser un detalle de gestión y pasa a ser una cláusula.
Conviene entonces que el criterio quede escrito y sea verificable por las dos partes, y no sujeto a interpretación.
El error más común es marcar como hito cualquier cosa que parezca importante.
Con treinta hitos ninguno significa nada y el tablero vuelve a ser una lista de tareas.
La referencia práctica es entre cinco y diez por proyecto, o uno por cada etapa que alguien externo reconocería.
Cuando una fecha de hito se corre, lo que hay que registrar no es la fecha nueva sino el motivo.
Sin ese registro se pierde la única señal temprana que tiene un proyecto.
Y si un hito se mueve tres veces, el problema ya no es la fecha sino la estimación original.
El entregable es la cosa concreta que se produce, como un documento, un módulo o una capacitación dictada.
El hito es el momento en que ese entregable se da por aceptado.
Muchas veces van juntos, pero un hito puede depender de varios entregables a la vez.
Llevar esa trazabilidad dentro del mismo sistema donde se factura es lo que propone el ERP en la nube de EGA Futura.
Conviene decirlo de entrada: hoy no está construido un objeto de Hito en el ERP, ni una casilla que marque una tarea como tal.
Lo que sí está son las piezas con las que un hito se representa.
Un hito se carga como una Tarea de proyecto con fecha límite y sin horas estimadas.
La Tarea de proyecto tiene un campo Deadline de tipo fecha, y dos fórmulas que trabajan sobre él.
Una devuelve los días que faltan para esa fecha y la otra los días transcurridos desde el inicio.
Hay además una fórmula de solo lectura que marca la tarea como vencida, que es exactamente la señal que un hito necesita.
La tarea tiene Horas estimadas, Horas reales y un desvío calculado entre las dos.
Dejar esos campos vacíos es lo que distingue en la práctica un hito de una tarea de trabajo.
Así el hito no ensucia el cálculo de esfuerzo del proyecto.
Existe un objeto dedicado a relacionar dos tareas entre sí, con siete motivos de relación posibles.
Los motivos son Bloqueada por, Relacionada a, Duplicada de, Requiere, Parte de, Depende de y Precede.
Con Depende de y Precede alcanza para armar la secuencia previa a un hito, y con Bloqueada por se explica por qué no avanza.
La tarea suma además una casilla de bloqueo con su campo de motivo, que resuelve el caso simple sin crear una relación.
La Tarea de proyecto es el único objeto del ERP que tiene tipos de registro, y son dos.
La Tarea estándar usa los estados Planificada, En progreso y Completada.
La Tarea de implementación de plataforma usa Planificado, Diseño, Desarrollo, Testing, Deploy, Completado y Descartada.
Un hito conviene cargarlo como Tarea estándar, porque sus tres estados encajan con la lógica de cumplido o no cumplido.
El Proyecto tiene cinco campos de resumen que cuentan tareas totales, activas, completadas, en espera y participantes.
Tiene además tres campos calculados: porcentaje de avance, días restantes y salud del proyecto.
El campo Metodología ofrece Cascada, Scrum, Kanban e Híbrida, y es el que le da sentido al uso de hitos.
En Cascada los hitos son la columna vertebral, mientras que en Scrum su lugar lo ocupa el cierre de cada iteración.
Falta una casilla que identifique una tarea como hito, así que hoy la distinción es una convención de carga y no un dato.
Falta también un campo que guarde la fecha original comprometida junto a la vigente, que es lo que permitiría medir el corrimiento.
La aplicación de proyectos está en construcción activa, así que conviene releer la estructura antes de apoyarse en este detalle.
La tarea tiene duración, esfuerzo y responsable, mientras que el hito solo tiene una fecha y un criterio de cumplimiento.
Por eso una tarea puede estar al sesenta por ciento y un hito no.
El hito se cumple o no se cumple.
Entre cinco y diez por proyecto suele ser suficiente.
Con treinta hitos ninguno significa nada y el tablero vuelve a ser una lista de tareas.
El criterio práctico es uno por cada etapa que alguien externo al equipo reconocería.
Se corre la fecha y, sobre todo, se registra el motivo del corrimiento.
La fecha nueva sola no informa nada, y el motivo es la señal temprana del problema de fondo.
Tres corrimientos seguidos indican que el error estuvo en la estimación original.
Hoy se carga como una Tarea de proyecto con Deadline y sin horas estimadas ni horas reales.
Las tareas previas se enlazan con el objeto de relación usando los motivos Precede y Depende de.
No hay todavía una casilla que marque la tarea como hito, así que la distinción es una convención de carga.
Se recorrió el inventario de objetos personalizados de la organización y no existe un objeto de Hito ni de Milestone.
La única coincidencia de nombre en toda la organización es MilestoneDate, que pertenece al objeto EGAFutura__Gasto__c y no tiene relación con proyectos.
EGAFutura__Proyecto_Tarea_proyecto__c, etiquetado Tarea de proyecto, tiene 42 campos en total y 28 propios de EGA Futura.
EGAFutura__Proyecto__c es una relación principal-detalle obligatoria hacia el proyecto.
Son obligatorios además EGAFutura__Estado__c y EGAFutura__Prioridad__c.
EGAFutura__Deadline__c y EGAFutura__Fecha_inicio__c son de tipo fecha.
EGAFutura__Dias_Deadline__c, EGAFutura__Dias_transcurridos__c y EGAFutura__HoursVariance__c son fórmulas numéricas.
EGAFutura__IsOverdue__c es una fórmula de casilla y EGAFutura__StatusIndicator__c una fórmula de texto.
EGAFutura__Horas_estimadas__c y EGAFutura__ActualHours__c son numéricos de cuatro dígitos sin decimales.
Es la única excepción encontrada en toda la organización: los demás objetos no definen tipos de registro.
La Tarea estándar usa los estados Planificada, En progreso y Completada.
La Tarea de implementación de plataforma usa Planificado, Diseño, Desarrollo, Testing, Deploy, Completado y Descartada.
EGAFutura__ProjectTaskRelation__c tiene cuatro campos propios.
EGAFutura__ParentProjectTask__c es principal-detalle hacia la tarea y EGAFutura__RelatedProjectTask__c una búsqueda hacia la misma.
EGAFutura__RelationReason__c tiene siete valores, cuyas etiquetas son Bloqueada por, Relacionada a, Duplicada de, Requiere, Parte de, Depende de y Precede.
Los valores almacenados están en inglés: Blocked By, Related To, Duplicate Of, Requires, Part Of, Depends On y Precedes.
EGAFutura__Proyecto__c tiene 18 campos propios, con cinco campos de resumen y tres fórmulas.
Los resúmenes son EGAFutura__Cantidad_total_Tareas__c, EGAFutura__Tareas_activas__c, EGAFutura__Tareas_completadas__c, EGAFutura__Tareas_espera__c y EGAFutura__Participantes_proyecto__c.
Las fórmulas son EGAFutura__PercentComplete__c, EGAFutura__DaysRemaining__c y EGAFutura__Health__c.
EGAFutura__Methodology__c almacena Waterfall, Scrum, Kanban e Hybrid, con etiquetas Cascada, Scrum, Kanban e Híbrida.
No hay casilla ni lista de selección que identifique una tarea como hito.
Tampoco hay un campo de fecha comprometida original junto a EGAFutura__Deadline__c, así que el corrimiento de fechas no queda medido.
Todo lo anterior se verificó contra la organización de desarrollo el 9 de agosto de 2026.
El ERP está en construcción activa y van a aparecer objetos y campos nuevos.
Que un campo no exista hoy no prueba que no vaya a existir, así que conviene releer la estructura antes de apoyarse en este detalle.