MS Teams - organizace týmů a kanálů

Bylo nebylo…

V jedné firmě (nebojte, není to o vás) se rozhodli, že:

• Budou pro podporu spolupráce (říkali "komunikaci") používat MS Teams. Buď se do toho pustili sami (nebo možná s někým, kdo především potřeboval prodávat předplatné Office/M365).
• Vytvořili týmy. Nijak moc promyšleně - spíš tak, jak to fungovalo dosud. Nebyl důvod jinak. Dle "organizační struktury". Útvarů.
• K zakázkám a jiným aktivitám, na kterých začínaly jednotlivé týmy pracovat, vytvářeli v rámci týmů kanály.

To není dobrý nápad. Pochopitelně to ani zdaleka nefungovalo uspokojivě a po delší době se ukázaly neřešitelné problémy. Např. chtěli uložit obsah zpráv uvedených v kanálech a to se dělá jen velmi obtížně. Ve většině jiných uposlechli "doporučení" a nechali uživatele, ať si vytvářejí týmy jak sami uznají za vhodné. Což je naprostá katastrofa.

Pokud jste v podobné situaci, ozvěte se.

Jak naznačený případ, tak využívání Teams jsou poněkud obtížně vysvětlitelné. Také proto je článek tak dlouhý a nepříliš srozumitelný. Něco s tím uděláme... 

Co ve skutečnosti potřebujeme

Zkuste zapomenout na to, že skupině lidí, která má v rámci funkčního uspořádání stejného "vedoucího" & víceméně konstantní povinnosti, říkate "tým". Pro jejich zapojení do firemní dělby práce potřebujeme systém umožňující podporu na procesním principu (viz procesní přístup a článek Organizační struktury).

Rutinní činnosti nemají být podporovány nástrojem určeným pro jednorázové akce (organizaci a kooordinaci týmu při realizaci konkrétního jednorázového záměru), byť se může zdát, že to "jde". Statický "tým" organizačního celku ve funkčním uspořádání je samozřemě také skupina lidí. Také používají úkoly a sdílí informace.

Jenže převážná většina toho, co využívají, má trvalou platnost a prakticky vždy se týká jiných útvarů. Opakuje se to. Je žádoucí, aby se to dělalo stejně nebo obdobně. Je zřejmé, že např. na obchodním případu / zakázce budou pracovat lidé napříč firmou. V rozumných scénářích zde budou externí subjekty, které je účelné zapojit do "komunikace" (typicky se mohou podílet na více zakázkách s obdobným obsahem, rozhodně je žádoucí sdílení informací mezi zakázkami atd.).

Klíčová otázka je, co se myslí pojmem komunikace. Někteří jedinci se tímto způsobem snaží obejít "maily" (aby nemuseli pracovat s e-mailovým klientem). Může být, že neumí nebo se jim nechce korektně reagovat na (jakékoli) doručené zprávy. Většinou  jen neumí s maily (poštovním klientem, termíny, úkoly atd.) pracovat (pomoci může Inbox Zero). Často nemají ve své organizaci prostředí, které by zpracování zpráv usnadňovalo & podporovalo. V takovém případě je lhostejné, v jaké formě zpráva dorazí.

Nastavte pro komunikaci jasná pravidla.

Pokud nahradíme mail chatem či komunikací obdobného typu (zprávy v kanálech Teams), může to být jenom horší (mj. proto, že tyto zprávy nejsou na jednom místě, nelze uspořádat, smysluplně značkovat či vytvářet z nich události či úkoly, nemluvě o naprosto neefektivní podobě interakce... kdy se musí obsah ~ někdy mnoha ~ kanálů kontrolovat a dohledávat, co se změnilo... či dokonce účastníci "čekají", co jim kdo odpoví).

Týmy & Teams × organizační struktura

Popsaná podoba nasazení Teams je sporná. Ještě mnohem větší zkázu přináší přístup (mj. podporovaný výrobcem), kdy se všem umožní zakládat týmy dle vlastního uvážení nebo obdobný chaos na doporučení rádoby expertů, kteří o věcné podstatě organizace práce a dat v daném prostředí nemají ani tušení. Ve stručnosti k čemu jsou Teams určeny a jak a proč by jejich účelné nasazení mohlo vypadat (vždy je potřeba nejdříve analyzovat a formulovat faktické potřeby):

• Týmy v Teams nejsou (primárně) zamýšleny pro podporu aktivit organizovaných uvnitř stálých útvarů statické organizační struktury. Jejich využití pro činnosti procesní oblasti je poměrně sporné (aktivity přesahují hranice útvaru/oblasti a není jednoduché nastavit pravidla tak, aby to uspokojivě fungovalo a hlavně existují mnohem vhodnější nástroje, viz jinde, např. využití pro CRM).
  • Bohužel v návodu na používání není dostatečně zdůrazněno, že týmy, které kopírují útvary (funkční organizační strukturu) jsou sice možné, ale pro racionální organizaci spolupráce nesmyslé (můžete vytvořit "útvarové týmy", ty je dobré využívat pro organizaci porad či volnočasových a obdobných aktivit celého útvaru).
  • Tým, pro které vytváříme pracovní prostředí, je účelová dočasná organizační jednotka.
  • Ve výše odkázaném návodu se praví:
    • A team is a group of people gathered to get something big done in your organization.
    • Teams are made up of channels, which are the conversations you have with your teammates.
      Tedy pro komunikaci mezi členy týmu se nemá používat chat, má se používat kanál. A protože kdyby se veškerá témata "komunikovala" v jednom kanálu, vznikl by naprosto zoufalý guláš, existují kanály. V jistém smyslu z bláta do louže. Dokud nemáte dost zkušeností - není jasné, do přesně znamená "komunikace" a co s vyměňovanými (sdílenými) informacemi potřebujete dělat, nemá smyl metodou pokus-omyl zakládat kanály. Tak vzniká ještě větší chaos, než komunikovat všechno v jednom. Klíčová otázka je, jestli/co je vůbec správné/potřeba komunikovat formou příspěvků v kanálu.
      
    • A následně "Each channel is dedicated to a specific topic, department, or project, feature, or whatever else is relevant to you..", což (ty přeškrtnuté dvě možnosti) je v rozporu s dříve uvedeným (autor jen vyjmenovává teoretické možnosti). Pro účelné použití "kanálů" je dobré striktně trvat na jednotném způsobu užití - kanál musí jediné dílčí téma. Je dobré mít konvence - zjednodušují nám život. Nejjednodušší bude kanály prostě ignorovat, pokud se neobjeví zcela konkrétní potřeba, pro kterou se budou hodit.
      Detailně & důkladně dále a jinde nebo se ptejte.
  • Pro práci musí vzniknout nezávislé "pracovní týmy", složené z lidí (interních i externích), kteří se na dané záležitosti skutečně účastní. Členové týmu mají být zaregistrovaní v Team-u, mají mít přílušné role v rámci dané aktivity a informace, které ke své práci potřebují, mají získávat především s využitím tohoto prostředí (když jim něco chybí, vznesou požadavek na zpřístupnění prostřednictvím funkčnosti Team-u).
