202609_Eagleprojects_Guida sintetica utilizzo Jira_v0.1

Guida sintetica all'utilizzo di Jira nelle commesse dell'area Execution - Bandi - R&D

Obiettivo del documento

Il presente documento ha l’obiettivo di illustrare i principali fondamenti di Jira e dell’ecosistema Atlassian, fornendo una panoramica delle logiche di base, delle principali funzionalità e delle modalità di utilizzo della piattaforma.

Allo stesso tempo, il documento descrive come tali funzionalità sono state declinate e personalizzate da EagleProjects nell’ambito del Modello Jira 2.0, evidenziando le principali configurazioni, regole operative e modalità di utilizzo adottate a supporto della gestione delle commesse.

Processo sintetico dell’utilizzo di Jira

[Immagine: diagramma del processo sintetico dell’utilizzo di Jira]

Responsabilità operative per ruolo

1. BU Manager

Il BU Manager interviene all’avvio della commessa, validandone l’avvio e assegnando il Project Manager di riferimento. Nell’ambito della raccolta dei feedback, fornisce una valutazione qualitativa delle performance di Project Manager, Service Manager, Team Leader e Professional coinvolti nella commessa. Inoltre, monitora l’invio delle richieste di feedback ai clienti da parte dei Project Manager e segnala eventuali necessità di follow-up nella raccolta delle risposte.

2. Project Manager

Il Project Manager definisce la roadmap della commessa e traduce le attività progettuali in task monitorabili su Jira. Durante l’esecuzione delle attività, monitora la corretta valorizzazione delle informazioni necessarie su Jira e tiene traccia dello stato di avanzamento e delle altre informazioni rilevanti associate ai task. Partecipa alla fase di raccolta feedback, fornendo una valutazione qualitativa delle performance di BU Manager, Service Manager, Team Leader e Professional coinvolti nella commessa. È inoltre responsabile dell’invio del questionario di soddisfazione al cliente e, una volta ricevuto il feedback, della registrazione degli esiti a sistema.

3. Service Manager

Il Service Manager traduce i task della commessa in sottotask su Jira e li assegna alle risorse di competenza. Durante l’esecuzione delle attività, monitora la corretta valorizzazione delle informazioni necessarie su Jira e tiene traccia dello stato di avanzamento e delle altre informazioni rilevanti associate ai sottotask. Partecipa inoltre alla raccolta dei feedback, fornendo una valutazione qualitativa delle performance di BU Manager, Project Manager, Team Leader e Professional coinvolti nella commessa.

4. Team Leader

Il Team Leader, ove richiesto, supporta la creazione dei sottotask su Jira e, ove previsto, la loro assegnazione alle risorse del team. Durante lo svolgimento delle attività, supervisiona e coordina l’esecuzione operativa del team, svolge direttamente i sottotask assegnati e supporta i membri del team nella gestione di eventuali criticità o dubbi. Monitora inoltre la corretta valorizzazione delle informazioni su Jira e tiene traccia dello stato di avanzamento dei sottotask. Nell’ambito della raccolta feedback, valuta qualitativamente le performance di BU Manager, Project Manager, Service Manager e Professional coinvolti nella commessa.

5. Professional

Il Professional svolge i sottotask assegnati secondo le modalità e le tempistiche previste e segnala e gestisce eventuali criticità operative emerse durante l’attività. Partecipa inoltre alla raccolta periodica dei feedback, fornendo una valutazione qualitativa delle performance di BU Manager, Project Manager, Service Manager e Team Leader coinvolti nella commessa.

Guida Operativa ed Ecosistema Architetturale per la Gestione in Jira

Jira è lo strumento a supporto della pianificazione e della gestione operativa del lavoro delle risorse e dei relativi responsabili di coordinamento, attraverso logiche di ticketing.

Le informazioni registrate in Jira alimentano il monitoraggio e la governance delle attività ricoprendo una funzione principalmente di supporto operativo.

Jira, inoltre, per le commesse di produzione, è connesso al gestionale SAP, consentendo il collegamento tra dati operativi e finanziari.

1. Fondamenti del modello 2.0 implementato in Jira

L'architettura del Modello 2.0 mette in relazione il perimetro gestionale delle commesse di produzione con il relativo spazio operativo in Jira. Jira è strutturato in “Spazi” e si basa su una gerarchia di oggetti (ticket), ognuno con una propria schermata di campi e un workflow specifico.

a. Terminologia

• Spazio: Il livello primario all'interno del sistema. Uno Spazio Jira corrisponde a una commessa SAP ed è generato tramite un automatismo con frequenza giornaliera: ogni volta che l'Amministrazione, Finanza e Controllo (AFC) crea o modifica un progetto all'interno di SAP, il sistema rileva l'evento e genera, durante la notte, il corrispondente Spazio in Jira. I Work Package definiti in SAP sono trasferiti automaticamente come valori selezionabili all'interno del campo Contract Revenue Type di ogni ticket.

  La creazione manuale di spazi (es. spazi draft o spazi speciali) rappresenta un'eccezione procedurale, gestibile esclusivamente dal Team Jira - DPMO a seguito di specifiche richieste del Management, permettendo la gestione di esigenze aziendali non ancora strutturate nel gestionale ERP (SAP)

• Ticket: singoli oggetti operativi e gerarchici all'interno dello Spazio. Indicano le specifiche tecniche, economiche e temporali del lavoro da svolgere

b. Gerarchia (Iniziativa, Epic, Task, Sottotask)

All’interno di uno Spazio, i ticket sono organizzati secondo una struttura gerarchica che consente di rappresentare attività con diversi livelli di granularità. I livelli più alti rappresentano aggregazioni strategiche o macro-attività, mentre quelli inferiori dettagliano progressivamente le singole attività operative.

Livello	Nome livello	Descrizione
2	Iniziativa	Rappresenta un insieme strategico di attività o obiettivi correlati che può comprendere uno o più Epic.
1	Epic	Rappresenta una porzione di lavoro di grandi dimensioni (obiettivo macro o funzionalità ad alto livello) che può contenere più Task.
0	Task	Rappresenta le attività principali in cui, generalmente, viene suddiviso un Epic.
-1	Sottotask	Rappresenta le suddivisioni granulari di un Task sono le singole unità operative da assegnare e svolgere

Nel Modello 2.0 di EagleProjects, la gerarchia standard di Jira è stata declinata per rispondere alle specifiche esigenze operative, individuando, per alcuni livelli gerarchici, tipologie di ticket dedicate, come riportato nella tabella seguente:

[Immagine: tabella delle tipologie di ticket dedicate per livello gerarchico]

Per maggiori informazioni consultare: Guida Introduttiva a Jira Cloud_v1.pdf

Per maggiori informazioni consultare: 202605_Processo gestione commesse in Jira_v0.pdf

2. Interfaccia utente

L'interfaccia utente è concepita per massimizzare la visibilità delle informazioni e per guidare l'utente attraverso i vincoli di avanzamento del processo.

a. Navigazione tra Spazi

La navigazione orizzontale tra i vari Spazi avviene consultando i contenitori generati da SAP (commesse). Gli utenti accedono agli Spazi a cui sono stati esplicitamente assegnati tramite specifici ruoli.

I Business Unit Manager (BUM) ricevono notifiche automatiche alla creazione di nuovi Spazi afferenti alla propria Business Unit e detengono una visibilità trasversale con diritti amministrativi, configurazione e approvazione su tali contenitori.

Per maggiori informazioni consultare: Guida Introduttiva a Jira Cloud_v1.pdf

b. Navigazione interna ad uno Spazio

La navigazione all’interno di uno Spazio avviene attraverso le schermate dei ticket, organizzate in sezioni funzionali che consentono di raccogliere, visualizzare e gestire le informazioni relative alla singola attività.

Le principali sezioni dell’interfaccia sono:

• Descrizione: sezione principale del ticket, contenente le informazioni fondamentali dell’attività, quali Summary, Description, Assignee e Due Date
• Field Tabs: schede che raggruppano i campi per argomento o funzione, ad esempio dettagli tecnici o informazioni aggiuntive
• Campi di contesto: campi aggiuntivi visibili nella sezione Details e organizzabili in base alle necessità operative
• Altri campi: campi non visibili se non valorizzati, che vengono inclusi automaticamente nella sezione Details quando compilati
• Configurazione layout ticket: sezione riservata agli amministratori di progetto per la gestione dell’ordine e della visibilità dei campi
• Activity: area dedicata alla tracciabilità dell’attività, comprendente commenti, cronologia delle modifiche, aggiornamenti di stato e worklog
• Menu azioni: raccoglie le azioni secondarie disponibili sul ticket, quali eliminazione, duplicazione, spostamento e altre operazioni di gestione
• Azioni del ticket: area dedicata alle principali azioni operative, incluse le transizioni di workflow e le azioni rapide configurate sul ticket

La coesione tra i diversi oggetti è garantita dai campi di collegamento, che consentono di mantenere la relazione tra i ticket appartenenti alla stessa struttura gerarchica

Per maggiori informazioni consultare: Guida Introduttiva a Jira Cloud_v1.pdf

3. Gestione dei ticket

Il nucleo della governance di progetto risiede nella gestione del ciclo di vita dei ticket, che consente di pianificare, monitorare e tracciare le attività e, conseguentemente, alimentare anche i dati utili alla fatturazione e alla misurazione dei KPI di performance.

a. Creazione di un ticket

Il ciclo di vita dei ticket segue un iter regolamentato dai ruoli:

• Il Project Manager si occupa di:
  • delineare le Iniziative e gli Epic, strutturando la roadmap e le milestone contrattuali
  • successivamente, di creare i Task, che fungono da contenitore operativo per le lavorazioni. Per fare questo, il Project Manager deve inserire i parametri di lavorazione: Service Type, Production Units, Target Production e Contract Revenue Type, Activity Budget Share, oltre alle date di pianificazione e alle eventuali dipendenze critiche con altri Task

Se il Project Manager non compila correttamente questi parametri in creazione, i Sottotask nasceranno privi di questi dati e non esisterà un meccanismo automatico di recupero, costringendo il Service Manager ad inserirli manualmente

I Task non vengono assegnati al Professional che eseguirà materialmente il lavoro, bensì al Service Manager.

• Il Service Manager, a sua volta, valuta il proprio Capacity Planner e, dopo aver ricevuto il Task, genera i relativi Sottotask a partire dal Task padre
• L'operatore riceverà infine l'assegnazione del Sottotask dal proprio Service Manager o da un Team Leader delegato

Per maggiori informazioni consultare: 202605 Processo gestione commesse in Jira_v1.pdf

Per maggiori informazioni consultare: Addendum Modelli Gestione Commessa_v0.pdf

b. Componenti principali

Ogni ticket richiede la compilazione di campi specifici in base al proprio livello gerarchico e alla propria tipologia.

I campi si distinguono per un'obbligatorietà di sistema (es. software blocca fisicamente la transizione o la creazione in mancanza di un campo obbligatorio compilato) o procedurale (es. imposta dalle direttive aziendali per garantire la compliance).

È importante distinguere i campi di produzione valorizzati a livello Task da quelli presenti nei Sottotask:

• a livello Task, i campi di produzione rappresentano le quantità certificabili ai fini della rendicontazione e della fatturazione della commessa, sotto la responsabilità del Project Manager
• a livello Sottotask, i dati rappresentano invece le dichiarazioni di produzione delle singole risorse operative, da validare successivamente a livello Task

Tra le componenti più rilevanti del modello si individuano:

• Contract revenue type: Voce di listino contrattuale, sincronizzata da SAP e selezionabile da menù a tendina, che collega l'attività al relativo valore economico. Usata per calcolare fatturato e monitorare avanzamento VDP (valore della produzione). È compilata dal PM sul Epic e Task. In assenza di questo campo, le attività non concorrono al fatturato e al monitoraggio del VDP
• Activity Budget Share: Peso percentuale dell'attività rispetto alla voce di listino di riferimento. In fase di budgeting, ogni voce contrattuale può essere ripartita in sotto-attività, ciascuna con il proprio peso %, usato per monitorare l'avanzamento economico della commessa. La % è compilata dal PM sul Task. In assenza di questo campo, le attività non concorrono al fatturato e al monitoraggio del VDP.
• Production Units: campo a compilazione manuale dedicato ai Project Manager: è l’unità di misura della produzione associata all'attività monitorata nel Task ed estesa automaticamente ai Sottotask. È definita dalla voce di listino contrattuale (vd. Contract revenue type)
• Target production: campo a compilazione manuale dedicato ai Project Manager per stabilire la quantità di produzione pianificata. Per l'area IT, il campo rappresenta la stima iniziale delle ore di lavoro previste dal Project Manager nel budget di commessa
• Actual production: campo a compilazione manuale, riservato a Professional e Project Manager, che rappresenta la produzione effettiva rispetto alle quantità previste nel Target production. Viene inserito dal Professional alla chiusura del Sottotask e sommato automaticamente nei commenti del Task. Il PM ne valida veridicità e corrispondenza con quanto pianificato.
• Production Weight: campo a compilazione manuale dedicato ai Service Manager ed introdotto esclusivamente nel Sottotask. Non indica un avanzamento reale, bensì una stima effettuata dal Service Manager del peso percentuale del Sottotask rispetto al Target Production del Task padre (se c’è un unico sottotask il PW è 100%). Una volta compilato il valore del Production Weight, un automatismo determinerà il corrispondente valore numerico del campo Target Production del Sottotask.
• Actual Production Progress: campo a compilazione manuale dedicato ai Professionals. Se la durata di un ticket supera le 8 ore o non viene chiusa in giornata, è obbligatorio aggiornare questo campo quando il ticket passa in “In Pending” alla sospensione giornaliera dell’attività. Questo è un obbligo procedurale non di sitema. Serve a dichiarare una stima dell’avanzamento percentuale rispetto all’attività assegnata. (al passaggio di stato in DONE si valorizzerà al 100% automaticamente).
• Service Type: campo a compilazione manuale dedicato ai Project Manager che identifica il tipo di servizio aziendale che verrà svolto per il completamento del Deliverable. Prevede la compilazione di un campo primario, ovvero il servizio e di uno secondario, attività effettivamente svolta prevista anche in fase di budgeting
• Rework: campo booleano (TRUE/FALSE) a compilazione manuale dedicato ai Service Manager / Team Leader / PRO (Professionals) che indica se l'attività rientra tra le rilavorazioni causate da fattori interni, con costo imputabile alla commessa senza generare ricavo aggiuntivo
• Story Points: campo a compilazione manuale dedicato ai Service Manager, utilizzato nell’Area IT per stimare l'effort o la complessità relativa del ticket per il calcolo dei KPI
• Tempo Team: campo a compilazione manuale dedicato ai Service Manager, non identifica il tempo, ma il Team a cui deve essere assegnata la lavorazione oggetto del ticket

c. Workflow, con dettaglio delle responsabilità per ruolo

In Jira, il workflow rappresenta il percorso che un ticket segue dalla creazione alla chiusura, definendone i diversi stati e le transizioni consentite tra uno stato e l’altro.

Nel Modello Jira 2.0, ogni issuetype dispone di un workflow specifico, con stati, transizioni, campi obbligatori e automazioni configurate in funzione del ruolo operativo del ticket.

Gli elementi principali di un workflow sono:

• Stato: indica la posizione del ticket all’interno del processo
• Transizione: rappresenta il passaggio da uno stato a un altro
• Risoluzione: identifica l’esito con cui il ticket viene chiuso

I workflow possono differire in funzione della tipologia di ticket e della configurazione dello Spazio Jira.

Per maggiori informazioni consultare: Guida Introduttiva a Jira Cloud_v1.pdf

i. Workflow Issuetype Iniziativa

l’Iniziativa segue un ciclo di vita semplificato, da “Created” a “To Do” e “In Progress”, con eventuale passaggio in “In Pending”, fino alla chiusura in “Done”, “CANCELLED” o “KO”.

[Immagine: workflow dell’issuetype Iniziativa]

Vademecum per ruolo

PM – Project Manager

Fase	Azioni
▸ In creazione	› Compilare Riepilogo con titolo significativo (non generico) › Impostare Data consegna cliente se nota al momento della creazione › (Area IT) Impostare Feature=true se il ticket viene utilizzato per identificare una feature da sviluppare
▸ Avvio lavorazione	› Impostare Assegnatario e inserire/ confermare le date di pianificazione che siano coerenti con la roadmap di commessa
▸ Chiusura	› Verificare che Stato e Risoluzione di tutti i ticket subordinati riflettano l'esito reale prima di portare il ticket a DONE / KO / CANCELLED

Per il dettaglio dei campi e delle relative regole di compilazione dell’Iniziativa, si rimanda alla Tabella 1 – “Iniziativa: campi e regole di compilazione” in Annex.

ii. Workflow Issuetype Epic

l’Epic segue un ciclo di vita semplificato, da “Created” a “To Do” e “In Progress”, con eventuale passaggio in “In Pending”, fino alla fase di “PM Approval” e alla chiusura in “Done”, “Cancelled” o “KO”.

[Immagine: workflow dell’issuetype Epic]

Vademecum per ruolo

PM – Project Manager

