“Houston, kita punya masalah.”
Kita semua pasti pernah menggunakannya setidaknya sekali. Istilah ini telah menjadi singkatan untuk momen menegangkan ketika sesuatu yang penting mengalami gangguan dan Anda membutuhkan solusi secepatnya.
Di tempat kerja, hal ini biasanya mengacu pada masalah yang memengaruhi beberapa tim. Misalnya, bug yang lolos dari beberapa putaran perbaikan, merusak tiga basis data pelanggan, dan menyebabkan lonjakan volume tiket dukungan. Masalah ini bermula di tim engineering, tetapi kini tim dukungan, produk, dan keberhasilan pelanggan semuanya turut bertanggung jawab atas bagian masing-masing.
Yang Anda butuhkan saat itu adalah tim tiger: kelompok kecil dan sementara yang terdiri dari para ahli yang dikumpulkan untuk menyelesaikan satu masalah yang jelas definisinya dan berisiko tinggi. Ide ini bermula pada tahun 1960-an di bidang dirgantara dan sejak itu menyebar ke bidang teknik, pemerintahan, keamanan, serta operasi sehari-hari.
Namun, seiring berjalannya waktu, istilah ini menjadi meluas hingga mencakup hampir semua rapat mendesak yang melibatkan beberapa pejabat senior. Kami akan menguraikan apa sebenarnya tim tiger itu, dari mana istilah tersebut berasal, dan bagaimana perbedaannya dengan tim tugas (task forces) dan ruang komando (war rooms) yang sering disamakan dengannya.
Ringkasan
Tim Tiger menarik beberapa spesialis dari tugas rutin mereka untuk menyelesaikan satu masalah spesifik yang berisiko tinggi, kemudian mengembalikan tugas tersebut setelah masalah tersebut teratasi. Istilah ini berasal dari industri dirgantara pada tahun 1960-an dan menjadi terkenal setelah misi Apollo 13.
- Gunakan tim ini ketika masalah tersebut memiliki batas akhir yang jelas, melintasi batas tim, dan telah terhenti dalam proses normal
- Lewati saja jika tujuannya tidak jelas, masalah sebenarnya adalah kekurangan tenaga kerja, atau pekerjaan tersebut sudah memiliki penanggung jawab
- Bentuklah tim ini dengan seorang sponsor, seorang pemimpin, para spesialis yang tepat, dan satu orang yang bertugas mencatat log keputusan
- Jalankan tim ini dengan menyepakati kondisi penghentian terlebih dahulu, menguji satu hipotesis pada satu waktu, dan memastikan perbaikan tersebut efektif sebelum membubarkan tim
- Selesaikan proses ini dengan menyerahkan risiko yang masih berlangsung dan pemantauan kepada pemilik tetap yang ditunjuk
Apa Itu Tim Tiger?
Tim Tiger adalah kelompok jangka pendek dengan satu tugas: menyelesaikan satu masalah yang tidak dapat diatasi oleh struktur organisasi saat ini dengan kecepatan yang dibutuhkan.
Struktur lebih penting daripada labelnya. Sebuah "tiger team" memerlukan tujuan yang jelas, keahlian untuk menyelidikinya, dan wewenang yang cukup untuk bertindak tanpa menjadi komite tetap lainnya.
Tim Tiger umumnya memiliki beberapa ciri khas:
- Dibentuk berdasarkan masalah: Anggota dipilih berdasarkan keahlian yang dibutuhkan dalam situasi tersebut, bukan sekadar karena mereka berada di departemen yang sama
- Ruang lingkup yang sempit: Tim ini berfokus pada satu tujuan yang telah ditetapkan, bukan menangani daftar perbaikan terkait yang terus bertambah
- Diberi keleluasaan untuk bertindak cepat: Anggota tim biasanya memiliki kapasitas yang dilindungi, akses lebih cepat ke pengambil keputusan, dan wewenang yang cukup untuk menghindari terjebak dalam siklus persetujuan yang biasa.
Anda dapat melihat struktur ini pada "Tiger Teams" asuransi pengangguran di Departemen Tenaga Kerja AS. Mulai tahun 2021, departemen tersebut mengumpulkan para ahli di bidang pencegahan penipuan, pengalaman pelanggan, asuransi pengangguran, data, dan rekayasa sistem untuk mengevaluasi masalah dalam program-program di masing-masing negara bagian serta merekomendasikan perbaikan jangka pendek. Dalam 24 bulan pertama, tim-tim ini bekerja sama dengan 36 negara bagian.
Namun, tidak semua tim Tiger akan memiliki bentuk yang sama. Beberapa anggota mungkin tetap terlibat sebagian dalam pekerjaan rutin mereka, sementara yang lain mungkin sepenuhnya menjauh darinya.
Dari mana asal istilah “tiger team”?
Istilah ini berasal dari industri dirgantara Amerika pada tahun 1960-an, jauh sebelum istilah tersebut menjadi istilah umum dalam konteks pemecahan masalah bisnis.
Salah satu penggunaan awal yang terdokumentasi muncul dalam makalah SAE tahun 1964 berjudul Program Management in Design and Development oleh J. R. Dempsey, W. A. Davis, A. S. Crossfield, dan Walter C. Williams. Makalah tersebut menggambarkan tim tiger sebagai sekelompok “spesialis teknis yang liar dan tanpa hambatan” yang dipilih berdasarkan pengalaman, energi, dan imajinasi mereka. Tugas mereka adalah tanpa henti mencari kemungkinan sumber kegagalan dalam sistem dan simulasi pesawat luar angkasa.
Dan mereka bukan sekadar para ahli senior yang dikumpulkan dalam satu ruangan. Mereka diharapkan untuk mempertanyakan asumsi-asumsi, menemukan kelemahan yang terlewatkan oleh orang lain, dan bekerja di luar beberapa batasan biasa yang melingkupi suatu program.
Enam tahun kemudian, Apollo 13 memberikan salah satu asosiasi paling terkenal bagi istilah tersebut. Pada 13 April 1970, sebuah tangki oksigen meledak saat pesawat ruang angkasa tersebut berada sekitar 200.000 mil dari Bumi. Jack Swigert menghubungi Pusat Kendali Misi melalui radio, “Houston, kami mengalami masalah di sini,” sebuah kalimat yang kemudian masuk ke dalam budaya populer sebagai “Houston, kami memiliki masalah.”
Direktur Penerbangan NASA , Gene Kranz , kemudian memimpin apa yang dalam catatan NASA disebut sebagai "Tim Tiger" Apollo 13 , bekerja sama dengan Tim Operasi Misi yang lebih luas untuk mengatasi masalah-masalah yang menghalangi para astronot untuk kembali dengan selamat. Tim Operasi Misi Apollo 13 kemudian menerima Medali Kebebasan Presiden atas perannya dalam operasi penyelamatan tersebut.
Misi Apollo 13 membantu mengukuhkan "tiger team" sebagai model pemecahan masalah yang terfokus di bawah tekanan, namun istilah tersebut tidak diciptakan oleh misi tersebut.
Tim Tiger vs. Satuan Tugas, Ruang Komando, Tim Merah, dan Skunkworks
Tim Tiger sering disamakan dengan struktur kelompok lain, seperti satuan tugas, ruang komando, tim merah, dan skunkworks. Meskipun semuanya melibatkan kelompok kecil yang bekerja di luar struktur tim biasa, namun masing-masing dibentuk dengan alasan yang berbeda.
| Struktur | Tugas utama | Apa yang membedakannya | Biasanya berakhir ketika |
|---|---|---|---|
| Tim Tiger | Selesaikan satu masalah yang terbatasi dan berisiko tinggi | Para spesialis dipilih berdasarkan masalah yang dihadapi dan diberi keleluasaan untuk bergerak cepat melintasi batas-batas tim biasa | Hasil yang telah ditetapkan tercapai dan tanggung jawab dikembalikan |
| Tim tugas khusus | Menangani masalah atau inisiatif yang lebih luas | Seringkali tim ini mengoordinasikan pekerjaan lintas beberapa fungsi dan mungkin beroperasi melalui struktur pengambilan keputusan biasa dalam organisasi | Rekomendasinya disampaikan atau inisiatif yang lebih luas telah selesai |
| Ruang komando | Koordinasikan respons terhadap insiden yang sedang berlangsung | Berfokus pada komunikasi yang cepat, pengambilan keputusan, dan pembaruan status saat insiden sedang berlangsung | Situasi saat ini telah stabil |
| Tim Merah | Ungkapkan kelemahan dengan berpikir atau bertindak seperti musuh | Menguji sistem, rencana, atau pertahanan alih-alih bertanggung jawab atas pekerjaan yang diperlukan untuk memperbaiki setiap kelemahan yang ditemukan | Latihan telah selesai dan temuan-temuan telah didokumentasikan |
| Skunkworks | Kembangkan ide, teknologi, atau produk eksperimental | Bekerja dengan tingkat otonomi yang tinggi untuk mengeksplorasi dan mengembangkan sesuatu yang baru, seringkali dalam jangka waktu yang lebih lama | Konsep tersebut ditinggalkan, terbukti berhasil, atau dipindahkan ke dalam organisasi yang lebih permanen |
Kesalahan paling umum adalah mengacaukan "tiger team" dengan "task force" karena keduanya dapat mengumpulkan orang-orang dari berbagai fungsi. Perbedaannya terletak pada mandatnya. Sebuah "task force" mungkin menyelidiki masalah yang luas, mengoordinasikan suatu inisiatif, atau merekomendasikan perubahan. Sebaliknya, "tiger team" biasanya diberi masalah yang lebih spesifik dan kebebasan yang lebih besar untuk menyelesaikannya dengan cepat.
Ruang komando (war room) dimulai dari titik yang berbeda. Ruang ini dibentuk berdasarkan insiden yang sedang berlangsung dan memberikan tempat serta ritme pengambilan keputusan yang terpadu bagi para penanggap insiden. Tim Tiger dapat terbentuk dari ruang komando jika insiden yang sedang terjadi mengungkap masalah yang lebih mendalam yang memerlukan upaya terfokus setelah situasi stabil.
Tim merah (red team) secara sengaja dirancang untuk berperan sebagai pihak lawan. Dalam bidang keamanan siber, misalnya, NIST mendefinisikan tim merah sebagai kelompok yang dibentuk untuk meniru serangan atau kemampuan eksploitasi pihak lawan. Tujuannya adalah menemukan kelemahan dengan menguji sistem. Tim harimau mungkin menggunakan pendekatan serupa, tetapi tanggung jawab utamanya yang lebih luas adalah menyelesaikan masalah yang menjadi alasan pembentukannya.
Skunkworks memiliki pendekatan yang berbeda. Model ini, yang dipopulerkan oleh Skunk Works milik Lockheed Martin, memberikan otonomi yang luar biasa kepada sekelompok kecil orang untuk mengembangkan sesuatu yang baru. Tim Tiger biasanya dibentuk untuk menangani suatu masalah dengan syarat penyelesaian yang jelas. Sementara itu, tim Skunkworks dapat tetap bekerja bersama dalam waktu yang jauh lebih lama selama ide tersebut dieksplorasi, dirancang, dan diuji.
Perbedaan-perbedaan ini penting karena memberi nama yang terdengar lebih mendesak pada sebuah kelompok tidak mengubah cara kerjanya. Sebelum membentuk tim tiger, pertanyaan yang lebih tepat adalah apakah masalah tersebut memang memerlukan struktur khusus tersebut sejak awal.
Kapan Anda Harus Membentuk Tim Tiger?
Tim Tiger cocok digunakan ketika suatu masalah bersifat lintas fungsi, memerlukan masukan dari spesialis, atau terhenti dalam proses normal. Namun, melibatkan spesialis ke dalam tim sementara juga akan mengalihkan mereka dari pekerjaan yang sudah menjadi tanggung jawab mereka.
Sebuah kasus yang baik biasanya lulus empat kriteria:
- Masalahnya memiliki batasan yang jelas: Anda dapat menjelaskan hasil yang dibutuhkan dan menentukan kapan tugas tim telah selesai. “Mengurangi kegagalan checkout di bawah 1%” memberikan target kepada tim. “Meningkatkan keandalan” tidak
- Masalah ini membutuhkan keahlian khusus yang terfokus: Keterampilan yang tepat mungkin tersebar di beberapa tim atau terkonsentrasi dalam satu disiplin ilmu, tetapi model kepemilikan saat ini tidak menyatukan mereka untuk mengatasi tantangan tersebut
- Proses normal telah terhenti atau berjalan terlalu lambat: Beberapa tim mungkin telah mencoba solusi sementara, atau rantai persetujuan yang ada tidak mampu mengikuti tenggat waktu atau konsekuensi yang ada
- Risiko yang dihadapi membenarkan adanya gangguan: Peluncuran yang gagal, tenggat waktu regulasi, kelemahan keamanan, masalah besar dengan pelanggan, atau perubahan sistem berisiko tinggi mungkin memerlukan pengalihan sementara tenaga ahli yang berpengalaman
Model yang sama juga dapat digunakan sebagai langkah pencegahan, sebelum perubahan berisiko tinggi diterapkan ke lingkungan produksi atau diluncurkan.
Kapan tidak perlu membentuk tim tiger
Hindari membentuk tim tiger jika tujuannya masih belum jelas, masalah sebenarnya adalah kekurangan tenaga kerja, atau pekerjaan tersebut sudah memiliki penanggung jawab yang jelas dan dapat diproses melalui prosedur normal. Jika masalah yang sama terus-menerus membutuhkan tim penyelamat sementara, hal itu menandakan perlunya penanggung jawab permanen atau perbaikan struktural.
Apa Saja Peran Utama dalam Tim Tiger?
Tim Tiger tidak memerlukan anggota yang banyak, tetapi setiap orang harus mengetahui tanggung jawab masing-masing. Dalam kebanyakan kasus, Anda akan membutuhkan beberapa peran inti:
- Sponsor: Seorang pemimpin senior yang dapat mengatasi hambatan, menyetujui keputusan dengan cepat, dan memastikan kapan tim telah mencapai kondisi penyelesaiannya
- Pemimpin tim Tiger: Memastikan pekerjaan terus berjalan, mengoordinasikan para spesialis, dan memastikan tim tetap fokus pada masalah yang menjadi tujuan pembentukannya
- Spesialis: Orang-orang yang dipilih berdasarkan keahlian yang dibutuhkan untuk mengatasi masalah tersebut. Komposisinya dapat mencakup bidang teknik, operasional, keamanan, produk, hukum, keuangan, atau fungsi lainnya, tergantung pada masalah yang dihadapi.
- Pemilik catatan keputusan: Mencatat keputusan-keputusan penting, asumsi, temuan, dan opsi yang ditolak agar alasan di balik keputusan tersebut tidak hilang setelah tim dibubarkan
Dalam tim kecil, satu orang dapat mengemban beberapa peran. Kuncinya adalah bahwa wewenang, tanggung jawab operasional sehari-hari, keahlian khusus, dan dokumentasi masing-masing memiliki penanggung jawab yang jelas.
Cara Mengelola Tim Tiger dalam 7 Langkah
Setelah tim terbentuk, pekerjaan tersebut memerlukan struktur yang memadai agar penyelidikan tidak berubah menjadi serangkaian rapat, teori, dan perbaikan yang tidak terkoordinasi. Langkah-langkah berikut ini memandu tim mulai dari sesi kerja pertama hingga tahap validasi dan serah terima.
1. Ubah tujuan menjadi panduan kerja
Setiap tim tiger memerlukan kondisi penutupan: hasil spesifik yang menandakan kepada semua orang bahwa masalah telah terselesaikan dan tim dapat dibubarkan. Sepakati hal tersebut terlebih dahulu, lalu jadikan sebagai pedoman yang dapat digunakan anggota tim untuk mengambil keputusan sehari-hari.
Sebuah ringkasan kerja singkat biasanya sudah cukup. Ringkasan tersebut harus menjawab:
- Hasil apa yang ingin kita ubah?
- Bagaimana kondisi dasar saat ini?
- Bagaimana kita akan mengukur peningkatan tersebut?
- Keterbatasan apa saja yang tidak boleh dilanggar?
- Apa saja yang berada di luar lingkup tim ini?
- Berapa lama hasilnya harus tetap berlaku sebelum kita menyatakan masalah tersebut telah terselesaikan?
Perhatikan dengan saksama pertanyaan terakhir. Bayangkan sebuah tim operasional yang sedang menangani tumpukan pekerjaan yang terus bertambah. Menurunkan antrian menjadi di bawah 500 kasus mungkin terasa seperti kemenangan untuk satu sore. Namun, mempertahankannya di angka tersebut selama seminggu penuh, sementara volume pemrosesan harian terus melampaui jumlah pekerjaan yang masuk, merupakan bukti yang jauh lebih kuat bahwa perbaikan tersebut akan bertahan lama.
Kiat Pro: Padukan metrik keberhasilan utama dengan satu metrik pengaman. Jika Anda sedang mengurangi kegagalan proses checkout, misalnya, lacak juga jumlah pengembalian dana atau tiket dukungan agar satu perbaikan tidak menyembunyikan masalah baru.
Mulailah dengan menunjuk pemimpin, sponsor, para spesialis, dan siapa pun yang akan memperbarui catatan kerja secara berkala. Kemudian, tentukan wewenang pengambilan keputusan sejak awal. Tim dapat mengambil beberapa keputusan secara mandiri, beberapa memerlukan persetujuan sponsor, dan beberapa keputusan lainnya tetap menjadi kewenangan tim yang biasanya bertanggung jawab atasnya.
Tim tersebut juga memerlukan batasan yang jelas terkait pekerjaannya. Sebelum penyelidikan mulai berjalan lancar, tuliskan:
Poin terakhir ini mencegah terjadinya penyimpangan yang signifikan. Penyelidikan terkait pembayaran, misalnya, mungkin mengungkap masalah terkait penetapan harga, pengaturan akun, atau proses onboarding pelanggan. Beberapa di antaranya mungkin layak diperbaiki nanti, tetapi jika semua masalah tersebut dimasukkan ke dalam tugas saat ini, upaya yang semula direncanakan selama dua minggu bisa berubah menjadi dua bulan.
Kapasitas juga memerlukan perhatian yang sama. Alihkan komitmen yang mendesak, geser tenggat waktu jika memungkinkan, dan beritahukan kepada pihak yang terdampak mengenai perubahan yang terjadi. Jika tidak, anggota tim akan berakhir harus menjalankan tim tiger di samping semua tugas yang sudah mereka tangani.
2. Tetapkan peran, wewenang pengambilan keputusan, dan batasan dengan jelas
Mulailah dengan menunjuk pemimpin, sponsor, para spesialis, dan siapa pun yang akan memperbarui catatan kerja secara berkala. Kemudian, tentukan wewenang pengambilan keputusan sejak awal. Tim dapat mengambil beberapa keputusan secara mandiri, beberapa memerlukan persetujuan sponsor, dan beberapa keputusan lainnya tetap menjadi kewenangan tim yang biasanya bertanggung jawab atasnya.
Tim tersebut juga memerlukan batasan yang jelas terkait pekerjaannya. Sebelum penyelidikan mulai berjalan lancar, tuliskan:
- Sistem, tim, atau proses yang boleh diubah oleh kelompok tersebut
- Bidang-bidang yang dapat diselidiki oleh tim tersebut, namun tidak dapat diubah tanpa persetujuan
- Risiko-risiko yang perlu segera dilaporkan ke tingkat atas
- Masalah-masalah terkait yang sebaiknya dicatat dan dibiarkan untuk saat ini
Poin terakhir ini mencegah terjadinya penyimpangan yang signifikan. Penyelidikan terkait pembayaran, misalnya, mungkin mengungkap masalah terkait penetapan harga, pengaturan akun, atau proses onboarding pelanggan. Beberapa di antaranya mungkin layak diperbaiki nanti, tetapi jika semua masalah tersebut dimasukkan ke dalam tugas saat ini, upaya yang semula direncanakan selama dua minggu bisa berubah menjadi dua bulan.
Kapasitas juga memerlukan perhatian yang sama. Alihkan komitmen yang mendesak, geser tenggat waktu jika memungkinkan, dan beritahukan kepada pihak yang terdampak mengenai perubahan yang terjadi. Jika tidak, anggota tim akan berakhir harus mengelola tim tiger di samping semua tugas yang sudah mereka tangani.
3. Pisahkan bukti dari teori, lalu tentukan apa yang akan diuji
Pada saat tim tiger dibentuk, mungkin sudah ada beberapa orang yang memiliki penjelasan mengenai apa yang salah. Mulailah dengan memilah antara apa yang diketahui tim dan apa yang hanya diduga oleh tim.
| Bucket | Apa yang harus ditulis di sini | Contoh |
|---|---|---|
| Telah dikonfirmasi | Temuan yang didukung oleh log, data, dokumen, atau uji coba yang dapat direproduksi | Kegagalan mulai terjadi setelah versi 4.2 dirilis |
| Tersangka | Penjelasan yang masuk akal namun masih perlu diuji | Ketergantungan API baru mungkin menyebabkan peningkatan waktu tunggu |
| Tidak diketahui | Pertanyaan-pertanyaan yang masih perlu dijawab oleh tim | Apakah kegagalan berdampak sama di setiap wilayah |
| Disingkirkan | Penjelasan yang tidak lagi didukung oleh bukti | Kapasitas basis data belum mencapai batasnya |
Tinjau perbaikan sebelumnya, eksperimen, catatan insiden, dan keputusan sebagai bagian dari latihan tersebut. Rute yang tampak menjanjikan hari ini mungkin sudah diuji enam bulan yang lalu. Dari situ, ubah penjelasan terkuat menjadi daftar hipotesis singkat. Untuk masing-masing hipotesis, catat apa yang menurut Anda sedang terjadi, bukti apa yang mendukungnya, bagaimana Anda akan mengujinya, dan apa yang dapat Anda simpulkan dari hasilnya.
Urutkan daftar prioritas berdasarkan apa yang akan Anda pelajari. Sebuah teori yang dapat menjelaskan sebagian besar masalah dan hanya membutuhkan waktu satu jam untuk diuji layak mendapat perhatian lebih dulu daripada teori yang memerlukan satu minggu kerja teknik.
4. Catat keputusan-keputusan yang dapat memengaruhi penyelidikan
Simpan catatan panggilan yang dapat memengaruhi langkah selanjutnya yang akan diambil tim atau yang mungkin perlu dipahami oleh seseorang di kemudian hari. Hal tersebut mungkin mencakup risiko yang diterima, jalur teknis yang ditolak, perubahan ruang lingkup, atau keputusan untuk menghentikan penyelidikan terhadap suatu hipotesis.
| Keputusan | Bukti yang digunakan | Apa yang berubah | Tinjau kembali jika |
|---|---|---|---|
| Nonaktifkan fitur X untuk akun yang terkena dampak | Log kesalahan mengidentifikasi kegagalan pada fitur X | Menghilangkan satu jalur kegagalan sementara pengujian tetap berlanjut | Tingkat kesalahan tetap tidak berubah |
| Uji ketergantungan Y berikutnya | Kegagalan berkorelasi dengan panggilan ke Y | Naikkan Y ke urutan hipotesis | Data regional menyimpang dari pola tersebut |
Tinjau kembali catatan setiap kali bukti baru menantang asumsi sebelumnya, dan pastikan keputusan terkini tetap terlihat bersamaan dengan bukti yang mendasarinya.
5. Biarkan masalah yang menentukan ritme kerja
Frekuensi pertemuan tim tiger bergantung pada seberapa cepat masalah tersebut berubah. Selama gangguan sistem yang sedang berlangsung, tim dapat berkumpul kembali setiap beberapa jam. Penyelidikan selama dua minggu terhadap masalah data yang berkembang lambat biasanya dapat dikelola dengan beberapa kali pertemuan dalam seminggu.
Terlepas dari kecepatannya, setiap rapat harus memiliki tujuan yang jelas. Bukti baru yang mengubah gambaran situasi, hambatan yang hanya dapat diatasi oleh sponsor, atau keputusan yang harus diambil bersama oleh tim, semuanya memenuhi syarat sebagai alasan untuk mengadakan rapat. Kemajuan sehari-hari sebaiknya didokumentasikan dalam catatan tertulis, sehingga orang-orang dapat meninjaunya kapan pun mereka memiliki waktu luang.
Jika pekerjaan berlangsung lebih dari beberapa minggu, jadwalkan tinjauan tengah proses. Hal ini memberi kesempatan kepada tim untuk mengambil jarak sejenak dari penyelidikan sehari-hari dan bertanya:
- Apakah diagnosis awal masih berlaku?
- Apakah cakupan penyelidikan telah meluas sejak tim tersebut dibentuk?
- Apakah masih ada cukup waktu untuk menyelesaikan pekerjaan yang tersisa?
Jawaban yang jujur pada tahap ini dapat mencegah tim menghabiskan paruh kedua waktunya untuk menangani masalah yang salah.
Para pemangku kepentingan biasanya tidak perlu terlibat langsung dalam proses ini. Sebuah catatan tertulis singkat setiap beberapa hari, yang mencakup apa yang telah dipelajari tim, keputusan apa yang telah diambil, dan di mana tim mengalami kendala, cukup untuk menjaga mereka tetap terinformasi sehingga dapat turun tangan saat diperlukan.
6. Berikan waktu bagi solusi tersebut untuk membuktikan keefektifannya
Sebuah perbaikan mungkin terlihat meyakinkan pada hari peluncurannya, namun tetap bisa gagal begitu lalu lintas normal, volume, atau kasus-kasus khusus kembali terjadi. Itulah mengapa tim tidak boleh menyatakan masalah telah teratasi begitu angka-angka menunjukkan perbaikan.
Lamanya pemantauan terhadap perbaikan bergantung pada seberapa sering masalah tersebut berpotensi muncul kembali. Misalnya, layanan dengan volume tinggi mungkin memberikan sinyal yang dapat diandalkan dalam hitungan jam. Penutupan keuangan bulanan mungkin memerlukan satu siklus penuh lagi sebelum dapat dipastikan bahwa perbaikan tersebut telah berhasil.
Sambil menunggu, perhatikan dua angka berikut:
- Metrik keberhasilan: Mengukur peningkatan dibandingkan dengan garis dasar yang tercantum dalam ringkasan kerja
- Metrik pengaman: Menunjukkan apakah perbaikan yang dilakukan menimbulkan masalah baru di tempat lain
Jika angka-angka mulai bergeser kembali, anggaplah itu sebagai bukti baru. Masukkan ke dalam penyelidikan dan lihat apa yang berubah. Hal itu mungkin akan menggeser hipotesis lain ke urutan teratas, atau mengungkapkan bahwa diagnosis awal hanya menjelaskan sebagian dari apa yang salah.
7. Serahkan pekerjaan kembali dengan rapi
Pada tahap ini, tim telah menyiapkan sebagian besar hal yang diperlukan untuk serah terima. Ringkasan kerja, bukti, hasil pengujian, catatan keputusan, dan data validasi semuanya sudah tercatat dalam berkas. Menulis ulang semua itu menjadi laporan penutupan yang rapi hanya akan menambah beban kerja tanpa memberikan manfaat yang berarti.
Sebaliknya, kumpulkan catatan-catatan tersebut dan pastikan kepemilikan yang tersisa tidak mungkin terlewatkan. Pemilik permanen harus meninggalkan proses ini dengan mengetahui:
- Apa saja yang masih perlu dipantau, dan untuk berapa lama
- Risiko apa saja yang masih terbuka
- Tugas apa saja yang belum selesai yang kini menjadi tanggung jawab mereka
- Kondisi apa saja yang seharusnya memicu penyelidikan lain
Sebelum ada yang pergi, jawablah: Siapa yang akan dihubungi jika masalah tersebut muncul kembali?
Setelah hasil dicapai dan keputusan diambil, tim tiger dapat dibubarkan. Anggota kembali ke tugas rutin mereka, tanggung jawab yang sedang berjalan dikembalikan ke struktur normal, dan hasil penyelidikan tetap tercatat untuk siapa pun yang membutuhkannya di kemudian hari.
Tim Tiger Reaktif vs. Preventif
Tim Tiger biasanya dilibatkan pada salah satu dari dua tahap. Beberapa di antaranya dibentuk setelah suatu masalah sudah berdampak pada bisnis. Yang lainnya dilibatkan lebih awal, saat masih ada waktu untuk mengidentifikasi titik-titik lemah dan mengubah rencana.
Perbedaannya terletak pada apa yang ingin dipelajari oleh tim tersebut.
Tim Tiger reaktif dimulai dengan masalah yang sudah terjadi
Inilah versi yang paling sering dikaitkan orang dengan tim Tiger. Bisa jadi peluncuran yang tertunda, gangguan yang berulang, proses kritis yang terhenti, atau beberapa tim yang mencoba memperbaiki masalah tanpa menemukan akar penyebabnya.
Pada tahap itu, tim tiger telah memiliki bukti sebagai dasar kerja. Tugasnya adalah menghubungkan sinyal-sinyal tersebut, mempersempit penyebab akar masalah, menguji penjelasan yang paling kuat, dan mengembalikan sistem ke keadaan stabil.
Mencapai tahap ini bisa jadi mahal. Dalam Survei Pusat Data Global 2025 dari Uptime Institute, 87% responden yang pernah mengalami gangguan yang berdampak besar dalam tiga tahun terakhir mengatakan bahwa hal tersebut sebenarnya bisa dihindari dengan manajemen, proses, atau konfigurasi yang lebih baik.
Laporan Analisis Gangguan Tahunan 2026 mereka juga menemukan bahwa 57% responden menyatakan gangguan besar terbaru mereka menelan biaya lebih dari $100.000, sementara satu dari lima responden memperkirakan biayanya melebihi $1 juta. Angka-angka ini spesifik untuk pusat data, sehingga tidak boleh dianggap sebagai tolok ukur universal untuk setiap tim Tiger.
Namun, hal ini menunjukkan mengapa pekerjaan setelah intervensi reaktif tidak boleh berhenti pada perbaikan sementara. Setelah situasi stabil, perhatikan kondisi-kondisi yang memungkinkan masalah berkembang sejauh itu.
Tim Tiger preventif berupaya mendeteksi masalah lebih dini
Tim Tiger preventif mulai dibentuk saat masih ada ruang untuk mengubah rencana.
NASA telah menerapkan pendekatan ini secara langsung. Ketika Pusat Teknik dan Keselamatan (Engineering and Safety Center) NASA membentuk tim penilaian untuk meninjau sistem propulsi pesawat ruang angkasa CALIPSO, tim tersebut membuat pohon kegagalan (fault tree) guna menganalisis jalur kegagalan yang mungkin terjadi sebelum peluncuran. Dalam tinjauan retrospektif NASA mengenai 15 tahun berdirinya Pusat Teknik dan Keselamatan, Direktur NESC Tim Wilson menggambarkan pendekatan tersebut sebagai:
Pendekatan kami adalah menyusun pohon kegagalan yang menunjukkan segala hal yang berpotensi salah, serta menentukan apakah kontrol yang tepat telah diterapkan selama proses pembuatan untuk memastikan sambungan-sambungan tersebut tidak bocor.
Pendekatan kami adalah menyusun pohon kegagalan yang menunjukkan segala hal yang berpotensi salah, serta menentukan apakah kontrol yang tepat telah diterapkan selama proses pembuatan untuk memastikan sambungan-sambungan tersebut tidak bocor.
Itu mendekati semangat tim Tiger di era awal industri dirgantara. Tim tersebut diberi tugas yang berakibat besar dan diminta untuk menguji tugas tersebut sebelum konsekuensinya muncul.
Hasilnya harus memberikan proyek secara keseluruhan sesuatu yang konkret untuk ditindaklanjuti, seperti:
- Skenario kegagalan yang perlu diuji sebelum peluncuran
- Ketergantungan yang terlewatkan dalam rencana awal
- Pemantauan yang harus dilakukan sejak hari pertama
- Tentukan dengan jelas kondisi rollback atau eskalasi
- Risiko yang telah ditinjau oleh pimpinan dan diputuskan untuk diterima
Contoh Tim Tiger di Dunia Nyata
Tim Tiger sering ditemukan di sektor konstruksi, perangkat lunak, dan pemerintahan. Graham, Grafana Labs, dan Otoritas Penanggulangan Penipuan Sektor Publik Inggris masing-masing membentuk tim tersebut untuk menangani masalah yang terdefinisi dengan jelas dan memiliki batas waktu penyelesaian yang pasti. Keahlian yang dibutuhkan bervariasi dari satu kasus ke kasus lainnya, sementara struktur timnya tetap sama.
Graham berhasil memangkas waktu pemasangan batang pengikat sebesar 51%
Kontraktor teknik sipil Graham membentuk tim tiger untuk menangani bagian proyek South Bank Quay yang bersifat berulang namun mahal. Para pekerja harus memasang 166 batang pengikat, masing-masing berpanjang lebih dari 38 meter dan berfungsi mengikat dinding dermaga ke dinding jangkar.
Tim tersebut terdiri dari staf proyek Graham, subkontraktor pemasangan, produsen batang pengikat, dan mitra rantai pasokan lainnya. Mereka pertama-tama memetakan proses pemasangan, kemudian mengukur pekerjaan di lokasi menggunakan rekaman time-lapse dan studi waktu dan gerakan. Setelah mendapatkan data acuan, mereka mengubah proses tersebut dan mengukurnya kembali.
Menurut studi kasus Get It Right Initiative, waktu pemasangan berkurang dari 185 menit menjadi 91 menit per tie rod, atau penurunan sekitar 51%, sementara jumlah tugas berkurang sebesar 37%. Graham juga melaporkan penghematan waktu 14 hari dalam program tersebut serta penghematan biaya yang diperkirakan sebesar £230.000.
Tim tersebut menemukan perubahan-perubahan kecil di seluruh proses, mengujinya pada pekerjaan yang sama, dan dapat menunjukkan dengan tepat apa yang telah membaik.
Grafana Labs mengubah masalah rilis menjadi tanggung jawab permanen
Rilis open-source Grafana Labs semakin banyak dilakukan secara manual, sementara tanggung jawab untuk memperbaikinya tersebar di beberapa tim insinyur. Tiga insinyur senior yang sebelumnya telah menangani sebagian masalah tersebut dikumpulkan selama satu kuartal untuk menyederhanakan alur kerja, mengotomatiskan proses build, dan mendukung penerapan patch langsung untuk saluran Grafana Cloud.
Tim Tiger Rilis secara drastis memangkas langkah-langkah manual dan membuat proses rilis keamanan menjadi lebih mudah ditangani. Pada akhir kuartal, upaya tersebut juga telah memperjelas celah jangka panjang yang cukup signifikan sehingga Grafana dapat membentuk tim rilis khusus.
Proses tersebut membantu mengatasi masalah-masalah yang berulang dalam manajemen rilis perangkat lunak. Intervensi singkat dapat menyelesaikan gesekan yang terjadi saat itu juga sekaligus menunjukkan di mana letak tanggung jawab berkelanjutan. Grafana telah menerapkan model yang sama di bidang lain, termasuk tim tiger yang membantu mendapatkan mitra utama.
Pemerintah Inggris menggunakan tim tiger sebelum risiko penipuan berubah menjadi kerugian
Pada tahun 2022, Otoritas Penipuan Sektor Publik Inggris (Public Sector Fraud Authority) menerapkan model "tiger team" saat skema dukungan energi baru masih dalam tahap perancangan.
Tim tersebut terdiri dari para ahli penipuan dari kementerian pemerintah, Ofgem, badan penyelesaian energi, serta pakar eksternal dari sektor energi. Menurut laporan tahunan Public Sector Fraud Authority tahun 2022–23, tim tersebut telah menyelesaikan penilaian dampak dan risiko penipuan pada enam skema energi baru di Departemen Bisnis, Energi, dan Strategi Industri serta satu skema di Departemen Keuangan Kerajaan Inggris.
Pekerjaan dimulai cukup awal sehingga tim program dapat menindaklanjuti temuan para spesialis. BEIS menyatakan bahwa beragam keahlian tersebut membantu memasukkan pertimbangan terkait penipuan ke dalam skema-skema tersebut dan memberikan gambaran kepada para menteri mengenai risiko-risiko utama saat program-program tersebut masih dalam tahap pengembangan.
Lima Kesalahan yang Dapat Menghambat Kinerja Tim Tiger
Lima kesalahan ini dapat melemahkan tim Tiger, bahkan ketika masalah dan struktur tim sudah jelas.
1. Mengubah beberapa hal sekaligus
Ketika tekanan tinggi, seringkali tergoda untuk menggabungkan tiga atau empat solusi yang menjanjikan sekaligus dan melihat apakah masalahnya hilang.
Hal itu dapat membantu Anda mencapai hasil yang lebih baik dengan cepat, tetapi meninggalkan pertanyaan yang membingungkan: Perbaikan mana yang berhasil? Jika tim Tiger bidang teknik memperbarui dependensi, mengubah batas waktu, dan meningkatkan kapasitas dalam rilis yang sama, penurunan jumlah kegagalan tidak memberikan banyak petunjuk mengenai penyebabnya. Hal ini juga mempersulit proses rollback jika masalah lain muncul di kemudian hari.
Solusinya: Jika memungkinkan, lakukan perubahan secara berurutan sehingga Anda dapat mengamatinya. Catat apa yang berubah dan apa yang terjadi sebelum menerapkan intervensi berikutnya. Untuk kasus mendesak di mana perubahan harus diterapkan secara bersamaan, dokumentasikan paket perubahan tersebut agar Anda dapat memisahkan dan menguji bagian-bagiannya setelah tekanan mendesak telah berlalu.
2. Membentuk tim sepenuhnya dari orang luar
Perspektif baru memang bisa membantu, tetapi orang-orang yang bekerja dengan sistem yang bersangkutan setiap hari sering kali mengetahui pengecualian, solusi sementara, dan ketergantungan yang tidak pernah tercantum dalam dokumentasi. Mengabaikan hal-hal tersebut dapat menghasilkan solusi yang tampak rapi dari luar namun gagal begitu diterapkan dalam alur kerja yang sebenarnya.
Hal ini berlaku tidak hanya di bidang teknik. Sebagai contoh, tim tiger yang merancang ulang proses persetujuan sebaiknya mendengarkan masukan dari orang-orang yang menangani persetujuan tersebut setiap hari, bukan hanya para pemimpin yang mengawasinya.
Solusinya: Libatkan setidaknya satu orang yang terlibat dalam pekerjaan sehari-hari, atau libatkan mereka sejak awal penyelidikan. Tanyakan di mana proses yang terdokumentasi berbeda dengan apa yang dilakukan orang-orang dalam praktiknya.
3. Mengubah tim tiger menjadi ajang saling menyalahkan
Begitu orang-orang merasa bahwa tim tiger sedang berusaha mengidentifikasi siapa yang menyebabkan masalah, mereka mungkin menjadi lebih berhati-hati dalam membagikan informasi. Seseorang mungkin tidak menyebutkan keputusan buruk yang pernah diambilnya sebelumnya, menghindari menyebut solusi sementara yang gagal, atau membela keputusan lama karena merasa bertanggung jawab secara pribadi atas hal tersebut. Hal ini membuat tim memiliki lebih sedikit bukti dan menyulitkan penemuan penyebab sebenarnya.
Solusinya: Pastikan tinjauan tetap berfokus pada keputusan, sistem, dan kondisi. Jika terdapat masalah kinerja atau perilaku yang terpisah, tangani melalui proses yang sesuai, bukan dengan menggabungkannya ke dalam penyelidikan tim tiger.
4. Melakukan perubahan berisiko tanpa merencanakan cara membatalkannya
Solusi yang menjanjikan dapat menimbulkan kegagalan baru tersendiri. Tim akan menghadapi masalah jika mereka merencanakan cara menerapkan perubahan tetapi tidak merencanakan cara membatalkannya. Proses rollback juga menjadi lebih sulit setelah pelanggan, data, atau sistem hilir mulai berinteraksi dengan perubahan tersebut.
Solusinya: Sebelum melakukan intervensi berisiko tinggi, tentukan bagaimana Anda akan membatalkan intervensi tersebut, bukti apa yang akan memicu pembatalan tersebut, dan siapa yang berwenang mengambil keputusan. Uji jalur pembatalan ketika konsekuensi dari kesalahan sangat besar.
5. Membuat sumber kebenaran kedua untuk tim Tiger
Pekerjaan mendesak sering kali dimulai di mana pun orang dapat bergerak paling cepat: obrolan pribadi, spreadsheet ad hoc, dokumen sementara, atau papan proyek terpisah. Masalah mulai muncul ketika keputusan, bukti, dan tugas tersebar di seluruh platform tersebut.
Seseorang melihat keputusan terbaru di obrolan, sementara orang lain masih mengikuti keputusan lama di spreadsheet. Setelah tim dibubarkan, merekonstruksi apa yang terjadi menjadi semakin sulit.
Solusinya: Tentukan satu tempat untuk keputusan terkini, penanggung jawab, dan status pekerjaan. Alat-alat lain masih dapat menyimpan log, analisis, atau percakapan, tetapi semuanya harus merujuk kembali ke catatan kerja yang sama ketika terjadi perubahan.
Cara Mengelola Tim Tiger di ClickUp
Sebuah tim tiger mungkin memiliki anggota yang tepat dan arahan yang jelas, namun tetap bisa kehilangan waktu karena bukti tersimpan di satu alat, keputusan diambil di alat lain, dan pekerjaan lanjutan dilakukan di tempat lain. Berikut adalah cara sebuah tim dapat mengelola seluruh proses tersebut di ClickUp, menggunakan contoh kegagalan checkout yang telah disebutkan sebelumnya.
Persiapan pada hari pertama
Misalkan tingkat kegagalan checkout telah meningkat menjadi 4% setelah rilis terbaru, dan sponsor telah meminta tim tiger untuk menurunkannya kembali di bawah 1%. Pemimpin tim memulai dengan membuat folder bernama “Tim tiger kegagalan checkout” di dalam ruang kerja engineering. Pekerjaan tersebut tetap berada di bawah pengawasan tim yang akan mengelolanya setelah tim tiger dibubarkan.
Di dalam Folder, pemimpin tim membuat Dokumen ClickUp untuk ringkasan kerja. Dokumen tersebut memuat syarat penyelesaian (tingkat kegagalan di bawah 1% selama 2 minggu penuh), garis dasar, metrik keberhasilan dan batasan, apa saja yang termasuk dan tidak termasuk dalam cakupan, siapa yang berwenang mengambil keputusan apa, serta tabel log keputusan. Selama sesi kerja pertama, tim sepakat untuk menguji ketergantungan API pembayaran baru terlebih dahulu. Pemimpin tim menyoroti baris tersebut di Dokumen dan mengubahnya menjadi Tugas tanpa meninggalkan ringkasan kerja.

