"Tiger Team" là gì? Định nghĩa, nguồn gốc và khi nào nên sử dụng

“Houston, chúng ta gặp sự cố rồi.”

Tất cả chúng ta đều đã từng sử dụng thuật ngữ này ít nhất một lần. Nó đã trở thành cách nói tắt cho khoảnh khắc căng thẳng khi một thứ quan trọng gặp sự cố và bạn cần khắc phục ngay lập tức.

Trong công việc, điều này thường ám chỉ một vấn đề ảnh hưởng đến nhiều nhóm. Chẳng hạn như lỗi phần mềm đó, dù đã trải qua nhiều đợt sửa chữa nhưng vẫn tồn tại, làm hỏng ba cơ sở dữ liệu của khách hàng và khiến số lượng phiếu hỗ trợ tăng vọt. Vấn đề này bắt đầu từ bộ phận kỹ thuật, nhưng giờ đây các bộ phận hỗ trợ, sản phẩm và thành công khách hàng đều phải chịu trách nhiệm một phần về nó.

Điều bạn cần ngay lúc này chính là một "Tiger Team": một nhóm chuyên gia nhỏ, tạm thời, được tập hợp lại để giải quyết một vấn đề cụ thể, có tầm quan trọng cao. Ý tưởng này bắt nguồn từ những năm 1960 trong lĩnh vực hàng không vũ trụ và từ đó đã lan rộng sang các lĩnh vực kỹ thuật, chính phủ, bảo mật và các hoạt động hàng ngày.

Tuy nhiên, theo thời gian, nhãn này đã bị mở rộng để chỉ gần như bất kỳ cuộc họp khẩn cấp nào có sự tham gia của một vài lãnh đạo cấp cao. Chúng tôi sẽ phân tích chi tiết "nhóm Tiger" thực sự là gì, nguồn gốc của nhãn này, và sự khác biệt giữa nó với các "nhóm tác chiến" (task forces) và "phòng chỉ huy khẩn cấp" (war rooms) – những khái niệm thường bị nhầm lẫn với nó.

"Tiger Team" là gì?

"Tiger team" là một nhóm làm việc ngắn hạn với một nhiệm vụ duy nhất: giải quyết một vấn đề mà cơ cấu hiện tại không thể khắc phục với tốc độ cần thiết.

Cấu trúc quan trọng hơn nhãn. Một nhóm "Tiger" cần có mục tiêu rõ ràng, chuyên môn để điều tra vấn đề đó và đủ thẩm quyền để hành động mà không trở thành một ủy ban thường trực khác.

Các "Nhóm Tiger" thường chia sẻ một số đặc điểm chung:

Bạn có thể thấy cấu trúc này trong các "Tiger Teams" về bảo hiểm thất nghiệp của Bộ Lao động Hoa Kỳ. Kể từ năm 2021, bộ này đã tập hợp các chuyên gia về phòng chống gian lận, trải nghiệm khách hàng, bảo hiểm thất nghiệp, dữ liệu và kỹ thuật hệ thống để đánh giá các vấn đề trong các chương trình của từng bang và đề xuất các cải tiến trong ngắn hạn. Trong 24 tháng đầu tiên, các nhóm này đã hợp tác với 36 bang.

Tuy nhiên, không phải mọi "Tiger Team" nào cũng giống nhau. Một số thành viên có thể vẫn tham gia một phần vào công việc thường ngày của họ, trong khi những người khác có thể tạm thời rời khỏi công việc đó hoàn toàn.

Thuật ngữ “tiger team” có nguồn gốc từ đâu?

Thuật ngữ này có nguồn gốc từ ngành hàng không vũ trụ Mỹ vào những năm 1960, rất lâu trước khi nó trở thành thuật ngữ phổ biến trong lĩnh vực giải quyết vấn đề kinh doanh.

Một trong những lần sử dụng thuật ngữ này được ghi chép sớm nhất xuất hiện trong bài báo của Hiệp hội Kỹ sư Ô tô (SAE) năm 1964 có tiêu đề “Quản lý Chương trình trong Thiết kế và Phát triển” của các tác giả J. R. Dempsey, W. A. Davis, A. S. Crossfield và Walter C. Williams. Bài báo mô tả “đội Tiger” là một nhóm “các chuyên gia kỹ thuật không bị ràng buộc và không e dè”, được lựa chọn dựa trên kinh nghiệm, năng lượng và sự sáng tạo của họ. Nhiệm vụ của họ là không ngừng tìm kiếm các nguyên nhân tiềm ẩn gây thất bại trong các hệ thống tàu vũ trụ và mô phỏng.

Và đây không chỉ đơn thuần là việc tập hợp các chuyên gia cấp cao trong một phòng. Họ được kỳ vọng sẽ đặt câu hỏi về các giả định, phát hiện những điểm yếu mà người khác đã bỏ qua, và thực hiện công việc vượt ra ngoài một số ràng buộc thông thường xung quanh một chương trình.

Sáu năm sau, sứ mệnh Apollo 13 đã gắn liền thuật ngữ này với một trong những sự kiện nổi tiếng nhất. Vào ngày 13 tháng 4 năm 1970, một bình oxy đã phát nổ khi tàu vũ trụ đang ở cách Trái Đất khoảng 200.000 dặm. Jack Swigert đã liên lạc qua radio với Trung tâm Điều khiển Nhiệm vụ: “Houston, chúng tôi gặp sự cố ở đây,” một câu nói sau này đã trở thành câu nói nổi tiếng trong văn hóa đại chúng: “Houston, chúng tôi gặp sự cố.”

Giám đốc bay của NASA , Gene Kranz , sau đó đã dẫn dắt nhóm được các tài liệu của NASA mô tả là “Tiger Team” của sứ mệnh Apollo 13 , tham gia vào công việc điều hành sứ mệnh rộng hơn để giải quyết những vấn đề cản trở các phi hành gia trở về an toàn. Đội Điều hành Sứ mệnh Apollo 13 sau đó đã được trao Huân chương Tự do của Tổng thống vì vai trò của họ trong chiến dịch cứu hộ này.

