Co je „tiger team“? Definice, původ a kdy jej využít

„Houstone, máme problém.“

Každý z nás ho už alespoň jednou použil. Stal se zkratkou pro ten moment, kdy se něco důležitého pokazí a je třeba to rychle opravit.

V praxi to obvykle znamená problém, který se týká několika týmů. Například ta jedna chyba, která přežila několik kol oprav, poškodila tři zákaznické databáze a zvyšuje počet žádostí o podporu. Začalo to v technickém oddělení, ale nyní se na tom podílejí i oddělení podpory, produktového vývoje a zákaznické spokojenosti.

To, co právě teď potřebujete, je „tiger team“: malá, dočasná skupina specialistů, která se spojila za účelem vyřešení jednoho jasně definovaného problému s vysokými sázkami. Myšlenka vznikla v 60. letech v leteckém a kosmickém průmyslu a od té doby se rozšířila do strojírenství, státní správy, bezpečnosti i každodenního provozu.

Postupem času se však tento pojem rozšířil natolik, že se jím označuje téměř jakékoli naléhavé setkání několika vedoucích pracovníků. Podrobně si vysvětlíme, co „tiger team“ vlastně je, odkud tento termín pochází a v čem se liší od „task forces“ a „war rooms“, s nimiž je často zaměňován.

Co je to „tiger team“?

„Tiger team“ je krátkodobá skupina s jediným úkolem: vyřešit jeden problém, který stávající struktura nedokáže vyřešit v požadované rychlosti.

Struktura je důležitější než název. „Tiger team“ potřebuje jasně definovaný cíl, odborné znalosti k jeho vyšetření a dostatečné pravomoci k jednání, aniž by se stal dalším stálým výborem.

„Tiger týmy“ mají obvykle několik společných charakteristik:

Tuto strukturu můžete vidět u „tiger týmů“ v rámci pojištění v nezaměstnanosti amerického Ministerstva práce. Od roku 2021 ministerstvo sdružilo odborníky na prevenci podvodů, zákaznickou zkušenost, pojištění v nezaměstnanosti, data a systémové inženýrství, aby posoudili problémy v jednotlivých státních programech a doporučili krátkodobá zlepšení. Během prvních 24 měsíců tyto týmy spolupracovaly s 36 státy.

Ne každý „tiger team“ však bude vypadat stejně. Někteří členové mohou částečně pokračovat ve své běžné práci, zatímco jiní se od ní mohou zcela odklonit.

Odkud pochází termín „tiger team“?

Tento termín má svůj původ v americkém leteckém a kosmickém průmyslu v 60. letech 20. století, dlouho předtím, než se stal běžnou součástí slovníku pro řešení obchodních problémů.

Jedno z prvních zdokumentovaných použití tohoto pojmu se objevuje v článku SAE z roku 1964 s názvem „Program Management in Design and Development“ (Řízení programů v oblasti návr hu a vývoje ) od autorů J. R. Dempseyho, W. A. Davise, A. S. Crossfielda a Waltera C. Williamse. V něm byl „tiger team“ popsán jako skupina „nezkrocených a neomezených technických specialistů“ vybraných na základě svých zkušeností, energie a představivosti. Jejich úkolem bylo neúnavně hledat možné zdroje selhání v systémech kosmických lodí a simulacích.

A nejednalo se pouze o skupinu zkušených odborníků, kteří se sešli v jedné místnosti. Očekávalo se od nich, že budou zpochybňovat zažité předpoklady, odhalovat slabiny, které jiným unikly, a pracovat mimo rámec obvyklých omezení daného programu.

O šest let později se tento termín spojil s jednou ze svých nejslavnějších událostí díky misi Apollo 13. 13. dubna 1970 explodovala kyslíková nádrž, když se kosmická loď nacházela přibližně 200 000 mil od Země. Jack Swigert vyslal rádiovou zprávu do řídícího střediska: „Houston, máme tu problém,“ což se později v populární kultuře zkrátilo na „Houston, máme problém.“

Letový ředitel NASA Gene Kranz poté vedl tým, který záznamy NASA popisují jako „tým Tiger“ mise Apollo 13 , a spolupracoval s širším operačním týmem mise na řešení problémů , které stály mezi astronauty a jejich bezpečným návratem. Operační tým mise Apollo 13 později obdržel Prezidentskou medaili svobody za svou roli při záchranné akci.

Mise Apollo 13 pomohla upevnit postavení „tiger teamu“ jako modelu pro soustředěné řešení problémů pod tlakem, ale tento termín nevymyslela.

