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

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

บางคนอาจจะนึกถึงความลำบากที่ต้องตื่นเช้าไปทำงานหรือไปโรงเรียนให้ทัน บางคนอาจจะนึงถึงการแก้โจทย์ปัญหาหรือการแก้ 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 หรือทำกับข้าวกินเอง ทุกอย่างเป็นวิธีแก้ปัญหาที่ถูกต้องทั้งนั้น

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

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

จากปัญหาหิวข้าว ถ้าหากเราบอกว่าตอนนี้เงินเราเหลืออยู่อีกแค่ 50 บาท การทำกับข้าวกินเอง หรือการไปซื้ออะไรถูก ๆ จากร้านสะดวกซื้ออาจจะเป็นวิธีการที่ดีที่สุด ในขณะที่การสั่ง Grab จะเป็นตัวเลือกที่ไม่ตอบโจทย์ทันทีเพราะเกิน 50 บาทแน่นอน (ดังเช่นลูกศรสีส้มในภาพด้านล่าง)

…แต่ถ้าบอกว่าตอนนี้ติดประชุมงานอยู่และเงินในธนาคารไม่ใช่ปัญหา การสั่งข้าวผ่าน 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 แง่มุมต่าง ๆ ของความเป็นจริง เอามา approximate หรือ make implication ต่อ หรือแม้กระทั้งเอาไปใช้ในการ predict สิ่งที่อาจจะเกิดขึ้นในอนาคตได้

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

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

(2) ตีกรอบ Problem Context

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

แน่นอนว่าจริง ๆ แล้วมันมี detail อีกหลายอย่างที่เราสามารถตั้งคำถามต่อได้อีกเช่น

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

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