Mở đầu — vì sao bài này quan trọng
Hãy thử nhớ lại một buổi retrospective hoặc một buổi thảo luận cải tiến mà bạn từng dẫn dắt. Khi bạn hỏi cả nhóm: "Theo các bạn, mình đang làm gì chưa tốt? Mình cần cải thiện chỗ nào?", chuyện gì thường xảy ra? Đa số trường hợp là một sự im lặng đầy ngại ngùng. Vài người nhìn xuống bàn phím. Một người buột miệng nói điều gì đó chung chung và an toàn kiểu "chắc mình cần giao tiếp tốt hơn". Còn những vấn đề thực sự nghiêm trọng — kiểu như "Product Owner thay đổi yêu cầu giữa Sprint mà không ai dám phản đối", hay "team toàn merge code không review" — thì nằm im dưới đáy, không ai dám gọi tên.
Đây là một nghịch lý kinh điển trong văn hóa làm việc, và nó đặc biệt rõ nét ở môi trường Việt Nam, nơi việc chỉ trích trực diện — dù là chỉ trích một quy trình chứ không phải một con người — vẫn dễ bị xem là mất lòng, là "vạch áo cho người xem lưng". Người ta sợ làm sếp phật ý, sợ đồng nghiệp tự ái, sợ bị quy chụp là tiêu cực.
TRIZ là một công cụ facilitation cực kỳ thông minh để phá vỡ chính nỗi sợ đó. Thay vì hỏi "Làm sao để làm tốt hơn?", TRIZ lật ngược câu hỏi lại: "Làm thế nào để đảm bảo chúng ta sẽ thất bại thảm hại nhất?". Nghe có vẻ ngớ ngẩn, nhưng chính sự ngớ ngẩn, hài hước đó lại tạo ra một không gian an toàn tâm lý (psychological safety) để mọi người mạnh dạn nói ra sự thật. Vì khi đang "đùa" về cách phá hoại, người ta không còn cảm giác đang tố cáo ai cả — họ đang chơi một trò chơi. Và trong lúc chơi, sự thật cay đắng nhất lại tự nhiên trồi lên mặt nước.
Là một Scrum Master, đây là một trong những công cụ giá trị nhất để bạn bỏ vào "toolbox" của mình khi cần khơi ra những vấn đề khó nói mà nhóm cứ né tránh hết Sprint này qua Sprint khác.
Khái niệm cốt lõi
TRIZ là gì trong bối cảnh Liberating Structures
Trước hết cần làm rõ một chút để bạn không nhầm lẫn. TRIZ (đọc là "tờ-rít", viết tắt từ tiếng Nga "Teoriya Resheniya Izobretatelskikh Zadatch" — Lý thuyết Giải quyết Vấn đề Sáng tạo) vốn là một phương pháp luận đồ sộ về sáng tạo kỹ thuật do nhà phát minh người Liên Xô Genrich Altshuller xây dựng từ thập niên 1940. Tuy nhiên, trong bộ Liberating Structures mà chúng ta dùng cho công việc facilitation, TRIZ là một microstructure đơn giản hơn nhiều, chỉ mượn một ý tưởng cốt lõi của TRIZ gốc: tư duy ngược (reverse thinking).
Trong Liberating Structures, TRIZ được mô tả là một "anti-thinking structure" — cấu trúc tư duy ngược. Thay vì hỏi điều bạn thực sự muốn, bạn hỏi điều ngược lại hoàn toàn.
Vì sao tư duy ngược lại hiệu quả hơn
Có ba lý do tâm lý khiến cách tiếp cận ngược đời này lại hiệu quả vượt trội so với câu hỏi trực tiếp:
Thứ nhất, nó hạ thấp rào cản tâm lý. Khi bạn hỏi "Làm sao để dự án này thất bại thảm hại nhất?", không ai phải sợ làm mất lòng ai. Mọi người được "cấp phép" để nói ra những điều tệ hại một cách công khai, thậm chí được khuyến khích nói càng tệ càng tốt. Sự hài hước (playfulness) chính là chất bôi trơn cho sự thật.
Thứ hai, nó dễ hơn về mặt nhận thức. Bộ não con người thường dễ hình dung một thảm họa cụ thể hơn là một thành công trừu tượng. Hỏi "làm sao để thành công" thì câu trả lời mơ hồ; hỏi "làm sao để thất bại" thì người ta liệt kê được ngay hàng tá hành vi cụ thể, vì những hành vi phá hoại đó thường rất sống động và quen thuộc.
Thứ ba, và đây là điểm tinh tế nhất — nó giúp nhóm tự nhận ra rằng mình đang LÀM những điều phá hoại đó rồi. Khi cả nhóm hào hứng liệt kê danh sách "cách để phá hoại Sprint", đến giai đoạn hai, mỗi người sẽ tự soi gương và giật mình: "Ơ, mấy cái này... mình đang làm thật mà." Đây là khoảnh khắc "aha" mạnh mẽ nhất của TRIZ. Nhóm không bị ai chỉ trích cả; họ tự nhìn thấy chính mình trong tấm gương phản chiếu mà họ vừa tự dựng lên.
Ba giai đoạn của TRIZ
TRIZ vận hành qua đúng ba giai đoạn (three stages), và bạn cần thuộc lòng cấu trúc này:
Giai đoạn 1 — Liệt kê cách phá hoại (Make a list). Đặt một "câu hỏi nghịch lý" (paradoxical/provocative question): "Hãy nghĩ ra mọi cách để đạt được kết quả TỆ HẠI NHẤT, ngược lại hoàn toàn với mục tiêu chúng ta mong muốn." Nhóm liệt kê tất cả những hành động, hành vi, quyết định có thể dẫn đến thảm họa. Càng nhiều, càng cụ thể, càng hài hước càng tốt.
Giai đoạn 2 — Soi gương thực tại (Find what we already do). Lần lượt rà soát từng mục trong danh sách vừa rồi và hỏi: "Có điều gì trong danh sách này mà chúng ta đang thực sự làm — dù chỉ một chút, hoặc đôi khi — trong thực tế hay không?" Đây là giai đoạn gây "đau" nhất nhưng cũng giá trị nhất. Hãy thành thật đánh dấu những mục mà nhóm đang phạm phải.
Giai đoạn 3 — Lên hành động dừng lại (Stop & plan first steps). Với những hành vi phá hoại mà nhóm thừa nhận đang làm, hỏi tiếp: "Bước đầu tiên nào chúng ta có thể làm để DỪNG những hành vi này lại?" Từ đây sinh ra các action item cụ thể, thực tế và có động lực cao, vì chính nhóm đã tự thấy mình cần thay đổi.
Tình huống thực tế
Ví dụ 1 — Công ty fintech ở TP.HCM và buổi retro "phá hoại Sprint"
Anh Tuấn là Scrum Master tại một công ty fintech khoảng 80 người ở Quận 1, TP.HCM. Nhóm của anh gồm 7 kỹ sư, làm sản phẩm ví điện tử. Suốt 4 Sprint liền, các buổi retrospective đều nhạt nhẽo: ai cũng nói "Sprint ổn", "không có gì lớn", trong khi velocity thực tế đang tụt dần và số bug rò rỉ ra production tăng đều.
Anh Tuấn quyết định dùng TRIZ. Anh mở đầu bằng câu hỏi: "Giả sử sếp lớn ngầm trả cho chúng ta gấp đôi lương để cố tình phá nát Sprint này một cách kín đáo nhất, để không ai phát hiện. Chúng ta sẽ làm gì?"
Cả phòng cười ồ. Và rồi danh sách trào ra rất nhanh: "Nhận thật nhiều task vào Sprint dù biết làm không kịp", "Đừng bao giờ cập nhật trạng thái task trên Jira", "Cứ merge thẳng vào main, đừng review", "Daily thì mỗi người đọc báo cáo cho có rồi giải tán", "Đợi đến ngày cuối Sprint mới bắt đầu test".
Đến giai đoạn 2, anh Tuấn hỏi nhẹ nhàng: "Trong số này, mình đang làm cái nào rồi?" Cả phòng im lặng vài giây — rồi một bạn dev cười gượng: "Cái merge thẳng vào main thì... em làm tuần nào cũng có." Một bạn khác: "Test dồn ngày cuối là đúng tụi mình luôn rồi." Hóa ra nhóm tự thừa nhận họ đang phạm tới 5 trong 8 "cách phá hoại" mà chính họ vừa nghĩ ra.
Bài học rút ra: Không một lời chỉ trích nào được thốt ra từ Scrum Master, nhưng nhóm tự phơi bày toàn bộ anti-pattern của mình. Action item sinh ra sau đó — "bắt buộc một reviewer cho mỗi PR vào main", "test song song trong Sprint" — có tỷ lệ thực thi cao hơn hẳn vì nó đến từ sự tự nhận thức, không phải mệnh lệnh.
Ví dụ 2 — Startup giáo dục và nỗi sợ "nói thật với CEO"
Một startup edtech ở Hà Nội, khoảng 25 người, có đặc thù là CEO rất quyền lực và hay ngồi dự retro. Vì vậy không ai dám nói thật về việc CEO liên tục chen yêu cầu mới vào giữa Sprint. Scrum Master tên Linh biết rõ vấn đề này nhưng nói trực tiếp thì quá nhạy cảm.
Linh dùng TRIZ với một biến thể tinh tế: "Hãy liệt kê mọi cách chắc chắn nhất để làm cho một startup giao hàng trễ và đốt sạch tiền nhà đầu tư." Đây là câu hỏi đủ trừu tượng để không chỉ đích danh ai. Danh sách hiện ra, và một mục nổi bật được nhiều người ngầm đồng tình: "Thay đổi ưu tiên liên tục, không bao giờ để team tập trung làm xong một thứ."
Khi mục này được đọc lên ở giai đoạn 2 và cả nhóm gật gù thừa nhận "ừ, mình đang bị thế", CEO — vốn cũng ngồi trong phòng — tự nhận ra mình chính là nguồn gốc mà không cần ai chỉ tay. Ông tự nói: "Cái này chắc tại anh hay đổi ý." Không khí vẫn vui vẻ vì vẫn đang trong "trò chơi phá hoại".
Bài học rút ra: TRIZ tạo ra một lớp đệm an toàn để vấn đề nhạy cảm về quyền lực được nói ra. Khi câu hỏi đủ chung chung và hài hước, ngay cả người có quyền lực nhất cũng tự soi mình mà không cảm thấy bị tấn công.
Ví dụ 3 — Nhóm vận hành tại một công ty logistics Đông Nam Á
Tại một công ty logistics có chi nhánh ở cả Việt Nam và Singapore, một nhóm vận hành kho liên tục để xảy ra giao hàng sai. Mọi buổi họp cải tiến trước đó đều biến thành phiên đổ lỗi giữa các ca. Anh quản lý quyết định thử TRIZ cho phần phi-kỹ thuật.
Câu hỏi: "Làm sao để đảm bảo khách hàng nhận sai đơn nhiều nhất có thể?" Vì câu hỏi hướng vào hành vi chứ không vào người, không khí đổ lỗi biến mất. Danh sách: "Không scan mã vạch khi đóng gói", "Để nhãn dán cũ trên thùng tái sử dụng", "Bàn giao ca không kiểm kê". Đến giai đoạn 2, hóa ra cả ba thói quen này đều đang tồn tại ở các mức độ khác nhau giữa các ca.
Bài học rút ra: TRIZ không chỉ dùng cho team phần mềm. Bất kỳ nhóm nào có "thói quen ngầm gây hại" mà mọi người ngại nói đều có thể dùng được. Việc chuyển trọng tâm từ "ai sai" sang "hành vi nào sai" đã hóa giải xung đột giữa các ca.
Hướng dẫn từng bước
Đây là quy trình chi tiết để bạn tự dẫn một phiên TRIZ, thời lượng khoảng 30–45 phút cho nhóm 5–10 người.
Bước 1 — Chuẩn bị câu hỏi nghịch lý (trước buổi họp). Xác định rõ kết quả MONG MUỐN của nhóm (ví dụ: "giao hàng đúng hạn, chất lượng tốt"), rồi lật ngược nó thành câu hỏi phá hoại. Câu hỏi tốt cần: hài hước, cụ thể với bối cảnh nhóm, và đủ khiêu khích. Ví dụ: "Làm thế nào để đảm bảo Sprint tới của chúng ta trở thành thảm họa lớn nhất lịch sử team?"
Bước 2 — Giải thích luật chơi (2 phút). Nói rõ với nhóm: đây là một trò chơi tư duy ngược, không ai bị phán xét, càng nghĩ ra cách phá hoại tệ và buồn cười càng tốt. Khuyến khích sự phóng đại.
Bước 3 — Giai đoạn 1: Brainstorm cách phá hoại (10–15 phút). Cho mỗi người tự viết ý tưởng ra sticky note (hoặc Miro/FigJam nếu online) trong 3–4 phút, sau đó lần lượt chia sẻ. Gom các ý lên một bảng chung. Đừng vội phán xét hay lọc — cứ thu thập thật nhiều.
Bước 4 — Giai đoạn 2: Soi gương (10 phút). Đi qua từng mục và hỏi cả nhóm: "Mục này có giống điều chúng ta đang làm không?" Dùng dấu chấm (dot voting) hoặc giơ tay để đánh dấu những hành vi mà nhóm thừa nhận đang phạm. Hãy giữ không khí nhẹ nhàng, đừng để biến thành phiên đổ lỗi.
Bước 5 — Giai đoạn 3: Hành động dừng lại (10 phút). Chọn ra 2–3 hành vi phá hoại "đau" nhất mà nhóm đang làm. Với mỗi cái, hỏi: "Bước đầu tiên nào ta có thể làm ngay để dừng nó lại?" Ghi lại thành action item có người chịu trách nhiệm và thời hạn.
Bước 6 — Chốt và theo dõi. Đưa các action item vào board theo dõi và rà lại ở buổi tiếp theo. TRIZ chỉ thực sự có giá trị khi giai đoạn 3 dẫn đến thay đổi thật.
Lỗi thường gặp & mẹo
Lỗi 1 — Dừng lại ở giai đoạn 1 vì thấy "vui quá rồi". Đây là sai lầm phổ biến nhất. Giai đoạn liệt kê cách phá hoại rất sôi động, mọi người cười nhiều, và Scrum Master non tay dễ kết thúc ở đó mà nghĩ "buổi họp thành công". Nhưng nếu không đi tới giai đoạn 2 và 3, TRIZ chỉ là một trò giải trí vô bổ. Mẹo: luôn dành đủ ít nhất nửa thời lượng cho hai giai đoạn sau.
Lỗi 2 — Câu hỏi nghịch lý quá nhạt hoặc quá trừu tượng. Nếu bạn hỏi "Làm sao để team không hiệu quả?" thì quá hiền, nhóm không bật được năng lượng. Câu hỏi cần phóng đại, cực đoan và cụ thể: "Làm sao để sản phẩm này bị mọi khách hàng ghét và xóa app trong vòng 1 phút?" Mẹo: dùng động từ mạnh và bối cảnh thật của nhóm.
Lỗi 3 — Để giai đoạn 2 biến thành đấu tố cá nhân. Khi soi gương, nếu ai đó nói "cái này là tại anh A đấy", không khí an toàn sẽ sụp đổ ngay. Mẹo: luôn giữ ngôn ngữ ở mức "chúng ta", tập trung vào hành vi và hệ thống, không vào con người. Bạn — Scrum Master — phải nhắc lại nguyên tắc này khi cần.
Lỗi 4 — Lạm dụng TRIZ. Nếu Sprint nào cũng dùng TRIZ, hiệu ứng bất ngờ và hài hước sẽ mất đi. Mẹo: dùng TRIZ khi nhóm đang né tránh, retro bị nhạt, hoặc cần khơi anti-pattern khó nói. Đừng biến nó thành thói quen máy móc.
Mẹo bổ sung cho bối cảnh Việt Nam: Trong nhóm có sự chênh lệch cấp bậc rõ rệt, hãy cân nhắc cho viết ẩn danh ở giai đoạn 1 (sticky note không tên, hoặc công cụ online ẩn danh). Điều này giúp những ý tưởng "động chạm" sếp vẫn được nói ra mà không ai phải lộ diện.
Bài tập thực hành
Bài 1 — Soạn câu hỏi nghịch lý. Chọn một mục tiêu thật của nhóm bạn (ví dụ: "Daily Scrum hiệu quả, đúng giờ, mọi người tập trung"). Viết ra 3 phiên bản câu hỏi TRIZ ngược lại với mức độ khiêu khích tăng dần. So sánh xem phiên bản nào có khả năng khơi gợi năng lượng nhất và lý giải vì sao.
Bài 2 — Tự chạy một mini-TRIZ. Trong buổi retro gần nhất, dành 20 phút thử TRIZ với chủ đề "Làm sao để các action item của retro không bao giờ được thực hiện?". Ghi lại danh sách phá hoại của nhóm, đánh dấu những cái nhóm đang phạm, và rút ra ít nhất 1 action item ở giai đoạn 3.
Bài 3 — Phân tích phản tư. Sau khi chạy, viết một đoạn ngắn (150–200 từ) trả lời: Giai đoạn nào khó nhất với vai trò facilitator của bạn? Có lúc nào không khí suýt biến thành đổ lỗi không, và bạn đã (hoặc nên) xử lý thế nào? Có anti-pattern nào trồi lên mà trước đó không ai dám nói không?
Tóm tắt
TRIZ trong Liberating Structures là một công cụ facilitation dựa trên nguyên lý tư duy ngược: thay vì hỏi cách làm tốt, bạn hỏi cách phá hoại tệ hại nhất. Chính sự hài hước và "đùa giỡn" này tạo ra không gian an toàn để nhóm nói ra những anti-pattern mà bình thường họ né tránh — đặc biệt giá trị trong văn hóa ngại chỉ trích trực diện như ở Việt Nam.
Hãy ghi nhớ ba giai đoạn cốt lõi: (1) liệt kê mọi cách phá hoại, (2) soi gương để thừa nhận những hành vi nhóm đang thực sự làm, và (3) lên bước hành động để dừng chúng lại. Sức mạnh của TRIZ nằm ở khoảnh khắc nhóm tự nhận ra mình trong tấm gương phá hoại do chính mình dựng nên — không ai chỉ trích ai, nhưng sự thật vẫn được phơi bày.
Lỗi chí mạng cần tránh là dừng ở giai đoạn vui mà bỏ quên hai giai đoạn sau, và để buổi họp trượt thành đổ lỗi cá nhân. Dùng TRIZ đúng lúc, đúng liều, và bạn sẽ có trong tay một công cụ phá băng mạnh mẽ để khơi ra những vấn đề khó nói nhất của nhóm.