„Tiger Team“ vs. „Task Force“, „War Room“, „Red Team“ a „Skunkworks“

„Tiger týmy“ jsou často zaměňovány s jinými skupinovými strukturami, jako jsou pracovní skupiny, krizové štáby, „red týmy“ a „skunkworks“. Ve všech případech se může jednat o malé skupiny pracující mimo obvyklou týmovou strukturu, ale jsou sestavovány z různých důvodů.

Nejčastěji se zaměňuje „tiger team“ s „task force“, protože oba mohou sdružovat lidi z různých funkcí. Rozdíl spočívá v mandátu. Task force může vyšetřovat širokou problematiku, koordinovat iniciativu nebo doporučovat změny. Tiger teamu je obvykle svěřován úžeji vymezený problém a větší volnost k jeho rychlému vyřešení.

„War room“ (krizové centrum) vychází z jiné situace. Je postaveno na incidentu, který se již odehrává, a poskytuje lidem, kteří na něj reagují, společný prostor a rytmus pro rozhodování. Z „war roomu“ může vzniknout „tiger team“, pokud bezprostřední incident odhalí hlubší problém, který vyžaduje soustředěnou práci, jakmile se situace stabilizuje.

„Red týmy“ jsou záměrně více zaměřeny na simulaci útoku protivníka. Například v oblasti kyberbezpečnosti definuje NIST „red tým“ jako skupinu zorganizovanou za účelem simulace útoku protivníka nebo jeho schopností zneužít zranitelnosti. Cílem je odhalit slabá místa tím, že se systém vystaví náročným testům. „Tiger tým“ může tento přístup částečně využívat, ale jeho širší odpovědností je vyřešit konkrétní problém, kvůli kterému byl sestaven.

Skunkworks jde jiným směrem. Tento model, proslavený díky Skunk Works společnosti Lockheed Martin, poskytuje malé skupině neobvyklou autonomii při vývoji něčeho nového. Týmy typu „tiger team“ se obvykle sestavují za účelem řešení konkrétního problému s jasně definovanou podmínkou ukončení. Týmy typu „skunkworks“ mohou zůstat pohromadě mnohem déle, zatímco se daný nápad prozkoumává, navrhuje a testuje.

Tyto rozdíly jsou důležité, protože pouhé pojmenování skupiny tak, aby to znělo naléhavěji, nic nemění na tom, jak funguje. Než sestavíte „tiger team“, je lepší si nejprve položit otázku, zda daný problém vůbec vyžaduje právě takovouto strukturu.

Kdy byste měli sestavit „tiger team“?

Vytvoření „tiger teamu“ má smysl, pokud se jedná o problém, který zasahuje do více funkčních oblastí, vyžaduje zapojení specialistů nebo uvízl v běžném procesu. Zapojení specialistů do dočasného týmu je však zároveň odvádí od práce, za kterou již nesou odpovědnost.

Dobrý případ obvykle splňuje čtyři kritéria:

Stejný model lze využít i preventivně, ještě předtím, než se vysoce riziková změna dostane do produkčního prostředí nebo do ostrého provozu.

Jaké jsou klíčové role v týmu „Tiger“?

„Tiger team“ nemusí mít velký počet členů, ale každý by měl vědět, za co je zodpovědný. Ve většině případů budete potřebovat několik klíčových rolí:

V malém týmu může jedna osoba zastávat více rolí. Klíčové je, aby pravomoci, každodenní odpovědnost, odborné znalosti a dokumentace měly jasně určené místo.

Jak vést „tiger team“ v 7 krocích

Jakmile je tým sestaven, je třeba práci dostatečně strukturovat, aby se vyšetřování nezměnilo v nekonečnou řadu schůzek, teorií a nesouvislých oprav. Následující kroky provedou tým od první pracovní schůzky až po ověření a předání.

1. Převést cíl do pracovního zadání

Každý „tiger team“ potřebuje podmínku ukončení činnosti: konkrétní výsledek, který všem signalizuje, že problém je vyřešen a tým se může rozpustit. Nejprve se na ní dohodněte a poté z ní vytvořte vodítko, podle kterého se budou lidé řídit při každodenním rozhodování.

K tomu obvykle postačí krátký pracovní brief. Ten by měl odpovědět na následující otázky:

Zvláštní pozornost věnujte poslední otázce. Představte si provozní tým, který se potýká s narůstajícím počtem nevyřízených případů. Snížení počtu případů v pořadí pod 500 se může jevit jako úspěch jednoho odpoledne. Udržení tohoto stavu po celý týden, přičemž denní zpracování stále převyšuje objem přicházející práce, je však mnohem silnějším důkazem toho, že náprava bude trvalá.

2. Stanovte role, rozhodovací pravomoci a hranice

Začněte tím, že určíte vedoucího, sponzora, specialisty a osobu, která bude průběžně aktualizovat pracovní záznamy. Poté včas vyřešte otázku rozhodovacích pravomocí. Tým může některá rozhodnutí činit samostatně, u některých je třeba souhlas sponzora a některá stále spadají do kompetence týmů, které je obvykle mají na starosti.

Tým také potřebuje jasně vymezené hranice své práce. Než vyšetřování nabere na obrátkách, sepište si:

Právě ten poslední bod zabraňuje mnoha odchylkám. Vyšetřování v oblasti plateb může například odhalit problémy s cenami, nastavením účtů nebo přijímáním nových zákazníků. Některé z nich možná stojí za to vyřešit později, ale pokud je všechny zahrnete do aktuálního úkolu, z dvoutýdenní práce se stane dvouměsíční.

Stejnou pozornost je třeba věnovat i kapacitám. Přerozdělte naléhavé úkoly, posuňte termíny tam, kde je to možné, a informujte dotčené odpovědné osoby o změnách. V opačném případě budou členové týmu muset vést „tiger team“ navíc ke všem úkolům, které již měli na starosti.

3. Oddělte důkazy od teorií a poté rozhodněte, co budete testovat

V okamžiku, kdy se „tiger team“ sestaví, může mít již několik lidí své vysvětlení toho, co se pokazilo. Začněte tím, že oddělíte to, co tým ví, od toho, co pouze předpokládá.

V rámci tohoto cvičení si projděte předchozí opravy, experimenty, poznámky k incidentům a rozhodnutí. Cesta, která dnes vypadá slibně, mohla být již před šesti měsíci otestována. Na základě toho sestavte z nejpřesvědčivějších vysvětlení krátký seznam hypotéz. U každé z nich zaznamenejte, co si myslíte, že se děje, jaké důkazy to podporují, jak to otestujete a co vám výsledek řekne.

Seřaďte úkoly podle toho, co se z nich můžete naučit. Teorie, která by mohla vysvětlit většinu problému a jejíž otestování zabere hodinu, si zaslouží pozornost před tou, která vyžaduje týden inženýrské práce.

4. Vedejte záznamy o rozhodnutích, která by mohla ovlivnit průběh vyšetřování

Ukládejte si záznamy o hovorech, které by mohly ovlivnit další postup týmu nebo které by někdo mohl později potřebovat pochopit. Může se jednat například o přijaté riziko, zamítnutý technický postup, změnu rozsahu projektu nebo rozhodnutí přestat se zabývat určitou hypotézou.

Projděte si záznamy vždy, když nové důkazy zpochybní dřívější předpoklad, a mějte aktuální rozhodnutí viditelné vedle důkazů, na nichž je založeno.

5. Nechte problém určovat pracovní rytmus

Četnost schůzek „tiger teamu“ závisí na tom, jak rychle se problém mění. Během aktuálního výpadku se tým může scházet každých několik hodin. Dvoutýdenní vyšetřování pomalu se vyvíjejícího problému s daty lze obvykle zvládnout několika schůzkami týdně.

Ať už je tempo jakékoli, každá schůzka by měla mít jasný účel. Může jít o nové důkazy, které mění celkový obraz situace, překážku, kterou může odstranit pouze sponzor, nebo rozhodnutí, které musí tým učinit společně. Každodenní pokrok je lepší zaznamenávat do písemného protokolu, kde si jej lidé mohou prohlédnout, kdykoli mají chvilku času.

Pokud práce trvá déle než pár týdnů, naplánujte si průběžné hodnocení. Týmu to dá příležitost odstup od každodenního vyšetřování a položit si otázku:

Upřímné odpovědi v této fázi mohou týmu zabránit v tom, aby strávil druhou polovinu práce řešením nesprávného problému.

Zainteresované strany obvykle nemusí být do tohoto procesu přímo zapojeny. Krátká písemná zpráva každých několik dní, která shrnuje, co se tým dozvěděl, jaká rozhodnutí přijal a kde narazil na překážky, jim umožňuje zůstat dostatečně v obraze, aby mohli zasáhnout, když to bude potřeba.