• Pro aktivitu vzniká tým. Tým existuje jen po dobu jejího trvání. Může se v průběhu měnit (interní i externí členy přidávat či nahrazovat). Po skončení akce tým zanikne.
  Když to takto od začátku vnímáte, je zřejmé, kam patří jaké informace. Je naprosto jasné, že podklady ani finální výstupy nemohou být pouze součástí pracovního prostoru týmu. Ale všechno, co potřebujeme ze sdílených informací uchovat, musí být možno uložit / archivovat. I proto musí být každý objekt, který se v prostředí týmu bude využívat, klasifikovaný a tím mít definovaný životní cyklus.
• V běžné firmě by týmy mohly (pokud se Teams ukáží jako nejlepší možnost) být využity jako pracovní prostor pro unikátní zakázky (nebo obdobné akce, které mají charakter projektů) - pro projekt je Team ideální prostředí/komunikační prostředek.
  Pro běžné zakázky nic takového nemá smysl (je nutné je řídit provozními prostředky, procesně - s daty v provozních systémech atd.).

Je potřeba si všechno důkladně vyzkoušet. Když k tomu nemáte dost času nebo zkušeností, je rozumné si k vytvoření koncepce nasazení nového nástroje přizvat někoho, kdo potřebné znalosti a zkušenosti má. Popř. vyžádat i podporu nasazení.

Pro sdílení vhodné nástroje - wiki, knihovnu dokumentů, ... 

Všechno další je nutné nastavit dle konkrétních podmínek. Se znalostí možností a omezení - např. většina dokumentů patří (minimálně cílově) do celofiremních knihoven dokumentů. Stačí je vybavit potřebnými metadaty a zvládat řízení přístupových práv. Nekompromisně eliminovat multiplicity. Chce to se nad skutečnými potřebami zamyslet (např. v případě implementace ERP nebo čehokoli jiného).

Nová doba přináší nové potřeby a požadavky. Proto přicházejí nové nástroje. Neměli bychom nové technologie nutit podporovat "součinnost" z dob dávno minulých. Spousta dřívějších zkušeností a osvědčených postupů se v novém prostředí neuplatní. Na ty nové potřeby musíme vytvořit nové adekvátní postupy, které staví na nových technologiích.

Zjednodušeně - Teams jsou velmi silným nástrojem, pokud jej používáte správně. Jsou určeny k podpoře "...to get something big...". Abyste mohli tuto technologii správně používat (nastavit), je dobré vědět, co s ní budete chtít/potřebovat dělat. Opačně to nemůže dopadnout moc dobře. Není nutné to vědět všechno "dokonale" předem. Je nutné počítat s tím, že to bude iterativní vývoj - jak se budou měnit lepším využitím technologií pracovní postupy, budou se měnit požadavky. Chce to vhodnou architekturu. 

Minulost × budoucnost

V oné firmě z počátečního příběhu došlo k obvyklému - ne zcela vhodnému - přesunu.

• Co se dříve dělalo špatně pomocí mailu, začalo se ještě hůř dělat v chatu a kanálech Teams. Bez koncepce, pravidel, neřízeně. Bez procesů. 
• Do komunikace v rámci kanálů se uváděly věcné (obsahové) informace, požadavky a úkoly. A zůstávaly jen tam, nikdo je nepřenesl do příslušné dokumentace (či systému pro podporu řízení pomocí úkolů... zadávat jakoukoli práci formou příspěvku na nástěnku, zprávou v chatu nebo mailem je naprosto nesmyslné a nepřípustné).
  Pokud něco takového děláte, urychleně si nechte provést audit systému řízení.
• Chat (kanály) jsou zamýšleny (má smysl používat) pouze pro specifické typy interakcí. Zjednodušeně řečeno nejlépe pouze pro "upozornění" / notifikace. Nepatří tam závazné hodnoty, závěry diskuse, upřesňování zadání, natož úkoly a změny požadavků.
• Odkaz na schůzku. Případně s průvodní informací, čemu je potřeba věnovat zvýšenou pozornost (z programu, přičemž je to uvedeno i u toho bodu programu).
• Odkaz na dokument. Případně s upozorněním, kdy vyprší termín (uvedený v dokumentu). Nebo odkaz na cokoli dalšího. V naznačeném režimu.
• Pokud k tomu není vhodný jiný lepší nástroj, je možné otevřít v rámci týmu (pozor - nezávislou & striktně účelovou = omezenou) diskusi - k tématu, které je obsaženo v některém odkázaném dokumentu (či něčem podobném, např. zahájenou průzkumem či něčím podobným). Do cílového dokumentu přenést případné závěry (dle zvyklostí včetně zdůvodnění). Kanál ihned "uzavřít" (odstranit). Z toho je zřejmé, že se ani k tomuto účelu příliš nehodí. Pokud by šlo o věcný obsah některého z dokumentů, je lepší využít standardního mechanismu připomínkování.
• Když vás napadne něco jiného, k čemu by zprávy v kanálech mohly být účelně použity, napište, 

