บันทึกการเรียน Humanistic Architecture

Sarunyhot
3 min readMar 30, 2023

--

เรียนรู้จิตวิทยาสู่การออกแบบ Software ให้เข้าถึงกลางใจลูกค้าและตัวเรา

คอร์ส Humanistic Architecture จัดโดยพี่คริส
เป็นคอร์สจำนวน 2 วัน รอบ 25-26 มีนาคม 2023

โดยวันแรกจะพาปูพื้นเข้าสู่จิตวิทยา วิธีการคิด การแก้ปัญหา เพื่อนำไปสู่วันที่สอง ซึ่งจะเริ่มเอาเนื้อหาในวันแรกมาอธิบายว่า มันช่วยการออกแบบ Software Architecture ได้อย่างไร

ถ้าพูดถึงซอฟแวร์คงหนีไม่พ้นการแก้ปัญหาที่เกิดขึ้น มีปัญหาเกิด เราถึงต้องแก้มัน
แต่จริงๆ แล้วนิยามของ “ปัญหา” มันคืออะไร และอะไรทำให้คนเราแก้ปัญหาไม่ได้ซักที

Problem (ปัญหา) ประกอบด้วย 3 ส่วน

  1. Current state — สภาวะปัจจุบัน
  2. Gap — ช่องว่าง ระยะห่างหรือวิธีที่เราต้องการจะไปยังจุดหมาย
  3. Desired state — จุดหมายหรือสิ่งที่เราต้องการ

แต่ในสถานการณ์จริงนั้นเรามักเข้าใจผิดว่าสิ่งต่างๆ นั้นคือปัญหา เช่น
“จนจังไม่มีตังใช้”, “อ้วนมากเลยตอนนี้”, “โค้ดอ่านไม่ออก”, “ระบบสเกลไม่ได้”
ซึ่งจริงๆ แล้วคือ Statement(ประโยคบอกเล่า), Disappointment(บ่น/ผิดหวัง) เฉยๆ
ทำให้เราเกิดการแก้ปัญหาผิดๆ ขึ้นมา จะเห็นเราว่าหลายครั้ง เรายังไม่รู้ด้วยซ้ำว่า Desired state คืออะไร แต่ก็กระโจนลงไปทำซะแล้ว ทั้งๆที่เราคิดไปเองว่า แบบนี้แหละคือวิธีแก้

จากประโยคว่าโค้ดอ่านไม่ออกนั้น เราอาจจะคิดว่า วิธีการง่ายนิดเดียวก็คือ ให้เวลาไปเรียนคอร์สออนไลน์ ไม่ก็หนังสือไปอ่าน

ปัญหา: โค้ดอ่านไม่ออก สิ่งที่คิด

แต่จริงๆ แล้วปลายทางเค้าอาจจะไม่ได้อยากอ่านโค้ดออกก็ได้ หรือต่อให้อ่านออก ก็มีวิธีแก้ปัญหาหลายอัน เราจะรู้ได้ไงว่าอันไหนจะแก้ปัญหาได้จริงๆ

ปัญหา: โค้ดอ่านไม่ออก สิ่งที่เกิดขึ้น

จากทางเลือกมากมายที่เกิดขึ้น สุดท้ายแล้วมันไม่มีอะไรที่แก้ปัญหาได้เลย เพราะจริงๆ แล้ว เรายังไม่เข้าใจว่าจริงๆ แล้วอะไรคือปัญหา ยิ่งแก้ยิ่งสร้างปัญหาใหม่ขึ้นมา

แก้ปัญหาและสร้างปัญหาใหม่

แล้วเราจะต้องแก้ปัญหาไปถึงเมื่อไหร่ล่ะ? คำตอบคือ เราก็แก้ไปเรื่อยๆ จนกว่าตัวเราจะยอมรับมันได้นั่นเอง ว่าจุดนี้เราพอใจแล้วนะ

อะไรทำให้คนเราบ่นหรือผิดหวัง และอะไรที่ทำให้เรายอมรับมันได้

เราจึงต้องใช้จิตวิทยาในการเข้าใจตัวเราและผู้อื่น เพื่อให้เราแก้ปัญหาได้ดีขึ้น

รู้จักกับ Satir iceberg model

Satir’s Personal Iceberg Metaphor

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

การที่เราแก้ปัญหาไม่ตรงนั้น เกิดจากตัว Expectation เราคาดหวังว่าต้องให้เค้า เป็นแบบนี้ หรือลูกค้าน่าจะอยากได้แบบนี้ ทำให้เราสร้าง Desired state ในมุมมองของเราขึ้นมานั่นเอง

