Czym jest zespół „Tiger Team”? Definicja, pochodzenie i kiedy warto z niego skorzystać

„Houston, mamy problem.”

Każdy z nas przynajmniej raz z niego skorzystał. Stało się to skrótem opisującym tę przygnębiającą chwilę, kiedy coś ważnego się psuje i trzeba to szybko naprawić.

W pracy zazwyczaj oznacza to problem, który dotyka kilka zespołów. Na przykład ten jeden błąd, który przetrwał kilka rund poprawek, uszkodził trzy bazy danych klientów i powoduje wzrost liczby zgłoszeń do pomocy technicznej. Zaczęło się od działu inżynierii, ale teraz część odpowiedzialności spoczywa na działach wsparcia, produktu i obsługi klienta.

W takiej sytuacji potrzebny jest właśnie zespół „tygrys”: niewielka, tymczasowa grupa specjalistów zebrana w celu rozwiązania jednego, jasno zdefiniowanego problemu o dużej wadze. Idea ta narodziła się w latach 60. XX wieku w przemyśle lotniczym i kosmicznym, a od tego czasu rozprzestrzeniła się na inżynierię, administrację rządową, bezpieczeństwo oraz codzienne działania operacyjne.

Z biegiem czasu jednak znaczenie tego terminu uległo rozszerzeniu i obecnie obejmuje niemal każde pilne spotkanie z udziałem kilku osób na wysokich stanowiskach. Wyjaśnimy, czym faktycznie jest zespół „tiger team”, skąd pochodzi ten termin oraz czym różni się od grup zadaniowych i centrów dowodzenia, z którymi często jest mylony.

Czym jest zespół „Tiger Team”?

„Tiger team” to grupa o krótkoterminowym charakterze, której zadaniem jest rozwiązanie jednego problemu, którego obecna struktura organizacyjna nie jest w stanie rozwiązać w wymaganym tempie.

Struktura ma większe znaczenie niż etykieta. Zespół „tiger team” potrzebuje jasno określonego celu, wiedzy specjalistycznej niezbędnej do przeprowadzenia dochodzenia oraz wystarczających uprawnień, by działać bez przekształcania się w kolejną stałą komisję.

Zespoły typu „tiger team” zazwyczaj mają kilka wspólnych cech:

Strukturę tę można zaobserwować w zespołach typu „tiger team” zajmujących się ubezpieczeniem od bezrobocia w Departamencie Pracy Stanów Zjednoczonych. Począwszy od 2021 r. departament zgromadził specjalistów w dziedzinie zapobiegania oszustwom, obsługi klienta, ubezpieczeń od bezrobocia, danych oraz inżynierii systemowej, aby ocenić problemy występujące w programach poszczególnych stanów i zaproponować krótkoterminowe usprawnienia. W ciągu pierwszych 24 miesięcy zespoły te współpracowały z 36 stanami.

Nie każdy zespół „tygrys” będzie jednak wyglądał identycznie. Niektórzy członkowie mogą częściowo kontynuować swoją zwykłą pracę, podczas gdy inni mogą całkowicie się od niej odciąć.

Skąd pochodzi termin „zespół tygrysów”?

Termin ten wywodzi się z amerykańskiego przemysłu lotniczego i kosmicznego z lat 60. XX wieku, na długo przed tym, zanim stał się powszechnie używany w kontekście problemów biznesowych.

Jedno z najwcześniejszych udokumentowanych zastosowań tego terminu pojawia się w artykule SAE z 1964 r. pt. „Program Management in Design and Development” autorstwa J. R. Dempseya, W. A. Davisa, A. S. Crossfielda i Waltera C. Williamsa. Opisano w nim zespół „tiger team” jako grupę „nieposkromionych i nieskrępowanych specjalistów technicznych”, wybranych ze względu na ich doświadczenie, energię i wyobraźnię. Ich zadaniem było nieustanne poszukiwanie potencjalnych źródeł awarii w systemach statków kosmicznych i symulacjach.

Nie byli to po prostu starsi eksperci zebrani w jednym pomieszczeniu. Oczekiwano od nich, że będą kwestionować założenia, wykrywać słabe punkty, które innym umknęły, oraz działać poza niektórymi typowymi ograniczeniami związanymi z programem.

Sześć lat później misja Apollo 13 nadała temu terminowi jedno z jego najsłynniejszych skojarzeń. 13 kwietnia 1970 r. doszło do eksplozji zbiornika tlenu, gdy statek kosmiczny znajdował się w odległości około 200 000 mil od Ziemi. Jack Swigert nawiązał łączność radiową z Centrum Kontroli Lotów, mówiąc: „Houston, mamy tu problem” – zdanie , które później weszło do kultury popularnej jako „Houston, mamy problem”.

Dyrektor lotów NASA , Gene Kranz , stanął wówczas na czele zespołu , który w dokumentacji NASA określono mianem „zespołu tygrysów” misji Apollo 13 , współpracując z szerszym zespołem operacyjnym misji w celu rozwiązania problemów stojących na drodze astronautów do bezpiecznego powrotu. Zespół operacyjny misji Apollo 13 otrzymał później Prezydencki Medal Wolności za swoją rolę w akcji ratunkowej.