Chuyến bay Apollo 13 đã góp phần khẳng định "nhóm Tiger" như một mô hình giải quyết vấn đề tập trung dưới áp lực, nhưng chính chuyến bay này không phải là người đặt ra thuật ngữ này.

"Nhóm Tiger" so với "Task Force", "War Room", "Red Team" và "Skunkworks"

Các "Tiger team" thường bị nhầm lẫn với các cấu trúc nhóm khác, chẳng hạn như nhóm tác chiến (task forces), phòng chỉ huy khẩn cấp (war rooms), nhóm đối kháng (red teams) và nhóm nghiên cứu đặc biệt (skunkworks). Mặc dù tất cả đều có thể bao gồm các nhóm nhỏ hoạt động ngoài cấu trúc nhóm thông thường, nhưng chúng được thành lập vì những lý do khác nhau.

Sự nhầm lẫn phổ biến nhất là giữa "Tiger Team" và "Task Force" vì cả hai đều có thể tập hợp các thành viên từ nhiều bộ phận khác nhau. Điểm khác biệt nằm ở nhiệm vụ được giao. Một "Task Force" có thể điều tra một vấn đề rộng lớn, điều phối một sáng kiến hoặc đề xuất các thay đổi. Trong khi đó, "Tiger Team" thường được giao giải quyết một vấn đề hẹp hơn và có nhiều tự do hơn để thực hiện công việc một cách nhanh chóng.

Phòng chỉ huy khẩn cấp (war room) lại bắt đầu từ một bối cảnh khác. Nó được thiết lập xung quanh một sự cố đang diễn ra và cung cấp cho những người ứng phó một không gian chia sẻ cùng nhịp độ nhất quán để ra quyết định. Một "Tiger Team" có thể hình thành từ phòng chỉ huy khẩn cấp nếu sự cố trước mắt bộc lộ một vấn đề sâu xa hơn, đòi hỏi phải tập trung vào công việc sau khi tình hình đã ổn định.

Đội "Red Team" có tính đối kháng rõ rệt hơn. Ví dụ, trong lĩnh vực an ninh mạng, NIST định nghĩa đội "Red Team" là một nhóm được tổ chức nhằm mô phỏng các khả năng tấn công hoặc khai thác của đối thủ. Mục tiêu là tìm ra các lỗ hổng bằng cách thử thách hệ thống. Đội "Tiger Team" có thể áp dụng cách tiếp cận tương tự, nhưng trách nhiệm rộng hơn của nó là giải quyết vấn đề cụ thể mà đội được thành lập để xử lý.

Mô hình "skunkworks" lại đi theo hướng khác. Mô hình này, được Lockheed Martin’s Skunk Works làm nổi tiếng, trao cho một nhóm nhỏ quyền tự chủ đặc biệt để phát triển những điều mới mẻ. Các đội Tiger thường được thành lập để giải quyết một vấn đề cụ thể với điều kiện kết thúc rõ ràng. Trong khi đó, các đội skunkworks có thể duy trì hoạt động cùng nhau trong thời gian dài hơn để nghiên cứu, thiết kế và thử nghiệm một ý tưởng.

Những điểm khác biệt này rất quan trọng vì việc đặt cho một nhóm một cái tên nghe có vẻ khẩn cấp hơn không làm thay đổi cách thức hoạt động của nhóm đó. Trước khi thành lập một "Tiger Team", câu hỏi quan trọng hơn là liệu vấn đề có thực sự đòi hỏi phải áp dụng cấu trúc cụ thể đó ngay từ đầu hay không.

Khi nào bạn nên thành lập một "Tiger Team"?

Việc thành lập một "Tiger Team" là hợp lý khi vấn đề mang tính liên chức năng, cần sự tham gia của các chuyên gia hoặc đã bị đình trệ trong quy trình thông thường. Tuy nhiên, việc huy động các chuyên gia vào một nhóm tạm thời cũng đồng nghĩa với việc họ phải tạm gác lại công việc mà họ đang phụ trách.

Một vụ án tốt thường phải vượt qua bốn tiêu chí:

Mô hình này cũng có thể được áp dụng như một biện pháp phòng ngừa, trước khi một thay đổi có rủi ro cao được đưa vào môi trường sản xuất hoặc ra mắt.

Các vai trò chính trong một "Tiger Team" là gì?

Một "Nhóm Tiger" không cần có đội hình quá đông, nhưng mỗi thành viên cần phải rõ ràng về trách nhiệm của mình. Trong hầu hết các trường hợp, bạn sẽ cần một số vai trò cốt lõi:

Trong một nhóm nhỏ, một người có thể đảm nhận nhiều vai trò khác nhau. Điều quan trọng là quyền hạn, quyền sở hữu hàng ngày, chuyên môn chuyên sâu và việc lập hồ sơ đều phải được phân công rõ ràng cho từng bộ phận cụ thể.

Cách điều hành một "Tiger Team" trong 7 bước

Khi nhóm đã được thành lập, công việc cần có đủ cấu trúc để tránh việc điều tra biến thành một chuỗi các cuộc họp, giả thuyết và các biện pháp khắc phục rời rạc. Các bước sau đây sẽ dẫn dắt nhóm từ phiên làm việc đầu tiên cho đến giai đoạn xác thực và bàn giao.

1. Chuyển đổi đối tượng thành bản tóm tắt công việc

Mỗi "Nhóm Tiger" đều cần có một điều kiện kết thúc: kết quả cụ thể báo hiệu cho tất cả mọi người rằng vấn đề đã được giải quyết và nhóm có thể giải tán. Hãy thống nhất về điều này trước tiên, sau đó biến nó thành một tiêu chí mà mọi người có thể sử dụng để định hướng các quyết định hàng ngày của mình.

Một bản tóm tắt công việc ngắn gọn thường là đủ. Bản tóm tắt này cần trả lời các câu hỏi sau:

Hãy đặc biệt chú ý đến câu hỏi cuối cùng. Hãy hình dung một nhóm vận hành đang phải đối phó với lượng công việc tồn đọng ngày càng tăng. Việc giảm số lượng hồ sơ tồn đọng xuống dưới 500 có thể được coi là một thành công trong một buổi chiều. Tuy nhiên, việc duy trì con số đó trong suốt một tuần, trong khi khối lượng xử lý hàng ngày vẫn vượt quá lượng công việc mới đến, mới là bằng chứng thuyết phục hơn nhiều cho thấy giải pháp này sẽ mang lại hiệu quả lâu dài.

2. Xác định rõ vai trò, quyền ra quyết định và phạm vi trách nhiệm

Bắt đầu bằng việc chỉ định người đứng đầu, người bảo trợ, các chuyên gia và người chịu trách nhiệm cập nhật hồ sơ công việc. Sau đó, cần xác định rõ quyền ra quyết định ngay từ đầu. Nhóm có thể tự đưa ra một số quyết định, một số cần sự phê duyệt của người bảo trợ, và một số vẫn thuộc thẩm quyền của các nhóm vốn chịu trách nhiệm về chúng.

Nhóm cũng cần có ranh giới rõ ràng về phạm vi công việc của mình. Trước khi cuộc điều tra bắt đầu diễn ra sôi nổi, hãy ghi lại:

Điểm cuối cùng này giúp tránh được nhiều sự lệch hướng. Ví dụ, một cuộc điều tra về thanh toán có thể phát hiện ra các vấn đề liên quan đến định giá, thiết lập tài khoản hoặc quy trình tiếp nhận khách hàng. Một số vấn đề trong số đó có thể đáng để khắc phục sau này, nhưng nếu gộp tất cả vào nhiệm vụ hiện tại, thì nỗ lực dự kiến kéo dài hai tuần sẽ biến thành hai tháng.

Sức chứa cũng cần được quan tâm tương tự. Hãy phân công lại các nhiệm vụ khẩn cấp, điều chỉnh thời hạn khi có thể và thông báo cho các bên liên quan về những thay đổi. Nếu không, các thành viên trong nhóm sẽ phải điều hành "đội Tiger" bên cạnh tất cả các công việc họ đang đảm nhận.

3. Tách biệt bằng chứng khỏi các giả thuyết, sau đó quyết định những gì cần kiểm chứng

Khi nhóm Tiger được thành lập, có thể đã có nhiều người đưa ra lời giải thích về nguyên nhân sự cố. Hãy bắt đầu bằng việc phân biệt rõ những gì nhóm đã biết với những gì nhóm chỉ mới nghi ngờ.

Trong quá trình này, hãy rà soát lại các biện pháp khắc phục trước đây, các thử nghiệm, ghi chú về sự cố và các quyết định đã đưa ra. Một phương án có vẻ hứa hẹn ngày hôm nay có thể đã được thử nghiệm từ sáu tháng trước. Từ đó, hãy chọn ra những giả thuyết thuyết phục nhất để đưa vào danh sách các giả thuyết ngắn. Đối với mỗi giả thuyết, hãy ghi lại những gì bạn cho là đang xảy ra, bằng chứng nào hỗ trợ cho giả thuyết đó, cách bạn sẽ kiểm chứng nó và kết quả sẽ cho bạn biết điều gì.

Sắp xếp thứ tự ưu tiên dựa trên những gì bạn có thể học được. Một giả thuyết có thể giải thích phần lớn vấn đề và chỉ mất một giờ để kiểm chứng xứng đáng được ưu tiên hơn so với một giả thuyết đòi hỏi một tuần công việc kỹ thuật.

4. Lưu giữ hồ sơ về các quyết định có thể ảnh hưởng đến quá trình điều tra

Lưu lại các cuộc gọi có thể ảnh hưởng đến việc cần làm tiếp theo của nhóm hoặc những thông tin mà ai đó có thể cần hiểu rõ sau này. Điều này có thể bao gồm một rủi ro đã được chấp nhận, một phương án kỹ thuật bị từ chối, một thay đổi phạm vi công việc, hoặc quyết định ngừng theo đuổi một giả thuyết.

Hãy rà soát lại hồ sơ mỗi khi có bằng chứng mới làm lung lay giả định trước đó, và luôn hiển thị quyết định hiện tại cùng với bằng chứng làm cơ sở cho quyết định đó.

5. Hãy để vấn đề cài đặt nhịp độ công việc

Tần suất cuộc họp của nhóm Tiger phụ thuộc vào tốc độ thay đổi của vấn đề. Trong trường hợp hệ thống ngừng hoạt động thực tế, nhóm có thể họp lại sau mỗi vài giờ. Đối với một cuộc điều tra kéo dài hai tuần về một vấn đề dữ liệu diễn biến chậm, thường chỉ cần một vài lần kiểm tra tiến độ mỗi tuần là đủ.

Dù tiến độ có như thế nào, mỗi cuộc họp cũng cần có mục đích rõ ràng. Những bằng chứng mới làm thay đổi bức tranh tổng thể, một trở ngại mà chỉ người bảo trợ mới có thể giải quyết, hoặc một quyết định mà cả nhóm phải cùng nhau đưa ra đều là những lý do hợp lệ. Tiến độ hàng ngày nên được ghi chép chi tiết trong biên bản, để mọi người có thể xem lại bất cứ khi nào rảnh rỗi.

Nếu công việc kéo dài hơn vài tuần, hãy lên lịch một buổi đánh giá giữa chừng. Điều này giúp nhóm có cơ hội tạm gác lại công việc điều tra hàng ngày và tự hỏi:

Những câu trả lời trung thực ở giai đoạn này có thể giúp nhóm tránh phải dành nửa sau của quá trình để giải quyết vấn đề sai lầm.