โดยเราจะมุ่งไปที่ Yearning (ความปราถนา, ความต้องการ)
ซึ่งเป็นของที่คนทั้งโลกมีเหมือนกัน (universal language) เราสามารถทำความเข้าใจได้

Satir belief at almost the core of human mind, we have communicable universal yearning
Acceptance, Love, Freedom, Belonging, etc.
This is universal human “food of mind” which create both satisfaction, and when deprived,
great disappointment.

ตัวอย่าง Yearning

1. Freedom
2. Safe
3. Loved
4. Accepted
5. Authentic
6. Autonomy
7. Be in Control
8. Moral — Integrity
9. Comfort
10. Peace
11. Belonged
12. Appreciated & Acknowledged
13. Efficient
14. Valued
15. Win

แต่ละคนมี Yearning ที่ต่างกัน ทำให้จาก Current state หนึ่ง นำพาไปสู่ Desired state ที่ต่างกัน
หากไม่เข้าใจแล้ว ก็จะเกิดสถานการณ์แบบนี้

ลูกค้า: บอกปัญหามา แก้ให้หน่อย
เดฟ: แก้ปัญหาไปให้
ลูกค้า: ยังไม่ได้แก้เลยนี่!!
เดฟ: ก็อันนี้ไงที่แก้ไป
ลูกค้า: ไม่ได้อยากได้แบบนี้, แก้ได้แล้ว แต่มีปัญหาใหม่อีกแล้ว

หากเริ่มต้นเข้าใจ Yearning ของตัวเอง ก็จะสามารถเข้าใจผู้อื่นได้เหมือนกัน

ไม่เข้าใจตัวเอง ก็ไม่เข้าใจผู้อื่น
เข้าใจตัวเองก่อน เพื่อเข้าใจผู้อื่น

เมื่อเราดีไซน์ software architecture หรือตัดสินใจนั้น มีทางวิธีแก้ปัญหามากมาย แก้ได้หมดเหมือนกัน ทำยังไงให้เราได้เลือกได้ถูกต้องและพอใจ ถ้าเรารู้ Yearning ก็ทำให้เลือกและตัดสินใจได้ดีขึ้น

Framework และภาษาตัวนี้ไม่เห็นทำได้แบบนี้เคยเขียนในภาษาที่ตัวเองถนัดเลย (ขาดความคุ้นเคย)
Tech lead ไม่อยากเปลี่ยนแปลง Pattern เร็วเกินไป (ขาดความมั่นใจและคุณค่า)
Programmer ที่อยากใช้เฟรมเวิร์คหรือภาษาใหม่ (ขาดการมองเห็นคุณค่าในตัวเอง)
Programmer ที่อยากใช้ของใหม่เพราะน่าสนุก อยากลอง(ต้องการเติมเต็ม Curiosity)

ในการค้นหาว่าอะไรคือ Yearning ที่แท้จริงนั่น มีสิ่งที่เรียกว่า

Three Centers of Intelligence

คนเรามีแรงขับเคลื่อนจากทั้งหมด 3 ศูนย์ ประกอบด้วย ใจ ร่างกาย หัว แต่ละอันก็ถูกขับเคลื่อนด้วยความรู้สึกที่แตกต่างกันไป

หัว (ความกลัว/ความวิตกกังวล)— เป็นแรงขับเคลื่อนเพื่อหลบหนีจากภัยคุกคาม อุปสรรคหรืออันตรายต่อความมั่นคงของเราที่อาจจะเข้ามาได้ ขับเคลื่อนด้วยการคิดและประเมินความเป็นไปได้ในอนาคตต่างๆ จากข้อมูลที่มี เพื่อทั้งป้องกันภัยอันตราย สร้างทางเลือกที่ดีต่อตนเองในอนาคต หรือเก็บทรัพยากรเพื่อเตรียมตัว

ใจ (ความอับอาย) — เป็นศูนย์ที่ขับเคลื่อนตามหาความผูกพันธ์และความรัก

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

โดยปกตินั้นคนเรามักจะถนัดในศูนย์ใดศูนย์หนึ่งอยู่แล้ว แต่บางทีก็สุดโต่งมากเกินไป ใช้ด้านใดด้านหนึ่งในการตัดสินใจ ทำให้มองเห็นทางเลือกในการขับเคลื่อนน้อยกว่าที่สามารถเป็นไปได้ และเกิดอาการ Incongruence ขึ้น (เช่น ถ้าอยากย้ายงานแต่ศูนย์หัวทำงานเยอะมาก ก็อาจจะเห็นแต่ความเสี่ยงในการย้าย และก็ย้ายงานไม่ได้ ทั้งๆ ที่ใจไม่อยู่กับงานปัจจุบันแล้ว หรือ บางครั้งใจอาจจะยึดติดกับความรักครั้งหนึ่งมากจนไม่ว่าจะอยู่ใน Abusive Relationship ยังไงก็มองไม่เห็นอันตรายหรือความเสี่ยงกับตัวเอง)