Misja Apollo 13 przyczyniła się do ugruntowania pozycji zespołu „tiger team” jako modelu skoncentrowanego rozwiązywania problemów pod presją, ale to nie ona zapoczątkowała użycie tego terminu.

Zespół „Tiger Team” a grupa zadaniowa, „War Room”, „Red Team” i „Skunkworks”

Zespoły typu „tiger team” są często mylone z innymi strukturami grupowymi, takimi jak grupy zadaniowe, „war rooms”, zespoły typu „red team” oraz „skunkworks”. Wszystkie one mogą obejmować małe grupy działające poza zwykłą strukturą zespołową, ale są tworzone z różnych powodów.

Najłatwiej pomylić zespół „tiger team” z grupą zadaniową, ponieważ obie struktury mogą skupiać osoby z różnych funkcji. Różnica sprowadza się do zakresu uprawnień. Grupa zadaniowa może badać szeroko zakrojony problem, koordynować inicjatywę lub rekomendować zmiany. Zespół „tiger team” zazwyczaj otrzymuje w zadanie rozwiązanie węższej kwestii i większą swobodę, by szybko się z nią uporać.

„War room” ma inne pochodzenie. Powstaje w związku z incydentem, który już ma miejsce, i zapewnia osobom reagującym na niego wspólną przestrzeń oraz rytm podejmowania decyzji. Z „war roomu” może wyłonić się zespół „tiger team”, jeśli bieżący incydent ujawni głębszy problem wymagający skoncentrowanej pracy po ustabilizowaniu się sytuacji.

Zespoły typu „red team ” mają bardziej celowo antagonistyczny charakter. Na przykład w dziedzinie cyberbezpieczeństwa NIST definiuje zespół typu „red team” jako grupę zorganizowaną w celu symulowania ataku przeciwnika lub jego zdolności do wykorzystania luk w zabezpieczeniach. Celem jest wykrycie słabych punktów poprzez poddanie systemu testom wytrzymałościowym. Zespół typu „tiger team” może kierować się podobnym podejściem, ale jego szerszym zadaniem jest rozwiązanie problemu, w związku z którym został powołany.

Zespół typu „skunkworks” działa w inny sposób. Model ten, rozsławiony przez Skunk Works firmy Lockheed Martin, zapewnia niewielkiej grupie niezwykłą autonomię w opracowywaniu nowych rozwiązań. Zespoły typu „tiger team” są zazwyczaj tworzone w celu rozwiązania konkretnego problemu, dla którego określono warunek zakończenia. Zespoły typu „skunkworks” mogą działać razem znacznie dłużej, podczas gdy pomysł jest analizowany, projektowany i testowany.

Te rozróżnienia mają znaczenie, ponieważ nadanie grupie nazwy brzmiącej bardziej pilnie nie zmienia sposobu jej działania. Przed utworzeniem zespołu „tiger team” lepiej zadać sobie pytanie, czy dany problem w ogóle wymaga zastosowania właśnie takiej struktury.

Kiedy należy utworzyć zespół „Tiger Team”?

Powołanie zespołu „tygrysiego” ma sens, gdy problem ma charakter międzyfunkcjonalny, wymaga wkładu specjalistów lub utknął w normalnym procesie. Jednak włączenie specjalistów do tymczasowego zespołu odciąga ich od zadań, za które już są odpowiedzialni.

Dobra sprawa zazwyczaj spełnia cztery kryteria:

Ten sam model można również wykorzystać w celach prewencyjnych, zanim zmiana wysokiego ryzyka trafi do środowiska produkcyjnego lub zostanie wprowadzona na rynek.

Jakie są kluczowe role w zespole „Tiger Team”?

Zespół „tiger team” nie musi składać się z wielu osób, ale każdy powinien wiedzieć, za co jest odpowiedzialny. W większości przypadków potrzebnych będzie kilka kluczowych ról:

W małym zespole jedna osoba może pełnić wiele ról. Kluczowe jest to, aby kompetencje, własność bieżących działań, specjalistyczna wiedza oraz dokumentacja miały jasno określone przypisanie.

Jak prowadzić zespół „Tiger Team” w 7 krokach

Gdy zespół już powstanie, praca musi być odpowiednio ustrukturyzowana, aby dochodzenie nie przerodziło się w ciąg spotkań, teorii i niepowiązanych ze sobą działań naprawczych. Poniższe kroki prowadzą zespół od pierwszej sesji roboczej aż po weryfikację i przekazanie sprawy.

1. Przekształć cel w brief roboczy

Każdy zespół „tygrys” potrzebuje warunku zakończenia działań: konkretnego wyniku, który sygnalizuje wszystkim, że problem został rozwiązany i zespół może się rozwiązać. Najpierw uzgodnijcie ten warunek, a następnie przekształćcie go w coś, co ludzie będą mogli wykorzystać jako wskazówkę przy podejmowaniu codziennych decyzji.

Zazwyczaj wystarczy krótka instrukcja robocza. Powinna ona zawierać odpowiedzi na następujące pytania:

Zwróć szczególną uwagę na ostatnie pytanie. Wyobraź sobie zespół operacyjny zmagający się z rosnącym zaległościami w przetwarzaniu spraw. Zmniejszenie liczby spraw w kolejce poniżej 500 może wydawać się sukcesem na jedno popołudnie. Utrzymanie tego poziomu przez cały tydzień, podczas gdy tempo codziennego przetwarzania nadal przewyższa napływ nowych spraw, jest znacznie mocniejszym dowodem na to, że rozwiązanie będzie trwałe.

2. Określ role, uprawnienia decyzyjne i granice kompetencji

Zacznij od wyznaczenia kierownika, sponsora, specjalistów oraz osoby odpowiedzialnej za bieżącą aktualizację dokumentacji roboczej. Następnie jak najwcześniej ustal, kto ma prawo podejmować decyzje. Zespół może samodzielnie podejmować niektóre decyzje, inne wymagają zgody sponsora, a jeszcze inne nadal należą do zespołów, które zazwyczaj są za nie odpowiedzialne.

Zespół musi również mieć jasno określony zakres obowiązków. Zanim dochodzenie nabierze tempa, zapisz:

Ten ostatni element pozwala uniknąć wielu niepożądanych odchyleń. Na przykład dochodzenie dotyczące płatności może ujawnić problemy związane z ustalaniem cen, ustawieniami kont lub procesem wdrażania klientów. Niektóre z nich warto rozwiązać później, ale włączenie ich wszystkich do bieżącego zadania sprawia, że dwutygodniowy wysiłek zamienia się w dwumiesięczny.

Równie duże obciążenie należy poświęcić kwestii dostępności zasobów. Przeznacz inne osoby do pilnych zadań, przesuń terminy tam, gdzie to możliwe, i poinformuj zainteresowanych właścicieli o zmianach. W przeciwnym razie członkowie zespołu będą musieli prowadzić zespół „tygrysów” oprócz wszystkich innych obowiązków, które już mieli na głowie.

3. Oddziel dowody od teorii, a następnie zdecyduj, co należy sprawdzić

W momencie powołania zespołu „tygrysiego” kilka osób może już mieć swoje wyjaśnienie tego, co poszło nie tak. Zacznij od oddzielenia tego, co zespół wie, od tego, co tylko podejrzewa.

W ramach tego ćwiczenia przejrzyj poprzednie rozwiązania, eksperymenty, notatki dotyczące incydentów i podjęte decyzje. Rozwiązanie, które dziś wydaje się obiecujące, mogło zostać przetestowane już sześć miesięcy temu. Następnie wybierz najprzekonujące wyjaśnienia i ułóż z nich krótką listę hipotez. Dla każdej z nich zapisz, co Twoim zdaniem się dzieje, jakie dowody zapewniają wparcie dla tej hipotezy, jak zamierzasz to sprawdzić oraz jakie wnioski wynikają z uzyskanego wyniku.

Uporządkuj listę zadań według tego, czego możesz się nauczyć. Teoria, która mogłaby wyjaśnić większość problemu, a jej przetestowanie zajmuje godzinę, zasługuje na uwagę przed tą, która wymaga tygodnia pracy inżynierskiej.

4. Prowadź rejestr decyzji, które mogą wpłynąć na przebieg dochodzenia

Zapisuj rozmowy, które mogą wpłynąć na dalsze działania zespołu lub które ktoś może słusznie potrzebować zrozumieć w późniejszym czasie. Mogą to być na przykład zaakceptowane ryzyko, odrzucone rozwiązanie techniczne, zmiana zakresu lub decyzja o zaprzestaniu weryfikacji hipotezy.

Przeglądaj dziennik za każdym razem, gdy nowe dowody podważają wcześniejsze założenia, i zapewnij widoczność aktualnej decyzji wraz z dowodami, na których się opiera.

5. Niech to problem wyznacza rytm pracy

Częstotliwość spotkań zespołu „tiger team” zależy od tego, jak szybko zmienia się problem. Podczas rzeczywistej awarii zespół może zbierać się co kilka godzin. Dwutygodniowe dochodzenie dotyczące powoli postępującego problemu z danymi zazwyczaj można przeprowadzić, organizując kilka spotkań w tygodniu.

Niezależnie od tempa pracy każde spotkanie powinno mieć jasny cel. Mogą to być nowe dowody zmieniające obraz sytuacji, przeszkoda, którą może usunąć wyłącznie sponsor, lub decyzja, którą zespół musi podjąć wspólnie. Codzienne postępy lepiej jest dokumentować w formie pisemnej, dzięki czemu uczestnicy mogą je przejrzeć w dowolnym wolnym momencie.

Jeśli praca trwa dłużej niż kilka tygodni, zaplanuj przegląd w połowie projektu. Da to zespołowi szansę na oderwanie się od codziennego prowadzenia śledztwa i zadanie sobie pytania:

Szczere odpowiedzi na tym etapie mogą uchronić zespół przed poświęceniem drugiej połowy czasu na rozwiązywanie niewłaściwego problemu.

Zainteresowane strony zazwyczaj nie muszą brać udziału w tych działaniach. Krótka notatka co kilka dni, zawierająca informacje o tym, czego zespół się dowiedział, jakie podjął decyzje i gdzie napotkał trudności, pozwala im być na bieżąco na tyle, by mogli wkroczyć do akcji, gdy zajdzie taka potrzeba.

