“ปัญหา” คืออะไร? มีโครงสร้างเป็นยังไง? และทำไมการเข้าใจคำ ๆ นี้ถึงสำคัญ

ทุกคนน่าจะรู้จักกับคำว่า “ปัญหา” อยู่แล้ว เพราะมันเป็นสิ่งที่เราต้องตื่นมาเจอทุกวัน

บางคนอาจจะนึกถึงความลำบากที่ต้องตื่นเช้าไปทำงานหรือไปโรงเรียนให้ทัน บางคนอาจจะนึงถึงการแก้โจทย์ปัญหาหรือการแก้ puzzle อะไรยาก ๆ หรือบางคนอาจจะนึกถึงคำถามที่บางทีก็ยังหาคำตอบไม่ได้ เช่น “ชาบู หรือ หมูกระทะ?” หรือ เราเรียนคณิตศาสตร์ไปทำไม ?

แต่ในบทความนี้เราอยากจะชวนทุกคนมาคุยให้ลึกลงไปกว่านี้นิดนึงกับคำว่า “ปัญหา” หรือ “Problem” ซึ่งเป็นคำที่อยู่ในชีวิตประจำวันของเรา เป็นคำที่เราคุ้นเคยกับมันมาก ๆ คุ้นเคยซะจนบางทีเราอาจจะลืมมองว่าภาพที่ชัดเจนของคำ ๆ นี้เป็นยังไง (และมันคงจะไม่ make sense ถ้าหากว่าเราสนใจในเรื่องของการแก้ปัญหา แต่ไม่พยายามเห็นภาพของคำว่าปัญหาให้ชัดซะก่อน)

นิยามของปัญหา

“ปัญหาคืออะไร ลองนิยามในแบบของตัวเอง ?”

ถ้าหากถามว่าปัญหาคืออะไร แน่นอนว่าแต่ละคนคงมีนิยามของตัวเองที่ไม่เหมือนกัน จากที่เราเคยได้ไปแชร์เรื่องนี้และมีโอกาสทำ poll เล่น ๆ เกี่ยวกับนิยามของคำว่าปัญหาของแต่ละคน ก็พบว่ามีคำตอบที่หลากหลายมาก และแต่ละอันก็แสดงให้เห็นความเหมือนและความแตกต่างบางอย่าง

“สิ่งที่ต้องเผชิญและแก้ไข”

“สิ่งที่เป็นอุปสรรคหรือสิ่งที่มันไม่เป็นอย่างที่มันควรจะเป็น”

“สิ่งที่เกิดขึ้นเมื่อทำอะไรบางสิ่งแล้วไปต่อไม่ได้ หรือต้องหยุดไปกลางคัน”

“สถานการณ์หรือเงื่อนไขที่ไม่เป็นไปตามที่คาดหวังหรือต้องการ ซึ่งสามารถเป็นเรื่องที่ท้าทายและส่งผลกระทบต่อความสบายใจหรือการดำเนินชีวิตของเรา”

แน่นอนว่านิยามเหล่านี้ไม่มีอันไหนผิดอันไหนถูก นิยามของแต่ละคนมันเกิดจากการนำประสบการณ์ที่เคยเจอมาทั้งหมดของตัวเอง นำมากางดูแล้วถามว่า “สิ่งเหล่านี้มีอะไรที่เหมือนกัน ?” แล้วพยายามหาข้อสรุปที่ครอบคลุมออกมา (ถึงแม้ว่าเราอาจจะทำโดยไม่รู้ตัวก็ตาม)

จากนิยามต่าง ๆ keywords ที่เกี่ยวข้อง รวมไปถึงปัญหาในหลายรูปแบบที่ส่วนตัวเคยเจอมา ถ้าหากจะถามว่ามีอะไรที่เหมือนกัน สำหรับเราคงจะมีอยู่สองอย่าง

(1) ปัญหาคือสิ่งที่มองหา “การแก้ไข” หรือ solution; อุปสรรค คือสิ่งที่เราหาทางก้าวข้าม, คำถาม คือสิ่งที่เราหาคำตอบ, ปัญหาทางคอมพิวเตอร์ คือสิ่งที่เราหา algorithm มาเพื่อแก้มัน

(2) ปัญหาสามารถแบ่งออกได้เป็น 2 ส่วนหลัก ๆ คือ “สิ่งที่เป็นอยู่” หรือ Actual State และ “สิ่งที่คาดหวังว่าควรจะเป็น” หรือ Desired State (หรือถ้าเปรียบเทียบ อาจจะมองว่าเป็นต้นทางและปลายทางก็ได้)

