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.

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

Zkuste zapomenout na to, že skupina lidí, která má v rámci funkčního uspořádání stejného "vedoucího", může fungovat jako tým vhodný pro organizaci a kooordinaci spolupráce. Tedy akce, která má začátek a konec + podílí se na ní i lidé mimo ten útvar. Ale i kdyby vždy byli jen interní - k čemu je prostor, kde je "všechno o všem"? Je zřejmé, že např. na obchodním případu / zakázce budou pracovat lidé napříč firmou. Nemluvě o tom, že v rozumných scénářích zde bude řada externích subjektů, které je nutné zahrnout do té "komunikace".

Klíčová otázka je, co se myslí tím pojmem "komunikace". Někteří jedinci se tímto způsobem snaží řešit "maily". Což obvykle znamená, že neumí nebo se jim nechce korektně reagovat na "podnět" (zprávu). Jenže v takovém případě je lhostejné, v jaké formě zpráva dorazí. Pokud nahradíme mail chatem, může to být jenom horší.

Je fakt, že jak konkrétní případ, tak podstata je poněkud obtížně vysvětlitelná. Proto je tento článek tak dlouhý a nepříliš srozumitelný. Něco s tím uděláme... 

Týmy & Teams × organizační struktura

Výše uvedený scénář je sporný. Ve stručnosti jak a proč by účelné nasazení Teams mohlo vypadat:

• Týmy v Teams nejsou (primárně) určeny pro podporu aktivit organizovaných uvnitř stálých útvarů statické organizační struktury. Pravděpodobně i jejich využití pro procesní oblasti je poměrně sporné (není jednoduché nastavit pravidla tak, aby to uspokojivě fungovalo a hlavně existují mnohem vhodnější nástroje, viz dále).
  • Bohužel v návodu na používání není dost 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 fakticky nepoužitelné (můžete vytvořit "útvarové týmy", ty využívejte pouze pro organizaci týmových volnočasových či obdobných aktivit celého útvaru).
  • Tým je obvykle účelová dočasná organizační jednotka.
  • Ve výše uvedené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.
    • 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 chce pokrýt všechny možnosti užití). Pro účelné použití "kanálů" je dobré jim dát jednotný význam - 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.
  • 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í.
• Pro aktivitu vzniká tým. Tým existuje jen po dobu jejího trvání. Může se v průběhu měnit (členy přidávat či nahrazovat). Po skončení akce tým zanikne.
  Když to takto od začátku vnímáte, je jasné, kam patří jaké informace.
• 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ým akcím, 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 toho 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. 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ě 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 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 zakázkové dokumentace.
• Jenže chat (kanály) jsou určeny (má smysl používat) pouze pro určené typy interakcí. Zjednodušeně řečeno "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) diskusi - k tématu, které je obsaženo v některém odkázaném dokumentu (či něčem podobném). Do dokumentu potom přenést jen závěry (dle zvyklostí včetně zdůvodnění, takže to nejspíš není dobrý nápad).
• Když vás napadne něco jiného, k čemu by oznámení v rámci kanálů mohly být účelně použity, napište, 

Nastavit pravidla komunikace tak, aby se kanál (popř. tým) dal víceméně bezprostředně (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) po skončení příslušné dílčí aktivity (tým po skončení akce) odstranit. 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 si dokonce předávají v chatu přílohy…
Zkrátka proto, že jsou tak zvyklí. Protože to jde.

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).

• Vstupy
  Podklady, které mají být využity (texty, data, obrázky aj.). To by mělo být samostatné úložiště, které patří k danému projektu/týmu. Může to být vyhrazená knihovna dokumentů, kterou lze nasdílet i externím uživatelům pro vkládání dat.
• 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. Tedy to nemůže být interní knihovna týmu. To lze řešit tak, že si příslušné úložiště (obvykle knihovnu SharePoint-u) připojíte do nástrojů týmu/kanálu. 
• Data
  Může se stát, že součástí práce týmu jsou data, ke kterým potřebujete zajistit přístup např. na souborové úrovni (např. výsledky dotazníků, které chcete zpracovávat nezávislou aplikací). 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 (rozumí se mimo tým; popř. složku v již připojené) a přidáte jako další nástroj.
• Změny požadavků či parametrů
  Dají se (a bylo by to vhodnější) vypořádat přímo ve správě podnětů/požadavků (specializovaný nástroj). Ale může existovat důvod, proč jsou např. v dokumentu textového či tabulkového procesoru (požadavek zákazníka). Proto může být stanoveno, že se pro každý takový podnět vytvoří samostatný kanál. Určený právě a jen pro vypořádání této dílčí záležitosti. Změna může být iniciována zprávou (chat, mail či telefon - relevantní obsah 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.).
  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.

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 komunikačním nástrojem podporováno. Proč jej vlastně potřebujeme.

• 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 výměny informací. Která je pro součinnost lidí a koordinaci jejich úsilí nutná.
• V podnikové praxi podpora týmové spolupráce. Částečně "výměna", ale mnohem více "sdílení" informací. K tomu jsou MS Teams určeny.
• Žádný nástroj nemůže podporovat všechny myslitelné typy používání. 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 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.

Příklad - poradenská spolupráce

Konkrétní (nejjednodušší) příklad - spolupráce (v primitivní 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. 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 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 ). 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č nepouží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. Tím jej zapojíte do všech aktivit.

Takže tým 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 nastavit specifická práva.

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 je něco potřeba uchovávat, nesmí to zůstat jako obsah chatu.

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ů různých týmů). 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 odpovídajícím místě. Zejména pokud k nim má být umožněn 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 celkem 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 to nikde v nastaveních nelze technicky zablokovat).
• Zakázat kopírování.
• Zakázat chat mimo definovaných typů interakcí (aneb je nutno předem vymezit, co - je přípustné pomocí chatu sdělovat - 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 interakce reagovat. Jinak 
• Dokumenty nesmí existovat jinde, než v závazných úložištích.
• Úkoly 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). 
• Požadavky jsou spravovány odpovídajícím způsobem (knihovna záležitostí). Opět záleží na tom, jestli a jak je potřeba & jednoduché či složité je 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ů a chatu 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). 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 týmů žádoucí scénář. Pokud ano, tak v jaké podobě (s jakými pravidly).
• 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).
• Protože 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), 
• Jenže 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.
• Obsah (objekty s informacemi, které mají delší než bezprostřední platnost) ukládat tam, kam patří (dokumenty, poznámky atd.). To samozřejmě vyžaduje promyslet a korektně nastavit pravidla. Klasifikovat typy záznamů 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.

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. 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 zdarma. Už dlouho nabízíme online poradnu a vývoj nadstaveb pro MS365.

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á.