ฉันจะบัญชีสำหรับงานที่ถูกเปลี่ยนแปลงหรือถูกลืมในการประมาณได้อย่างไร

เพื่อจัดการประมาณการระดับงานและการรายงานเวลาฉันได้ใช้ (โดยประมาณ) เทคนิคที่ Steve McConnell อธิบายไว้ในบทที่ 10 ของการประมาณค่าซอฟต์แวร์. โดยเฉพาะเมื่อถึงเวลาที่ฉันจะสร้างการประมาณการระดับงาน (ขวาก่อนการเข้ารหัสเริ่มต้นในโครงการ) ฉันกำหนดงานในระดับที่ค่อนข้างละเอียดดังนั้นเมื่อเป็นไปได้ฉันไม่มีงานที่มีจุดเดียว 50 ประมาณการ% -confidence มากกว่าสี่ชั่วโมง ด้วยวิธีนี้กระบวนการประมาณงานช่วยในการสร้างซอฟต์แวร์ในขณะที่ช่วยให้ฉันไม่ลืมงานในระหว่างการประเมิน ฉันคิดค่าชั่วโมงที่เป็นไปได้สำหรับแต่ละงานด้วยและใช้การคำนวณทางสถิติที่ McConnell อธิบายพร้อมกับข้อมูลความแม่นยำในอดีตของฉันฉันสามารถสร้างการประมาณการในระดับความเชื่อมั่นอื่น ๆ เมื่อต้องการ ฉันรู้สึกว่าวิธีนี้ใช้งานได้ดีสำหรับฉัน เราจำเป็นต้องนำงานและการประมาณของพวกเขาไปยัง TFS เพื่อติดตามดังนั้นฉันจึงใช้การประเมินตามเปอร์เซ็นต์ความเชื่อมั่นที่ฉันได้รับคำสั่งให้ใช้

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

ฉันยินดีที่จะชี้แจงสิ่งที่ฉันถามหากจำเป็น - แจ้งให้เราทราบว่ามีอะไรไม่ชัดเจน

หนังสือเล่มนี้Waltzing With Bears: การจัดการความเสี่ยงในโครงการซอฟต์แวร์ (โดย DeMarco และ Lister ผู้เขียน Peopleware) มีวิธีการที่ยอดเยี่ยมในเรื่องนี้ นี่คือการตีความซ้ำของฉัน:

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

แต่เราควรคิดถึงการประมาณว่าเป็นการแจกแจงความน่าจะเป็น การประเมิน "โลกที่สมบูรณ์แบบ" นี้เป็นจุดที่เหลือมากที่สุดในการกระจายความน่าจะเป็นโดยประมาณ

ถัดไปสร้าง "ถ้าสิ่งต่าง ๆ เป็นไปอย่างนั้นไปสำหรับโครงการที่คล้ายกันเช่นนี้" การประมาณนี้ช่วยให้คุณใช้ "มุมมองภายนอก" ( http://wiki.lesswrong.com/wiki/Outside_view ) โดยหลีกเลี่ยงจากการเข้าใจผิดในการวางแผน ( http://wiki.lesswrong.com/wiki/Planning_fallacy )

ถัดไปสร้าง "ฉัน 90% แน่ใจว่าเราจะทำตามการประมาณการ X" มั่นใจมาก ๆ ว่าคุณหมายถึง 90% แน่นอน กล่าวอีกนัยหนึ่งคุณคาดว่าจะใช้เวลานานกว่าการประมาณการนี้เพียงครั้งเดียวสำหรับทุก ๆ สิบโครงการที่คุณทำ

ตอนนี้เราสามารถใช้การประมาณการแรกของคุณเป็นประมาณการความน่าจะเป็น 0.1% และที่สองของคุณเป็นประมาณการความน่าจะเป็น 50% (ฤดูกาลเพื่อลิ้มรส) และที่สามเป็นการประมาณ 90% ของคุณซึ่งจะให้เส้นโค้งที่ดี

สมมติว่าการประมาณการ 0%, 50% และ 90% ของคุณคือ 1 พฤษภาคม 1 มิถุนายนและ 1 สิงหาคมจากนั้นกราฟประมาณการของคุณจะมีลักษณะดังนี้:

     100 |                                  ......
         |                        ..........
% chance |                ........
of being |          ......
  done   |      ....
         |   ...
         |...
       0 +-----------------------------------------
          \           \           \           \
           May 1st     June 1st    July 1st    August 1st

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

ในคำ - ฉุกเฉิน

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

อย่างไรก็ตามโดยทั่วไปการพูดมีสามประเภทที่อาจเกิดขึ้นฉันขอแนะนำให้ดู:

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

ส่วนสุดท้ายนี้มีความสำคัญ - ไม่ใช่แค่ "สิ่งต่าง ๆ ใช้เวลานานกว่าที่ฉันคิด" แต่เป็น "โมดูลการจัดตารางเวลาบุคคลที่สามที่เราได้รับแจ้งว่าเราต้องใช้เพราะมาตรฐานของ บริษัท อาจไม่ขึ้นอยู่กับงาน" วิธีที่คุณคำนวณว่ามีความเสี่ยงที่อาจเกิดขึ้นเมื่อต้องเพิ่มความเสี่ยงเป็นร้อยละโอกาสที่ความเสี่ยงอาจเกิดขึ้นจะแสดงเป็นทศนิยม (ดังนั้น 50% = 0.5) คูณด้วยผลกระทบของความเสี่ยงนั้น (เช่นในตัวอย่างว่าคุณต้องเขียน CRON ด้วยตนเอง งานแทนการใช้ตัวจัดตารางเวลาและจะใช้เวลา 10 วันจำนวนนี้คือ 10 วัน)

ดังนั้นหากมีโอกาส 50% ที่ความเสี่ยงของคุณจะผ่านไปและจะใช้เวลา 10 วันในการพยายามปัดเศษถ้ามันเพิ่มคุณก็เพิ่มอีก 5 วัน เพิ่มค่าทั้งหมดสำหรับความเสี่ยงที่ระบุทั้งหมดในโครงการและเพิ่มลงในยอดรวม

2) Shit Happens Contingency - คำอธิบายที่ดีที่สุดที่ฉันเคยได้ยินมาถึงแม้ว่ามันจะไม่ได้สวยงาม มันเป็นโครงการไอทีอึเกิดขึ้น มันไม่เคยเป็นไปตามที่คุณคิดว่ามันจะต้องใช้เวลานานกว่าเดิมพลาดไปเรื่อย ๆ โดยทั่วไป SH ฉุกเฉินจะอยู่ระหว่าง 10% (ขั้นต่ำสัมบูรณ์) และ 25% (แม้ว่าจะสูงกว่า) โดยที่ 15% เป็นเรื่องปกติระดับที่แน่นอนขึ้นอยู่กับระดับของความไม่แน่นอนและความเสี่ยงทั่วไป (โพสต์เป้าหมายเคลื่อนที่ข้อกำหนดที่ไม่แน่นอน )

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

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

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

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

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

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

คุณกังวลหรือไม่ว่าการเพิ่มงานพิเศษคุณจะบิดเบือนความแม่นยำในอดีตของคุณหรือไม่ หรือคุณคิดว่าการไม่รวมงานพิเศษจะทำให้ความแม่นยำเอียง

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