Nastavit pravidla používání tak, aby se kanál (popř. tým) dal víceméně bezprostředně po skončení příslušné dílčí aktivity odstranit (reálně dle typu akce - ale rozhodně to neznamená např. u zakázky, že by měl existovat do doběhu záruční doby - záruky je nutno řešit jiným mechanisem, byť nad částečně shodnými daty). Nemá existovat důvod, aby nadále existovat. Počítat s tím, že všechno (co je uloženo na úrovni týmu) zmizí. Co nemá zmizet, do toho prostoru týmu nepatří - umístěte to tam, kam to patří a do týmu si dejte odkazy, které pomohou případnému navigačnímu přístupu).

Někde dokonce ke zprávám v kanálu (i chatu) dávají přílohy…
Zkrátka proto, že jsou tak zvyklí (e-mail). Protože to jde.
Nemělo by to jít...

Jak to dopadlo

Když akce (zakázka/projekt) skončila, objevila se potřeba obsah těch kanálů někam uložit. Jelikož některé důležité informace (odsouhlasení diskutovaných změn v obsahu plnění/podobě spolupráce) nikde jinde nebyly. A bylo potřeba zpětně (řadu měsíců po ukončení práce) dohledat, proč se to či ono dělalo tak, jak se to dělalo. Jenže vzhledem k určení kanálů není standardně podporovano uložení obsahu chatu. Situace přímo křičí, jak se to mělo dělat lépe:

• Vyzkoušet, co a jak se dá a má dělat.
• Nastavit pravidla a pokud možno omezit nežádoucí praktiky.
• Všechno ověřit a přitom popsat & zaškolit + následně podporovat uživatele.
  Nikoli jednorázově - trvale. Lidi, systém i prostředí je nutné stále rozvíjet. 

Je nešťastné řídit se zvyklostmi komunikace založené na (nevhodném způsobu) používání elektronické pošty, jednodušších komunikátorů či jiných platforem pro spolupráci. Každý nástroj má specifika a omezení. Naše zvyklosti z dob před digitální revolucí jsou také většinou zavádějící. Pro novou technologii se vyplatí investovat přiměřené úsilí do jejího poznání a nalezení optimálního způsobu jejího nasazení.

Kam co patří

Příklady (jen nejobvyklejší typy obsahu) pro korektně nastavené týmy.

• Vstupy/podklady
  Zdroje, které mají být při akci využity (texty, data, obrázky aj.). Pro ty by mělo být využito centrální úložiště, které se připojí (filtrovaným pohledem) k danému projektu/týmu. Pro vkládání může existovat vyhrazená knihovna dokumentů (popř. centrální DMS) s potřebným flow, kterou lze nasdílet i externím uživatelům pro nahrávání dat (popř. to zajistit pomocí Forms, čímž lze zajistit potřebná metadata a spuštění příslušného procesu přijetí dat). Jedny a tytéž podklady mohou být užitečné ve více projektech a mají být uspořádány a archivovány podle obecně platných pravidel, proto je lepší použít centrální úložiště (pokud má organizace DMS, je to povinné). Musí být opatřeny odpovídajícími metadaty. Mohou být zneplatněny a aktualizovány (např. vytvořen úkol pro některého účastníka, aby doručil novou verzi - tu je potřeba umístit řízeným způsobem). Neměly by existovat ve více instancích (verzovány musí být v onom jediném/správném úložišti). Pro účelné zobrazení dle potřeb konkrétního týmu se dají využít metadata nebo odkazy (horší možnost, ty je nutno udržovat aktuální).
  Bezpochyby mají zůstat zachovány i po skončení aktivity (po zániku Team-u). Z tohoto hlediska je sporné, jaká data/dokumenty by měly být uloženy na úrovni Team-u. Pravděpodobně dávají smysl "interní" dokumenty (typicky generované a využívané pro fixování změn prováděných v interních datech - např. plánu práce, akceptačních kritériích, ...).
• Výstupy
  Pokud v průběhu či na konci práce má být zdokumentován výsledek nebo výsledkem je digitální obsah, téměř jistě patří někam, kde se s nímu bude dále pracovat (předá se či se sdílí & rozhodně má být ve své předběžné verzi zpřístupněn k připomínkování). Tedy to nejspíš nebude být interní knihovna týmu (byť to je přijatelné a přístup připomínkujících není tak zásadní problém, otázkou je podpora pro připomínkování - lepší bude využít centrální mechanismus). To lze řešit tak, že si příslušné úložiště (obvykle knihovnu SharePoint-u - je vysoce pravděpodobné, že to bude ta stejná, ve které jsou podklady, v případě DMS je to jisté) připojíte do nástrojů týmu/kanálu. Je lepší připojit a pracovat standardními způsobem nad jedinou verzí dokumentu než jej mít někde jako pracovní verzi a tu průběžně publikovat. Pro vyhrazený přístup je lepší využít možnosti "vyjmutí" (zámku). Mělo by být zakázáno dokumenty modifikovat mimo úložiště.
• Data (technická)
  Může se stát, že součástí práce týmu jsou data (datové soubory), ke kterým potřebujete zajistit přístup např. na souborové úrovni (např. výsledky dotazníků, které chcete zpracovávat nezávislou aplikací, která funguje pouze lokálně na bázi souborového přístupu). Můžete synchronizovat a zpřístupnit knihovnu dokumentů týmu, ale to je zjevně v rozporu s jednoduchostí přístupu a trvanlivostí příslušných souborů. Řešení je stejné - použijete či vytvoříte knihovnu dokumentů na SharePoint-u nebo jiném úložišti (rozumí se mimo tým; popř. složku v již připojené) a přidáte jako další nástroj (tedy úložiště musí mít konektor pro Teams; pokud nedokážete připojit úložiště jako souborový systém, resp. v té podobě, kterou vyžaduje případný prehistorický nástroj, je potřeba to řešit výhradním lokálním zpracováním a synchronizací).
