Public:Phanousk/Documentation/RT/metrics

Z HelpDesk
< Public:Phanousk
Verze z 27. 5. 2011, 07:59, kterou vytvořil Phanousk (diskuse | příspěvky) (založení článku)
(rozdíl) ← Starší verze | zobrazit aktuální verzi (rozdíl) | Novější verze → (rozdíl)

This page is a loose translation of LPS:RT Metriky which is our primary documentation and maybe is not up-to-date. Different ZCU's RT queues are treated in different fastness and quality, in fact according to attitude of their operators. If we want to know how each queue stands on the basis of requestors needs than it is likely to analyze all the requests. We made some simple description of metrics quantifying process of treating requests. However it is likely to read the acquired numbers correctly because every queue has unique character and what is considered bad in one queue doesn't have to be bad in other.

Základní metriky

Přehled definovaných metrik a způsob jejich výpočtu.

  • Používané proměnné
    • $stat_period - doba pro výpočet metrik
    • $decay_period - doba, po které je ticket považován za shnilý (neřešený)
    • $multi_requestor - minimální počet requestorů pro multiuživatelský požadavek
    • @internal_emails - seznam emailu považovaných za interní (tj. @civ.zcu.cz)

Hodnocení aktuálního stavu

  • M1 - Počet neuzavřených požadavků
    • (ticket.status == open) || (ticket.status == new) k datu výpočtu metriky
    • Vyjadřuje počet nedořešených požadavků - při vysokém počtu možno usuzovat na nedotahování požadavků do konce nebo neuzavírání vyřešených.
    • Čím menší, tím lépe
  • M2 - Počet neřešených požadavků
    • (ticket.status == new) k datu výpočtu metriky
    • Počet požadavků, na které nikdo nesáhnul - při vysokém počtu znamená, že požadavky nejsou přebírány
    • Čím menší, tím lépe.
  • M3 - Počet neuzavřených požadavků bez reply
    • (ticket.status == open) || (ticket.status == new) k datu výpočtu metriky a současně daný ticket nemá žádnou transakci typu Correspond jejíž transaction.EmailAddress je ze skupiny @internal_emails
    • Postihuje požadavky, na které uživatel nedostal žádnou odpověd od CIVu (=není informován). Částečně se překrývá s M1.
    • Čím menší, tím lépe.
    • Poznámka: M3-M2 jsou otevřené požadavky bez reply, tj. typicky obsahují komentář, ale jsou bez odpovědi. Tedy někdo se požadavkem zabýval, ale neobtěžoval se žadatele informovat.
  • M4 - Počet neuzavřených vnějších požadavků
    • Stejně jako M1, ale navíc alespoň jeden requestory není z @internal_emails
    • Neřešené požadavky, které od CIVu požadují jeho zákazníci, a které nejsou dořešeny. Vysoký počet může způsobovat negativní pocity uživatelů.
    • Čím menší, tím lépe
  • M5 - Počet neuzavřených vnitřních požadavků
    • Stejně jako M1, ale navíc všichni requestoři jsou z @internal_emails
    • Neřešené požadavky, které od sebe požadují jednotlivé součásti CIVu, a které nejsou dořešeny. Vysoký počet indikuje interní "nevycházení si vstříc".
    • Čím menší, tím lépe
  • M8 - Počet neuzavřených požadavků bez vlastníka
    • (ticket.status == open) || (ticket.status == new) k datu výpočtu metriky a ticket.owner == ""
    • Počet ticketů, které si nikdo nevzal. Pokud je v dané frontě vyžadováno braní požadavků, svědčí vysoké hodnoty o nedodržování pokynů.
    • Čím menší, tím lépe
  • M9 - Počet neuzavřených ticketů s poslední zprávou od requestora
    • (ticket.status == open) || (ticket.status == new) k datu výpočtu metriky a poslední transaction.EmailAddress je od některého z requestorů
    • Poslední příspěvek od žadatele značí očekávání reakce ze strany CIV. Velký počet znamená podezřele vysoké množství "míčů na straně CIV".
    • Čím menší, tím lépe
  • M10 - Počet požadavků neřešených déle než stanovený interval
    • (ticket.status == open) || (ticket.status == new) k datu výpočtu metriky a poslední transakce od uživatele @email_address není v intervalu <nyní-$decay_period, nyní>
    • Požadavky, na které nebylo CIVem šáhnuto déle než uvedený interval. Vysoký počet značí spící/shnilé požadavky
  • M15 - Počet neřešeným multirequestorských požadavků
    • (ticket.status == open) || (ticket.status == new) a počet requestorů je alespoň $multi_requestor
    • Počet zásadnějších / rozsáhlejších požadavků. Může indikovat malé věnování pozornosti kritickým požadavkům,
  • M6 - Doba čekání otevřených požadavků
    • doba uplynulá od poslední aktivity správce fronty (pokud nereagoval vůbec, pak od poslední aktivity requestora)
    • Dává přehled o době čekání uživatele na řešení
    • Čím nižší, tím lepší
    • M16b - Minimální doba odpovědi
    • M16c - Maximální doba odpovědi
    • M16d - Průměrná doba odpovědi

