Jira Work Management
Cuando debes gestionar varios proyectos al mismo tiempo se hace necesario, casi imprescindible, contar con una herramienta que te permita llevar el seguimiento de las tareas. De lo contrario, volverte mono será tu destino. Si bien hay varias en el mercado, me he familiarizado con Jira Work Management (JWM) basicamente por la parte de desarrollo de software, con Jira Software previamente, y por tanto la transición ha sido suave.
Si bien su uso es muy intuitivo, acá dejo algunos aprendizajes obtenidos. Primero estudiar y analizar para posteriormente empezar a llenar el tablero con tareas.
¿Las actividades/tareas del proyecto tienen todas la misma jerarquía? ¿las podemos agrupar en hitos definidos? Si la respuesta es sí, entonces lo primero que habrá que hacer es crear Épicas (que no están activas por defecto en JWM) según la plantilla elegida. En mi caso trato las épicas como hitos o como sectorizaciones de tareas lo que ayuda visualmente sobre todo en la vista de cronograma.
Roles
Si bien tenemos tres roles predefinidos: administrador, miembro y lector, considero más que conveniente generar nuevos roles para detallar las funciones de cada usuario, o grupo de usuarios, sobre todo cuando se trata de proyectos complejos con muchos involucrados y jerarquías de funciones.
A los tres iniciales, generalmente agrego «Aprobador» a quienes deben efectivamente aprobar o rechazar una tarea. No es el responsable de la tarea quién debe hacerlo.
Para dar un mayor control, generalmente el aprobador debe ser además el informador de la tarea. Esto, porque el campo Approvers original de JWM no funciona para la generación de reglas (algo que espero se corrija en nuevas versiones).
Flujo de trabajo
Tal vez la primera actividad que se debe realizar es establecer el flujo de trabajo que conlleva además definir las etapas que abordará el proyecto. Para uno simple siempre se propone 3 etapas o estados para cada tarea: Por hacer (backlog), haciendo (In use) o terminado (done). Sin embargo, considero que son muy pocas para atender cualquier proyecto por simple que sea. En mi caso particular siempre establezco 5 a lo menos:
- Por hacer, el siempre e inmanente backlog.
- En uso, trabajos en desarrollo.
- Revisión, por aprobar
- Rechazado, este debiese ser parte transitorio o terminado.
- Terminado, trabajos terminados y aprobados.
- Cancelado, trabajos descartados.
Además, ¿que tal si se dan tareas urgentes? las que definimos como prioritarias (hay un campo para eso), pero entre tantas tareas las podemos pasar por alto. Alternativas:
- Establecer reglas para alertar por correo al usuario a cargo para cuando una tarea se marque como alta prioridad.
- Crear una etapa en el tablero denominada «Urgente» que agrupe todas las tareas indicadas con un nivel de prioridad alto (esta es mi elección).
También, para mayor claridad y separación, una columna «Rechazado» en el tablero indica claramente qué actividades debe el usuario responsable retomar para corregir lo necesario y volver al ciclo de revision-aprobación.
Si no consideramos el estado de Rechazado como actividad terminal sino como una oportunidad de mejora, en que el responsable tiene la opción de retormar la actividad y efectuar los cambios pertinentes el proyecto ganará en eficacia.
