⏱️ ‘ประเมินเท่าไร ให้คูณสอง!’ (Over Estimation) 😱

ถอดรหัส 4 ‘หลุมดำ’ ของการประเมินโปรเจกต์ ที่ทำให้ ‘Estimate’ ของคุณ ‘ไม่เคยตรง’ (และวิธีเอาตัวรอด!) 💥

🧭 บทเรียนที่ผมไม่เคยลืม”

“เวลา Estimate งาน ให้คุณคูณสองก่อนบอก PM”

ประโยคนี้มาจากที่ปรึกษาท่านหนึ่งในโปรเจกต์แรกของผม ซึ่งตอนนั้นฟังดูเหมือนเล่นมุก…แต่พอผ่านไป 6 เดือน ผมไล่นับวันทำงานจริง — 90 กว่า man-day ใกล้เคียงกับ 2 เท่าที่เขาแนะไว้เป๊ะ!

สิ่งที่เขาสอน ไม่ใช่แค่สูตรสำเร็จ แต่คือ “Mindset” ว่าเราต้องเผื่อไว้เสมอ เพราะการประเมินในโลกของซอฟต์แวร์ ไม่เคยแม่น 100% และบทความนี้…จะพาไปดูว่า “ทำไม” และ “จะอยู่กับมันอย่างไร” พร้อมแนวทางที่คุณสามารถนำไปใช้ได้ในทีมของคุณจริงๆ

ผมหวังว่าบทความนี้จะไม่ใช่แค่การถ่ายทอดประสบการณ์ แต่เป็นเครื่องมือให้คุณใช้สร้างความเข้าใจในทีม เสริมศรัทธาระหว่างกัน และลดความขัดแย้งระหว่างฝั่งธุรกิจกับฝั่งเทคนิคลงได้บ้าง

🕳️ 1. 4D Blackholes — หลุมดำที่กลืนเวลาคุณทุกโปรเจกต์

🔲 D1: Dev Dependency Hell — ปัญหาทางเทคนิคที่ดูเล็ก แต่พังได้ทั้งระบบ ตัวอย่างเช่น

“เมื่อวานยังรันได้…แต่วันนี้ขึ้น staging แล้วพัง!”

• ใช้ Node.js คนละเวอร์ชัน → รันไม่ได้ • Library ถูกอัปเดตโดยไม่รู้ตัว → เจอ bug ใหม่ • config ที่ dev ใช้ได้ → แต่ production พังเพราะ env ไม่ตรงกัน

📦 คำว่า “Freeze Dependency” แปลตรงๆ ว่า “แช่แข็งเวอร์ชัน” — เหมือนการเลือกแป้งขนมสูตรเดิมทุกครั้ง เพราะแค่เปลี่ยนยี่ห้อเดียว…รสชาติอาจเพี้ยนทั้งถาด

💡 วิธีเอาตัวรอด?

• ใช้ Docker (เหมือนแพ็คงานลงกล่องพร้อมรันทุกที่)
• ใช้ Dev Container หรือ Prebuilt Image ที่ lock สภาพแวดล้อมให้เหมือนกันหมด
• เขียน README และ onboarding ที่ให้ dev ใหม่ set env ได้ใน 15 นาทีแบบ reproducible
• ใช้ CI/CD Pipeline ตรวจ version dependency ก่อน Merge ทุกครั้ง

🔲 D2: Differing Definition — เข้าใจ Requirement คนละแบบแบบไม่รู้ตัว

“อ้าว! ต้องรองรับภาษาอังกฤษด้วยเหรอ?”

• ลูกค้าคิดแบบหนึ่ง → เขียน requirement ไว้ไม่ครบ • dev อ่านอีกแบบ → สร้างระบบที่ตอบคนละโจทย์

ในโลกจริง การ “เข้าใจไม่ตรงกัน” เกิดขึ้นแม้ในการคุยกันตรงๆ เพราะแต่ละคนมี “กรอบความคิด” (mental model) ต่างกัน เช่น ผู้ใช้อาจพูดว่า “อยากได้ระบบค้นหาง่ายๆ” — แต่ง่ายของเขา คือ Google-style search แต่ของ dev คือช่องค้นหาธรรมดาที่มี filter 1–2 ตัว

💡 วิธีเอาตัวรอด?

• ใช้ mockup, wireframe, หรือ clickable prototype ให้เห็นของจริง
• ทำ scenario walk-through กับ user จริง เพื่อให้เข้าใจ flow ใช้งานจริง
• จด Use Case + Non-use Case ให้ครบถ้วน
• ถ้าเจอ keyword กว้าง เช่น “เร็ว”, “ง่าย”, “สวย” → ต้องให้ทุกฝ่ายช่วย define

🔲 D3: Disguised Scope Creep — “แค่เปลี่ยนนิดเดียว” ที่กลายเป็นช้าง

“พี่แค่ขอเพิ่มช่อง filter อีกหน่อยเอง” → กลายเป็น redesign ทั้งระบบค้นหา