6. Dejte opravě čas, aby se osvědčila

Oprava může vypadat přesvědčivě v den jejího nasazení, ale přesto selhat, jakmile se obnoví běžný provoz, objem dat nebo okrajové případy. Proto by tým neměl prohlásit problém za vyřešený v okamžiku, kdy se čísla zlepší.

Jak dlouho je třeba sledovat opravu, závisí na tom, jak často se problém může znovu objevit. Například u služby s vysokým objemem provozu můžete získat spolehlivý signál již během několika hodin. U měsíčního finančního uzávěrku může být zapotřebí dalšího celého cyklu, než bude možné s jistotou říci, že oprava vydržela.

Zatímco čekáte, mějte na paměti dvě čísla:

Pokud se čísla začnou vracet k původním hodnotám, považujte to za nový důkaz. Zahrňte jej do vyšetřování a sledujte, co se tím změní. Může to posunout jinou hypotézu na první místo v pořadí nebo odhalit, že původní diagnóza vysvětlovala pouze část toho, co se dělo.

7. Předávejte práci v pořádku

V této fázi má tým již připraveno téměř vše, co je k předání případu zapotřebí. Pracovní zadání, důkazy, testy, protokol o rozhodnutích a ověřovací data jsou již součástí spisu. Jejich přepisování do uhlazené závěrečné zprávy znamená jen další práci a nic víc.

Místo toho shromážděte všechny tyto záznamy a zajistěte, aby bylo zřejmé, komu případ patří. Trvalý vlastník by měl odcházet s vědomím, že:

Než někdo odejde, odpovězte na otázku: Kdo dostane hlášení, pokud se problém znovu objeví?

Jakmile je dosaženo výsledku a odpověď je vyřešena, může se „tiger team“ rozpustit. Členové se vrátí ke své běžné práci, průběžné povinnosti se přesunou zpět do běžné struktury a vyšetřování zůstane zaznamenáno pro kohokoli, kdo ho bude v budoucnu potřebovat.

Reaktivní vs. preventivní „tiger týmy“

„Tiger týmy“ se obvykle zapojují v jedné ze dvou fází. Některé se sestavují až ve chvíli, kdy problém již negativně ovlivňuje chod firmy. Jiné se zapojují dříve, dokud je ještě čas odhalit slabá místa a změnit plán.

Rozdíl spočívá v tom, co se tým snaží zjistit.

Reaktivní „tiger týmy“ začínají s problémem, který již probíhá

Toto je typ situace, kterou si většina lidí spojuje s „tiger týmy“. Může jít o zpoždění uvedení produktu na trh, opakující se výpadek, selhání kritického procesu nebo situaci, kdy se několik týmů pokouší o nápravu, aniž by odhalily příčinu problému.

V této fázi má „tiger team“ k dispozici důkazy, na jejichž základě může pracovat. Jeho úkolem je propojit tyto signály, zúžit okruh možných příčin, ověřit nejpravděpodobnější vysvětlení a uvést systém zpět do stabilního stavu.

Dosažení této fáze může být nákladné. V průzkumu Global Data Center Survey 2025, který provedl Uptime Institute, 87 % respondentů, kteří v posledních třech letech zažili výpadek s významnými dopady, uvedlo, že by se mu dalo zabránit lepším řízením, procesy nebo konfigurací.

Z jejich výroční analýzy výpadků z roku 2026 rovněž vyplynulo, že 57 % respondentů uvedlo, že jejich poslední závažný výpadek stál více než 100 000 dolarů, zatímco každý pátý odhadl náklady na více než 1 milion dolarů. Tyto údaje se vztahují konkrétně na datová centra, a proto by neměly být považovány za univerzální měřítko pro každý „tiger team“.

Ukazují však, proč by práce po reaktivním zásahu neměla skončit pouze okamžitým vyřešením problému. Jakmile se situace stabilizuje, podívejte se na podmínky, které umožnily, aby se problém dostal tak daleko.

Preventivní „tiger týmy“ odhalují problémy včas

Preventivní „tiger team“ se sestavuje v době, kdy je ještě možné plán upravit.

NASA tento přístup přímo využila. Když její Centrum pro inženýrství a bezpečnost (Engineering and Safety Center) sestavilo hodnotící tým k posouzení pohonného systému kosmické lodi CALIPSO, skupina vytvořila strom poruch, aby před startem prozkoumala možné cesty k selhání. V retrospektivě NASA k 15 letům existence Centra pro inženýrství a bezpečnost popsal ředitel NESC Tim Wilson tento přístup takto:

Náš přístup spočíval ve vytvoření stromu poruch, který znázorňoval vše, co by se mohlo pokazit, a v posouzení, zda byly během výrobního procesu zavedeny vhodné kontrolní mechanismy, které by zajistily, že tyto armatury nebudou prosakovat.

To se blíží duchu prvních „tiger teamů“ v leteckém a kosmickém průmyslu. Tým dostane za úkol něco zásadního a je požádán, aby to prověřil ještě předtím, než nastanou důsledky.

Výsledkem by mělo být, že celý projekt získá konkrétní podklady pro další postup, například:

Příklady „tiger teamů“ v praxi

Týmy „Tiger“ se vyskytují ve stavebnictví, v oblasti vývoje softwaru i ve státní správě. Společnost Graham, Grafana Labs i britský Úřad pro boj proti podvodům ve veřejném sektoru (Public Sector Fraud Authority) každý z nich sestavily s cílem vyřešit konkrétní problém s jasně stanoveným cílem. Odborné znalosti se lišily případ od případu, zatímco struktura zůstala stejná.

Společnost Graham zkrátila dobu montáže tyčí řízení o 51 %

Stavební firma Graham sestavila „tiger team“ pro opakující se, ale nákladnou část svého projektu South Bank Quay. Pracovní čety měly nainstalovat 166 tahových tyčí, z nichž každá měřila více než 38 metrů a sloužila k ukotvení nábřežní zdi k kotevní zdi.

Tým sdružoval projektové pracovníky společnosti Graham, subdodavatele instalace, výrobce táhel a další partnery v dodavatelském řetězci. Nejprve zmapovali instalační proces, poté změřili práci na místě pomocí časosběrných záběrů a studie času a pohybu. Jakmile získali výchozí údaje, změnili proces a znovu jej změřili.

Podle případové studie iniciativy „Get It Right“ se doba montáže snížila ze 185 minut na 91 minut na jeden táhlo, což představuje snížení o přibližně 51 %, zatímco počet úkolů klesl o 37 %. Graham rovněž uvedl, že se v rámci programu ušetřilo 14 dní a odhadovaných 230 000 liber.

Tým zjistil drobné změny v rámci celého procesu, otestoval je na stejné práci a dokázal přesně ukázat, co se zlepšilo.

Společnost Grafana Labs proměnila problém s vydáním nové verze v trvalou odpovědnost

Vydávání open-source verzí Grafana Labs se stávalo stále více manuální záležitostí, zatímco odpovědnost za jejich vylepšování byla roztříštěna mezi několik vývojářských týmů. Tři zkušení inženýři, kteří již dříve pracovali na jednotlivých částech tohoto problému, byli na jedno čtvrtletí spojeni do jednoho týmu s cílem zjednodušit pracovní postupy, automatizovat sestavování a podporovat přímé vydávání oprav pro kanály Grafana Cloud.

„Release Tiger Team“ výrazně omezil počet manuálních kroků a usnadnil správu bezpečnostních verzí. Na konci čtvrtletí tato práce také dostatečně jasně odhalila dlouhodobý nedostatek, díky čemuž mohla společnost Grafana vytvořit specializovanou skupinu pro vydávání verzí.

Tento postup pomáhá řešit opakující se problémy se správou vydávání softwaru. Krátký zásah může vyřešit bezprostřední třenice a zároveň ukázat, komu náleží trvalá odpovědnost. Společnost Grafana uplatnila stejný model i v jiných oblastech, včetně „tiger teamu“, který pomohl získat významného partnera.

Britská vláda využila „tiger team“ ještě předtím, než se rizika podvodů proměnila ve ztráty

V roce 2022 využil britský Úřad pro boj proti podvodům ve veřejném sektoru (Public Sector Fraud Authority) model „tiger teamu“ ještě v době, kdy se nové programy podpory v oblasti energetiky teprve připravovaly.

Tým sdružoval specialisty na podvody z vládních úřadů, z Ofgem, z orgánů pro vypořádání plateb v energetice a externí odborníky z energetického sektoru. Podle výroční zprávy Úřadu pro podvody ve veřejném sektoru za období 2022–23 provedl tento tým posouzení dopadů a rizik podvodů u šesti nových energetických programů v rámci Ministerstva pro podnikání, energetiku a průmyslovou strategii a u jednoho programu v rámci Ministerstva financí Jejího Veličenstva.