6. Daj rozwiązaniu czas, by się sprawdziło

Poprawka może wydawać się przekonująca w dniu jej wdrożenia, a mimo to zawieść, gdy powróci normalny ruch, natężenie lub wystąpią skrajne przypadki. Dlatego zespół nie powinien ogłaszać rozwiązania problemu w momencie, gdy wskaźniki ulegną poprawie.

To, jak długo należy monitorować poprawkę, zależy od tego, jak często problem może się ponownie pojawić. Na przykład w przypadku usługi o dużym natężeniu ruchu wiarygodny sygnał może pojawić się już w ciągu kilku godzin. W przypadku comiesięcznego zamknięcia finansowego może być konieczny kolejny pełny cykl, zanim będzie można stwierdzić, że poprawka zadziałała.

W międzyczasie miej na widoku dwie liczby:

Jeśli wyniki zaczną się ponownie zmieniać, potraktuj to jako nowy dowód. Włącz to do dochodzenia i sprawdź, co to zmieni. Może to sprawić, że na czoło listy wysunie się inna hipoteza lub ujawni, że pierwotna diagnoza wyjaśniała jedynie część tego, co szło nie tak.

7. Przekaż sprawę w idealnym stanie

Na tym etapie zespół przygotował już większość elementów niezbędnych do przekazania sprawy. Brief roboczy, dowody, testy, rejestr decyzji i dane weryfikacyjne znajdują się już w dokumentacji. Przepisywanie ich do dopracowanego raportu końcowego oznacza jedynie dodatkową pracę, nie wnosząc nic więcej.

Zamiast tego zgromadź te dokumenty i spraw, by nie dało się przeoczyć faktu, kto jest faktycznym właścicielem własności. Osoba, która ostatecznie przejmie sprawę, powinna odejść ze świadomością, że:

Zanim ktokolwiek odejdzie, odpowiedz na pytanie: Kto otrzyma zgłoszenie, jeśli problem powróci?

Gdy osiągnięty zostanie wynik i ustalona zostanie odpowiedź, zespół „tygrysów” może się rozwiązać. Członkowie wracają do swoich zwykłych obowiązków, bieżące zadania powracają do normalnej struktury, a wyniki dochodzenia pozostają w aktach dla każdego, kto będzie ich potrzebował w przyszłości.

Zespoły „tygrysie” reagujące a prewencyjne

Zespoły „Tiger” zazwyczaj wkraczają do akcji w jednym z dwóch momentów. Niektóre są tworzone dopiero wtedy, gdy problem już wpływa na działalność firmy. Inne są angażowane wcześniej, kiedy jest jeszcze czas na wykrycie słabych punktów i zmianę planu.

Różnica sprowadza się do tego, czego zespół próbuje się dowiedzieć.

Reaktywne zespoły typu „tiger team” zaczynają pracę od problemu, który już się pojawił

To właśnie ta wersja kojarzy się większości osób z zespołami typu „tiger team”. Może to być opóźnienie w uruchomieniu produktu, nawracająca awaria, załamanie się kluczowego procesu lub sytuacja, w której kilka zespołów próbuje wprowadzać poprawki, nie docierając do źródła problemu.

W tym momencie zespół „tiger team” dysponuje już dowodami, na podstawie których może pracować. Jego zadaniem jest połączenie tych sygnałów, zawężenie kręgu potencjalnych przyczyn źródłowych, zweryfikowanie najbardziej prawdopodobnych hipotez oraz przywrócenie systemu do stabilnego stanu.

Dotarcie do tego etapu może być kosztowne. W badaniu „Global Data Center Survey 2025” przeprowadzonym przez Uptime Institute 87% respondentów, którzy w ciągu ostatnich trzech lat doświadczyli poważnej awarii, stwierdziło, że można było jej uniknąć dzięki lepszemu zarządzaniu, procesom lub konfiguracji.

W raporcie „Annual Outage Analysis 2026” stwierdzono również, że 57% respondentów podało, iż ich ostatnia poważna awaria kosztowała ponad 100 000 dolarów, a co piąty oszacował ten koszt na ponad 1 milion dolarów. Dane te dotyczą konkretnie centrów danych, dlatego nie należy ich traktować jako uniwersalnego punktu odniesienia dla każdego zespołu „tygrysiego”.

Pokazują one jednak, dlaczego działania po interwencji reaktywnej nie powinny kończyć się na natychmiastowym rozwiązaniu problemu. Gdy sytuacja się ustabilizuje, należy przyjrzeć się warunkom, które doprowadziły do tak poważnego problemu.

Prewencyjne zespoły „tygrysie” wcześnie wykrywają potencjalne problemy

Prewencyjny zespół „tygrys” rozpoczyna działania, gdy wciąż istnieje możliwość zmiany planu.

NASA bezpośrednio wykorzystała to podejście. Kiedy jej Centrum Inżynierii i Bezpieczeństwa (Engineering and Safety Center) powołało zespół oceniający w celu przeanalizowania układu napędowego statku kosmicznego CALIPSO, grupa ta stworzyła drzewo błędów, aby zbadać możliwe ścieżki awarii przed startem. W retrospektywie NASA poświęconej 15-leciu działalności Centrum Inżynierii i Bezpieczeństwa dyrektor NESC Tim Wilson opisał to podejście w następujący sposób:

Nasze podejście polegało na sporządzeniu drzewa błędów, które przedstawiało wszystko, co mogło pójść nie tak, oraz na ustaleniu, czy podczas procesu montażu zastosowano odpowiednie środki kontroli, aby zapewnić, że te złącza nie będą przeciekać.

To zbliża się do ducha wczesnych zespołów „tygrysich” z branży lotniczej. Zespół otrzymuje zadanie o istotnych konsekwencjach i ma za zadanie zmierzyć się z nim, zanim te konsekwencje się pojawią.

Wynikiem tych działań powinno być dostarczenie szerszemu zespołowi projektowemu konkretnych wskazówek do działania, takich jak:

Przykłady zespołów „Tiger Team” w praktyce

Zespoły typu „tiger team” spotyka się w branży budowlanej, w sektorze oprogramowania oraz w administracji publicznej. Firmy Graham i Grafana Labs oraz brytyjski Urząd ds. Zwalczania Nadużyć Finansowych w Sektorze Publicznym utworzyły po jednym takim zespole w celu rozwiązania konkretnego problemu o jasno określonym celu. Chociaż zakres wiedzy specjalistycznej różnił się w zależności od przypadku, struktura zespołów pozostawała taka sama.

Firma Graham skróciła czas montażu drążków kierowniczych o 51%

Wykonawca robót inżynierii lądowej, firma Graham, utworzyła zespół „tiger team” w związku z powtarzalnym, ale kosztownym elementem projektu South Bank Quay. Ekipy miały do zamontowania 166 prętów łączących, z których każdy miał długość ponad 38 metrów i służył do zakotwiczenia ściany nabrzeża do ściany kotwiącej.

W skład zespołu weszli pracownicy projektu firmy Graham, podwykonawca odpowiedzialny za montaż, producent cięgien oraz inni partnerzy z łańcucha dostaw. Najpierw opracowali mapę procesu montażu, a następnie zmierzyli czas trwania prac na miejscu przy użyciu nagrań poklatkowych oraz analizy czasu i ruchu. Po ustaleniu punktu odniesienia wprowadzili zmiany w procesie i ponownie go zmierzyli.

Zgodnie z analizą przypadku przeprowadzoną w ramach inicjatywy „Get It Right” czas montażu jednego drążka kierowniczego skrócił się z 185 minut do 91 minut, co stanowi spadek o około 51%, a liczba zadań zmniejszyła się o 37%. Firma Graham odnotowała również oszczędność 14 dni w ramach programu oraz szacunkową kwotę 230 000 funtów.

Zespół zidentyfikował drobne zmiany w całym procesie, przetestował je na tych samych zadaniach i był w stanie dokładnie wykazać, co uległo poprawie.

Firma Grafana Labs przekształciła problem związany z wydaniem w stałą własność

Wydania oprogramowania open source firmy Grafana Labs wymagały coraz więcej pracy ręcznej, a odpowiedzialność za ich ulepszanie była rozproszona między kilka zespołów inżynierów. Trzech starszych inżynierów, którzy już wcześniej zajmowali się niektórymi aspektami tego problemu, zostało zebranych na jeden kwartał, aby uprościć cykl pracy, zautomatyzować kompilacje i zapewnić wsparcie dla kanałów Grafana Cloud.

Zespół „Release Tiger Team” radykalnie ograniczył liczbę kroków wykonywanych ręcznie i ułatwił obsługę wydawania aktualizacji zabezpieczeń. Pod koniec kwartału dzięki tej pracy udało się również wystarczająco wyraźnie zidentyfikować długoterminową lukę, co pozwoliło firmie Grafana utworzyć dedykowaną grupę ds. wydawania aktualizacji.

Taki sposób postępowania pomaga rozwiązywać powtarzające się problemy związane z zarządzaniem wydaniami oprogramowania. Krótka interwencja może rozwiązać bieżące trudności, a jednocześnie wskazać, na kim spoczywa stała odpowiedzialność. Firma Grafana zastosowała ten sam model w innych obszarach, m.in. tworząc zespół „tiger team”, który pomógł pozyskać ważnego partnera.

Rząd Wielkiej Brytanii skorzystał z pomocy zespołu „tiger team”, zanim ryzyko oszustw przerodziło się w straty

W 2022 r. brytyjski Urząd ds. Zwalczania Nadużyć w Sektorze Publicznym (Public Sector Fraud Authority) zastosował model zespołu „tiger team” jeszcze w trakcie opracowywania nowych programów wsparcia energetycznego.

Oceny skutków oszustw i ryzyka w ramach sześciu nowych programów energetycznych w Departamencie Biznesu, Energii i Strategii Przemysłowej oraz jednego w Ministerstwie Skarbu zostały zakończone zgodnie z raportem rocznym Urzędu ds. Oszustw w Sektorze Publicznym za lata 2022–23.

Prace rozpoczęto na tyle wcześnie, aby zespoły programowe mogły podjąć działania w oparciu o ustalenia specjalistów. BEIS stwierdziło, że szeroki zakres wiedzy eksperckiej pomógł uwzględnić kwestie związane z oszustwami w samych programach oraz zapewnił ministrom widoczność w odniesieniu do kluczowych ryzyk jeszcze na etapie ich kształtowania.