Membuat antrian hipotesis
Tugas pertama tersebut dimasukkan ke dalam daftar yang disebut antrian hipotesis, bersama dengan setiap teori lain yang ingin diuji oleh tim. Status daftar tersebut mengikuti kategori bukti dari langkah 3, dengan satu status tambahan untuk pekerjaan yang sedang berlangsung: Dicurigai, Sedang Diuji, Terkonfirmasi, dan Tereliminasi. Hal-hal yang belum diketahui dapat dicantumkan dalam ringkasan sebagai pertanyaan terbuka.
Seiring selesainya pengujian, tugas-tugas berpindah, dan seluruh tim dapat melihat apa yang sudah diketahui dan apa yang masih berupa dugaan. Pemimpin tim menambahkan 3 Bidang Kustom ke setiap hipotesis: Dampak, Biaya pengujian, dan Hasil. Dengan mengurutkan berdasarkan Dampak dan kemudian Biaya pengujian, teori-teori yang paling mungkin menjelaskan masalah dan paling cepat diverifikasi akan muncul di bagian atas.
Memeriksa apa yang sudah pernah dicoba
Sebelum para insinyur menjalankan uji API, salah satu di antara mereka bertanya kepada Brain²: “Apakah kita sudah pernah menguji batas waktu penyedia pembayaran sebelumnya?”
Brain² mencari Tugas, Dokumen, Obrolan, dan aplikasi terhubung melalui Enterprise Search, dan menemukan penyelidikan serupa dari 6 bulan lalu, lengkap dengan sumber-sumber yang tertaut. Tim membaca apa yang telah dikesampingkan pada penyelidikan sebelumnya, menyesuaikan tes, dan menempelkan tautan-tautan tersebut ke dalam Tugas hipotesis agar riwayatnya tetap tertaut padanya.

