Proyectos team-managed, ahora también en Jira Service Management

Si llevas tiempo trabajando en entornos de Jira Cloud, ya estarás familiarizado con los diferentes tipos de proyecto: team-managed y company-managed. Los que antes se conocían como Next Gen o Classic.

Hasta ahora, los proyectos team-managed solo estaban disponibles en los productos Jira Software y Jira Work Management. Este tipo de proyectos estaban pensados para que cualquier usuario, sin necesidad de saber cómo administrar una instancia de Jira, pudiera crearlos, personalizarlos y utilizarlos con su equipo. Como su propio nombre indica, son proyectos de equipo: creados por el equipo, gestionados por el equipo y, por lo tanto, sin conexión ninguna con el resto de proyectos de la compañía. Toda la configuración que se realiza en estos proyectos (extremadamente sencilla) se queda en estos proyectos, sin interferir en ninguno otro, ni en la administración general de la instancia. Pueden ser muy útiles para equipos pequeños, temporales o incluso proyectos aislados con una duración determinada. En el caso de que necesites poder avanzar sin conocimientos de administración de Jira, también pueden ser muy buena solución.

Atlassian está trabajando para incorporar esta funcionalidad ahora también en los proyectos de Jira Service Management. Y nosotros la hemos probado para contarte todos los detalles y evaluar hasta qué punto merecen la pena en este tipo de proyectos.

Si tú también quieres probar esta funcionalidad que ahora mismo está en Beta, tienes que hacer una solicitud para que incluyan esta opción en tu instancia y listo. También se puede habilitar desde <your site name>.

Las características principales de estos proyectos, respecto a los proyectos de tipo company-managed son:

• ESTRUCTURA:
  • De manera más visual podemos ver cómo están formados estos tipos de proyectos:

• No hay esquemas de ningún tipo de por medio y toda la configuración se realiza de manera más autónoma, lo que simplifica esta configuración.
• El mantenimiento del proyecto lo realiza directamente el equipo y no los administradores de la instancia.

• ROLES Y PERMISOS: 
  • El acceso al proyecto solo puede ser de dos tipos: privado (solo las personas añadidas al proyecto podrán verlo) o abierto (cualquier persona de la instancia podrá verlo).
  • La gestión de permisos se realiza directamente a través de los roles del proyecto.
  • En vez de tener un esquema de permisos, disponemos de la posibilidad de crear nuevos roles e incluir los permisos que deben tener esos roles.
  • En la misma sección donde se gestionan los permisos del rol se pueden agregar usuarios y grupos.
  • Es una manera muy rápida de gestionar a la vez y en un mismo lugar usuarios, roles y permisos.

• REQUEST TYPES: 
  • Desde esta sección es desde donde se va a poder crear nuevos campos y seleccionar, con solo arrastrar el elemento, dónde se va a incluir: en el portal o solamente en la parte del agente para incluir la información que sólo se tratará de forma interna.
  • También se podrá editar el workflow, crear nuevos request types, poner campos obligatorios y valores por defecto desde esta sección.
  • La creación del flujo de trabajo se realiza desde un editor mucho más sencillo y simplificado.
  • En el flujo se han desprendido de las post funciones, condiciones y validaciones, que en este tipo de proyecto se llaman Reglas. Tienen poca variedad de reglas, lo que limita bastante lo que se puede realizar en el flujo(Por ejemplo: restringir transiciones a ciertas personas, estados o valores de un campo, asignación automática o editar automáticamente un campo). Seguramente tendrás que utilizar reglas de automation para compensar esa carencia.
  • A diferencia de los proyectos company-managed, donde nos encontramos varios esquemas que configurar y agregar al proyecto para definir un request type, en los team-managed tenemos esto en un solo lugar.

• PORTAL: 
  • La apariencia visual del portal es idéntica a la de un proyecto company-managed. Un usuario que entre al portal no apreciará ninguna diferencia entre dos portales que coexistan en el Help center y que sean de tipos de proyecto distintos.
  • Se puede configurar la apariencia y el acceso a el portal de la misma manera que se haría con un company-managed. Los permisos de los customers también son configurables desde el propio proyecto.
  • Se pueden crear Forms, añadir idiomas, traducciones, encuestas de satisfacción, base de conocimientos de Confluence al igual que en los proyectos company-managed.

• NOTIFICACIONES: 
  • Las notificaciones que reciben los customers o clientes son iguales que las de un proyecto company-managed y se configuran desde el mismo proyecto.
  • Las notificaciones internas, que recibirían los agentes o usuarios de Jira, sí que presentan algunas diferencias en comparación a los proyectos de tipo company-managed,(Por ejemplo: no se puede seleccionar que se notifique a un usuario o grupo especificado en un campo. Por lo que no se puede seleccionar un usuario individual). 

• OTRAS FUNCIONALIDADES: 
  • Automation y SLA: no hay cambios en este sentido, funcionan igual que en los proyectos de tipo company-managed.
  • Colas: tampoco hay diferencia en la configuración de las colas, incluso se pueden agregar columnas o filtros con los campos personalizados de las request types.
  • Filtros, JQL: en la búsqueda avanzada de incidencias también podemos agregar columnas o filtrar por campos que sean propios de este proyecto.

Antes de aventurarte a seleccionar un proyecto de este estilo, tienes que tener en cuenta las siguientes limitaciones:

• Los flujos de trabajo y estados se pueden copiar entre tipos de solicitudes, pero no entre proyectos diferentes. Recuerda que lo que pase en un proyecto de equipo, se queda en el equipo.
• Las reglas habilitadas para los flujos de trabajo son bastante limitadas, por lo que es posible que tengas que apoyarte en reglas de automation si quieres ampliar las funcionalidades.
• En la configuración de las request type, no podrás elegir qué campos serán editables y cuáles no.
• Si te arrepientes tras un tiempo trabajando con este tipo de proyecto y quieres cambiar a uno gestionado por la compañía, te tocará crear otro y moverlo todo. No existe una migración natural para hacerlo.
• Si tienes también Assets, y hay campos que comparten información, no podrás usarlos en este tipo de proyectos.
• No se puede incluir la plantilla de ITSM que propone Atlasssian por el momento.

Tras este análisis, nuestra conclusión sería la siguiente:

Tras haber probado todos los tipos de proyecto team-managed que se pueden crear: para Jira Software, Jira Work Management y Jira Service Management, estos últimos son realmente los más parecidos a los proyectos company-managed. Mantienen muchas funcionalidades intactas e incluso mejoran y facilitan la configuración del propio proyecto unificando varias configuraciones en el mismo menú.

A nivel técnico, lo que menos nos convence es no poder seleccionar los campos que serán editables al no haber la opción ni existir las pantallas como tal. Y las limitaciones del flujo de trabajo, hay muy pocas acciones disponibles ahora mismo.

Desde luego es una opción muy buena y totalmente válida para un equipo que pueda trabajar con las funcionalidades de caja y además que quieran ser autónomos completamente, sin tener ninguna dependencia de un administrador de la instancia. Si necesitas una configuración mayor o evolucionar este proyecto inicial, entonces tendrás que migrar a uno de tipo company-managed en el futuro.