[Critical Thinking] Lối suy nghĩ đặt giả thuyết (Hypothetical Thinking)

Chào cả nhà. Trước tiên mình muốn giới thiệu tổng thể về Critical Thinking, mọi người có thể tham khảo tiếng Nhật tại:

https://kotobank.jp/word/クリティカル・シンキング-2099758

hoặc tiếng Anh tại:

https://www.indeed.com/…/caree…/critical-thinking-skills

(mỗi nguồn lại có cách liệt kê skills set khác nhau)

Tổng thể này hơi to và đa dạng, nên trong bài viết lần này mình chỉ chia sẻ về Lối suy nghĩ đặt giả thuyết.

1. Phân loại giả thuyết theo mục đích


1.1. Giả thuyết cho kết luận

Khác với vồ vập đốt cháy giai đoạn “jump to conclusion” thì ở mục này, chúng ta đặt ra giả thuyết rồi kiểm chứng, sau đó mới kết luận. Cách này sử dụng “sự tinh tế”, kinh nghiệm, v.v. để đẩy nhanh quá trình thay vì đi mân mê dò đường theo mép tường. Một ví dụ có lẽ ai cũng đã từng trải qua đó là trong Toán học, nhẩm nghiệm rồi chứng minh nó là nghiệm (trong một số trường hợp có chứng minh nó là duy nhất).


1.2. Giả thuyết để giải quyết các câu hỏi 5W2H, lấp nhưng mảng còn trống hổng.

2. Tiền đề đặt giả thuyết:

[Critical Thinking] Lối suy nghĩ đặt giả thuyết (Hypothetical Thinking)
“kinh nghiệm” hay “thường thức” có thể gây ra định kiến sai khác với hiện thực của trường hợp cụ thể

2.1. Thông tin khách quan (thường thức), những điều quan sát được.

Ví dụ là giai thoại Isaac Newton bị quả táo rơi trúng đầu hay Archimedes tắm tràn nước.


2.2. Tri thức, kinh nghiệm trong lĩnh vực liên quan.


Mỗi người thuộc lĩnh vực khác nhau có kinh nghiệm khác nhau nên cũng có thể đặt giả thuyết khác nhau. Nếu team có thành phần đa dạng để tham khảo nhiều giả thuyết, có thể tham khảo căn cứ để định hướng kiểm chứng.
Ví dụ về kiểu đặt giả thuyết này có lẽ thường gặp ở Risk Assessment (Đánh giá rủi ro), điển hình là ở nhà máy hay công trường xây dựng, khi thao tác với các máy móc hạng nặng có thể gây tai nạn khi bất cẩn. Dựa vào kinh nghiệm mà các thành viên đưa ra giả thuyết những tai nạn như thế nào có thể xảy ra, và do đó, hội đồng quyết định phương án kiểm soát tương ứng.

Mặt khác, “kinh nghiệm” hay “thường thức” có thể gây ra định kiến sai khác với hiện thực của trường hợp cụ thể. Vấn đề này sẽ được bàn luận ở phần khác sau này.

3. Các technique trong quy trình đặt giả thuyết


3.1. Công thức Toyota: Đặt câu hỏi “Tại sao” lặp đi lặp lại 5 lần (có thể ít hơn hay nhiều hơn cho đến khi lần tới gốc rễ của vấn đề)

Tham khảo tại video ngắn sau: https://www.youtube.com/watch?v=SrlYkx41wEE

3.2. Thay đổi góc nhìn, đặt địa vị khác (thường gặp trong báo chí).

Có thể bắt gặp ví dụ về kiểu suy nghĩ đặt mình vào địa vị người khác trong các logic riddle của Ted-Ed. Vốn dĩ là mỗi người có mục đích, mục tiêu và tài nguyên khác nhau nên cách tiếp cận cùng một vấn đề sẽ khác nhau.

Các bạn có thể theo dõi thêm video sau “Can you solve the pirate riddle?” – Alex Gendler để hiểu thêm nhé: https://www.youtube.com/watch?v=Mc6VA7Q1vXQ

3.3. Đặt giả thuyết cho tương lai dựa trên các dữ liệu quá khứ.

Có lẽ mọi người đều từng trải hành động này. Đơn cử như tình cờ phát hiện 1 lỗi trong hệ thống, thì chúng ta cũng dự lượng cùng 1 lỗi này sẽ tiếp tục phát sinh trong tương lai, do đó cần phải đặt ra phương pháp vá lỗi.

4. Trau chuốt lại giả thuyết

Tiếp tục đặt câu hỏi, so sánh với thông tin mới và lần lại về khởi điểm xem giả thuyết này có phục vụ giải quyết câu hỏi ban đầu của chúng ta hay không. Tránh đi lạc sang địa bàn hoàn toàn khác, sau khi rẽ nhiều lần.

5. Kiểm chứng

[Critical Thinking] Lối suy nghĩ đặt giả thuyết (Hypothetical Thinking)
Check tất cả các bước trung gian không thấy lỗi nhưng kết quả kiểm chứng không như ý muốn…

5.1. Lập kế hoạch kiểm chứng (5W2H), đặc biệt là phương pháp (How) có khả thi hay không?

5.2. Phân tích định tính và định lượng

5.3. Đánh giá và tái cấu trúc giả thuyết

Đối với các bạn viết code có lẽ cũng trải qua nhiều trường hợp không có bug khi compile, nhưng kết quả không chạy đúng ý muốn. Xây dựng prototype ở thế giới thực hay kế hoạch kinh doanh cũng vậy, check tất cả các bước trung gian không thấy lỗi nhưng kết quả kiểm chứng không như ý muốn thì cũng phải lần mò cấu trúc lại mô hình dựa trên các thông tin (data) mới được bổ sung.

Ví dụ về R&D sản phẩm hỗ trợ 1 động tác của người lao động. Sản phẩm thực hiện được đúng chức năng theo thiết kế, nhưng khi mời chào thì đối tượng được nhắm đến lại không có hứng thú. Hỏi ra thì lý do là cồng kềnh và đắt đỏ, trong khi tỷ lệ thời lượng thao tác được tự động hóa chỉ chiếm một lượng thời gian tương đối nhỏ so với tổng thể công việc của họ, nên cost performance không được như ý.

Do đó, trong marketing sản phẩm, có framework 4P: Product, Price, Place, Promotion; 3C: Company, Competitor, Customer; …

Bản thân mình làm R&D và cũng mới lững thững học sơ cua về sản phẩm hóa, cũng bị choáng ngợp với nhiều yếu tố chưa từng tính đến, nên bài viết này mang tính chia sẻ thông tin cùng nhau học thêm, hơn là chia sẻ kinh nghiệm, mong là có giá trị tham khảo. Nếu mọi người có nguồn nào chia sẻ nữa thì chia sẻ cho mình học hỏi thêm với.

Mọi đóng góp, trao đổi, ý kiến xây dựng về bài viết này xin được gửi về địa chỉ email: dilamtainhat.vpj@gmail.com.

Để lại bình luận

Địa chỉ email của bạn sẽ không được công khai