• Změny požadavků či parametrů - specifikací / akceptačních protokolů
  Některé typy se dají (a bylo by to vhodnější) vypořádat přímo správou podnětů/požadavků (specializovaný nástroj buď sdílený nebo lokální v týmu). Může existovat důvod, proč jsou umístěny např. v dokumentu textového či tabulkového procesoru (požadavek zákazníka). Lze vyzkoušet přístup, že se pro každý takový podnět na změnu vytvoří samostatný kanál (nelze doporučit). Určený právě a jen pro vypořádání/diskusi o této dílčí záležitosti. Úprava může být iniciována zprávou (chat, mail či telefon - relevantní obsah ~ kopie, záznam ~ se uloží do vhodného úložiště a odkaz se umístí do chatu kanálu a tím se zpřístupni ostatním členům týmu). Případná diskuse by měla obsahovat identifikaci souvislostí (případě překážek a způsobů řešení) a závěr - jakým způsobe bude podnět/požadavek vypořádán. Závěry (a případné vázané informace) musí být přeneseny do příslušného dokumentu (požadavky na výstup, specifikace plnění, akceptační protokol apod.). Kanál se odstraní.
  Pokud žádný takový dokument neexistuje, je dobré (nutné) jej založit.
  Sdílet (zejména se zákazníkem) a průběžně informovat o provedených změnách. Opět je zřejmé, kde má být takový dokument (či jiný formát dat) umístěn - rozhodně nikoli uvnitř kanálu.
• Pokud je tým pracovním prostředím pro spolupráci na jednorázové aktivitě (projekt nebo unikátní zakázka), bezpochyby definuje tým, role, plán práce, ... data, která existují (mají smysl) pouze pokud existuje tým (aktivita).
  Ovšem pokud má řízení práce zahrnovat / respektovat dostupnost zdrojů, je nutno používat odpovídající nástroj (který umí sdílet centrální zásobník zdrojů).
• Je potřeba správně umístit i data/mechanismy, které se v tradičním pojetí mohou zdát lokální, ovšem reálně musí být centralizované - např. systém řízení rizik.
• V prostředí Team-u lze využívat jen v metodice definované prvky, typy obsahu, funkčnost atd. stanoveným způsobem. Pokud se objeví potřeba nového typu, je nutno ji nejdříve analyzovat, najít optimální řešení, doplnit do metodiky a pak to lze použít.

Vyplatí se to. Může se zdát, že bude náročné vytvořit dostatečnou sadu pravidel - co kam patří a co kdo musí udělat v jaké situaci. Je to ovšem dramaticky méně náročné, než se snažit vyznat v chaosu, který bez pravidel zákonitě vzniká.

Co je to komunikace

Klíčová otázka. Co má být - nástrojem pro podporu spolupráce - realizováno. Proč tomu říkáme "komunikace". K čemu předávání/sdílení informací potřebujeme. Co od nástroje očekáváme.

• Komunikace = výměna sdělení (viz definice komunikace na wikipedii - jen pro zajímavost). V širším pojetí se dá chápat jako technická podoba/podpora výměny (resp. sdílení) informací. Kterážto je nutná pro součinnost lidí a koordinaci jejich úsilí (viz poznávací a řídící informace).
• V podnikové praxi podpora týmové spolupráce. Částečně "výměna", ale mnohem více "sdílení" informací + úkoly. K tomu jsou MS Teams určeny.
  • Žádný nástroj nemůže podporovat všechny myslitelné způsoby použití.
  • Každý systém využívá specifické mechanismy (datové struktury apod.), odpovídající určitému pojetí (zde klíčovým principům obvyklé podoby spolupráce v typických - možná tradičních - organizacích).
  • Pro jeho rozumné využití je potřeba respektovat principy, podle kterých byl vytvořen.
• Podpora spolupráce znamená (asynchronní zprávy + interaktivní prvky):
  • Sdílení podkladů a zajištění přístupu k nim pokud možno dle rolí.
  • Spolupráce na vytváření "obsahu" = dokumenty, plán práce atd.
  • Koordinaci činností všeho typu = podporu řízení pomocí úkolů. 
  • Integraci (snadné použití) aplikací typu ankety/průzkumy apod.
  • Sběr požadavků a správu podnětů.
  • Podpora organizace schůzek a prostředky pro interaktivní spolupráci (online schůzky, chat, ...).

 

Procesy

Čím se liší komunikace (popř. širší potřeby podpory spolupráce) dočasných a trvalých týmů?

• Když se nad tím zamyslíme, je zřejmé, že v případě rutinních činností je týmem celá firma. Takový tým je korektní, ale zjevně neefektivní, protože by téměř jistě byl nepřehledný. Proto je výhodnější podporu spolupráce na úrovni celé organizace podpořit adekvátními prostředky.
  • Typicky řídící dokumentace musí mít za firmu jedno jediné místo (a týmy dávají smysl pro dílčí rozvojové záměry).
    • Procesní model.
    • Rozvoj dovedností.
    • Systém kontroly.
    • ...
  • Jedno účetnictví, zákazníci a zakázky, jedny cestovní příkazy, dovolené, ...
  • Dílčí požadavky/záměry změn (rozumí se rozhraní rutinních činností) musí připomínkovat zejména ostatní organizační celky.
• Systém pro řízení využití kapacit / úkoly je specifická záležitost (musí pokrývat využití interních i externích zdrojů pro rutinní i projektové záměry), rozhodně musí být sdílený celou firmou, všemi dílčími rutinními i mimořádnými aktivitami.
• Pokud útvar považuje za účelné mít "svůj Team", určitě se dá využít pro izolaci interních aktivit (porady, průzkumy apod.), ale nic z dat/dokumentů/funkcí, které nejsou striktně "interní", tam být nesmí... čímž vzniká otázka, zda vůbec mohou existovat nějaké naprosto "lokální" prvky, které je smysluplné "chránit" před ostatními útvary (při sdílení - např. knihovny dokumentů - lze snadno a je výhodné využívat možnost filtrování záznamů dle metadat).

Tým na rozdíl od útvarů/procesů není hierarchický.

To neplatí dogmaticky/absolutně, je ovšem nutno jasně definovat, co "smí" být obsahem statického týmu. Lépe méně, při potřebě posoudit... zejména to, zda navrhovaná funkčnost či obsah není potřebný/užitečný pro ostatní. Tým je ze své podstaty pouze dočasný ("... group of people gathered to get something big done..."). 