Scope Creep ไม่ได้แย่เสมอ เพราะมันสะท้อนว่า user ใช้ระบบจริงแล้วเจอสิ่งที่ควรปรับปรุง แต่ถ้าไม่มีการวางรั้วป้องกัน มันจะทำลายทั้ง timeline และ morale ของทีมแบบไม่รู้ตัว

💡 วิธีเอาตัวรอด?

• ตั้ง Budget Time สำหรับ Unplanned Change (เช่น 20% ของ sprint)
• ใช้วิธี MoSCoW Prioritization (Must–Should–Could–Won’t Have) กับทุก Feature
• ตอบกลับคำขอแบบมีเหตุผล เช่น “เพิ่มฟีเจอร์นี้ใช้เวลา 3 วัน ต้องแลกกับฟีเจอร์ที่วางไว้ไหม?”

🔲 D4: Detached Estimator — คนประเมิน ≠ คนทำจริง

Senior ประเมินว่า “3 วันน่าจะพอ” → แต่โยนให้ Junior ที่ใช้เวลา 8 วันยังไม่เสร็จ

หลายองค์กรให้ Lead เป็นคน Estimate เพราะ “เขามองภาพรวมได้” แต่ลืมไปว่า คนเขียนโค้ดจริงอาจยังไม่เข้าใจ pattern หรือ architecture ที่ complex เหล่านั้น เช่น Junior อาจไม่เคยเชื่อม OAuth กับระบบ 3rd party มาก่อน แม้แต่งานเล็ก ๆ ก็กลายเป็นภารกิจใหญ่ได้

💡 วิธีเอาตัวรอด?

• ให้คนทำประเมินเอง (Bottom-up Estimation)
• หรือให้ Senior จับมือ Junior คุยเพื่อ calibrate ให้เข้าใจความสามารถจริง
• ใช้ Planning Poker หรือ Team Estimation Game เพื่อให้ทุกเสียงมีส่วนร่วม

🗣️ 2. ศิลปะของ Estimation คือการ ‘สื่อสารความไม่แน่นอน’ อย่างมืออาชีพ

🎯 Estimation ไม่ใช่ “คำสัญญา” แต่คือ “บทสนทนาเรื่องความเสี่ยง” ที่ผู้บริหาร, PO, และทีมต้องกล้าคุยกันอย่างตรงไปตรงมา

✅ เทคนิคที่ควรใช้?

1. สื่อสารเป็นช่วง (Range Not Point)

• “ใช้เวลา 10–15 วัน โดย Worst case คือ 15” → เปิดพื้นที่เผื่อความเปลี่ยนแปลง และลดความคาดหวังผิดพลาด

2. ใช้การ Estimate เป็น ‘เครื่องมือคิด’ ร่วมกับทีม

• ไม่ใช่แค่ “ใส่ตัวเลข” แต่ใช้โอกาสนี้ identify ความเสี่ยง จุดไม่แน่ใจ และเช็ค resource

3. วางวัฒนธรรม “ผิดได้ แต่ต้องเรียนรู้”

• ห้าม blame เมื่อ dev ทำไม่ได้ตามเวลา เพราะนั่นจะทำให้รอบหน้าทุกคน estimate แบบปิดบัง (หรือเงียบไปเลย)

4. ปกป้องคุณภาพเสมอ

• ถ้า deadline บีบจน dev ต้อง hardcode หรือข้าม testing → จะกลายเป็น Technical Debt ที่ต้องจ่ายแพงในอนาคต

5. ใช้ Velocity และ Historical Data

• แทนที่จะใช้ “ความรู้สึก” ในการประเมิน ลองใช้ข้อมูลย้อนหลัง 3 sprint มาช่วย benchmark ความเป็นจริงของทีม

✨ “จงประเมินด้วยความซื่อสัตย์ ไม่ใช่ความเก่ง”

Consultant ที่ให้ผมคูณสอง ไม่ได้อยากให้ผมโกหก แต่ให้ผมเผื่อชีวิตจริงที่ “ไม่ได้เดินตรงตามแผน” เพราะในความเป็นจริง…ไม่มีใครรู้ทุกอย่างตอนเริ่มโปรเจกต์

ในโลกซอฟต์แวร์ ไม่มีการประเมินใดแม่น 100% แต่เราสามารถประเมินได้ “ซื่อสัตย์” และ “ชวนทีมคุยอย่างโปร่งใส” ว่าอะไรคือ known–unknown ที่เราต้องเผื่อไว้

📌 ข้อคิด “Estimate ที่ดี ไม่ใช่คำตอบที่แม่นยำ…แต่คือคำเชิญชวนให้ทุกคนกล้าคุยเรื่องความไม่แน่นอน ด้วยความเข้าใจ ไม่ใช่ด้วยความกลัว”

วันละเรื่องสองเรื่อง

4DBlackholes

EstimateWithEmpathy

DevRealism

TechLeadership

บริหารความคาดหวัง