เมื่อก้าวสู่ตำแหน่งบริหาร ต้องรู้จักตรวจสอบงาน

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

ตรวจถี่แค่ไหนดี

สูงความเสี่ยงของงานต่ำ

ความเสี่ยงของงาน: สูง · ความชำนาญของคนทำ: ยังใหม่

ตรวจทุกจุด

นัดดูงานถี่ ทำด้วยกันช่วงแรก และตรวจก่อนส่งทุกครั้ง

• เช่น น้องนัท นักพัฒนาใหม่ เขียนสคริปต์ย้ายข้อมูลนักศึกษา 40,000 คนเป็นครั้งแรก ก่อนเปิดระบบลงทะเบียนเรียนของมหาวิทยาลัยลูกค้า

ความเสี่ยงของงาน: สูง · ความชำนาญของคนทำ: ชำนาญ

ตรวจจุดวิกฤต

ตกลงจุดตรวจ 2–3 จุดไว้ล่วงหน้า นอกนั้นปล่อยให้ทำเอง

• เช่น นักพัฒนา backend ที่ย้ายข้อมูลมา 5 ปี ตกลงแค่ 3 จุด: ซ้อมรันก่อน จำนวนแถวตรงกัน มีแผนถอยกลับ

ความเสี่ยงของงาน: ต่ำ · ความชำนาญของคนทำ: ยังใหม่

สุ่มตรวจแล้วสอน

ตรวจบางชิ้น แล้วใช้เป็นโอกาสสอนงาน

• เช่น นักพัฒนา frontend คนใหม่แก้ข้อความและสีหน้าจอในแอปจองคิว

ความเสี่ยงของงาน: ต่ำ · ความชำนาญของคนทำ: ชำนาญ

ดูแค่ผลลัพธ์

ดูตัวเลขปลายทางและจุดที่ผิดปกติ ไม่ต้องดูทุกขั้นตอน

• เช่น นักพัฒนา frontend ที่ดูแลแอปจองคิวมา 5 ปี ดูแค่เรื่องที่ร้านแจ้งเข้ามาหลังปล่อยเวอร์ชันใหม่

ยังใหม่ความชำนาญของคนทำชำนาญ

แกนตั้ง: ความเสี่ยงของงาน (ต่ำ → สูง) แกนนอน: ความชำนาญของคนทำ (ยังใหม่ → ชำนาญ)

ตัวอย่างจากทีมของพี่วุฒิ (Tech Lead) · ตรวจห่างขึ้นเมื่อคนชำนาญขึ้น ไม่ใช่เมื่อหัวหน้ายุ่งขึ้น

ตรวจงาน ไม่ใช่จับผิดคน

• ตกลงจุดตรวจตั้งแต่ตอนมอบงาน คนทำรู้ล่วงหน้าว่าจะถูกดูตรงไหน เมื่อไร ไม่ใช่ถูกตรวจแบบจู่โจม
• ตรวจเทียบเกณฑ์ที่ตกลงไว้ ไม่ใช่เทียบกับความชอบของคุณ
• พูดที่งาน ไม่พูดที่นิสัย “สคริปต์ยังไม่รองรับนักศึกษาที่มี 2 รหัส” ดีกว่า “สะเพร่าอีกแล้ว”
• ปิดด้วยคำถาม “ติดอะไรไหม ให้ช่วยอะไรไหม” การตรวจจึงกลายเป็นการช่วย ไม่ใช่การจับผิด

ส่วนการไล่ดูทั้งทีมทุกสัปดาห์ ตั้งแต่เป้า งาน คน จนถึงตัวคุณเอง ใช้ 4 ตรวจ

จำให้ขึ้นใจ

เสี่ยงสูงตรวจถี่ ชำนาญแล้วตรวจห่าง — คนทำตามสิ่งที่คุณ “ตรวจ” ไม่ใช่สิ่งที่คุณ “หวัง”

อ่านต่อ: บริหารคนให้เหมาะกับแต่ละคน · อย่าบริหารเกินบทบาท · บริหารงานแบบวงจรปิด