สรุปสิ่งที่น่าสนใจจากการไปเรียนคอร์ส Humanistic Architecture

เมื่อหลายเดือนก่อน เราได้โอกาสไปเรียนคอร์ส “Humanistic Architecture” โดยคำโปรยที่อ่านเจอใน social media คือการมอง software architecture ไม่ใช่เพียงเรื่องของ technical อย่างเดียว แต่เป็นการนำ “ความเป็นมนุษย์” มาใช้ในการตัดสินใจ เพราะแนวคิดนี้เชื่อว่าทุกระบบ ทุก code ทุก design ล้วนมีที่มาจากสิ่งหนึ่งในใจของมนุษย์ทุกคนนั่นคือ “ความโหยหา (yearning)” ที่รอการตอบสนอง เนื้อหาอาจจะไม่ได้ครอบคลุมทั้งคอร์ส แต่คิดว่าเป็นอีกหนึ่งคอร์สที่เปลี่ยนแนวคิดของเราให้เข้าใจคนอื่นมากขึ้น มาดูกัน

1. “ปัญหา” คืออะไรกันแน่

มนุษย์ (ในที่นี้หมายถึงคนที่ทำงานอยู่ในวงการพัฒนา software) ดูเหมือนจะมีความสัมพันธ์ที่ซับซ้อนกับสิ่งที่เรียกว่า “ปัญหา” ไม่ว่าจะเป็นปัญหาทาง technical ปัญหาการ design หรือแม้แต่ปัญหาในชีวิต มนุษย์มักคิดว่า “ถ้ามันมีปัญหา ก็ต้องหาทางแก้” ซึ่งในวงการ software เราก็พูดกันบ่อยว่า “เราสร้าง software เพื่อแก้ปัญหา” แต่เคยตั้งคำถามไหมว่า

จริง ๆ แล้ว “ปัญหา” มันคืออะไรแน่

ถ้าตามคำนิยามของคอร์สนี้ “ปัญหา” คือ ช่องว่างระหว่างสภาวะปัจจุบัน (current state) กับ สภาวะที่ต้องการ (desired state) แปลว่าถ้าไม่มี desired state ก็ไม่เกิดปัญหาเลย เพราะไม่มี “จุดหมาย” ที่เราจะไปถึง

ตัวอย่างเช่น

• “ระบบเรา scale ไม่ได้” — ยังไม่ใช่ปัญหา มันแค่ “คำบอกเล่า”
• “ระบบเรา scale ไม่ได้ แต่ควรรองรับ 1 ล้าน req/sec” — นี่แหละถึงจะเป็นปัญหา เพราะเรามีทั้งปัจจุบันและเป้าหมายให้เปรียบเทียบ

หรือ

• “ไม่มีใครอ่าน code รู้เรื่อง” — ไม่จำเป็นต้องเป็นปัญหา ถ้า code นั้นไม่ได้ใช้งาน
• “ไม่มีใครอ่าน code รู้เรื่อง ทั้งทีมต้องดูแลมันต่อไปอีกอย่างน้อย 3 ปี” — ตอนนี้ถึงจะเป็น “ปัญหา”

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

2. จาก “ข้อเท็จจริง” สู่ “ความผิดหวัง”

แต่ก่อนที่ปัญหาจะเกิดขึ้น เรามักจะมีสิ่งหนึ่งเกิดขึ้นมาก่อนเสมอนั่นคือ “ความผิดหวัง” (Disappointment)

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

แปลว่าในบริบทนี้ ทุก “ปัญหา” จึงเริ่มต้นจาก “ความผิดหวัง” นั่นเอง ตัวอย่างเช่น

Current State	Desired State	Solution
ใช้ Excel แล้วเสียเวลา	อยากคลิกเดียวเห็นทุกข้อมูล	สร้างระบบใหม่
ใช้ Excel แล้วเสียเวลา	อยากใช้เวลาน้อยลง	จ้างคนเพิ่ม

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