Các bên liên quan thường không cần tham gia trực tiếp vào quá trình này. Một ghi chú ngắn gọn bằng văn bản được gửi vài ngày một lần, nêu rõ những gì nhóm đã tìm hiểu, những quyết định đã đưa ra và những điểm còn vướng mắc, sẽ giúp họ nắm bắt tình hình đủ để can thiệp khi cần thiết.

6. Cho giải pháp thời gian để chứng minh hiệu quả của nó

Một bản sửa lỗi có thể trông thuyết phục vào ngày nó được triển khai nhưng vẫn có thể sụp đổ khi lưu lượng truy cập bình thường, khối lượng dữ liệu hoặc các trường hợp ngoại lệ quay trở lại. Đó là lý do tại sao nhóm không nên tuyên bố vấn đề đã được giải quyết ngay khi số chỉ số cải thiện.

Thời gian theo dõi hiệu quả của biện pháp khắc phục phụ thuộc vào tần suất vấn đề có khả năng tái phát. Ví dụ, một dịch vụ có lưu lượng cao có thể cung cấp tín hiệu đáng tin cậy chỉ trong vài giờ. Trong khi đó, việc đóng sổ tài chính hàng tháng có thể cần thêm một chu kỳ đầy đủ nữa trước khi có thể khẳng định rằng biện pháp khắc phục đã phát huy hiệu quả.

Trong khi chờ đợi, hãy giữ hai số trong chế độ xem:

Nếu các số bắt đầu có xu hướng giảm dần, hãy coi đó là bằng chứng mới. Đưa nó vào quá trình điều tra và xem nó sẽ thay đổi điều gì. Điều này có thể đưa một giả thuyết khác lên hàng đầu trong danh sách ưu tiên, hoặc tiết lộ rằng chẩn đoán ban đầu chỉ giải thích được một phần của vấn đề đang xảy ra.

7. Bàn giao công việc một cách rõ ràng

Đến thời điểm này, nhóm đã chuẩn bị sẵn hầu hết các tài liệu cần thiết cho việc bàn giao. Bản tóm tắt công việc, bằng chứng, các bài kiểm tra, nhật ký quyết định và dữ liệu xác thực đều đã được lưu trữ trong hồ sơ. Việc viết lại chúng thành một báo cáo kết thúc hoàn chỉnh chỉ làm tăng thêm công việc mà không mang lại nhiều giá trị khác.

Thay vào đó, hãy tập hợp các hồ sơ đó lại và làm cho quyền sở hữu còn lại trở nên không thể bỏ qua. Người sở hữu vĩnh viễn nên rời đi với sự hiểu biết rằng:

Trước khi ai đó bước đi, hãy trả lời câu hỏi: Ai sẽ là người nhận cuộc gọi nếu vấn đề tái phát?

Khi đã đạt được kết quả và câu trả lời được xác định, "Nhóm Tiger" có thể giải tán. Các thành viên quay trở lại công việc thường ngày, các trách nhiệm đang diễn ra được chuyển giao trở lại cơ cấu tổ chức thông thường, và hồ sơ điều tra được lưu giữ để phục vụ cho những ai cần đến trong tương lai.

Nhóm Tiger phản ứng so với nhóm Tiger phòng ngừa

Các nhóm Tiger thường được triển khai tại một trong hai thời điểm. Một số được thành lập khi vấn đề đã bắt đầu ảnh hưởng đến hoạt động kinh doanh. Số khác được đưa vào sớm hơn, khi vẫn còn thời gian để phát hiện các điểm yếu và điều chỉnh kế hoạch.

Sự khác biệt nằm ở mục tiêu mà nhóm đang cố gắng tìm hiểu.

Các nhóm "Tiger" phản ứng bắt đầu từ một vấn đề đã đang diễn ra

Đây là phiên bản mà hầu hết mọi người thường liên tưởng đến khi nhắc đến "nhóm Tiger". Đó có thể là một đợt ra mắt sản phẩm bị trì hoãn, một sự cố ngừng hoạt động lặp đi lặp lại, một quy trình quan trọng bị gián đoạn, hoặc nhiều nhóm đang cố gắng khắc phục sự cố mà không tìm ra nguyên nhân gốc rễ.

Lúc đó, "Nhóm Tiger" đã có bằng chứng để thực hiện công việc. Nhiệm vụ của họ là kết nối các dấu hiệu đó, thu hẹp nguyên nhân gốc rễ, kiểm chứng các giả thuyết hợp lý nhất và đưa hệ thống trở lại trạng thái ổn định.

Việc đạt đến giai đoạn này có thể tốn kém. Trong Khảo sát Trung tâm Dữ liệu Toàn cầu năm 2025 của Uptime Institute, 87% số người được hỏi từng trải qua sự cố ngừng hoạt động có tác động lớn trong ba năm qua cho biết sự cố đó có thể đã được tránh nếu có quản lý, quy trình hoặc cấu hình tốt hơn.

Báo cáo Phân tích Sự cố Hàng năm 2026 của họ cũng chỉ ra rằng 57% số người được hỏi cho biết sự cố lớn gần đây nhất của họ gây thiệt hại hơn 100.000 USD, trong khi 1/5 số người được hỏi ước tính chi phí lên tới trên 1 triệu USD. Những con số này chỉ áp dụng cụ thể cho các trung tâm dữ liệu, do đó không nên coi chúng là tiêu chuẩn chung cho mọi "Tiger Team".

Tuy nhiên, những trường hợp này cho thấy tại sao công việc sau một biện pháp can thiệp phản ứng không nên dừng lại ở việc khắc phục ngay lập tức. Khi tình hình đã ổn định, hãy xem xét các điều kiện đã khiến vấn đề trở nên nghiêm trọng đến mức đó.

Các nhóm Tiger phòng ngừa tìm kiếm các vấn đề tiềm ẩn từ sớm

Một nhóm phòng ngừa được thành lập khi vẫn còn thời gian để điều chỉnh kế hoạch.