Pięć błędów, które mogą zniweczyć sukces zespołu „Tiger Team”

Te pięć błędów może osłabić zespół „tygrysów”, nawet jeśli problem i struktura zespołu są jasno określone.

1. Wprowadzanie kilku zmian jednocześnie

Kiedy presja jest duża, kuszące jest połączenie trzech lub czterech obiecujących rozwiązań i sprawdzenie, czy problem zniknie.

Dzięki temu można szybko osiągnąć lepszy wynik, ale pozostaje niewygodne pytanie: które rozwiązanie zadziałało? Jeśli zespół inżynierów typu „tiger team” w ramach tej samej aktualizacji zaktualizuje zależność, zmieni limit czasu i zwiększy obciążenie, spadek liczby awarii niewiele mówi o przyczynie. Utrudnia to również przywrócenie poprzedniego stanu, jeśli później pojawi się inny problem.

2. Tworzenie zespołu wyłącznie z osób spoza organizacji

Świeże spojrzenie może być pomocne, ale osoby, które na co dzień pracują z danym systemem, często znają wyjątki, obejścia i zależności, które nigdy nie znalazły się w dokumentacji. Pominięcie ich może skutkować rozwiązaniami, które z pozoru wydają się przejrzyste, ale zawodzą, gdy tylko zetkną się z rzeczywistym cyklem pracy.

Ma to zastosowanie nie tylko w inżynierii. Na przykład zespół „tygrysów” przeprojektowujący proces zatwierdzania powinien wysłuchać opinii osób, które na co dzień zajmują się tymi zatwierdzeniami, a nie tylko liderów, którzy nad nimi czuwają.

3. Przekształcanie zespołu „tygrysiego” w ćwiczenie polegające na szukaniu winnych

Gdy ludzie poczują, że zespół „tiger team” próbuje ustalić, kto spowodował problem, mogą stać się bardziej ostrożni w tym, co udostępniają. Ktoś może pominąć błędną decyzję, którą podjął wcześniej, unikać wzmianki o nieudanym rozwiązaniu tymczasowym lub bronić dawnej decyzji, ponieważ czuje się za nią osobiście odpowiedzialny. To sprawia, że zespół dysponuje mniejszą ilością dowodów, a ustalenie prawdziwej przyczyny staje się trudniejsze.

4. Wprowadzanie ryzykownej zmiany bez planu sposobu jej cofnięcia

Obiecujące rozwiązanie może samo w sobie spowodować nową awarię. Zespoły wpadają w kłopoty, gdy planują wdrożenie zmiany, ale nie przewidują, jak ją cofnąć. Cofnięcie zmiany staje się również trudniejsze, gdy klienci, dane lub systemy niższego szczebla zaczną już korzystać z tej zmiany.

5. Stworzenie drugiego źródła informacji dla zespołu „tiger team”

Pilne zadania często powstają tam, gdzie ludzie mogą działać najszybciej: na prywatnym czacie, w doraźnym arkuszu kalkulacyjnym, w tymczasowym dokumencie lub na osobnej tablicy projektowej. Kłopoty zaczynają się, gdy decyzje, dowody i zadania są rozproszone po wszystkich tych miejscach.

Ktoś widzi najnowszą decyzję na czacie, podczas gdy inna osoba działa zgodnie ze starą decyzją zapisaną w arkuszu kalkulacyjnym. Po zamknięciu pracy zespołu odtworzenie przebiegu wydarzeń staje się jeszcze trudniejsze.

Jak zarządzać zespołem „Tiger Team” w ClickUp

Zespół „tiger team” może dysponować odpowiednimi ludźmi i precyzyjnym briefem, a mimo to tracić czas, ponieważ dowody znajdują się w jednym narzędziu, decyzje są podejmowane w innym, a działania następcze są realizowane gdzie indziej. Oto jak jeden zespół mógłby przeprowadzić cały wysiłek w ClickUp, wykorzystując przykład nieudanej transakcji z poprzedniej części.

Przygotowania pierwszego dnia

Załóżmy, że po ostatnim wydaniu odsetek nieudanych operacji checkout wzrósł do 4%, a sponsor poprosił zespół „tygrysów” o obniżenie go poniżej 1%. Lider zaczyna od utworzenia folderu o nazwie „Zespół tygrysów ds. nieudanych operacji checkout” w przestrzeni inżynieryjnej. Praca pozostaje w zasięgu zespołu, który przejmie za nią odpowiedzialność po rozwiązaniu zespołu „tygrysów”.

W folderze lider tworzy dokument ClickUp zawierający brief roboczy. Zawiera on warunek zakończenia projektu (poniżej 1% awarii przez 2 pełne tygodnie), punkt odniesienia, wskaźniki powodzenia i zabezpieczające, zakres prac oraz to, co się w nim mieści, a co nie, kto może podejmować jakie decyzje, a także tabela rejestrująca decyzje. Podczas pierwszej sesji roboczej zespół uzgadnia, że najpierw przetestuje nową zależność API płatności. Kierownik zaznacza tę pozycję w dokumencie i przekształca ją w zadanie bez opuszczania briefu.