Práce byla zahájena v dostatečném předstihu, aby programové týmy mohly reagovat na zjištění specialistů. Ministerstvo BEIS uvedlo, že díky širokému spektru odborných znalostí bylo možné do programů začlenit opatření proti podvodům a poskytnout ministrům přehled o klíčových rizicích již v době, kdy se programy teprve formovaly.

Pět chyb, které mohou zmařit práci „tiger teamu“

Těchto pět chyb může oslabit „tiger team“ i v případě, že je problém i struktura týmu jasně definována.

1. Změna několika věcí najednou

Když je tlak vysoký, je lákavé zkombinovat tři nebo čtyři slibná řešení a zjistit, zda problém zmizí.

Díky tomu můžete rychle dosáhnout lepších výsledků, ale zůstává tu jedna nepříjemná otázka: Která oprava zabrala? Pokud technický „tiger team“ v rámci jedné verze aktualizuje závislost, změní časový limit a zvýší kapacitu, pokles počtu selhání vám o příčině řekne jen velmi málo. Také to ztěžuje vrácení změn, pokud se později objeví další problém.

2. Sestavení týmu výhradně z externích členů

Nový úhel pohledu může pomoci, ale lidé, kteří s daným systémem pracují každý den, často znají výjimky, provizorní řešení a závislosti, které se do dokumentace nikdy nedostaly. Jejich opomenutí může vést k řešením, která zvenčí vypadají elegantně, ale selžou, jakmile se dostanou do reálného pracovního prostředí.

To platí i mimo oblast inženýrství. „Tiger tým“, který například přepracovává schvalovací proces, by měl naslouchat lidem, kteří tato schválení každý den zpracovávají, a ne pouze vedoucím pracovníkům, kteří na ně dohlížejí.

3. Proměna „tiger teamu“ v hledání viníků

Jakmile lidé získají dojem, že se „tiger team“ snaží zjistit, kdo problém způsobil, mohou být opatrnější v tom, co sdělují. Někdo může zamlčet své dřívější špatné rozhodnutí, vyhnout se zmínce o neúspěšném provizorním řešení nebo obhajovat staré rozhodnutí, protože se za něj cítí osobně zodpovědný. Tým tak má k dispozici méně důkazů a je obtížnější odhalit skutečnou příčinu.

4. Provádění riskantní změny bez plánu, jak ji zvrátit

I slibná oprava může sama o sobě způsobit novou poruchu. Týmy se dostávají do potíží, když plánují, jak změnu nasadit, ale ne jak ji vrátit zpět. Vrátit změnu zpět je také obtížnější, jakmile zákazníci, data nebo navazující systémy začnou se změnou interagovat.

5. Vytvoření druhého zdroje pravdy pro „tiger team“

Naléhavá práce často začíná tam, kde se lidé mohou pohybovat nejrychleji: v soukromém chatu, v ad hoc tabulce, v dočasném dokumentu nebo na samostatné projektové tabuli. Problémy nastávají, když se rozhodnutí, důkazy a úkoly rozptýlí napříč všemi těmito místy.

Někdo vidí v chatu nejnovější rozhodnutí, zatímco jiná osoba jedná podle starého rozhodnutí v tabulce. Po ukončení činnosti týmu je pak ještě těžší rekonstruovat, co se vlastně stalo.

Jak řídit „tiger team“ v ClickUp

„Tiger team“ může mít sice ty správné lidi a jasný zadání, ale přesto ztrácet čas, protože důkazy jsou uloženy v jednom nástroji, rozhodnutí se přijímají v jiném a následné práce probíhají někde jinde. Zde je příklad, jak by jeden tým mohl řídit celý proces v ClickUp, a to na základě dřívějšího příkladu s neúspěšnou platbou.

Příprava v první den

Řekněme, že po nedávném vydání vzrostl počet selhání checkoutu na 4 % a zadavatel požádal „tiger team“, aby tento podíl snížil zpět pod 1 %. Vedoucí týmu nejprve vytvoří složku s názvem „Checkout failures tiger team“ v rámci vývojového prostoru. Práce zůstává v blízkosti týmu, který ji převezme, jakmile se „tiger team“ rozpadne.

Uvnitř složky vytvoří vedoucí dokument ClickUp Doc pro pracovní zadání. Ten obsahuje podmínku ukončení (míra selhání nižší než 1 % po dobu 2 celých týdnů), výchozí stav, metriky úspěchu a bezpečnostní metriky, co spadá do rozsahu projektu a co ne, kdo může činit jaká rozhodnutí a tabulku s protokolem rozhodnutí. Během první pracovní schůzky se tým dohodne, že nejprve otestuje novou závislost na platebním API. Vedoucí tuto položku v dokumentu zvýrazní a převede ji na úkol, aniž by opustil pracovní zadání.

