Menu
ESC

Nhập từ khóa để tìm kiếm

↑↓ Di chuyển
Enter Mở
ESC Đóng

Đang tải...

Bài 51 — Six Thinking Hats — Multiple perspective

Scrum Master Toolbox Bài 51/60

Mở đầu — vì sao bài này quan trọng

Bạn đã bao giờ ngồi trong một buổi họp mà ở đó có người chỉ chăm chăm chỉ ra rủi ro, có người lại bay bổng với ý tưởng mới, trong khi người thứ ba liên tục hỏi "số liệu đâu?" — và tất cả cãi nhau suốt một tiếng đồng hồ mà không ra được quyết định nào? Đó là cảnh tượng quen thuộc của hầu hết các đội nhóm. Vấn đề không nằm ở chỗ ai đúng ai sai, mà ở chỗ mọi người đang tranh luận với những "loại tư duy" khác nhau cùng một lúc, va vào nhau như xe cộ ở ngã tư không đèn.

Six Thinking Hats (Sáu Chiếc Mũ Tư Duy) — phương pháp do Edward de Bono giới thiệu năm 1985 — ra đời để giải quyết chính tình huống này. Ý tưởng cốt lõi rất đơn giản nhưng thay đổi cuộc chơi: thay vì để mọi người cãi nhau theo lập trường cá nhân, cả nhóm cùng "đội" một chiếc mũ tư duy tại một thời điểm, suy nghĩ song song theo cùng một hướng, rồi đổi mũ để khám phá hướng khác. De Bono gọi đây là "parallel thinking" — tư duy song song, đối lập với "adversarial thinking" — tư duy đối kháng kiểu tranh biện phương Tây cổ điển.

Là một Scrum Master, bạn liên tục đứng giữa những cuộc thảo luận có nguy cơ trượt khỏi quỹ đạo: một buổi retrospective bế tắc vì người này phòng thủ người kia chỉ trích, một quyết định kiến trúc kỹ thuật mà ai cũng có ý kiến nhưng không ai chịu nghe ai, hay một Sprint Planning mà cả nhóm phân vân giữa hai hướng đi. Six Thinking Hats là một công cụ facilitation cực kỳ mạnh để bạn dẫn dắt nhóm tách bạch cảm xúc khỏi dữ kiện, tách rủi ro khỏi cơ hội, và đảm bảo mọi góc nhìn đều được khai thác đầy đủ thay vì bị át đi bởi người nói to nhất. Trong bài này, tôi sẽ giúp bạn hiểu rõ sáu chiếc mũ, cách điều phối một phiên Six Hats hiệu quả, và những cạm bẫy thường gặp khi áp dụng trong môi trường đội nhóm Việt Nam.

Khái niệm cốt lõi

Bản chất của Six Thinking Hats là chia tư duy thành sáu chế độ riêng biệt, mỗi chế độ tượng trưng bằng một màu mũ. Khi cả nhóm "đội" cùng một màu mũ, mọi người tạm thời chỉ tư duy theo đúng chế độ đó — không pha trộn, không nhảy lung tung. Chiếc mũ không phải là tính cách của người tham gia; nó là một vai trò tạm thời mà ai cũng có thể đội. Đây là điểm tinh tế nhất: ngay cả người vốn bi quan cũng phải tư duy lạc quan khi đội mũ vàng, và người vốn mơ mộng cũng phải chỉ ra rủi ro khi đội mũ đen.

Mũ Trắng — Dữ kiện và thông tin

Mũ trắng (White Hat) đại diện cho sự thật khách quan: số liệu, dữ kiện, thông tin đã biết và thông tin còn thiếu. Khi đội mũ trắng, nhóm chỉ trình bày facts một cách trung lập, không diễn giải, không cảm xúc. Câu hỏi điển hình: "Chúng ta biết chắc điều gì? Dữ liệu nào đang có? Chúng ta còn thiếu thông tin gì và làm sao để lấy?" Ví dụ: "Sprint vừa rồi đội hoàn thành 23/34 story points" là phát biểu mũ trắng. "Đội làm việc kém hiệu quả" thì không — đó là diễn giải, không phải dữ kiện.

