Công cụ tư duy mà kĩ sư phần mềm nào cũng cần biết

Kỹ năng lập trình đưa bạn vào ngành, nhưng cách bạn tư duy sẽ quyết định bạn đi xa tới đâu trong sự nghiệp.

Jan 19, 2025

Tại sao một số kỹ sư có thể giải quyết vấn đề nhanh gọn lẹ và giao tiếp hiệu quả, trong khi người khác thì loay hoay mãi?

Chúng ta đều biết, hiệu suất làm việc không chỉ đến từ kỹ năng lập trình, mà còn phụ thuộc vào cách tư duy và phân tích vấn đề.

Trong bài viết hôm nay, mình sẽ chia sẻ với bạn một công cụ tư duy đơn giản nhưng cực kỳ mạnh mẽ – MECE. Đây là phương pháp mà mình đã áp dụng nhiều lần để giải quyết những vấn đề phức tạp và làm việc hiệu quả hơn.

📚 MECE là gì? Tại sao lại cần biết?

Giải thích ngắn gọn: MECE (Mutually Exclusive, Collectively Exhaustive)1 là một cách tiếp cận tư duy có cấu trúc, giúp bạn chia nhỏ và phân loại vấn đề sao cho:
Mutually Exclusive-ME (không trùng lắp): các phần được chia không chồng chéo.
Collectively Exhaustive-CE (đầy đủ): không bỏ sót bất kỳ phần quan trọng nào.

Để dễ hiểu hơn, hãy cùng xem một ví dụ đơn giản sau. Hãy tưởng tượng bạn đang suy nghĩ: "Tối nay ăn gì?". Thay vì đau đầu suy nghĩ, ta có thể chia ra làm hai lựa chọn: ăn ngoài hoặc ăn nhà2. Dựa trên nguyên tắc MECE, chúng ta có thể phân tích như sau:

Không trùng lắp: rõ ràng là bạn không thể vừa ăn ở nhà vừa ăn ngoài được.
Đầy đủ: chắc chắn là bạn phải ăn ở một trong hai nơi này rồi.

Áp dụng MECE cho câu hỏi “tối nay ăn gì?”

Từ đây, có thể thấy MECE giúp chúng ta không chỉ đơn giản hóa suy nghĩ mà còn đảm bảo không bỏ sót yếu tố nào. Điều này càng quan trọng hơn trong các tình huống phức tạp, đặc biệt là khi áp dụng vào công việc lập trình, nơi yêu cầu phân tích vấn đề một cách toàn diện và có hệ thống.

Trong bài viết này, hãy xem cách MECE được áp dụng qua ba tình huống cụ thể mà mình đã trải nghiệm:

Debug khi hệ thống gặp vấn đề
Giao tiếp trong công việc
Lên kế hoạch cho dự án

Bắt đầu nào!🚀

👋 Hey, nếu đây là lần đầu bạn đọc newsletter này, thì xin tự giới thiệu mình là Bryant (Dũng). Chào mừng bạn đến Growth Engineering Journal - newsletter hàng tuần của mình, nơi mình chia sẻ về tư duy phát triển bản thân và những thứ hay ho cho kĩ sư phần mềm 😜.

🔍 Ba tình huống áp dụng thực tế

Use case #1: chẩn đoán và xử lý sự cố 🛠️

Tưởng tượng hệ thống đang chạy ngon lành bỗng một ngày bạn nhận được report từ user rằng thời gian phản hồi rất chậm, đôi khi bị đơ hoặc không sử dụng được (lỗi 500 internal server error) ảnh hưởng tới trải nghiệm và business output. Trong trường hợp này, thay vì hoang mang hay xử lý theo cảm tính, bạn có thể áp dụng MECE để phân loại nguyên nhân và giải quyết vấn đề một cách có hệ thống.

❌ Trước đây: phỏng đoán theo cảm tính “xé túi mù” rồi lao vào hì hục làm.

✅ Giờ đây: Mình tiếp cận vấn đề một cách có hệ thống hơn. Chúng ta có thể chia các nguyên nhân thành các nhóm không trùng lặp và đầy đủ như sau:

Nguyên nhân từ phía client (frontend): payload api không đúng, logic code Javascript bị sai…
Nguyên nhân từ phía server (backend): endpoint API dính edge case mà chưa xử lý, server log có exception…
Nguyên nhân từ database: lỗi kết nối, câu query không tối ưu, database timeout…
Nguyên nhân do từ hạ tầng (infrastructure): database trên cloud bị gần đầy bộ nhớ, cloud provider gặp sự cố…
Nguyên nhân khác: deployment bị lỗi

