สรุปเนื้อหา: เมื่อเทคเปลี่ยนไวกว่าใจคน จะออกแบบระบบให้อยู่รอดต้องรู้สิ่งนี้

สรุปเนื้อหาจาก Session "เมื่อเทคเปลี่ยนไวกว่าใจคน จะออกแบบระบบให้อยู่รอดต้องรู้สิ่งนี้" โดยคุณกานต์ (ODDS-TEAM)

โลกเทคทุกวันนี้หมุนไวจนน่าเวียนหัว... เครื่องมือใหม่ ๆ มาทุกสัปดาห์ ทุกเดือนทุกปี จะเรียนรู้ได้ยังไงหมด คำถามคือ... เราจะเรียนรู้เครื่องมือทุกตัวนั่นไหวเหรอ? แน่นอนว่าไม่ไหว

🎯 เปลี่ยนคำถาม... แล้วจะเห็นคำตอบ

มีคนเคยถาม Jeff Bezos ว่า "อะไรกำลังจะเปลี่ยนในอีก 10 ปีข้างหน้า?" เขาตอบว่า "ให้ลองถามใหม่ว่า... อะไรบ้างที่จะ ไม่เปลี่ยน ในอีก 10 ปีข้างหน้า?"

What's not going to change in the next 10 years?

แทนที่เราจะวิ่งไล่ตามสิ่งที่ 'เปลี่ยน' ตลอดเวลา ให้เรา Focus และสร้างรากฐานบนสิ่งที่ 'ไม่เปลี่ยนแปลง'

🤔 แล้วอะไรล่ะ ที่ไม่เปลี่ยน?

มุมของคนสร้างระบบ สิ่งนั้นคือ Human + Architecture Thinking แบ่งย่อยเป็น 3 หัวข้อ

1. Translating business drivers into architectural decisions

แปลง Business ให้เป็น Architecture

คือการ 'ตีโจทย์' ธุรกิจให้แตกก่อนลงมือทำ

ตัวอย่าง: ลูกค้าบอก "อยากได้บ้าน" 🏡

เราต้องถามต่อ: "บ้านแบบไหน?"

ลูกค้าบอก: "บ้านริมทะเล" 🌊

การออกแบบบ้านทั่วไปกับบ้านริมน้ำ ต่างกันลิบลับแล้ว บ้านริมทะเลต้องทนลม ทนไอเค็ม ทนคลื่น

และส่วนสำคัญที่สุดของการตีโจทย์ คือการคิดเผื่อ "แรงปะทะ" ที่จะเข้ามา หรือที่เรียกว่า Residuality Theory (ทฤษฎีสิ่งที่หลงเหลือ)

• ให้นึกถึง "ลูกหมู 3 ตัว" 🐷

• Stresser (หมาป่า): คือแรงปะทะ เช่น requirement เปลี่ยน, traffic พุ่ง, โดนโจมตี

• Residue (บ้านอิฐ): คือ ระบบของเราที่ยังอยู่รอดได้

หน้าที่ของ Architect คือต้องแปลงโจทย์ธุรกิจ (เช่น บ้านริมทะเล) ให้เป็น Non-Functional (ต้องทนแรงลมได้เท่าไหร่) เพื่อให้ระบบของเราเป็น "บ้านอิฐ" ไม่ใช่ "บ้านฟาง" ที่โดนหมาป่าเป่าทีเดียวก็พัง

2. Evaluating trade-offs and make informed choices

ประเมิน Trade-offs

ในโลกเทค... ไม่มีคำตอบที่ 'ดีที่สุด' มีแต่ 'เหมาะสมที่สุด' ณ บริบทนั้นๆ

"ได้อย่าง ก็ต้องเสียอย่าง" เสมอ

• ตัวอย่าง (คนละครึ่ง): ถ้าคนใช้เยอะมาก จะ Scale "Read" (คนดูข้อมูลได้) หรือ "Write" (คนลงทะเบียนได้)? ถ้าเลือก Read คนก็บ่นว่าลงทะเบียนไม่ได้ ถ้าเลือก Write คนก็อาจจะเข้ามาดูข้อมูลไม่ได้
• ตัวอย่าง (AI): จะใช้ Model ของตัวเอง (ช้าแต่คุมได้) หรือ Model as a Service (เร็วแต่แพง)?

หน้าที่ของเราคือต้องมองให้รอบด้าน ชวนทีมมาดูหลายๆ มุม และที่สำคัญ... ทุกครั้งที่ตัดสินใจ ให้บันทึก ไว้ด้วย Architecture Decision Records (ADRs) ว่าทำไมตอนนั้นเราถึงเลือกแบบนี้

3. Expanding technical breadth while keeping sufficient depth

ขยายความรู้ให้กว้าง แต่ยังให้มีความเชี่ยวชาญที่เราลงลึกอยู่

เราไม่จำเป็นต้องรู้ทุกตัว แต่เราต้อง "กระจายความรู้แนวกว้าง" (รู้ว่ามีอะไรบ้าง) และ "Maintain ความลึก" (เชี่ยวชาญบางเรื่อง) เพื่อให้เรามี 'ตัวเลือก' ในการออกแบบ Solution ที่หลากหลายขึ้น

ขอแค่ใช้ "กฎ 1%" ขอแค่วันละ 30 นาที หาความรู้เพิ่มเติม (จาก InfoQ, Thoughtworks Radar, Medium ฯลฯ)

แค่นี้เราก็จะออกแบบระบบที่ "อยู่รอด" ในยุคที่เทคเปลี่ยนไวกว่าใจคนได้แล้วครับ!