Bài 2: Quy Trình 4 Bước "Đập Tan" Mọi Bài Toán Khó

Series: Tư Duy First Principles – Giải Mã Năng Lực Giải Quyết Vấn Đề Đột Phá

Từ lý thuyết đến hành động

Ở Bài 1, chúng ta đã hiểu vì sao Tư duy theo lối mòn đang âm thầm giới hạn khả năng sáng tạo và giải quyết vấn đề của bạn, và vì sao First Principles Thinking lại là công cụ có thể phá vỡ trần giới hạn đó. Nhưng hiểu lý thuyết thôi chưa đủ – First Principles Thinking chỉ thực sự có giá trị khi bạn biến nó thành một quy trình có thể lặp lại, chứ không phải một khoảnh khắc "giác ngộ" ngẫu nhiên.

Trong bài này, chúng ta sẽ đi qua 4 bước cụ thể, kèm theo một case study xuyên suốt để bạn thấy toàn bộ quy trình được áp dụng liền mạch từ đầu đến cuối – không chỉ dừng ở lý thuyết rời rạc.

Case study xuyên suốt: Một team kỹ thuật gồm 10 người đang gặp vấn đề "Pull Request (PR) mất trung bình 3 ngày mới được merge, làm chậm tốc độ release sản phẩm." Chúng ta sẽ dùng chính bài toán này để minh họa cho cả 4 bước.

Bước 1: Nhận diện vấn đề

Nghe có vẻ hiển nhiên, nhưng đây lại là bước nhiều người làm sai nhất. Rất nhiều vấn đề chúng ta cố gắng giải quyết thực chất là triệu chứng, chứ không phải vấn đề gốc.

Ví dụ: "Doanh số tháng này giảm" không phải là vấn đề – đó là triệu chứng. Vấn đề thực sự có thể là "khách hàng không còn thấy giá trị trong sản phẩm ở mức giá hiện tại" hoặc "kênh phân phối chính đang mất hiệu quả". Nếu bạn bắt tay vào "giải quyết" triệu chứng (ví dụ: chạy thêm quảng cáo để bù doanh số), bạn có thể tốn nguồn lực mà không chạm được vào nguyên nhân thực sự.

Ba tiêu chí của một câu định nghĩa vấn đề tốt

Để nhận diện đúng vấn đề, hãy viết nó ra bằng một câu càng cụ thể càng tốt, đáp ứng đủ ba yếu tố:

1. Đối tượng bị ảnh hưởng cụ thể – Ai đang gặp vấn đề? (một team, một nhóm khách hàng, một quy trình cụ thể)
2. Biểu hiện đo lường được – Vấn đề thể hiện qua con số hoặc hiện tượng nào? (không dùng tính từ mơ hồ như "chậm", "kém hiệu quả" mà không có đơn vị đo)
3. Bằng chứng/nguồn dữ liệu – Bạn lấy thông tin này từ đâu? (số liệu hệ thống, khảo sát, quan sát trực tiếp)

Tránh những mô tả mơ hồ như "mình cần cải thiện hiệu suất team". Thay vào đó, áp dụng vào case study của chúng ta:

Vấn đề: "Team Engineering (10 người) đang mất trung bình 3 ngày làm việc để một Pull Request được review và merge, tính từ dữ liệu Git trong 3 tháng gần nhất. Trong khi đó, roadmap sản phẩm yêu cầu tốc độ release 2 lần/tuần, và với tốc độ merge hiện tại, team chỉ đạt được khoảng 1 lần/tuần."

Lưu ý cách câu này có số liệu cụ thể (3 ngày, 3 tháng, 2 lần/tuần vs 1 lần/tuần) thay vì chỉ nói "PR bị merge chậm". Con số cụ thể sẽ giúp bạn ở Bước 3 và Bước 4 có cơ sở để thiết kế và đo lường giải pháp.

Bước 2: Loại bỏ giả định

Đây là bước quan trọng nhất và cũng khó nhất, vì nó đòi hỏi bạn phải "lật ngược" chính cách suy nghĩ quen thuộc của mình – thứ mà tâm lý học gọi là "functional fixedness" (sự cố định chức năng): xu hướng chỉ nhìn thấy một sự vật/quy trình theo đúng cách nó vẫn được sử dụng, mà không thấy được những khả năng khác.

Kỹ thuật liệt kê giả định

Hãy liệt kê ra giấy mọi giả định, mọi quy tắc ngầm mà bạn đang mặc nhiên coi là đúng khi tiếp cận vấn đề. Một mẹo hữu ích: viết ra mọi câu có dạng "X phải Y" hoặc "X luôn cần Z" liên quan đến vấn đề, sau đó khoanh tròn từng câu và tự hỏi: "Điều này có thực sự đúng không, hay chỉ là thứ mình đang mặc định vì mọi người vẫn làm vậy?"