Fase	Azioni
▸ In creazione	› Compilare Riepilogo con nome deliverable riconoscibile › Valorizzare Contract Revenue Type e Production Units — impatto sulla rendicontazione › Collegare all'Iniziativa tramite campo Principale (se presente) e al macro ambito di Roadmap tramite collegamento ad Idee › Creare Epic fittizi per pianificazione a lungo termine da assegnare ai Service Manager › (Area IT) Impostare Feature=true se il ticket viene utilizzato per identificare una feature da sviluppare
▸ Avvio lavorazione (TO DO)	› Inserire Contract revenue Type, Start date pianificato e Data di scadenza — obbligatori di sistema, la transizione è bloccata senza › Verificare allineamento con la Roadmap di Commessa
▸ Chiusura	› Verificare coerenza Actual Production vs Target Production (devono essere >0) › Controllare che tutti i Task figli siano in stato conclusivo prima di procedere

SM – Service Manager

Fase	Azioni
▸ Pianificazione periodica	› Creare e aggiornare la pianificazione a lungo termine nell'Epic fittizio assegnato › Aggiornare i dati man mano che i sottotask vengono assegnati, per evitare duplicazioni di occupazione nel Capacity Planner

Per il dettaglio dei campi e delle relative regole di compilazione dell’Epic, si rimanda alla Tabella 2 – “Epic: campi e regole di compilazione” in Annex.

iii. Workflow Issuetype Task

Il Task segue un ciclo di vita dalla creazione e assegnazione alla lavorazione, con eventuale passaggio in “In Pending”, fino alla fase di “PM Approval” e alla chiusura in “Done”, “CANCELLED” o “KO”.

[Immagine: workflow dell’issuetype Task]

Vademecum per ruolo

PM – Project Manager

Fase	Azioni
▸ In creazione	› Compilare tutti i campi validator: Start date pianificato, Data di scadenza, Activity Budget Share, Contract Revenue Type, Service Type, Production Units, Target Production — il sistema blocca se mancanti › Assegnare il Task al Service Manager di competenza (non al Professional) › Valorizzare Rework (TRUE / FALSE) e Fornitore-Provider nei casi specifici
▸ Chiusura (PM Approval)	› Leggere il commento automatico generato dal sistema con la somma dell'Actual Production dei Sottotask figli › Validare o correggere Actual Production per sbloccare il passaggio a DONE — è il dato comunicato al Controller per la rendicontazione economica (non è necessario allineare Target ed Actual qualora i due valori non coincidano) › Controllare che tutti i Sottotask siano in stato conclusivo prima di procedere a spostare in DONE/KO/CANCELLED

SM – Service Manager

Fase	Azioni
▸ Passaggio in TO DO	› Compilare Tempo Team — obbligatorio di sistema per la transizione › Verificare coerenza di date e campi di produzione compilati dal PM
▸ Durante lavorazione	› Monitorare l'avanzamento dei Sottotask figli › Aggiornare Assegnatario task se il responsabile cambia

Per il dettaglio dei campi e delle relative regole di compilazione del Task, si rimanda alla Tabella 3 – “Task: campi e regole di compilazione” in Annex.

Workflow Issuetype Story (solo reparto IT)

La Story segue un workflow dedicato alle attività dell’Area IT, dalla creazione e stima alla presa in carico e lavorazione, con eventuale passaggio in “In Pending”, fino al rilascio e alla chiusura in “Done” o “Resolved”.

[Immagine: workflow dell’issuetype Story]

Vademecum per ruolo

PM – Project Manager

Fase	Azioni
▸ In creazione – Da stimare	› Compilare Riepilogo, Contract Revenue Type, Activity Budget Share, Service Type, Production Units, Target Production — obbligatori di sistema › Verificare collegamento all'Epic tramite campo Principale › Assegnare ticket al Service Manager in modo che possa prendere in carico l’attività di pianificazione
▸ Chiusura	› Verificare che Risoluzione rifletta l'esito reale

SM – Service Manager

Fase	Azioni
▸ Passaggio in IN STIMA	› Compilare Tempo Team, Start date pianificato, Data di scadenza — obbligatori di sistema e necessari per la visibilità nel Capacity Planner
▸ Chiusura	› Compilare campi KPI condizionali applicabili al Service Type

Per il dettaglio dei campi e delle relative regole di compilazione della Story, si rimanda alla Tabella 4 – “Story: campi e regole di compilazione” in Annex.

Workflow Issuetype Task Gestionali (solo reparto IT)

Il Task Gestionale, utilizzato dall’Area IT, segue un workflow dedicato, dalla presa in carico e lavorazione, con eventuale passaggio in “In Pending”, fino alla chiusura in “Done” o “Resolved”.

[Immagine: workflow dell’issuetype Task Gestionali]

Per il dettaglio dei campi e delle relative regole di compilazione dei Task Gestionali, si rimanda alla Tabella 5 – “Task Gestionali: campi e regole di compilazione” in Annex.

Workflow Issuetype Task Esecutivi (solo reparto IT)

Il Task Esecutivo Helpdesk segue un workflow operativo dedicato, dalla stima e presa in carico alla lavorazione, con eventuale passaggio in “In Pending”, fino alla chiusura in “Done” o “Resolved”. È attivo il tracciamento temporale.

[Immagine: workflow dell’issuetype Task Esecutivo Helpdesk]

Il Task Esecutivo Bug segue un workflow più articolato, dalla stima e presa in carico alle fasi di review, test e rilascio, con eventuale passaggio in “In Pending”, fino alla chiusura in “Done” o “Resolved”. È attivo il tracciamento temporale

[Immagine: workflow dell’issuetype Task Esecutivo Bug]

Vademecum per ruolo

PM – Project Manager

Fase	Azioni
▸ In creazione	› Compilare Riepilogo, Contract Revenue Type, Service Type, Production Units, Target production — obbligatori di sistema › Verificare collegamento all'Epic tramite campo Principale › Assegnare ticket al Service Manager in modo che possa prendere in carico l’attività di pianificazione

SM – Service Manager

Fase	Azioni
▸ Passaggio in DA FARE	› Compilare Tempo Team, Assegnatario, Start date pianificato, Data di scadenza, Stima originale, Story Points — obbligatori di sistema e necessari per la visibilità nel Capacity Planner
▸ Chiusura	› Verificare che Risoluzione rifletta l'esito reale

PRO – Professional

Fase	Azioni
▸ Passaggio in IN CORSO	› Prendere correttamente in carico l'attività e aggiornare lo stato — da questo momento il tracciamento temporale è attivo
▸ Durante lavorazione (IN PENDING)	› La transizione sospende il tracciamento temporale — non lasciare il ticket in IN CORSO a fine giornata senza aggiornare lo stato
▸ Chiusura	› Compilare i campi KPI condizionali applicabili, secondo le condizioni di obbligatorietà descritte alle sezioni dedicate › Portare il ticket a DONE / RESOLVED — non lasciarlo in stati intermedi

Per il dettaglio dei campi e delle relative regole di compilazione dei Task Esecutivi, si rimanda alla Tabella 6 – “Task Esecutivi: campi e regole di compilazione” in Annex.

iV. Workflow Issuetype Sottotask

Il Sottotask rappresenta il livello operativo di dettaglio ed è l’unico (per i servizi) su cui è attivo il tracciamento temporale. Il workflow prevede l’avvio della lavorazione, con eventuale passaggio in “In Pending” o “Device Processing”, fino alla chiusura in “Done”, “CANCELLED” o “KO”.

[Immagine: workflow dell’issuetype Sottotask]

Vademecum per ruolo

SM – Service Manager

Fase	Azioni
▸ Creazione	› Creare il Sottotask sempre dal Task padre › Verificare che i campi ereditati (Contract Revenue Type, Service Type, Production Units, Tempo Team, Link Epic) siano stati propagati correttamente — se mancanti, intervenire prima sul Task
▸ Passaggio in TO DO	› Compilare: Assegnatario, Stima originale, Data di scadenza, Production Weight (%), Start date pianificato, Activity Type › Verificare Tempo Team (ereditato o da compilare manualmente)

PRO – Professional

Fase	Azioni
▸ Passaggio in IN PROGRESS	› Prendere correttamente in carico l'attività e aggiornare lo stato — da questo momento il tracciamento temporale è attivo
▸ Durante lavorazione (IN PENDING)	› Se durata >8h o attività non chiuse nella giornata di presa in carico: aggiornare Actual Production progress (%) almeno una volta al giorno › Non lasciare il ticket in IN PENDING senza aggiornamento del dato
▸ Chiusura	› Compilare Actual Production (quantità effettiva lavorata) › Valorizzare i campi KPI condizionali se applicabili alla propria attività › Portare il ticket allo stato corretto (DONE / KO / CANCELLED) — non lasciarlo in stati intermedi

Per il dettaglio dei campi e delle relative regole di compilazione del Sottotask, si rimanda alla Tabella 7 – “Sottotask: campi e regole di compilazione” in Annex.

Workflow Issuetype Analisi – Sviluppo – Test – Manualistica – UX/UI (solo reparto IT)

Le attività di Analisi, Sviluppo, Test, Manualistica e UX/UI seguono workflow dedicati, articolati in funzione delle specifiche fasi operative previste, dalla stima e presa in carico fino alla lavorazione, revisione/approvazione e chiusura, con eventuale passaggio in “In Pending”. È attivo il tracciamento temporale.

Workflow Analisi:

[Immagine: workflow Analisi]

Workflow Sviluppo:

[Immagine: workflow Sviluppo]

Workflow Manualistica:

[Immagine: workflow Manualistica]

Workflow UX/UI:

[Immagine: workflow UX/UI]

Vademecum per ruolo

SM – Service Manager

Fase	Azioni
▸ In creazione	› Verificare campi ereditati: EPICKEY, Link Epic, Contract Revenue Type, Service Type, Production Units, Team — se mancanti, intervenire prima sulla Story/ Task padre
▸ Passaggio in DA FARE	› Compilare: Story Points, Assegnatario, Tempo Team, Start date pianificato, Data di scadenza, Stima originale — obbligatori di sistema per la transizione e per il Capacity Planner

PRO – Professional

Fase	Azioni
▸ Passaggio in IN CORSO	› Prendere in carico l'attività e aggiornare lo stato — da questo momento il tracciamento temporale è attivo
▸ Durante la lavorazione (IN PENDING)	› La transizione sospende il tracciamento temporale — non lasciare il ticket in IN CORSO a fine giornata senza aggiornare lo stato
▸ Chiusura	› Compilare i campi KPI condizionali applicabili, secondo le condizioni di obbligatorietà descritte alle sezioni dedicate › Portare il ticket a DONE / RESOLVED — non lasciarlo in stati intermedi

Per il dettaglio dei campi e delle relative regole di compilazione delle attività di Analisi, Sviluppo, Test, Manualistica e UX/UI, si rimanda alla Tabella 8 – “Analisi, Sviluppo, Test, Manualistica e UX/UI: campi e regole di compilazione” in Annex.

d. Eccezioni Operative: Gestione Rework e Quality Check

La creazione di un Sottotask di Rework consente di tracciare attività di rilavorazione derivanti da lavorazioni già eseguite che, per anomalie operative, devono essere nuovamente svolte. Queste attività non generano ulteriore ricavo contrattuale, producendo esclusivamente un impatto in termini di costo. Per classificare un Rework, l'operatore utilizza un'automazione dedicata sul Sottotask originale. Il nuovo ticket riporterà il prefisso “Rework-”, il campo Rework sarà forzato a “TRUE” e si creerà automaticamente un collegamento di tipo “rework of” con la chiave del ticket originario, mantenendo inalterata la tracciabilità della catena di lavorazione. Seguendo questa logica di creazione dei ticket di “Rework” sarà quindi possibile tracciare le reiterazioni del processo di validazione, utile alla valorizzazione del relativo KPI.

Per standardizzare il processo di apertura dei ticket di Rework e ridurre errori manuali, è disponibile una specifica automazione Jira attivabile direttamente dal Sottotask che ha generato la necessità di rilavorazione (si specifica che in questo caso, il campo “Rework” sarà contrassegnato con valore “FALSE” o “Null” perché si tratta della lavorazione originale).

I Sottotask di Quality Check seguono un paradigma simile per l'alimentazione dei KPI. Ogni attività di controllo qualità deve essere saldamente collegata ai Sottotask oggetto di verifica tramite una relazione di tipo “blocks”.

Chi è assegnato al Sottotask di Quality Check (definito tramite il settaggio del campo Activity Type = Quality Check) esegue la verifica seguendo una checklist fornita dal Project Manager, che risiede fuori da Jira in quanto varia per commessa, cliente e standard tecnico applicabile.

Al termine del controllo, il numero di anomalie riscontrate va registrato nel campo KPI_N°Fix rilevati in QC del Sottotask della lavorazione verificata – non del Sottotask di Quality Check. Se il ciclo copre più lavorazioni, i fix vanno ripartiti sui rispettivi Sottotask secondo l'effettiva provenienza. Per compilare di un Sottotask già chiuso, selezionare il tasto Automation Jira che ne abilita temporaneamente la compilazione.

In questo modo l'anomalia resta attribuita al ticket che l'ha generata: seguendo questo processo sarà possibile valorizzare il relativo KPI, utile a verificare la bontà della lavorazione.

L'uso della checklist e l'attribuzione dei fix al ticket corretto sono richiesti dal modello operativo, non sono imposti da Jira.

La logica di calcolo del sistema attraversa l’intera catena di lavorazione, restituendo indicatori qualitativi oggettivi sulle lavorazioni.

e. Modalità di tracciamento temporale

La valorizzazione del tempo impiegato influisce direttamente sui dati elaborati dal plugin Tempo Timesheet. Il tracciamento può avvenire in modalità automatica o manuale; per alcune tipologie di ticket non è invece previsto.

• Automatica

  Il tempo lavorato viene registrato in automatico in funzione dello stato del Sottotask.

  Ogni qualvolta l'operatore transita il ticket dalla categoria di stato “IN PROGRESS” a uno stato non attivo o conclusivo, il tracciamento si interrompe e il sistema calcola il tempo trascorso nello stato attivo

  • Il sistema genera automaticamente un log di lavoro (worklog) al termine di ciascun periodo trascorso in stato attivo.
  • La stima residua (Remaining Estimate) viene aggiornata automaticamente sulla base del tempo registrato
  • La modalità automatica è prevista sui Sottotask e sui Task Esecutivi IT

• Manuale

  Il tracciamento manuale, sempre possibile, avviene tramite l’inserimento del worklog da parte dell’utente. Se l’attività si conclude nella stessa giornata, il worklog viene inserito al termine dell’attività; se l’attività si estende su più giorni, viene inserito almeno una volta al giorno.

  La registrazione può essere effettuata tramite “Altre azioni (…) → Log Time (Registra lavoro)” oppure tramite la sezione “Monitoraggio del tempo”.

• Non prevista

  Per le Iniziative (Livello 2), gli Epic (Livello 1) e i Task standard (Livello 0), il tracciamento temporale non è attivo né tecnicamente supportata la modalità automatica dai workflow nativi.

  Allo stesso modo, per la divisione IT, i Task Gestionali (es. redazione documentazione e Task DevOps hardware) non richiedono un tracciamento puntuale delle ore lavorate tramite Timesheet e non prevedono necessariamente la creazione di Sottotask dedicati.

Per maggiori informazioni consultare: Guida Introduttiva a Jira Cloud_v1.pdf.

4. Permessi e ruoli

Il software Jira si basa su una netta separazione delle responsabilità, codificata attraverso i Ruoli di Progetto.

a. Cosa sono

Il modello distingue chiaramente le figure direzionali, esterni rispetto alla lavorazione del ticket, dagli attori strettamente operativi.

Figure Direzionali e di Governance:

• Team Jira (Referente Tecnico / DPMO): Amministratori globali del sistema Atlassian. Hanno la possibilità di configurazione, l’amministrazione degli account, la gestione dei plugin (come Tempo) e forniscono consulenza tecnica e formativa. Intervengono sulla configurazione dei progetti solo su richiesta formale del Management
• Controller: Garanti della connessione SAP-Jira. Predispongono i progetti e i Work Package in SAP. Sono gli unici responsabili per correggere discrepanze o valori errati nel Contract Revenue Type. Monitorano la sincronizzazione e non intervengono mai direttamente all’interno dei workflow di Jira
• Contract Manager: Autorità responsabile del controllo del ciclo di fatturazione in base al traguardo delle milestone definite nel contratto e supervisionate dal PM. Il Contract Manager si occupa di emettere le fatture coerentemente con quanto concordato con il cliente, nonché di supportare il PM nella predisposizione/ revisione del budget di commessa
• Performance Manager: Definisce i KPI per l’area Execution e ne monitora i risultati in coordinamento con i SM. Valida lo staffing di medio-lungo periodo e gestisce i prestiti di risorse tra diverse aree di competenza, ma non manipola l’assegnazione materiale dei ticket
• Business Unit Manager (BUM): Riceve notifica immediata della creazione di uno Spazio pertinente alla propria unit, designando il PM. Riveste il potere di amministrazione, configurazione e approvazione ultima all’interno della commessa