Tworzenie kolejki hipotez

To pierwsze zadanie trafia do listy o nazwie „Kolejka hipotez”, wraz z każdą inną teorią, którą zespół chce zweryfikować. Statusy na tej liście odpowiadają kategoriom dowodów z kroku 3, z dodatkiem statusu dla zadań w toku: „Podejrzane”, „W trakcie testowania”, „Potwierdzone” i „Wykluczone”. Nieznane elementy mogą pozostać w briefie jako pytania otwarte.

W miarę zakończania testów zadania są przenoszone, a cały zespół może zobaczyć, co jest już wiadome, a co nadal pozostaje w sferze przypuszczeń. Lider dodaje do każdej hipotezy 3 pola niestandardowe: „Wpływ”, „Koszt testu” i „Wynik”. Sortowanie według „Wpływu”, a następnie „Kosztu testu” sprawia, że na górze listy znajdują się teorie, które mogą wyjaśnić najwięcej i których sprawdzenie zajmuje najmniej czasu.

Sprawdź, co już zostało wypróbowane

Zanim inżynierowie przeprowadzą test API, jeden z nich pyta Brain²: „Czy testowaliśmy już wcześniej limity czasu dostawców usług płatniczych?”.

Brain² przeszukuje zadania, dokumenty, czat i połączone aplikacje za pomocą funkcji Enterprise Search i wyświetla podobne dochodzenie sprzed 6 miesięcy wraz z połączonymi źródłami. Zespół zapoznaje się z tym, co zostało wykluczone poprzednim razem, dostosowuje test i wkleja linki do zadania dotyczącego hipotezy, aby historia pozostała z nim połączona.

Unikanie uwzględniania nowych zgłoszeń w dochodzeniu

Pod koniec pierwszego tygodnia osoby spoza zespołu zaczęły zgłaszać powiązane problemy: błąd w wyświetlaniu cen, powolny przepływ ustawień konta. Każda z tych spraw mogłaby łatwo przerodzić się w nowe zadanie.

Kierownik tworzy formularz w ClickUp, który przesyła przesłane zgłoszenia do osobnej listy o nazwie „Parking lot”. Każde zgłoszenie staje się tam osobnym zadaniem, a sponsor przegląda tę listę podczas każdego spotkania, aby zdecydować, czy któreś z nich należy uwzględnić w zakresie projektu.

Zapewnienie sponsorowi jednego miejsca, w którym może znaleźć wszystkie informacje

Sponsor musi podjąć krok, gdy oczekuje się od niego podjęcia decyzji, ale nie musi na bieżąco śledzić przebiegu pozostałej części dochodzenia.

Kierownik dodaje pole wyboru o nazwie „Wymaga decyzji sponsora” i tworzy pulpit nawigacyjny z trzema kartami: jedną dla zadań oczekujących na decyzję sponsora, jedną dla zablokowanych lub zaległych zadań oraz jedną prowadzącą śledzenie wskaźnika niepowodzeń w postaci pola liczbowego. Sponsor otwiera tę stronę przed każdym spotkaniem podsumowującym.

Zautomatyzowanie przypomnień i aktualizacji

W drugim tygodniu zespół wyłącza funkcję dla kont, których dotyczy problem, jako tymczasowe rozwiązanie, a decyzja ta wymaga ponownej oceny za 7 dni. Kierownik ustawia termin wykonania zadania na ten dzień i dodaje automatyzację, która powiadomi właściciela, gdy nadejdzie ten termin.

Informowanie interesariuszy również zaczyna zajmować czas kierownika projektu. „Super Agent” publikuje teraz w każdy Monday i czwartek krótkie podsumowanie, w którym omawia nowe decyzje, przeszkody oraz wszelkie sprawy oczekujące na decyzję sponsora.

Przekazanie pracy

Wskaźnik niepowodzeń utrzymuje się poniżej 1% przez pełne 2 tygodnie, więc zespół spełnił warunek zakończenia działania. Kierownik przenosi pozostałe otwarte zadania na listę zespołu ds. płatności i przydziela je nowym osobom. Ostatni wpis w dzienniku decyzji wskazuje nowego właściciela oraz warunki, które powinny spowodować rozpoczęcie nowego dochodzenia. Następnie kierownik archiwizuje folder.

Ceny ClickUp

Najlepszy zespół „Tiger Team” wie, kiedy należy podjąć krok wycofania się

Zespół „tygrys” stanowi kontrolowany wyjątek. Polega on na tymczasowym skoncentrowaniu wiedzy specjalistycznej, uprawnień i uwagi wokół problemu, z którym zwykła struktura organizacyjna nie jest w stanie poradzić sobie w normalnym tempie.

To sprawia, że zakończenie jest równie ważne jak sama interwencja. Gdy problem zostanie opanowany, zespół powinien być w stanie wycofać się, nie zabierając ze sobą swoich decyzji, dowodów ani niedokończonej pracy. Jeśli organizacja nadal jest zależna od tej samej tymczasowej grupy, aby utrzymać ciągłość działania, oznacza to, że problem uległ zmianie.