Mũ Đỏ — Cảm xúc và trực giác

Mũ đỏ (Red Hat) cho phép mọi người bày tỏ cảm xúc, linh cảm, trực giác mà không cần giải thích hay biện minh. Đây là chiếc mũ giải phóng, vì trong môi trường công sở người ta thường phải che giấu cảm xúc. Khi đội mũ đỏ, bạn được phép nói "Tôi cảm thấy lo lắng về deadline này" mà không ai được hỏi "tại sao". Cảm xúc là dữ liệu thật, và việc cho nó một không gian hợp pháp giúp nó không rò rỉ ngầm phá hoại buổi họp. Mũ đỏ thường được giữ ngắn — vài chục giây mỗi người.

Mũ Đen — Thận trọng và rủi ro

Mũ đen (Black Hat) là chiếc mũ của sự cẩn trọng: rủi ro, điểm yếu, lý do tại sao một ý tưởng có thể thất bại, những gì không khớp với kinh nghiệm hay quy định. De Bono nhấn mạnh đây là chiếc mũ giá trị nhất nhưng cũng dễ bị lạm dụng nhất — nó giúp ta tránh sai lầm, nhưng nếu đội quá lâu sẽ giết chết mọi ý tưởng. Mũ đen mang tính logic phê phán, không phải tiêu cực vô căn cứ: phải chỉ ra được "rủi ro gì, vì sao".

Mũ Vàng — Lạc quan và giá trị

Mũ vàng (Yellow Hat) là đối trọng của mũ đen: tìm kiếm lợi ích, giá trị, lý do tại sao một ý tưởng có thể thành công. Đây là sự lạc quan có logic — không phải "tôi thích nó" mà là "ý tưởng này tốt vì nó giúp giảm thời gian xử lý 30%". Mũ vàng thường khó hơn mũ đen, vì con người có xu hướng tự nhiên dễ thấy rủi ro hơn thấy cơ hội.

Mũ Xanh Lá — Sáng tạo và phương án mới

Mũ xanh lá (Green Hat) đại diện cho sáng tạo, ý tưởng mới, giải pháp thay thế, sự "khiêu khích" tư duy. Khi đội mũ xanh lá, mọi phán xét bị tạm gác lại — đây là lúc brainstorm, đề xuất điên rồ, hỏi "còn cách nào khác không?". Đây là chiếc mũ của sự tăng trưởng và khả năng.

Mũ Xanh Dương — Điều phối và tổng quan

Mũ xanh dương (Blue Hat) là chiếc mũ quản trị quá trình tư duy — chiếc mũ của người facilitator. Nó quyết định trình tự các mũ, đặt mục tiêu buổi họp, tóm tắt, và rút ra kết luận. Là Scrum Master, bạn sẽ thường xuyên đội mũ xanh dương để điều phối, nhưng điều hay là bạn có thể trao mũ xanh dương cho cả nhóm vào cuối buổi để họ tự tổng kết và quyết định bước tiếp theo.

Sức mạnh thật sự đến từ việc sắp xếp trình tự các mũ thành một "bản nhạc tư duy" (de Bono gọi là sequencing). Không có thứ tự cố định bắt buộc, nhưng một trình tự phổ biến cho việc đánh giá một ý tưởng là: Xanh dương (đặt mục tiêu) → Trắng (thu thập dữ kiện) → Xanh lá (sinh ý tưởng) → Vàng (tìm lợi ích) → Đen (tìm rủi ro) → Đỏ (kiểm tra cảm nhận) → Xanh dương (kết luận).

Tình huống thực tế

Ví dụ 1 — Tiki gỡ bế tắc quyết định công nghệ