Attori Operativi in Jira:

• Project Manager (PM): Assegnato con il ruolo di “Administrator”. È il responsabile strategico della commessa. Deve gestire il progetto prima che inizi l’esecuzione materiale, allocando il budget sui sistemi dedicati (esterni a Jira) e declinandolo in Iniziative, Epic e Task al suo interno. Ad inizio progetto compila la roadmap e il Gantt. È sua esclusiva responsabilità validare il dato di Valore della Produzione (VDP) prodotto dalle risorse tramite lo “sblocco” del “PM Approval”. Il PM non interviene nel dettaglio esecutivo e non si sostituisce al Service Manager nell’assegnazione operativa
• Service Manager (SM): Anch’egli assegnato con ruolo “Administrator”, ma con responsabilità tattica sul proprio team. Riceve degli Epic “fittizi” di ingaggio dal PM per valutare la saturazione del personale. Successivamente, scorpora i Task operativi in Sottotask, associandovi la stima oraria, le date, il Tempo Team e ne assegna l’elaborazione alle risorse. Bilancia le dimensioni verticali (la consegna della commessa) e orizzontali (la saturazione orizzontale del proprio team nel Capacity Planner)
• Team Leader (TL): Ruolo ibrido. Assume funzioni del Professional qualora operi direttamente, o funzioni vicarie del Service Manager laddove gli venga esplicitamente demandata la micro-pianificazione dei Task
• Professional (PRO): Assegnato con il ruolo di “Utente”. È l’esecutore materiale. Interagisce esclusivamente a Livello -1 (Sottotask) o Livello 0 se Task Esecutivi IT. Responsabile di avanzare fisicamente la lavorazione nei workflow (attivando il tracciamento), di documentare l’avanzamento giornaliero per attività lunghe e di indicare l’Actual Production in fase di chiusura

b. Come modificarli

L’attribuzione e l’escalation dei privilegi non derivano da complesse interfacce di autorizzazione per il singolo utente, ma da logiche gerarchiche di assegnazione.

• Alla creazione dello Spazio Jira, il BUM competente riceve una notifica automatica e dispone dei permessi necessari per aggiungere utenti.
  • Allo stato attuale, non esiste un owner formale unico dell’abilitazione delle risorse agli Spazi: la responsabilità è condivisa, di fatto, tra PM, SM e BUM

Per maggiori informazioni consultare: Guida Introduttiva a Jira Cloud_v1.pdf

Per maggiori informazioni consultare: Ruoli e Permessi Jira.html

5. Modalità di visualizzazione

Data l'elevata densità di ticket (Epic, Task, Sottotask, Rework e Quality Check) riversata all'interno degli Spazi per via della disgregazione procedurale, è possibile utilizzare differenti modalità di visualizzazione e strumenti, che consentono di consultare e gestire i ticket in funzione delle specifiche esigenze operative.

a. Creazione di filtri

I filtri consentono di visualizzare e gestire i ticket sulla base di criteri specifici, ad esempio stato, assegnatario, tipologia o Spazio di appartenenza. Possono essere salvati e riutilizzati nelle diverse viste, Dashboard e board.

Per esigenze di ricerca più avanzate, Jira mette inoltre a disposizione il linguaggio JQL (Jira Query Language), che consente di definire criteri di ricerca personalizzati.

Per maggiori informazioni consultare: Guida Introduttiva a Jira Cloud_v1.pdf

b. Viste preconfigurate

Le rappresentazioni visuali statiche sotto forma di semplici elenchi non riescono a narrare lo stato evolutivo di un progetto complesso. A questo scopo, le viste preconfigurate, incastonate nel modello gestionale, offrono spaccati temporali interattivi.

Tra le viste e gli strumenti disponibili in Jira, i Piani (Advanced Roadmaps) consentono di pianificare attività trasversali a più Spazi e team, visualizzare le dipendenze tra ticket e simulare diversi scenari. Offrono una rappresentazione temporale delle attività e supportano la pianificazione della capacità del team.

Per maggiori informazioni consultare: Guida Introduttiva a Jira Cloud_v1.pdf

6. Sintesi delle Linee Guida di utilizzo di Jira

La sezione descrive le principali regole operative che disciplinano l’utilizzo di Jira lungo il processo di commessa, chiarendo responsabilità, vincoli e modalità di gestione delle diverse attività.

In particolare, vengono richiamate le indicazioni relative alla creazione e assegnazione dei ticket, avanzamento degli stati, compilazione dei campi e validazione delle attività, evidenziando le condizioni necessarie per garantire la corretta alimentazione dei dati, il monitoraggio e la data quality.

a. Responsabilità in Jira per fase di processo

Le tabelle seguenti riassumono le principali responsabilità associate alle diverse fasi del processo di commessa e le relative azioni da svolgere in Jira, indicando per ciascuna attività il ruolo coinvolto e la sezione della piattaforma da utilizzare.

Le attività sono articolate nelle principali fasi di Preventivazione, Avvio commessa e Gestione ricorrente della commessa.

Fase 1 — Preventivazione

Azione in Jira	Attore	Sezione
Apertura del ticket di ingaggio del Solution Specialist con informazioni chiave (cliente, scope, scadenza attività, materiale, requisiti di alto livello)	Director Commerciale / CSM	Gestione offerte Solution Specialist (GOSS)
Inserimento materiale di proposta e dettaglio stime di effort (FTE ed elapsed per Area di Competenza, HW/SW, data prevista di avvio e fine attività)	Solution Specialist	Gestione offerte Solution Specialist (GOSS)
Verifica la stima di effort elaborata dal PM e aggiorna il pre-staffing, creando un epic “fittizio” nello spazio draft. Una volta che la commessa ed il relativo contratto sono finalizzati, il Service Manager potrà aggiornare e finalizzare l’epic	Service Manager	Gestione offerte Solution Specialist (GOSS); Spazio Draft - Studio Di Fattibilita' (DRAFT)

Fase 2 — Avvio commessa

Azione in Jira	Ruolo	Sezione
Definizione della roadmap di commessa di alto livello per macro-ambiti, con specifica di attività, tempi, deliverable ed FTE (a valle della definizione del budget di commessa e del piano di rendicontazione ore risorse che avviene fuori da Jira – ref. Documento “Gestione commesse e2e”) – spiegare le 3 tipologie di roadmap in coerenza con le 3 tipologie di contratto e deliverable fatturabile: Deliverable contrattuale coincidente con quello fatturabile, fatturazione solo a deliverable completo (100%) → creazione Epic Deliverable contrattuale che prevede più deliverable fatturabili (non coincidono), fatturazione per voce economica completata → creazione Iniziativa Fatturazione per SAL / Milestone di avanzamento → creazione Iniziativa Non è prevista la creazione della roadmap per le commesse “a flusso”, ossia nelle quali le lavorazioni vengono assegnate di volta in volta con il cliente senza pianificazione preventivata (es. Delivery)	Project Manager	Piani in Spazio di commessa, o in alternativa Discovery come App ad hoc – a discrezione del PM
Richiesta allocazione risorse alla commessa al Service Manager, tramite creazione Epic di richiesta FTE	Project Manager	Spazio di commessa
Aggiornamento pre-staffing in favore dello staffing effettivo per la singola commessa, spostando l’Epic dell’assegnazione del pre-staffing dallo Spazio draft allo Spazio effettivo associando i nominativi effettivi delle risorse	Service Manager	Spazio di commessa (vista Capacity planner)
Declinazione della roadmap in attività di dettaglio che costituiscono il Gantt di progetto e da cui poi verranno assegnati task e sotto-task alle risorse	Project Manager	Spazio di commessa

Fase 3 — Gestione ricorrente della commessa

Azione in Jira	Ruolo	Sezione
Assegnazione ricorrente dei task al Service Manager dell’Area di Competenza coinvolta, definendo tempi quantità e dipendenze	Project Manager	Spazio di commessa
Ricezione notifica di assegnazione dei task e smistamento dei relativi sottotask assegnandoli alle risorse della propria Area di Competenza	Service Manager	Spazio di commessa
Ricezione notifica di assegnazione dei sottotask e relativa presa in carico, inserendo tutti i campi richiesti (produzione, tempo)	Professional	Spazio di commessa
Validazione del completamento dei sottotask assegnati alle risorse della sua Area di Competenza, verificando la correttezza dei campi	Service Manager	Spazio di commessa
Verifica andamento dei task rispetto alla roadmap di commessa	Project Manager	Spazio di commessa
Presidio della saturazione e della corretta allocazione delle risorse per la propria Area di Competenza	Service Manager	Spazio di commessa
Monitoraggio del raggiungimento delle milestone per la fatturazione	Contract Manager	Spazio di commessa
Monitoraggio del livello di saturazione complessiva delle Operations	Performance Manager	Spazio di commessa + Dashboard di sintesi

b. Vincoli operativi

Oltre alle azioni da svolgere, è necessario rispettare specifici vincoli operativi e di corretta compilazione, finalizzati a garantire la coerenza delle informazioni registrate in Jira e la qualità dei dati utilizzati per il monitoraggio.

I vincoli riguardano in particolare la creazione dei Task e Sottotask, la gestione degli stati, l’assegnazione delle attività, l’aggiornamento della produzione, il tracciamento del tempo, la validazione delle lavorazioni e la gestione dello staffing.

Azione in Jira	Attore	Vincolo
Apertura dei ticket livello task e sottotask (0) e (-1)	Project Manager/ Service Manager	- La data di inizio e la data di fine non può essere antecedente alla data di apertura del ticket e deve essere coerente con la roadmap. Eventuali disallineamenti vengono rilevati dal Data Quality - Eventuali slittamenti di due-date dei sottotask devono essere adeguatamente motivati al PM e alla BU nei casi dei task - Il task/ sottotask deve essere assegnato ad una sola risorsa responsabile - Nel caso in cui il PM o il SM non conoscano ancora l’assegnatario del task/ sottotask al momento della creazione, lasciano il task/ sottotask in “created” fino all’effettiva assegnazione. Il task/sottotask non deve essere avanzato di stato rispetto allo stato iniziale di creazione prima che venga individuato l’assegnatario. Non è consentito assegnare task a sé stessi per tenerli in stand-by fino a effettiva assegnazione (ad eccezione dei casi in cui il SM effettivamente elabora il sottotask) - Le tempistiche attese per l’elaborazione di un task/ sottotask devono essere uguali per tutti a parità di grade (i.e., medesime tempistiche per tutti i Professional; medesime tempistiche per tutti i Team Leader). Non è consentito assegnare tempistiche diverse a risorse con lo stesso grado di seniority - È sempre necessario che il PM compili il Contract Revenue Type e l’Activity Budget Share all’apertura del task - La due date di un task o sottotask deve essere impostata, al massimo, entro l’ultimo giorno del mese di competenza. In questo modo, le attività risultano correttamente riconducibili al relativo mese di riferimento, consentendo di automatizzare il monitoraggio mensile del VDP. Qualora un’attività non venga completata entro la data ultima prevista, ricadente nel mese di competenza, sarà necessario riaprire un nuovo task e i relativi sottotask, indicando come Target Production esclusivamente le quantità ancora da lavorare. - La due-date di un sottotask deve essere necessariamente relativa alla tempistica di chiusura attesa per il sottotask in oggetto. Non può essere riferita alle tempistiche complessive di conclusione dell’attività (task) né alle tempistiche di rilascio complessivo di uno sviluppo, altrimenti si genera una rilevazione errata del dato
Elaborazione dei ticket livello sottotask (-1)* * sono compresi anche gli Issue Type Bug e Help Desk dell’Area IT. Sebbene tecnicamente tali Issue Type siano collocati al livello (0) di Jira, ai fini del presente processo devono essere gestiti con lo stesso comportamento previsto per i sottotask	Professional	- Lo stato “To do” indica che un’attività è pronta per essere lavorata ed è stata assegnata ad una risorsa. Non è possibile associare a stato “To do” dei task che non hanno un assegnatario o che hanno campi mancanti - Lo stato “In progress” indica che un’attività è in lavorazione. È consentito portare il ticket in progress solo all’effettivo avvio dell’attività - Lo stato “In Pending” indica che un’attività è temporaneamente sospesa (es. nel caso in cui sia necessario dedicarsi temporaneamente ad altre attività o a fine giornata). Non è consentito inserire lo stato “In Pending” quando l’attività è conclusa ed in attesa di validazione - Lo stato “Done” indica che la lavorazione da parte del professional è conclusa. Ogni attività conclusa deve essere messa in stato Done, anche se in attesa di validazione del coordinatore - Stato “KO” indica una lavorazione interrotta per volontà del cliente. In questo caso è sempre necessario motivare la richiesta di annullamento. Tale stato sarà soggetto a revisione di Data Quality - Lo stato “Cancelled” indica una lavorazione interrotta per necessità interne. Necessario motivare la richiesta di annullamento - Actual Production: Ogni professional è tenuto a dichiarare l’Actual Production con cadenza giornaliera: nel caso di sottotask finito entro la giornata dichiarerà la produzione finale effettiva, nel caso di sottotask che dura più di una giornata dichiarerà la % di avanzamento della produzione effettiva giornaliera (campo “Actual Production progress (%)”) - Modulo tempo: il modulo tempo Timesheet legge il tempo (registrato in automatico da jira) impiegato per elaborare un sottotask - quantificando il periodo trascorso dal sottotask nella Status Category “In Progress”
Validazione dei task e sottotask	Project Manager/ Service Manager	- Quando il Professional conclude il sottotask lo passa in stato “Done”, a quel punto Il SM supervisiona la qualità della lavorazione e se sono necessari dei feedback apre un sottotask di “Rework”. Non è possibile fornire dei feedback che vengano indirizzati riaprendo il sotto-task in oggetto ma è sempre necessario aprire un sottotask “Rework” dedicato. Attività soggetta a controllo di Data Quality - Nel momento in cui tutti i sottotask di un task sono terminati, il task si sposta in automatico in stato “PM Approval”, se questo si trova nello stato “In Progress”. Il PM ne riceve notifica e verifica l’adeguatezza dei livelli di produzione, se idonei sposta il task in “Done” se non è idoneo apre un ulteriore task. - Per le attività che richiedono Quality Check, il Service Manager apre un sotto-task di Quality Check alla risorsa assegnata all’attività. Non è possibile assegnare il sotto-task del Quality Check alla risorsa che ha elaborato il sotto-task da verificare; il sotto-task da verificare deve essere sempre in stato “Done”
Staffing	Service Manager	- Al momento dell’avvio della commessa, sposta il ticket dello spazio fittizio creato in fase di pre-staffing nello spazio reale di commessa per mettere lo staffing effettivo o elimina il ticket fittizio ormai non più necessario e ne crea uno nuovo nello spazio reale. Questo è necessario al fine di evitare duplicazioni di staffing

c. Indicazioni operative integrative

Le attività attribuite al Service Manager possono essere gestite anche dal Team Leader, ove previsto dall’organizzazione dell’Area di Competenza.

Il timesheet gestito in MySond deve risultare coerente con quanto registrato in Jira in termini di commessa lavorata. Le tempistiche possono tuttavia non risultare perfettamente coincidenti, in quanto le ore produttive rilevate in Jira possono non corrispondere al totale delle ore lavorate, ad esempio in presenza di attività quali riunioni o formazione.

La definizione della roadmap di commessa e della relativa struttura gerarchica deve essere coerente con la tipologia di contratto e con i deliverable fatturabili. In particolare:

• se il deliverable contrattuale contiene più elementi fatturabili, viene creata un’Iniziativa
• se il deliverable contrattuale coincide con un solo elemento fatturabile, non viene utilizzata l’Iniziativa
• per ciascun elemento fatturabile con deliverable esplicito viene creato un Epic, corrispondente a una singola voce contrattuale, ovvero all’elemento fatturabile definito nell’ elenco prezzi, caricato in SAP a livello di “Work Package”
• in assenza di un elemento fatturabile o di un deliverable esplicito, l’attività viene gestita tramite Task e Sottotask, in accordo con AFC
• qualora la realizzazione dell’Epic richieda più attività operative, vengono creati più Task in presenza di una sola attività operativa viene creato un unico Task
• i Sottotask rappresentano le attività operative unitarie assegnate ai singoli Professional, creando quindi una ripartizione dell’attività definita nel Task-padre. Se l’attività viene assegnata a un singolo Professional e/o non è necessario fare ulteriori suddivisioni, il sottotask sarà unico. I sottotask devono contenere le informazioni necessarie alla pianificazione e alla definizione dei target produttivi

7. Strumenti integrati

Il perimetro software deborda le funzionalità standard di Jira, affidandosi a strumenti e plugin essenziali per soddisfare le ambizioni architetturali di EagleProjects, collegando la produzione giornaliera alla previsione di bilancio a lungo termine.

a. Tempo Timesheet e Tempo Capacity Planner

Gli strumenti forniti dalla suite “Tempo” rappresentano il sistema cardine per il monitoraggio della saturazione dei team e per il consuntivo delle ore produttive effettivamente impiegate dalle risorse.

i. Introduzione

Il pacchetto Tempo consente una dualità di controllo indispensabile:

