Con l’intelligenza artificiale questo secondo flusso non si \u00e8 ridotto: il codice infatti si produce pi\u00f9 in fretta, si rilascia pi\u00f9 spesso, e ogni rilascio porta con s\u00e9 la sua coda di segnalazioni, correzioni e richieste di chiarimento. Oltre a capire come rendere visibile la #capacit\u00e0 reale del team<\/strong><\/a> per un PM in ambito IT \u00e8 fondamentale impostare bene il processo di raccolta, smistamento e pianificazione dei ticket<\/strong> in modo che entrino nel piano di lavoro senza stravolgerlo.<\/p>\n\n\n\n I problemi tipici sono sempre gli stessi:<\/p>\n\n\n\n Di seguito vedremo tre semplici processi<\/strong> per riuscire a integrare i ticket all’interno del flusso di lavoro<\/a><\/strong>, senza che l’attivit\u00e0 di assistenza diventi bloccante per i progetti di sviluppo in corso.<\/p>\n\n\n\n<\/a>\n\n\n\n Il primo passo \u00e8 decidere dove arrivano i ticket<\/strong>. In Twproject<\/strong><\/a> ogni ticket \u00e8 un ToDo<\/strong><\/a>, cio\u00e8 una micro-attivit\u00e0 che vive sempre dentro un progetto o una fase. Per l’help desk interno la soluzione pi\u00f9 lineare \u00e8 creare un progetto dedicato, ad esempio “Assistenza IT” o “Supporto prodotto X”, che raccoglie tutte le richieste in un solo posto.<\/p>\n\n\n\n A quel progetto le richieste possono arrivare per diverse strade:<\/p>\n\n\n\n Il risultato \u00e8 che nessuna richiesta resta pi\u00f9 in una casella personale o in una chat: tutto \u00e8 tracciato, ricercabile e con uno storico. Anche i permessi sono separati: un ruolo “cliente” pu\u00f2 avere accesso in sola lettura al progetto e, allo stesso tempo, il diritto di creare ToDo.<\/p>\n\n\n\n Un ticket raccolto ma non classificato \u00e8 solo una riga in pi\u00f9 in una lista. Ogni ToDo di Twproject porta con s\u00e9 le informazioni che servono per smistarlo:<\/p>\n\n\n\n Lo smistamento dei ToDo pu\u00f2 essere fatto in modo visivo con la Kanban di Twproject<\/strong><\/a>, che \u00e8 multidimensionale: le colonne possono essere la gravit\u00e0, lo stato, l’assegnatario o le fasi del progetto. Per un help desk, il responsabile apre la Kanban sul progetto di assistenza, vede le richieste in ingresso non ancora assegnate e le trascina verso la persona o la fase giusta. Ogni cambio di stato e di assegnatario resta registrato nella cronologia del ToDo.<\/p>\n\n\n\n Per non perdere nulla per strada intervengono le notifiche<\/strong><\/a>: si pu\u00f2 essere avvisati quando un ToDo viene aggiunto, modificato, chiuso o quando \u00e8 scaduto ed \u00e8 ancora aperto. Ognuno sceglie il canale; e-mail immediata, riepilogo periodico (digest), avviso a schermo o semplice log.<\/p>\n\n\n\n Un dettaglio utile per i team IT: quando un ticket si rivela pi\u00f9 grande del previsto, per esempio una “piccola modifica” che diventa un’evoluzione del prodotto, il ToDo si pu\u00f2 trasformare in progetto<\/strong>. Il ToDo originale si chiude e nasce un sottoprogetto con le sue fasi e stime, invece di restare un ticket che occupa una persona per settimane.<\/p>\n\n\n\n<\/a>\n\n\n\n Qui si gioca la partita vera. Un ticket che non pesa sul carico \u00e8 un ticket che ruba tempo ai progetti senza che nessuno se ne accorga.<\/p>\n\n\n\n In Twproject <\/strong>il collegamento \u00e8 diretto. Sul progetto di assistenza i membri del team hanno un’assegnazione di tipo spot <\/strong><\/a>(vedi qui<\/strong> <\/a>la differenza tra attivit\u00e0 di progetto, spot o di routine<\/strong>), pensata proprio per le attivit\u00e0 non pianificabili: anche con stima zero, ogni ToDo con una data “da fare il”<\/strong> e una stima in ore<\/strong> entra subito nel carico di lavoro<\/strong><\/a> della persona per quel giorno. Lo stesso vale per i ToDo distribuiti con il planner<\/strong><\/a>, dove il responsabile li trascina sul calendario dei singoli assegnatari: quattro ore pianificate luned\u00ec su un ticket sono quattro ore “prenotate” nel carico di luned\u00ec.<\/p>\n\n\n\n Cos\u00ec, quando si guarda la vista del carico, i ticket compaiono accanto alle fasi di progetto. Se uno sviluppatore ha la settimana occupata da segnalazioni urgenti, lo si vede prima di assegnargli una nuova fase, e si pu\u00f2 decidere con i numeri se spostare un ticket, riassegnarlo o rinviare la consegna<\/strong>.<\/p>\n\n\n\nINDICE<\/h5>\n
\n\n
Le criticit\u00e0 da affrontare nella gestione dei ticket<\/h2>\n\n\n\n
\n
1. Un unico punto d’ingresso per tutte le richieste<\/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. Classificare, assegnare e decidere le priorit\u00e0<\/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. Integrare i ticket nel carico di lavoro<\/h3>\n\n\n\n
![\"\"](\"https:\/\/twproject.com\/blog\/wp-content\/uploads\/2022\/01\/assegnazione-proj-840x148.png\")
<\/figure>\n\n\n\n