การประเมิน Software ให้ถูกต้องแบบ Uncle Bob

วันนี้ผมจะมาสรุปสิ่งที่ลุง Bob พูดเกี่ยวกับการประเมินให้ถูกต้อง ในงาน YOW!2016 มาให้อ่านกันครับ สำหรับใครที่ต้องการดูวีดีโอตัวเต็มสามารถกดเข้าไปดูได้ที่นี้เลย

1. การประเมินที่ผิด จะทำให้คนไม่ไว้ใจเรา

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

2. การประเมินส่วนใหญ่ เป็นการประเมินที่แย่

เพราะการประเมินเป็นสิ่งที่ยาก โดยเฉพาะการประเมินการเขียน software เช่นถ้าให้คุณประเมินเวลาในการผูกเชือกรองเท้า คุณอาจจะประเมินว่าผูกได้ในเวลาไม่ถึง 5 วินาที และการประเมินนั้นอาจจะถูกเป๊ะๆ แต่ถ้าให้คุณประเมินการเขียนวิธีการผูกเชือกรองเท้า คุณจะประเมินผิดแน่นอน การเขียนวิธีการทำอะไรสักอย่าง คือสิ่งที่โปรแกรมเมอร์อย่างเราทำ เรามักจะประเมินผิดอย่างน้อย 3 เท่า แม้ว่าเราจะรู้อยู่แล้วว่าเราจะประเมินผิดอย่างน้อย 3 เท่า 😂

3. บางทีเราก็ประเมินสูงไป

เรามักจะประเมินอะไรที่ดูยาก และไม่รู้ว่าต้องทำยังไง ณ เวลานั้น สูงเกินไป แต่เมื่อลงมือทำจริงๆ อาจจะไม่ใช้เวลาเยอะขนาดนั้น

4. การประเมินที่ดีควรจะมีสามสิ่งนี้

1. ซื่อสัตย์ - ถ้ามันเป็นข่าวร้าย คุณต้องสามารถบอกข่าวร้ายได้ ไม่ว่าบอกไปแล้ว คุณจะโดนด่า หรือโดนดุ เพราะว่าถ้าคุณกล้าบอกข่าวร้าย แล้วมันถูก คุณจะสร้างความเชื่อใจให้กับคนที่คุณบอก
2. ต้องแม่น - เมื่อถึงเวลาที่คุณประเมิน มันจะต้องเสร็จตามที่คุณบอกจริงๆ
3. ต้องละเอียด ต้องเป๊ะ - อย่าประเมินว่างานจะเสร็จภายในชีวิตนี้ และอย่าเป๊ะเกินไป อย่าพยายามประเมินว่าจะเสร็จวันไหน ให้ประเมินว่าจะเสร็จช่วงวันไหน

5. การประเมินส่วนใหญ่ เป็นการโกหก

ถ้าคุณประเมินว่างานจะเสร็จวันที่ … ส่วนใหญ่คุณก็ทำไม่เสร็จวันนั้นหรอก เพราะฉะนั้นคุณโกหก หรือว่าคุณทำเสร็จไปแล้ว แต่ประเมินว่าจะเสร็จอาทิตย์ คุณโกหก สาเหตุหนึ่งที่ทำให้คุณโกหก เพราะว่าคุณประเมินจากหลังมาหน้า โปรเจ็คส่วนใหญ่คุณรู้อยู่แล้วว่า end date มันต้องอยู่วันไหน คุณถูกบีบมากว่ามันจะต้องเสร็จวันนี้ แล้วบ่อยครั้งที่ถ้าคุณประเมินให้ถูกต้องมันจะเกิน end date สิ่งที่คุณทำต่อไปก็คือโกหกว่ามันจะเสร็จ สิ่งที่คุณควรจะทำคือประเมินอย่างถูกต้อง แล้วเอามาแผ่ดูว่า features ไหนที่ตัดออกไปได้บ้าง หรืออันไหนที่ถ้าเพิ่มคนจะช่วยให้คุณทำเสร็จทัน หรือถ้ายังไงไม่เสร็จคุณก็ควรยืนกรานในสิ่งที่คุณประเมิน

6. การประเมินให้ถูกต้อง

หากคุณต้องการประเมินให้ถูกต้อง ให้ทำ Work Breakdown Structure แค่ไม่กี่ level แล้วประเมินเวลา เสร็จแล้วคูณจำนวนวันทั้งหมดด้วย 4 - 6 เพราะว่าการประเมินภาพรวมได้ไม่แม่น หากเราต้องการประเมินให้แม่นขึ้น เราต้องใช้เวลานานมาก และเวลาคือเงิน เพราะฉะนั้นทำ Work Breakdown แค่ 3 - 4 level พอ แล้วคูณ 4 - 6 ไปดีกว่า

เพราะถ้าคุณต้องการตัวเลขที่ถูกต้องจริงๆ คุณต้องทำโปรเจ็คนั้นไปแล้วจริงๆ หน้าที่คุณก็คือต้องบอกให้ manager รู้ด้วยเช่นกัน Cost ของการประเมินให้แม่นขึ้นโต exponential แต่สิ่งได้รับกลับมาเป็น logarithm 👈

7. สูตรการประเมิน

ให้ประเมินเป็น 3 สถานการณ์

1. ทุกอย่างเป็นไปได้สวย (B) - โอกาสเกิดขึ้นแค่ 5%
2. ทุกอย่างพังพินาศ (W) - โอกาสเกิดขึ้น 95%
3. ทุกอย่างตามที่คาดไว้ (N)- โอกาสเกิดขึ้น 50%

ทุกครั้งที่คุณตอบการประเมินให้บอกเป็นช่วงเวลา คุณสามารถโชว์ graph ความน่าจะเป็นได้

คุณสามารถเอาเลขที่คุณประเมินมาวาด normal distribution โดยใช้สูตรด้านล่าง เพื่อแสดงช่วงของการประเมิน

\[stddev = (W-B)/6\] \[mean = (B+W+4N) / 6\] \[ProjectMean = sum(mean)\] \[ProjectStdDev = sqrt(sum(stddev^2))\]

8. หน้าที่ของ Manager คือการ Manage ความไม่แน่นอน

ถ้าคุณให้การประเมินเป็นช่วงเวลาแบบด้านบน Manager จะไม่เอาแน่นอน เพราะมันคือหน้าที่ของเขาที่ต้องกำจัดความไม่แน่นอน แต่ก็ไม่เป็นไร สิ่งที่คุณต้องทำการคือยืนหยัดกับความจริง และ ห้ามให้สัญญา ถ้าคุณทำตามคำสัญญาไม่ได้ เพราะ Manager ก็จะประเมินงานอื่นๆตามคำที่คุณบอก ถ้าคุณประเมินผิดจะทำให้เกิด domino effect หรืองานพังต่อๆกันไป คุณต้องกล้าที่จะบอกว่า ไม่ ถ้ามันเป็นไปไม่ได้จริงๆ

9. โปรแกรมเมอร์ไม่ชอบการเผชิญหน้า

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