จะตอบกลับอย่างไรเมื่อมีการขอประมาณการ

ในฐานะโปรแกรมเมอร์เราถูกถามอย่างต่อเนื่องว่า 'ใช้เวลานานเท่าไหร่'?

และคุณก็รู้ว่าสถานการณ์นั้นเป็นเช่นนี้เสมอ:

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

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

เป็นผลให้ฉันมักจะให้การประมาณการที่ฉันรู้ในภายหลังว่าฉันไม่สามารถปฏิบัติตาม มันเกิดขึ้นนับครั้งไม่ถ้วนและฉันมักจะสัญญาว่าจะไม่เกิดขึ้นอีก แต่มันก็เป็นเช่นนั้น

กระบวนการส่วนตัวของคุณในการตัดสินใจและจัดทำประมาณการคืออะไร? เทคนิคใดที่คุณคิดว่ามีประโยชน์

จากThe Pragmatic Programmer: จาก Journeyman ถึง Master :

จะพูดอะไรเมื่อถูกขอให้ประมาณ

คุณพูดว่า "ฉันจะกลับไปหาคุณ"

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

ในส่วนผู้เขียนแนะนำกระบวนการต่อไปนี้:

• กำหนดความแม่นยำที่คุณต้องการ ขึ้นอยู่กับระยะเวลาที่คุณสามารถอ้างอิงประมาณการในความแม่นยำที่แตกต่างกัน การพูดว่า "5 ถึง 6 เดือน" นั้นแตกต่างจากคำว่า "150 วัน" หากคุณแอบเข้าไปสักเล็กน้อยในเดือนที่ 7 คุณก็ยังค่อนข้างแม่นยำ แต่ถ้าคุณแอบเข้าไปในวันที่ 180 หรือวันที่ 210 ไม่มากนัก
• ตรวจสอบให้แน่ใจว่าคุณเข้าใจสิ่งที่ถูกถาม กำหนดขอบเขตของปัญหา
• สร้างแบบจำลองระบบ แบบจำลองอาจเป็นแบบจำลองทางจิตไดอะแกรมหรือบันทึกข้อมูลที่มีอยู่ สลายโมเดลนี้และสร้างการประเมินจากส่วนประกอบ กำหนดค่าและช่วงข้อผิดพลาด (+/-) ให้กับแต่ละค่า
• คำนวณค่าประมาณตามโมเดลของคุณ
• ติดตามประมาณการของคุณ บันทึกข้อมูลเกี่ยวกับปัญหาที่คุณประเมินการประมาณของคุณและค่าจริง
• สิ่งอื่น ๆ ที่จะรวมในการประเมินของคุณคือการพัฒนาและจัดทำเอกสารข้อกำหนดหรือการเปลี่ยนแปลงข้อกำหนดข้อกำหนดการสร้างหรือปรับปรุงเอกสารและข้อกำหนดการออกแบบการทดสอบ (หน่วยการรวมและการยอมรับ) การสร้างหรืออัปเดตคู่มือผู้ใช้หรือ README หากมีคนทำงานร่วมกัน 2 คนขึ้นไปจะมีค่าใช้จ่ายในการติดต่อสื่อสาร (การโทรศัพท์อีเมลการประชุม) และการรวมซอร์สโค้ด หากเป็นภารกิจที่ยาวนานให้พิจารณางานต่าง ๆ เช่นงานอื่นเวลาหยุดงาน (วันหยุดพักผ่อนวันหยุดเวลาป่วย) งานประชุมและงานอื่น ๆ เมื่อเลือกวันส่งมอบ

การประเมินซอฟต์แวร์เป็นงานที่ยากที่สุดในวิศวกรรมซอฟต์แวร์เพียงไม่กี่วินาที

มีกลยุทธ์มากมายสำหรับการสร้างพวกเขาทั้งหมดขึ้นอยู่กับการรับความต้องการที่ดีก่อน แต่เมื่อหลังของคุณพิงกำแพงและพวกเขาปฏิเสธที่จะให้รายละเอียดที่ดีกว่าแก่คุณปลอมมัน:

1. ดูความต้องการที่คุณมี
2. ตั้งสมมติฐานเพื่อเติมลงในช่องว่างตามการคาดเดาที่ดีที่สุดของคุณในสิ่งที่พวกเขาต้องการ
3. เขียนสมมติฐานทั้งหมดของคุณ
4. ทำให้พวกเขานั่งอ่านและยอมรับสมมติฐานของคุณ (หรือหากคุณโชคดีให้พวกเขามอบและให้ความต้องการที่แท้จริงแก่คุณ)
5. ตอนนี้คุณมีข้อกำหนดโดยละเอียดที่คุณสามารถประเมินได้

มันเหมือนแม่ของฉันเคยขู่ตอนที่ฉันยังเป็นเด็ก "รีบหยิบเสื้อผ้าออกมาหรือจะเลือกพวกเขา!

ฉันพัฒนาคนที่มุ่งมั่นที่จะต้องการการประมาณการที่แม่นยำ สิ่งที่เราตัดสินซึ่งทำได้ดีมากคือ:

• ฉันถูกเรียกเก็บเงินตลอดเวลาที่ฉันใช้ประเมิน ประมาณ 20-25% ของสิ่งที่ฉันเรียกเก็บเงิน
• ฉันตรวจสอบงานอย่างละเอียดมาก ๆ ไม่มีการยิงจากสะโพก ฉันเข้าไปในโค้ดแล้วหาว่าต้องการเปลี่ยนบรรทัดอะไรส่วนอื่น ๆ ของโปรแกรมที่จะส่งผลกระทบต่อการทดสอบที่ฉันต้องทำเพื่อให้แน่ใจว่าสิ่งต่างๆยังคงทำงานอยู่ ฉันประเมินแต่ละชิ้นเป็นหน่วย. 1 ชั่วโมง (6 นาที)
• ฉันส่งประมาณการของเขาสำหรับแต่ละงานพร้อมกับรายละเอียด

20-25% ของการเรียกเก็บเงินฟังดูเยอะมาก

แต่เขาจะขอให้ฉันเปลี่ยนแปลง XYZ โดยคิดว่าใช้เวลาประมาณ 2 ชั่วโมง ในการประมาณรายละเอียด 1 ชั่วโมงฉันจะตรวจสอบว่าใช้เวลา 8.5 ชั่วโมง ดังนั้นเขาจะตัดสินใจว่ามันคุ้มค่ากับการจ่าย 8.5 ชั่วโมงหรือไม่ ถ้าไม่เช่นนั้นเขาจะประหยัดได้ 7.5 ชั่วโมงในสิ่งที่จะทำให้เขาต้องเสียถ้าฉันทำโดยไม่ต้องมีการประมาณการ

และถ้าเขาไม่ต้องการที่จะลงทุน 8.5 ชั่วโมงการทำงานรายละเอียดที่ฉันได้สำหรับการประมาณการเป็นงานที่ฉันได้มีการทำต่อไป

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

เขาเป็นคนนิกเกิลและหรี่ไหม? ไม่ฉันดูที่การปล่อยให้เขาใช้เงินของเขาซึ่งเขาเห็นประโยชน์มากที่สุด และฉันดีใจที่ได้รับประสบการณ์ในการประเมินซึ่งฉันมักจะแย่ที่

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

พวกเขาเกือบจะได้รับจุด

ขึ้นอยู่กับการประมาณการ

สำหรับการประมาณการเบื้องต้นระดับสูงสำหรับกรณีธุรกิจดังนั้นสิ่งสำคัญคือ:

1. ความเร็ว. วิธีใดก็ตามที่คุณใช้จะต้องรวดเร็ว ประเด็นทั้งหมดคือผู้มีส่วนได้ส่วนเสียไม่แน่ใจว่ามันคุ้มค่าที่จะทำโครงการหรือไม่ซึ่งเป็นเหตุผลที่พวกเขาต้องการตัวเลขสำหรับกรณีธุรกิจ หากกรณีธุรกิจมั่นคงพวกเขาไม่ต้องการการประมาณของคุณ ส่วนใหญ่ของโครงการเหล่านี้จะไม่ไปข้างหน้าดังนั้นจึงเป็นสิ่งสำคัญที่จะไม่ใช้ความพยายามมากเกินไปในการประเมิน
2. ให้ช่วง ทำให้มันกว้าง คุณไม่มีเวลาที่จะวิเคราะห์ความต้องการฝึกอบรมเชิงปฏิบัติการกับผู้มีส่วนได้ส่วนเสียตรวจสอบสมมติฐาน หลากหลายบอกผู้รับประมาณการ "โครงการซอฟต์แวร์มีความซับซ้อนและมีความเสี่ยงตามธรรมชาติ - หากคุณต้องการประมาณการที่เหมาะสมคุณต้องให้รายละเอียดและเวลามากขึ้น" ปัญหาของการให้หมายเลขเดียวหรือช่วงแคบ ๆ คือมันทำให้คุณเข้ามุมโดยตั้งค่าความคาดหวังก่อนที่จะทำการวิเคราะห์จริง

ฉันพบว่าเทคนิคที่ดีที่สุดในการเลือกโครงการเปรียบเทียบที่ "รู้สึก" เหมือนกัน "ความรู้สึก" เป็นอัตวิสัยอย่างสมบูรณ์ - แต่ด้วยการประมาณแบบนี้ประสบการณ์ของฉันบอกฉันว่าคุณจะไม่พบการวัดที่มีวัตถุประสงค์ จากนั้นให้บริการที่หลากหลาย ฉันได้อ่านหนังสือบางเล่มที่บอกว่าช่วง -50% ถึง + 100% นั้นดี แต่ขึ้นอยู่กับหลายปัจจัย

สำหรับการประมาณการในระดับต่ำอย่างละเอียด:

1. คุณต้องมีพื้นฐาน หากพื้นฐานไม่มั่นคงการประมาณค่าก็ไร้ความหมาย
2. ล่างสุดดีที่สุด รับรายละเอียดการทำงานแยกย่อยประเมินแต่ละส่วนประกอบจากนั้นหมุนเป็นจำนวนมากขึ้น ฉันคิดว่าการวางแผนโป๊กเกอร์เป็นเทคนิคที่ยอดเยี่ยมที่นี่
3. เอกสารที่อาจเกิดขึ้น ทำให้ชัดเจนเมื่อมีการเพิ่มกรณีฉุกเฉิน (ถ้ามี) มีการเพิ่มในรายการโฆษณาแต่ละรายการหรือไม่ หรือประมาณทั้งหมด? หรือเพื่อความเสี่ยงที่เฉพาะเจาะจง? หรือไม่มีเลย?
4. ระบุสมมติฐานของคุณ ตรวจสอบให้มากที่สุดเท่าที่เป็นไปได้ในกรอบเวลา
5. ระบุอย่างชัดเจนว่ามีอะไรรวมอยู่และไม่รวมอยู่ในค่าประมาณ ตัวอย่างเช่นมีการตรวจสอบรวมหรือไม่ มีความล่าช้าทางเทคนิคหรือไม่

คำแนะนำบางอย่างจากด้านมืดจากผู้เรียนรู้วิธีที่ยาก

ข้อกำหนดไม่ชัดเจน ไม่มีใครทำการวิเคราะห์เชิงลึกเกี่ยวกับผลกระทบทั้งหมด

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

คุณสมบัติใหม่นี้อาจทำลายสมมติฐานบางอย่างที่คุณทำในรหัสของคุณและคุณเริ่มคิดในทันทีในทุกสิ่งที่คุณอาจต้องปรับเปลี่ยน

นี่เป็นความรับผิดชอบของคุณที่จะคำนึงถึงหากคุณคาดหวังว่าคนอื่นจะมีความเชี่ยวชาญเกี่ยวกับเรื่องนี้