Hodnocení uplynulého období

Obrat požadavků

  • M11 - Počet požadavků vzniklých v daném časovém období
    • Transakce "Create" je v časovém intervalu <nyní-$stat_period, nyní>
    • Dává orientační přehled o průtoku požadavků frontou
  • M12 - Počet požadavků uzavřených v daném časovém období
    • Poslední transakce "Resolve/Delete/Stall/Reject" je v časovém intervalu <nyní-$stat_period, nyní>
    • Dává orientační přehled o průtoku požadavků frontou
  • M13 - Navýšení počtu požadavků v daném časovém období
    • M11-M12
    • Kladné číslo znamená, že přibylo více požadavků než bylo vyřešeno, tj. prodlužování fronty. Dlouhodobé prodlužování může svědčit o nízké pracovní morálce nebo přetížení pracovníků.
    • Čím menší, tím lépe
  • M14 - Poměr vyřešených požadavků v daném časovém období
    • M12/M11 (pro M11 > 0)
    • Obdobné hodnocení jako M13, ale relativně (pod 100% značí hromadění požadavků
    • Čím vyšší, tím lépe

Časové metriky

  • M17 - Charakteristika prvních odpovědí ve sledovaném intervalu
    • M17a - Počet prvních odpovědí ve sledovaném intervalu
      • Počet požadavků, jejichž první Correspond od uživatele z @internal_emails je v časovém intervalu <nyní-$stat_period, nyní>. Vztaženo na úplně všechny tickety (i uzavřené)
      • Dává orientační přehled o metrikách M17b, M17c, M17d
    • M17b - Minimální doba první odpovědi
      • Minimální časový rozdíl mezi vytvořením požadavků a prvním Correspond od uživatele z @internal_emails, přičemž Correspond je v časovém intervalu <nyní-$stat_period, nyní>. Vztaženo na úplně všechny tickety (i uzavřené)
      • Minimální doba, kterou CIV potřeboval na první odpověď uživateli. Orientační hodnota, ve které frontě je nejvšímavější řešitel (anebo má jednoduché úkoly :)).
      • Čím menší, tím lépe
    • M17c - Maximální doba první odpovědi
      • Maximální časový rozdíl mezi vytvořením požadavků a prvním Correspond od uživatele z @internal_emails, přičemž Correspond je v časovém intervalu <nyní-$stat_period, nyní>. Vztaženo na úplně všechny tickety (i uzavřené)
      • Maximální doba, kterou CIV potřeboval na první odpověď uživateli. Teoreticky by neměla být delší než maximální počet dní volna ve sledovaném období. Příliš vysoká hodnota svědči o problému s odpovídáním.
      • Čím menší, tím lépe
    • M17d - Průměrná doba první odpovědi
      • Obdobně jako M6, akorát jde o průměr, takže lépe postihuje celkový přístup k řešení ve frontě
      • Čím menší, tím lépe
  • M16 - Charakteristika odpovědí ve sledovaném intervalu
    • Poznámka: pokud je sled událostí requestor.correspond1, requestor.correspond2, civ.correspond1, pak je doba čekání na odpověď určována jako civ.correspond1 - requestor.correspond1; Pokud requestor nesouhlasi s vytvoritelem ticketu (typicky hlaseni BSA, zalozeni ticketu za nekoho jineho), nelze sparovat a jsou vynechany
    • M16a - Počet v3ech odpovědí ve sledovaném intervalu
    • M16b - Minimální doba odpovědi
    • M16c - Maximální doba odpovědi
    • M16d - Průměrná doba odpovědi
  • TODO
    • M7 volne nazvy
    • pocet ticketu jejichz creator neni mezi requestory

Výpočet metrik

Postup jak jsou jednotlivé metriky získávány.

TODO

Vyhodnocení vývoje kritérií v čase

Z časového vývoje kritéria lze vyvodit další informace než jen z jednotlivých bodových údajů

TODO