• Il “Timesheet” serve a certificare, contabilizzare a posteriori quanto effort sia stato speso su un dato Sottotask in termini di sole ore produttive lavorate
• Il “Capacity Planner” rappresenta invece lo strato di simulazione preventiva, impiegato quotidianamente dal Service Manager per assicurare che la saturazione orizzontale dei propri “Tempo Team” sia realistica, bilanciando le richieste conflittuali di commesse multiple e impedendo sovraccarichi

ii. Interfaccia utente

L’interfaccia di Tempo segue una logica di inclusione ben definita: affinché un ticket venga recepito e reso manipolabile ai fini della pianificazione, deve possedere un set minimo di attributi. Un Task o Sottotask privo di Tempo Team, Assegnatario, Data di scadenza e Stima Originale risulta “invisibile” per il Capacity Planner e per le estrazioni di pianificazione.

iii. Gestione ruoli e permessi dei team

La configurazione strutturale e l'assegnazione nei Capacity Planner sono esclusive prerogative del Service Manager. Il parametro fondamentale è il campo Tempo Team, che sgancia il tracciamento orario dal singolo utente per aggregarlo al centro di costo del reparto.

Il Project Manager osserva questi aggregati a un livello macroscopico per valutare il rischio di progetto, ma non ha l'autorità di alterarne i membri o la distribuzione interna.

Nota: nelle estrazioni da Capacity Planner prevale il Team associato alla risorsa nel plug-in rispetto al campo Tempo Team del Task; il Service Manager presidia la corretta configurazione di Team e risorse.

iv. Creazione di report

La combinazione tra le estrazioni Tempo e la gerarchia Jira produce reportistiche cruciali per i reparti di controllo. L’attenzione del plugin Tempo si concentra principalmente sul confronto tra le ore lavorate e le ore pianificate.

Il controllo della produzione e della qualità delle lavorazioni segue invece logiche e responsabilità distinte, che devono essere definite in funzione dei ruoli coinvolti.

v. Funzionalità specifiche di Timesheet

L'aspetto determinante del Timesheet è che calcola le ore impiegate in automatico collegandosi direttamente agli stati del ticket. Come precedentemente dettagliato, portare un ticket in IN PROGRESS attiva il contatore; muoverlo in stati di sospensione lo arresta.

La registrazione manuale del log di lavoro è sempre consentita; la modifica di un log già registrato è invece soggetta ai permessi associati al ruolo dell’utente. Lasciare un ticket in stato IN PROGRESS oltre il periodo effettivo di lavorazione può determinare una rilevazione non corretta delle ore e generare scostamenti nel Timesheet.

vi. Funzionalità specifiche di Capacity Planner (Epic Fittizi)

Per colmare il distacco temporale tra il momento in cui una commessa è concepita e la sua puntuale granularizzazione operativa in Sottotask stimati, la prassi adotta uno strumento metodologico noto come Epic Fittizio (o ticket fittizio di ingaggio).