Mencegah permintaan baru masuk ke dalam penyelidikan
Pada akhir minggu pertama, orang-orang di luar tim mulai mengemukakan masalah terkait: bug pada tampilan harga, alur pembuatan akun yang lambat. Masing-masing masalah tersebut dapat dengan mudah berubah menjadi pekerjaan baru.
Pemimpin tim membuat Formulir ClickUp yang mengirimkan data ini ke Daftar terpisah bernama "Parking lot". Setiap pengajuan akan menjadi Tugas tersendiri di sana, dan sponsor meninjau Daftar tersebut pada setiap sesi check-in untuk memutuskan apakah ada hal yang termasuk dalam ruang lingkup.
Memberikan sponsor satu tempat untuk melihat
Sponsor perlu turun tangan ketika ada keputusan yang menunggu keputusan mereka, tetapi mereka tidak perlu mengikuti proses penyelidikan lainnya secara harian.
Pemimpin tim menambahkan kolom centang berlabel “Membutuhkan keputusan sponsor” dan membuat dasbor dengan 3 kartu: satu untuk Tugas yang menunggu keputusan sponsor, satu untuk pekerjaan yang terhambat atau terlambat, dan satu lagi untuk melacak tingkat kegagalan sebagai kolom angka. Sponsor membuka halaman tersebut sebelum setiap sesi check-in.
Panduan ini menunjukkan cara membuat dasbor proyek berdasarkan sinyal-sinyal yang perlu diperhatikan:
Biarkan pengingat dan pembaruan berjalan secara otomatis
Pada minggu ke-2, tim menonaktifkan suatu fitur untuk akun-akun yang terdampak sebagai solusi sementara, dan keputusan tersebut perlu dievaluasi kembali dalam 7 hari. Pemimpin tim menetapkan tanggal jatuh tempo Tugas tersebut pada hari itu dan menambahkan Otomatisasi yang memberi tahu pemiliknya saat tanggal tersebut tiba.
Pembaruan kepada pemangku kepentingan juga mulai menyita waktu pemimpin tim. Seorang Super Agent kini memposting ringkasan singkat setiap Senin dan Kamis, yang mencakup keputusan baru, hambatan, dan hal-hal yang masih menunggu persetujuan dari sponsor.

