Chưa bao giờ việc tạo ra lời giải lại dễ dàng như bây giờ. Chỉ với vài lệnh, một mô hình AI có thể viết code, thiết kế giao diện, tổng hợp báo cáo và dựng một bản mô phỏng sản phẩm trong chốc lát. Công cụ càng mạnh, chúng ta càng dễ rơi vào cảm giác tiến bộ: số đầu việc được tích vào to–do list tăng lên đều đặn, dashboard chớp nhoáng đầy dữ liệu, slide trông như một tác phẩm nghệ thuật. Nhưng càng quan sát, tôi càng nhận thấy một nghịch lý: nhiều thất bại không đến từ việc làm kém, mà đến từ việc bỏ công bỏ sức những thứ không đáng làm. Nhiều dự án được đẩy gấp rút, chỉnh sửa và cải tiến liên tục, nhưng đi một đoạn đường dài rồi người ta mới thấy không có gì thực sự được giải quyết. Vấn đề không phải đội nhóm làm việc không hiệu quả, mà là vì từ đầu không ai dừng lại để hỏi xem đề bài có đúng hay không.

Tại sao chúng ta lại dễ lao vào giải pháp đến vậy?

Một phần vì “hội chứng hành động”: con người thích cảm giác hoàn thành. Áp lực deadline, mong muốn gây ấn tượng và thói quen “làm cho xong” khiến chúng ta nhảy vào triển khai mà quên mất bước xác định vấn đề. Mike Figliuolo, tác giả kiêm huấn luận viên về lãnh đạo, chỉ ra rằng nhiều nhóm vội vã lập kế hoạch mà không làm rõ vấn đề, tiêu chí thành công và quyết định cần đưa ra. Ông cảnh báo rằng bỏ qua bước này đồng nghĩa với lãng phí rất nhiều thời gian và nguồn lực. Câu hỏi “What problem are we trying to solve?” tưởng chừng quá hiển nhiên nhưng lại thường bị lãng quên giữa những checklist và họp hành.¹

Peter Drucker từng gói gọn sự khác biệt giữa việc làm và việc đáng làm bằng một câu nói đã trở thành kinh điển: “Efficiency is doing things right. Effectiveness is doing the right things.” Bạn có thể rất hiệu quả – làm việc đúng quy trình, nhanh hơn, ít tốn kém hơn – nhưng vẫn thất bại nếu đang leo chiếc thang đặt nhầm tường. Nhiều người nhầm lẫn giữa hiệu quả và hiệu lực. Hiệu quả nói về cách thức: làm nhiều hơn với ít nguồn lực, hoặc chạy dự án nhanh hơn. Hiệu lực nói về việc chọn lựa: tập trung vào những sáng kiến tạo ra giá trị và phù hợp với mục tiêu chiến lược. Vì vậy, Asana nhấn mạnh rằng cần ưu tiên hiệu lực trước rồi mới tối ưu hiệu quả. Làm đúng việc quan trọng hơn làm việc đúng cách. Những nhóm bận rộn cả ngày nhưng không bao giờ tiến gần mục tiêu lớn, đơn giản vì họ đã đầu tư vào những việc vô thưởng vô phạt.²

Rob Lambert, một nhà tư vấn phát triển đội ngũ, kể rằng ông từng thấy những công ty nơi nhân viên dành tới 90 % thời gian để trang trí slide cho các cuộc họp mà không ai biết slide đó giải quyết vấn đề gì. Ở một dự án chuyển đổi số khác, ban lãnh đạo tung khẩu hiệu “hiện đại hóa” và “tăng hiệu suất”, chi hàng triệu bảng Anh, nhưng không chỉ ra được điều cụ thể nào cần thay đổi. Hậu quả là dự án kéo dài vô tận mà không mang lại kết quả gì. Lambert kết luận rằng nếu chúng ta không hỏi “What problem are we trying to solve?”, mọi nỗ lực chỉ là tối ưu những vấn đề không hề tồn tại. Câu hỏi này buộc ta đối diện với thực tế: liệu có bằng chứng rõ ràng cho vấn đề, liệu nó có quan trọng, và liệu nó có phù hợp với chiến lược hay không.³

Làm thế nào để tránh được bẫy “hiệu suất”?

Để tránh chiếc bẫy hành động và tập trung đúng chỗ, Lemon’s Tribe thường dùng một bộ câu hỏi. Không phải là công thức thần kỳ, nhưng chúng giúp loại bỏ phần lớn “bài toán giả” trước khi đổ tiền bạc và thời gian vào giải pháp.⁴