Il Project Manager inoltra questo Epic al Service Manager, fungendo da “prenotazione a maglia larga” (non un'assegnazione nominale, ma una prenotazione di team) della capacità operativa per le settimane o i mesi venturi. Una volta ricevuta conferma di fattibilità, il Project Manager crea i veri Task operativi.

Man mano che i Sottotask reali vengono assegnati nominalmente con stime precise, il Service Manager ha l'obbligo di ridurre proporzionalmente la stima appoggiata sull'Epic Fittizio originario.

Per maggiori informazioni consultare: Guida Tempo – Timesheet e Capacity_v0.pdf

b. Jira Discovery

Questo modulo consente di gestire un livello di astrazione superiore rispetto agli elementi presenti negli Spazi Jira, mantenendo la possibilità di collegare tra loro i diversi oggetti. Lo strumento permette quindi di costruire roadmap di alto livello utili ai Project Manager per la governance delle commesse lungo l’intero ciclo di vita.

i. Macroambito/ Idea (interfaccia utente, campi disponibili, workflow, modalità di creazione)

Nella prassi, l'Iniziativa (Livello 2) o un oggetto “Idea” incarna il Macroambito. Il Project Manager sfrutta le viste di Jira Product Discovery (JPD) per delineare i fabbisogni strategici, tracciare le dipendenze e associarvi milestone temporali di massima, ancor prima di spingersi nel dettaglio dei Task e dei centri di costo.

ii. Collegamento tra Macroambito/Idea ed Epic

La continuità concettuale postula che un'Idea generica in Discovery possa confluire in uno o più Epic esecutivi contrattualizzati nel progetto Jira, tramutandosi da strategia a execution.

Tramite i link incrociati, il tracciamento della roadmap permette di evincere come un ritardo su un Epic collegato vada ad impattare la baseline temporale dell'Idea in Discovery, fungendo da cassa di risonanza precoce verso gli stakeholder.

iii. Viste

Le viste di Roadmap di Commessa e le Roadmap JPD aggregano l'avanzamento, incrociando lo stato embrionale delle Idee con l'effettivo avanzamento dei Task legati agli Epic. Le viste fungono da strumento principale per i meeting di allineamento con i clienti (come evidenziato nel vademecum PM-06).

iv. Addendum - Scelta dei modelli di gestione della commessa

La decisione di instradare un progetto su JPD, di impiegare Iniziative di Livello 2 (per contratti multi-deliverable e fatturazione a SAL), o di condensare la commessa unicamente in Epic semplici per una fatturazione 1:1, non è rimessa all'improvvisazione. È delineata in un addendum specifico sulle scelte architetturali (“Scelta dei modelli di gestione commessa”) e guidata da criteri volumetrici e di complessità di fatturazione. Questa scelta plasma indelebilmente l'intero Spazio e le procedure conseguenti per l'intero ciclo di vita.

Per maggiori informazioni consultare: Guida Jira Discovery per Roadmap.pdf

Per maggiori informazioni consultare: Addendum Modelli Gestione Commessa_v0.pdf

c. JXL Sheets

JXL Sheets rappresenta uno strumento semplice e operativo per effettuare modifiche massive sugli elementi Jira e consultare rapidamente informazioni di diversa natura, attraverso un’interfaccia simile a un foglio Excel.

Lo strumento risulta particolarmente utile per gli utenti abituati alla gestione tramite fogli elettronici, facilitando attività di aggiornamento e gestione massiva dei dati.

Per maggiori informazioni consultare: Guida Rapida all’Utilizzo di JXL Sheets

Come delineato dalla mappa dei contenuti, la definizione specifica di foglio, i metodi di creazione, le modifiche in bulk e l'interpretazione della legenda icone per questo specifico add-on sono delegati a un documento manualistico a parte integrato nell'ecosistema, concentrando l'uso operativo primario sulla capacità di alterazione massiva dei dati di classificazione in caso di riorganizzazioni strutturali.

8. Annex

Tabella 1 – Iniziativa: campi e regole di compilazione

In creazione

Campo	Descrizione	Tipo campo	Obbligo	Compil.	Tab	Note
Riepilogo (Summary)	Breve sintesi del contenuto dell'attività, utile per identificare rapidamente l'oggetto del ticket.	string	BLOCCA	Manuale	General
Tipo ticket (Issue Type)	Categoria Jira del ticket (es. Iniziativa, Epic, Task).	single-select	BLOCCA	Manuale	General
Richiedente (Reporter)	Utente che ha creato o richiesto il ticket.	Single-select User Picker	BEST PRACTICE	AUTO	General	Se NON modificato: verrà compilato automaticamente con l'utente che sta creando il ticket.
Data consegna cliente (Customer Delivery Date)	Data di consegna pianificata con il Cliente.	Date Picker	BEST PRACTICE	Manuale	Pianificazione
Feature	Indica se l'attività rappresenta una funzionalità di prodotto/software.	Radio Button (single-select)	BEST PRACTICE	Manuale	Info IT	Per l’Area IT: contrassegnare con “true” nel caso il ticket identifichi la Funzionalità da sviluppare
Workflow Status	Indica lo stato specifico del workflow nel quale si trova il ticket.	Jira-workflow status	BEST PRACTICE	Manuale	General

Inizio lavorazione (stati TO DO)

Campo	Descrizione	Tipo campo	Obbligo	Compil.	Tab	Note
Assegnatario (Assignee)	Utente responsabile del completamento del ticket.	Single-select User Picker	BEST PRACTICE	Manuale	General
Data di inizio (Start Date)	Data di avvio effettiva dell'attività.	Date Picker	BEST PRACTICE	AUTO	System	Valorizzata dal sistema al passaggio in IN PROGRESS; azzerata se il ticket rientra in TO DO o IN PENDING.
Start date pianificato (Planned Start Date)	Data di inizio pianificata per l'attività.	Date Picker	BEST PRACTICE	Manuale	Pianificazione
Data di scadenza (Due Date)	Data di fine pianificata per l'attività.	Date Picker	BEST PRACTICE	Manuale	Pianificazione

Chiusura (stati DONE / KO / CANCELLED)

Campo	Descrizione	Tipo campo	Obbligo	Compil.	Tab	Note
End date	Data di completamento effettiva dell'attività.	Date Picker	BEST PRACTICE	AUTO	System	Valorizzata dal sistema alle transizioni DONE, KO e CANCELLED.
Risoluzione (Resolution)	Categorizzazione dello stato finale del ticket al momento della chiusura.	single-select	BEST PRACTICE	AUTO	General	Impostata dal sistema in base allo stato finale: Completato per DONE, Non sarà fatto per KO e CANCELLED.

Facoltativi — nessun obbligo di sistema o procedurale

Campo	Descrizione	Tipo campo	Obbligo	Compil.	Tab	Note
Stima originale (Original Estimate)	Tempo stimato inizialmente per completare l'attività.	Time Tracking	—	Manuale	Pianificazione
Etichette (Labels)	Parole chiave utilizzate per categorizzare o filtrare i ticket.	Labels	—	Manuale	General
Priorità	Livello di priorità assegnato all'attività.	single-select	—	Manuale	General
Allegato (Attachment)	File o documenti allegati al ticket.	attachment	—	Manuale	General
Descrizione (Description)	Dettaglio esteso descrittivo del ticket.	multiline	—	Manuale	General
Ticket collegati (Linked Issues)	Riferimenti ad altri ticket collegati o dipendenti.	Jira-link	—	Manuale	General
Obiettivi (Goals)	Collega l'Iniziativa a traguardi strategici definiti in Atlas, per monitorare l'allineamento ai risultati di business.	Atlassian Goal picker	—	Manuale	General
Multiple Assignee	Campo opzionale per indicare più utenti responsabili.	Multi-select User Picker	—	Manuale	System	L'uso multiplo non è consigliato come best practice.
Multiple teams	Campo opzionale per indicare più squadre coinvolte.	Multi-select Team Picker	—	Manuale	System	L'uso multiplo non è consigliato come best practice.
Versioni di correzione (Fix Versions)	Versione in cui il ticket viene risolto o per la quale è pianificata la risoluzione.	Date Picker	—	Manuale	Info IT
Note	Spazio dedicato ad annotazioni interne integrative, senza modificare la descrizione principale.	multiline	—	Manuale	Note
Rework	Indica se l'attività rientra tra i rework causati da fattori interni, con costo imputabile alla commessa.	Radio Button (single-select)	—	Manuale	System	L’obbligatorietà si verifica solo nei casi in cui l’attività rientri nella tipologia rework
Codice Demand (Demand Code)	Identificativo univoco della richiesta di prodotto o servizio da parte del cliente.	string	—	Manuale	Info IT
Fornitore-Provider (Supplier / Provider)	Fornitore esterno che eroga il servizio correlato all'attività.	single-select	—	Manuale	System	Per aggiornare le voci presenti nel menu a tendina, è necessario aprire un ticket di supporto tramite l’Helpdesk Jira.
Data consegna Stima (Estimate Delivery Date)	Data in cui la stima viene condivisa con gli stakeholder.	Date Picker	—	Manuale	Info IT
Data approvazione tecnica (Technical Approval Date)	Data in cui la soluzione o l'approccio tecnico vengono approvati.	Date Picker	—	Manuale	Info IT
Data approvazione HLD (HLD Approval Date)	Data in cui viene approvato il documento di High-Level Design.	Date Picker	—	Manuale	Info IT
Data Invio HLD (HLD Submission Date)	Data in cui il documento di High-Level Design viene inviato per revisione.	Date Picker	—	Manuale	Info IT
Data consegna TestList (Test List Delivery Date)	Data in cui la lista dei test (o piano di test) viene consegnata.	Date Picker	—	Manuale	Info IT
Data approvazione stima (Estimate Approval Date)	Data in cui i dati relativi alle stime comunicati al cliente vengono approvati.	Date Picker	—	Manuale	Info IT
Comune (Municipality)	Comune di riferimento dell'attività.	single-select	—	Manuale	Localizzazione
Provincia (Province)	Provincia di riferimento dell'attività.	single-select	—	Manuale	Localizzazione
Regione	Regione di riferimento dell'attività.	single-select	—	Manuale	Localizzazione
Data fine ripianificata (Rescheduled End Date)	Nuova data di fine a seguito di ripianificazione.	Date Picker	—	Manuale	System

Tabella 2 – Epic: campi e regole di compilazione

In creazione

Campo	Descrizione	Tipo campo	Obbligo	Compil.	Tab	Note
Riepilogo (Summary)	Breve sintesi del contenuto dell'attività.	string	BLOCCA	Manuale	General
Tipo ticket (Issue Type)	Categoria Jira del ticket (es. Epic).	single-select	BLOCCA	Manuale	General
Richiedente (Reporter)	Utente che ha creato o richiesto il ticket.	Single-select User Picker	BEST PRACTICE	AUTO	General	Se NON modificato: verrà compilato automaticamente con l'utente che sta creando il ticket.
EPICKEY	Collegamento custom all'epic di riferimento (utilizzato anche per sottoelementi non direttamente figli di un epic).	string	BEST PRACTICE	AUTO	System
Production Units	Unità di misura della produzione associata all'attività monitorata nel Task. E’ definita dalla voce di listino contrattuale.	single-select	BEST PRACTICE	Manuale	Produzione
Feature	Indica se l'attività rappresenta una funzionalità di prodotto/software.	Radio Button (single-select)	BEST PRACTICE	Manuale	Info IT	Per l’Area IT: contrassegnare con “true” nel caso il ticket identifichi la Funzionalità da sviluppare
Workflow Status	Stato specifico del workflow in cui si trova il ticket.	Jira-workflow status	BEST PRACTICE	Manuale	General

Inizio lavorazione (stati TO DO)

Campo	Descrizione	Tipo campo	Obbligo	Compil.	Tab	Note
Assegnatario (Assignee)	Utente responsabile del completamento del ticket.	Single-select User Picker	BEST PRACTICE	Manuale	General
Data di inizio (Start Date)	Data di avvio effettiva dell'attività.	Date Picker	BEST PRACTICE	AUTO	System	Valorizzata dal sistema al passaggio in IN PROGRESS; azzerata se il ticket rientra in TO DO o IN PENDING.
Contract Revenue Type	Voce di listino contrattuale, sincronizzata da SAP che collega l'attività al relativo valore economico. Usata per calcolare fatturato avanzamento VDP.	single-select	BLOCCA · BEST PRACTICE	Manuale	Produzione	Obbligatorio al passaggio in TO DO insieme a Start date pianificato e Data di scadenza: se manca, Jira blocca la transizione. I valori derivano dai Work Package del progetto SAP.
Start date pianificato (Planned Start Date)	Data di inizio pianificata per l'attività.	Date Picker	BLOCCA · BEST PRACTICE	Manuale	Pianificazione
Data di scadenza (Due Date)	Data di fine pianificata per l'attività.	Date Picker	BLOCCA · BEST PRACTICE	Manuale	Pianificazione	Campo collegato: aggiorna automaticamente la data fine nella Roadmap JPD.

Chiusura (IN PROGRESS → PM APPROVAL → DONE / KO / CANCELLED)

Campo	Descrizione	Tipo campo	Obbligo	Compil.	Tab	Note
End date	Data di completamento effettiva dell'attività.	Date Picker	BEST PRACTICE	AUTO	System	Valorizzata dal sistema alla transizione «Lavorazione completa da verificare» (IN PROGRESS → PM APPROVAL) e alle chiusure KO / CANCELLED.
Risoluzione (Resolution)	Categorizzazione dello stato finale del ticket alla chiusura.	single-select	BEST PRACTICE	AUTO	General	Impostata dal sistema: Completato alla transizione «Lavorazione verificata»; Non sarà fatto per KO e CANCELLED.
Actual Production	Rappresenta la produzione effettiva rispetto alle quantità previste nel Target production.	Number (decimale)	BLOCCA · BEST PRACTICE	Manuale	Produzione	Obbligatoria alla transizione «Lavorazione verificata» (PM APPROVAL → DONE): il sistema apre una schermata dedicata e rifiuta il passaggio se il valore è vuoto o pari a 0.

Facoltativi — nessun obbligo di sistema o procedurale

Campo	Descrizione	Tipo campo	Obbligo	Compil.	Tab	Note
Principale (Parent)	Riferimento automatico al ticket genitore (Iniziativa).	Jira-link	—	Manuale	General
Stima originale (Original Estimate)	Tempo stimato inizialmente per completare l'attività.	Time Tracking	—	Manuale	Pianificazione
Etichette (Labels)	Parole chiave per categorizzare o filtrare i ticket.	Labels	—	Manuale	General
Priorità	Livello di priorità assegnato all'attività.	single-select	—	Manuale	General
Allegato (Attachment)	File o documenti allegati al ticket.	attachment	—	Manuale	General
Descrizione (Description)	Dettaglio esteso descrittivo del ticket.	multiline	—	Manuale	General
Ticket collegati (Linked Issues)	Riferimenti ad altri ticket collegati o dipendenti.	Jira-link	—	Manuale	General
Obiettivi (Goals)	Collega l'Epic a traguardi strategici definiti in Atlas.	Atlassian Goal picker	—	Manuale	General
Team	Team di riferimento dell'assegnatario dell'attività.	Single-select Team (Jira) Picker	—	Manuale	System
Tempo Team	Team di riferimento per la rilevazione tempo tramite plug-in Tempo.	Single-select Team (Tempo) Picker	—	Manuale	Pianificazione
Multiple Assignee	Campo opzionale per indicare più utenti responsabili.	Multi-select User Picker	—	Manuale	System	Non consigliato come best practice.
Multiple teams	Campo opzionale per indicare più squadre coinvolte.	Multi-select Team Picker	—	Manuale	System	Non consigliato come best practice.
Versioni di correzione (Fix Versions)	Versione in cui il ticket viene risolto o pianificato per la risoluzione.	Date Picker	—	Manuale	Info IT
Data consegna cliente (Customer Delivery Date)	Data di consegna pianificata con il Cliente.	Date Picker	—	Manuale	Pianificazione
Target Production	Quantità di produzione pianificata per l'attività.	Number (decimale)	—	Manuale	Produzione
Note	Annotazioni interne integrative.	multiline	—	Manuale	Note
Rework	Indica se l'attività rientra tra i rework causati da fattori interni.	Radio Button (single-select)	—	Manuale	System	L’obbligatorietà si verifica solo nei casi in cui l’attività rientri nella tipologia rework
Codice Demand (Demand Code)	Identificativo univoco della richiesta di prodotto o servizio del cliente.	string	—	Manuale	Info IT
Fornitore-Provider (Supplier / Provider)	Fornitore esterno che eroga il servizio correlato all'attività.	single-select	—	Manuale	General	Per aggiornare le voci presenti nel menu a tendina, è necessario aprire un ticket di supporto tramite l’Helpdesk Jira.
Data consegna Stima (Estimate Delivery Date)	Data in cui la stima viene condivisa con gli stakeholder.	Date Picker	—	Manuale	Info IT
Data approvazione tecnica (Technical Approval Date)	Data in cui la soluzione o l'approccio tecnico vengono approvati.	Date Picker	—	Manuale	Info IT
Data approvazione HLD (HLD Approval Date)	Data in cui viene approvato il documento di High-Level Design.	Date Picker	—	Manuale	Info IT
Data Invio HLD (HLD Submission Date)	Data in cui il documento HLD viene inviato per revisione.	Date Picker	—	Manuale	Info IT
Data consegna TestList (Test List Delivery Date)	Data in cui la lista dei test (o piano di test) viene consegnata.	Date Picker	—	Manuale	Info IT
Data approvazione stima (Estimate Approval Date)	Data in cui i dati relativi alle stime comunicati al cliente vengono approvati.	Date Picker	—	Manuale	Info IT
Comune (Municipality)	Comune di riferimento dell'attività.	single-select	—	Manuale	Localizzazione
Provincia (Province)	Provincia di riferimento dell'attività.	single-select	—	Manuale	Localizzazione
Regione	Regione di riferimento dell'attività.	single-select	—	Manuale	Localizzazione
Data fine ripianificata (Rescheduled End Date)	Nuova data di fine a seguito di ripianificazione.	Date Picker	—	Manuale	System

Tabella 3 – Task: campi e regole di compilazione

In creazione

Campo	Descrizione	Tipo campo	Obbligo	Compil.	Tab	Note
Riepilogo (Summary)	Breve sintesi del contenuto dell'attività.	string	BLOCCA	Manuale	General
Tipo ticket (Issue Type)	Categoria Jira del ticket (Task, Story, Bug, Redazione documentazione, Hardware/DevOps, Helpdesk, Rilascio).	single-select	BLOCCA	Manuale	General
Principale (Parent)	Riferimento automatico al ticket genitore (Epic) per l'attività.	Jira-link	BEST PRACTICE	AUTO	General
Richiedente (Reporter)	Utente che ha creato o richiesto il ticket.	Single-select User Picker	BEST PRACTICE	AUTO	General	Se NON modificato: verrà compilato automaticamente con l'utente che sta creando il ticket.
Assegnatario (Assignee)	Utente responsabile del completamento del ticket.	Single-select User Picker	BEST PRACTICE	Manuale	General	Deve essere assegnato dal PM al Service Manager — è il SM che gestisce la pianificazione operativa
Start date pianificato (Planned Start Date)	Data di inizio pianificata per l'attività.	Date Picker	BLOCCA · BEST PRACTICE	Manuale	Pianificazione
Data di scadenza (Due Date)	Data di fine pianificata per l'attività.	Date Picker	BLOCCA · BEST PRACTICE	Manuale	Pianificazione
Contract Revenue Type	Voce di listino contrattuale, sincronizzata da SAP che collega l'attività al relativo valore economico. Usata per calcolare fatturato avanzamento VDP.	single-select	BLOCCA · BEST PRACTICE	Manuale	Produzione	I valori di questo campo vengono automaticamente creati e modificati da SAP tramite un automatismo che si attiva una volta al giorno
Activity Budget Share	Peso % attività rispetto alla voce listino di riferimento. In fase di budgeting, ogni voce contrattuale può essere suddivisa in sotto-attività, ciascuna con un proprio peso %, utilizzato per monitorare l’avanzamento economico della commessa.	Number (percentuale)	BLOCCA · BEST PRACTICE	Manuale	Produzione	Obbligatorio alla creazione del Task: se vuoto, Jira non consente di creare il ticket. Va compilato con la percentuale indicata nel budget di commessa già approvato. Non viene propagato ai Sottotask. In assenza di questo campo, le attività non concorrono al fatturato e al monitoraggio del VDP.
Service Type	Identifica il tipo di servizio aziendale svolto per il completamento del Deliverable. E' composto servizio + attività effettivamente svolta prevista anche in fase di budgeting.	Select List-cascading	BLOCCA · BEST PRACTICE	Manuale	General
Production Units	Unità di misura della produzione associata all'attività monitorata nel Task. E’ definita dalla voce di listino contrattuale.	single-select	BLOCCA · BEST PRACTICE	Manuale	Produzione
Target Production	Quantità di produzione pianificata per l'attività.	Number (decimale)	BLOCCA · BEST PRACTICE	Manuale	Produzione
Link Epic	Collegamento default all'epic di riferimento nel sistema Jira.	Jira-Epic Link	BEST PRACTICE	AUTO	System	Valorizzato dal sistema alla creazione con il collegamento all'Epic padre. Sulla schermata il campo di sistema equivalente si chiama «Collegamento all'epic».
EPICKEY	Collegamento custom all'epic di riferimento (anche per sottoelementi non direttamente figli di un epic).	string	BEST PRACTICE	AUTO	System
Rework	Indica se l'attività rientra tra i rework causati da fattori interni.	Radio Button (single-select)	BEST PRACTICE	Manuale	General	L’obbligatorietà si verifica solo nei casi in cui l’attività rientri nella tipologia rework- campo utile per il calcolo KPI
Workflow Status	Stato specifico del workflow in cui si trova il ticket.	Jira-workflow status	BEST PRACTICE	Manuale	General

Passaggio in TO DO

Campo	Descrizione	Tipo campo	Obbligo	Compil.	Tab	Note
Tempo Team	Team di riferimento per la rilevazione tempo tramite plug-in Tempo.	Single-select Team (Tempo) Picker	BLOCCA · BEST PRACTICE	Manuale	Pianificazione

Passaggio in IN PROGRESS

Campo	Descrizione	Tipo campo	Obbligo	Compil.	Tab	Note
Data di inizio (Start Date)	Data di avvio effettiva dell'attività.	Date Picker	BEST PRACTICE	AUTO	Pianificazione	Valorizzata dal sistema alla transizione «Inizio lavorazione» (TO DO → IN PROGRESS).

Lavorazione completata (IN PROGRESS → PM APPROVAL)

Campo	Descrizione	Tipo campo	Obbligo	Compil.	Tab	Note
End date	Data di completamento effettiva dell'attività.	Date Picker	BEST PRACTICE	AUTO	Pianificazione	Valorizzata dal sistema alla transizione «Lavorazione completata» (IN PROGRESS → PM APPROVAL).

Lavorazione verificata (PM APPROVAL → DONE)

Campo	Descrizione	Tipo campo	Obbligo	Compil.	Tab	Note
Actual Production	Rappresenta la produzione effettiva rispetto alle quantità previste nel Target production.	Number (decimale)	BLOCCA · BEST PRACTICE	Manuale	Produzione	Al passaggio in PM APPROVAL il sistema pubblica nei commenti la somma degli Actual Production dei Sottotask. Alla transizione «Lavorazione verificata» si apre una schermata dedicata: il PM valida o corregge il valore, altrimenti la transizione viene rifiutata.
Risoluzione (Resolution)	Categorizzazione dello stato finale del ticket alla chiusura.	single-select	BEST PRACTICE	AUTO	General	Impostata dal sistema in base allo stato finale: Completato per DONE, Non sarà fatto per KO e CANCELLED.

Facoltativi — nessun obbligo di sistema o procedurale

Campo	Descrizione	Tipo campo	Obbligo	Compil.	Tab	Note
Team	Team di riferimento dell'assegnatario.	Single-select Team (Jira) Picker	—	Manuale	General
Stima originale (Original Estimate)	Tempo stimato inizialmente per completare l'attività.	Time Tracking	—	Manuale	Pianificazione
Etichette (Labels)	Parole chiave per categorizzare o filtrare i ticket.	Labels	—	Manuale	General
Priorità	Livello di priorità assegnato all'attività.	single-select	—	Manuale	General
Allegato (Attachment)	File o documenti allegati al ticket.	attachment	—	Manuale	General
Descrizione (Description)	Dettaglio esteso descrittivo del ticket.	multiline	—	Manuale	General
Ticket collegati (Linked Issues)	Riferimenti ad altri ticket collegati o dipendenti.	Jira-link	—	Manuale	General
Multiple Assignee	Campo opzionale per indicare più utenti responsabili.	Multi-select User Picker	—	Manuale	System	Non consigliato come best practice.
Multiple teams	Campo opzionale per indicare più squadre coinvolte.	Multi-select Team Picker	—	Manuale	System	Non consigliato come best practice.
Versioni di correzione (Fix Versions)	Versione in cui il ticket viene risolto o pianificato per la risoluzione.	Date Picker	—	Manuale	Info IT
Note	Annotazioni interne integrative.	multiline	—	Manuale	Note
Data Invio HLD (HLD Submission Date)	Data in cui il documento HLD viene inviato per revisione.	Date Picker	—	Manuale	Info IT
Fornitore-Provider (Supplier / Provider)	Fornitore esterno che eroga il servizio correlato.	single-select	—	Manuale	General	Per aggiornare le voci presenti nel menu a tendina, è necessario aprire un ticket di supporto tramite l’Helpdesk Jira.
Comune (Municipality)	Comune di riferimento dell'attività.	single-select	—	Manuale	Localizzazione
Provincia (Province)	Provincia di riferimento dell'attività.	single-select	—	Manuale	Localizzazione
Regione	Regione di riferimento dell'attività.	single-select	—	Manuale	Localizzazione
Asset richiesti (Required Assets)	Asset o strumentazione necessari alla lavorazione.	string	—	Manuale	General
Σ stima originale (Σ Original Estimate)	Somma delle stime originali dei ticket figli.	Time Tracking	—	AUTO	Pianificazione	Calcolato dal sistema.

Tabella 4 – Story: campi e regole di compilazione

In creazione

Campo	Descrizione	Tipo campo	Obbligo	Compil.	Tab	Note
Riepilogo (Summary)	Breve sintesi del contenuto dell'attività.	string	BLOCCA	Manuale	General
Tipo ticket (Issue Type)	Categoria Jira del ticket (Task, Story, Bug, Redazione documentazione, Hardware/DevOps, Helpdesk, Rilascio).	single-select	BLOCCA	Manuale	General
Principale (Parent)	Riferimento automatico al ticket genitore (Epic) per l'attività.	Jira-link	BEST PRACTICE	AUTO	General
Contract Revenue Type	Voce di listino contrattuale, sincronizzata da SAP che collega l'attività al relativo valore economico. Usata per calcolare fatturato avanzamento VDP.	single-select	BLOCCA · BEST PRACTICE	Manuale	Produzione	I valori di questo campo vengono automaticamente creati e modificati da SAP tramite un automatismo che si attiva una volta al giorno
Activity Budget Share	Peso % attività rispetto alla voce listino di riferimento. In fase di budgeting, ogni voce contrattuale può essere suddivisa in sotto-attività, ciascuna con un proprio peso %, utilizzato per monitorare l’avanzamento economico della commessa.	Number (percentuale)	BLOCCA · BEST PRACTICE	Manuale	Produzione	Obbligatorio alla creazione del Task: se vuoto, Jira non consente di creare il ticket. Va compilato con la percentuale indicata nel budget di commessa già approvato. Non viene propagato ai Sottotask. In assenza di questo campo, le attività non concorrono al fatturato e al monitoraggio del VDP.
Production Units	Unità di misura della produzione associata all'attività monitorata nel Task. E’ definita dalla voce di listino contrattuale.	single-select	BLOCCA · BEST PRACTICE	Manuale	Produzione
Service Type	Identifica il tipo di servizio aziendale svolto per il completamento del Deliverable. E' composto servizio + attività effettivamente svolta prevista anche in fase di budgeting.	Select List-cascading	BLOCCA · BEST PRACTICE	Manuale	Produzione
EPICKEY	Collegamento custom all'epic di riferimento (anche per sottoelementi non direttamente figli di un epic).	string	BEST PRACTICE	AUTO	System
Richiedente (Reporter)	Utente che ha creato o richiesto il ticket.	Single-select User Picker	—	AUTO	General	Se NON modificato -> verrà compilato automaticamente con l'utente che sta creando il ticket.
Workflow Status	Stato specifico del workflow in cui si trova il ticket.	Jira-workflow status	BEST PRACTICE	Manuale	General

Passaggio in Stima (CREATED → Stima)

Campo	Descrizione	Tipo campo	Obbligo	Compil.	Tab	Note
Tempo Team	Team di riferimento per la rilevazione tempo tramite plug-in Tempo.	Single-select Team (Tempo) Picker	BLOCCA · BEST PRACTICE	Manuale	Pianificazione
Target Production	Quantità di produzione pianificata per l'attività.	Number (decimale)	BLOCCA · BEST PRACTICE	Manuale	Produzione	Per l’area IT, il campo rappresenta la stima iniziale delle ore di lavoro previste dal PM nel budget di commessa.
Start date pianificato (Planned Start Date)	Data di inizio pianificata per l'attività.	Date Picker	BLOCCA · BEST PRACTICE	Manuale	Pianificazione
Data di scadenza (Due Date)	Data di fine pianificata per l'attività.	Date Picker	BLOCCA · BEST PRACTICE	Manuale	Pianificazione
Assegnatario (Assignee)	Utente responsabile del completamento del ticket.	Single-select User Picker	BEST PRACTICE	Manuale	General	Deve essere assegnato dal PM al Service Manager o assicurarsi che riceva notifica che deve gestire la pianificazione

Presa in carico (Stima → IN PROGRESS)

Campo	Descrizione	Tipo campo	Obbligo	Compil.	Tab	Note
Data di inizio (Start Date)	Data di avvio effettiva dell'attività.	Date Picker	BEST PRACTICE	AUTO	Pianificazione	Valorizzata dal sistema alla transizione «Presa in carico».

Rilascio e chiusura (RELEASE → DONE; RESOLVED)

Campo	Descrizione	Tipo campo	Obbligo	Compil.	Tab	Note
End date	Data di completamento effettiva dell'attività.	Date Picker	BEST PRACTICE	AUTO	Pianificazione	Valorizzata dal sistema alla transizione «Rilasciato» (RELEASE → DONE).
Risoluzione (Resolution)	Categorizzazione dello stato finale del ticket alla chiusura.	single-select	BLOCCA · BEST PRACTICE	AUTO	General	Obbligatoria al passaggio in RESOLVED: il sistema apre una schermata con il solo campo Risoluzione. Alla DONE viene impostata dal sistema.
Story Points	Rappresenta una misura della complessità, dell'effort o della dimensione dell'attività (da 1 a 5). Il valore esprime una valutazione relativa basata su complessità tecnica, incertezza, rischi e volume del lavoro. È utile per la definizione e il monitoraggio dei KPI qualitativi.	Number (decimale)	CONDIZIONALE	Manuale	Pianificazione	Richiesto dalla schermata della transizione «Rilasciato»; I casi applicativi e le relative condizioni per il calcolo dei KPI verranno concordate con il proprio Service Manager / Performance manager
KPI_Feedback del Cliente (KPI_Customer Feedback)	Feedback rilasciato dal cliente, utile per il calcolo del KPI qualitativo sulle lavorazioni (Service Type = Design o Sviluppo).	single-select	CONDIZIONALE	Manuale	TAB KPI da valutare	L'obbligatorietà si verifica nei casi di utilizzo per il tracciamento dei KPI. I casi applicativi e le relative condizioni per il calcolo dei KPI verranno concordate con il proprio Service Manager / Performance manager
KPI_Tech Review Approvato 1° ciclo (KPI_Tech Review Approved 1st Cycle)	Campo utilizzato esclusivamente per finalità di monitoraggio KPI, volto a indicare se la Tech Review è stata approvata al primo ciclo di revisione (Yes / No).	single-select	CONDIZIONALE	Manuale	TAB KPI da valutare	L'obbligatorietà si verifica nei casi di utilizzo per il tracciamento dei KPI. I casi applicativi e le relative condizioni per il calcolo dei KPI verranno concordate con il proprio Service Manager / Performance manager
KPI_n° Test in testlist (KPI_No. of Tests in Test List)	Campo utilizzato esclusivamente per il calcolo dei KPI, indicante il numero totale di casi di test previsti nella test list associata al ticket.	Number (decimale)	CONDIZIONALE	Manuale	TAB KPI da valutare	L'obbligatorietà si verifica nei casi di utilizzo per il tracciamento dei KPI. I casi applicativi e le relative condizioni per il calcolo dei KPI verranno concordate con il proprio Service Manager / Performance manager
KPI_n° Test con esito positivo al primo ciclo (KPI_No. of Tests Passed at 1st Cycle)	Campo utilizzato esclusivamente per il calcolo dei KPI, indicante il numero di test completati con esito positivo al primo ciclo di esecuzione.	Number (decimale)	CONDIZIONALE	Manuale	TAB KPI da valutare	L'obbligatorietà si verifica nei casi di utilizzo per il tracciamento dei KPI. I casi applicativi e le relative condizioni per il calcolo dei KPI verranno concordate con il proprio Service Manager / Performance manager
KPI_n° test positivi su totale previsti in testlist (No. of Positive Tests vs Total in Test List)	Campo utilizzato esclusivamente per il calcolo dei KPI, indicante il numero totale di test con esito positivo rispetto ai test previsti nella test list.	Number (decimale)	CONDIZIONALE	Manuale	TAB KPI da valutare	L'obbligatorietà si verifica nei casi di utilizzo per il tracciamento dei KPI. I casi applicativi e le relative condizioni per il calcolo dei KPI verranno concordate con il proprio Service Manager / Performance manager
KPI_n° Performance Test (KPI_No. of Performance Tests)	Campo utilizzato esclusivamente per finalità KPI, indicante il numero totale di performance test eseguiti sul ticket o rilascio associato.	Number (decimale)	CONDIZIONALE	Manuale	TAB KPI da valutare	L'obbligatorietà si verifica nei casi di utilizzo per il tracciamento dei KPI. I casi applicativi e le relative condizioni per il calcolo dei KPI verranno concordate con il proprio Service Manager / Performance manager
KPI_n° Performance Test con esito positivo (KPI_No. of Performance Tests Passed)	Campo utilizzato esclusivamente per finalità KPI, indicante il numero di performance test completati con esito positivo.	Number (decimale)	CONDIZIONALE	Manuale	TAB KPI da valutare	L'obbligatorietà si verifica nei casi di utilizzo per il tracciamento dei KPI. I casi applicativi e le relative condizioni per il calcolo dei KPI verranno concordate con il proprio Service Manager / Performance manager

Facoltativi — nessun obbligo di sistema o procedurale

Campo	Descrizione	Tipo campo	Obbligo	Compil.	Tab	Note
Team	Team di riferimento dell'assegnatario.	Single-select Team (Jira) Picker	—	Manuale	General
Stima originale (Original Estimate)	Tempo stimato inizialmente per completare l'attività.	Time Tracking	—	Manuale	Pianificazione
Etichette (Labels)	Parole chiave per categorizzare o filtrare i ticket.	Labels	—	Manuale	General
Priorità	Livello di priorità assegnato all'attività.	single-select	—	Manuale	General
Allegato (Attachment)	File o documenti allegati al ticket.	attachment	—	Manuale	General
Descrizione (Description)	Dettaglio esteso descrittivo del ticket.	multiline	—	Manuale	General
Ticket collegati (Linked Issues)	Riferimenti ad altri ticket collegati o dipendenti.	Jira-link	—	Manuale	General
Multiple Assignee	Campo opzionale per indicare più utenti responsabili.	Multi-select User Picker	—	Manuale	General	Non consigliato come best practice.
Multiple teams	Campo opzionale per indicare più squadre coinvolte.	Multi-select Team Picker	—	Manuale	General	Non consigliato come best practice.
Versioni di correzione (Fix Versions)	Versione in cui il ticket viene risolto o pianificato per la risoluzione.	Date Picker	—	Manuale	General
Note	Annotazioni interne integrative.	multiline	—	Manuale	Note
Fornitore-Provider (Supplier / Provider)	Fornitore esterno che eroga il servizio correlato.	single-select	—	Manuale	General	Per aggiornare le voci presenti nel menu a tendina, è necessario aprire un ticket di supporto tramite l’Helpdesk Jira.
Componenti (Components)	Componenti o aree funzionali del progetto software a cui il ticket è associato. Utilizzato per categorizzare attività, moduli applicativi o domini tecnici di riferimento.	jira-multi-select	—	Manuale	General
Sprint	Sprint Agile di appartenenza del ticket, utilizzato per la pianificazione e il monitoraggio delle attività all’interno del ciclo Scrum.	jira-Sprint field	—	Manuale	General
obiettivi (Goals)	Collega l'Epic a traguardi strategici definiti in Atlas.	Atlassian Goal picker	—	Manuale	General
Data consegna Stima (Estimate Delivery Date)	Data in cui la stima viene condivisa con gli stakeholder.	Date Picker	—	Manuale	Altre Date
Data approvazione tecnica (Technical Approval Date)	Data in cui la soluzione o l'approccio tecnico vengono approvati.	Date Picker	—	Manuale	Altre Date
Data approvazione HLD (HLD Approval Date)	Data in cui viene approvato il documento di High-Level Design.	Date Picker	—	Manuale	Altre Date
Data Invio HLD (HLD Submission Date)	Data in cui il documento HLD viene inviato per revisione.	Date Picker	—	Manuale	Altre Date
Data consegna TestList (Test List Delivery Date)	Data in cui la lista dei test (o piano di test) viene consegnata.	Date Picker	—	Manuale	Altre Date
Data approvazione stima (Estimate Approval Date)	Data in cui i dati relativi alle stime comunicati al cliente vengono approvati.	Date Picker	—	Manuale	Altre Date
Interessa le versioni (Affects Versions)	Versione nella quale viene riscontrato un problema	Date Picker	—	Manuale	General

Tabella 5 – Task Gestionali: campi e regole di compilazione

In creazione (stato iniziale: TO DO)

Campo	Descrizione	Tipo campo	Obbligo	Compil.	Tab	Note
Riepilogo (Summary)	Breve sintesi del contenuto dell'attività.	string	BLOCCA	Manuale	General
Tipo ticket (Issue Type)	Categoria Jira del ticket (Task, Story, Bug, Redazione documentazione, Hardware/DevOps, Helpdesk, Rilascio).	single-select	BLOCCA	Manuale	General
Principale (Parent)	Riferimento automatico al ticket genitore (Epic) per l'attività.	Jira-link	BEST PRACTICE	AUTO	General
Contract Revenue Type	Voce di listino contrattuale, sincronizzata da SAP che collega l'attività al relativo valore economico. Usata per calcolare fatturato avanzamento VDP.	single-select	BLOCCA · BEST PRACTICE	Manuale	Produzione	I valori di questo campo vengono automaticamente creati e modificati da SAP tramite un automatismo che si attiva una volta al giorno
Service Type	Identifica il tipo di servizio aziendale svolto per il completamento del Deliverable. E' composto servizio + attività effettivamente svolta prevista anche in fase di budgeting.	Select List-cascading	BLOCCA · BEST PRACTICE	Manuale	Produzione
EPICKEY	Collegamento custom all'epic di riferimento (anche per sottoelementi non direttamente figli di un epic).	string	BEST PRACTICE	AUTO	System
Richiedente (Reporter)	Utente che ha creato o richiesto il ticket.	Single-select User Picker	BEST PRACTICE	AUTO	General	Se NON modificato -> verrà compilato automaticamente con l'utente che sta creando il ticket.
Workflow Status	Stato specifico del workflow in cui si trova il ticket.	Jira-workflow status	BEST PRACTICE	Manuale	General

Presa in carico (TO DO → IN PROGRESS)

Campo	Descrizione	Tipo campo	Obbligo	Compil.	Tab	Note
Data di inizio (Start Date)	Data di avvio effettiva dell'attività.	Date Picker	BEST PRACTICE	AUTO	Pianificazione	Valorizzata dal sistema alla transizione «Presa in carico».
Assegnatario (Assignee)	Utente responsabile del completamento del ticket.	Single-select User Picker	BEST PRACTICE	AUTO	General	Impostato dal sistema sull'utente che esegue la presa in carico.

Chiusura (DONE / RESOLVED)

Campo	Descrizione	Tipo campo	Obbligo	Compil.	Tab	Note
End date	Data di completamento effettiva dell'attività.	Date Picker	BEST PRACTICE	AUTO	Pianificazione	Valorizzata dal sistema alle transizioni «Lavorazione completata» e «Resolved».
Risoluzione (Resolution)	Categorizzazione dello stato finale del ticket alla chiusura.	single-select	BLOCCA · BEST PRACTICE	AUTO	General	Obbligatoria al passaggio in RESOLVED: il sistema apre una schermata con il solo campo Risoluzione. Alla DONE viene impostata dal sistema.
KPI_Feedback del Cliente (KPI_Customer Feedback)	Feedback rilasciato dal cliente, utile per il calcolo del KPI qualitativo sulle lavorazioni (Service Type = Design o Sviluppo).	single-select	CONDIZIONALE	Manuale	TAB KPI da valutare	Nessuna schermata di transizione lo richiede: la compilazione alla chiusura è procedurale e dipende dal Service Type.
KPI_Tech Review Approvato 1° ciclo (KPI_Tech Review Approved 1st Cycle)	Campo utilizzato esclusivamente per finalità di monitoraggio KPI, volto a indicare se la Tech Review è stata approvata al primo ciclo di revisione (Yes / No).	single-select	CONDIZIONALE	Manuale	TAB KPI da valutare	Nessuna schermata di transizione lo richiede: la compilazione alla chiusura è procedurale e dipende dal Service Type.
KPI_n° Test in testlist (KPI_No. of Tests in Test List)	Campo utilizzato esclusivamente per il calcolo dei KPI, indicante il numero totale di casi di test previsti nella test list associata al ticket.	Number (decimale)	CONDIZIONALE	Manuale	TAB KPI da valutare	Nessuna schermata di transizione lo richiede: la compilazione alla chiusura è procedurale e dipende dal Service Type.
KPI_n° Test con esito positivo al primo ciclo (KPI_No. of Tests Passed at 1st Cycle)	Campo utilizzato esclusivamente per il calcolo dei KPI, indicante il numero di test completati con esito positivo al primo ciclo di esecuzione.	Number (decimale)	CONDIZIONALE	Manuale	TAB KPI da valutare	Nessuna schermata di transizione lo richiede: la compilazione alla chiusura è procedurale e dipende dal Service Type.
KPI_n° test positivi su totale previsti in testlist (No. of Positive Tests vs Total in Test List)	Campo utilizzato esclusivamente per il calcolo dei KPI, indicante il numero totale di test con esito positivo rispetto ai test previsti nella test list.	Number (decimale)	CONDIZIONALE	Manuale	TAB KPI da valutare	Nessuna schermata di transizione lo richiede: la compilazione alla chiusura è procedurale e dipende dal Service Type.
KPI_n° Performance Test (KPI_No. of Performance Tests)	Campo utilizzato esclusivamente per finalità KPI, indicante il numero totale di performance test eseguiti sul ticket o rilascio associato.	Number (decimale)	CONDIZIONALE	Manuale	TAB KPI da valutare	Nessuna schermata di transizione lo richiede: la compilazione alla chiusura è procedurale e dipende dal Service Type.
KPI_n° Performance Test con esito positivo (KPI_No. of Performance Tests Passed)	Campo utilizzato esclusivamente per finalità KPI, indicante il numero di performance test completati con esito positivo.	Number (decimale)	CONDIZIONALE	Manuale	TAB KPI da valutare	Nessuna schermata di transizione lo richiede: la compilazione alla chiusura è procedurale e dipende dal Service Type.

Facoltativi — nessun obbligo di sistema o procedurale

Campo	Descrizione	Tipo campo	Obbligo	Compil.	Tab	Note
Tempo Team	Team di riferimento per la rilevazione tempo tramite plug-in "Tempo".	Single-select Team (Tempo) Picker	—	Manuale	Pianificazione
Start date pianificato (Planned Start Date)	Data di inizio pianificata per l'attività.	Date Picker	—	Manuale	Pianificazione
Data di scadenza (Due Date)	Data di fine pianificata per l'attività.	Date Picker	—	Manuale	Pianificazione
Target Production	Quantità di produzione pianificata per l'attività.	Number (decimale)	—	Manuale	Produzione	Per l'area IT il campo esprime le ore di lavoro previste: non esistono pezzi di produzione, la produzione coincide con il tempo.
Production Units	Unità di misura della produzione associata all'attività monitorata nel Task. E’ definita dalla voce di listino contrattuale.	single-select	—	AUTO	Produzione	Impostato automaticamente a «FTE» alla creazione del ticket.
Team	Team di riferimento dell'assegnatario.	Single-select Team (Jira) Picker	—	Manuale	General
Stima originale (Original Estimate)	Tempo stimato inizialmente per completare l'attività.	Time Tracking	—	Manuale	Pianificazione
Etichette (Labels)	Parole chiave per categorizzare o filtrare i ticket.	Labels	—	Manuale	General
Priorità	Livello di priorità assegnato all'attività.	single-select	—	Manuale	General
Allegato (Attachment)	File o documenti allegati al ticket.	attachment	—	Manuale	General
Descrizione (Description)	Dettaglio esteso descrittivo del ticket.	multiline	—	Manuale	General
Ticket collegati (Linked Issues)	Riferimenti ad altri ticket collegati o dipendenti.	Jira-link	—	Manuale	General
Multiple Assignee	Campo opzionale per indicare più utenti responsabili.	Multi-select User Picker	—	Manuale	General	Non consigliato come best practice.
Multiple teams	Campo opzionale per indicare più squadre coinvolte.	Multi-select Team Picker	—	Manuale	General	Non consigliato come best practice.
Versioni di correzione (Fix Versions)	Versione in cui il ticket viene risolto o pianificato per la risoluzione.	Date Picker	—	Manuale	General
Note	Annotazioni interne integrative.	multiline	—	Manuale	Note
Fornitore-Provider (Supplier / Provider)	Fornitore esterno che eroga il servizio correlato.	single-select	—	Manuale	General	Per aggiornare le voci presenti nel menu a tendina, è necessario aprire un ticket di supporto tramite l’Helpdesk Jira.
Componenti (Components)	Componenti o aree funzionali del progetto software a cui il ticket è associato. Utilizzato per categorizzare attività, moduli applicativi o domini tecnici di riferimento.	jira-multi-select	—	Manuale	General
Sprint	Sprint Agile di appartenenza del ticket, utilizzato per la pianificazione e il monitoraggio delle attività all’interno del ciclo Scrum.	jira-Sprint field	—	Manuale	General
obiettivi (Goals)	Collega l'Epic a traguardi strategici definiti in Atlas.	Atlassian Goal picker	—	Manuale	General
Story Points	Valore numerico utilizzato per stimare l’effort o la complessità relativa del ticket secondo metodologia Agile/Scrum ed usato per il calcolo del KPI.	Number (decimale)	CONDIZIONALE	Manuale	Pianificazione	L’obbligatorietà è dipendente dalle regole di validazione e dalle logiche di calcolo KPI. I casi applicativi e le relative condizioni verranno dettagliati nelle sezioni dedicate
Data consegna Stima (Estimate Delivery Date)	Data in cui la stima viene condivisa con gli stakeholder.	Date Picker	—	Manuale	Altre Date
Data approvazione tecnica (Technical Approval Date)	Data in cui la soluzione o l'approccio tecnico vengono approvati.	Date Picker	—	Manuale	Altre Date
Data approvazione HLD (HLD Approval Date)	Data in cui viene approvato il documento di High-Level Design.	Date Picker	—	Manuale	Altre Date
Data Invio HLD (HLD Submission Date)	Data in cui il documento HLD viene inviato per revisione.	Date Picker	—	Manuale	Altre Date
Data consegna TestList (Test List Delivery Date)	Data in cui la lista dei test (o piano di test) viene consegnata.	Date Picker	—	Manuale	Altre Date
Data approvazione stima (Estimate Approval Date)	Data in cui i dati relativi alle stime comunicati al cliente al vengono approvati.	Date Picker	—	Manuale	Altre Date
Interessa le versioni (Affects Versions)	Versione nella quale viene riscontrato un problema	Date Picker	—	Manuale	General

Tabella 6 – Task Esecutivi: campi e regole di compilazione

In creazione (stato iniziale: TO ESTIMATE)

Campo	Descrizione	Tipo campo	Obbligo	Compil.	Tab	Note
Riepilogo (Summary)	Breve sintesi del contenuto dell'attività.	string	BLOCCA	Manuale	General
Tipo ticket (Issue Type)	Categoria Jira del ticket (Task, Story, Bug, Redazione documentazione, Hardware/DevOps, Helpdesk, Rilascio).	single-select	BLOCCA	Manuale	General
Principale (Parent)	Riferimento automatico al ticket genitore (Epic) per l'attività.	Jira-link	BEST PRACTICE	AUTO	General
EPICKEY	Collegamento custom all'epic di riferimento (anche per sottoelementi non direttamente figli di un epic).	string	BEST PRACTICE	AUTO	System	Valore ereditato dal Task; se non compilato nel Task non viene ereditato.
Contract Revenue Type	Tipologia di attività contrattuale generatrice di ricavo (proviene da SAP).	single-select	BLOCCA · BEST PRACTICE	Manuale	System	I valori di questo campo vengono automaticamente creati e modificati da SAP tramite un automatismo che si attiva una volta al giorno
Service Type	Identifica il tipo di servizio aziendale svolto per il completamento del Deliverable. E' composto servizio + attività effettivamente svolta prevista anche in fase di budgeting.	Select List-cascading	BLOCCA · BEST PRACTICE	Manuale	System
Production Units	Unità di misura della produzione associata all'attività monitorata nel Task. E’ definita dalla voce di listino contrattuale.	single-select	BLOCCA · BEST PRACTICE	Manuale	System
Target Production	Quantità di produzione pianificata per l'attività.	Number (decimale)	BLOCCA · BEST PRACTICE	Manuale	Pianificazione (schermata di creazione)	Per l'area IT il campo esprime le ore di lavoro previste: non esistono pezzi di produzione, la produzione coincide con il tempo. Obbligatorio alla creazione; non è presente sulla schermata di modifica del ticket.
Richiedente (Reporter)	Utente che ha creato o richiesto il ticket.	Single-select User Picker	—	AUTO	General	Se NON modificato -> verrà compilato automaticamente con l'utente che sta creando il ticket.
Workflow Status	Stato specifico del workflow in cui si trova il ticket.	Jira-workflow status	BEST PRACTICE	Manuale	General

Passaggio in TO DO (transizione «Stimato» da TO ESTIMATE)

Campo	Descrizione	Tipo campo	Obbligo	Compil.	Tab	Note
Story Points	Valore numerico utilizzato per stimare l’effort o la complessità relativa del ticket secondo metodologia Agile/Scrum ed usato per il calcolo del KPI.	Number (decimale)	BLOCCA · BEST PRACTICE	Manuale	Pianificazione	Obbligatorio al passaggio in TO DO insieme ad Assegnatario, Tempo Team, Start date pianificato e Data di scadenza: se manca, Jira blocca la transizione.
Assegnatario (Assignee)	Utente responsabile del completamento del ticket.	Single-select User Picker	BLOCCA · BEST PRACTICE	Manuale	General	Campi necessari per pianificazione Service manager in Capacity Planner
Tempo Team	Team di riferimento per la rilevazione tempo tramite plug-in "Tempo".	Single-select Team (Tempo) Picker	BLOCCA · BEST PRACTICE	Manuale	Pianificazione	Campi necessari per pianificazione Service manager in Capacity Planner
Start date pianificato (Planned Start Date)	Data di inizio pianificata per l'attività.	Date Picker	BLOCCA · BEST PRACTICE	Manuale	Pianificazione	Campi necessari per pianificazione Service manager in Capacity Planner
Data di scadenza (Due Date)	Data di fine pianificata per l'attività.	Date Picker	BLOCCA · BEST PRACTICE	Manuale	Pianificazione	Campi necessari per pianificazione Service manager in Capacity Planner
Stima originale (Original Estimate)	Tempo stimato inizialmente per completare l'attività.	Time Tracking	BEST PRACTICE	Manuale	Pianificazione	Utile alla pianificazione in Capacity Planner ma non bloccante.

Presa in carico (TO DO / IN PENDING → IN PROGRESS)

Campo	Descrizione	Tipo campo	Obbligo	Compil.	Tab	Note
Data di inizio (Start Date)	Data di avvio effettiva dell'attività.	Date Picker	BEST PRACTICE	AUTO	Pianificazione	Valorizzata dal sistema alla transizione «Presa in carico»; il ticket viene inoltre assegnato all'utente che la esegue.

Chiusura (Bug: TO BE RELEASED TO PRODUCTION → DONE; Helpdesk: IN PROGRESS → DONE; RESOLVED)

Campo	Descrizione	Tipo campo	Obbligo	Compil.	Tab	Note
KPI_Feedback del Cliente (KPI_Customer Feedback)	Feedback rilasciato dal cliente, utile per il calcolo del KPI qualitativo sulle lavorazioni (Service Type = Design o Sviluppo).	single-select	CONDIZIONALE	Manuale	TAB KPI da valutare	L'obbligatorietà si verifica nei casi di utilizzo per il tracciamento dei KPI. I casi applicativi e le relative condizioni per il calcolo dei KPI verranno concordate con il proprio Service Manager / Performance manager
KPI_Tech Review Approvato 1° ciclo (KPI_Tech Review Approved 1st Cycle)	Campo utilizzato esclusivamente per finalità di monitoraggio KPI, volto a indicare se la Tech Review è stata approvata al primo ciclo di revisione (Yes / No).	single-select	CONDIZIONALE	Manuale	TAB KPI da valutare	L'obbligatorietà si verifica nei casi di utilizzo per il tracciamento dei KPI. I casi applicativi e le relative condizioni per il calcolo dei KPI verranno concordate con il proprio Service Manager / Performance manager
KPI_n° Test in testlist (KPI_No. of Tests in Test List)	Campo utilizzato esclusivamente per il calcolo dei KPI, indicante il numero totale di casi di test previsti nella test list associata al ticket.	Number (decimale)	CONDIZIONALE	Manuale	TAB KPI da valutare	L'obbligatorietà si verifica nei casi di utilizzo per il tracciamento dei KPI. I casi applicativi e le relative condizioni per il calcolo dei KPI verranno concordate con il proprio Service Manager / Performance manager
KPI_n° Test con esito positivo al primo ciclo (KPI_No. of Tests Passed at 1st Cycle)	Campo utilizzato esclusivamente per il calcolo dei KPI, indicante il numero di test completati con esito positivo al primo ciclo di esecuzione.	Number (decimale)	CONDIZIONALE	Manuale	TAB KPI da valutare	L'obbligatorietà si verifica nei casi di utilizzo per il tracciamento dei KPI. I casi applicativi e le relative condizioni per il calcolo dei KPI verranno concordate con il proprio Service Manager / Performance manager
KPI_n° test positivi su totale previsti in testlist (No. of Positive Tests vs Total in Test List)	Campo utilizzato esclusivamente per il calcolo dei KPI, indicante il numero totale di test con esito positivo rispetto ai test previsti nella test list.	Number (decimale)	CONDIZIONALE	Manuale	TAB KPI da valutare	L'obbligatorietà si verifica nei casi di utilizzo per il tracciamento dei KPI. I casi applicativi e le relative condizioni per il calcolo dei KPI verranno concordate con il proprio Service Manager / Performance manager
KPI_n° Performance Test (KPI_No. of Performance Tests)	Campo utilizzato esclusivamente per finalità KPI, indicante il numero totale di performance test eseguiti sul ticket o rilascio associato.	Number (decimale)	CONDIZIONALE	Manuale	TAB KPI da valutare	L'obbligatorietà si verifica nei casi di utilizzo per il tracciamento dei KPI. I casi applicativi e le relative condizioni per il calcolo dei KPI verranno concordate con il proprio Service Manager / Performance manager
KPI_n° Performance Test con esito positivo (KPI_No. of Performance Tests Passed)	Campo utilizzato esclusivamente per finalità KPI, indicante il numero di performance test completati con esito positivo.	Number (decimale)	CONDIZIONALE	Manuale	TAB KPI da valutare	L'obbligatorietà si verifica nei casi di utilizzo per il tracciamento dei KPI. I casi applicativi e le relative condizioni per il calcolo dei KPI verranno concordate con il proprio Service Manager / Performance manager
Risoluzione (Resolution)	Categorizzazione dello stato finale del ticket alla chiusura.	single-select	BLOCCA · BEST PRACTICE	AUTO	General	Obbligatoria al passaggio in RESOLVED: il sistema apre una schermata con il solo campo Risoluzione. Alla DONE viene impostata dal sistema.
End date	Data di completamento effettiva dell'attività.	Date Picker	BEST PRACTICE	AUTO	Pianificazione	Valorizzata dal sistema alla transizione di chiusura.

Facoltativi — nessun obbligo di sistema o procedurale

Campo	Descrizione	Tipo campo	Obbligo	Compil.	Tab	Note
Team	Team di riferimento dell'assegnatario.	Single-select Team (Jira) Picker	—	Manuale	General
Data consegna Stima (Estimate Delivery Date)	Data in cui la stima viene condivisa con gli stakeholder.	Date Picker	—	Manuale	Altre Date
Data approvazione tecnica (Technical Approval Date)	Data in cui la soluzione o l'approccio tecnico vengono approvati.	Date Picker	—	Manuale	Altre Date
Data approvazione HLD (HLD Approval Date)	Data in cui viene approvato il documento di High-Level Design.	Date Picker	—	Manuale	Altre Date
Data Invio HLD (HLD Submission Date)	Data in cui il documento HLD viene inviato per revisione.	Date Picker	—	Manuale	Altre Date
Data consegna TestList (Test List Delivery Date)	Data in cui la lista dei test (o piano di test) viene consegnata.	Date Picker	—	Manuale	Altre Date
Data approvazione stima (Estimate Approval Date)	Data in cui i dati relativi alle stime comunicati al cliente al vengono approvati.	Date Picker	—	Manuale	Altre Date
Etichette (Labels)	Parole chiave per categorizzare o filtrare i ticket.	Labels	—	Manuale	General
Priorità	Livello di priorità assegnato all'attività.	single-select	—	Manuale	General
Allegato (Attachment)	File o documenti allegati al ticket.	attachment	—	Manuale	General
Descrizione (Description)	Dettaglio esteso descrittivo del ticket.	multiline	—	Manuale	General
Ticket collegati (Linked Issues)	Riferimenti ad altri ticket collegati o dipendenti.	Jira-link	—	Manuale	General
Versioni di correzione (Fix Versions)	Versione in cui il ticket viene risolto o pianificato per la risoluzione.	Date Picker	—	Manuale	General
Sprint	Sprint Agile di appartenenza del ticket, utilizzato per la pianificazione e il monitoraggio delle attività all’interno del ciclo Scrum.	jira-Sprint field	—	Manuale	General
Interessa le versioni (Affects Versions)	Versione nella quale viene riscontrato un problema	Date Picker	—	Manuale	General

Tabella 7 – Sottotask: campi e regole di compilazione

In creazione

Campo	Descrizione	Tipo campo	Obbligo	Compil.	Tab	Note
Workflow Status	Stato specifico del workflow in cui si trova il ticket.	Jira-workflow status	BEST PRACTICE	Manuale	General
Riepilogo (Summary)	Breve sintesi del contenuto dell'attività.	string	BLOCCA	Manuale	General
Tipo ticket (Issue Type)	Categoria Jira del sottotask (Analisi, Sviluppo, Test, UX/UI, Manualistica).	single-select	BLOCCA	Manuale	General
Principale (Parent)	Riferimento automatico al ticket genitore (Task).	Jira-link	—	AUTO	General
Richiedente (Reporter)	Utente che ha creato o richiesto il ticket.	Single-select User Picker	BEST PRACTICE	AUTO	General	Se non modificato, sarà l'utente che crea il ticket.
EPICKEY	Collegamento custom all'epic di riferimento (anche per sottoelementi non direttamente figli di un epic).	string	BEST PRACTICE	AUTO	System
Contract Revenue Type	Voce di listino contrattuale, sincronizzata da SAP che collega l'attività al relativo valore economico. Usata per calcolare fatturato avanzamento VDP.	single-select	BEST PRACTICE	AUTO	General	Valore ereditato dal Task; se non compilato nel Task non viene ereditato.
Service Type	Identifica il tipo di servizio aziendale svolto per il completamento del Deliverable. E' composto servizio + attività effettivamente svolta prevista anche in fase di budgeting.	Select List-cascading	BEST PRACTICE	AUTO	General	Valore ereditato dal Task; se non compilato nel Task non viene ereditato.
Production Units	Unità di misura della produzione associata all'attività monitorata nel Task. E’ definita dalla voce di listino contrattuale..	single-select	BEST PRACTICE	AUTO	Produzione	Valore ereditato dal Task; se non compilato nel Task non viene ereditato.
Link Epic	Collegamento all'epic di riferimento nel sistema Jira.	Link	BEST PRACTICE	AUTO	General	Valore ereditato dal Task; se non compilato nel Task non viene ereditato.
Rework	Indica se l'attività rientra tra i rework causati da fattori interni.	Radio Button (single-select)	CONDIZIONALE	AUTO	System	L’obbligatorietà si verifica solo nei casi in cui l’attività rientri nella tipologia rework. Vedi paragrafo dedicato E’ sempre possibile compilare questo campo anche manualmente
Ticket collegati (Linked Issues)	Riferimenti ad altri ticket collegati o dipendenti.	Jira-link	CONDIZIONALE	Manuale	General	Per questa tipologia di campo è espressamente prevista la compilazione manual, tranne casi specifici dove sono presenti automazioni. L'obbligatorietà si verifica nei casi di rework e quality check. I casi applicativi e le relative condizioni per il calcolo dei KPI verranno concordate con il proprio Service Manager / Performance manager
Activity Type	Dettaglio dell'attività svolta nel sottotask. (ex -attività di 2° livello)	single-select	CONDIZIONALE	Manuale	General	L'obbligatorietà si verifica nei casi di utilizzo per il tracciamento dei KPI. I casi applicativi e le relative condizioni per il calcolo dei KPI verranno concordate con il proprio Service Manager / Performance manager

Passaggio in TO DO

Campo	Descrizione	Tipo campo	Obbligo	Compil.	Tab	Note
Assegnatario (Assignee)	Utente responsabile del completamento del ticket.	Single-select User Picker	BLOCCA · BEST PRACTICE	Manuale	General	Obbligatorio al passaggio in TO DO. All'avvio della lavorazione il sistema lo sovrascrive con l'utente che esegue la transizione in IN PROGRESS.
Stima originale (Original Estimate)	Tempo stimato inizialmente per completare l'attività.	Time Tracking	BEST PRACTICE	Manuale	Pianificazione	Utile alla pianificazione in Capacity Planner ma non bloccante: il passaggio in TO DO richiede Assegnatario, Tempo Team, Start date pianificato, Data di scadenza e Production Weight (%).
Data di scadenza (Due Date)	Data di fine pianificata per l'attività.	Date Picker	BLOCCA · BEST PRACTICE	Manuale	Pianificazione	Campi necessari per pianificazione Service manager in Capacity Planner
Tempo Team	Team di riferimento per la rilevazione tempo tramite plug-in Tempo.	Single-select Team (Tempo) Picker	BLOCCA · BEST PRACTICE	AUTO	Pianificazione	Ereditato dal Task alla creazione; se il Task non lo aveva valorizzato va inserito, perché il passaggio in TO DO viene altrimenti bloccato.
Production Weight (%)	Peso percentuale del sottotask rispetto al task padre, usato per il calcolo proporzionale dell'avanzamento.	Number (percentuale)	BLOCCA · BEST PRACTICE	Manuale	Produzione	La % è da intendersi come stima riferita al target del task padre.
Start date pianificato (Planned Start Date)	Data di inizio pianificata per l'attività.	Date Picker	BLOCCA · BEST PRACTICE	Manuale	Pianificazione	Campi necessari per pianificazione Service manager in Capacity Planner
Target Production	Quantità di produzione pianificata per l'attività.	Number (decimale)	—	AUTO	Produzione	Si valorizza automaticamente alla compilazione di Production Weight (%).

Passaggio in IN PROGRESS

Campo	Descrizione	Tipo campo	Obbligo	Compil.	Tab	Note
Data di inizio (Start Date)	Data di avvio effettiva dell'attività.	Date Picker	BEST PRACTICE	AUTO	Pianificazione	Valorizzata dal sistema alla transizione «Inizio lavorazione».

Lavorazione sospesa (stati IN PENDING / DEVICE PROCESSING)

Campo	Descrizione	Tipo campo	Obbligo	Compil.	Tab	Note
Actual Production progress (%)	Percentuale di avanzamento giornaliero della produzione nel sottotask rispetto al task padre.	Number (percentuale)	CONDIZIONALE	Manuale	Produzione	Se la durata del ticket è > 8 ore,o più ingenerale per qualsiasi attività che non venga completata e chiusa nella stessa giornata di presa in carico, è obbligatoria almeno una volta al giorno.

Chiusura (stati DONE / KO / CANCELLED)

Campo	Descrizione	Tipo campo	Obbligo	Compil.	Tab	Note
End date	Data di completamento effettiva dell'attività.	Date Picker	BEST PRACTICE	AUTO	Pianificazione	Valorizzata dal sistema alle transizioni di chiusura.
Actual Production	Quantità di produzione consuntivata.	Number (decimale)	BLOCCA · BEST PRACTICE	Manuale	Produzione	Richiesta alla transizione «Lavorazione completata»: il sistema apre la schermata «Actual Production +Tab KPI».
Risoluzione (Resolution)	Categorizzazione dello stato finale del ticket alla chiusura.	single-select	BEST PRACTICE	AUTO	General	Impostata dal sistema alla chiusura. Se n° Fix da quality check è ≥ 1 il sistema imposta Risoluzione = Esito Negativo.
KPI_N°Fix rilevati in QC (No. of Quality Check Fixes)	Numero di fix rilevati durante il Quality Check, usato per il calcolo del KPI quantitativo sulle lavorazioni di design.	Number (decimale)	CONDIZIONALE	Manuale	TAB KPI da valutare	Compare nella schermata della transizione «Lavorazione completata». Si compila sul ticket dell'attività che ha generato l'errore. Serve solo al calcolo dei KPI di qualità. L'obbligatorietà dipende dal Service Type ed è governata dalle regole predisposte con il proprio service manager / Performance manager
KPI_N°Errori-Varianti-Vincoli rilevati tardivamente (No. of Errors, Variances & Constraints Identified Late)	Numero di errori emersi dopo la consegna dell'attività, perché segnalati dal cliente o scoperti in una fase successiva (es. vincoli non individuati in analisi, errori sfuggiti al Quality Check, errori rilevati da un team diverso da quello che ha eseguito la lavorazione).	Number (decimale)	CONDIZIONALE	Manuale	TAB KPI da valutare	Compare nella schermata della transizione «Lavorazione completata». Si compila sul ticket dell'attività che ha generato l'errore. Serve solo al calcolo dei KPI di qualità. L'obbligatorietà dipende dal Service Type ed è governata dalle regole predisposte con il proprio service manager / Performance manager
KPI_Quantità Target (KPI_Target Production Quantity)	Quantità di lavoro stimata da eseguire in questa attività. Non è la quantità contrattuale o rendicontata (Production Units / Actual Production).	Number (decimale)	CONDIZIONALE	Manuale	TAB KPI da valutare	Compare nella schermata di creazione. Serve solo al calcolo dei KPI di qualità. L'obbligatorietà dipende dal Service Type ed è governata dalle regole predisposte con il proprio service manager / Performance manager
KPI_Quantità lavorata (KPI_Actual Production Quantity)	Quantità di lavoro effettivamente eseguita nell’ attività. Non è la quantità contrattuale o rendicontata (Production Units / Actual Production).	Number (decimale)	CONDIZIONALE	Manuale	TAB KPI da valutare	Compare nella schermata della transizione «Lavorazione completata». Serve solo al calcolo dei KPI di qualità. L'obbligatorietà dipende dal Service Type ed è governata dalle regole predisposte con il proprio service manager / Performance manager
KPI_Feedback del Cliente (KPI_Customer Feedback)	Feedback rilasciato dal cliente, utile per il calcolo del KPI qualitativo sulle lavorazioni (Service Type = Design o Sviluppo).	single-select	CONDIZIONALE	Manuale	TAB KPI da valutare	Compare nella schermata della transizione «Lavorazione completata». Si compila sul ticket dell'attività che ha generato l'errore. Serve solo al calcolo dei KPI di qualità. L'obbligatorietà dipende dal Service Type ed è governata dalle regole predisposte con il proprio service manager / Performance manager
Assegnatario (Assignee)	Utente responsabile del completamento del ticket.	Single-select User Picker	BLOCCA · BEST PRACTICE	Manuale	General	Alla chiusura il sistema verifica che l'Assegnatario sia valorizzato: deve essere l'utente che ha effettuato la lavorazione.

Facoltativi — nessun obbligo di sistema o procedurale

Campo	Descrizione	Tipo campo	Obbligo	Compil.	Tab	Note
Team	Team di riferimento dell'assegnatario.	Single-select Team (Jira) Picker	—	Manuale	General	Il valore si compila automaticamente quando/se viene compilato nel task padre.
Etichette (Labels)	Parole chiave per categorizzare o filtrare i ticket.	Labels	—	Manuale	General
Priorità	Livello di priorità assegnato all'attività.	single-select	—	Manuale	General
Allegato (Attachment)	File o documenti allegati al ticket.	attachment	—	Manuale	General
Descrizione (Description)	Dettaglio esteso descrittivo del ticket.	multiline	—	Manuale	General
Versioni di correzione (Fix Versions)	Versione in cui il ticket viene risolto o pianificato per la risoluzione.	Date Picker	—	Manuale	General
Interessa le versioni (Affects Versions)	Versione nella quale viene riscontrato un ticket.	Date Picker	—	Manuale	General
Comune (Municipality)	Comune di riferimento dell'attività.	single-select	—	Manuale	Localizzazione
Provincia (Province)	Provincia di riferimento dell'attività.	single-select	—	Manuale	Localizzazione
Regione	Regione di riferimento dell'attività.	single-select	—	Manuale	Localizzazione

Tabella 8 – Analisi, Sviluppo, Test, Manualistica e UX/UI: campi e regole di compilazione

In creazione (stato iniziale: TO ESTIMATE)

Campo	Descrizione	Tipo campo	Obbligo	Compil.	Tab	Note
Riepilogo (Summary)	Breve sintesi del contenuto dell'attività.	string	BLOCCA	Manuale	General
Tipo ticket (Issue Type)	Categoria Jira del ticket (Task, Story, Bug, Redazione documentazione, Hardware/DevOps, Helpdesk, Rilascio).	single-select	BLOCCA	Manuale	General
Principale (Parent)	Riferimento automatico al ticket genitore (Epic) per l'attività.	Jira-link	—	AUTO	General
EPICKEY	Collegamento custom all'epic di riferimento (anche per sottoelementi non direttamente figli di un epic).	string	BEST PRACTICE	AUTO	System	Valore ereditato dal Task; se non compilato nel Task non viene ereditato.
Link Epic	Collegamento all'epic di riferimento nel sistema Jira.	Link	BEST PRACTICE	AUTO	System	Valore ereditato dal Task; se non compilato nel Task non viene ereditato.
Contract Revenue Type	Tipologia di attività contrattuale generatrice di ricavo (proviene da SAP).	single-select	BEST PRACTICE	AUTO	System	Valore ereditato dal Task; se non compilato nel Task non viene ereditato e deve essere compilato manualmente.
Service Type	Identifica il tipo di servizio aziendale svolto per il completamento del Deliverable. E' composto servizio + attività effettivamente svolta prevista anche in fase di budgeting.	Select List-cascading	BEST PRACTICE	AUTO	System	Valore ereditato dal Task; se non compilato nel Task non viene ereditato e deve essere compilato manualmente.
Production Units	Unità di misura della produzione associata all'attività monitorata nel Task. E’ definita dalla voce di listino contrattuale.	single-select	BEST PRACTICE	AUTO	System	Valore ereditato dal Task; se non compilato nel Task non viene ereditato e deve essere compilato manualmente.
Richiedente (Reporter)	Utente che ha creato o richiesto il ticket.	Single-select User Picker	—	AUTO	General	Se NON modificato -> verrà compilato automaticamente con l'utente che sta creando il ticket.
Workflow Status	Stato specifico del workflow in cui si trova il ticket.	Jira-workflow status	BEST PRACTICE	Manuale	General

Passaggio in TO DO (transizioni «Stimato» / «Stima approvata»)

Campo	Descrizione	Tipo campo	Obbligo	Compil.	Tab	Note
Story Points	Valore numerico (da 1 a 5) utilizzato per stimare l’effort o la complessità relativa del ticket secondo metodologia Agile/Scrum ed usato per il calcolo del KPI.	Number (decimale)	BLOCCA · BEST PRACTICE	Manuale	Pianificazione	Obbligatorio al passaggio in TO DO insieme ad Assegnatario, Tempo Team, Start date pianificato e Data di scadenza: se manca, Jira blocca la transizione.
Assegnatario (Assignee)	Utente responsabile del completamento del ticket.	Single-select User Picker	BLOCCA · BEST PRACTICE	Manuale	General	Campi necessari per pianificazione Service manager in Capacity Planner
Tempo Team	Team di riferimento per la rilevazione tempo tramite plug-in "Tempo".	Single-select Team (Tempo) Picker	BLOCCA · BEST PRACTICE	Manuale	Pianificazione	Ereditato dal ticket padre (Story o Task gestionale) alla creazione; se assente va inserito, perché il passaggio in TO DO viene altrimenti bloccato.
Start date pianificato (Planned Start Date)	Data di inizio pianificata per l'attività.	Date Picker	BLOCCA · BEST PRACTICE	Manuale	Pianificazione	Campi necessari per pianificazione Service manager in Capacity Planner
Data di scadenza (Due Date)	Data di fine pianificata per l'attività.	Date Picker	BLOCCA · BEST PRACTICE	Manuale	Pianificazione	Campi necessari per pianificazione Service manager in Capacity Planner
Stima originale (Original Estimate)	Tempo stimato inizialmente per completare l'attività.	Time Tracking	BEST PRACTICE	Manuale	Pianificazione	Utile alla pianificazione in Capacity Planner ma non bloccante.

Presa in carico (TO DO / IN PENDING → IN PROGRESS)

Campo	Descrizione	Tipo campo	Obbligo	Compil.	Tab	Note
Data di inizio (Start Date)	Data di avvio effettiva dell'attività.	Date Picker	BEST PRACTICE	AUTO	Pianificazione	Valorizzata dal sistema alla presa in carico; il ticket viene assegnato all'utente che la esegue e il padre viene portato in IN PROGRESS se si trova in TO DO, Stima o IN PENDING.

Chiusura (DONE / RESOLVED)

Campo	Descrizione	Tipo campo	Obbligo	Compil.	Tab	Note
KPI_Feedback del Cliente (KPI_Customer Feedback)	Feedback rilasciato dal cliente, utile per il calcolo del KPI qualitativo sulle lavorazioni (Service Type = Design o Sviluppo).	single-select	CONDIZIONALE	Manuale	TAB KPI da valutare	L'obbligatorietà si verifica nei casi di utilizzo per il tracciamento dei KPI. I casi applicativi e le relative condizioni per il calcolo dei KPI verranno concordate con il proprio Service Manager / Performance manager
KPI_Tech Review Approvato 1° ciclo (KPI_Tech Review Approved 1st Cycle)	Campo utilizzato esclusivamente per finalità di monitoraggio KPI, volto a indicare se la Tech Review è stata approvata al primo ciclo di revisione (Yes / No).	single-select	CONDIZIONALE	Manuale	TAB KPI da valutare	L'obbligatorietà si verifica nei casi di utilizzo per il tracciamento dei KPI. I casi applicativi e le relative condizioni per il calcolo dei KPI verranno concordate con il proprio Service Manager / Performance manager
KPI_n° Test in testlist (KPI_No. of Tests in Test List)	Campo utilizzato esclusivamente per il calcolo dei KPI, indicante il numero totale di casi di test previsti nella test list associata al ticket.	Number (decimale)	CONDIZIONALE	Manuale	TAB KPI da valutare	L'obbligatorietà si verifica nei casi di utilizzo per il tracciamento dei KPI. I casi applicativi e le relative condizioni per il calcolo dei KPI verranno concordate con il proprio Service Manager / Performance manager
KPI_n° Test con esito positivo al primo ciclo (KPI_No. of Tests Passed at 1st Cycle)	Campo utilizzato esclusivamente per il calcolo dei KPI, indicante il numero di test completati con esito positivo al primo ciclo di esecuzione.	Number (decimale)	CONDIZIONALE	Manuale	TAB KPI da valutare	L'obbligatorietà si verifica nei casi di utilizzo per il tracciamento dei KPI. I casi applicativi e le relative condizioni per il calcolo dei KPI verranno concordate con il proprio Service Manager / Performance manager
KPI_n° test positivi su totale previsti in testlist (No. of Positive Tests vs Total in Test List)	Campo utilizzato esclusivamente per il calcolo dei KPI, indicante il numero totale di test con esito positivo rispetto ai test previsti nella test list.	Number (decimale)	CONDIZIONALE	Manuale	TAB KPI da valutare	L'obbligatorietà si verifica nei casi di utilizzo per il tracciamento dei KPI. I casi applicativi e le relative condizioni per il calcolo dei KPI verranno concordate con il proprio Service Manager / Performance manager
KPI_n° Performance Test (KPI_No. of Performance Tests)	Campo utilizzato esclusivamente per finalità KPI, indicante il numero totale di performance test eseguiti sul ticket o rilascio associato.	Number (decimale)	CONDIZIONALE	Manuale	TAB KPI da valutare	L'obbligatorietà si verifica nei casi di utilizzo per il tracciamento dei KPI. I casi applicativi e le relative condizioni per il calcolo dei KPI verranno concordate con il proprio Service Manager / Performance manager
KPI_n° Performance Test con esito positivo (KPI_No. of Performance Tests Passed)	Campo utilizzato esclusivamente per finalità KPI, indicante il numero di performance test completati con esito positivo.	Number (decimale)	CONDIZIONALE	Manuale	TAB KPI da valutare	L'obbligatorietà si verifica nei casi di utilizzo per il tracciamento dei KPI. I casi applicativi e le relative condizioni per il calcolo dei KPI verranno concordate con il proprio Service Manager / Performance manager
Risoluzione (Resolution)	Categorizzazione dello stato finale del ticket alla chiusura.	single-select	BLOCCA · BEST PRACTICE	AUTO	General	Obbligatoria al passaggio in RESOLVED: il sistema apre una schermata con il solo campo Risoluzione. Alla chiusura viene impostata dal sistema.
End date	Data di completamento effettiva dell'attività.	Date Picker	BEST PRACTICE	AUTO	Pianificazione	Valorizzata dal sistema alla transizione di chiusura («HLD OK» per Analisi, «Rilasciato in produzione» per Sviluppo, «Lavorazione completata» per Test e Manualistica, «Review OK» per UX/UI).

Facoltativi — nessun obbligo di sistema o procedurale

Campo	Descrizione	Tipo campo	Obbligo	Compil.	Tab	Note
Data consegna Stima (Estimate Delivery Date)	Data in cui la stima viene condivisa con gli stakeholder.	Date Picker	—	Manuale	Altre Date
Data approvazione tecnica (Technical Approval Date)	Data in cui la soluzione o l'approccio tecnico vengono approvati.	Date Picker	—	Manuale	Altre Date
Data approvazione HLD (HLD Approval Date)	Data in cui viene approvato il documento di High-Level Design.	Date Picker	—	Manuale	Altre Date
Data Invio HLD (HLD Submission Date)	Data in cui il documento HLD viene inviato per revisione.	Date Picker	—	Manuale	Altre Date
Data consegna TestList (Test List Delivery Date)	Data in cui la lista dei test (o piano di test) viene consegnata.	Date Picker	—	Manuale	Altre Date
Data approvazione stima (Estimate Approval Date)	Data in cui i dati relativi alle stime comunicati al cliente al vengono approvati.	Date Picker	—	Manuale	Altre Date
Etichette (Labels)	Parole chiave per categorizzare o filtrare i ticket.	Labels	—	Manuale	General
Priorità	Livello di priorità assegnato all'attività.	single-select	—	Manuale	General
Allegato (Attachment)	File o documenti allegati al ticket.	attachment	—	Manuale	General
Descrizione (Description)	Dettaglio esteso descrittivo del ticket.	multiline	—	Manuale	General
Ticket collegati (Linked Issues)	Riferimenti ad altri ticket collegati o dipendenti.	Jira-link	—	Manuale	General
Versioni di correzione (Fix Versions)	Versione in cui il ticket viene risolto o pianificato per la risoluzione.	Date Picker	—	Manuale	General
Sprint	Sprint Agile di appartenenza del ticket, utilizzato per la pianificazione e il monitoraggio delle attività all’interno del ciclo Scrum.	jira-Sprint field	—	Manuale	General
Interessa le versioni (Affects Versions)	Versione nella quale viene riscontrato un problema	Date Picker	—	Manuale	General