NASA đã áp dụng trực tiếp phương pháp này. Khi Trung tâm Kỹ thuật và An toàn (Engineering and Safety Center) của NASA thành lập một nhóm đánh giá để xem xét hệ thống động cơ của tàu vũ trụ CALIPSO, nhóm này đã xây dựng một sơ đồ cây lỗi để phân tích các đường dẫn hỏng hóc có thể xảy ra trước khi phóng. Trong bài tổng kết 15 năm hoạt động của Trung tâm Kỹ thuật và An toàn, Giám đốc NESC Tim Wilson đã mô tả phương pháp này như sau:

Cách tiếp cận của chúng tôi là xây dựng một sơ đồ cây lỗi (fault tree) để chỉ ra mọi sự cố có thể xảy ra và xác định xem các biện pháp kiểm soát thích hợp đã được áp dụng trong quá trình lắp ráp hay chưa, nhằm đảm bảo các mối nối đó không bị rò rỉ.

Điều đó gần gũi với tinh thần của nhóm Tiger trong ngành hàng không vũ trụ thời kỳ đầu. Nhóm được giao một nhiệm vụ quan trọng và được yêu cầu xem xét kỹ lưỡng trước khi hậu quả xảy ra.

Kết quả thu được nên mang lại cho dự án tổng thể những hành động cụ thể để thực hiện, chẳng hạn như:

Ví dụ về "Tiger Team" trong thực tế

Các nhóm Tiger xuất hiện trong lĩnh vực xây dựng, phần mềm và chính phủ. Graham, Grafana Labs và Cơ quan Chống Gian lận Khu vực Công của Vương quốc Anh đều đã thành lập một nhóm Tiger để giải quyết một vấn đề cụ thể với mục tiêu rõ ràng. Chuyên môn cần thiết thay đổi tùy theo từng trường hợp, trong khi cấu trúc của nhóm vẫn giữ nguyên.

Graham đã giảm 51% thời gian lắp đặt thanh nối

Nhà thầu xây dựng dân dụng Graham đã thành lập một "nhóm Tiger" để xử lý một phần công việc lặp đi lặp lại nhưng tốn kém trong dự án South Bank Quay của mình. Các đội thi công phải lắp đặt 166 thanh giằng, mỗi thanh dài hơn 38 mét và dùng để neo tường cầu cảng vào tường neo.

Nhóm này bao gồm nhân viên dự án của Graham, nhà thầu phụ lắp đặt, nhà sản xuất thanh giằng và các đối tác khác trong chuỗi cung ứng. Đầu tiên, họ lập bản đồ quy trình lắp đặt, sau đó đo lường công việc tại công trường bằng cách sử dụng các đoạn phim quay theo thời gian và nghiên cứu thời gian và chuyển động. Sau khi có được mức cơ sở, họ thay đổi quy trình và đo lường lại.

Theo nghiên cứu điển hình của Sáng kiến Get It Right, thời gian lắp đặt đã giảm từ 185 phút xuống còn 91 phút cho mỗi thanh giằng, tương đương mức giảm khoảng 51%, trong khi số công việc giảm 37%. Graham cũng báo cáo rằng chương trình đã tiết kiệm được 14 ngày và ước tính tiết kiệm được 230.000 bảng Anh.

Nhóm đã phát hiện ra những thay đổi nhỏ trong toàn bộ quy trình, thử nghiệm chúng trên cùng một công việc và có thể chỉ ra chính xác những điểm nào đã được cải thiện.

Grafana Labs đã biến một vấn đề liên quan đến việc phát hành thành quyền sở hữu lâu dài

Các bản phát hành mã nguồn mở của Grafana Labs ngày càng phụ thuộc nhiều vào thao tác thủ công, trong khi trách nhiệm cải tiến chúng lại được phân tán giữa nhiều nhóm kỹ sư. Ba kỹ sư cấp cao, những người đã và đang giải quyết một phần của vấn đề này, đã được tập hợp lại trong một quý để đơn giản hóa quy trình công việc, tự động hóa việc xây dựng và hỗ trợ việc vá lỗi trực tiếp cho các kênh Grafana Cloud.

Nhóm Tiger Team phụ trách phát hành đã cắt giảm đáng kể các bước thực hiện thủ công và giúp việc quản lý các bản phát hành bảo mật trở nên dễ dàng hơn. Đến cuối quý, công việc này cũng đã làm rõ một khoảng trống dài hạn đủ để Grafana thành lập một nhóm phát hành chuyên trách.

Tiến độ này giúp giải quyết các vấn đề thường gặp trong quản lý phát hành phần mềm. Một biện pháp can thiệp ngắn hạn có thể giải quyết những mâu thuẫn trước mắt đồng thời chỉ ra trách nhiệm lâu dài thuộc về ai. Grafana đã áp dụng mô hình tương tự ở các lĩnh vực khác, bao gồm một "Nhóm Tiger" đã góp phần thu hút được một đối tác lớn.

Chính phủ Anh đã sử dụng một nhóm "Tiger" trước khi các rủi ro gian lận trở thành tổn thất

Năm 2022, Cơ quan Chống Gian lận Khu vực Công của Vương quốc Anh đã áp dụng mô hình "Tiger Team" trong khi các chương trình hỗ trợ năng lượng mới vẫn đang được thiết kế.

Nhóm này quy tụ các chuyên gia chống gian lận từ các bộ, ngành của chính phủ, Ofgem, các cơ quan giải quyết tranh chấp trong lĩnh vực năng lượng, cùng các chuyên gia bên ngoài ngành năng lượng. Theo báo cáo thường niên năm 2022–23 của Cơ quan Chống Gian lận Khu vực Công, nhóm đã hoàn thành việc đánh giá tác động và rủi ro gian lận đối với sáu chương trình năng lượng mới thuộc Bộ Kinh doanh, Năng lượng và Chiến lược Công nghiệp, cùng một chương trình thuộc Bộ Tài chính Hoàng gia.