• Procesy definují pouze role, činnosti a spouštěcí události (+ rozhraní atd.). Konkrétní lidé jsou v centrální správě zdrojů.
• Útvary jsou naopak primárně lidé, ovšem ve statických "pozicích" - dle tohoto organizačního principu nemůže být jeden člověk součástí více útvarů.

Asi je výhodnější si život zjednodušovat než komplikovat - takže Team-y nechme pro jednorázové aktivity a ty ostatní podporujme jinými technickými prostředky.

Příklad - poradenská spolupráce (projekt)

Konkrétní (nejjednodušší) příklad - spolupráce (v základní podobě) zákazníka a poradenské firmy na rozvojovém projektu u zákazníka - např. převodu péče o vztahy se zákazníky (z terénních obchodníků) na obchodní administrativu a související tvorbě (revizi) systému řízení výroby (případová studie jinde). Ptáme se, s jakými informacemi takový projekt pracuje a jak se pro jeho potřebu využijí komunikační prostředky. Při použití MS Teams:

• Nesporné potřeby / požadavky.
  • Administrátor (kde jsou k tomu lepší podmínky, měl by Team být u zákazníka, pokud by byl u dodavatele, pouze provizorně) vytvoří nový tým s vhodným jménem (Restrukturalizace 2020, interně kódový systemizovaný název, jelikož "název" týmu se objeví v odkazech/adresách). A udělá vše, co je pro fungování takového týmu nutné (detaily v metodice).
  • Na výstupu projektu má být:
    • Procesní model obchodu  a výroby (databáze a schémata).
    • Kalkulační vzorec (nástroj - aplikace & metodika).
    • Jednoznačná pravidla pro tvorbu nabídek včetně cenotvorby, řízení spolupráce se subdodavateli a zadávání výrobních zakázek (něco jako obchodní politika - fakticky součást / podklad pro procesní model).
  • V průběhu jsou používány tyto typy komunikace (jen základní):
    • Notifikace - kde je k dispozici/zpřístupněn nový či byl změněn obsah.
    • Obsah - dokumenty (výstupní & podklady), kalendář / plán práce, databáze/systém správy úkolů, metodika a směrnice (pravidla fungování tohoto konkrétního projektu) např. formou hypertextového systému založeného na wikiknihovně.
    • Data v provozních informačních systémech (zprostředkovaná pomocí transformace/výběru pokud je to možné nebo pseudorozhraním, na kterém je popsán způsob použití těch informačních systémů a případně způsob protokolování získaných informací).
• Příklad reakce na vznik neplánovaného obsahu: V průběhu akce došlo k tomu, že proběhl průzkum spokojenosti a potřeb stávajících zákazníků.
  • Tento dílčí záměr vznikl spontánně (nebyl v plánu prací). Nedůsledností (nadšením) realizačního týmu ani nebyl do plánu prací zařazen. Tedy k jeho provedení nevznikla žádná pravidla.
    Je to přijatelná situace?
    I kdyby to byla nezpochybnitelně jednorázová účelová záležitost?
    Pokud ne, existuje jiné rozumné řešení, než to napravit?
  • Metodika a dotazník (skript) vznikly ad hoc nekorektně v prostředí projektu/týmu. Následně se zde začaly také zpracovávat výsledky této aktivity (sice v samostatném kanálu, ale ani tak to není v pořádku). Sice je takový scénář pro pilotní aktivitu myslitelný, je ovšem nutné mít jasnou představu, co se s daty a nástroji bude dít dál. 
  • Primárně se musel doplnit plán+výkaz práce. Vytvořit (základ) závazná metodika pro provádění takového průzkumu. V jejím rámci upřesnit používání nástrojů a způsob uložení získaných dat pro běžnou provozní potřebu.
    Tohle rozhodně jednorázová záležitost nebyla - takový průzkum (byť dotyčná firma předtím nic takového nedělala) je standardní součástí obchodu. Proto bylo žádoucí celý mechanismus přenést do běžného provozu.
• Každý tým i kanál musí mít svého správce ("vlastníka"). Ten zodpovídá za to, že jeho využívání bude v souladu s pravidly a když se objeví cokoli, s čím pravidla nepočítají, tak si zajistí jejich aktualizaci, popř. nápravu - správné umístění toho, s čím se počítalo, ale bylo nedopatřením provedeno nesprávně.

Proč ne/používat Team pro "trvalou" aktivitu.

• Na první pohled se to může jevit jako rozumné. 
  Např. se uvažuje o využití Teams jako jednoduchého nástroje pro CRM. Může to být (možná by měl) tým strategického rozvoje. Nebo tým pro řízení kvality.
• Jakmile ale do úložiště týmu umístíte první dokument nebo jiný typ trvalé informace, bez ohledu na všechny předpoklady dřív nebo později zjistítíte, že k němu potřebuje mít přístup i někdo mimo danou skupinu, takže ho do toho týmu přidáte (protože většinou nestačí jen "sdílet"). Tím toho člověka zapojíte do všech aktivit.
• Pokud budete mít např. onen tým strategického rozvoje, tak klíčovým výstupem je podniková strategie. Ta je podkladem pro řadu jiných týmů, popř. procesů. Je potřeba definovat mechanismy, jak má být včetně odkazovaných zdrojů v přiměřeném rozsahu a ve správné verzi zpřístupněna všem, kdo ji mají využívat ve své práci.

Takže Team pro trvalé týmy mohou dávat smysl, ale veškerá data/dokumenty apod. musí být umístěny v úložištích, ke kterým lze zprostředkovat řízený přístup i jiným způsobem, než členstvím v týmu. Také je dobré respektovat, že Teams nenabízí jednoduchý způsob, jak k jednotlivým dokumentům (především složkám) nastavit specifická práva (pouze změny | čtení | čtení bez stažení). 

K čemu jsou Teams vhodné