Vytváření fronty hypotéz

Tento první úkol se zařadí do seznamu nazvaného „Fronta hypotéz“ spolu se všemi ostatními teoriemi, které tým chce otestovat. Stavy v tomto seznamu odpovídají kategoriím důkazů z kroku 3, přičemž je přidán jeden stav pro práci v průběhu: „Podezření“, „Testování“, „Potvrzeno“ a „Vyloučeno“. Neznámé skutečnosti mohou být v briefu uvedeny jako otevřené otázky.

Jakmile jsou testy dokončeny, úkoly se přesouvají a celý tým vidí, co je již známo a co je zatím jen domněnka. Vedoucí přidá ke každé hypotéze 3 vlastní pole: Dopad, Náklady na test a Výsledek. Seřazení podle Dopadu a následně podle Nákladů na test umístí na začátek seznamu teorie, které by mohly vysvětlit nejvíce a jejichž ověření zabere nejméně času.

Zkontrolujte, co již bylo vyzkoušeno

Než inženýři spustí test API, jeden z nich se zeptá Brain²: „Testovali jsme už dříve časové limity poskytovatelů platebních služeb?“

Brain² prohledává úkoly, dokumenty, chat a propojené aplikace pomocí funkce Enterprise Search a najde podobné vyšetřování z před 6 měsíci s odkazy na zdroje. Tým si přečte, co bylo minule vyloučeno, upraví test a vloží odkazy do úkolu s hypotézou, aby k němu zůstala připojena historie.

Zabránění tomu, aby se do vyšetřování dostávaly nové žádosti

Na konci prvního týdne začali lidé mimo tým upozorňovat na související problémy: chybu v zobrazení cen, pomalý proces založení účtu. Každý z nich by se mohl snadno proměnit v novou práci.

Vedoucí vytvoří formulář v ClickUp, který tyto podněty odesílá do samostatného seznamu s názvem „Parking lot“. Každý podnět se tam stane samostatným úkolem a sponzor při každém kontrolním setkání seznam zkontroluje, aby rozhodl, zda něco spadá do rozsahu projektu.

Poskytnutí jediného místa, kam se může sponzor obrátit

Sponzor musí zasáhnout, když se čeká na jeho rozhodnutí, ale nemusí den za dnem sledovat průběh zbytku vyšetřování.

Vedoucí přidá zaškrtávací políčko s názvem „Vyžaduje rozhodnutí sponzora“ a vytvoří dashboard se třemi kartami: jedna pro úkoly čekající na sponzora, jedna pro zablokovanou nebo zpožděnou práci a jedna sledující míru selhání jako číselné pole. Sponzor si tuto stránku otevře před každým check-inem.

Nechte připomenutí a aktualizace běžet samy

Ve 2. týdnu tým jako dočasné řešení deaktivuje určitou funkci pro dotčené účty a toto rozhodnutí je třeba za 7 dní znovu zvážit. Vedoucí nastaví termín splnění úkolu na tento den a přidá automatizaci, která majitele úkolu upozorní, až tento den nastane.

Čas vedoucího týmu začínají zabírat také aktualizace pro zainteresované strany. Superagent nyní každé pondělí a čtvrtek zveřejňuje krátké shrnutí, které zahrnuje nová rozhodnutí, překážky a vše, co čeká na sponzora.

Předání práce zpět

Míra selhání se po celé dva týdny drží pod 1 %, takže tým splnil podmínku pro ukončení. Vedoucí přesune zbývající otevřené úkoly do seznamu platebního týmu a přeřadí je. Poslední záznam v protokolu rozhodnutí uvádí jméno nového vlastníka a podmínky, za kterých by mělo být zahájeno nové vyšetřování. Poté vedoucí složku archivuje.

Ceny služby ClickUp

Nejlepší „tiger team“ ví, kdy je čas ustoupit

„Tiger team“ je řízená výjimka. Dočasně soustředíte odborné znalosti, pravomoci a pozornost na problém, který běžná struktura nedokáže vyřešit obvyklým tempem.

To znamená, že závěr je stejně důležitý jako samotný zásah. Jakmile je problém pod kontrolou, tým by měl být schopen odstoupit, aniž by s sebou odnášel svá rozhodnutí, důkazy nebo nedokončenou práci. Pokud organizace stále závisí na téže dočasné skupině, aby vše fungovalo, problém se změnil.

