Projektové týmy v MS Teams

Když tomu říkáme "tým", vypadá to jako tým a funguje to jako tým, nejspíš to bude tým.

Projekt

Viz metodika - mimořádná aktivita. Specifická skupina lidí. Má mít ohraničený (chráněný) prostor, ve kterém má data a nástroje, které využívá k práci ("...dělá něco významného..."):

• Projektovou dokumentaci - podklady, výstupy, ...
• Plán prací (včetně úkolování - přesněji systém pro podporu řízení projektu).
• Specifikace výstupů (včetně správy požadavků a řízení změn) -> akceptační kritéria.
• Podle toho, jak vyspělé projekty řídíme, tak agendu správy rizik a další.

Projektový tým - konkrétní skupina lidí, kteří se na realizaci podílejí - plní role v konkrétní organizaci projektu a plní úkoly (jsou přiřazeni jako zdroj k úkolům plánu práce).

Co potřebujeme pro řízení projektu?

Projektovou kancelář a odpovídající prostředí / nástroje.

• Úložiště projektové dokumentace s podporou workflow pro řízení tvorby a úprav. Jak přesně má vypadat projektová dokumentace, může / bude záviset na typu projektu a vaší metodice.
• Inteligentní mechanismus pro sjednávání a modifikace požadavků - podpora inicializace, diskuse, formulace a připomínkování datově (tzn. v seznamech, nikoli v dokumentech) definovaných specifikací a jejich akceptačních kritérií/testů. Změny jsou řízeny (projednávány, dokumentovány a schvalovány) a protokolovány a jejich součástí jsou i příslušné úpravy akcetptačních testů. Akceptační (popř. předakceptační) testy se provádějí sjednaným jednoznačným způsobem a jejich výsledky jsou zde zadávány a zpracovány (více samostatně). 

Pozor! Pro dílčí / průběžné výstupy je to také užitečné.

• Integrovaný nástroj pro správu kapacit firemních zdrojů (Project for Web/Teams). Který podporuje nebo je upravitelný pro řízení pomocí úkolu (podle principů MBO).
• Propojení schůzky/jednání s činností v plánu prací. Dle závazné a podrobné metodiky pro řízení schůzek (případně specificky pro projekty).
• Komunikační prostředky podporující organizaci jednání, zadávání a sledování plnění úkolů atd.
• Podporu pro obsazování a předávání pozic/rolí (automatizace zařazování do skupin nejen pro účely řízení přístupu) - procesní (workflow) podporu organizace práce na projektu.

Záleží na metodice / systému projektového řízení.

Jak má projekt probíhat?

Základní požadavky jsou jasné.

• Je nutno zamezit zahajování projektů, které nejsou nutné nebo na ně není dostatek zdrojů (popř. jim musí předcházet jiné změny). Tedy je potřeba začít plánovat včas.
• Když je akceptován námět (způsob posuzování samostatně), je jisté, že budou vznikat materiály (návrh záměru & projektu, aby mohl být posouzen), které bude nutné sdílet. Proto musí bezprostředně vzniknout pracovní prostor (který bude následně vyžíván i pro řízení projektu), ve kterém mohou lidé, kteří se na práci účastní, jednoduše sdílet podklady, dokumentaci a komunikovat. Všichni včetně těch zapojených později, mají k dispozici všechny informace - proto musí platit přísný zákaz předávat informace trvalého charakteru nevhodnými kanály (email, chat, ...).
  • Zpřístupnit informace (podklady, ...) & zjednodušit způsob jejich předání (aby každý, kdo má cokoli relevantního, byl schopen své materiály zpřístupnit všem). Také je dobré se naučit správně využívat automatické notifikace, případně umožnit jednoduché využití standardních pracovních postupů (např. když umístím či aktualizuji dokument v knihovně dokumentů, lze k němu spustit připomínkování - rovnou z knihovny, popř naopak - pomocí jednoduchého rozhraní - Power App v Teams - přidám dokument s potřebnými metadaty a všechno ostatní proběhne automaticky).
  • Zadávat/sjednávat a kontrolovat/přebírat plnění úkolů.
  • Podílet se na tvorbě specifikací a plánu práce.
