ค่าประมาณไม่ใช่เป้าหมาย แต่เป็นเครื่องมือสื่อสาร

“ใช้เวลานานเท่าใดในการทำเช่นนี้”

“การเปลี่ยนแปลงนี้ยากเพียงใด”

หากคุณเริ่มโกรธและหงุดหงิด แสดงว่าคุณเป็นนักพัฒนาซอฟต์แวร์ การประมาณค่า เจ็บปวด โดยเฉพาะอย่างยิ่งเมื่อคนที่ขอให้คุณประเมินงาน (เรียกพวกเขาว่า 'บ๊อบ') แค่มีความคิดคร่าวๆ ว่าพวกเขาขออะไร ความเจ็บปวดมากมายนี้เกิดจากความแตกต่างในสิ่งที่บ๊อบต้องการและสิ่งที่คุณคิดว่าบ๊อบต้องการ

การประมาณการไม่ใช่เป้าหมาย

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

เป็นเครื่องมือสื่อสาร

สินค้าที่จัดส่งมีสิ่งที่ขึ้นอยู่กับมัน อาจเป็นการตลาด การประชาสัมพันธ์ การวิเคราะห์ธุรกิจ การวางแผนผลิตภัณฑ์ในอนาคต หรือเรื่องอื่นๆ ขึ้นอยู่กับว่าบริษัทมีขนาดใหญ่เพียงใด ซึ่งหมายความว่าคำตอบที่ Bob กำลังมองหาคือ "ฉันจะเริ่มสมมติว่าสิ่งนี้จะเสร็จสิ้นได้เมื่อใด เพื่อที่ฉันจะได้เริ่มวางแผนสิ่งที่ขึ้นอยู่กับสิ่งนั้น"

ฉันกำลังตอบ "นี่ ควร ทำได้โดย…” แต่บ๊อบกำลังมองหา “สิ่งนี้ จะ ทำได้โดย…”.

David Bryant Copeland มีหนังสือยอดเยี่ยม The Senior Software Engineer ซึ่งพูดถึงเรื่องนี้ในบทแรก:

วิศวกรซอฟต์แวร์อาวุโสได้รับความไว้วางใจและคาดว่าจะทำงานที่สำคัญที่สุดและทำได้อย่างน่าเชื่อถือ วิธีที่จะบรรลุผลสำเร็จนั้นคือการมุ่งเน้นทุกสิ่งที่คุณทำเพื่อผลลัพธ์

พึงระลึกไว้เสมอว่า เป็นการดีที่สุดที่จะพบกับ Bob ตามเงื่อนไขของเขา ซึ่งหมายความว่า:

• ประมาณการควรทำที่ความมั่นใจ 90% ไม่ใช่ 50%

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

• การประมาณการควรยึดตามระยะเวลาในการจัดส่ง ไม่ใช่เวลาในการทดสอบ หรือเวลาในการปรับใช้คิว หรืออย่างอื่น

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

• ค่าประมาณที่ดีที่สุดคือ "ตอนนี้ยังตอบไม่ได้ แต่เดี๋ยวจะติดต่อกลับไป"

  ง่ายกว่ามากในการประมาณ 90% ของเวลาในการจัดส่งหากการประมาณการแบ่งออกเป็นส่วนย่อยๆ ซึ่งแต่ละส่วนจะเข้าใจง่ายกว่า หนังสือหลายเล่มพูดถึงกลวิธีในการประมาณการที่แม่นยำ แต่อยู่นอกขอบเขตของโพสต์นี้

จะเกิดอะไรขึ้นถ้าฉันบอกว่าฉันเคลื่อนที่เร็วไม่พอ

ทุกที่ที่ฉันทำงาน ฉันได้รับแจ้งว่าผู้บริหารอยากให้เราดำเนินการให้เร็วขึ้น ไม่ว่าผลิตภัณฑ์จะจัดส่งได้เร็วเพียงใด แม้ว่าคุณภาพจะลดลงโดยสิ้นเชิง แม้ว่าการประเมินจะบ้ามาก แม้ว่าคุณจะทำงาน 20 ชั่วโมงต่อวัน ฝ่ายบริหารก็ยังหวังว่าคุณจะสามารถดำเนินการได้เร็วขึ้น เป็นหน้าที่ของนักพัฒนาซอฟต์แวร์ที่จะเห็นว่าเป็นเพียงความปรารถนาและทำหน้าที่ของพวกเขาในการก้าวให้เร็วแต่สามารถรักษาได้ คาดการณ์ได้ ให้ผลลัพธ์ และรักษาระดับคุณภาพไว้สูง

แล้วเมื่อฉัน เกินค่าประมาณของฉันเป็นจำนวนที่น่าขัน และดูเหมือนว่าค่าประมาณของฉันจะเบาบางอย่างไม่น่าเชื่อ

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

หากคุณกำหนดเป้าหมายกรณี 50% ภาวะแทรกซ้อนที่ไม่คาดคิดอาจทำลายตารางผลิตภัณฑ์ทั้งหมด คุณจะทำอย่างนั้นประมาณครึ่งเวลา! หากคุณกำหนดเป้าหมายกรณี 90% แม้ว่าสิ่งต่างๆ จะไม่ดี กำหนดการที่เหลือสามารถทำงานตามที่ตั้งใจไว้ สินค้าจัดส่งตรงเวลา ทุกคนมีความสุข คุณได้รับเงินเพิ่มและโปรโมชัน และรางวัลที่ดีที่สุด:คุณจะได้รับค่าประมาณมากขึ้น!