Menyerahkan kembali pekerjaan
Tingkat kegagalan tetap di bawah 1% selama 2 minggu penuh, sehingga tim telah memenuhi syarat untuk keluar. Pemimpin tim memindahkan Tugas yang masih terbuka ke Daftar tim pembayaran dan menugaskan ulang tugas-tugas tersebut. Entri terakhir dalam log keputusan mencantumkan pemilik baru dan kondisi yang harus dipenuhi untuk memulai penyelidikan baru. Kemudian, pemimpin tim mengarsipkan Folder tersebut.
Harga ClickUp
Batasan penggunaannya: ClickUp tidak akan menggantikan sistem yang menghasilkan bukti. Jika tim Tiger Anda menangani gangguan produksi, simpan log, peringatan, dan telemetri real-time di alat pemantauan atau penanganan insiden yang dirancang khusus untuk itu. Pindahkan keputusan, pekerjaan tindak lanjut, dan konteksnya ke ClickUp agar tim yang lebih luas dapat menindaklanjutinya.
Cocok untuk: Tim Tiger yang beroperasi selama beberapa hari atau minggu, terutama ketika beberapa orang menguji ide, mengambil keputusan, menganalisis konteks dari pekerjaan sebelumnya, dan menyerahkan hasilnya kepada pemilik tetap.
Tim Tiger Terbaik Tahu Kapan Harus Mundur
Tim Tiger adalah pengecualian yang terkendali. Anda secara sementara memusatkan keahlian, wewenang, dan perhatian pada suatu masalah yang tidak dapat ditangani oleh struktur biasa dengan kecepatan normalnya.
Hal itu menjadikan tahap penutupan sama pentingnya dengan tahap intervensi. Setelah masalah terkendali, tim harus dapat mundur tanpa membawa serta keputusan, bukti, atau pekerjaan yang belum selesai. Jika organisasi masih bergantung pada kelompok sementara yang sama untuk menjaga kelancaran operasional, berarti masalahnya telah berubah.
Yang tersisa setelah serah terima adalah catatan mengenai bagaimana masalah tersebut dipahami dan diselesaikan. Di ClickUp, catatan tersebut tetap dapat dicari meskipun Folder tim tiger telah diarsipkan, sehingga pemilik berikutnya dapat menemukan ringkasan, hipotesis, dan catatan keputusan tanpa harus menyusunnya kembali.
Pertanyaan yang Sering Diajukan tentang Tim Tiger
Seberapa besar seharusnya ukuran tim Tiger?
Tidak ada jumlah anggota yang baku. Pertahankan kelompok inti sesedikit mungkin sesuai dengan skala masalah, lalu libatkan spesialis lain saat Anda membutuhkan keahlian mereka. Jumlah anggota yang lebih besar akan menambah beban komunikasi dan penjadwalan. Jika seseorang hanya perlu memberikan bukti atau menjawab pertanyaan tertentu, ia tidak perlu menjadi anggota tetap tim Tiger.
Apakah tim tiger dapat bekerja dari jarak jauh?
Ya. Tim Tiger tidak perlu berada di ruangan yang sama secara fisik. Yang dibutuhkan adalah akses cepat ke bukti yang sama, kepemilikan yang jelas, dan tempat yang andal untuk pengambilan keputusan. Untuk tim yang tersebar, pastikan catatan kerja selalu diperbarui dan gunakan panggilan sinkron hanya untuk pengambilan keputusan, hambatan, atau bukti yang mengubah arah penyelidikan. Hal ini mencegah perbedaan zona waktu mengubah setiap pembaruan menjadi rapat tambahan.
Apakah tim tiger merupakan bagian dari Agile atau Scrum?
Tidak. Tim Tiger bukanlah peran, acara, atau tanggung jawab formal dalam Scrum. Panduan Scrum resmi mendefinisikan Tim Scrum sebagai tim yang terdiri dari Product Owner, Scrum Master, dan Pengembang. Perusahaan yang menerapkan Scrum tetap dapat membentuk tim Tiger untuk menangani masalah yang melintasi batas-batas tim yang sudah ada. Anda hanya perlu memutuskan bagaimana kerja sementara tersebut berinteraksi dengan komitmen Sprint saat ini dan Tujuan Produk.
Apakah tim tiger harus bersifat teknis?
Tidak. Model ini awalnya muncul di bidang kedirgantaraan dan masih umum digunakan di bidang teknik dan keamanan, tetapi struktur ini dapat diterapkan di mana pun ada masalah sulit yang memerlukan keahlian khusus yang terkonsentrasi. Sebuah "tiger team" dapat menyelidiki kasus penipuan, merancang ulang proses operasional, menyelesaikan masalah regulasi, atau menangani masalah komersial. Keahlian yang dibutuhkan akan berbeda-beda sesuai dengan masalah yang dihadapi.
Apakah orang di luar perusahaan dapat bergabung dengan tim Tiger?
Ya. Spesialis eksternal, vendor, konsultan, atau mitra rantai pasokan dapat bergabung jika mereka memiliki pengetahuan yang tidak dimiliki oleh tim internal. Berikan mereka kejelasan yang sama mengenai ruang lingkup, akses, kerahasiaan, dan hak pengambilan keputusan seperti halnya anggota internal. Mereka harus terlibat karena penyelidikan membutuhkan keahlian mereka, bukan sekadar karena organisasi mereka terpengaruh oleh hasilnya.
Apa yang terjadi jika tim tiger tidak dapat menyelesaikan masalah tersebut?
Tim tersebut tetap harus meninggalkan organisasi dengan masalah yang lebih terfokus daripada saat awal. Hal itu mungkin berarti mengidentifikasi hal-hal yang telah dikesampingkan, mengisolasi hal-hal yang masih belum diketahui, mendokumentasikan intervensi mana yang gagal, dan menunjukkan di mana tim saat ini telah mencapai batas keahlian atau wewenangnya. Dari situ, pimpinan dapat memutuskan apakah pekerjaan tersebut memerlukan spesialis yang berbeda, waktu tambahan, penanggung jawab tetap, atau perubahan struktural yang lebih besar. Kegagalan mencapai kondisi akhir yang semula tidak menghapus apa yang telah dipelajari dari penyelidikan tersebut.
Apa perbedaan antara tim tiger dan tim lintas fungsi?
Istilah “lintas fungsi” menggambarkan siapa saja yang menjadi anggota tim. Istilah “tim harimau” menggambarkan alasan dibentuknya kelompok tersebut dan berapa lama kelompok tersebut diperkirakan akan ada. Tim lintas fungsi dapat bersifat permanen dan bertanggung jawab atas produk, proses, atau bidang bisnis yang sedang berjalan. Tim harimau dibentuk untuk menangani masalah tertentu dan dibubarkan setelah tugas tersebut selesai. Tim harimau sering kali bersifat lintas fungsi, tetapi kedua istilah tersebut tidak dapat digunakan secara bergantian.
