El viernes pueden quedar varias dudas distintas: una reunión que no aparece, dos sesiones parecidas y una hora anotada en una incidencia demasiado genérica. Revisarlas por separado ayuda a decidir qué corregir y qué necesita una aclaración.
1. Define el periodo y la persona que revisas
Escribe la fecha inicial y el primer día fuera del periodo. Si cierras antes del viernes, incluye solo los días transcurridos. Conserva el mismo criterio de zona horaria en tus referencias y en Jira.
Usa tu jornada real como referencia: las pausas, vacaciones, festivos o jornadas reducidas no son huecos que deban rellenarse con trabajo inventado. La guía no establece una obligación de horas ni un criterio de facturación.
2. Localiza las incidencias y abre sus worklogs
La documentación de Atlassian permite buscar incidencias con trabajo registrado dentro de un intervalo. Este ejemplo cubre del lunes 28 de septiembre al viernes 2 de octubre de 2026:
worklogDate >= "2026-09-28" AND worklogDate < "2026-10-03"JQL devuelve incidencias. Abre Actividad > Work log y comprueba autor, fecha de inicio y duración de las entradas concretas. El tiempo acumulado de una incidencia puede incluir otros autores y otros periodos.
Si una incidencia contiene más de 1.000 worklogs, las búsquedas JQL relacionadas solo consideran los más recientes; revisa su vista o una exportación autorizada si necesitas entradas anteriores. Los permisos también pueden limitar lo que ves.
3. Compara cada día con sus referencias
Reúne calendario, notas y tareas trabajadas. Si usas Clockify, sus registros son una referencia opcional. Una reunión del calendario solo aporta contexto: confirma que ocurrió, qué trabajo representa y dónde corresponde registrarla.
Comprueba cobertura, incidencia, inicio, duración y descripción. Una coincidencia en el total puede ocultar una ausencia compensada por un duplicado. Para dos entradas parecidas, compara sus campos antes de borrar.
Una semana ficticia: tres decisiones diferentes
La tabla es una lista de comprobaciones, no una recomendación de corregir automáticamente. El viernes se trabajaron seis horas; ese día no necesita llegar a ocho.
| Día | Registrado | Hallazgo | Decisión tras comprobar |
|---|---|---|---|
| Lunes 28 | 8 h | Sin diferencias en el ejemplo | Conservar las entradas verificadas |
| Martes 29 | 7 h 30 min | Reunión de 30 min ausente | Añadir solo si se confirma que ocurrió y no está registrada |
| Miércoles 30 | 8 h 45 min | Dos registros de 45 min del mismo trabajo | Eliminar uno solo si se confirma el doble registro |
| Jueves 1 | 8 h | 1 h con contexto insuficiente | Mantener pendiente hasta aclarar la incidencia o la descripción |
| Viernes 2 | 6 h | Jornada real de seis horas | Conservar; no completar hasta ocho por costumbre |
El total inicial es 38 h 15 min. Si se confirma la reunión y el doble registro, añadir 30 minutos y retirar 45 deja 38 h. La hora del jueves ya estaba incluida en ambos totales y sigue pendiente de contexto. El ejemplo aún no está listo para darlo por cerrado.
4. Corrige con evidencia y verifica el resultado
Antes de añadir tiempo, comprueba que no exista ya. Para editar o eliminar, Jira requiere permisos sobre worklogs propios o ajenos. Si falta una acción, consulta al administrador. La guía de corrección explica el recorrido.
Después de guardar, vuelve a consultar las entradas y el total del periodo. Comprueba también la estimación restante de la incidencia cuando tu equipo la utilice: es un dato diferente del total semanal personal. Conserva la referencia de lo que cambió.
Checklist semanal para reutilizar
- He fijado las fechas, el autor y el criterio de zona horaria.
- He abierto las entradas concretas y comprobado sus permisos y alcance.
- He contrastado cada día con referencias del trabajo realmente realizado.
- He revisado incidencia, inicio, duración y descripción.
- He comprobado los posibles duplicados antes de corregirlos.
- He vuelto a consultar Jira tras guardar cada cambio.
- He separado las dudas pendientes y anotado qué falta para resolverlas.
- He cerrado la semana solo cuando las diferencias están verificadas o documentadas según el proceso del equipo.
5. Deja una lista breve de pendientes
Para cada duda conserva el día, la incidencia, el tiempo afectado, la evidencia disponible y la siguiente comprobación. Por ejemplo: «Jueves: 1 h registrada; confirmar si corresponde a soporte o al proyecto antes de editar».
Si una duda queda sin resolver, sigue el procedimiento de tu equipo y haz visible su estado. No ajustes duraciones para que el total encaje. Para una revisión diaria más detallada, consulta cómo revisar tus horas de hoy.
DÓNDE ENCAJA SYNC4US
Una revisión común antes de confirmar cambios
Sync4us reúne bloques de la jornada y worklogs de Jira para facilitar la revisión antes de preparar cambios. Clockify es opcional. Cada escritura en Jira requiere la revisión y confirmación explícitas de la persona usuaria.
Preguntas frecuentes
¿Puedo obtener mi total semanal personal solo con JQL?
La búsqueda localiza incidencias. Debes comprobar las entradas concretas del autor y del periodo o usar una herramienta autorizada que las lea con ese alcance.
¿Cada reunión del calendario debe convertirse en un worklog?
Confirma que ocurrió y que corresponde registrarla según el proceso de tu equipo. El calendario aporta contexto, no una justificación automática para escribir en Jira.
¿Cuándo doy la semana por cerrada?
Cuando has revisado las diferencias, verificado las correcciones y documentado cualquier excepción con su siguiente paso según el proceso del equipo.
Fuentes y alcance
- Campos JQL — Atlassian Support
- Registrar, editar y eliminar tiempo — Atlassian Support
- Permisos de seguimiento de tiempo — Atlassian Support
Fuentes oficiales revisadas el 8 de octubre de 2026. El checklist y la semana ficticia son una propuesta editorial propia. La guía se refiere a Jira Cloud; los nombres y las opciones dependen de idioma, permisos y configuración.