Tại một đội phát triển thuộc một công ty thương mại điện tử lớn ở TP.HCM (tạm gọi là đội Logistics của Tiki), nhóm tranh cãi suốt hai buổi họp liền về việc có nên chuyển hệ thống tính phí vận chuyển sang microservices hay giữ nguyên monolith. Mỗi buổi đều biến thành cuộc chiến giữa hai phe: nhóm kỹ sư trẻ hào hứng muốn tách service, nhóm senior lo lắng về độ phức tạp vận hành.

Scrum Master quyết định chạy một phiên Six Thinking Hats kéo dài 75 phút. Khi đội mũ trắng, lần đầu tiên mọi người cùng nhìn vào con số thật: hệ thống hiện tại có 4 lần sự cố tính sai phí trong quý, thời gian triển khai trung bình 40 phút, và đội chỉ có 2 người biết vận hành Kubernetes. Khi đội mũ vàng, ngay cả nhóm senior cũng buộc phải kể ra lợi ích của microservices. Khi đội mũ đen, các kỹ sư trẻ — vốn đang phòng thủ — phải tự liệt kê rủi ro, và họ nhận ra rủi ro vận hành lớn hơn họ tưởng. Đến mũ đỏ, sự thật lộ ra: phần lớn cảm thấy "chưa sẵn sàng về năng lực vận hành". Kết quả ở mũ xanh dương cuối buổi không phải là "có hay không" mà là một phương án trung gian: tách riêng đúng module tính phí ra trước, đầu tư đào tạo vận hành trong một quý, rồi mới đánh giá tiếp.

Bài học: Six Hats không tạo ra câu trả lời thần kỳ, nhưng nó buộc mỗi phe phải tạm bước ra khỏi lập trường của mình và nhìn từ góc đối lập. Chính việc nhóm trẻ phải đội mũ đen và nhóm senior phải đội mũ vàng đã làm tan rã thế đối đầu.

Ví dụ 2 — Một retrospective "đóng băng" được hâm nóng lại

Một startup fintech khoảng 25 người ở Hà Nội có một đội mà các buổi retrospective đã trở nên nhạt nhẽo và phòng thủ. Mỗi khi ai đó nêu vấn đề, người liên quan lập tức giải thích biện minh, và buổi họp biến thành những lời đổ lỗi ngầm. Scrum Master thử dùng Six Thinking Hats để cấu trúc lại buổi retro về một sự cố lớn: một bản release gây lỗi thanh toán trong 3 giờ.

Cô bắt đầu bằng mũ trắng — cả nhóm chỉ liệt kê timeline sự kiện và số liệu, không ai được nói "lẽ ra". Sau đó mũ đỏ cho mỗi người 30 giây nói cảm xúc: nhiều người thừa nhận họ thấy "sợ bị quy trách nhiệm" — và việc nói thành lời này đã giải tỏa căng thẳng rõ rệt. Mũ đen để cả nhóm cùng mổ xẻ rủi ro hệ thống (không phải lỗi cá nhân), mũ xanh lá để sinh giải pháp, mũ vàng để chọn giải pháp khả thi nhất. Vì mọi người cùng đội một mũ tại một thời điểm, không ai bị "tấn công" riêng lẻ — sự cố trở thành vấn đề của hệ thống chứ không phải của một con người.

Bài học: Khi một retrospective bị mắc kẹt trong vòng xoáy phòng thủ và đổ lỗi, Six Hats là một cách hiệu quả để "phi cá nhân hóa" vấn đề, vì cả nhóm tư duy song song thay vì đối đầu.

Ví dụ 3 — Lạm dụng mũ đen ở một agency

Một agency phần mềm gia công ở Đà Nẵng áp dụng Six Hats cho việc đánh giá một đề xuất tính năng mới từ khách hàng Nhật. Nhưng buổi đầu thất bại: facilitator để mọi người tự do, và vì văn hóa nhóm vốn rất thận trọng, gần như cả buổi trôi vào mũ đen — ai cũng chỉ ra vì sao tính năng sẽ khó. Đề xuất bị "bóp chết" trước khi kịp khám phá giá trị.

