เมื่อต้อง Estimate ด้วยวิธีดั้งเดิม

PERT, Delphi and More

สวัสดีครับ สำหรับทุกคนที่ “จำเป็น — จำใจ” ต้องใช้วิธีการ Estimate งานในโปรเจกต์แบบเดิมอยู่

1. การใช้เวลาในการ Estimate มากไม่ได้เป็นการการันตีว่าจะได้ผลที่ถูกต้องมากขึ้น
2. ใช้ PERT* ในการทำ Estimation แล้วถือว่าโอเคนะแต่ใช้เวลาพอสมควร
3. ใช้ Delphi** ในการทำ Estimation ก็ดีเหมือนกันเพราะได้ความคิดเห็นจากคนมากกว่าหนึ่งคน มีการเปิดช่องให้พูดคุยเพื่อทำความเข้าใจในงานระหว่างกันด้วยแต่เสียเวลามากเลย
4. เคยเอาคนทั้งทีมมาช่วยกันทำนะ นั่งรวมกันในห้องประชุมแล้วก็ Estimate ร่วมกัน เสียเวลา เสียแรง ผลที่ได้ก็ใช่จะตรงเป๊ะ ไม่คุ้มเท่าไร
5. ตอนหลังเลยเปลี่ยนเป็นจับคู่กัน Estimate ส่วนใหญ่จะเป็น Senior + Junior คู่กันช่วยกัน Estimate เฉพาะงานที่ได้รับมอบหมายให้ทำ ประหยัดเวลาได้มากขึ้น ผลลัพธ์ที่ได้ก็โอเค ถือว่าคุ้มค่าที่จะทำต่อ
6. สำคัญมากว่าควรจะให้คนทำได้มีสิทธิมีเสียงในการ Estimate ด้วย ไม่ใช่ว่าใครก็ไม่รู้จับงานมายัดใส่มือพร้อมกับเวลาที่น้อยเกินไป
7. หลังๆเริ่มมีการรวมกลุ่มระหว่าง Developer และ QA เข้ามาช่วยกัน Estimate เพื่อเปิดมุมมองของอีกฝั่งหนึ่ง ประโยชน์ที่ได้รับก็คือการทำ Requirement Analysis และ Design ไปในตัวเลย
8. ได้ด้วเลขมาแล้วก็อย่าลืมคิดเรื่องวันหยุดราชการ วันลาพักร้อนและวันลาป่วยเผื่อๆไว้ด้วย
9. ได้ตัวเลขมาแล้วก็อย่าลืมบวก Buffer ไปด้วยนะ ไม่งั้นเดี๋ยวมี Change เข้ามาแล้วจะยุ่ง
10. อย่ามองว่า Software Estimation คือกระบวนการที่ทำครั้งเดียวเสร็จ หมั่นตรวจสอบผลการ Estimate อยู่เรื่อยๆเพราะบ่อยครั้งตัวเลขที่ได้มามันไม่ตรงหรอก ถ้า Requirement แรกก็คลาดเคลื่อนไปมากกว่า 30% แล้วเราควรจะมานั่งพิจารณาหน่อยว่า เฮ้ย แล้วไอ้ Requirement ที่เหลือมันจะตรงมั้ยวะเนี่ยะ ฮ่าๆๆ กระบวนการนี้เรียกว่า Re-Estimation
11. ถ้า Requirement ไม่ค่อยชัดเจนหรือคาดการณ์แล้วว่าต้องมีการเปลี่ยนแปลงเกิดขึ้นเรื่อยๆ แนะนำให้ใช้ Iterative จะดีกว่า การทำ Estimation จะยืดหยุ่นมากขึ้นด้วย
12. ถ้าเป็นไปได้ก็พยายามแบ่ง Requirement ออกมาเป็นส่วนย่อยๆแล้วค่อย Estimate จากงานที่เล็กๆ ตัวเลขที่ได้จะแม่นยำกว่าเดิม
13. ถ้าไม่แน่ใจว่างานนี้ยากง่ายแค่ไหน ลองปรึกษาผู้เชี่ยวชาญดูก่อน จะทีมเดียวกันหรือต่างทีมก็ได้นะ

*Program Evaluation and Review Technique (PERT)

PERT เป็นทฤษฎีทางสถิติที่ใช้อย่างแพร่หลายใน Project Management โดยเฉพาะอย่างยิ่งกับการทำ Task Estimation เวลาใช้งานก็ไม่ยากเลย … PERT ขอแค่ตัวเลขสามตัว

1. Best case: ถ้าพูดถึง Estimation เราจะตอบคำถามที่ว่า “คุณคิดว่าคุณจะใช้เวลาน้อยที่สุดเท่าไรในการทำงานนี้ให้เสร็จ?” ให้เข้าข้างตัวเองเต็มที่เลย
2. Worst case: กลับกัน “อย่างแย่ที่สุด คุณต้องการเวลาเท่าไร?”
3. Most likely case: ทางสายกลางครับ “เอาแบบแมนๆ คุณคิดว่าจริงๆแล้วคุณต้องการเวลาเท่าไรในการทำงานให้เสร็จ?”

เมื่อได้ตัวเลขสามตัวนี้มาแล้วก็ส่งเข้าคำนวณในสูตรสำเร็จนี้

งานนี้ก็ใช้เวลาประมาณ 25 วัน

**Delphi

Delphi เป็นอีกเทคนิคที่ใช้ในการทำ Task Estimation หลักการที่ผมเคยใช้โดยสรุปคือจะให้ผู้เชี่ยวชาญมากกว่าหนึ่งคนมา Estimate งานเดียวกัน

การ Estimate จะทำเป็นรอบ รอบแรกต่างคนต่างให้ความคิดเห็นแล้วเอามาดูกันว่าตัวเลขที่ได้เป็นอย่างไร … หารเฉลี่ยออกมาแล้วถามว่า “โอเคกันมั้ยทั้งสามท่าน?” ถ้ามันมีความแตกต่างกันมากอย่าง 10–30–35 แบบนี้ก็คงไม่โอเคหรอก มันต้องมีความเข้าใจในเนื้องานที่ต่างกันแน่นอน

หลังจากพูดคุยเพิ่มเติมเรื่องรายละเอียดของงาน … เราจะเริ่มต้นการ Estimate รอบสองและรอบสามจนได้ตัวเลขที่ใกล้เคียงกันมากขึ้น “ว่าไงทุกท่าน 30 วัน?” … “โอเคๆ” — จบครับ งานนี้น่าจะใช้เวลา 30 วัน (ตรงหรือไม่แล้วแต่บุญแต่กรรม ฮ่าๆ)

ผมเขียนบทความนี้เพราะอยากเปลี่ยนแปลงสิ่งที่เป็นอยู่ในอุตสาหกรรมการผลิตซอฟท์แวร์ให้ดีขึ้นตามความเชื่อและประสบการณ์ของผม ถ้าเพื่อนๆเชื่อในแนวทางเดียวกัน เรามาช่วยกันคนละไม้คนละมือทำให้สังคมของเราดีขึ้นครับ จะแชร์บทความนี้ผ่าน Social Network หรือจะแบ่งปันเรื่องราวนี้ให้คนที่นั่งข้างๆฟังบ้างก็ได้

The Future Has Arrived — It’s Just Not Evenly Distributed Yet, William Gibson

อนาคตอยู่ตรงนี้แล้ว เรามีหน้าที่ต้องถ่ายทอดมันออกไปให้คนอื่นได้สัมผัสสิ่งดีๆร่วมกันครับ