• Chceme podporovat organizaci jednání.
  Všechny myslitelné scénáře, i takové, které někomu nepřipadají rozumné.
  
  • Přípravu (podklady).
  • Řízení průběhu.
  • Zpracování závěrů.
• Účastníci musí mít možnost velmi jednoduše zaznamenávat postup své práce = aktualizovat stav svých úkolů a tím (adaptivní) plán prací projektu. Právě k tomu se hodí propojení na kalendář.
• Pravděpodobně budeme chtít sdílet některá data s externími subjekty (ať už případnými zákazníky/partnery nebo dodavateli). Potřebujeme tedy poměrně robustní systém správy přístupu.

Co by měl obsahovat Team projektu?

Vzniká automatizovaně (vznikem projektu cestou projektové kanceláře - ono zdaleka nestačí, když k obsahu má přístup projektový tým) dle závazné šablony pro projekt - pro všechny navržené typy obsahu stanovena závazná pravidla, žádná lidová tvořivost.

• Standardní prvky
  • Knihovnu dokumentů... je jisté, že má být jenom jedna, pokud není potřea samostatná knihovna pro publikování uveřejnitelných výstupů pro "pozorovatele".
  • OneNote pro poznámky aj.
• Project for Teams | Planner... jednotně. Zjevně stačí úplně nejjednodušší nástroj. Ale je dobré jej propojit s úkoly a řízením času.
• Mechanismus pro propojení specifikací a akceptačních testů na plán práce s podporou projednávání a dokumentování změn (konzistentní správa akceptací... níže).
• Propojení na centrální systém řízení rizik (více samostatně).
• Analogicky sdílený mechanismus pro správu podnětů / odchylek.
• Rozhraní do knihovny podnikové dokumentace, popř. knowledge-base.

Potřeby - požadavky - specifikace - akceptace

Při řízení projektu je potřeba:

• Pomoci identifikovat a popsat (jednoznačnost, bezkonfliktnost) potřeby (co kdo jak proč dělá v současnosti a co jsou příčiny a jaké možnosti změn).
• Na tom základě formulace a konsolidace požadavků (do podoby vhodné pro sjednání mezi zadavatelem a realizátorem).
• Specifikace popisují vlastnosti / podobu vytvářeho výstupu. Měly být provázány na činnosti projektu, které danou část / vlastnost výstupu vytvářejí (tak determinují způsob jejich dosažení). Jedna specifikace může deklarovat uspokojení více požadavků a jeden požadavek se může promítnout do více specifikací.
• Tento seznam vlastností se rozpracuje na akceptační kritéria (jedno kritérum může krýt i více specifovaných vlastností). Definují, jakým způsobem se ověří, že dosažená úroveň té které vlastnosti pokrývá "své" požadavky.
• Pro kritéria se sjednají akceptační testy - jeden test může ověřovat splnění více kritérií a plnění kritéria může být podmíněno více testy.

Každá změna ve výše uvedených položkách může vyvolávat závislé změny. Musí být protokolována a potvrzena zadavatelem (na úrovni projektu i jeho částí a úkolů). Neodsouhlasená změna by měla blokovat zahájení závislých prací. Může to vypadat "složitě". Jenže realita taková prostě je. Nepřípustné zjednodušování může způsobovat významné škody.

MS Teams prakticky vše uvedené podporují, s drobnými vylepšeními nabízejí potenciál pro radikální zvýšení kvality řízení projektu. Nutno upozornit, že úplné využití možností není úplně triviální a např. umístění některých typů podkladů, případně výstupů je potřeba dobře rozvážit. Obdobně jako u všeho - nejdříve je potřeba si vyjasnit pravidla pro řízení projektu, minimálně založit typologii, získat základní dovednosti např. pro řízení dokumentace (připomínkování) atd. Nejlépe upravit stávající systém projektového řízení (nebo vytvořit, pokud jej nemáte) s využitím procesního metamodelu a iterativního rozvoje nástrojů.