EGA Futura » Capacitación y Soporte
Un proyecto es una lista de cosas por hacer hasta que alguien decide quién las hace.
Esa decisión es la asignación de recursos, y es el punto donde la planificación toca la realidad.
La palabra recurso suena fría, pero en la enorme mayoría de los proyectos los recursos son personas, con su jornada, su especialidad y sus otros compromisos.
Lo primero que se asigna es gente, porque es lo escaso y lo que decide el ritmo.
Después vienen los equipos y las máquinas, que se comparten entre tareas y a veces entre proyectos distintos.
Y por último los espacios y las ubicaciones físicas, que en obras, plantas y talleres condicionan qué se puede hacer en paralelo.
Los tres compiten por lo mismo, que es el calendario.
Asignar sería trivial si cada persona hiciera una sola cosa por vez y si las tareas no dependieran unas de otras.
En la práctica ocurre lo contrario: las dependencias mandan y una tarea que espera a otra deja ociosa a la persona asignada.
Por eso una asignación razonable no arranca por la lista de personas sino por el orden en que las tareas se destraban.
Primero se entiende qué bloquea a qué, y recién después se reparte.
El primero es la sobreasignación, que aparece cuando la misma persona figura en tareas simultáneas que suman más horas de las que tiene el día.
Es un error silencioso, porque en el plan todo cierra y solo se descubre cuando las fechas empiezan a correrse.
El segundo es el cuello de botella por especialidad, que se da cuando una sola persona sabe hacer algo que muchas tareas necesitan.
Ahí el problema no se arregla asignando mejor sino repartiendo el conocimiento, que es una decisión de otro orden.
No se puede asignar bien lo que no se estimó, aunque sea de manera gruesa.
La estimación en horas de trabajo es la unidad más útil, porque se compara directamente contra la disponibilidad real de cada persona.
Lo que vuelve valiosa a esa estimación no es acertar sino compararla después con lo que llevó de verdad.
Esa diferencia entre lo estimado y lo real es el mejor insumo para la siguiente planificación.
Una asignación no es un contrato, es una hipótesis sobre cómo va a andar el proyecto.
Cuando una tarea se bloquea, lo sano es registrar el motivo del bloqueo y mover a la persona a otra cosa mientras tanto.
Un proyecto que nunca reasigna suele ser un proyecto donde nadie está mirando el avance real.
La asignación ocurre en dos niveles, y conviene distinguirlos porque responden preguntas distintas.
El nivel del Proyecto define quiénes forman parte del equipo, y el nivel de la Tarea de proyecto define quién se ocupa de cada cosa concreta.
El Participante del proyecto es el registro que vincula a una persona con un proyecto.
Cada participante guarda la persona y el proyecto al que pertenece, y esa relación es de dependencia: el participante vive dentro del proyecto y no existe por fuera de él.
El Proyecto muestra a su vez un contador de Participantes del proyecto, que se actualiza solo a medida que el equipo se arma.
La Tarea de proyecto tiene dos campos de persona y no cumplen la misma función.
El Usuario asignado es quien hace el trabajo, y el Supervisor es quien lo revisa.
La tarea registra además su Ubicación, que es el lugar donde se ejecuta, y su Área funcional a nivel del proyecto, que ubica el trabajo dentro de la organización.
Cada tarea guarda sus Horas estimadas y sus Horas reales, y el sistema calcula solo el Desvío de horas entre ambas.
Ese desvío es el dato que convierte la asignación en algo medible en lugar de una impresión.
La tarea lleva también Gastos estimados, para el costo que no es tiempo de trabajo.
La tarea tiene una casilla Tarea bloqueada y un campo de texto para la Razón del bloqueo.
Existe además la casilla No programar, para dejar fuera del cronograma lo que por ahora no corresponde asignar.
Las relaciones entre tareas se registran con motivos explícitos como Bloqueada por, Depende de, Requiere y Precede, que son los que explican en qué orden se puede repartir el trabajo.
El Proyecto calcula solo su porcentaje de avance, sus días restantes y un indicador de salud del proyecto.
Y lleva contadores separados de tareas activas, completadas y en espera, que juntos muestran si el equipo está avanzando o esperando.
Cada tarea tiene su Prioridad, con los valores Crítica, Alta, Normal y Baja, y Normal como valor por omisión.
Asignar una tarea es decir quién la hace, y asignar un recurso es verificar que esa persona tenga el tiempo para hacerla.
La segunda mirada es la que evita que el plan se llene de compromisos imposibles.
Las tareas cercanas conviene asignarlas con nombre y apellido, porque su contexto ya se conoce.
Las lejanas suelen dejarse sin persona hasta que se acercan, para no comprometer a alguien que quizá ya no esté disponible.
Las salidas son tres: correr una tarea en el tiempo, pasarla a otra persona o reducir su alcance.
Comparar las horas estimadas de las tareas simultáneas es la forma más directa de detectar el problema antes de que ocurra.
Sirve para lo siguiente, no para lo actual: la comparación entre lo estimado y lo real es lo que mejora la próxima estimación.
Sin ese registro, cada proyecto vuelve a estimar desde cero y repite los mismos errores.
El vínculo entre una persona y un proyecto se guarda en EGAFutura__Participante_proyecto__c.
Sus dos campos propios son EGAFutura__Persona__c, un Lookup a User, y EGAFutura__Proyecto__c, una relación Master-Detail con el proyecto.
Su campo Name es un Auto Number, así que el registro no se nombra a mano.
La tarea es EGAFutura__Proyecto_Tarea_proyecto__c, hija de Proyecto por Master-Detail.
Las personas se guardan en EGAFutura__Usuario_asignado__c y EGAFutura__Supervisor__c, los dos Lookup a User.
El lugar es EGAFutura__Ubicacion__c, Lookup a Ubicación, y el bloqueo se maneja con EGAFutura__Tarea_bloqueada__c y EGAFutura__Razon_bloqueo__c.
La exclusión del cronograma es EGAFutura__DoNotProgram__c, de tipo Checkbox.
Son EGAFutura__Horas_estimadas__c y EGAFutura__ActualHours__c, los dos Number de cuatro dígitos sin decimales.
El desvío es EGAFutura__HoursVariance__c, una fórmula, por lo tanto de solo lectura.
El costo estimado es EGAFutura__Gastos_estimados__c, de tipo Currency con dos decimales.
El objeto EGAFutura__Proyecto__c expone cinco resúmenes y tres fórmulas, todos de solo lectura.
Los resúmenes son EGAFutura__Participantes_proyecto__c, EGAFutura__Cantidad_total_Tareas__c, EGAFutura__Tareas_activas__c, EGAFutura__Tareas_completadas__c y EGAFutura__Tareas_espera__c.
Las fórmulas son EGAFutura__PercentComplete__c, EGAFutura__DaysRemaining__c y EGAFutura__Health__c.
El campo EGAFutura__Area_funcional__c del proyecto es obligatorio, igual que EGAFutura__Descripcion__c y EGAFutura__Estado__c.
En EGAFutura__Prioridad__c de la tarea la etiqueta coincide con el valor almacenado, tilde incluida en Crítica, y el valor por omisión es Normal.
En EGAFutura__Estado__c de la tarea no siempre coinciden, porque el objeto tiene dos tipos de registro con juegos de estados disjuntos.
El tipo Standard expone Planificada, En progreso y Completada, con valor igual a la etiqueta.
El tipo PlatformImplementation expone Planificado, Diseño, Desarrollo, Testing, Deploy, Completado y Descartada, y ahí los valores almacenados son Planned, Design, Development, Testing, Deploy, Completed y Discarded.
La trampa está en que los dos juegos se distinguen a simple vista solo por la vocal final de la etiqueta, así que cualquier filtro conviene escribirlo contra el valor almacenado.
Los motivos de relación entre tareas viven en EGAFutura__ProjectTaskRelation__c, campo EGAFutura__RelationReason__c, y ahí las siete etiquetas están en español pero los valores almacenados van en inglés: Blocked By, Related To, Duplicate Of, Requires, Part Of, Depends On y Precedes.