Ở buổi sau, Scrum Master siết chặt vai mũ xanh dương: phân bổ thời gian rõ ràng cho từng mũ (mũ vàng và xanh lá mỗi mũ 12 phút, mũ đen chỉ 8 phút), và quy định không ai được "đội nhầm mũ" — nếu đang ở mũ vàng mà ai nói rủi ro thì bị nhắc nhẹ nhàng. Lần này, tính năng được nhìn nhận đầy đủ, và nhóm đề xuất được một phiên bản rút gọn khả thi cho khách.

Bài học: Six Hats chỉ phát huy hiệu quả khi người điều phối (mũ xanh dương) kỷ luật về trình tự và thời lượng. Để nhóm tự do rất dễ dẫn đến việc một màu mũ — thường là mũ đen — chiếm trọn buổi họp.

Hướng dẫn từng bước

Dưới đây là quy trình tôi khuyên bạn dùng khi điều phối một phiên Six Thinking Hats:

  • Xác định mục tiêu rõ ràng (mũ xanh dương mở màn). Trước khi bắt đầu, hãy chốt câu hỏi cụ thể mà nhóm cần giải quyết: "Chúng ta có nên áp dụng X không?", "Làm sao cải thiện quy trình deploy?". Mục tiêu mơ hồ sẽ khiến mọi chiếc mũ trở nên vô nghĩa.
  • Giới thiệu luật chơi. Nếu nhóm chưa quen, hãy giải thích ngắn gọn từng mũ và nguyên tắc cốt lõi: tại một thời điểm, tất cả cùng đội một mũ; mũ là vai trò, không phải tính cách; không phán xét người khác vì đã đội mũ.
  • Thiết kế trình tự mũ phù hợp. Tùy mục đích mà chọn sequence. Đánh giá ý tưởng đã có: Trắng → Vàng → Đen → Đỏ → Xanh dương. Tìm ý tưởng mới: Trắng → Xanh lá → Vàng → Đen. Giải quyết sự cố nhạy cảm: Trắng → Đỏ → Đen → Xanh lá → Vàng.
  • Phân bổ thời gian cho mỗi mũ và bám sát. Ví dụ mỗi mũ 8–12 phút. Dùng đồng hồ đếm. Đây là phần quan trọng nhất của vai mũ xanh dương — không để một mũ "ăn" hết thời gian.
  • Đội từng mũ, ghi chép trực quan. Với mỗi mũ, viết ý kiến lên bảng/Miro theo cột màu tương ứng. Giữ cả nhóm trong đúng chế độ tư duy; nếu ai lạc sang mũ khác, nhẹ nhàng kéo về: "Ý hay, ta để dành cho mũ đen lát nữa nhé."
  • Riêng mũ đỏ — nhanh và không giải thích. Đi vòng quanh, mỗi người nói cảm xúc trong vài chục giây, không tranh luận.
  • Kết thúc bằng mũ xanh dương. Tóm tắt những gì thu được ở mỗi mũ, rồi dẫn nhóm đến quyết định hoặc action items cụ thể. Có thể trao mũ xanh dương cho cả nhóm để họ tự kết luận, tăng cảm giác sở hữu.
  • Chốt bước tiếp theo. Một phiên Six Hats không có action item là một phiên lãng phí. Ghi rõ ai làm gì, khi nào.

Lỗi thường gặp & mẹo

Lỗi: Biến mũ thành nhãn tính cách. "Anh A lúc nào cũng đội mũ đen" — đây là hiểu sai nguy hiểm nhất. Mũ là vai trò chung của cả nhóm tại một thời điểm, không phải cách phân loại con người. Hãy luôn nhấn mạnh cả nhóm cùng đội một mũ.

Lỗi: Để mũ đen thống trị. Như ví dụ agency Đà Nẵng, văn hóa thận trọng dễ khiến buổi họp chìm trong rủi ro. Mẹo: luôn đặt mũ vàng trước mũ đen trong trình tự, và phân bổ cho mũ vàng/xanh lá nhiều thời gian hơn nếu nhóm vốn bi quan.