3. “ปัญหา” ไม่ได้แปลว่า “ความเจ็บปวด”

หลายคนเข้าใจว่า ปัญหาต้องมาพร้อม “ความทุกข์” หรือ “pain point” แต่จริง ๆ แล้ว “ปัญหา” ไม่จำเป็นต้องมีอารมณ์ลบใด ๆ เลย ตัวอย่างเช่น

“HTML/CSS/JS ก็เพียงพอแล้ว จะมี React ไปทำไม”
“C++ ทำได้ทุกอย่าง จะสร้างภาษาใหม่ไปเพื่ออะไร”
“เรียก Procedure call ตรง ๆ ก็ง่ายกว่า จะใช้ Event ไปทำไม”

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

4. Satir และมุมมองเชิงมนุษย์ของ “ปัญหา”

จากประสบการณ์คนสอนที่เริ่มมองหาคำตอบว่า “ปัญหาเกิดจากอะไร” เขากลับพบคำตอบจากศาสตร์อื่นที่ไม่ใช่ computer science นั่นคือ “จิตวิทยา”

แนวคิดที่เขาได้เรียนรู้คือ Humanistic Psychology ซึ่งได้กล่าวกับมองมนุษย์แบบองค์รวม ไม่แยก “พฤติกรรมภายนอก” ออกจาก “ประสบการณ์ภายใน” หรือ “ทฤษฎีสมอง” ทุกมุมมองมีส่วนของความจริง แต่ไม่มีมุมใดที่ครอบคลุม “ความเป็นมนุษย์ทั้งหมด” ได้ หนึ่งในนักจิตวิทยาที่เขาชอบคือ Virginia Satir ซึ่งพูดไว้ได้น่าสนใจว่า

ปัญหาที่แท้จริง ไม่ได้อยู่ที่ตัวปัญหามันเอง แต่อยู่ที่วิธีที่เรารับมือกับมัน

5. วงจรของความผิดหวังไม่รู้จบ

ในวงการ software มันจะมีความผิดหวังซ้อนความผิดหวังไปเรื่อย ๆ อยู่ ยกตัวอย่างเช่น

1. ระบบ scale ไม่ได้ -> ต้องการให้ scale ได้ -> แก้ด้วย server แรง ๆ -> ความผิดหวังที่ตามมา: ค่าใช้จ่ายพุ่งสูง

2. ค่าใช้จ่ายพุ่งสูง -> ต้องการให้ลดลง -> ย้ายไปใช้ cloud -> ความผิดหวังที่ตามมา: ทีมไม่มีความรู้เรื่อง cloud

3. ทีมไม่มีความรู้เรื่อง cloud -> ต้องการให้ทีมเก่ง -> ส่งอบรม training -> ความผิดหวังที่ตามมา: ทีมถูก headhunt ไป…

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

6. ความยอมรับเกิดจากอะไร

Satir อธิบายว่า พฤติกรรมของมนุษย์เปรียบเหมือนภูเขาน้ำแข็ง สิ่งที่เราเห็น (พฤติกรรม) เป็นเพียงส่วนยอดเล็ก ๆ แต่สิ่งที่อยู่ใต้ผิวน้ำ คือ อารมณ์ -> ความคาดหวัง -> ความเชื่อ -> และความโหยหา (Yearning)

https://www.pinterest.com/pin/519462138260489891/

เป้าหมายของ Satir คือภาวะที่เรียกว่า Congruence คือการที่ “หัว ใจ ร่างกาย และ value ที่เรายึดถือ” ของเราสอดคล้องกัน เมื่อสิ่งเหล่านี้ไม่สอดคล้อง เราจะรู้สึกเหมือน “แตกสลายจากภายใน” และเมื่อใดที่ Yearning ถูกตอบสนอง เราจะสามารถ “ยอมรับ” สถานการณ์ได้จริง ๆ

7. Yearning คือรากเหง้าของทุกปัญหา

