Proces: Client service, change management (CWCS)
Proces: Client service, change management (CWCS)
Verse: 2v0
Datum: 9.1.2012
Vlastník procesu: - Role Project Manager
- Role Account Manager
- Role Operátor
Nadřízený proces: - RFP (nepovinně)
Hlavní podřízené procesy: -
1 Účel procesu
Proces ve svém celku zajišťuje realizaci a dodávku softwarového produktu nebo realizaci změn pro konečného stávajícího zákazníka, který má s Onlio, a.s. uzavřenou smlouvu o podpoře SLA.
2 Stručný popis procesu
Proces zajišťuje úkony, které je třeba vykonat k dosažení výsledného softwarového produktu. Díky nastavení a dodržení procesu by měly být zabezpečeny jednotlivé kroky, které zahrnují postup vzniku software od jeho návrhu, přes vývoj, až po dodání zákazníkovi. Proces ve svých fázích zahrnuje úkony kontrolních mechanizmů, aby byl zajištěn požadavek, kdy poptávka zákazníka bude uspokojena výsledným produktem.
3 Zkratky a pojmy
JIRA - nástroj pro elektronickou evidenci požadavků TL - Team Leader
BSD - Manager Business Solution Delivery HR - personální oddělení
PM - Project Manager AM - Account Manager
CMS - Content Management System
4 Evidence, SW podpora
Proces je evidován v JIRA (xxxxx://xxxx.xxxxx.xxx/) v samostatném projektu Onlio - client service (JIRA Project Key: CWCS), který zabezpečuje řízení požadavků stávajících klientů. Zpravidla se jedná o klienty s podepsanou smlouvou SLA. Procesem projektu jsou řízeny z velké části změnové požadavky zákazníka a "malý" softwarový vývoj.
5 Popis procesu v JIRA
Kapitola popisuje nastavení a chod procesu vývoje v JIRA.
5.1 Terminologie a obecná pravidla
Popsáno v poslední schválené verzi dokumentu "Terminologie JIRA".
6 Cyklus projektu
6.1.1 Příchozí požadavek (JIRA, mail, telefon…)
1. Eviduje role operátor, provádí první filtraci (vložení metadat, kontrola zadání, směrování na vykonavatele). Speciální požadavek řady IT projektů (UPA, CKF atd.) je přidělen rovnou na projektovou skupinu, pomocí kroku workflow DEVELIVERY s přidělením skupiny s prefixem PRJ.
Doba trvání úkonu cca 2 minuty (čas uveden především pro představu, jaký by měl být cca objem práce)
2. Eviduje role operátor - druhý stupeň filtrace, kdy je nutné zvážit prioritu daného issue, dostupnost AM/PM a správné směrování s ohledem na prioritu. Z tohoto kroku issue směřuje zpravidla delší cestou, tedy přes pracovníky v roli AM/PM, pomocí kroku workflow LEADER s přidělením pracovníka.
Doba trvání úkonu cca 10 minut celkem i s prvním stupněm filtrace (čas uveden především pro představu, jaký by měl být cca objem práce)
6.1.2 Zkrácená cesta požadavku (rutinní požadavky)
1. Přidělení rovnou na projektovou skupinu (PRJ-CKF, PRJ-UPA atd.) nebo týmovou skupinu (TEAM-MS, TEAM-WEB, TEAM-JAVA atd.), pomocí kroku workflow DELIVERY s přidělením správné skupiny nebo týmu. Tento postup je aplikován v případě rutinních požadavků, globálně těch, které nevyžadují další komunikaci s klientem. Příkladem jsou to opakované publikace fotogalerií, importy dat, jednoduché změny obsahu atd.
2. Požadavek má přidělený skupina nebo tým, jejichž členové byli emailem informováni o přiřazení požadavku. Team/Project Leader dále požadavek přiděluje konkrétnímu pracovníkovi. Další variantou je možnost, kdy si pracovníci sami přiřazují požadavky, které jsou ke zpracování pro danou týmovou/projektovou skupinu. Tedy pracovník se sám podívá do filtru, co je nutné zpracovat a na požadavku začne pracovat (je aplikováno např. u webového týmu).
3. V případě nejasností zadání je issue vráceno příslušnému AM/PM daného klienta k ujasnění. Ujasnění může provést sám, jelikož klientovi požadavky zná nebo provede konzultaci s klientem a výsledek předá zpět týmové/projektové skupině.
6.1.3 Cesta požadavku přes AM/PM
1. Předání požadavku k AM/PM pomocí kroku workflow LEADER s přidělením pracovníka. K AM/PM se dostávají požadavky, které vyžadují jeho zásah. Tím může být pouhé ujasnění zadání požadavku, ale také např. nabídka jiného, lepšího, efektivnějšího řešení, které zohledňuje současné trendy nebo nabízí nové možnosti CMS Aladin apod. Důležité je, aby v tomto kroku VZNIKLO ÚPLNÉ ZADÁNÍ POŽADAVKU tak, aby se dal předat do vývoje. Pakliže to zadání vyžaduje, vzniká rozdělení požadavku na jednotlivé issue (sub-task). V tomto kroku se může také zjistit, že jde o požadavek nad rámec procesu a projektu CWCS a celý požadavek se přesměruje do procesu RFP. Zpravidla se tak děje při rozsahem a finančně objemných požadavcích.
2. Předání do vývoje pomocí kroku workflow DELIVERY s přidělením pracovníka nebo týmu. Požadavek se předává do vývoje a to buď příslušnému PM (pakliže jde o činnost, u které je nutná účast PM) nebo se přiděluje danému týmu dle skupin (WEB, GRAFIKA, ADMIN atd.). V tomto kroku probíhá řešení požadavku. Pakliže vznikne nejasnost v zadání, předává se zpět příslušnému AM/PM pomocí kroku workflow LEADER s přidělením pracovníka a kroky se opakují do jejich vyřešení.
6.1.4 Požadavek ukončen
1. Předání hotového požadavku zpět AM/PM pomocí kroku workflow LEADER s přidělením pracovníka. Požadavek je vyřešen a předán AM/PM, který dále komunikuje s klientem o ukončení a předání prací. AM/PM doplňuje fakturační data a issue předává klientovi ke konečné akceptaci.
2. Po akceptaci klientem je požadavek uzavřen.
6.2 Metadata
Výběr důležitých položek, se kterými se v projektu pracuje.
Component/s
Označuje klienta, kterému dané issue přísluší.
Fix Version/s
Tato položka označuje DUZP fakturace, ve které jsou práce fakturovány. Pro aktivní (otevřené) issue slouží hodnota "Aktuální verze".
.plánovaný start
Datum plánovaného startu definuje den, kdy se má začít s prací. Vyplněná hodnota ovlivňuje notifikace pro hlídání SLA parametrů.
.plánovaný čas
Plánovaný čas ukazuje očekávanou dobu trvání úkolu v hodinách.
.plánované dokončení
Datum plánovaného dokončení určuje den ukončení prací. Vyplněná hodnota ovlivňuje notifikace pro hlídání SLA parametrů.
.nejpozdější reakce
Nejpozdější reakce je počítané pole, které ukazuje datum a čas nejpozdější reakce pro dodržení SLA parametrů.
Cena bez DPH
V kroku "Verify" je povinnou položkou. Celková cena za provedené práce.
Čas
V kroku "Verify" je povinnou položkou. Čas, který je fakturovaný klientovi.
Rozpočet
V kroku "Verify" je povinnou položkou. Slouží i pro pravidelné reporty. Hodnotou ve většině případů je jedna z položek číselníku. Pro zjednodušení práce používáme program, který rozšiřuje možnosti standardní systémové schránky o volbu z předdefinovaných možností.
Hodnoty číselníku:
PRÁCE V HODINOVÉ SAZBĚ 1 000,- Kč PRÁCE V HODINOVÉ SAZBĚ 1 500,- Kč ZAHRNUTO DO PAUŠÁLU REKLAMACE
INTERNÍ PROJEKT
PRÁCE JSOU VYÚČTOVÁNY V RÁMCI NADŘAZENÉHO ISSUE PRÁCE JSOU VYÚČTOVÁNY V RÁMCI OBJEDNÁVKY
PRÁCE JSOU VYÚČTOVÁNY V RÁMCI PROJEKTU PRÁCE JSOU VYÚČTOVÁNY V RÁMCI SLA REALIZOVÁNO V RÁMCI SMLOUVY
POPTÁVKA SLUŽEB POŽADAVEK NEREALIZOVÁN
REALIZOVÁNO V RÁMCI DOHODY ADMINISTRATIVNÍ PRÁCE ADMINISTRATIVNÍ ISSUE DUPLICITNÍ ISSUE
INTERNÍ ÚKOL REŽIJNÍ ČAS
PRÁCE BYLY PROVEDENY V REŽII ONLIO ISSUE NEREALIZOVÁNO - ZALOŽENO Z MAILU
Security Level
Položka, která zajišťuje zpřístupnění issue danému klientovi.
Component Lead
Jde o počítané pole. Zobrazuje jméno nebo jména pracovníků odpovědných za daného klienta.
Faktura
Zajišťuje a zobrazuje propojení na fakturu ve vazbě na projekt faktur vydaných.
6.3 Workflow
schématické zobrazení workflow
6.3.1 Stav "Open"
Do stavu "Open" se požadavek dostává z akce "Create Issue", kterou může provádět v rámci projektu CWCS i klient s přístupem k systému JIRA a oprávněním vytvoření požadavku.
Metadata:
• Typ issue - výběr "Task", "New Feature", "Improvement", "Bug"
• Summary
• Priority
• Due date
• Description
• Přílohy
• Security Level
• URL
• Comment
Akce:
• Leader
• Delivery
• Quick Close
6.3.2 Stav "Leader"
Stav "Leader" zpravidla slouží ke komunikaci s klientem. Tento stav je klíčovým stavem procesu. Metadata:
• Typ issue - výběr "Task", "New Feature", "Improvement", "Bug"
• Summary
• Description
• Fix Version/s
• Assignee
• Reporter
• Component/s
• Due date
• Priority
• Rozpočet
• Security Level
• .plánovaný start
• .plánované dokončení
• .plánovaný čas
• Přílohy
• URL
• Comment
Akce:
• Delivery
• Test
• Call for Approve
• Wait
• Verify
• Quick Close
6.3.3 Stav "Waiting for Approve"
Do stavu se převádí ve chvíli, kdy jsou práce vyjasněny a je třeba získat souhlas klienta.
Metadata:
• Assignee
• Due date
• Priority
• Rozpočet
• Security Level
• .plánovaný start
• .plánované dokončení
• .plánovaný čas
• Comment
Akce:
• Approve
• Not Approve
6.3.4 Stav "Not Approved"
Do stavu "Not Approve" issue převádí klient v případě, že nesouhlasí s navrhovaným řešením nebo podmínkami. Do komentáře uvádí důvody nesouhlasu. Pracovník v roli AM/PM může vyjasnit nebo upravit podmínky řešení a znovu požádat o souhlas. V opačném případě issue uzavírá.
Metadata:
• Comment
Akce:
• Call for Approve
• Close
6.3.5 Stav "Delivery"
Stav "Delivery" je výkonným stavem procesu. V tomto stavu probíhá samotný vývoj, úpravy atd.
Metadata při zkráceném procesu ze stavu "Open":
• Typ issue - výběr "Task", "New Feature", "Improvement", "Bug"
• Summary
• Description
• Fix Version/s
• Assignee
• Reporter
• Component/s
• Due date
• Priority
• Rozpočet
• Security Level
• .plánovaný start
• .plánované dokončení
• .plánovaný čas
• Přílohy
• URL
• Comment
Metadata při přesunu z ostatních stavů (Leader, Testing, Waiting):
• Assignee
• Comment
Akce:
• Test
• Leader
• Wait
• Verify
6.3.6 Stav "Testing"
Stav "Testing" je stavem, který úzce spolupracuje s činnostmi ve stavu "Delivery". Jde o stav, kdy jsou kontrolovány výsledky práce pracovníku z vývoje.
Metadata:
• Assignee
• Comment
Akce:
• Delivery
• Leader
• Wait
• Verify
6.3.7 Stav "Waiting"
Do stavu "Waiting" je issue přesunuto ve chvíli, kdy na úkolu nelze pracovat, protože se na "něco" čeká. Zpravidla se jedná o podklady, o přístup apod. Předmět čekání je upřesněn komentářem. Issue ve stavu "Waiting" se obyčejně předává vedoucímu pracovníkovi.
Metadata:
• Assignee
• Due Date
• .plánovaný start
• .plánované dokončení
• .plánovaný čas
• Comment
Akce:
• Leader
• Delivery
• Test
• Verify
6.3.8 Stav "Verified"
Stav "Verified" říká, že byla provedena kontrola nasazení změn, byly vyčísleny náklady spojené s požadavkem, je povinně vyplněn strávený čas na provedení požadavku, do pole "Rozpočet" jsou uvedeny detaily účtování a je uvedena cena v Kč. Celé je předáno k odsouhlasení klientem.
Metadata:
• Resolution (povinné)
• Fix Version/s
• Assignee
• Čas (povinné)
• Cena bez DPH (povinné)
• Rozpočet (povinné)
• Security Level
• Faktura
• Comment
Akce:
• Accept
• Reopen
6.3.9 Stav "Accepted"
Do stavu "Accepted" se issue dostává se souhlasem klienta. Issue může za klienta akceptovat pracovník v roli AM/PM, ale v takovém případě by měl v komentáři být uveden text, který říká na základě jakého rozhodnutí bylo issue akceptováno. Příkladnými důvody mohou být akceptace jinou cestou, např. telefonicky, osobně nebo je řešení nasazeno nad rámec lhůty pro automatickou akceptaci bez výhrad.
Metadata:
• Assignee
• Comment
Akce:
• Invoice Data
• Leader
• Close
6.3.10 Stav "Closed "
Do stavu "Closed" požadavek přechází ze stavu "Open", "Leader" přechodem "Quick Close", který je zkráceným uzavřením issue. Nastane v případech, kdy je požadavek z jakéhokoliv důvodu zrušen, je duplikován jiným existujícím požadavkem nebo existuje jiný důvod k jeho uzavření bez realizace. K ukončení ze stavu "Accepted" dochází po dokončení realizace a předání řešení.
Metadata při posunu pomocí "Quick Close":
• Resolution (povinné)
• Assignee
• Component/s
• Fix Version/s
• Čas (povinné)
• Cena bez DPH (povinné)
• Rozpočet (povinné)
• Security Level
• Faktura
• Comment
Metadata při posunu pomocí "Close" ze stavu "Accepted":
• Fix Version/s
• Faktura
• Comment (Komentář)
Akce:
• Edit data (slouží oprávněným uživatelům ke změně údajů v issue)
• Reopen
6.3.11 Stav "Reopen" (přechází do stavu "Leader")
"Reopen" se využívá ze stavu "Verified" a "Closed". V obou případech se provádí v situaci, kdy nastala potřeba issue znovu předat ke zpracování. Např. byly ve zpracování nalezeny chyby. Při využití kroku "Reopen" přejde issue ve skutečnosti do stavu "Leader".
Metadata v případě přechodu ze stavu "Verified":
• Assignee
• Comment
Metadata při přechodu ze stavu "Closed":
• Typ issue - výběr "Task", "New Feature", "Improvement", "Bug"
• Summary
• Priority
• Due date
• Component/s
• Fix Version/s
• Assignee
• Reporter
• Description
• Rozpočet
• Attachment
• Cena bez DPH
• Security Level
• Čas
• Security Level
• .plánovaný start
• .plánované dokončení
• .plánovaný čas
• Faktura
• URL
• Comment
Akce:
• V případě "Reopen" se automaticky nastaví pole "Resolutin" na hodnotu "None"
7 Dokumentace
Veškerá administrativa procesu je vedená v JIRA u daného issue, případně je založeno issue speciální, např. pro účely zápisu ze schůzky apod. U většiny klientů s uzavřeným SLA je forma komunikace v JIRA podchycena i smluvně a to včetně akceptace požadavku v JIRA jako objednávky.
Ve speciálních případech je možné vytvořit objednávku, zápis ze schůzky či předávací protokol zvlášť dle schválené šablony. Takto vytvořený dokument je nazván a uložen dle příslušné směrnice. Znalost, jaké dokumenty je třeba připravit má kompetentní pracovník v roli AM/PM.
8 Činnosti vlastníka procesu
Vlastníky procesu jsou role Project Manager, Account manager a Operátor. První dvě role zajišťují proces samotného řízení požadavku. Operátor má na starost přidělení požadavku a pravidelnou měsíční přípravu podkladů k fakturaci.
8.1 Měsíční příprava fakturace
Pracovník v roli Operátor má za úkol do dvou pracovních dnů po skončení kalendářního měsíce připravit data k fakturaci v těchto krocích:
1. V administraci projektu vytvoří novou položku "Aktuální verze".
2. Původní položku "Aktuální verze" přejmenuje na "YYYY-MM", kde YYYY je rok a MM je měsíc právě uplynulého kalendářní měsíce.
3. Převede všechna issue, která jsou v původní verzi "Aktuální verze", nyní v nové YYYY-MM a nejsou ve stavech Closed a Accepted do nově vytvořené "Aktuální verze".
4. Informuje AM/PM o tomto kroku pomocí emailu na adresu xx_xx_xxxxx@xxxxx.xxx .
9 Reporty
Pro usnadnění sledování plnění úkolů slouží sada připravených reportů.