คุณมีสิ่งอื่น ๆ ที่ต้องทำจากการมอบหมายที่ผ่านมาและคุณจะต้องมาพร้อมกับประมาณการที่คำนึงถึงงานอื่นที่เข้ามา

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

คำนิยาม 'เสร็จสิ้น' อาจไม่ชัดเจน: เมื่อใดจะเสร็จสิ้น 'เสร็จสิ้น' ในขณะที่เพิ่งเสร็จสิ้นการเข้ารหัสหรือ 'เสร็จสิ้น' ในขณะที่ "ผู้ใช้ใช้งาน"

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

ไม่ว่าคุณจะใส่ใจในเรื่องเหล่านี้อย่างไรบางครั้ง "ความภาคภูมิใจของโปรแกรมเมอร์" ทำให้คุณยอมรับ / ยอมรับเวลาที่สั้นกว่าที่คุณคิดเอาไว้ พิเศษเมื่อคุณรู้สึกถึงความกดดันของกำหนดเวลาและความคาดหวังด้านการจัดการ

อย่าทำอย่างนี้! คุณฟังดูเหมือนเป็นคนทำงานหนักที่มีแรงจูงใจในตัวเองและอาจเป็นคนที่ยอมแพ้ง่าย ๆ

ปัญหาคือนี่: สมมติว่าคุณและโจทำการประมาณเวลาสำหรับงานเดียวกัน (แต่ระหว่างพนักงานแยกกันสองคนโดยไม่ทราบการประมาณการทั้งสองในคราวเดียว) คุณประมาณการอย่างกล้าหาญ, "หนึ่งสัปดาห์" ไม่เป็นไรคุณคิดว่าคุณจะทำงานมากกว่า 100 ชั่วโมงต่อสัปดาห์ไม่ได้รับค่าล่วงเวลา ตอนนี้คุณมาสายสามวันแล้ว

ในขณะเดียวกันโจประมาณ 5 เดือน คุณคิดว่ามันไร้สาระคุณคิดว่าคุณสามารถดึงมันออกมาได้ภายในหนึ่งสัปดาห์ โจทำงานเท่าไหร่ 10 ชั่วโมงต่อสัปดาห์? ... ยกเว้นเขาจะเสร็จตรงเวลาใน 5 เดือน

เดาผู้ที่ถูกมองว่าเป็นคนโง่? ใช่แล้วคุณล่ะ Joe ดูเหมือนว่าเป็นคนทำงานที่ยอดเยี่ยม แต่ตอนนี้คุณดูเหมือนไม่น่าเชื่อถือ ไม่สำคัญว่าคุณจะได้รับผลลัพธ์ที่ดียิ่งขึ้นในเวลาประมาณ 7% ของเวลาที่โจเอาไป สิ่งที่สำคัญคือคุณต้องหยุดงาน 3 วันจากการประมาณหนึ่งสัปดาห์

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

"สองสัปดาห์!"

อย่างจริงจัง. การประเมินครั้งแรกของฉันอยู่เสมอสองสัปดาห์ เพราะฉันมีบล็อกจิตแปลก ๆ บางอย่างที่ทำให้ฉันคิดว่าทุกอย่างดูเหมือนจะเป็นสองสัปดาห์

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

ผู้จัดการที่ดีทุกคนที่ฉันเรียนรู้ที่จะจำ "สองสัปดาห์!" เป็นคำตอบที่ต้องใช้วาจาแมงดา - ตบเบา ๆ ในการตอบสนอง

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

ฉันไม่ได้ลองด้วยตัวเอง แต่อยากจะดูว่าการประมาณการของฉันถูกต้องแค่ไหน

ขึ้นอยู่กับองค์กรและวิธีใช้ประมาณการ

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

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

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

การประเมินเพื่ออะไร งานขนาดเล็กหรือโซลูชั่นที่สมบูรณ์

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