🌟 Với cách tiếp cận này, lợi ích đạt được là:

Tăng xác suất khoanh vùng và tìm ra vấn đề.
Cả team cùng chung một hệ quy chiếu thay vì mỗi người làm một kiểu.
Phân chia công việc hợp lý hơn, rút ngắn thời gian fix bug.

Fix bug là “nghiệp” của anh em làm kĩ sư phần mềm. Ngoài việc tích lũy kinh nghiệm, kĩ năng phân tích và khoanh vùng sự cố sẽ giúp bạn nhận diện và giải quyết vấn đề hiệu quả hơn.

Tất nhiên, việc áp dụng MECE không đảm bảo 100% thành công, nhưng trong phần lớn trường hợp thì nó chắc chắn hiệu quả hơn nhiều so với cách tiếp cận không có hệ thống.

Use case #2: giao tiếp với dân non-technical 🗣️

Ứng dụng web của công ty đang gặp vấn đề chạy chậm, khiến người dùng phải chờ lâu khi tải trang. Và bạn cần giải thích vấn đề này với một trưởng phòng kinh doanh không có nền tảng kỹ thuật. Trong trường hợp này, làm thế nào để truyền đạt một vấn đề kỹ thuật phức tạp một cách rõ ràng và dễ hiểu?

❌Nếu là mình phiên bản trước đây thì mình sẽ trả lời:

Tuy nhiên, đây là một cách trình bày chưa thực sự hiệu quả. Thông tin lộn xộn, không có cấu trúc rõ ràng, và rất khó hiểu đối với người không có nền tảng kỹ thuật.

✅ Thử cách tiếp cận khác theo MECE xem:

"Hệ thống của chúng ta đang bị chậm vì ba nhóm nguyên nhân chính:
Giống như nhà hàng bị quá tải: server của chúng ta đang phải phục vụ quá nhiều khách cùng lúc.
Giống như thư viện sách không được sắp xếp tốt: database của chúng ta mất nhiều thời gian để tìm thông tin, nhất là khi dữ liệu ngày càng nhiều.
Giống như việc không có tủ đồ cá nhân: chúng ta chưa có hệ thống lưu trữ tạm (cache) nên phải đi lấy cùng một thông tin nhiều lần.
Để giải quyết, chúng ta có hai giai đoạn:
Ngắn hạn: triển khai cache - giống như việc bố trí tủ đồ để tiện lấy đồ thường xuyên dùng.
Dài hạn: tối ưu database và nâng cấp server khi cần - giống như việc sắp xếp lại thư viện và mở thêm quầy phục vụ trong nhà hàng."
Với cách tiếp cận này, chúng ta sẽ cải thiện tốc độ phản hồi của hệ thống mà không làm gián đoạn người dùng hiện tại."

🌟 Cách trình bày này tốt hơn vì:

Thông tin có cấu trúc rõ ràng
Sử dụng ẩn dụ đời thường dễ hiểu3
Đưa ra lộ trình giải quyết cụ thể
Thể hiện được sự chuyên nghiệp của bạn

Cho dù bạn làm startup hay big tech, dù là công ty outsource hay product thì bạn cũng cần phải phối hợp để giải quyết vấn đề, nên việc điều chỉnh cách tiếp cận khi giao tiếp không chỉ thuận tiện trong trao đổi mà còn xây dựng niềm tin và giúp bạn tạo hình ảnh nổi bật hơn so với phần còn lại trong team.

Bạn biết ai đang cần những bài học này không? Hãy Share bài viết để truyền cảm hứng đến họ!

Use case #3: lập kế hoạch

Tình huống quen thuộc: dự án có cả đống tính năng trong backlog, từ yêu cầu của khách hàng, cải tiến kỹ thuật, đến mục tiêu kinh doanh. Làm sao để ưu tiên công việc một cách hợp lý và minh bạch với tất cả các bên liên quan?

Thay vì chỉ dựa vào cảm tính hoặc phó mặc cho PM quyết định, bạn có thể thử áp dụng MECE như sau:

👤 Những việc người dùng cần (User requirements): các tính năng ảnh hưởng trực tiếp đến trải nghiệm người dùng.
🛠️ Những việc hệ thống cần (Technical enhancement & debts): sửa lỗi hoặc cải thiện hiệu suất hệ thống.
💼 Những việc kinh doanh cần (Business requirements): các tính năng tạo doanh thu hoặc giúp đạt mục tiêu kinh doanh.

