ยอมรับกันตรงๆ ไหมครับ? ว่าบ่อยครั้งเวลา Dev อย่างเราเดินออกจากห้องประชุม สิ่งที่เราบ่นกับเพื่อนคือ “สรุปเรียกมาทำไมวะ? ไม่เห็นมี Task อะไรให้ทำเลย” หรือ “คุยกันตั้งนาน สรุปให้กูทำอะไร? เสียเวลาเขียนโค้ดชิบหาย”
เรามักจะคาดหวังว่า Meeting ที่ดี = Meeting ที่จบแล้วได้ Ticket ที่เขียน Spec มาเป๊ะ ๆ ว่าต้องแก้ไฟล์ไหน บรรทัดที่เท่าไหร่ แต่หารู้ไม่ว่า… นั่นคือ Mindset ที่กำลังขังเราไว้เป็นแค่ “Coder” ไม่ใช่ “Software Engineer”
จริงๆ แล้วการประชุมที่มีประสิทธิภาพ ไม่ใช่การป้อน Task ใส่ปากเรา แต่คือการ Sync “Context”
วันนี้ผมเลยอยากชวนทุกคนมา Refactor ความคิด ตัวเองกันใหม่ ว่าทำไมเราถึงควรเลิกโหยหา Task แล้วหัดมองหา "The Why" ในห้องประชุมแทน
- “Context, Not Control” (หยุดรอคำสั่ง แล้วเริ่มหา Business Logic)
อันนี้คือ Culture ของ Netflix ที่น่าสนใจมาก
The Exception: เรามักหงุดหงิดเวลา Business หรือ PM อธิบายภาพกว้าง ๆ เวิ่นเว้อ แล้วเราก็คิดในใจว่า “ข้ามไปตอนสั่งงานเลยได้ป่ะ?”
The Fix: ใจเย็นก่อน… การที่เขาไม่ออกคำสั่ง แต่พยายามเล่าที่มาที่ไป นั่นคือเขากำลังให้ “Context” หน้าที่ของคุณไม่ใช่การรอรับคำสั่ง แต่คือการ Inject Context นั้นเข้าสมอง
- Why it matters: ถ้าคุณรู้แค่ Task (What) คุณจะเขียนโค้ดได้แค่ตามสั่ง แต่ถ้าคุณรู้ Context (Why) คุณจะสามารถ Design Solution ที่ดีกว่าที่ PM คิดได้ด้วยซ้ำ
- Challenge: เลิกทำตัวเป็น Function ที่รอรับ Parameter แต่จงทำตัวเป็น AI ที่เข้าใจ Intention ของ User ถ้าเข้าประชุมแล้วยังไม่รู้ว่า “ทำไปทำไม” อย่าเพิ่งถามหา Task แต่ให้ถามกลับไปว่า “Business Goal ของอันนี้คืออะไรครับ?”
- The “API Contract” Approach (Input/Output ต้องชัด แต่ Output ไม่จำเป็นต้องเป็น Code)
The Exception: “ประชุมจบแล้ว ไม่มี Action Plan ให้ Dev เลย” -> return null;
The Fix: อย่ามองว่า Output ของการประชุมต้องเป็น Coding Task เสมอไป บางครั้ง Output ของการประชุมคือ “Clarity” (ความชัดเจน) หรือ “Decision” (การตัดสินใจ)
- How to: ทรีตการประชุมให้เหมือน API Call
- Input: ก่อนเข้าประชุม อ่าน Agenda ให้แตก (Pre-processing)
- Process: ถกเถียงกันด้วย Logic และ Data
- Output: สรุปให้ได้ว่า “เราจะไปทางไหนต่อ”
- ถ้าจบประชุมแล้วไม่ได้ Task เขียนโค้ด แต่ได้ข้อสรุปว่า “ฟีเจอร์นี้ยังไม่ควรทำตอนนี้” นั่นถือว่าเป็น Successful Meeting นะครับ เพราะมันช่วย save effort ทีม ไม่ให้ไปเขียนโค้ดที่ไม่มีใครใช้ (Dead Code)
- “First Principles Thinking” (ขุดหา Root Cause ดีกว่ารับ Requirement มาแบบ Hardcode)
The Exception: รับ Requirement มาแบบงงๆ ว่า “ลูกค้าอยากได้ปุ่มสีเขียวตรงนี้” -> เราก็ก้มหน้าก้มตาทำ –> สุดท้ายมารู้ทีหลังว่า User ไม่ได้อยากได้ปุ่ม แต่อยากได้ทางลัด
The Fix: หลักการ First Principles ของ Elon Musk ในห้องประชุม หน้าที่ของเราไม่ใช่แค่รับ Requirement มา implement เลย แต่ต้องช่วยทีม Debug ความคิดตั้งแต่นาทีแรก
- Challenge: ฝึกตัวเองให้เป็นคน “ขี้สงสัย” (ในทางสร้างสรรค์)
- อย่าเพิ่งรีบถามว่า “ใช้ Library ตัวไหน?”
- ให้ถามว่า “ปัญหาจริงๆ ของ User คืออะไร?”
- บางทีพอเราเข้าใจ The Why จริงๆ เราอาจจะเสนอวิธีแก้ปัญหาทาง Tech ที่ง่ายกว่า เร็วกว่า และไม่ต้องเขียนปุ่มสีเขียวบ้านั่นเลยก็ได้
เพื่อน ๆ ครับ การบ่นว่า “ประชุมมีแต่น้ำ” บางทีอาจจะเป็นเพราะเรา Filter หาเนื้อไม่เป็น เองก็ได้ การประชุมที่มีคุณภาพ ไม่ใช่โรงงานผลิต Task แต่เป็นพื้นที่สำหรับ Align Context
- เลิกรอให้ใครมาป้อนงาน (Task)
- ฝึกสกิลในการจับ “The Why” ให้ได้
- แล้วคุณจะพบว่า การประชุมที่ ไม่มีงานงอก นี่แหละ คือโอกาสทองให้เราได้ใช้สมอง Engineer Design ระบบที่ถูกต้องที่สุดตั้งแต่แรก
แต่ถ้าใครเจอประชุมที่ไม่ได้ทั้ง Context และ Solution อันนี้ผมก็คงต้องบอกว่า “เหนื่อยหน่อยนะเพื่อน”
แล้วพบกันใหม่กับ PRIMO Tech-a-Break ครั้งหน้าครับ
ติดตามบทความใหม่ ๆ คลิกเลย