Po przekazaniu sprawy pozostaje dokumentacja opisująca, w jaki sposób problem został zrozumiany i rozwiązany. W ClickUp dokumentacja ta pozostaje dostępna do przeszukiwania nawet po zarchiwizowaniu folderu zespołu „tiger”, dzięki czemu kolejny właściciel sprawy może znaleźć brief, hipotezy i dziennik decyzji bez konieczności ich odtwarzania.

Najczęściej zadawane pytania dotyczące zespołów „Tiger Team”

Jak duży powinien być zespół „tiger team”?

Nie ma uniwersalnej liczby członków zespołu. Trzymaj rdzeń zespołu tak mały, jak pozwala na to skala problemu, a następnie angażuj innych specjalistów, gdy potrzebujesz ich wiedzy. Większy skład wiąże się z większym nakładem pracy związanym z komunikacją i planowaniem. Jeśli ktoś musi jedynie dostarczyć dowody lub odpowiedzieć na konkretne pytanie, niekoniecznie musi stać się stałym członkiem zespołu „tiger team”.

Czy zespół „tiger team” może pracować zdalnie?

Tak. Zespół „tiger team” nie musi pracować w tym samym pomieszczeniu. Potrzebuje natomiast szybkiego dostępu do tych samych dowodów, jasnej własności oraz niezawodnego forum do podejmowania decyzji. W przypadku zespołu rozproszonego należy na bieżąco aktualizować dokumentację roboczą, a rozmowy synchroniczne rezerwować na potrzeby podejmowania decyzji, rozwiązywania problemów blokujących lub omawiania dowodów, które mają wpływ na przebieg śledztwa. Dzięki temu różnice stref czasowych nie sprawią, że każda aktualizacja będzie wymagała zorganizowania kolejnego spotkania.

Czy zespół „tiger team” jest częścią metodyki Agile lub Scrum?

Nie. Zespół „tiger team” nie jest formalną rolą, wydarzeniem ani zakresem odpowiedzialności w Scrumie. Oficjalny Przewodnik po Scrumie definiuje zespół Scrumowy jako grupę skupioną wokół właściciela produktu, Scrum Mastera i programistów. Firma stosująca Scrum może jednak utworzyć zespół „tiger team” w celu rozwiązania problemu wykraczającego poza granice istniejących zespołów. Należy jedynie zdecydować, w jaki sposób ta tymczasowa grupa będzie współdziałać z bieżącymi zobowiązaniami w ramach sprintu oraz celami produktu.

Czy zespół „tiger team” musi składać się z ekspertów technicznych?

Nie. Model ten powstał w przemyśle lotniczym i kosmicznym i nadal jest powszechnie stosowany w inżynierii oraz w dziedzinie bezpieczeństwa, ale taka struktura może sprawdzić się wszędzie tam, gdzie trudny problem wymaga skoncentrowanej wiedzy specjalistycznej. Zespół „tygrys” może prowadzić dochodzenie w sprawie oszustwa, przeprojektować proces operacyjny, rozwiązać problem regulacyjny lub zająć się problemem handlowym. Zakres wiedzy specjalistycznej zmienia się w zależności od problemu.

Czy osoby spoza firmy mogą dołączyć do zespołu „tygrysiego”?

Tak. Zewnętrzni specjaliści, dostawcy, konsultanci lub partnerzy z łańcucha dostaw mogą dołączyć do zespołu, jeśli dysponują wiedzą, której brakuje zespołowi wewnętrznemu. Należy zapewnić im taką samą jasność co do zakresu zadań, dostępu, poufności i uprawnień decyzyjnych, jak członkom wewnętrznym. Powinni oni uczestniczyć w pracach, ponieważ dochodzenie wymaga ich wiedzy specjalistycznej, a nie tylko dlatego, że wynik ma wpływ na ich organizację.

Co się stanie, jeśli zespół „tiger team” nie będzie w stanie rozwiązać problemu?

Zespół powinien opuścić organizację, pozostawiając za sobą węższy zakres problemu niż ten, od którego zaczynał. Może to oznaczać zidentyfikowanie tego, co zostało wykluczone, wyodrębnienie pozostałych niewiadomych, udokumentowanie, które działania zakończyły się niepowodzeniem, oraz wskazanie, w jakich obszarach obecny zespół osiągnął limity swojej wiedzy lub uprawnień. Na tej podstawie kierownictwo może zdecydować, czy do wykonania zadania potrzebny jest inny specjalista, więcej czasu, stały właściciel, czy też większa zmiana strukturalna. Nieosiągnięcie pierwotnego warunku zakończenia nie wymazuje wniosków wyciągniętych w trakcie dochodzenia.

Jaka jest różnica między zespołem „tiger team” a zespołem międzyfunkcyjnym?

Termin „międzyfunkcjonalny” opisuje skład zespołu. Termin „zespół tygrys” opisuje powód, dla którego grupa została zebrana, oraz przewidywany czas jej funkcjonowania. Zespół międzyfunkcjonalny może mieć charakter stały i odpowiadać za bieżący produkt, proces lub obszar działalności. Zespół tygrys jest tworzony w celu rozwiązania konkretnego problemu i rozwiązuje się po zakończeniu zadania. Zespół tygrys często ma charakter międzyfunkcjonalny, ale te dwa terminy nie są zamienne.