Teams jsou postaveny na SharePoint-u & Exchange. Máme k dispozici plnohodnotnou infrastrukturu, se kterou není potřeba hledat provizoria a kompromisy. Základem rozumného využití je ovšem dobrá klasifikace informací a interakcí / aktivit, které mají být v systému podporovány. Musí být stanovena závazná pravidla používání. Vždy s ohledem na potřebu či nutnost uchování obsahu po dobu práce nebo i déle.

Pokud má obsah trvalou platnost, nesmí vznikat coby zpráva.

Když potřebujete zjistit, co platí (domluva, pravidla, parametry, postupy, termíny, ... cokoliv), nemáte to hledat ani v hromadě elektronické pošty, ani v ještě příšernější hromadě zpráv chatu/kanálu (v extrémním případě několika desítek různých kanálů desítek různých týmů). Nemáte vůbec hledat. To nedává smysl. Informace, které mají širší či delší (či nejasnou) platnost, musí být uchovávány odpovídající formou (procesní model, nastavení systémů, dokumenty, wiki apod. v podobě analýz, metodik apod.) na přesně určeném jednoznačném odpovídajícím místě. Zejména pokud k nim má být umožněn řízený přístup i odjinud.

Je rozumné:

• Zajistit, že skupiny, kanály, knihovny a všechny další typy obsahu vznikají velmi striktně řízeně a podle dohodnutých pravidel (uživatelé nesmí vytvářet skupiny - či spíše nic - dle vlastního uvážení - zajistit automatizovanou samoobsluhou, která si vyžádá potřebné údaje a potom vytvoří a nastaví vhodný typ týmu podle šablony).
• Zakázat přílohy - dokumenty patří do knihoven (ať už týmu nebo jinde). Tím se vyjasní, k čemu jsou určeny zprávy. Když se zpráva týká konkrétního dokumentu nebo jiného objektu či skupiny, je jednoduché do zprávy vložit odkaz na příslušný objekt (je smutné, že přílohy zpráv nelze nikde v nastaveních zablokovat).
• Zakázat kopírování dokumentů (za každou cenu bránit multiplicitám).
• Zakázat chat/zprávy mimo definovaných typů interakcí.
  Je nutno předem vymezit, co je přípustné pomocí chatu předávat - např. zda tam patří dotazy, podněty, povzdechy, názory, oznámení o změnách dokumentů nebo sdělení o závěrech nezaznamenaného jednání, zjišťování stanovisek k aktivitám teambuildingu apod. Musí být zcela jasně určeno, kdo (a jak) je povinen na jaký typ sdělení reagovat. 
• Dokumenty nesmí existovat jinde, než v závazných úložištích. Musí mít povinná metadata.
• Úkoly (dané aktivity, pro kterou byl tým sestaven) se zadávají, sledují a hodnotí prostřednictvím určeného dílčího nástroje (Planner, Project Online apod.). Pokud má tým primárně sloužit podpoře spolupráce, tak je plánování práce, jeji sjednávání, kontrola průběhu a přebírání výsledků & hodnocení zcela zásadní funčností (viz později).
  Použitý prostředek by měl být schopen využívat centrální zásobník zdrojů (kapacit), aby bylo možno automatizovaně podporovat vyvažování (hodnocení zatížení zdrojů, hledání zdrojů s potřebnou způsobilostí a co nejnižší cenou...).
• Požadavky jsou spravovány odpovídajícím způsobem (knihovna záležitostí, popř. specializovaná aplikace). Opět záleží na tom, jestli a jak je potřeba & jednoduché či složité uchovat tato data i po skončení práce (zániku týmu).
• Předávací / akceptační protokoly jsou ve vhodném prostředí (knihovna dokumentace - výstupy). Sice mají mít genezi v prostředí týmu / projektu, ale je nutno počítat s tím, že obvykle bude potřeba výsledné dokumenty uchovat i po ukončení akce (zániku týmu), většinou včetně jejich geneze (později samostatně).
• Do mailů či chatu/zpráv patří ty informace, které mají pouze dočasnou platnost (představte si to tak, že jakmile danou zprávu akceptuje poslední příjemce, zanikne, protože se k ní již nikdo nikdy nemá vracet, popř. zanikne při svojí exspiraci bez ohledu na to, kdo všechno ji četl, jelikož už neplatí). K tomu je samozřejmě potřeba říci, jak mají být předávány všechny ostatní informace.
  • Odkaz na schůzku je jasný - ukončením schůzky ztrácí platnost a měl by z historie zpráv zmizet. Pokud to nejde automaticky, měla by to být povinnost organizátora schůzky.
  • Program či podklady schůzky musí být u dané schůzky (formou odkazů). Upozornění na změnu obsahu podkladů patří mezi zprávy a mělo by být navázáno na oznámení schůzky - tohle může být inspirace pro to, jak smysluplně využívat kanály (všimněte si, že schůzky jsou implicitně vztahovány ke kanálu; je tím myšleno samostatný kanál pro každou schůzku / téma).
• Kanál by měl být využíván pro výměnu zpráv týkajících se jednoho tématu. Např. vznikne nejasnost nebo problém. Pro diskusi nad danou otázkou je vhodné založit kanál, který se po ukončení diskuse odstraní. Výsledky diskuse je nutno zaznamenat tam, kam patří.
• Připomínkování
  Může se stát, že v rámci výměny zpráv (v kanálu = otázky a odpovědi) se účastníci na něčem domluví - např. na tom, že se něco má dělat konkrétním způsobem (např. jak má vypadat nabídka, na co je potřeba dávat pozor, popř. jakým způsobem se mají předávat konkrétní informace či cokoli podobného).
  • Takovou dohodu (její obsah/výsledek) je potřeba zapracovat jako aktualizaci do příslušné metodiky či dokumentu, úpravy si nechat schválit a původní zprávy nejlépe z původního kanálu odstranit (což znamená do oné aktualizace zahrnout vše, co je z diskuse v kanálu podstatné a není jisté, že to lze smazat - proto by připomínkování mělo probíhat spíše přímo nad cílovým dokumentem formou komentářových podnětů a vysvětlivek autora; pro témata, ke kterým neexistuje dokument, je cesta prostřednictvím zpracování podnětu).
  • Aktualizace sama může být kanál a případný text původního podnětu a navazující výměny názorů, pokud je to účelné, může být zkopírován (nikoli odkázán, protože tam tu informaci chceme uložit trvale) do zadání úkolu nebo přímo do akualizovaného dokumentu.
  • Veškerá následná komunikace má být vedena a zpracována závazným způsobem (dle pravidel pro připomínkování obsahu).
