3 สิ่งที่ทำให้ Senior สอน Junior แล้วเหนื่อย พร้อมวิธีแก้

การก้าวขึ้นมาเป็น Senior หรือ Tech Lead สิ่งที่มาคู่กับ Code ที่ซับซ้อนขึ้น คือความรับผิดชอบที่ “กว้างขึ้น” และหนึ่งในหน้าที่ที่เลี่ยงไม่ได้คือ “การ Mentoring” หรือการปั้นน้องใหม่ให้เก่งขึ้น

ในทางทฤษฎี การสอน Junior คือการสร้างกำลังเสริมมาช่วยทีม แต่ในทางปฏิบัติ Senior หลายคนกลับรู้สึก Burnout ยิ่งสอนยิ่งเหนื่อย ยิ่งปั้นงานยิ่งไม่เดิน สุดท้ายต้องดึงงานกลับมาทำเองเพราะเร็วกว่า

ปัญหาไม่ได้อยู่ที่ “ตัวน้อง” หรือ “ตัวคุณ” ไม่เก่ง แต่ปัญหาอยู่ที่ Process (กระบวนการ)

ก่อนจะไปดูวิธีแก้ ลองเช็คดูครับว่าคุณกำลังเจอกับ 3 ปัญหานี้อยู่หรือเปล่า?

1. โดนขัดจังหวะจนเสียโฟกัส

Developer แบบเราจะรู้ดีว่าการดำดิ่งลงไปใน Code ต้องใช้สมาธิสูงมาก

แต่การที่ Junior เดินมาสะกิดไหล่หรือทักแชทมาว่า "พี่ครับ ดูตรงนี้ให้หน่อย" ทุกๆ 30 นาที ทำให้เราเสียโฟกัสตลอดเวลา กว่าจะกลับมาจูนติดว่าเขียน Code ถึงบรรทัดไหน ก็เสียเวลา

2. คำถามเดิมๆ ซ้ำๆ

"พี่ครับ ตรงนี้รันยังไงนะครับ?" ทั้งที่คุณเพิ่งสอนไปเมื่อวาน หรือการถามคำถามที่หาคำตอบได้ง่ายๆ ใน Google หรือใน Documentation

ปัญหานี้ไม่ได้เกิดจากน้องจำไม่ค่อยได้เสมอไป แต่อาจเกิดจากการที่เราไม่ได้กำหนด "กติกาการถาม" ทำให้เขารู้สึกว่าการถามพี่ ง่ายกว่าการหาเอง

3. ระเบิดเวลาแบบเงียบๆ

นี่คือสิ่งที่น่ากลัวที่สุด คือการที่ Junior เงียบหายไปทั้งวัน เรานึกว่าเขากำลังทำได้ดี แต่พอถึงกำหนดส่งงาน กลับเดินมาบอกว่า "ผมติดตรงนี้ตั้งนานแล้ว แก้ไม่ได้ครับ"

การ "ไม่กล้าขอความช่วยเหลือ" จนนาทีสุดท้าย ทำให้ Senior ต้องกลายร่างเป็นนักดับเพลิง คอยตามแก้ไฟไหม้จนงานตัวเองเสีย

สร้างทางออกด้วย Mentorship Agreement

การแก้ปัญหาเหล่านี้ ไม่ใช่การเลิกสอน แต่คือการสร้างข้อตกลงร่วมกัน หรือ Mentorship Agreement

แทนที่จะเปิดโอกาสให้ถามเมื่อไหร่ก็ได้ ให้เปลี่ยนมาเป็นการ "ตกลงร่วมกัน" เพื่อเปลี่ยนความคาดหวังให้ชัดเจน ด้วย 3 ขั้นตอนง่ายๆ ดังนี้:

Step 1: เป้าหมายคืออะไร (Goal Setting)

อย่าสอนไปเรื่อยๆ ให้กำหนดเป้าหมายระยะสั้นที่วัดผลได้จริง เพื่อให้ Junior โฟกัสถูกจุด

• ❌ ตัวอย่างที่คลุมเครือ: "อยากให้เก่ง Java ขึ้น"
• ✅ ตัวอย่างที่ชัดเจน: "ภายใน 1 เดือน ต้องสามารถเขียน Unit Test ให้ครอบคลุม Business Logic หลักได้"

Step 2: เจอกันถี่แค่ไหน (Frequency & Boundaries)

เพื่อเพิ่มโฟกัสของคุณเอง และฝึกให้ Junior รู้จักรวบรวมปัญหาก่อนถาม ให้กำหนดเวลาคุยที่แน่นอน

• ปกป้องเวลาส่วนตัว: ตกลงกันว่าช่วงเช้าขอเขียน Code ห้ามกวน (ยกเว้น Production ล่ม)
• Office Hour: รวบรวมคำถามมาคุยกันทุกวันอังคารและพฤหัส ตอน 14:00 น. หรือ Standup Meeting สั้นๆ 15 นาทีตอนเย็น

Step 3: วันสิ้นสุดข้อตกลง (Timeline)

การ Mentoring ไม่ควรทำไปตลอดกาล ควรกำหนดระยะเวลาเพื่อวัดผล

• เช่น "เราจะลองทำตามแผนนี้ 1 เดือน แล้วมาดูกันว่าน้องเขียน Unit Test ได้ตามเป้าไหม"
• ถ้าทำได้สำเร็จ ก็ค่อยขยับไปตั้ง Goal ใหม่ หรือถ้าไม่สำเร็จ จะได้หาสาเหตุและปรับวิธีสอนทันที ไม่ใช่ปล่อยยืดเยื้อไปครึ่งปี

การทำ Mentorship Agreement เป็นสิ่งที่ควรทำ

การทำ Mentorship Agreement ไม่ใช่การใจร้ายกับ Junior แต่คือการฝึกความรับผิดชอบ (Ownership) ให้กับเขา และเป็นการ "คืนเวลา" ให้กับตัวคุณเอง

เมื่อกติกามันชัด น้องจะกล้าทำงานมากขึ้น พี่ก็จะได้เขียน Code อย่างสงบสุข และนั่นคือจุดเริ่มต้นของคำว่า High-Performing Team อย่างแท้จริงครับ