Príde tiket. Práca je väčšia než pre jedného človeka alebo trvá dlhšie než jedno popoludnie. GLPI ponúka tri spôsoby, ako ju namodelovať — úlohy v rámci tiketu, vzťah rodič-dieťa medzi tiketmi alebo projekt — a väčšina tímov si na prvý raz vyberie zle. Cena zlej voľby je reálna: chybne klasifikovaná práca má nesprávny reporting, nesprávne SLA a oveľa ťažšie sa neskôr migruje do správnej štruktúry, než keby sa tam začalo.
Úlohy: rozdelenie v rámci jedného tiketu
Úloha (Task) žije vnútri rodičovského tiketu. Má vlastného riešiteľa, termín, plánované aj skutočné trvanie a stav (Vyriešiť / Vyriešené). Nemá vlastné SLA, vlastného žiadateľa, vlastnú kategóriu ani vlastné pravidlá viditeľnosti — všetko dedí od rodičovského tiketu.
Úlohy sú správne vtedy, keď má jeden tiket viac krokov, ktoré spolu prejde jeden alebo dvaja technici. Príklad: „Inštalácia novej tlačiarne na financiách." Technik vytvorí úlohy Natiahnuť kábel zo switchu, Pripevniť tlačiareň, Nakonfigurovať ovládač na print serveri, Otestovať z troch staníc. Všetko vykonáva tá istá skupina, voči tomu istému SLA, pre toho istého žiadateľa.
Úlohy sú zlé vtedy, keď kroky potrebujú rôzne SLA, rôzne tímy bez vzájomnej viditeľnosti, alebo rôzne kritériá ukončenia — pretože nič z toho sa vnútri jedného tiketu nedá líšiť.
Tikety rodič-dieťa: práca naprieč tímami
GLPI podporuje prepojenie tiketov vo viacerých vzťahoch, najužitočnejším je Rodič / Dieťa. Každý detský tiket je plnohodnotným tiketom: vlastná priraďovacia skupina, vlastné SLA, vlastný stav nezávislý od rodiča. Rodičovský tiket drží komunikáciu so žiadateľom; deti nesú technickú prácu.
Toto je správna štruktúra, keď práca preteká cez hranice tímov. Požiadavka na onboarding nového zamestnanca ide na začiatku do HR; vznikajú detské tikety Pridelenie laptopu (hardware IT), Vytvorenie účtov (identity tím), Pridelenie miesta (facility). Každé dieťa má vlastné SLA podľa záväzkov daného tímu a rodič zostáva otvorený, kým sa nezavrú všetky deti.
Cenou štruktúry rodič-dieťa je governance: niekto musí rozhodnúť, ktoré deti blokujú zavretie rodiča, kto môže deti vytvárať a ako sa stav propaguje hore. Bez toho vznikne rodičovský tiket, ktorý je „otvorený, čakajúci" dva mesiace, lebo na jedno dieťa sa zabudlo.
Projekty: plánovaná práca s míľnikmi
Projekty žijú vo vlastnom module (Nástroje > Projekty), nie vo fronte tiketov. Projekt má dátum začiatku a konca, míľniky, projektové úlohy (iné než úlohy v tikete), členov tímu s percentuálnou alokáciou a Gantta. Projekty môžu generovať tikety a tikety môžu byť prepojené na projekty, ale projekt je inou entitou — je plánovaný, nie reaktívny.
Projekty sú správne vtedy, keď je práca plánovaná na týždne či mesiace dopredu, má formálne míľniky a dodávku. Upgrade GLPI 10→11 je projekt. Migrácia datacentra je projekt. Sťahovanie kancelárie je projekt. Príprava na ISO 27001 audit s podčasťami a závislosťami je projekt.
Projekty sú zlé pre reaktívnu prácu, aj keď je veľká. Major incident nie je projekt. Multi-tímová odpoveď na incident sú tikety rodič-dieťa, nie projekt — pretým, kým by ste nastavili Gantta, je incident vyriešený.
Rozhodnutie: tri otázky
Keď príde otázka štruktúry, pýtajte sa v poradí:
- Je to plánované (vs. reaktívne)? Ak plánované s míľnikmi a dodávkou: projekt. Ak reaktívne: pokračujte.
- Prechádza to cez tímy s rôznymi SLA? Ak áno: tikety rodič-dieťa. Ak nie: pokračujte.
- Potrebuje jeden tím sledovať viac krokov? Ak áno: jeden tiket s úlohami. Ak nie: je to pravdepodobne len jeden bežný tiket.
Riešené príklady: „Nasadiť endpoint protection na 200 laptopov" — plánované, dodávka, míľniky → projekt. „Nový zamestnanec nastupuje v pondelok" — reaktívne, prechádza HR/IT/facility → rodič-dieťa. „Vymeniť pokazený disk na produkčnom serveri" — reaktívne, jeden tím, viac krokov → tiket s úlohami. Vyberte raz, ešte pred začatím práce. Náklady migrácie medzi štruktúrami sú oveľa vyššie než náklady na plánovanie.