Áp dụng vào case study "team mất 3 ngày để merge PR":

Càng bóc tách được nhiều giả định, bạn càng tiến gần hơn đến bản chất thật của vấn đề. Một lưu ý quan trọng: đừng vội bác bỏ hay giữ lại giả định ngay lúc này – mục tiêu của Bước 2 chỉ là liệt kê và đặt câu hỏi, việc phân tích sâu hơn sẽ diễn ra ở Bước 3.

Công cụ hỗ trợ: "Chesterton's Fence"

Một nguyên tắc hữu ích khi loại bỏ giả định là "Hàng rào của Chesterton" (Chesterton's Fence) – trước khi phá bỏ một quy tắc hay hàng rào mà bạn không hiểu lý do tồn tại của nó, hãy tìm hiểu tại sao nó được dựng lên trước đã. Có thể quy tắc "2 reviewer" từng được đặt ra sau một sự cố nghiêm trọng do chỉ 1 người review bỏ sót lỗi bảo mật. Nếu vậy, việc loại bỏ hoàn toàn giả định này mà không có cơ chế thay thế tương đương có thể tạo ra rủi ro mới. First Principles không có nghĩa là phá bỏ mù quáng – mà là hiểu rõ lý do gốc rồi mới quyết định giữ, sửa, hay bỏ.

Bước 3: Truy tìm nguyên lý gốc

Sau khi loại bỏ các giả định, hãy tiếp tục đào sâu cho đến khi chạm được vào những sự thật nền tảng – những điều không thể bàn cãi, dựa trên quy luật vật lý, toán học, hành vi con người, hoặc dữ liệu thực tế đã được kiểm chứng.

Kỹ thuật "5 Whys"

Công cụ hữu ích nhất ở bước này là kỹ thuật "5 Whys" (5 câu hỏi Tại sao), được phát triển bởi Sakichi Toyoda và trở thành nền tảng của hệ thống sản xuất Toyota (Toyota Production System). Với mỗi câu trả lời, tiếp tục hỏi "Tại sao?" cho đến khi bạn chạm được nguyên nhân gốc rễ, thường chỉ sau 4-5 lần hỏi.

Áp dụng vào case study:

1. Tại sao PR mất 3 ngày để merge? → Vì reviewer thường bận, không review ngay khi PR được mở.
2. Tại sao reviewer bận? → Vì mỗi reviewer phải xử lý trung bình 8 PR/tuần, ngoài công việc code chính của họ.
3. Tại sao lại có nhiều PR dồn lên mỗi reviewer đến vậy? → Vì trong team 10 người, chỉ có 2 senior engineer đủ điều kiện được chỉ định làm reviewer chính thức.
4. Tại sao chỉ 2 người đủ điều kiện review? → Vì quy định nội bộ (viết trong tài liệu onboarding từ 2 năm trước) yêu cầu reviewer phải có tối thiểu 3 năm kinh nghiệm tại công ty.
5. Tại sao lại đặt ngưỡng 3 năm kinh nghiệm? → Khi truy lại lịch sử, không ai trong team hiện tại (kể cả manager) nhớ rõ lý do cụ thể. Quy định này được kế thừa từ một tài liệu do người quản lý cũ (đã nghỉ việc) soạn thảo khi team mới thành lập, có thể xuất phát từ một sự cố production cụ thể nhưng chưa từng được xem lại kể từ đó.

Đến đây, nguyên lý gốc lộ ra: nút thắt cổ chai không nằm ở quy trình review kỹ thuật, mà nằm ở một quy định tùy tiện, đã lỗi thời, giới hạn số người đủ điều kiện tham gia review.

Phân biệt "nguyên lý gốc" và "giả định được ngụy trang"

Một sai lầm phổ biến ở bước này là dừng lại quá sớm, tưởng nhầm một giả định là nguyên lý gốc. Câu trả lời ở Why #3 ("chỉ có 2 người đủ điều kiện") nghe có vẻ như một sự thật – nhưng nó chỉ là hệ quả của một quy định (Why #4), chứ chưa phải gốc rễ. Dấu hiệu nhận biết bạn đã chạm đến nguyên lý gốc thực sự: câu trả lời không thể bị "Tại sao?" tiếp thêm một lần nữa mà vẫn tìm ra nguyên nhân sâu hơn có ý nghĩa – ở đây, việc quy định "3 năm kinh nghiệm" không có lý do rõ ràng nào còn hợp lệ chính là điểm dừng hợp lý, vì nó lộ ra bản chất: đây là một giả định chưa từng được kiểm chứng lại, không phải một ràng buộc kỹ thuật hay quy luật khách quan.

Bước 4: Xây dựng lại từ con số 0

Đây là bước sáng tạo nhất. Từ những dữ kiện gốc đã tìm được, hãy tự hỏi: "Nếu bắt đầu lại từ đầu, không bị ràng buộc bởi cách làm cũ, mình sẽ thiết kế giải pháp như thế nào?"

Quay lại case study, giải pháp mới có thể được xây dựng theo hướng:

• Phân loại PR theo mức độ rủi ro thay vì áp dụng một quy trình cứng nhắc cho mọi loại thay đổi: PR chạm vào payment/security/database migration cần 2 reviewer có kinh nghiệm; PR sửa UI, viết test, cập nhật docs chỉ cần 1 reviewer bất kỳ trong team.
• Mở rộng danh sách reviewer đủ điều kiện dựa trên đánh giá năng lực thực tế qua một bài kiểm tra code review mẫu, thay vì dựa vào thâm niên – có thể nâng từ 2 lên 5-6 người đủ điều kiện, giảm tải trung bình mỗi người từ 8 PR/tuần xuống còn 3-4 PR/tuần.
• Tự động hóa phần review có thể tự động hóa: thiết lập CI pipeline tự động chạy lint, test coverage, static analysis – để reviewer con người chỉ tập trung vào logic nghiệp vụ và kiến trúc, thay vì mất thời gian soi lỗi format.
• Giới hạn kích thước PR: khuyến khích chia nhỏ task thành PR dưới 200 dòng thay đổi, vì dữ liệu ngành (và nhiều nghiên cứu về code review) cho thấy PR nhỏ được review nhanh hơn đáng kể và tỷ lệ phát hiện lỗi cũng cao hơn so với PR lớn.

Giải pháp này không đến từ việc "copy quy trình của công ty khác", mà đến trực tiếp từ việc hiểu bản chất của nút thắt: vấn đề không phải là thiếu quy trình review, mà là một giả định lỗi thời đang giới hạn nguồn cung reviewer một cách không cần thiết.

Đo lường lại sau khi triển khai

First Principles Thinking không dừng lại ở việc "thiết kế giải pháp mới" – bước cuối cùng, dù không được liệt kê chính thức trong 4 bước, là quay lại đo lường bằng chính chỉ số bạn đã dùng để định nghĩa vấn đề ở Bước 1. Nếu sau khi triển khai, thời gian merge PR trung bình giảm từ 3 ngày xuống còn 1 ngày, bạn có bằng chứng định lượng rằng giải pháp đang đi đúng hướng. Nếu không, đó là tín hiệu để quay lại Bước 2 hoặc Bước 3 – có thể vẫn còn một giả định ẩn khác chưa được phát hiện.

Lưu ý khi thực hành toàn bộ quy trình

• Viết ra giấy (hoặc document) từng bước, đừng chỉ nghĩ trong đầu – việc viết ra buộc bạn phải rõ ràng và trung thực với chính mình, đồng thời tạo ra tài liệu có thể chia sẻ, phản biện cùng team.
• Không vội kết luận ở bước 2 hoặc 3. Cảm giác "à mình hiểu rồi" thường xuất hiện sớm hơn thời điểm bạn thực sự chạm đến nguyên lý gốc – đây là một dạng thiên kiến gọi là "premature closure" (đóng kết luận quá sớm) trong tâm lý học nhận thức.
• Làm việc theo nhóm nhỏ (3-5 người) thường hiệu quả hơn làm một mình, vì mỗi người sẽ phát hiện những giả định khác nhau dựa trên góc nhìn và kinh nghiệm riêng. Cân nhắc chỉ định một người đóng vai "devil's advocate" – chuyên đặt câu hỏi phản biện cho mọi giả định được nêu ra.
• Giới hạn thời gian cho mỗi bước (ví dụ: 15-20 phút/bước trong một buổi workshop) để tránh sa đà vào phân tích vô tận (paralysis by analysis).

Kết bài

Quy trình 4 bước này nghe đơn giản trên giấy, nhưng đòi hỏi sự kiên nhẫn và trung thực trí tuệ khi thực hành. Ở bài tiếp theo, chúng ta sẽ xem cách áp dụng cụ thể quy trình này vào bối cảnh công việc thực tế – đặc biệt là trong lĩnh vực kỹ thuật và quản lý, với nhiều ví dụ và tình huống cụ thể hơn nữa.

👉 Đón đọc Bài 3: First Principles trong Công việc – "Vũ khí" của Kỹ sư và Nhà quản lý