คนสอนมองว่าความโหยหา (Yearning) คือ “อาหารของจิตใจ” ที่มนุษย์ทุกคนมี มันอาจจะมาในรูปแบบความต้องการทางร่างกาย (เช่น ความปลอดภัย) ทางอารมณ์ (เช่น การได้รับการยอมรับ) หรือทางสติปัญญา (เช่น ความเข้าใจ)

เมื่อ Yearning ถูกตอบสนอง -> เรารู้สึกพอใจ เมื่อ Yearning ถูกละเลย -> เกิดความผิดหวัง -> นำไปสู่การสร้าง “ปัญหาใหม่”

สิ่งที่หลายคนผิดพลาดในในการตอบสนอง yearning คือการตอบสนองในระดับอื่น เช่น expectation แปลว่าเราสามารถได้ในสิ่งที่คาดหวัง แต่ยังรู้สึกว่างเปล่าได้ ถ้าไม่ใช่สิ่งที่ใจต้องการจริง ๆ ดังนั้น คนสอนมองว่าหัวใจของ software design ที่แท้จริง คือ การเข้าใจ Yearning ของผู้คน ไม่ใช่เพียง “pain point”

8. Empathy คือทักษะในการเข้าใจ Yearning

มนุษย์ทุกคนมีศักยภาพที่จะเข้าใจผู้อื่น (empathize) ในขณะเดียวกัน empathy ที่แท้จริงไม่ได้หมายถึง “เห็นด้วย” หรือ “ยอมทุกอย่าง” มันคือ “การสัมผัสถึงความโหยหา” ที่อยู่เบื้องหลังพฤติกรรม เช่น ทีมอ่าน code ไม่รู้เรื่อง ทั้งทีมต้องดูแลมันต่อไปอีกอย่างน้อย 3 ปี ความโหยหาแท้จริงอาจคือ “อยากรู้สึกมีคุณค่า” หรือ “อยากมี control” ถ้าเราตอบด้วย “งั้น outsource ไปเลยสิ” ก็มีโอกาสที่จะโดนต่อต้าน เพราะมันไม่ตรงกับ Yearning ของเขา

Empathy ที่แท้จริงจึงต้องเกิดจาก “การเข้าใจ Yearning ของตัวเองก่อน” เพราะถ้าเราไม่รู้ว่าเราต้องการอะไร เราจะเผลอเอาความโหยหาของตัวเองไปฉายใส่คนอื่น และจะเข้าใจว่า “คนอื่นไม่อยากแก้ปัญหา” ทั้งที่จริง ๆ เขาแค่มี Yearning ต่างจากเรา

9. การออกแบบที่สอดคล้องกับ Yearning

ในวงการ software เรามีหลายทางเลือกในการออกแบบระบบ เช่น เลือกภาษา เลือก framework เลือก architecture คำถามคือ “เราจะเลือกอย่างไร” ในทางคณิตศาสตร์ นี่คือ Optimization Problem ก็คือการหาคำตอบที่ดีที่สุดจากหลายทางเลือก แต่ใน Humanistic Architecture เรา optimize ไม่ใช่เพื่อได้คำตอบที่ดีที่สุดในมุมมองคณิตศาสตร์ แต่เพื่อ ตอบสนอง Yearning ที่แท้จริงของมนุษย์

ตัวอย่างการออกแบบระบบตามการตอบสนองต่อ Yearning:

• Yearning to be safe -> ให้คุณค่ากับความมั่นคงและสามารถ audit ย้อนหลังได้ -> รวมศูนย์ configuration
• Yearning to be autonomous -> อยากมีอิสระในการเปลี่ยนแปลง -> แยก configuration กระจายให้ทีมดูแลเอง
• Yearning for comfort -> อยากให้ง่าย -> ใส่ configuration ไว้ใน Git ก็พอ

ทุก design decision มี “แรงขับภายใน” อยู่เบื้องหลังเสมอ. และเมื่อแรงขับ (หัว–ใจ–กาย–คุณค่า) ไม่สอดคล้องกัน (Congruence) — เราจะรู้สึกว่า “มันไม่ make sense”

