[PRIMO Tech-a-Break] เลิกบ่นว่าเสียเวลาถ้าไม่ได้ Task! : เปลี่ยน Mindset การประชุม ให้เป็น Dev สาย Context-Driven

อันนี้คือ 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 ของอันนี้คืออะไรครับ?”

2. 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)

3. “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 ที่ง่ายกว่า เร็วกว่า และไม่ต้องเขียนปุ่มสีเขียวบ้านั่นเลยก็ได้