Oblast PM hodnotí řízení projektu — řídicí rutiny, plánování, reporting, role a evidenci rizik. Vychází z procesní dokumentace (Confluence), ne z kódu.

Zdroj a rozsah

Vyhodnoceno z Confluence prostoru „TF Platform" (Základní procesy, Práce s Jirou, Prioritizace, Onboarding, Nasazení). Hodnotíme, zda je proces zdokumentován; jeho dodržování v praxi (živý stav Jira, kvalita tiketů, estimaty, reporting) vyžaduje přístup k Jira a rozhovor (➖). TFPL je navíc interní produkt, takže část položek mířících na klienta je méně relevantní.

📊 Skóre

Stav	Počet
🟢 OK	1
🟠 Částečně	4
🔴 Špatně	6
➖ Mimo rozsah (Jira/rozhovor)	1

Celkově: silně je zdokumentovaný interní vývojový / Jira pipeline (workflow, povinné estimaty a selecty, prioritizace, dashboardy). Slabá až chybějící je PM vrstva směrem ke klientovi — pravidelný stavový report, delivery plán, registr rizik, viditelnost odchylek. Většina procesních stránek je navíc z roku 2024 — u ostrého auditu nutno ověřit aktuálnost rozhovorem.

🔍 Co jsme hodnotili

#	Položka	Stav
1	Jira workflow (stavy, owner, estimate, priorita, dashboard)	🟢
2	Prioritizovaný backlog / zadání pro tým	🟠
3	Záznam nasazení (changelog + UAT)	🟠
4	Projektové role a odpovědnosti	🟠
5	Standard popisu tiketů	🟠
6	Zapsané řídicí rutiny a jejich frekvence	🔴
7	Delivery plán na nejbližší 2 týdny	🔴
8	Registr rizik / decision log s dopadem, ownerem, termínem	🔴
9	Limit velikosti tiketu (max 2 MD)	🔴
10	Viditelnost odchylek od plánu (owner/dopad/krok)	🔴
11	Písemné potvrzení rozhodnutí a dohod	🔴
12	Pravidelné písemné shrnutí stavu klientovi	➖

📌 Klíčové nálezy

🟢 Silný Jira / vývojový pipeline

Proces práce v Jira je dobře zdokumentovaný: definované stavy workflow, povinné vlastnictví ticketu, restrikce (original estimate před IN PROGRESS; povinné selecty Testy/Migrace/Dokumentace/Infra před code review), prioritizace řazeným backlogem a dashboardy (JQL). Zdokumentovaný je i postup nasazení na produkci se záznamem do changelogu a stavem UAT (schválení uživatelem).

🟠 Role a standard tiketů jen částečně

Onboardingová stránka nedefinuje formální matici rolí a odpovědností — dílčí odpovědnosti (ticket owner, kdo prioritizuje) jsou roztroušené. Standard popisu tiketu je částečný (service tag, issue types, povinné selecty), reálnou kvalitu popisů ale nelze z dokumentace ověřit.

🔴 Chybí PM vrstva směrem ke klientovi

V auditovaných stránkách nejsou zdokumentované: řídicí rutiny a jejich kadence (stand-up/retro/report), delivery plán na 2 týdny, registr rizik / decision log, sledování odchylek od plánu (owner/dopad/krok) ani písemné potvrzování dohod. Limit velikosti tiketu (2 MD) v těchto stránkách také není.

ℹ️ Kontext: TFPL je interní produkt, takže část těchto položek (report klientovi, potvrzené dohody) je méně relevantní než u externí dodávky. U auditu vašeho systému by právě tahle vrstva byla klíčová a hodnotila by se s přístupem k vaší Jira a rozhovorem.

➖ Dodržování v praxi — nutno ověřit z Jira

U položek jako soulad Jira s realitou, kvalita a velikost tiketů, reálný delivery výhled nebo reporting klientovi platí, že proces může být zdokumentován, ale skutečné dodržování se ověří jen v živé Jira a rozhovorem.

✅ Doporučení

Priorita	Doporučení
Vysoká	Zdokumentovat řídicí rutiny (kadence stand-up/retro/report) a sledování odchylek od plánu.
Vysoká	Zavést registr rizik / decision log s ownerem a termínem.
Střední	Aktualizovat procesní stránky z roku 2024 a doplnit standard velikosti/detailu tiketů.