Problem is the gap between the “Actual State” and the “Desired State.”

ยกตัวอย่างเช่น โจทย์คณิตศาสตร์ → (คำถาม, คำตอบที่คาดหวัง), ปัญหาทางคอมพิวเตอร์ → (Input, Output), ลืมกุญแจไว้ในรถ → (เข้ารถไม่ได้, เข้ารถได้), หรือการทำธุรกิจที่ต้องแก้ pain point หรือ disappointment ของลูกค้า → (Reality, Expectation)

โดยสรุปแล้วเราสามารถวาดภาพออกมาได้ โดยที่ต้นทางคือ Actual State และปลายทางคือ Desired State, และช่องว่างระหว่าง 2 state นี้ก็คือสิ่งที่เรียกว่าปัญหานั่นเอง

ส่วนลูกศรก็คือวิธีการแก้ปัญหา เป็นสิ่งที่จะพาเราเดินจาก Actual State ไปสู่ Desired State

ดี หรือ ไม่ดี?

วิธีแก้ปัญหาสำหรับปัญหา ๆ หนึ่งมีได้ หลายวิธี และนั่นเป็นเหตุผลว่าทำไมลูกศรในภาพถึงมีหลายอัน; ถ้าหากว่าเราหิวข้าวเราอาจจะเดินไปซื้อของหน้าปากซอย สั่งข้าวผ่าน Grab หรือทำกับข้าวกินเอง ทุกอย่างเป็นวิธีแก้ปัญหาที่ถูกต้องทั้งนั้น

แต่คำถามก็คือ เราจะรู้ได้ไงว่าวิธีแก้ปัญหาอันไหนดี หรือไม่ดี?

จริง ๆ เราตอบไม่ได้หรอกว่าวิธีการไหนมันดีหรือไม่ดี ยกเว้นซะว่าเราตอบตัวเองได้ว่ามันดีกับอะไร? หรือถ้าพูดอีกแบบก็คือ วิธีการมันตอบโจทย์กับบริบทของปัญหามากน้อยแค่ไหน?

จากปัญหาหิวข้าวถ้าเราบอกว่าตอนนี้เงินเราใกล้หมดธนาคารแล้ว การทำกับข้าวกินเองอาจจะเป็นวิธีการที่ดีที่สุด แต่ถ้าบอกว่าตอนนี้ติดประชุมงานอยู่ การสั่งข้าวผ่าน Grab ก็จะกลายเป็นตัวเลือกแรกทันที

ถ้าหากเป็นการออกแบบ algorithm บริบทอาจจะหมายถึง resources ที่จำกัดอย่างเช่นระยะเวลาในการรัน (Time) หรือพื้นที่ที่ใช้ในการเก็บข้อมูล (Space) หรือที่เราว่า “Computational Complexity” หรือถ้าเป็นการจัด event บริบทตรงนี้อาจจะหมายถึง จำนวนเงิน สถานที่ จำนวนทีมคนจัดงาน ระยะเวลา จุดประสงค์หรือเป้าหมาย และอีกหลาย ๆ อย่าง

ทั้งนี้บริบทอาจจะเปลี่ยนไปตามรูปแบบของปัญหาในแบบต่าง ๆ

ภาพกว้าง

อีกหนึ่งข้อสังเกตของปัญหาก็คือความเป็น “Cause and Effect”; ปัญหา D อาจจะเกิดจากปัญหา A, B, C และปัญหา D นั้นอาจจะส่งผลให้เกิดปัญหา E ต่อไป

ซึ่งหลายคนน่าจะเคยได้ยินวิธีคิดอย่างเช่น Five whys ที่ถ้าหากว่าเราเจอปัญหาอะไรบางอย่าง ให้ลองถามว่าทำไมลึกลงไป 5 ครั้ง เพื่อให้เห็นปัญหาที่ลึกขึ้น ว่าต้นเหตุของปัญหาจริง ๆ คืออะไรเช่นไปทำงานสาย → เพราะตื่นสาย → เพราะนาฬิกาปลุกไม่ทำงาน → เพราะแบตหมด → …