Công việc được bắt đầu đủ sớm để các nhóm chương trình có thể thực hiện các biện pháp dựa trên những phát hiện của các chuyên gia. BEIS cho biết phạm vi chuyên môn đa dạng này đã giúp lồng ghép các yếu tố phòng chống gian lận vào các chương trình và giúp các bộ trưởng nắm bắt được các rủi ro chính ngay từ khi các chương trình vẫn đang trong giai đoạn hình thành.

Năm sai lầm có thể làm hỏng hoạt động của một "Tiger Group"

Năm sai lầm này có thể làm suy yếu một "Tiger Team" ngay cả khi vấn đề và cấu trúc nhóm đã được xác định rõ ràng.

1. Thay đổi nhiều thứ cùng một lúc

Khi áp lực gia tăng, người ta thường có xu hướng áp dụng cùng lúc ba hoặc bốn giải pháp hứa hẹn để xem liệu vấn đề có được giải quyết hay không.

Cách làm này có thể giúp bạn đạt được kết quả tốt hơn một cách nhanh chóng, nhưng lại để lại một câu hỏi khó giải đáp: Giải pháp nào đã phát huy tác dụng? Nếu một nhóm kỹ thuật cập nhật một phụ thuộc, thay đổi thời gian chờ và tăng sức chứa trong cùng một bản phát hành, thì việc giảm số lượng lỗi xảy ra sẽ không cho bạn biết nhiều về nguyên nhân. Điều này cũng khiến việc khôi phục lại phiên bản trước trở nên khó khăn hơn nếu một vấn đề khác phát sinh sau này.

2. Thành lập nhóm hoàn toàn từ những người bên ngoài

Một góc nhìn mới có thể hữu ích, nhưng những người làm việc trực tiếp với hệ thống bị ảnh hưởng hàng ngày thường nắm rõ các trường hợp ngoại lệ, giải pháp tạm thời và các mối phụ thuộc mà chưa bao giờ được ghi vào tài liệu. Việc bỏ qua những yếu tố này có thể dẫn đến các giải pháp trông có vẻ hoàn hảo từ bên ngoài nhưng lại thất bại ngay khi đối mặt với quy trình làm việc thực tế.

Điều này không chỉ áp dụng trong lĩnh vực kỹ thuật. Ví dụ, một nhóm "Tiger" tái thiết kế quy trình phê duyệt nên lắng nghe ý kiến từ những người trực tiếp xử lý các phê duyệt đó hàng ngày, chứ không chỉ từ các nhà lãnh đạo giám sát quy trình.

3. Biến "Tiger Team" thành một cuộc truy cứu trách nhiệm

Khi mọi người cảm thấy rằng "Tiger Team" đang cố gắng xác định ai là người gây ra vấn đề, họ có thể trở nên thận trọng hơn trong việc chia sẻ thông tin. Ai đó có thể bỏ qua một quyết định sai lầm mà họ đã đưa ra trước đó, tránh đề cập đến một giải pháp tạm thời không thành công, hoặc bảo vệ một quyết định cũ vì họ cảm thấy mình phải chịu trách nhiệm cá nhân về điều đó. Điều này khiến nhóm có ít bằng chứng hơn và làm cho việc tìm ra nguyên nhân thực sự trở nên khó khăn hơn.

4. Thực hiện một thay đổi rủi ro mà không có kế hoạch để đảo ngược nó

Một giải pháp hứa hẹn có thể lại gây ra một lỗi mới. Các nhóm thường gặp rắc rối khi họ lập kế hoạch triển khai một thay đổi nhưng lại không tính đến cách đảo ngược nó. Việc đảo ngược cũng trở nên khó khăn hơn khi khách hàng, dữ liệu hoặc các hệ thống hạ lưu đã bắt đầu tương tác với thay đổi đó.

5. Tạo ra một nguồn thông tin đáng tin cậy thứ hai cho nhóm Tiger

Công việc khẩn cấp thường bắt đầu ở bất kỳ nơi nào mọi người có thể hành động nhanh nhất: một cuộc trò chuyện riêng tư, một bảng tính tạm thời, một tài liệu tạm thời hoặc một bảng dự án riêng biệt. Vấn đề nảy sinh khi các quyết định, bằng chứng và công việc bị phân tán khắp các kênh này.

Một người nhìn thấy quyết định mới nhất trong cuộc trò chuyện, trong khi người khác lại thực hiện theo quyết định cũ trong bảng tính. Sau khi nhóm đã đóng công việc, việc tái hiện lại những gì đã xảy ra trở nên càng khó khăn hơn.

Cách quản lý một "Tiger Team" trong ClickUp

Một "Tiger Team" có thể có nhóm phù hợp và bản tóm tắt nhiệm vụ rõ ràng, nhưng vẫn có thể lãng phí thời gian vì bằng chứng được lưu trữ trong một công cụ, quyết định được đưa ra trong một công cụ khác, và công việc theo dõi lại nằm ở một nơi khác. Dưới đây là cách một nhóm có thể điều hành toàn bộ nỗ lực này trong ClickUp, sử dụng ví dụ về lỗi thanh toán từ phần trước.

Cài đặt trong ngày đầu tiên

Giả sử tỷ lệ lỗi checkout đã tăng lên 4% sau một bản phát hành gần đây, và người tài trợ đã yêu cầu nhóm Tiger giảm tỷ lệ này xuống dưới 1%. Người dẫn dắt bắt đầu bằng cách tạo một thư mục có tên “Nhóm Tiger xử lý lỗi checkout” bên trong không gian kỹ thuật. Công việc này sẽ được giao cho nhóm sẽ chịu trách nhiệm chính sau khi nhóm Tiger giải thể.

Trong thư mục, trưởng nhóm tạo một tài liệu ClickUp Doc để làm bản tóm tắt công việc. Tài liệu này bao gồm điều kiện kết thúc (tỷ lệ lỗi dưới 1% trong 2 tuần liên tiếp), mức cơ sở, các chỉ số thành công và chỉ số an toàn, những gì nằm trong và ngoài phạm vi, ai có quyền ra quyết định nào, cùng với bảng ghi chép quyết định. Trong phiên làm việc đầu tiên, nhóm thống nhất sẽ kiểm thử sự phụ thuộc vào API thanh toán mới trước tiên. Người dẫn dắt đánh dấu dòng đó trong tài liệu và chuyển nó thành một Công việc mà không cần rời khỏi bản tóm tắt.