Po předání zůstává záznam o tom, jak byl problém pochopen a vyřešen. V ClickUp zůstává tento záznam prohledávatelný i po archivaci složky „tiger teamu“, takže další odpovědná osoba může najít zadání, hypotézy a protokol rozhodnutí, aniž by je musela znovu sestavovat.

Často kladené otázky týkající se „tiger týmů“

Jak velký by měl být „tiger team“?

Neexistuje žádný univerzální počet členů. Jádro týmu by mělo být tak malé, jak to daný problém dovoluje, a další odborníky zapojujte až tehdy, když potřebujete jejich znalosti. Čím větší je tým, tím větší je zátěž spojená s komunikací a koordinací. Pokud někdo potřebuje pouze poskytnout důkazy nebo odpovědět na konkrétní otázku, nemusí se nutně stát stálým členem „tiger teamu“.

Může „tiger team“ pracovat na dálku?

Ano. „Tiger team“ nemusí sdílet fyzickou místnost. Potřebuje však rychlý přístup ke stejným důkazům, jasné rozdělení odpovědnosti a spolehlivé místo pro rozhodování. V případě rozptýleného týmu udržujte pracovní záznamy aktuální a synchronní hovory si vyhrazujte pouze pro rozhodování, překážky nebo důkazy, které mění průběh vyšetřování. Tím zabráníte tomu, aby časové rozdíly proměnily každou aktualizaci v další schůzku.

Je „tiger team“ součástí metodiky Agile nebo Scrum?

Ne. „Tiger team“ není formální role, událost ani odpovědnost v rámci Scrumu. Oficiální Průvodce Scrumem definuje Scrumový tým jako skupinu složenou z produktového vlastníka, Scrum Mastera a vývojářů. Společnost využívající Scrum však může přesto sestavit „tiger team“ pro řešení problému, který přesahuje hranice stávajících týmů. Stačí se jen rozhodnout, jak bude tato dočasná pracovní skupina spolupracovat se stávajícími závazky ve sprintu a cíli produktu.

Musí být „tiger team“ technicky zaměřený?

Ne. Tento model vznikl v leteckém a kosmickém průmyslu a je stále běžný v inženýrství a bezpečnosti, ale jeho struktura může fungovat kdekoli, kde je třeba soustředit odborné znalosti na řešení složitého problému. „Tiger team“ může vyšetřovat podvody, přepracovat provozní proces, vyřešit regulační problém nebo se zabývat obchodním problémem. Odborné znalosti se mění podle konkrétního problému.

Mohou se k „tiger teamu“ připojit i lidé mimo společnost?

Ano. Externí odborníci, dodavatelé, konzultanti nebo partneři v dodavatelském řetězci se mohou zapojit, pokud disponují znalostmi, které interní tým nemá. Zajistěte jim stejnou jasnost ohledně rozsahu, přístupu, důvěrnosti a rozhodovacích pravomocí jako interním členům. Měli by být součástí týmu proto, že vyšetřování vyžaduje jejich odborné znalosti, a ne pouze proto, že výsledek se týká jejich organizace.

Co se stane, pokud „tiger team“ nedokáže problém vyřešit?

Tým by měl organizaci opustit s užším problémem, než s jakým začal. To může znamenat identifikovat, co již bylo vyloučeno, izolovat zbývající neznámé faktory, zdokumentovat, které zásahy selhaly, a ukázat, kde současný tým dosáhl hranic svých odborných znalostí nebo pravomocí. Na základě toho může vedení rozhodnout, zda práce vyžaduje jiného specialistu, více času, stálého odpovědného pracovníka nebo větší strukturální změnu. Nesplnění původní podmínky pro ukončení projektu nevymaže poznatky získané během vyšetřování.

Jaký je rozdíl mezi „tiger týmem“ a mezifunkčním týmem?

Pojem „mezifunkční“ popisuje, kdo je členem týmu. Pojem „tým typu tiger“ popisuje, proč byla skupina sestavena a jak dlouho se předpokládá, že bude existovat. Mezifunkční tým může být stálý a mít na starosti konkrétní produkt, proces nebo oblast podnikání. Tým typu tiger se sestavuje za účelem řešení konkrétního problému a po dokončení daného úkolu se rozpustí. Tým typu tiger je často mezifunkční, ale tyto dva pojmy nejsou zaměnitelné.