แต่เวลาเรานึกถึง Five whys ส่วนใหญ่เราจะนึกถึงความเป็น linear ที่ A ทำให้เกิด B ทำให้เกิด C แต่จริง ๆ แล้วปัญหาหลาย ๆ อย่างมันไม่ได้ linear ขนาดนั้น ปัญหาหนึ่งอาจจะเกิดจากหลายปัญหา หรือปัญหาเดียวส่งผลกับหลายปัญหาก็ได้

หรือปัญหาหนึ่งกับอีกปัญหาหนึ่งอาจจะส่งผลกระทบกันเองจนก็ได้เป็น loop ก็ได้ เช่น ตีแบตพลาด → รู้สึกว่าต้องรีบทำแต้มกลับมา → ตีพลาดหนักกว่าเดิม → เร่งทำแต้ม → ยิ่งพลาด → …

ถ้าหากว่าเราถอยออกมาจากปัญหาใดปัญหาหนึ่ง เราจะพบว่าปัญหาหนึ่งมันมีความเป็น interconnected system กันอยู่ โดยที่หลาย ๆ ปัญหามีความเชื่อมโยงและส่งผลกัน และยิ่งเรา analyse แต่ละปัญหาลึกลงไปเท่าไหร่เราก็จะเจอปัญหาอื่น ๆ ที่เชื่อมโยงกันต่อไปเรื่อย ๆ

“From an early age we are taught to break apart problems, to fragment the world. This apparently makes complex tasks and subjects more manageable, but we pay a hidden, enormous price. We can no longer see the consequences of our actions: we lose our intrinsic sense of connection to a larger whole.” — Peter Senge, 1990

เรารู้สึกว่าภาพนี้สำคัญมาก เพราะหลายครั้งเรามักจะ focus กับการแก้ปัญหาใดปัญหาหนึ่งจนลืมมองภาพใหญ่ไป ซึ่งบางทีการแก้ปัญหาหนึ่งได้อาจจะส่งผลเสียต่ออีกปัญหาโดยที่เราไม่รู้ตัวก็ได้

ทำไมถึงสำคัญ?

Model หรือทฤษฎีต่าง ๆ จริง ๆ แล้วมันไม่ได้ represent ความเป็นจริงทั้งหมด ความเป็นจริงเป็นสิ่งที่มี detail หรือความละเอียดไม่จำกัด แต่เราเลือกที่จะหลงลืม detail เหล่านั้นไป แล้วเหลือไว้แต่สิ่งที่เราอยากจะสื่อจริง ๆ

แต่ถึงแม้ว่า “All models are wrong” หรือไม่ได้ represent ความเป็นจริงทั้งหมดอยู่ในนั้น แต่มันก็มีประโยชน์มากพอที่จะเอา model มาใช้ analyse แง่มุมต่าง ๆ ของความเป็นจริง เอามา make implication หรือ interpretation ต่อ หรือแม้กระทั้งเอาไปใช้ในการ predict สิ่งที่อาจจะเกิดขึ้นในอนาคตได้

สำหรับเราแล้วการพยายามนิยามคำว่าปัญหา พยายามแบ่ง structure มันออกมา มันทำให้เรารู้ว่าจะต้องมองปัญหา ๆ หนึ่งยังไง ในแง่มุมไหนบ้าง ยกตัวอย่างเช่น

(1) เข้าใจ Actual State, Desired State ว่าคืออะไร

(2) ตีกรอบ Problem Context

(3) พยายามถอยออกมาเพื่อมองภาพกว้าง (Interconnected system)

แน่นอนว่าจริง ๆ แล้วมันมี detail อีกหลายอย่างที่เราสามารถตั้งคำถามต่อได้อีกเช่น “เราจะ define actual กับ desired state ยังไงให้เห็น pattern ที่จะนำไปใช้แก้ปัญหาได้”, “ในปัญหาต่าง ๆ เราควรมองบริบทในมุมไหนบ้าง”, “เราจะมีวิธี analyse system ที่มัน complex มาก ๆ ยังไงได้บ้าง” และอีกหลาย ๆ คำถาม แต่นั่นคงจะเป็นเรื่องที่เราจะเก็บเอาไว้คุยกันในบทความอื่น ๆ ต่อไป

สุดท้ายอยากชวนทุกคนมาช่วยกันตีความ มาช่วยกันทำภาพให้ชัดขึ้น หรืออาจจะสร้างภาพใหม่ที่ครอบคลุมกว่านี้ของคำว่า “ปัญหา”; แล้วมาแชร์กันครับ~