10. ความสอดคล้องภายในคือรากของการออกแบบที่ดี

ภาวะ Congruence คือเมื่อ “ทุกส่วนในตัวเรา” เดินไปในทิศทางเดียวกัน หัว (เหตุผล), ใจ (ความรู้สึก), กาย (สัญชาตญาณ), และ Yearning (แรงขับภายใน) อยู่ในจังหวะเดียวกัน

ในทางกลับกัน หากสิ่งใดสิ่งหนึ่งขัดกัน เราจะเกิดความสับสน ไม่มั่นใจ หรือรู้สึก “ฝืนใจ” สัญญาณแบบนี้คือจุดที่เราควรกลับมาทบทวน Yearning ของตัวเอง และดูว่าเรากำลัง optimize เพื่ออะไรแน่

11. Mannequin: การมอง software architecture ในฐานะ “มนุษย์”

การเช็คว่าคนอื่นเกิดภาวะ Congruence หรือไม่ สามารถนำแนวคิด Mannequin Model หรือการ “ปั้นหุ่น” เป็นวิธีฝึกมอง software architecture ให้เหมือน “มนุษย์คนหนึ่ง” มีความผิดหวัง มีแรงขับภายใน วิธีนี้มี 4 ขั้นตอน

1. ดูว่า framework หรือ pattern นั้น “เปลี่ยนอะไร” ไม่ใช่แค่ “ทำอะไร” พิจารณา current state -> coping stance -> desired state

2. พยายามเข้าใจ Yearning ที่ซ่อนอยู่ เพราะทุก architecture pattern เกิดจาก yearning บางอย่าง เช่น ความมั่นคง ความยืดหยุ่น หรือความสนุก

3. ตรวจสอบ 3 ศูนย์ภายใน (head, heart, body)

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

4. เชื่อมโยงกลับกับปัญหาของเราเอง ถ้า Yearning ของเรา (เช่น ต้องการ performance) ขัดกับ Yearning ของ architecture (เช่น เน้น comfort) ก็อาจไม่เหมาะ แม้จะดู “ดี” ในเชิง technical

12. ความสำเร็จและภาวะ Congruence

Satir กล่าวไว้ว่า “ความสำเร็จ” ไม่ใช่เรื่องโชค แต่คือ “การบรรลุสิ่งที่เราตั้งใจทำ” เพราะฉะนั้นเราต้องชัดก่อนว่า เราตั้งใจทำอะไร และ เรากำลังตอบสนอง yearning อะไรอยู่

เมื่อเรารู้แล้ว หัว ใจ และกายของเราจะทำงานสอดคล้องกันเอง และความรู้สึก “success” จะเกิดขึ้นโดยธรรมชาติ

13. สรุป

“Every design in computer architecture is a reflection of human yearning.”

เบื้องหลังทุก design decision มีมนุษย์อยู่ มนุษย์ที่มี Yearning, ความผิดหวัง, ความหวัง, และความพยายามจะเข้าใจโลกของตัวเอง

Humanistic Architecture ไม่ได้สอนให้เรายอมรับและจมกับปัญหา แต่มันสอนให้เรามองลึกกว่านั้น — มองเห็น “หัวใจของมนุษย์” ที่อยู่เบื้องหลังทุก code ทุก requirement และทุกการตัดสินใจ

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

โดยรวมเราแนะนำคอร์สนี้ให้กับคนที่อยู่ในวงการ software ครับ สิ่งที่เราเอาไปประยุกต์ใช้มันมีมากกว่า งาน design หรือ architecture แต่ยังรวมถึงการสื่อสารและรับฟังคนในทีมและลูกค้า รวมถึงเข้าใจระบบ legacy ที่ตัวเองเคยเกลียดมาก แล้วตัดสินใจลงมือทำให้ตอบสนอง Yearning ได้ตรงจุดมากขึ้น