Py có một sở thích vô-tình-tích-cực là tìm cách áp dụng phương pháp, cách tiếp cận thường được sử dụng ở lĩnh vực này sang chuyên môn khác. Thao tác này đối với não giống như luyện viết chữ bằng tay không thuận. Kết quả, cùng một vấn đề, Py nhìn thấy cách khai thác mới đầy thú vị, hoặc thậm chí có đôi lần phải “Euréka!” vì hóa ra có nhiều chuyện có thể được lý giải theo cách đơn giản đến vậy.
Mở bài dài dòng chẳng qua để thể hiện phần nào “sự ưu ái” của Py đối với MECE, hay còn được nhắc đến là nguyên tắc “Không bao gồm, không bỏ sót”. Thuở đầu, Py cũng nhận định MECE như một “công cụ” để trình bày slide thuyết trình cho mạch lạc và logic, chỉ là trong suốt một khoảng thời gian dài buộc bản thân phải MECE, vô tình, cách lập luận của Py dần nhận được những mỹ từ như “sắc sảo”, “bén’ – dĩ nhiên có nhiều yếu tố khác cộng hưởng vào sự công nhận này, nhưng chắc chắn đóng góp của MECE là không nhỏ.
Lý thuyết
MECE1 là viết tắt của Mutually Exclusive, Collectively Exhaustive, nghĩa là “Các nhóm loại trừ lẫn nhau và bao quát toàn diện”. Đây là một phương pháp tư duy phổ biến trong phân tích vấn đề và ra quyết định. Cụ thể, MECE giúp phân chia một tập hợp phức tạp thành các phần riêng biệt, không chồng chéo (Mutually Exclusive) và bao quát toàn bộ vấn đề (Collectively Exhaustive). MECE được McKinsey phổ biến rộng rãi, nhằm tối ưu hóa cách tư duy logic khi giải quyết các vấn đề chiến lược kinh doanh. Cách tiếp cận này giúp đảm bảo rằng không có khía cạnh nào bị bỏ sót hoặc trùng lặp khi phân tích dữ liệu hoặc lập kế hoạch.
Để dễ nhớ hơn, như Py có giới thiệu ở trên, MECE có thể dịch gọn là “Không bao gồm và không bỏ sót” – big thanks đến các anh chị ở PMax vì bài training siêu hiệu quả. Nhưng trên thực tế thì thường dễ “ME” hơn “CE”, tức là khó có thể xác định toàn vẹn các thành tố của vấn đề nhưng vẫn có thể đảm bảo mỗi thành phần không trùng lặp lẫn nhau.
Thực hành
MECE là nguyên tắc, nên về cơ bản, MECE không có hình dạng2. Còn đối với PO thì MECE thường hiện diện ở:
- Issue Tree: một sơ đồ mapping đơn giản giữa vấn đề – giải pháp
- Mindmap: công cụ phổ biến vẽ ra các luồng tư duy khi phân tích
- User Flow: (thường được hiểu là) chuối các hành động user cần thực hiện để hoàn thành một “tác vụ”
hoặc thậm chí là user story, roadmap, user journey mapping…, vì câu hỏi muôn thuở mà PO cần giải quyết luôn là: đã define hết tất cả các case chưa?
Mẹo nhỏ được truyền miệng là logic “1-” (một trừ), tức là lý tưởng nhất, từ một vấn đề nên được tách nhỏ thành 2 vấn đề có tổng bằng 1, rồi từ mỗi nhánh lại tiếp tục chẻ nhỏ theo kiểu “1-”. Ví dụ, khi define các trạng thái gửi tin nhắn thì luôn tồn tại “Đã gửi” và “Chưa gửi = 1- Đã gửi”; tương tự như vậy, đối với “Đã gửi” thì sẽ tồn tại ít nhất 2 trạng thái “Thành công”, “Thất bại”, hoặc nếu toàn diện hơn hơn thì nên đề cập đến “Không xác định”. Nhưng điều quan trọng nhất để “ME” có lẽ là xác định dimension2 phù hợp, lại là một bài toán cần được giải bằng “common sense” nên chia sai nhiều lần tự nhiên sẽ biết cách chia hợp lý.
Dù vậy, để “ME” thì vẫn dễ hơn “CE” vì “tất cả” giống như vô cực, đều là khái niệm ở bờ lý tưởng, mà để CE thì lại quay về bài toán domain knowledge hoặc “giờ bay”; nên nhắc lại khẩu huyết: đọc nhiều vào, quan sát nhiều vào. Chẳng hạn như để “CE” khi define các stages trong journey đặt vé xem phim của user thì việc đầu tiên nên nghĩ đến là research các user journey tương tự, xem các map này thường được chia làm mấy stages, tự refine lại các stages này để phù hợp với mục tiêu research và bài toán cần giải quyết. Hoặc có thể bám theo Công thức bán hàng cơ bản nhất – AIDA3 – Attention (Thu hút), Interest (Thích thú), Desire (Khao khát), Action (Hành động), rồi lại localize các stage về bối cảnh là các tính năng đang làm.
Thêm nữa, đôi khi phân tích vấn đề kiểu MECE sẽ phát sinh rất nhiều “luồng” cùng tồn tại song song, nên thường MECE sẽ được áp dụng song hành cùng các nguyên tắc khác, phổ biến nhất có lẽ là nguyên tắc Pareto4, tên thường gọi là 80/20, còn nickname ít người biết là “Big Head Long Tail”. Nói theo cách ngắn gọn: tập trung vào những gì hiệu quả; còn theo đúng câu chữ: khoảng 80% hậu quả đến từ 20% nguyên nhân, nên cần ưu tiên giải quyết tốt 20% này.
Miễn trách
Thành thật mà nói Py không biết cách áp dụng MECE chuẩn, chủ yếu là dùng thế nào thấy thuận tay và có hiệu quả thì cứ duy trì. Với nhiều câu hỏi hàng ngày, Py cũng hay MECE như bài tập dành cho não. Ví dụ, câu trả lời cho câu hỏi “Hôm nay ăn gì?” thường bắt đầu với dimension món khô hay món nước, hoặc ăn chay hay ăn mặn; từ đó lại tiếp tục phân nhỏ và loại trừ dần đến còn lại sự lựa chọn hợp lý nhất.
Vẫn phải nhắc lại một chút, MECE cũng không phải là nguyên tắc bắt buộc mọi PO cần nắm rõ, vì tư duy của mỗi người vốn khác nhau và dĩ nhiên cách tiếp cận cũng có sự khác biệt giữa nhiều PO dù là trên cùng một vấn đề – tương tự như Elevator Pitch. Nên những dòng chia sẻ này cốt yếu chỉ mong mang đến “góc nhìn” mà bạn cũng sẽ thấy thú vị như Py đang nhận định.
[1] McKinsey Alumni, Barbara Minto: “MECE: I invented it, so I get to say how to pronounce it”, link
[2] PrepLounge, MECE Principle, link
[3] Chiến lược Marketing, 2017, AIDA: Công thức bán hàng cơ bản nhất, link
[4] Better Explained, Understanding the Pareto Principle (The 80/20 Rule), link
Cám ơn bạn đã nán lại cho đến những dòng cuối cùng này.
Chúc bạn nhiều may mắn và bình an.
Anpy
Leave a Reply