Dựa trên phân tích này, kết hợp với phương pháp Eisenhower4 mình đã tổ chức cuộc họp và chủ động dẫn dắt để xây dựng roadmap gồm:

Việc gấp: tập trung vào những tính năng ảnh hưởng trực tiếp đến trải nghiệm người dùng.
Việc quan trọng: tối ưu hệ thống để chuẩn bị cho tương lai.
Việc nền tảng: xây dựng quy chuẩn code và hệ thống giám sát để tránh "nợ kỹ thuật" trong tương lai.

Bằng cách trình bày kế hoạch này với các bên liên quan, bạn không chỉ giúp họ hiểu rõ đâu là ưu tiên mà còn tăng tính thuyết phục. Ví dụ: phân bổ effort theo tỷ lệ 50% cho mục tiêu kinh doanh, 40% cho nhu cầu người dùng, và 10% cho cải tiến kỹ thuật.

🌟 Cách này có gì hay?

Dễ theo dõi: mọi người đều hiểu đang làm gì và tại sao
Thuyết phục: các bên liên quan thấy được kế hoạch rõ ràng
Cân bằng: không bỏ quên yếu tố nào

Tuy nhiên, đừng lạm dụng MECE❗️

Mặc dù nguyên tắc MECE là một công cụ tư duy vô cùng hữu ích trong việc phân tích và giải quyết vấn đề, nó cũng có những hạn chế nhất định. Dưới đây là một số điểm hạn chế bạn cần lưu ý:

Tính linh hoạt: trong phát triển phần mềm, đặc biệt là Agile methodology, yêu cầu thường thay đổi nhanh chóng. Việc cố gắng duy trì một cấu trúc MECE quá chặt chẽ có thể làm giảm khả năng thích ứng với những thay đổi này.
Độ phức tạp của hệ thống: các hệ thống phần mềm thường có nhiều mối quan hệ phức tạp giữa các module, component. Việc phân chia hệ thống thành các phần hoàn toàn độc lập đôi khi là không khả thi hoặc không hiệu quả. Chưa kể là những hệ thống legacy lâu đời thì việc nắm hết được mọi thứ gần như bất khả thi.
Tính chủ quan: cách phân chia MECE thường phụ thuộc vào kinh nghiệm và hiểu biết của người phân tích. Điều này có thể dẫn đến những cách phân chia khác nhau cho cùng một vấn đề.

Việc biết khi nào nên và không nên áp dụng MECE là cả một nghệ thuật. Đôi khi chúng ta phải trải qua đủ nhiều thất bại mới tìm được những cách giải quyết vấn đề tốt hơn. May mắn là những cách này đã được đúc kết thành những nguyên lý như MECE là một ví dụ.

Nhưng chúng chỉ thực sự trở thành một phần trong cách tư duy của chúng ta khi ta đã trải nghiệm và chiêm nghiệm đủ nhiều từ chính công việc của mình.

📖 TL;DR

MECE (Mutually Exclusive, Collectively Exhaustive) là công cụ giúp phân tích vấn đề có hệ thống, đơn giản là chia để trị một cách thông minh.

Ba tình huống thực tế mình áp dụng MECE:

🐞🔍 Debug: phân loại nguyên nhân lỗi thành các nhóm rõ ràng để tăng hiệu quả tìm bug
🗣️📊 Giao tiếp: trình bày vấn đề kỹ thuật cho dân non-technical một cách dễ hiểu.
🗂️📅 Lập kế hoạch: sắp xếp backlog và ưu tiên công việc hợp lý hơn.

⚠️ Lưu ý: MECE không phải chìa khóa vạn năng - cần linh hoạt áp dụng và kết hợp với các phương pháp khác.

📚✨ Bài học quan trọng nhất: Những nguyên lý này chỉ thực sự có giá trị khi ta đã trải nghiệm và rút ra bài học từ chính công việc của mình

✌️ Bài hôm nay chỉ có thế

Bạn đã thử áp dụng MECE chưa? Nếu có, hãy chia sẻ một tình huống mà bạn thấy nó hiệu quả nhất – hoặc nếu bạn gặp khó khăn, mình rất muốn nghe câu chuyện của bạn để cùng thảo luận thêm (vì chúng ta học được nhiều nhất từ kinh nghiệm của nhau và trên hết nếu bạn đã làm được đến mức này thì mình rất rất trân trọng 🙏🏻). Đừng ngần ngại để lại comment nhé, chắc chắn mình sẽ phản hồi!

Growth Engineering Journal