Please enable JavaScript.

Coggle requires JavaScript to display documents.

Team Pec Obiettivi 2018 (Customer Satisfaction (5) (CS03: Soddisfazione…

- - - - Per tutti i ticket di tipo Change, Fault ed Help valutati nell’anno.
    - - Numero dei ticket con valutazione sulla risoluzione >= 4 (la scala va da 1 a 5) sul totale dei ticket per cui è stata fornita una valutazione.Misura in %.
    - - fornire un buon servizio di helpdesk
  - - - Per tutti i ticket di tipo Change, Fault ed Help valutati nell’anno.
    - - "Numero dei ticket con valutazione sulla qualità del servizio >= 4 (la scala va da 1 a 5) sul totale dei ticket per cui è stata fornita una valutazione.
        Misura in %."
    - - fornire un buon servizio di helpdesk
  - - - A progetto terminato, viene richiesto al cliente (specificatamente al PJM - se definito - o al dirigente di riferimento dell'Ateneo) un feedback in merito alla soddisfazione sulla gestione del progetto in termini di rispondere alla seguente domanda: “Come valuta la professionalità dei referenti Cineca di Ateneo che hanno svolto le attività e quale è il grado di soddisfazione sullo svolgimento del progetto?” con eventuale possibilità di aggiungere suggerimenti/commenti.
    - - Portare a compimento i progetti con un elevato grado di soddisfazione cliente
  - - - N.B. un requisito è “evaso” quanto tutte le issue collegate al requisito sono state risolte
        e validate e la data-di-rilascio del requisito è pari alla massima data di rilascio (=disponibilità per l’installazione)
        delle release in cui sono state risolte e validate le issue collegate al requisito."
      - "Percentuale di requisiti evasi nel rispetto dei tempi di consegna sul totale dei requisiti confermati
        e per i quali è prevista la consegna nell'intervallo temporale di analisi (trimestre).
    - - "R_tot = Numero totale di requisiti nello stato C=<Confermato dal Cliente>
        e la cui ""data di prevista consegna"" rientra nell'intervallo di analisi (trimestre) ;
      - R_evasi = Numero di requisiti appartenenti all'insieme ""R_tot"" che risultano completamente evasi
        entro la ""data di prevista consegna"" dichiarata.;
      - (R_evasi / R_tot) * 100"
    - - Misura la capacità del team di rispettare gli impegni di consegna assunti formalmente con i clienti e registrati nel proprio "portafoglio ordini".
  - - - Percentuali di requisiti entrati nell'intervallo temporale di analisi (trimestre) per i quali non è stata data risposta al cliente in termini di presa in carico e pianificazione oppure in termini di rifiuto/annullamento entro 3 settimane dalla ricezione del requisito stesso.
    - - "R_tot = Numero totale di requisiti entrati (=ricevuti) all'interno dell'intervallo temporale di analisi (trimestre) a prescindere dallo stato e la cui data di inserimento sia comunque anteriore a 3 settimane dalla data corrente.
        R_gestiti (S,C,X,R) = Numero di requisiti appartenenti all'insieme ""R_tot"" per i quali è stata data una risposta al cliente -
        e quindi sono transitati allo stato S=Stimato o C=Confermato o X/R=Annullato/Rifiutato entro 3 settimane dalla data di inserimento.
        
        SP02a = (R_gestiti / R_tot) * 100
    - - rispondere velocemente ai clienti sulla fattibilità e possibilità di realizzazione dei requisiti che ha richiesto via ticket
- - - - Verifica stato avanzamento delle AGDT pianificate
    - - Numero di AGDT approvate e rilasciate rispetto al numero totale di AGDT approvate.
    - - portare a compimento le issue in roadmap del piano dei sistemi
  - - - Completamento dei progetti Sprint assegnati (specificare) fino ad attivare ambiente in preproduzione.
        Specificare target.
    - - Ambienti preproduzione Sprint configurati.
- - - - L_tot = conteggio di tutte le issue aperte e chiuse di un prodotto con delivery-date entro il 31/12 dell’anno corrente
      - L_inevaso = conteggio di tutte le issue aperte di un prodotto con delivery-date entro il 31/12 dell’anno corrente
      - SP06 = ( L_inevaso / L_tot)*100
    - - "Misurazione del volume di backlog annuale di un Prodotto (issue “aperte” con scadenza entro l’anno) rispetto al volume complessivo gestito (issue aperte e chiuse con scadenza entro l’anno).
        Misura la quantità di lavoro che rimane “inevaso” alla fine dell’anno solare rispetto al lavoro complessivo preso in carico da un prodotto."
    - - Misura la quantità di lavoro che rimane “inevaso” alla fine dell’anno solare rispetto al lavoro complessivo preso in carico da un prodotto.
  - - - Per tutti i ticket di tipo Change, Fault ed Help inseriti nell’anno. Età presa in carico: Ore trascorse dalla creazione fino alla prima waiting for support o alla prima escalation (facenti riferimento al solo orario lavorativo).
    - - "Numero ticket presi incarico nei termini sotto indicati sul totale dei ticket pervenuti per priorità.
        
        Misura in %.
        
        • Red Code: presa in carico entro le 4 ore
        
        • Very high: presa in carico entro le 8 ore
        
        • High: presa in carico entro le 12 ore
        
        • Medium: presa in carico entro le 16 [ore]
        
        • Low: presa in carico entro le 24 ore"
    - - Misurare la reattività delle risorse nel prendersi in carico i ticket che gli vengono assegnati o che si autoassegnano
  - - - Per tutti i ticket di tipo Help inseriti nell’anno. Età prima risoluzione: Ore trascorse dalla creazione fino alla prima risoluzione esclusi i periodi di waiting for customer (facenti riferimento al solo orario lavorativo)
    - - "Numero ticket Risolti nei termini sotto indicati sul totale dei ticket pervenuti per priorità.
        
        Misura in %.
        
        • Red Code: risoluzione entro 1 giorno
        
        • Very high: risoluzione entro 2 giorni
        
        • High: risoluzione entro 3 giorni
        
        • Medium: risoluzione entro 4 giorni
        
        • Low: risoluzione entro 5 giorni"
    - - Misurare la capacità delle risorse di risolvere velocemente i ticket che gli vengono assegnati o che si autoassegnano
  - - - Verifica attraverso la checklist-DaD, eseguita ad intervalli di 6 mesi per ogni team.
        
        Checklist adozione DaD
        
        Il TL viene visto come figura di riferimento e positiva da seguire?
        
        Il TL riesce a risolvere i problemi che emergono e le difficoltà date dalla pressione della schedulazione del lavoro?
        
        Eiste una figura in grado di sostituire alla bisogna il TL?
        
        Il Team è motivato e crede nel lavoro che fa?
        
        Il TL conosce i propri TM, le potenzialità di ciascuno e le mette a frutto?
        
        Il Team è in grado di effettuare scelte sulla vita dei propri prodotti per migliorarne la qualità degli stessi e per superare le aspettative degli stakeholder hanno?
        
        Il Team riesce a trovare soluzioni autonomamente in caso di situazioni non gestite nel processo o si ferma in attesa di una indicazione esterna?
        
        Il Team è propositivo nel miglioramento del processo?
        
        Il Team conosce le direttive della BU per lo sviluppo dei prodotti? Le segue? Cerca di essere propositivo per migliorarle?
        
        Il Team ha dimostrato di saper imparare dai propri errori?
        
        Le competenze all'interno del Team sono compartimentate o diffuse? La conoscenza è condivisa?
        
        I TM si preoccupano del fatto che un problema/una soluzione venga risolta o lasciano che ci pensino gli altri?
        
        I TM cercano di effettuare il proprio lavoro a favore degli altri membri del team (es: scrivere una buona analisi affinchè venga prodotto un buon codice e sia possibile effettuare un buon test)?
        
        I TM sono propositivi e concilianti nel lavoro con TM differenti dal loro?
        
        Il Team condivide le proprie soluzioni ed i propri fallimenti (e come li hanno superati) con gli altri Team?
        
        Il Team collabora con i propri Stakeholder per la realizzazione del prodotto?
        
        Il PO conosce i propri Stakeholder e le loro necessità?
        
        Il PO riesce a fornire al Team tutte le informazioni necessarie per comprendere e soddisfare un "need" dello Stakeholder?
        
        Il Team riesce a gestire gli imprevisti o li schiva perchè rovinerebbero la pianificazione?
        
        Il Team ritiene che i propri Stakeholder siano contenti e soddisfatti del prodotto?
        
        Le richieste di Change vengono prese come un'opportunità o come un problema?
        
        I rilasci del prodotto introducono funzionalità che fanno la "differenza" ed immediatamente utilizzabili dallo stakeholder (Consumable Solution) o semplicemente introducono cambiamenti che magari vengono percepiti come non necessari?
        
        Il Team si interroga sul come migliorarsi ad intervalli regolari?
        
        Il Team vive rincorrendo l' "emergenza"?
        
        Il Team riesce a mantenere un WIP (Work In Progress) al minimo?
        
        Il Team conosce i processi DAD e li implementa nel quotidiano?
        
        Il Team tiene basso/sotto controllo il numero di Anomalie (Bug)?
        
        Il Team rispetta le stime di effort e di delivery?
        
        Il Team implementa dei test automatici?
        
        Il Team tiene traccia di un elenco di Test di non regressione?
        
        Il Team segue uno stile di lavoro che mette i Test al centro? (TDD o BDD)
        
        Il Team si prende il tempo necessario per effettuare in maniera completa ed efficace i Test manuali?
        
        Il Requisito scritto dal PO è comprensibile o richiede rivisitazioni multiple?
        
        Il TL riesce a fornire al PO una visione della pianificazione a 3 mesi?
        
        Il TL riesce a fornire al Team una pianificazione chiara?
        
        Il TL si fa "scudo" verso il Team dei problemi che giungono dall'esterno o lascia i TM soli ad affrontarli?
        
        Il PO prioritizza correttamente le attività oppure le ultime o quelle dell'ultimo Stakeholder arrabbiato diventano le nuove prioritarie?
        
        Il PO riesce a filtrare il flusso di richieste verso il team o passa tutto al team come un flusso continuo?
        
        Il TL utilizza Tempo Planner?
        
        Il TL ha creato una Board Agile?
        
        Il PO prioritizza le attività sulla Board Agile?
        
        Il TL ha spiegato al Team il corretto utilizzo degli strumenti ed ha sostenuto i TM nel loro utilizzo?
        
        Il Team effettua sviluppi a tempi variabili rispetto alle necessità dello sviluppo stesso?
    - - Adozione completa della metodologia DaD da parte dei team di sviluppo
  - - - Misurazione del livello di automazione del CQ attraverso i tool e la metodologia adottate. Evidenza di una crescita di almeno il 40% rispetto all'anno precedente.
    - - Numero di casi di test censiti nel database e Numero di test eseguiti in media per release
    - - Aumentare qualità efficentando i costi
- - - - Evidenza dei requisiti rilasciati rispetto alla roadmap
    - - Completamento del piano di sviluppo di Sprint definito dal PO