• Đây có thật sự là vấn đề? Nghe thì đơn giản, nhưng rất nhiều dự án bắt đầu từ một sở thích cá nhân, một nhu cầu mơ hồ hoặc một yêu cầu mang tính trào lưu, chứ không phải một vấn đề thực sự. Mike Figliuolo nhấn mạnh rằng bước đầu tiên là định nghĩa rõ ràng vấn đề và quyết định cần đưa ra. Một cách kiểm tra đơn giản là đặt cho mình câu hỏi: nếu vấn đề này được giải quyết, điều gì sẽ tốt hơn? Nếu câu trả lời quá mơ hồ hoặc không ai biết chắc, có lẽ đây chưa phải một vấn đề mà là một ý tưởng thú vị chưa qua kiểm chứng.
• Ai đang “đau” vì nó? Một vấn đề chỉ đáng giải khi nó gây đau đớn cho một nhóm người cụ thể. Nhiều tổ chức hô hào “tăng năng suất” hay “chuyển đổi số” mà không ai trong tổ chức thực sự cảm thấy bức xúc. Nếu khách hàng không than phiền, nhân viên không gặp khó khăn, doanh thu không bị ảnh hưởng, có thể đây chưa phải vấn đề cấp thiết. Hãy nói chuyện với người dùng, xem dữ liệu, lắng nghe nhân viên tuyến đầu. Nếu không xác định được ai đang chịu đau, việc xây dựng giải pháp chỉ là giải quyết một giả định của chính bạn.
• Nếu giải được, tác động ra sao? Không phải bài toán nào cũng đáng giải ngay lập tức. Bạn cần ước lượng tác động: nó có giúp giữ chân thêm khách hàng, tăng doanh thu, giảm chi phí hay mở ra cơ hội mới không? Figliuolo khuyên rằng phải định nghĩa thành công trông như thế nào. Điều đó có nghĩa là đặt ra những chỉ số cụ thể, chẳng hạn đạt retention 90% hay giảm thời gian xử lý 50%. Nếu đầu tư hàng tháng trời mà chỉ đổi lại một cải thiện nhỏ, hãy cân nhắc xem nguồn lực có nên dành cho việc khác.
• Nếu không làm gì, chuyện gì xảy ra? Không làm gì cũng là một lựa chọn. Lambert chỉ ra rằng có những dự án được triển khai rầm rộ nhưng nếu dừng lại thì chẳng có chuyện gì xấu xảy ra. Câu hỏi này giúp bạn nhận ra cái giá của sự trì hoãn. Nếu không giải quyết mà khách hàng vẫn hài lòng, doanh thu không giảm và đội ngũ vẫn vận hành tốt, có lẽ vấn đề đó không đáng ở vị trí đầu danh sách.
• Chúng ta có đang giải quyết nguyên nhân gốc? Nhiều “vấn đề” chỉ là triệu chứng. Một ngày đẹp trời, bạn thấy số CSAT của chatbot chăm sóc khách hàng tụt; bạn vội tối ưu mô hình, nhưng nguyên nhân gốc có thể là do dịch vụ bị lỗi, khách hàng không hoàn thành được “hành trình” của họ, nên họ trút giận lên chatbot (lúc này đang đại diện công tư xử lý vấn đề cho khách hàng). Figliuolo nhắc rằng trước khi chạy đua với giải pháp, hãy dành thời gian xác định đúng vấn đề và quyết định cần đưa ra. Một kỹ thuật hữu ích là liên tục hỏi “Tại sao?” cho tới khi chạm tới căn nguyên. Khi xác định được gốc rễ, bạn có thể phát hiện ra giải pháp nằm ở một bộ phận khác hoàn toàn – ví dụ thay vì thêm tính năng, bạn cần cải thiện quy trình onboarding. Giải quyết đúng nguyên nhân giúp tránh việc đổ nguồn lực vào những cải tiến bề mặt. (Bạn có thể tìm đọc thêm bài viết về Problem Solving – Giải quyết vấn đề và nhiều hơn thế nữa (Kỳ 1) và Problem Solving – Giải quyết vấn đề và nhiều hơn thế nữa (Kỳ 2))

Chọn đúng vấn đề không chỉ là câu chuyện về quyết định, mà còn là câu chuyện về quản lý thời gian. Stephen R. Covey, trong cuốn The 7 Habits of Highly Effective People, nhấn mạnh rằng quản lý thời gian thực ra là quản lý giá trị – bạn cần một la bàn chứ không chỉ một chiếc đồng hồ. Ông phân chia công việc thành bốn nhóm: khẩn cấp và quan trọng, quan trọng nhưng không khẩn cấp, khẩn cấp nhưng không quan trọng, và không khẩn cấp lẫn không quan trọng. Nơi bạn nên dành nhiều thời gian nhất là ô “quan trọng nhưng không khẩn cấp” – những hoạt động như lên kế hoạch, học hỏi, suy nghĩ sâu giúp bạn hiểu rõ vấn đề và tránh bị kéo vào những việc vặt. Khi bạn đã xác định đúng bài toán, hãy bảo vệ thời gian của bản thân và đồng đội khỏi những yêu cầu khẩn cấp nhưng ít giá trị.⁵

Tạm kết

Sự bùng nổ của AI khiến chi phí tạo ra giải pháp gần như bằng không, nhưng cái giá của việc giải sai bài toán là thời gian, chi phí cơ hội, và cả sự nhiệt huyết của đội ngũ chuyên môn. Trong bối cảnh các công cụ tự động giúp bạn chạy nhanh hơn, lợi thế cạnh tranh không nằm ở tốc độ mà nằm ở khả năng xác định đúng hướng. Nếu chọn sai vấn đề, AI chỉ giúp bạn lạc đường nhanh hơn. Nói ngắn gọn, điều khó nhất trong giải quyết vấn đề không nằm ở câu trả lời, mà nằm ở câu hỏi. Thay vì vội vã nhảy vào viết code, làm slide hay vẽ roadmap, hãy dành thời gian đặt những câu hỏi trên. Khi bạn biết chắc mình đang giải đúng bài toán, kỹ năng và công cụ mới thực sự được sử dụng hiệu quả. Còn nếu không, mọi nỗ lực chỉ là trang trí cho một sai lầm.

---

Nguồn tham khảo

1. https://emeritus.org/insights/learn-how-to-define-the-problem-before-solving-it/ ↩︎
2. https://asana.com/resources/efficiency-vs-effectiveness-whats-the-difference ↩︎
3. https://www.cultivatedmanagement.com/what-problem-are-we-trying-to-solve/ ↩︎
4. https://emeritus.org/insights/learn-how-to-define-the-problem-before-solving-it/ ↩︎
5. https://www.franklincovey.com/courses/the-7-habits/habit-3/ ↩︎