Xây dựng danh sách các giả thuyết

Công việc đầu tiên đó sẽ được đưa vào một danh sách gọi là "Hàng đợi giả thuyết", cùng với mọi giả thuyết khác mà nhóm muốn kiểm chứng. Các trạng thái của danh sách này tuân theo các nhóm bằng chứng từ bước 3, với một trạng thái bổ sung dành cho công việc đang tiến hành: "Nghi ngờ", "Đang kiểm chứng", "Đã xác nhận" và "Đã loại trừ". Các yếu tố chưa rõ có thể được ghi trong bản tóm tắt dưới dạng các câu hỏi mở.

Khi các thử nghiệm hoàn tất, các Công việc sẽ được chuyển tiếp, và toàn bộ nhóm có thể thấy những gì đã được xác định và những gì vẫn chỉ là phỏng đoán. Người dẫn dắt thêm 3 Trường Tùy chỉnh vào mỗi giả thuyết: Tác động, Chi phí thử nghiệm và Kết quả. Sắp xếp theo Tác động rồi đến Chi phí thử nghiệm sẽ đưa các giả thuyết có khả năng giải thích nhiều nhất và mất ít thời gian nhất để kiểm tra lên đầu danh sách.

Kiểm tra những gì đã được thử trước đó

Trước khi các kỹ sư tiến hành kiểm thử API, một trong số họ hỏi Brain²: “Chúng ta đã từng kiểm thử thời gian chờ của nhà cung cấp dịch vụ thanh toán chưa?”

Brain² tìm kiếm trong các mục Nhiệm vụ, Tài liệu, Trò chuyện và các ứng dụng kết nối thông qua Tìm kiếm Doanh nghiệp, và phát hiện ra một cuộc điều tra tương tự từ 6 tháng trước, kèm theo các nguồn tham khảo được liên kết. Nhóm xem lại những gì đã bị loại trừ lần trước, điều chỉnh thử nghiệm và dán các liên kết vào Nhiệm vụ giả thuyết để lịch sử vẫn được gắn liền với nó.

Tránh để các yêu cầu mới lọt vào quá trình điều tra

Đến cuối tuần thứ 1, những người bên ngoài nhóm đã bắt đầu nêu ra các vấn đề liên quan: lỗi hiển thị giá, luồng thiết lập tài khoản chậm chạp. Mỗi vấn đề này đều có thể dễ dàng biến thành công việc mới.

Người phụ trách sẽ cài đặt một biểu mẫu ClickUp để gửi các bài nộp/gửi này vào một danh sách riêng biệt có tên là "Parking lot". Mỗi bài nộp/gửi sẽ trở thành một công việc riêng biệt trong danh sách đó, và người tài trợ sẽ xem xét danh sách này tại mỗi buổi kiểm tra tiến độ để quyết định xem có bài nộp/gửi nào thuộc phạm vi dự án hay không.

Cung cấp cho nhà tài trợ một nơi duy nhất để theo dõi

Người tài trợ cần can thiệp khi có quyết định đang chờ họ phê duyệt, nhưng họ không cần phải theo dõi sát sao quá trình điều tra hàng ngày.

Người phụ trách thêm một trường ô chọn có tên “Cần quyết định của người bảo trợ” và tạo một bảng điều khiển với 3 thẻ: một thẻ dành cho các Công việc đang chờ quyết định của người bảo trợ, một thẻ dành cho công việc bị tắc nghẽn hoặc quá hạn, và một thẻ đang theo dõi tỷ lệ thất bại dưới dạng trường số. Người bảo trợ mở trang đó trước mỗi lần báo cáo tiến độ.

Để các nhắc nhở và cập nhật tự động chạy

Trong tuần thứ 2, nhóm sẽ vô hiệu hóa một tính năng đối với các tài khoản bị ảnh hưởng như một giải pháp tạm thời, và quyết định này cần được xem xét lại sau 7 ngày. Người phụ trách đặt ngày đáo hạn của công việc vào ngày đó và thêm một tự động hóa để thông báo cho chủ sở hữu khi đến ngày đó.

Việc cập nhật thông tin cho các bên liên quan cũng đang bắt đầu chiếm nhiều thời gian của người dẫn dắt. Hiện nay, một "Super Agent" sẽ đăng một bản tóm tắt ngắn vào mỗi Monday và thứ Năm, bao gồm các quyết định mới, các rào cản và bất kỳ vấn đề nào đang chờ quyết định từ nhà tài trợ.

Chuyển giao công việc

Tỷ lệ thất bại duy trì dưới 1% trong suốt 2 tuần liên tiếp, do đó nhóm đã đáp ứng điều kiện kết thúc nhiệm vụ. Trưởng nhóm chuyển các công việc còn mở sang Danh sách công việc của đội thanh toán và phân công lại cho họ. Mục nhập cuối cùng trong nhật ký quyết định ghi rõ chủ sở hữu mới và các điều kiện cần thiết để bắt đầu một cuộc điều tra mới. Sau đó, trưởng nhóm lưu trữ thư mục.

Giá dịch vụ ClickUp

Nhóm Tiger xuất sắc nhất biết khi nào nên rút lui

"Nhóm tiger" là một trường hợp ngoại lệ được kiểm soát. Đây là việc tạm thời tập trung chuyên môn, quyền hạn và sự chú ý vào một vấn đề mà cơ cấu thông thường không thể xử lý với tốc độ bình thường.

Điều đó khiến giai đoạn kết thúc trở nên quan trọng không kém gì giai đoạn can thiệp. Một khi vấn đề đã được kiểm soát, nhóm nên có thể rút lui mà không mang theo các quyết định, bằng chứng hay công việc chưa hoàn thành của mình. Nếu tổ chức vẫn phải phụ thuộc vào chính nhóm tạm thời đó để duy trì hoạt động, thì vấn đề đã thay đổi.