Lỗi: Nhảy mũ lung tung. Khi đang ở mũ vàng mà có người nêu rủi ro, cả nhóm dễ bị cuốn theo. Người mũ xanh dương phải kiên quyết "công viên hóa" (park) ý kiến lạc mũ và quay lại sau.

Lỗi: Bỏ qua mũ đỏ vì thấy "không chuyên nghiệp". Trong văn hóa công sở Việt Nam, nhiều người ngại bày tỏ cảm xúc. Nhưng chính mũ đỏ là van xả giúp cảm xúc ngầm không phá hoại buổi họp. Đừng cắt nó.

Mẹo cho đội từ xa: Dùng Miro/Mural với sáu cột màu, hoặc đơn giản là sáu kênh khác nhau. Có thể chạy mũ trắng và mũ đỏ theo dạng đóng góp ẩn danh để mọi người thật lòng hơn.

Mẹo về liều lượng: Không phải buổi nào cũng cần đủ sáu mũ. Đôi khi chỉ cần "đội mũ đen 5 phút" trước một quyết định lớn, hoặc "đội mũ vàng" để cứu một ý tưởng đang bị vùi dập, là đủ. Six Hats có thể dùng từng phần.

Mẹo về thời lượng tổng: Một phiên đầy đủ thường 60–90 phút. Đừng cố nhồi vào một buổi standup 15 phút.

Bài tập thực hành

  • Tự luyện sequencing. Lấy một quyết định thật mà nhóm bạn đang phân vân (ví dụ: "có nên đổi công cụ quản lý task không?"). Tự thiết kế trình tự sáu mũ phù hợp và phân bổ thời gian cho từng mũ. Viết ra giấy.
  • Chạy thử mini với một mũ duy nhất. Trong buổi họp tiếp theo, trước một quyết định, hãy mời cả nhóm "cùng đội mũ đen 5 phút" để liệt kê rủi ro, rồi "cùng đội mũ vàng 5 phút". Quan sát chất lượng thảo luận thay đổi thế nào so với tranh luận tự do.
  • Điều phối một phiên đầy đủ. Chọn một retrospective hoặc một quyết định kiến trúc, áp dụng quy trình 8 bước ở trên. Sau buổi, tự đánh giá: mũ nào nhóm làm tốt nhất, mũ nào khó nhất, bạn đã giữ trình tự được không?
  • Phản tư về văn hóa nhóm. Viết một đoạn ngắn trả lời: Nhóm tôi có xu hướng "mắc kẹt" ở chiếc mũ nào nhất (thường là mũ đen hoặc mũ trắng quá nhiều)? Tôi sẽ điều chỉnh trình tự ra sao để bù lại?

Tóm tắt

Six Thinking Hats là công cụ giúp cả nhóm tư duy song song thay vì đối kháng, bằng cách chia tư duy thành sáu chế độ: mũ trắng (dữ kiện), mũ đỏ (cảm xúc), mũ đen (rủi ro), mũ vàng (lợi ích), mũ xanh lá (sáng tạo), và mũ xanh dương (điều phối). Sức mạnh của nó nằm ở chỗ buộc mọi người tạm rời lập trường cá nhân và cùng nhìn vấn đề từ một góc tại một thời điểm — điều này phi cá nhân hóa xung đột và đảm bảo mọi góc nhìn đều được khai thác.

Là Scrum Master, bạn chủ yếu đội mũ xanh dương: đặt mục tiêu, thiết kế trình tự mũ, giữ kỷ luật thời gian, và dẫn nhóm đến kết luận. Hãy nhớ ba điều quan trọng nhất: mũ là vai trò chứ không phải tính cách; đừng để mũ đen thống trị (đặt mũ vàng trước nó); và một phiên Six Hats luôn phải kết thúc bằng action items cụ thể. Bắt đầu nhẹ nhàng — chỉ cần một hoặc hai mũ trong buổi họp tới — rồi dần dần đưa cả bộ sáu mũ vào những quyết định lớn của nhóm.