• Využíváte třeba průzkumy (ty samy existují nezávisle, a máte chuť sdílet analýzu výsledků nebo koordinovat součinnost na přípravě - zase se hodí kanál, který s definitivním uzavřením práce na anketě také zanikne - všechny věcné informace které ať už z tvorby nebo rozboru vznkají, patří do průvodní dokumentace průzkumu - mimo jiné proto, že daný záznam máme vybavit více atributy (kategoriemi, značkami, vazbami na jiné aktivity/průzkumy atd.), přes které dává smysl je zpřístupňovat. A umístit jej tam, kam patří - možná neplatí jinde, než v rámci projektu (týmu), ale většinou má širší vazby, proto má skončit v některé celopodnikové knihovně dokumentů. V týmu/kanálu umístíme odkaz.

Stačí vědět, jak se připojují do týmu/kanálu další nástroje. Popř. vytvářejí odkazy.

Kdy je užití týmů a kanálů sporné

Jednoduchý scénář - IT outsourcer by chtěl používat Teams pro komunikaci při poskytování podpory klientům. Vypadá to elegantně a jednoduše. Jenže co je podstatou poskytování podpory (bez ohledu na to, jak tomu říkáme)?

• Plánování péče/rozvoje (běžná profylaxe, analýza provozu, školení, ...). Některé tyto aktivity se týkají uživatelů u klienta, některé ne. Na ty společné je potřeba zorganizovat termín. Většinou je nutný alespoň jednoduchý záznam výsledků.
• Možná je dobré vyčlenit samostatně "metodickou podporu".
  Tady by se dalo o využití Teams uvažovat. Často se objeví dotaz nebo se zjistí nekorektní způsob používání IT, popř. dojde ke změně nastavení a tedy i postupu, jak lidé mají např. aktualizovat dokument.
  • O tématu lze diskutovat (viz výše připomínkování)
  • Závazná verze toho, jak se to má dělat či co je potřeba dodržovat, musí být nesporná. Tedy velmi přesně formulována v metodice, aby mohla být provázána na ostatní pravidla. 
  • Po diskusi následuje závazná formulace, publikace a notifikace dotčených uživatelů. Ale zjevně je lepší integrovat do Teams komunikační rozhraní standardního nástroje (viz dále, popř. ALVAO), mimo jiné proto, že ne všichni klienti budou ochotni používat Teams. 
• Obvykle je nosná funkčnost nástroje pro zefektivnění poskytování podpory (nejen v IT) něco jako helpdesk/servicedesk - správa incidentů. Pokud je uzavřena SLA, existují definované typy incidentů a reakční doby. O zásazích je nutné vést poměrně přesnou evidenci. I ty ostatní činnosti je potřeba vykazovat - což by měl zajišťovat jediný systém.
• Bylo by velmi nešťastné používat Teams pro dotazy v rámci podpory či požadavky.

Optimální řešení závisí na konkrétních podmínkách. Lze odhadnout, že pro poskytování podpory Teams kryjí 20-40% potřebné funkčnosti. Zbývající potřeby by se řešily obtížně a neefektivně. Navíc typicky funkčnost nástroje pro podporu by měla zajistit, že se incidentu bude věnovat co nejdřív první volný technik (což komplikuje koncepci tým pro jednotlivého klienta). Pro poskytování podpory je vhodný nástroj typu extranet, který lze velmi efektivně vytvořit (včetně případné jednoduché funkčnosti na základě šablony helpdesku) např. pomocí SharePoint-u a komunikační možnosti Teams hladce integrovat.

Ono je celkem sporné, jestli všichni uživatelé u klienta mají být členy případného týmu nebo se jejich identifikace má zajistit jinak. Samozřejmě jiná situace je, pokud se "tým" podpory vytvoří v prostředí klienta a za poskytovatele je správcem správně nakonfigurovaný "virtuální technik" nebo aplikace servicedesku.

Co potřebujete uchovat

Předpokládejme, že jste se rozhodli využít Teams pro spolupráci při realizaci velkého obchodního případu - ať už pouze interně nebo se zapojením externích partnerů z obou stran - zákazníka & subdodavatelů. Dohodnete se, že veškerá dokumentace (informace) budou uchovávány = sdíleny pomocí Teams (viz Teams pro zakázky).

• Začínáme plánem práce. Kde má být a jak má vypadat?
  Případně pokud mají být vytvářeny - co výkazy práce? Hotové činnosti z plánu práce by měly být v něm. Takže žádný (nezávislý) výkaz  práce nepotřebujete (získáte jej výpisem ukončených činností včetně původního odhadu a dalších údajů... samozřejmě potřebujeme nástroj, který to bude evidovat). Je to jediný správný způsob, protože plán práce je nezbytné udržovat platný. To lze pouze tak, že veškeré provedené činnosti do něj zaznamenáváte (tak, jak skutečně proběhly) a návazně aktualizujete plán dosud neukončených aktivit. 
  • Pro tento účel lze zřídit kanál "Plán práce" nebo pokud je to extrémně rozsáhlý projekt, lze jej členit na etapy a potom je potřeba mít nástroj, který umožňuje plánování a vykazování práce etap v rámci nadřazeného plánu.
  • Funguje tak dlouho, dokud není práce (projekt, etapa) skončena. Kanál obsahuje pouze upozornění na změny plánu prací - ideálně s odkazem na danou položku. Není přípustné, aby se v něm vyskytovala sdělení s delší platností - veškeré takové informace musí existovat nezávisle na něm.
  • Vlastní plán práce je Planner, Work progress tracker nebo odpovídající typ obsahu SharePoint-u. Popř. Project for Web/Teams.
    
• Veškeré informace vztahující se k organizaci práce (které nejsou plánem práce = metodika & postupy, analýzy, akceptační kritéria apod.). patří do metodiky řízení/organizace akce. Bezpochyby bude existovat základní verze. Můžeme se na ni odkázat (pokud je fixně platná a neměnná) nebo ji převzít a následně upravovat. Má být umístěna v snadno odkazovatelné a propojitelné hierarchické struktuře - obvykle vyhovuje wikiknihovna (nativní součást Teams). Ve zprávách se objeví jen velmi dočasně platná upozornění na provedené aktualizace apod.
• Vždy budou existovat "podklady" - halda odkazů, obrázků, výstřižků apod. včetně dokumentů, které nejsou "formální/oficiální" součástí dokumentace akce. Sporné je, kam patří. 

Zkrátka všechno, co potřebujete uchovat, musí existovat v podobě dokumentů nebo datových záznamů ("tabulek"). Nedává smysl stavět jakoukoli spolupráci/dohodu na útržcích informací, roztroušených v mailech nebo zprávách skupiny (kanálu). 

Správné řešení

Sice je teoretická možnost vytvořit konektor, který by s příspěvky kanálu něco dělal, ale příliš to nedává smysl. Jaké je korektní řešení?

• Zvážit, jestli je „komunikace“ přes kanály či chat týmů žádoucí scénář. Pokud ano, tak v jaké podobě (s jakými pravidly). Tedy každý příspěvek by měl být předem definovaného typu a žádné jiné by nebyly povolené. Což je v obvyklé situaci nereálné.
• Pokud to tak má být, je potřeba domyslet, jak určené (?) typy zpráv uložit do určeného úložiště (popř. získat nástroj, který to bude podporovat). Velmi drahé, nejisté, nepodporované (např. je prakticky nemožné zavést klasifikaci zpráv).
• Rozhodně nemá smyslu ukládat všechno. Nedává smysl to dělat, zejména proto, že nechceme, aby v haldě balastu někdy někdo něco hledal. Inormace, které mají být uchovány (aneb jsou klasifikovány), by měly být "na svém místě". Dostupné bez hledání.
• Ovšem jak definovat, co se má ukládat?
• Co přesně vede k tomu, že v příspěvcích kanálu máme něco, co bychom chtěli uchovat?
• Co z toho je vlastně potřeba mít "uložené", proč a na jak dlouho?
• Bude obtížné zdůvodnit, proč mají být v příspěvcích kanálů/skupiny informace, které je potřeba uchovat (z jakých důvodů), jinak bychom vynakládali úsilí na podporu nekorektního řešení (což by téměř jistě nemohlo dopadnout dobře).
• Používejme kanály k tomu, k čemu jsou určeny (viz výše "conversation").
• Jenom pro výzvy, oznámení, upozornění - prostě pro obsah, který nemá trvalou platnost. V ideálním případě by měly mít určenou platnost a poté by měly zmizet. Nechceme po nikom, aby procházel zprávy v nepřehledné souslednosti, kdy větší část je irelevantní.
• Obsah (objekty s informacemi, které mají delší než bezprostřední platnost) ukládat tam, kam patří (dokumenty, databáze, schémata, wiki atd.). To samozřejmě vyžaduje promyslet a korektně nastavit pravidla. Klasifikovat typy "sdělení" a určit jim odpovídající prostředky.
• Pokud víme, že zprávy z chatu nelze (ani to nedává smysl) nijak extrahovat a uložit, tak do chatu prostě nic takového, co by bylo potřeba uložit, nesmíme dávat. Uložit obsah tam, kam patří a do kanálu uvést odkaz. Jak to dělají Teams např. u systémových změn.
• Co udělat s těmi stávajícími? Využít pro zmapování typů obsahu a specifikaci skutečných potřeb.
• Ručně je projít a při té příležitosti upřesňovat zásady organizace dat.
• Převést informace s delší platností do žádoucí podoby a úložiště.
• Přitom formulovat pravidla a ověřovat postupy.
• Odstranit vše, co tam dle nových pravidel být nemá. Tedy obvykle vše.

Aneb rozumný postup je přiznat si, že by se to mělo dělat jinak, než dosud. Současně s novými technologiem přejít na nové postupy / organizaci práce. Rozumné typy obsahu (dokumenty, wiki atd.) lze zálohovat, synchronizovat a používat naprosto běžným způsobem (otevřít týmový web přes SharePoint a najít např. přes Site Contents to, co nás zajímá).

Čím dříve, tím lépe.

Přečtěte si pokračování Jak a k čemu používat MS Teams, Projekty s MS Teams. Pokud jste v podobné situaci, rádi poskytneme konzultaci a analýzu zdarma. Už dlouho nabízíme online poradnu a vývoj nadstaveb pro MS365.

Zásadní doporučení pro nasazení MS Teams

Naprosto fatální - pokud nechcete "splakat nad výdělkem" (aneb myslíte to "vážně" - očekáváte od uplatnění této technologie zřetelný přínos).

• Definujte procesy (spouštěcí události, role a jejich povinnosti) pro činnosti, které mají Teams popořit. Na jejich základě se dá vytvořit workflow, které umožní identifikované instance evidovat a řídit.
• Znemožněte vytvářet (default nastavení) týmy každému (viz Manage who can create Microsoft 365 Groups; viz dále), koho to napadne.
• Pokud nemáte (špičkově) kvalifikovaného správce pro M365 (nedává smysl bavit se výhradně o Teams, ten člověk musí mít dostatečný přehled), což je dost pravděpodobné, protože jich je dost málo a běžné organizaci se nemůže vyplatit mít vlastního, tak správu M365 outsourcujte - ale je opravdu podstatné, koho si k tomu vyberete.
• Pokud nemáte přehled o tom, kdo, co, jak a k čemu v organizaci používá (data, technologie, systémy, nástroje, ...), prvním krokem musí být hloubková analýza využití IT.

Obsah článku je jenom předběžný - budeme se k němu vracet. Zejména pokud se ozve někdo, koho toto téma zajímá.