ซึ่งนำมาสู่ข้อสงสัยว่า คนเราควรตัดสินใจผ่านพลังงานศูนย์ไหน?

คำตอบคือให้ใช้ทุกศูนย์เลย เราควรหัดใช้ศักยภาพที่มีอยู่ในแต่ละศูนย์ เพื่อให้เกิดการ balance กัน และทำให้ไปทางเดียวกันกับ Yearning ที่ต้องการ
ในกรณีที่เราตัดสินใจได้ถูกแล้ว จะมีสิ่งที่เรียกว่า Congruence เกิดขึ้น
มันคือสภาวะที่เรารู้สึกพอใจ สบายใจ ไม่เกิดข้อสงสัยหรือกังขา กับเรื่องที่เราตัดสินใจลงไป เพราะว่าเราได้คำตอบที่ หัว ใจ ร่างกาย ไปทางเดียวกันกับ Yearning

Congruence

แต่ถ้าเราตัดสินใจไปแล้ว ยังเกิดความไม่สบายใจ เอ๊ะหรือมันไม่ใช่ แก้แบบอื่นได้หรือป่าว จะทำให้เกิด Incongruence ซึ่งมาจากที่แต่ละศูนย์ไม่ไปทางเดียวกันกับ Yearning

Incongruence

ในคลาสได้มีการทำ workshop โดยให้ลองนำเสนอการเลือก Architecture ที่ต้องการ โดยใช้พลังงานให้ครบทุกศูนย์ เพื่อให้เรามีข้อมูลตัดสินใจให้ครบทุกด้าน

ในคลาสพี่คริสได้ยกตัวอย่างการออกแบบ Architecture ที่เป็น Microservice ขึ้นมา ซึ่งเป็นสิ่งที่เห็นภาพชัดมาก โดยได้มีการวาดรูปร่างของ Architecture ที่เกิดจาก Yearning คนละแบบ ทำให้เห็นว่า แม้จะตัดสินใจเป็น Microservice เหมือนกัน แต่เวลาลงรายละเอียดโครงสร้างซอฟแวร์แล้ว มันต่างกันอย่างมาก ซึ่งมาจากการที่เราตัดสินใจโดยมี Yearning คนละแบบ

บรรยากาศในคลาสก็ค่อนข้างสนุก เนื่องจากมีการพูดคุยและยกเคสตัวอย่างมากมาย ทำให้เกิดการถกเถียงและมาวิเคราะห์กัน

สิ่งที่ต้องทำหลังจากจบคลาสคือการ Reflect การตัดสินใจหรือออกแบบ Architecture ในอดีต หรือเอาซอฟแวร์ปัจจุบันนำมาคิด โดยนำวิธีการคิดต่างๆ ในคลาสมาใช้ ทำให้เข้าใจโค้ดได้มากขึ้น รวมถึงใช้เป็นเครื่องมือต่างๆ ในอนาคตด้วย

ความสนุกคือเราสามารถฝึกได้ทุกวัน โดยไม่ต้องรอสถานการณ์จากงานประจำเลย เช่น ลองฝึกคิดดูสิว่าถ้าเราอยากเปลี่ยน Frontend framework จาก React เป็น Angular จะเป็นยังไง หรือถ้าอยากใช้ Clean architecture มันคิดมาจาก Yearning อะไร และทำให้เรา Congruence ได้ไหม โครงสร้างปัจจุบันมันเกิดมาจากการตัดสินใจยังไง ทำไมตอนนั้นคิดแบบนั้น ทำไมตอนนี้ถึงมีปัญหา

Codebase ที่เราเจอแล้วคิดว่ามันไม่ make sense ในปัจจุบัน เมื่อก่อนมันอาจจะคิดมาดีแล้วก็ได้นะ แต่ด้วยปัจจุบันสถานการณ์และสภาพแวดล้อม+Yearning ที่เปลี่ยนไป มันเลยไม่ Congruence แค่นั้นเอง

ยังมีเรื่องของการใช้ Abstraction ที่ต้องเจอบ่อยๆในการออกแบบโค้ด รวมไปถึงมันเกี่ยวเนื่องกับ Design pattern ต่างๆ อย่างไรบ้าง เนื้อหาแน่นมาก slide ที่ให้มาก็อธิบายได้ดี และเยอะมาก ต้องมาทบทวนต่อหลังจบคลาส

สรุปว่าเป็นคลาสที่ดี ทำให้เรามีเครื่องมือในการออกแบบ Software Architecture ได้ดี และมีความสุขมากขึ้น 😄

--

--