ฉันมีช่วงเวลาที่ยากลำบากกับฝ่ายบริหารที่ขอประมาณการงานเขียนโปรแกรมที่ใช้การควบคุมของบุคคลที่สามซึ่งฉันไม่มีประสบการณ์มาก่อน
ฉันเข้าใจแน่นอนว่าทำไมพวกเขาถึงต้องการค่าประมาณ แต่ฉันรู้สึกว่าการประมาณใด ๆ ที่ฉันให้อาจจะเป็น a) สั้นเกินไปและทำให้ฉันดูไม่ดีหรือ b) ยาวเกินไปและทำให้ฉันดูไม่ดี
ฉันจะให้ฝ่ายบริหารประมาณหรือตอบกลับอย่างไรเพื่อให้พวกเขาออกจากหลังเพื่อที่ฉันจะได้ทำงานต่อไป!
คำตอบ:
คำตอบที่ดีที่สุดที่คุณสามารถให้ได้คือขอเวลาในการเคาะต้นแบบอย่างรวดเร็วเพื่อให้คุณสามารถประมาณการได้แม่นยำยิ่งขึ้น โดยไม่ต้องบางประสบการณ์กับเครื่องมือหรือปัญหาประมาณการใด ๆ ที่คุณให้ความหมายเป็นหลัก
นอกจากนี้ไม่ค่อยมีปัญหากับการประมาณการที่ยาวเกินไป เกิดปัญหาที่ไม่คาดคิดการเปลี่ยนแปลงลำดับความสำคัญและข้อกำหนดจะ "อัปเดต" แม้ว่าคุณจะไม่ได้ใช้งานตลอดเวลาที่ขอคุณก็จะมีเวลาทดสอบมากขึ้นหรือจะปล่อย "ก่อนกำหนด" ก็ได้
ฉันมักจะมองโลกในแง่ดีเกินไปในการประมาณการของฉันและมันอาจสร้างความเครียดให้กับชีวิตของคุณได้มากโดยเฉพาะอย่างยิ่งเมื่อคุณเป็นโปรแกรมเมอร์อายุน้อยที่ไม่มีประสบการณ์และความมั่นใจในตนเองที่จะบอกความจริงที่ไม่สบายใจแก่ผู้บังคับบัญชา
ฉันจะแจ้งให้คุณทราบเป็นความลับ แม้ว่าคุณจะเป็นผู้เชี่ยวชาญด้านเทคโนโลยีดังกล่าว แต่การประมาณการของคุณก็มีแนวโน้มที่จะไม่ถูกต้องอย่างมาก มันเป็นธรรมชาติของสัตว์ร้ายเมื่อทำอะไรบางอย่างที่เป็นงานวิจัยและพัฒนาโดยเนื้อแท้ น่าเสียดายที่ฝ่ายบริหารมักพยายามใช้รูปแบบการผลิตและต้องการการประมาณการที่ถูกต้อง เพื่อแสดงประเด็นของฉันให้พิจารณาความยากลำบากในการประมาณความพยายามสองอย่างต่อไปนี้อย่างถูกต้อง:
A) ผลิตร่ม 11K อีกคันที่เหมือนกับ 2K ที่คุณปั่นเมื่อเดือนที่แล้ว B) ออกแบบร่มชนิดใหม่และสร้างร่มแบบแรก
การพัฒนาซอฟต์แวร์คือ B แต่พวกเขากำลังขอค่าประมาณโดยสมมติว่า A
สิ่งที่ดีที่สุดที่คุณทำได้คือแบ่งงานออกเป็นชิ้นเล็ก ๆ เท่าที่จะทำได้ (ไม่เกิน 1/2 วันต่อวัน) จากนั้นเพิ่มจำนวนสุดท้ายที่คุณคิดขึ้นเป็นสามเท่า (วิธี Spolsky)
อีกวิธีหนึ่งคือ Steve McConnell มีหนังสือทั้งเล่ม (หลายเล่ม) เกี่ยวกับวิศวกรรมซอฟต์แวร์ด้านนี้ http://www.amazon.com/Software-Estimation-Demystifying-Practices-Microsoft/dp/0735605351
สตีฟแมคคอนเนลล์ (และอื่น ๆ ) พูดคุยเกี่ยวกับเกี่ยวกับกรวยของความไม่แน่นอน โดยทั่วไปคุณจะให้ค่าประมาณที่มีลักษณะดังนี้:
การทำงานจะใช้เวลาระหว่าง 3 ถึง 9 สัปดาห์โดยมีโอกาสมากที่สุด 4 สัปดาห์
เมื่อโครงการดำเนินไปคุณสามารถปรับแต่งประมาณการของคุณได้ ในขณะที่คุณทำงานมากขึ้นและเข้าใจถึงความพยายามที่จำเป็นดีขึ้นคุณสามารถปรับแต่งค่าประมาณของคุณให้แม่นยำยิ่งขึ้นได้
มันได้ผลสำหรับฉัน แต่อาจต้องใช้ความพยายามบ้างเพื่อให้ผู้มีส่วนได้ส่วนเสียอื่น ๆ ในโครงการเข้าใจกระบวนการนี้
คุณอาจต้องการพิจารณาให้ทั้งค่าประมาณและระดับความเชื่อมั่นเช่น 50/50 ซึ่งจะใช้เวลา 3-6 เดือนหรือ 6-9 เดือนหรือโอกาส 75% ที่จะทำได้ใน 9 เดือนและ 90% ที่คุณจะได้รับ ทำในหนึ่งปี
สิ่งที่คุณควรพิจารณาอีกประการหนึ่งคือการใช้แนวทาง " ภูมิปัญญาของฝูงชน " ลองถามผู้คน 25-50 คนว่าพวกเขาคิดว่าจะใช้เวลานานแค่ไหนและเฉลี่ยประมาณ ฉันคิดว่าการวางแผนโป๊กเกอร์ของ Mike Cohn นั้นคล้ายกับสิ่งนี้มากแม้ว่าจะยากที่จะวางแผนกับนักพัฒนาเพียงคนเดียว
แบ่งประมาณการของคุณออกเป็น:
เสนอให้ปรับประมาณการและเหตุการณ์สำคัญระหว่างทาง สิ่งที่ไม่รู้จักที่ไม่รู้จักจะกลายเป็นสิ่งที่ไม่รู้จักสิ่งที่ไม่รู้จักที่รู้จักควรกลายเป็นที่รู้จักเมื่อคุณได้รับประสบการณ์และค่าประมาณของคุณที่รู้จักที่รู้จักสามารถปรับเปลี่ยนได้ตามความคืบหน้าจนถึงปัจจุบัน คุณสามารถประเมินเบื้องต้นจากนั้นประเมินใหม่เมื่อคุณทำได้ประมาณ 25% จากนั้นอีกครั้งที่ 50% จากนั้นอีกครั้งที่ 85% ในแต่ละขั้นตอนการประมาณการของคุณควรเริ่มบรรจบกันตามเวลาจริงที่งานจะใช้
ฉันใช้ระบบการติดฉลากที่ชัดเจนสำหรับการประมาณการของฉัน ... คลาส A คลาส B และคลาส C
ค่าประมาณคลาส C เป็นค่าแรกที่ได้รับ มีการระบุอย่างเปิดเผยว่าบวกหรือลบ 50% เนื่องจากไม่ทราบ ถ้าพวกเขาต้องการให้ฉันเรียนคลาส B ต่อไปฉันก็ต้องใช้เงินเพื่อค้นคว้า
คลาส B คือบวกหรือลบ 25% บางครั้งสิ่งนี้ดีพอและพวกเขาก็ให้เงินฉันสร้าง ถ้าไม่ได้เงินน้อยลงและการวิจัยมากขึ้น
คลาส A คือบวกหรือลบ 10% สุดท้ายแล้วไปหรือไม่ไป หากเป็นการเดินทางและฉันหลงไปไกลจากที่คาดไว้ฉันมักจะสารภาพและเร็วเกินไป
ฉันคิดว่าถ้าคุณลบวลี "ที่ใช้การควบคุมของบุคคลที่สามที่ฉันไม่มีประสบการณ์มาก่อน" คุณอาจมีคำอธิบายที่ดีกว่าเกี่ยวกับปัญหาใหญ่ของคุณ
หาก "Agile" สอนอะไรเราถ้าฝ่ายบริหารคาดหวังให้คุณประเมินโครงการในลักษณะนั้นอย่างต่อเนื่องและคุณจะ "ดูไม่ดี" หากคุณบอกว่าไม่สามารถจัดหาได้เนื่องจากคุณไม่มี ข้อมูลเพียงพอคุณอยู่บนทางหลวงไป FAIL
ปัญหาที่ใหญ่ที่สุดคือปัญหาที่คุณไม่สามารถควบคุมได้และคุณยังไม่ได้ระบุ บ่อยแค่ไหนที่คุณมองย้อนกลับไปและพูดกับตัวเองว่า "อืมฉันกดค่าประมาณของฉันบนปุ่ม - ในการลองครั้งที่สามหลังจากที่ฉันพบว่า ... และฉันต้องการเวอร์ชัน ... และ dba จะเปิดอยู่ พักร้อนเป็นเวลาหนึ่งสัปดาห์และผู้จัดการโครงการต้องการให้ฉัน ... เป็นเวลาหนึ่งสัปดาห์และภรรยาของฉันก็ท้องและ ... ".
ฉันพยายามอย่างแท้จริงที่จะพูดว่า "ฉันสามารถระบุปัจจัยเสี่ยงที่สำคัญและจัดทำรายการตรวจสอบสิ่งที่ส่งมอบเพื่อทดสอบใน xx วันเมื่อถึงตอนนั้นฉันจะให้การประมาณเพิ่มเติมอีกครั้ง"
และคงจะดีไม่น้อยหากคุณสามารถแนะนำว่าพวกเขาควร "โปรดยืนยันว่าฉันจะไม่พยายามให้การประมาณประเภทนั้นที่น่าเชื่อถือแก่คุณอีกในอนาคตยิงฉันถ้าฉันพยายาม"
(คุยโว แต่เพียงเล็กน้อย)
อย่าแม้แต่พยายามประมาณ ไม่มีวิธีใดที่ค่าประมาณของคุณจะถูกต้อง หลังจากทั้งหมดเป็นเพียงการประมาณ
ฉันอยากจะแนะนำให้คุณแบ่งคุณลักษณะออกเป็นชิ้นเล็ก ๆ แทน (ไม่เกิน 1-2 วัน) และพยายามส่งมอบชิ้นส่วนเหล่านี้เป็นรหัสที่ใช้งานได้สมบูรณ์ทดสอบได้และมีคุณค่าให้กับลูกค้า / ผู้จัดการ ด้วยวิธีนี้เขาจะเห็นความก้าวหน้าของคุณเองในแต่ละวัน นอกจากนี้ยังหมายความว่าในความเป็นจริงเขาสามารถตัดสินใจที่จะหยุดการพัฒนาได้เมื่อพอใจและพิจารณาว่ามันเสร็จสมบูรณ์แม้ว่ามันอาจจะไม่บรรลุเป้าหมายทั้งหมดก็ตาม
ดูแนวทางปฏิบัติที่คล่องตัว "การวางแผนการวางจำหน่าย" และ "การวางแผนการทำซ้ำ" สำหรับข้อมูลเชิงลึกเพิ่มเติมเกี่ยวกับแนวทางนี้
โปรดทราบว่าหากคุณขอเวลาโดยประมาณมากขึ้น แต่ทำให้ทันเวลามันจะดูดีกว่าการประมาณและต้องขอขยายเวลา
ฉันจะพยายามล้อเลียนต้นแบบเพื่อให้คุณมีความคิดที่ดีขึ้นเกี่ยวกับเวลาที่ต้องใช้ ซื่อสัตย์กับผู้บริหารของคุณเพื่อให้พวกเขาสามารถจัดงบประมาณสำหรับความล่าช้าที่ไม่คาดคิดในช่วงการเรียนรู้
แก้ไข:คุณอาจดูว่าคุณจะได้รับกำหนดเวลา "ซ้ำ" เพิ่มเติมหรือไม่ ใน "การคิดและการเรียนรู้เชิงปฏิบัติ" แอนดี้ฮันท์เป็นจุดที่ดีที่ผู้คนเป็นผู้เชี่ยวชาญโครงการที่อยู่ใกล้กับจุดสิ้นสุดของโครงการและมีความรู้น้อยที่สุดในช่วงเริ่มต้น การออกแบบและการประมาณเวลาทั้งหมดของคุณไม่สมเหตุสมผลในตอนเริ่มต้นเมื่อทุกคนมีความรู้น้อยที่สุดเกี่ยวกับโครงการ หากคุณ "ย้ำ" กำหนดเวลาและแก้ปัญหาเป็นชิ้น ๆ คุณจะประสบความสำเร็จมากขึ้น
การประมาณค่าที่แม่นยำจำนวนมากคือการรู้ด้วยตนเอง หากคุณเขียนโค้ดเป็นจำนวนมากหากคุณต้องเรียนรู้ API จำนวนมากคุณจะเริ่มรู้สึกถึงคำถามเช่น:
ตลอดเวลานั้นคุณควรเข้าใจสิ่งต่างๆเช่น:
จากสิ่งเหล่านี้ทั้งหมดคุณจะสามารถพัฒนาความรู้สึกได้ว่าบางสิ่งต้องใช้เวลานานเพียงใดและสามารถระบุสมมติฐานของคุณได้ ("สมมติว่า API มีเหตุผล ... ") แม้จะเผชิญกับข้อมูลที่ไม่สมบูรณ์อย่างน่าอนาถ
ประมาณระยะเวลาที่คุณต้องใช้เพื่อเรียนรู้มากพอที่จะประมาณได้ดีขึ้นตัวอย่างเช่น "ฉันไม่รู้: ฉันไม่เคยทำงานกับสิ่งนี้มาก่อนฉันอาจต้องใส่ค่าประมาณของคุณที่นี่เพื่อหาว่า คุณจำเป็นต้องเรียนรู้เกี่ยวกับเรื่องนี้ซึ่งฉันต้องรู้ก่อนที่จะสามารถให้การประมาณที่ดีสำหรับการใช้สิ่งนี้เพื่อจบโครงการของคุณ "
คุณเพียงแค่เดาตัวเลขภายนอกและทำการประเมินทันทีแจ้งให้พวกเขาทราบว่าข้อมูลในอนาคตอาจส่งผลต่อการประมาณการของคุณ แต่คุณจะอัปเดตให้เป็นปัจจุบัน
ในขณะที่คุณประเมินโปรดแจ้งให้พวกเขาทราบไม่ว่าจะผ่านเอกสารที่เผยแพร่ทางเว็บหรือการอัปเดตรายสัปดาห์ แต่จะรวม "วันที่สิ้นสุดโดยประมาณ" ที่อัปเดตและเหตุผล (ถ้ามี) สำหรับส่วนขยายไว้เสมอ
ผู้จัดการส่วนใหญ่ควรเข้าใจว่า - โดยการขอวันที่สิ้นสุดพวกเขากำลังพูดว่า "ให้ความคิดกับเราว่าเราจะวางแผนกำหนดการของเราได้อย่างไร" และ "อย่าใช้เวลาตลอดไป"
หากคุณจบลงด้วยการขยายเวลามากกว่าหนึ่งครั้งหรือสองครั้งให้ประเมินตารางเวลาทั้งหมดของคุณอีกครั้งโดยอาศัยความรู้ใหม่ของคุณที่คุณคาดเดาได้
เวลาเขียนโปรแกรมฉันมักจะเอาสิ่งที่คิดว่าจะเอามาคูณด้วย 3 เพื่อหาค่าประมาณ ถ้าฉันคิดว่าฉันสามารถทำงานได้ใน 1 สัปดาห์ฉันบอกลูกค้าว่าจะใช้เวลา 3 - ถ้าฉันคิดว่าจะใช้เวลา 3 สัปดาห์ฉันบอกลูกค้า 9 สัปดาห์
การทำเช่นนี้ทำให้ฉันตั้งตัวเองเป็น "ภายใต้คำมั่นสัญญามากกว่าส่งมอบ" - ถ้าคุณทำได้สำเร็จชีวิตของคุณจะดีขึ้นมากและลูกค้าของคุณจะมีความสุขอย่างมาก
ในกรณีของคุณคุณจะต้องเข้าใจอย่างน้อยว่าคุณกำลังดำน้ำอะไรก่อนที่จะประมาณการ บางทีคุณอาจต้องระบุระยะเวลาในการประมาณการด้วยซ้ำ การคูณด้วย 3 ช่วยให้ลูกค้ามีความสุข
แบ่งมันออกเป็นสิ่งที่คุณมีประสบการณ์มาบ้าง การสับมันจะทำให้คุณมีความคิดที่ดีขึ้นเกี่ยวกับสิ่งที่คุณรู้และสิ่งที่คุณไม่รู้
เมื่อชิ้นส่วนมีขนาดเล็กพอที่จะมองว่าเป็นงานที่กำหนดไว้เพียงงานเดียวงานบางส่วนจะไม่สามารถประเมินได้ทั้งหมด สำหรับสิ่งนั้นให้ทำต้นแบบก่อนหรือปล่อยให้ตัวเองใช้เวลาพอสมควรขึ้นอยู่กับขนาดของชิ้นส่วน หากคุณพบว่าคุณมีชิ้นงานที่ใหญ่เกินคาดเดาไม่ได้ในการทำงาน 2-4 สัปดาห์ให้กลับไปสับชิ้นส่วนนั้นก่อน
ในที่สุดคุณจะได้รับโซลูชันทางเทคโนโลยีแปลก ๆ (ที่คุณคิดว่าควรใช้งานได้ แต่ไม่รู้แน่ชัด) และต้องทำงานมากมายเพื่อสำรองข้อมูลนั้นเมื่อมันใช้งานได้ จะมีการออกแบบที่ขาดหายไปเล็กน้อยซึ่งควรเลือกไลบรารีที่รู้จักกันดีหรืออัลกอริทึมที่เรียบง่ายสำหรับเวอร์ชันเริ่มต้น
หากคุณไม่สามารถแบ่งงานได้คุณควรจ้างคนที่มีประสบการณ์เพียงพอที่สามารถทำได้ (เนื่องจากการขาดประสบการณ์ของคุณจะหลอกหลอนคุณด้วยวิธีอื่นเช่นกัน) หากคุณไม่สามารถจ้างใครสักคนได้คุณควรต่อรองราคาแบบสุ่มเป็นระยะเวลานาน (6 เดือนถึง 2 ปี) และมุ่งตรงไปยังต้นแบบที่ยุ่งเหยิง (จนกว่าคุณจะสามารถให้ประสบการณ์ตัวเองมากพอที่จะรู้ว่าอะไรถูกและอะไร ไม่ถูกต้อง). แต่ถ้าคุณจบลงด้วยความล้มเหลวสิ่งสำคัญคืออย่าล้อเลียนตัวเองและคิดว่าคุณกำลังทำ "วิธี" ที่ถูกต้อง ต้นแบบถูกโยนทิ้งไป หวังว่าเมื่อการนับถอยหลังต้นแบบเสร็จสมบูรณ์คุณก็พร้อมที่จะสร้างมันขึ้นมาจริง
พอล.
ฉันจะเพิ่มสิ่งที่ RB พูดเมื่อฉันพบว่าตัวเองอยู่ในสถานการณ์เช่นนี้ฉันประมาณว่าจะต้องใช้เวลานานแค่ไหนกับเครื่องมือที่ฉันคุ้นเคยจากนั้นจึงเพิ่มเป็นสองเท่าเพื่อสร้างเส้นโค้งการเรียนรู้
ส่วนที่สำคัญมีการสื่อสารเพื่อการจัดการที่ประมาณการเป็นเดาถ้าพวกเขากดสำหรับการประมาณการที่แม่นยำมากขึ้นหรือถ้าพวกเขาพยายามที่จะ - พระเจ้ารัก - ขายคุณการ จำกัด เวลา (แน่นอนมันจะพาคุณ 2 วันในการสร้างเอ็นเตอร์ไพรส์ องค์กรคุณเป็นคนดี) ยึดติดกับปืนของคุณอย่าประนีประนอมกับการประมาณการของคุณหรือข้อเท็จจริงที่ว่ามันไม่น่าเชื่อถือ
หากการจัดการแทนที่คุณและ timebox งานเช่น "ดีก็จะต้องมีการดำเนินการใน 2 วัน" อีกครั้งปล่อยให้พวกเขารู้ว่าพวกเขาประมาณการซึ่งเป็นสิ่งน่าเชื่อถือเป็นของคุณเอง
จดทั้งหมดนี้เป็นลายลักษณ์อักษร
ฉันจัดการกับการประมาณค่าในงานของฉันค่อนข้างน้อยและมันเป็นความท้าทายที่แท้จริง ความท้าทายที่ยิ่งใหญ่ที่สุดอย่างหนึ่งของฉันคือการประมาณระยะเวลาที่นักพัฒนารายอื่นจะต้องใช้เวลาในการทำงานให้สำเร็จโดยที่ไม่รู้ว่านักพัฒนาคนนั้นจะมีทักษะมากเพียงใด
ในขณะที่คุณอาจเห็นความสำเร็จครั้งแรกด้วยวิธีการ "ภายใต้คำมั่นสัญญามากกว่าส่งมอบ" แต่คุณจะพบว่าเมื่อเวลาผ่านไปคุณจะได้รับการเสนอราคาสูงกว่าคนอื่น ๆ ที่ทำตามโรงเรียนความคิด การขาดความแม่นยำจะย้อนกลับมากัดคุณไม่ทางใดก็ทางหนึ่ง ความแม่นยำนั้นเชื่อมโยงกับประสบการณ์และการ จำกัด จำนวนสิ่งที่ไม่รู้จักด้วยเทคโนโลยีนี้
สิ่งหนึ่งที่ฉันอยากแนะนำคือควรทำความเข้าใจว่างบประมาณประเภทใดที่คุณคาดว่าจะใช้ได้ หากคุณมีงบประมาณน้อยอย่าไปคลั่งไคล้เทคโนโลยีที่ไม่คุ้นเคยและยึดติดกับสิ่งที่คุณรู้ หากงบประมาณของคุณยืดหยุ่นกว่าเล็กน้อยคุณก็สามารถทดลองได้เล็กน้อย
โปรดทราบด้วยว่าจะมีงานบางอย่างที่คุณสามารถทำได้คือ Wild Ass Guess (WAG) สำหรับสิ่งเหล่านี้คุณควรกำหนดเวลาขั้นต่ำในการประมาณของคุณและทำให้ชัดเจนว่าคุณไม่รู้ว่าค่าสูงสุดคือเท่าไร บ่อยครั้งที่การประมาณแบบนี้เป็นเหตุผลเพียงพอที่ผู้บริหารจะตัดคุณสมบัติ / ความต้องการบางอย่างออกไป
นั่นเป็นทักษะที่ขาดไม่ได้ที่ทั้งผู้จัดการโครงการและโปรแกรมเมอร์อาจมี (และแน่นอนว่าอาจเชี่ยวชาญ!) ฉันพบบทความการประเมินงานการพัฒนาซอฟต์แวร์ที่ทำได้ง่ายขึ้น (เล็กน้อย)ซึ่งฉันคาดว่าจะช่วยในการประเมินงานของโครงการได้ดีขึ้น
คำตอบทั้งหมดข้างต้นครอบคลุมทุกอย่างเกี่ยวกับการหาค่าประมาณเอง
สิ่งหนึ่งที่ฉันจะเน้นคือการติดตามค่าประมาณของคุณ (สเปรดชีต Excel ขนาดเล็ก a la Joel หรือแม้แต่เอกสาร Notepad ถ้ามันง่ายมาก) และในตอนท้ายของทุกวันให้อัปเดตตัวเลขนี้เป็นตัวเลขที่แม่นยำที่สุดที่คุณสามารถให้ได้ . แม้ว่าคุณจะไม่จำเป็นต้องส่งเรื่องนี้กลับไปให้เจ้านายของคุณ แต่การอัปเดตข้อมูลนี้จะช่วยให้คุณมีความคิดที่ดีขึ้นเกี่ยวกับความคืบหน้าของสิ่งต่างๆและที่สำคัญคุณจะรู้สึกดีว่าเหตุใดการประมาณการของคุณจึงเปลี่ยนแปลงไปเมื่องานดำเนินไป .
การทำเช่นนี้จะช่วยให้คุณประเมินได้ดีขึ้นในอนาคตทั้งสำหรับเทคโนโลยีเฉพาะนี้และอื่น ๆ ที่คุณไม่เคยใช้มาก่อนเพียงเพราะต้องให้คุณในระดับหนึ่งที่จะสังเกตเห็นเมื่อความคาดหวังของคุณเปลี่ยนไปในช่วงเวลาปกติและหาสาเหตุที่เกิดขึ้น .
การประมาณระยะเวลาที่จะต้องใช้เวลาเป็นส่วนหนึ่งของงานของคุณ ตราบใดที่เข้าใจว่าเป็นการประมาณไม่ใช่กำหนดเวลาคุณก็ไม่ควรกังวลอะไร ไม่มีใครวางค่าประมาณได้ดีไปกว่าผู้ที่จะเขียนโค้ด หากคุณไม่สามารถประมาณการได้ดีคุณจำเป็นต้องแจ้งให้ผู้บริหารทราบถึงความเสี่ยงที่แนบมากับการประมาณการที่ไม่ดีของคุณเพื่อให้พวกเขาสามารถพิจารณาใหม่ได้ว่าคุ้มค่าที่จะเสี่ยงในการเขียนโปรแกรมกับการควบคุมของบุคคลที่สามที่ไม่รู้จักเหล่านี้หรือไม่
นั่นเป็นสถานการณ์ที่พบบ่อยมาก: ความจำเป็นในการจัดการกับสิ่งที่ไม่รู้จัก วิธีที่มีประโยชน์ในการจัดการกับปัญหานี้คือตระหนักดีว่านอกจากงานเขียนโปรแกรมจริงแล้วคุณยังมีการเรียนรู้บางอย่างที่ต้องทำ - และฝ่ายบริหารควรตระหนักถึงสิ่งนั้นด้วย
เมื่อคุณตกอยู่ในสถานการณ์เช่นนี้โครงการจะกลายเป็นโครงการ R&D ในทันใดและเวลาที่ยาวนานกว่าปกติจะไม่ทำให้คุณดูแย่เนื่องจากคุณกำลังเรียนรู้และผลิตรายการ ฉันไม่รู้ว่าคุณเรียนรู้ได้เร็วแค่ไหนหรือคุณมีทรัพยากรอะไรเพื่อจัดการกับปัญหาที่คุณอาจพบ (Stack Overflow เป็นหนึ่งในตัวเลือกที่คุณมี)
ฉันจะบอกว่าคุณควรประมาณตามปกติแล้วคูณด้วย 1.5 (ถ้าคุณเป็นคนที่เรียนรู้เร็วและสามารถเข้าถึงแหล่งข้อมูลเพื่อแก้ปัญหาของคุณได้) หรือ 2.5 หากคุณเป็นผู้เรียนโดยเฉลี่ยและพึ่งพาตัวเองเท่านั้น
ฉันหวังว่านี่จะช่วยได้!
พยายามอย่างเต็มที่เพื่อแยกงานออกเป็นชิ้น ๆ ที่สามารถจัดการได้ ด้วยความโชคดีมีงานบางอย่างที่เกี่ยวข้องกับองค์ประกอบของบุคคลที่สามที่เกี่ยวข้องและงานอื่น ๆ ที่เกี่ยวข้องน้อยกว่า (จึงประเมินได้ง่ายกว่า) ให้ผู้บริหารประเมินการแยกส่วนและชี้ให้เห็นว่าค่าประมาณที่ไม่แน่นอนที่สุดอยู่ที่ใด
ฉันเห็นด้วยอย่างยิ่งกับใครก็ตามที่แนะนำให้เล่นและสร้างต้นแบบบางอย่าง ตั้งค่ากล่องเวลาคงที่สำหรับกิจกรรมการสร้างต้นแบบ ("ฉันต้องใช้เวลาสองวันก่อนเพื่อให้ส่วนนี้ของค่าประมาณของฉันดีขึ้น")
คุณสามารถให้ช่วงได้หรือไม่? 40-60 ชั่วโมงอะไรแบบนั้น?
ยิ่งงานเล็กลงก็ยิ่งยากขึ้นถ้าคุณสามารถจัดกลุ่มได้คุณจะมี "slop" เพิ่มขึ้นเล็กน้อยเนื่องจากข้อผิดพลาดอาจสมดุลในตอนท้ายของโครงการ
ดูพื้นที่ใด ๆ ที่คุณมีประสบการณ์และใช้เป็นแนวทาง "ครั้งสุดท้ายที่จำเป็นในการสร้างคุณลักษณะที่เปลี่ยนฐานข้อมูลฉันต้องใช้ X" โชคดี.