Gestión de tareasciclo de vida

Estados, reasignación y fallo

¿Cómo funcionan realmente los estados, la reasignación y el fallo de las tareas?

Los estados de las tareas proceden de valores configurables y cambian con permisos concedidos; el porcentaje completado y la fecha real se registran a medida que avanza el trabajo. La reasignación es una autorización explícita – la permite quien asigna y se ejerce con notas – y el fallo es una rama documentada, no una fila eliminada.

La secuencia

4 pasos
  1. La tarea se crea y se asigna

    El registro se abre con quien asigna, la persona asignada, las fechas y la prioridad, y aparece en las listas de tareas de ambas partes.

  2. El estado cambia con permiso

    Quienes tienen el permiso concedido actualizan el estado a partir de valores configurados, y el porcentaje completado refleja el avance.

  3. Reasignar donde esté permitido

    Si se concedió «puede reasignar», la persona asignada pasa la tarea a otro empleado con notas; «puede volver a reasignar» rige los saltos posteriores.

  4. Completar o marcar como fallida

    Al completarse se registra la fecha real; el fallo registra una descripción con documentos, y en ambos casos la tarea permanece en el registro de tareas.

Cómo funciona

Los valores de estado son elementos configurables de una lista de valores, no un conjunto fijo programado en el código, y actualizar el estado de una tarea es una acción sujeta a permisos vinculada al recurso del gestor de tareas. El porcentaje completado refleja el avance en el registro, y al completarse la tarea se anota la fecha real junto a la fecha de vencimiento original.

La reasignación se controla con tres indicadores explícitos: quien asigna decide si la persona asignada puede reasignar, la persona asignada reasigna a un empleado elegido con notas de reasignación, y un indicador «puede volver a reasignar» determina si la cadena puede continuar. Una tarea también puede llevar un indicador de seguimiento, que mantiene vinculado a un observador sin transferir la titularidad. La vista de flujo presenta el historial de la tarea, de modo que el recorrido desde la creación hasta el titular actual se puede leer.

La rama de fallo refleja la del proyecto: una tarea se marca como fallida con una descripción del fallo, los documentos del fallo se adjuntan como prueba y la tarea permanece en el registro de tareas. La eliminación está protegida – una tarea con tareas hijas se comprueba antes de poder eliminarse.

Conviene saber

  • Valores de estado configurablesLos estados se basan en listas de valores por organización, de modo que el vocabulario del ciclo de vida coincide con cómo la empresa nombra realmente sus etapas.
  • Autorizaciones explícitas de reasignación«Puede reasignar», «reasignar a» con notas y «puede volver a reasignar» son indicadores registrados por separado, no un botón de transferencia libre.
  • Historial del flujo de la tareaLa vista de flujo muestra la evolución de la tarea, de modo que quién la tuvo y qué cambió se lee en el registro, no se reconstruye.
  • Rama de fallo documentadaLas tareas fallidas conservan una descripción del fallo y los documentos adjuntos en lugar de eliminarse o reetiquetarse.
  • Eliminación protegidaAntes de poder eliminar una tarea se comprueba si tiene tareas hijas, lo que protege las jerarquías de subtareas huérfanas.

Vea estados, reasignación y fallo en funcionamiento en continON.

Una demostración guiada en un entorno de demostración anonimizado – esta funcionalidad dentro de su módulo, en la plataforma compartida.