Hồi mình mới bắt đầu đi làm, mình hay bị mắc kẹt trong kiểu “có vấn đề là lao vào giải liền”. Cứ thấy bug, thấy task khó là nhào vô xử, không cần biết vấn đề đó nằm trong bối cảnh nào, có liên quan gì tới cái khác không. Hậu quả là giải xong cái này thì phát sinh cái kia, vòng lặp cứ thế tiếp diễn.
Rồi một ngày mình tình cờ đọc được cuốn “Tư Duy Đột Phá” (Breakthrough Thinking) của Shozo Hibino và Gerald Nadler. Và mình nhận ra một điều: vấn đề không phải là thiếu giải pháp, mà là cách mình đặt vấn đề sai từ đầu.
Ảnh: Nikolai Ulltang trên Pexels
Tóm tắt nhanh về tác giả
Shozo Hibino là giáo sư người Nhật chuyên về quản lý và giải quyết vấn đề sáng tạo. Ông nổi tiếng với phương pháp “Bảy công cụ cho kế hoạch sản phẩm mới”.
Gerald Nadler là giáo sư emeritus về kỹ thuật hệ thống tại Đại học Nam California (USC). Ông dành nhiều năm nghiên cứu về tư duy hệ thống và áp dụng nó vào giải quyết vấn đề trong doanh nghiệp.
Hai ông kết hợp lại cho ra cuốn sách này, và nó đã trở thành một trong những tác phẩm kinh điển về tư duy sáng tạo trong quản lý.
7 nguyên tắc tư duy đột phá
Điểm mình thích nhất là cuốn sách không chỉ nói lý thuyết suông, mà đưa ra 7 nguyên tắc cụ thể mà ai cũng có thể áp dụng:
1. Nguyên tắc về sự khác biệt độc đáo (Uniqueness)
Mỗi vấn đề là độc nhất. Đừng áp dụng công thức cũ cho vấn đề mới. Mình thấy nguyên tắc này đúng nhất khi làm code — mỗi cái bug, mỗi cái feature đều có context riêng, cứ copy-paste solution cũ là tự tạo technical debt thôi.
2. Nguyên tắc triển khai mục đích (Purposive Focus)
Thay vì hỏi “làm sao để giải quyết?”, hãy hỏi “tại sao mình cần giải quyết cái này?”. Khi mình đặt câu hỏi “tại sao” đủ sâu, nhiều khi vấn đề tự nhiên biến mất hoặc hoá ra nó không phải là vấn đề thật sự.
3. Nguyên tắc giải pháp tiếp theo (Next Solution)
Không cần phải có giải pháp hoàn hảo ngay từ đầu. Hãy chọn giải pháp tốt nhất cho bước tiếp theo, rồi từ đó điều chỉnh dần. Cứ như kiểu agile vậy — chạy sprint, rồi retrospective, rồi cải tiến.
4. Nguyên tắc thiết lập hệ thống (Systems)
Nhìn vấn đề trong một hệ thống tổng thể, không chỉ là một mảnh riêng lẻ. Trong .NET, nếu mình chỉ tối ưu một cái endpoint mà không nhìn vào cả architecture, thì sớm muộn cũng đụng phải bottleneck chỗ khác.
5. Nguyên tắc thu thập thông tin có giới hạn (Limited Information Collection)
Đừng thu thập quá nhiều thông tin. Càng thu thập, càng bối rối và trì hoãn quyết định. Hãy chỉ thu thập đủ để đưa ra quyết định cho bước tiếp theo — đó là nguyên tắc mình thấy hữu ích nhất.
6. Nguyên tắc lôi kéo người khác tham gia (People Involvement)
Đừng giải quyết vấn đề một mình. Kéo người khác vào. Mỗi góc nhìn khác nhau sẽ cho bạn một mảnh ghép khác nhau. Trong công việc, mình áp dụng bằng cách luôn code review với đồng nghiệp, dù chỉ là feature nhỏ nhất.
7. Nguyên tắc cải tiến liên tục (Continuous Improvement)
Không có giải pháp nào là vĩnh viễn. Luôn cải tiến từng ngày, từng chút một. Cứ như refactor code vậy — mỗi lần touch vào một file, hãy để nó sạch hơn lúc mới thấy.
Ảnh: Arturo Añez trên Pexels
Tư duy đột phá trong thực tế
Có một câu chuyện mình nhớ mãi từ cuốn sách này: một công ty sản xuất gặp vấn đề với máy móc luôn bị hỏng hóc. Ai cũng tập trung vào việc sửa máy, tối ưu quy trình sửa chữa. Cho tới khi có người hỏi: “Tại sao máy lại hỏng?”. Hoá ra nguyên nhân là do bụi từ khu vực đóng gói. Giải pháp? Đặt một cái quạt. Chỉ vậy thôi.
Nguyên tắc số 2 (Purposive Focus) đã giúp họ không phí thời gian tối ưu cái sai.
Là một .NET developer, mình thấy cuốn sách này đặc biệt hữu ích khi:
- Design system architecture — thay vì vội vã implement, hãy dùng nguyên tắc Systems để nhìn tổng thể
- Debug — dùng Purposive Focus để xác định đúng nguyên nhân gốc rễ
- Code review — dùng People Involvement để có nhiều góc nhìn
Kết luận
Tư Duy Đột Phá không phải là một cuốn sách self-help kiểu “hãy nghĩ tích cực lên”. Nó là một phương pháp luận thực tế để giải quyết vấn đề.
Điểm 10/10 cho nội dung, nhưng hơi trừ một chút vì sách viết khá học thuật và có thể hơi khô với người mới bắt đầu. Nhưng nếu bạn là dân kỹ thuật (dev, PM, system architect), cuốn này là must-read.
Mình đọc và áp dụng được kha khá nguyên tắc vào công việc hàng ngày, nhất là cái Limited Information Collection — cái này cứu mình khỏi cảnh phân tích quá lâu mà không dám quyết định.
Còn anh em nào đọc rồi thì cho mình hỏi: nguyên tắc nào bạn thấy hữu ích nhất? Comment bên dưới nha! 😊
Bài review sách liên quan