งานเล็ก - การวางแผนโปกเกอร์ฉันพบว่าทำงานได้ดีมาก (ไม่สมบูรณ์แบบงาน 1PT บางงานใช้เวลานานกว่านี้และงาน 5pt ใช้เวลาไม่กี่นาที

นำเสนอช่วงตามสิ่งที่คุณรู้วันนี้ ใช้Cone of Uncertaintyเพื่อกำหนดช่วงรอบการเดาเริ่มต้นของคุณ

ทุกสัปดาห์คำนวณว่าเหลือเท่าไรให้ทำใหม่ประเมินตามสิ่งที่คุณรู้ เมื่อคุณมีขนาดตัวอย่างเพียงพอที่คุณจะได้รับงานมากแค่ไหนในแต่ละสัปดาห์ให้ระบุช่วงความมั่นใจ 90% สำหรับสิ่งที่เหลือเพื่อให้ช่วงวันที่แคบลง (โดยปกติ) เมื่อโครงการดำเนินไปและปริมาณงานที่เหลือ (หวังว่า ) หดตัว

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

พวกเขา: ราคาเท่าไหร่?

ฉัน:มันขึ้นอยู่กับสิ่งที่คุณต้องการให้ฉันทำ โดยทั่วไปฉันเริ่มโครงการประเภทนี้ประมาณ $ X

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

เมื่อเราตัดสินใจแบ่งปันประสบการณ์และความรู้เกี่ยวกับกระบวนการประเมินซอฟต์แวร์และกำหนดการประมาณค่าสี่ประเภท :

• รูปเบสบอล
• ประมาณการบริการ
• การประมาณคุณสมบัติ
• การประเมินส่วนประกอบ

แน่นอนประเภทเหล่านั้นแตกต่างกัน Ballpark คือสิ่งที่มักจะเรียกว่า“ guesstimate” ดังนั้นจึงเป็นตัวเลขหรือช่วงโดยประมาณที่ให้ความคิดทั่วไปเกี่ยวกับค่าใช้จ่ายและอาจช่วยให้ผู้มีโอกาสตัดสินใจได้ว่าพวกเขาต้องการอภิปรายเพิ่มเติมหรือไม่

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

ทุกคนควรทราบถึงความเสี่ยงที่มาพร้อมกับการประเมินการพัฒนาซอฟต์แวร์: การประเมินค่าต่ำไป, การประเมินค่าสูงไป, สถานการณ์ความล้มเหลวของมหากาพย์ทั้งหมดเป็นต้น

คุณสามารถอ่านเพิ่มเติมได้ที่บล็อกของเรา!

http://blog.lemberg.co.uk/project-management/software-estimation-process/

หวังว่าข้อมูลนี้จะช่วยคุณได้!

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

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

คำแนะนำบางอย่างอยู่บนประสบการณ์ของฉันประมาณ 10 ปี:

• ระบุช่วงเสมอ (เช่นขอบเขตล่างและบน) สิ่งนี้จะสื่อสารระดับความไม่แน่นอนของคุณ
• หากคุณมีความไม่แน่นอนมากขอให้รอการเลื่อน (เช่น 1 วันเพื่อทำการวิเคราะห์แล้วให้ช่วงที่เข้มงวดมากขึ้น)
• หากงานมันใหญ่เกินไปให้แบ่งและกำหนดช่วงสำหรับแต่ละชิ้น

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

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

หากคุณทำหลายโครงการสำหรับเจ้านายหรือลูกค้าเดียวกันคุณสามารถลองประเมินความซับซ้อนในวงกว้างแทนที่จะเป็นสัปดาห์หรือเป็นเดือนซึ่งอาจเป็นขนาดเสื้อยืด ระบุโครงการที่ผ่านมาไม่กี่และกำหนดขนาด S, M, L, XL

แล้วถามตัวเองว่าโครงการใดที่คล้ายกับขอบเขต และแทนที่จะตอบด้วย "2 เดือน" คุณสามารถตอบด้วย "เสียงเหมือน L to me" (หรือสิ่งที่การสอบเทียบสำหรับโครงการของคุณกลายเป็น)

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

จากนั้นเมื่อความต้องการเปลี่ยนแปลงคุณสามารถพูดว่า "การเปลี่ยนแปลงนั้นทำให้ฟังดูเหมือน XL"

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