Con la inteligencia artificial, este segundo flujo no se ha reducido: el c\u00f3digo se produce m\u00e1s r\u00e1pido y se publica con m\u00e1s frecuencia, y cada lanzamiento trae consigo su propia cola de incidencias, correcciones y peticiones de aclaraci\u00f3n. Adem\u00e1s de entender c\u00f3mo hacer visible la #capacidad real del equipo<\/strong><\/a>, para un PM del sector TI es fundamental configurar bien el proceso de recogida, clasificaci\u00f3n y planificaci\u00f3n de los tickets<\/strong>, de modo que entren en el plan de trabajo sin trastocarlo.<\/p>\n\n\n\n Los problemas t\u00edpicos son siempre los mismos:<\/p>\n\n\n\n A continuaci\u00f3n veremos tres procesos sencillos<\/strong> para integrar los tickets en el flujo de trabajo<\/a><\/strong>, sin que la actividad de asistencia bloquee los proyectos de desarrollo en curso.<\/p>\n\n\n\n<\/a>\n\n\n\n El primer paso es decidir ad\u00f3nde llegan los tickets<\/strong>. En Twproject<\/strong><\/a> cada ticket es un ToDo<\/strong><\/a>, es decir, una microactividad que vive siempre dentro de un proyecto o de una fase. Para el help desk interno, la soluci\u00f3n m\u00e1s sencilla es crear un proyecto dedicado, por ejemplo \u00abAsistencia TI\u00bb o \u00abSoporte producto X\u00bb, que re\u00fana todas las solicitudes en un solo lugar.<\/p>\n\n\n\n Las solicitudes pueden llegar a ese proyecto por distintas v\u00edas:<\/p>\n\n\n\n El resultado es que ninguna solicitud se queda en un buz\u00f3n personal o en un chat: todo queda registrado, se puede buscar y tiene un historial. Los permisos tambi\u00e9n est\u00e1n separados: un rol \u00abcliente\u00bb puede tener acceso de solo lectura al proyecto y, al mismo tiempo, el derecho a crear ToDo.<\/p>\n\n\n\n Un ticket recogido pero sin clasificar es solo una l\u00ednea m\u00e1s en una lista. Cada ToDo de Twproject lleva consigo la informaci\u00f3n necesaria para clasificarlo:<\/p>\n\n\n\n Los ToDo se pueden clasificar de forma visual con el Kanban de Twproject<\/strong><\/a>, que es multidimensional: las columnas pueden ser la gravedad, el estado, el asignatario o las fases del proyecto. En un help desk, el responsable abre el Kanban del proyecto de asistencia, ve las solicitudes entrantes a\u00fan sin asignar y las arrastra hacia la persona o la fase adecuada. Cada cambio de estado y de asignatario queda registrado en el historial del ToDo.<\/p>\n\n\n\n Para no perder nada por el camino est\u00e1n las notificaciones<\/strong><\/a>: puedes recibir un aviso cuando se a\u00f1ade, modifica o cierra un ToDo, o cuando ha vencido y sigue abierto. Cada uno elige el canal; correo inmediato, resumen peri\u00f3dico (digest), aviso en pantalla o un simple registro.<\/p>\n\n\n\n Un detalle \u00fatil para los equipos de TI: cuando un ticket resulta m\u00e1s grande de lo previsto, por ejemplo un \u00abpeque\u00f1o cambio\u00bb que se convierte en una evoluci\u00f3n del producto, el ToDo se puede transformar en proyecto<\/strong>. El ToDo original se cierra y nace un subproyecto con sus propias fases y estimaciones, en lugar de quedarse como un ticket que ocupa a una persona durante semanas.<\/p>\n\n\n\n<\/a>\n\n\n\n Aqu\u00ed es donde se juega el verdadero partido. Un ticket que no pesa en la carga es un ticket que le roba tiempo a los proyectos sin que nadie se d\u00e9 cuenta.<\/p>\n\n\n\n En Twproject <\/strong>la conexi\u00f3n es directa. En el proyecto de asistencia, los miembros del equipo tienen una asignaci\u00f3n de tipo spot <\/strong><\/a>(consulta aqu\u00ed<\/strong> <\/a>la diferencia entre actividades de proyecto, spot y de rutina<\/strong>), pensada precisamente para las actividades que no se pueden planificar: incluso con estimaci\u00f3n cero, cada ToDo con una fecha \u00aba realizar el\u00bb<\/strong> y una estimaci\u00f3n en horas<\/strong> entra de inmediato en la carga de trabajo<\/strong><\/a> de la persona para ese d\u00eda. Lo mismo ocurre con los ToDo distribuidos con el planner<\/strong><\/a>, donde el responsable los arrastra al calendario de cada asignatario: cuatro horas planificadas el lunes en un ticket son cuatro horas \u00abreservadas\u00bb en la carga del lunes.<\/p>\n\n\n\n As\u00ed, cuando se consulta la vista de carga, los tickets aparecen junto a las fases de proyecto. Si un desarrollador tiene la semana ocupada por incidencias urgentes, se ve antes de asignarle una nueva fase, y se puede decidir con cifras si mover un ticket, reasignarlo o aplazar la entrega<\/strong>.<\/p>\n\n\n\n\u00cdNDICE<\/h5>\n
\n\n
Los problemas a resolver en la gesti\u00f3n de tickets<\/h2>\n\n\n\n
\n
1. Un \u00fanico punto de entrada para todas las solicitudes<\/h3>\n\n\n\n
\n
![\"\"](\"https:\/\/twproject.com\/blog\/wp-content\/uploads\/2021\/09\/define-todo.png\")
<\/figure>\n\n\n\n<\/a>\n\n\n\n2. Clasificar, asignar y decidir las prioridades<\/h3>\n\n\n\n
\n
![\"kanban](\"https:\/\/twproject.com\/blog\/wp-content\/uploads\/2024\/12\/extended-view-kanban-cards-840x450.jpg\")
<\/figure>\n\n\n\n3. Integrar los tickets en la carga de trabajo<\/h3>\n\n\n\n
![\"\"](\"https:\/\/twproject.com\/blog\/wp-content\/uploads\/2023\/02\/load-2-840x242.png\")
<\/figure>\n\n\n\n