Điều còn lại sau khi bàn giao là hồ sơ ghi lại cách vấn đề được hiểu và giải quyết. Trong ClickUp, hồ sơ này vẫn có thể tìm kiếm được ngay cả khi thư mục của "Nhóm Tiger" đã được lưu trữ, nhờ đó người phụ trách tiếp theo có thể tìm thấy bản tóm tắt, các giả thuyết và nhật ký quyết định mà không cần phải tái tạo lại chúng.

Các câu hỏi thường gặp về "Nhóm Tiger"

Một "Tiger Group" nên có quy mô như thế nào?

Không có quy định chung về số lượng thành viên. Hãy giữ nhóm nòng cốt nhỏ nhất có thể tùy theo quy mô vấn đề, sau đó mời các chuyên gia khác tham gia khi cần đến kiến thức của họ. Một đội ngũ lớn hơn sẽ gây ra nhiều gánh nặng hơn về giao tiếp và sắp xếp lịch trình. Nếu ai đó chỉ cần cung cấp bằng chứng hoặc trả lời một câu hỏi cụ thể, họ không nhất thiết phải trở thành thành viên thường trực của đội Tiger.

Một nhóm "Tiger" có thể thực hiện công việc từ xa được không?

Đúng vậy. Một "Tiger Team" không nhất thiết phải chia sẻ phòng làm việc. Điều quan trọng là nhóm phải có quyền truy cập nhanh chóng vào cùng một nguồn chứng cứ, có quyền sở hữu rõ ràng và có một kênh đáng tin cậy để đưa ra quyết định. Đối với nhóm làm việc từ xa, hãy luôn cập nhật hồ sơ công việc và chỉ tổ chức các cuộc gọi đồng bộ khi cần đưa ra quyết định, giải quyết các vấn đề cản trở hoặc khi có chứng cứ mới làm thay đổi hướng điều tra. Điều này giúp tránh việc chênh lệch múi giờ khiến mỗi lần cập nhật lại trở thành một cuộc họp khác.

"Tiger team" có phải là một phần của Agile hay Scrum không?

Không. "Tiger team" không phải là một vai trò, sự kiện hay trách nhiệm chính thức trong Scrum. Hướng dẫn Scrum chính thức định nghĩa Đội Scrum bao gồm Product Owner, Scrum Master và các nhà phát triển. Một công ty áp dụng Scrum vẫn có thể thành lập một "tiger team" để giải quyết một vấn đề vượt ra ngoài ranh giới của các nhóm hiện có. Bạn chỉ cần quyết định cách thức công việc tạm thời đó tương tác với các cam kết Sprint hiện tại và các Mục tiêu Sản phẩm.

Một "Tiger Team" có nhất thiết phải là nhóm kỹ thuật không?

Không. Mô hình này bắt nguồn từ ngành hàng không vũ trụ và vẫn phổ biến trong lĩnh vực kỹ thuật và bảo mật, nhưng cấu trúc này có thể áp dụng ở bất kỳ đâu khi một vấn đề phức tạp cần sự tập trung chuyên môn cao. Một nhóm "Tiger" có thể điều tra gian lận, tái thiết kế quy trình vận hành, giải quyết vấn đề tuân thủ quy định, hoặc thực hiện công việc với một vấn đề thương mại. Chuyên môn cần thiết sẽ thay đổi tùy theo từng vấn đề cụ thể.

Những người bên ngoài công ty có thể tham gia vào một "Tiger Group" không?

Đúng vậy. Các chuyên gia bên ngoài, nhà cung cấp, chuyên gia tư vấn hoặc đối tác chuỗi cung ứng có thể tham gia khi họ sở hữu kiến thức mà nhóm nội bộ không có. Hãy đảm bảo họ được cung cấp sự rõ ràng tương tự về phạm vi công việc, quyền truy cập, bảo mật thông tin và quyền ra quyết định như các thành viên nội bộ. Họ nên tham gia vì quá trình điều tra cần đến chuyên môn của họ, chứ không chỉ đơn thuần vì tổ chức của họ bị ảnh hưởng bởi kết quả điều tra.

Nếu nhóm "Tiger" không thể giải quyết vấn đề thì sẽ ra sao?

Nhóm này vẫn cần đảm bảo rằng khi rời khỏi tổ chức, vấn đề còn lại phải hẹp hơn so với lúc bắt đầu. Điều đó có thể bao gồm việc xác định những yếu tố đã được loại trừ, cô lập các yếu tố chưa rõ còn lại, ghi chép những biện pháp can thiệp nào đã thất bại, và chỉ ra những điểm mà nhóm hiện tại đã đạt đến giới hạn về chuyên môn hoặc thẩm quyền. Từ đó, ban lãnh đạo có thể quyết định liệu công việc có cần một chuyên gia khác, thêm thời gian, một người chịu trách nhiệm lâu dài, hay một sự thay đổi cấu trúc lớn hơn hay không. Việc không đạt được điều kiện kết thúc ban đầu không làm mất đi những bài học thu được từ quá trình điều tra.

Sự khác biệt giữa "Tiger Team" và "nhóm đa chức năng" là gì?

“Đa chức năng” mô tả thành phần của nhóm. “Tiger team” mô tả lý do tại sao nhóm này được thành lập và thời gian tồn tại dự kiến của nó. Một nhóm đa chức năng có thể là nhóm thường trực và chịu trách nhiệm về một sản phẩm, quy trình hoặc lĩnh vực kinh doanh đang diễn ra. Một “Tiger team” được thành lập để giải quyết một vấn đề cụ thể và sẽ giải tán ngay sau khi nhiệm vụ đó hoàn thành. Một “Tiger team” thường là nhóm đa chức năng, nhưng hai thuật ngữ này không thể dùng thay thế cho nhau.