ผู้จัดการโครงการที่ต้องการล็อคประมาณการเวลาด้วยสัญญาที่ลงนามแล้ว

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

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

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

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

ฉันเชื่อว่าสิ่งที่เกิดขึ้นต่อไปคือผู้จัดการโครงการและ / หรือผู้นำโครงการปกป้องฉันและไม่ปล่อยให้สิ่งนี้เกิดขึ้น

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

โปรดทราบว่าฉันเป็นพนักงานเต็มเวลาไม่ใช่ที่ปรึกษาอิสระ

อัปเดต : ฉันต้องการเพิ่มว่าฉันได้ให้การประมาณการใหม่ทุกสัปดาห์ แต่ดูเหมือนว่าการประมาณการและวันที่ส่งมอบดั้งเดิมเป็นสิ่งที่ PM ได้รับการแก้ไข

คำถามของฉันคือสิ่งนี้ควรยกธงสีแดงเกี่ยวกับผู้จัดการหรือไม่

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

เป็นเรื่องปกติหรือไม่ที่ผู้จัดการจะต้องล็อคเวลาประมาณการของผู้พัฒนาซอฟต์แวร์ด้วยสัญญาที่ลงนามแล้ว

ฉันไม่เคยได้ยินเรื่องนี้มาใช้กับพนักงาน

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

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

ใช่นั่นควรจะปลุกเสียงระฆังอย่างแน่นอน

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

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

หนึ่งการเปลี่ยนแปลงข้อมูลจำเพาะ => สัญญาถือเป็นโมฆะ อาจเป็นสิ่งที่จะโมฆะหลังจาก 10 นาทีในวันแรกของคุณ :)

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

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

นี่ไม่ใช่ธงสีแดงนี่คือความโง่เขลาของอาวุธ

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

หากคุณตำหนิและเตะม้าเพราะคุณไม่รู้ว่ากำลังจะไปไหนอย่าแปลกใจถ้าม้ากัดคุณและวิ่งหนีไป!

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

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

การออกกำลังกายอีกอย่างหนึ่งคือการแบ่งงานใหญ่ออกเป็นหน่วยย่อยที่ประเมินได้น้อยกว่า แบบฝึกหัดนี้จะช่วยให้คุณเข้าใจดียิ่งขึ้นว่าคุณต้องทำอะไรบ้างเช่นกัน ตรวจสอบการประมาณค่าซอฟต์แวร์ของ Steve McConnell และรูปแบบข้อกำหนดซอฟต์แวร์ของ Stephen Withall สำหรับเคล็ดลับในการแยกงานและค้นหาข้อกำหนดที่ซ่อนอยู่ตามลำดับ

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

ถาม "ผู้จัดการโครงการ" ของคุณ: เรากำลังขายซอฟต์แวร์หรือกำหนดส่งหรือไม่?

ฉันเป็นผู้จัดการโครงการและโปรแกรมเมอร์ :-) ฉันสามารถพูดจาโผงผางเป็นเวลานานเกี่ยวกับว่า PMs ส่วนใหญ่มาจากนอกอุตสาหกรรมและไม่สามารถจัดการกับสิ่งที่ไม่เหมาะกับรูปแบบสายการผลิต ... แต่ฉัน จะไม่ไม่ใช่ที่นี่ แต่นี่คือการโต้เถียงที่ยาวนานเกี่ยวกับสิ่งที่ต้องทำจริง ๆ (Mr Mod ถ้ามันยาวเกินไปที่จะทำในสิ่งที่คุณต้องการ) ผมเห็นด้วยกับความคิดเห็นที่ทำอยู่แล้วที่นี่บางอย่างที่คุณควรทำก่อนคนอื่น ๆ แต่นี่คือสิ่งที่ผมคิดว่าดีที่สุดจะได้รับการย้ายครั้งแรกของคุณ โอ้และคำตอบที่ชัดเจนสำหรับคำถามของคุณคือใช่ แต่มีรายละเอียดในภาษาที่มีสีสันและรายละเอียดด้านล่าง

ก่อนที่ฉันจะเริ่มสังเกตว่า PM น่าจะทำให้คุณเศร้าโศกเพราะคนอื่นที่อยู่ในห่วงโซ่อาหารกำลังทำให้พวกเขาเศร้าใจ พวกเขา (เรา) เป็นสิ่งมีชีวิตที่เรียบง่าย ... มีหลายวิธีที่จะหลีกเลี่ยงสถานการณ์ที่คุณอธิบายไว้ - ไมค์บราวน์ครอบคลุมได้ดีทีเดียว นอกจากนี้ยังไม่มีอะไรผิดปกติกับการทำงานบางอย่างเป็นเวลา 3/4/5 .. ชั่วโมงก่อนที่จะเริ่มเปิดกล้อง (จริง ๆ แล้วสัญญาณเตือนภัยทุกประเภทต้องออกไปถ้าสิ่งนี้ไม่เกิดขึ้น) และถ้าคุณกำลังจะเข้าไปในดินแดนที่ไม่รู้จักให้ย้อนกลับและขอเวลาหนึ่งสัปดาห์เพื่อทำการวิจัยพื้นที่และเทคโนโลยีเพื่อให้สามารถประเมินได้อย่างสมเหตุสมผล (คุณต้องการทำสิ่งนี้อย่างถูกต้องเพราะคุณต้องการให้เทคโนโลยีใหม่เรียนรู้และเล่นกับดอน คุณเหรอ?) หาก PM และผู้บริหารของคุณในสถานที่ที่คุณอยู่ไม่เข้าใจสิ่งนี้ ... จากนั้นอัปเดตเรซูเม่ของคุณและมองหาทางออกที่ใกล้ที่สุด ปล่อยให้พวกเขาไปสู่ชะตากรรมที่พวกเขาสมควรได้รับอย่างมั่งคั่ง PM คิดว่าจะทำให้พนักงานเต็มเวลาเซ็นสัญญาเช่นนั้นเป็นสัญญาณที่ไม่ดี ... วิธีเดียวที่ฉันจะเห็นว่าพวกเขาอาจจะไม่ไร้ความสามารถเลยก็คือพวกเขาเพียงแค่เล่นเกมใจกับหัวหน้าโครงการของคุณและคุณ (จากสิ่งที่ฉันอ่านพวกเขาไม่ได้นำสิ่งนี้มาให้คุณโดยตรงและในที่สุดก็ไม่ได้ทำตามการคุกคาม) PMing เป็นสวรรค์สำหรับนักจิตวิทยาองค์กรที่เป็นมาตรฐานของคุณ เป็นเรื่องที่ดีที่คนอื่นเข้ามาตีแทนคุณจากสิ่งที่คุณพูดดังนั้นคำแนะนำด้านล่างอาจกลายเป็นผลดีต่อคุณในที่สุด ฉันคิดว่าพวกเขาจะมีการปฏิวัติในมือของพวกเขาหากกลายเป็นมากกว่าการพูดคุย

ดังนั้นกับสถานการณ์ / หลุมที่คุณอธิบายเพราะมันจะเกิดขึ้นกับใครสักคนที่ไหนสักแห่ง (เช่นประมาณ 5 นาทีที่แล้วและอีกครั้งในอีก 5 ตาราง schedRepeat ()) อาจไม่มีความโง่เขลาของสัญญา แต่เนื้อเรื่องพื้นฐานจะเหมือนกันเสมอ จัดระเบียบการประชุม (!) พวกเขาชอบการประชุม ;-) ทุกคนสามารถตบท้ายของตัวเองได้ในตอนท้าย สิ่งสำคัญ:ตรวจสอบให้แน่ใจว่าคุณได้รวมถึงหัวหน้าโครงการ / หัวหน้าทีม / สถาปนิก / ผู้จัดการโครงการด้านเทคนิคของคุณในการเชิญประชุมที่มีปัญหากับพวกเขาอยู่แล้ว ลำดับชั้นที่สูงขึ้นคุณสามารถไปหาใครสักคนที่ 'ด้าน' ของคุณดีกว่า เพราะ PM ของคุณจะเห็นว่าและลองจับคู่ผู้จัดการการออกแบบของคุณด้วยสิ่งที่เทียบเท่า ถ้าไม่ใช่พวกเขาจะโง่และคุณชนะมาแล้ว ในตัวเองโดยทั่วไปแล้วจะดึงพวกเขากลับเข้าแถวเพราะตอนนี้พวกเขาสามารถมองเห็นใครบางคนที่สามารถไล่พวกเขาออกจากที่นั่นได้ หากพวกเขากำลังเล่นเกมกับคุณคุณได้รับอนุญาตให้กลับมาชอบ

ในการประชุมให้ดูรายละเอียดทางเทคนิคเกี่ยวกับสิ่งที่คุณติดต่อด้วยและทำไมต้องใช้เวลา พวกเขาควรต้องการทราบสิ่งนี้ (และวิธีที่พวกเขาสามารถช่วยคุณทำมันให้สำเร็จ) แต่ความจริงที่น่าเศร้าคือสิ่งนี้ไม่ได้เกิดขึ้น ... คุณอาจจะได้รับ 10 นาทีก่อนที่ดวงตาของพวกเขาจะกลิ้งกลับเข้ามาในหัว ตอนนี้สิ่งที่ฉันต้องการทำที่นี่อาจไม่ถูกกฎหมาย ... ใช่ฉันตรวจสอบแล้วมันผิดกฎหมายอย่างยิ่งและคุณไม่ต้องการเข้าคุกนาน ประเด็นก็คือคุณได้พยายามอย่างเต็มที่ในการเป็นฝ่ายรุกและหากคุณมีอาการแสดงที่สูงขึ้นความเจ็บปวดของคุณจะกลายเป็นของพวกเขา ... ตามที่ควรจะเป็น คุณจะต้องใช้วิจารณญาณในการตัดสินว่าสิ่งต่าง ๆ มีความน่าสนใจอย่างไรเนื่องจาก 'การเพิ่มระดับ' เป็นสิ่งที่จะเกิดขึ้น หากความเป็นผู้นำในสถานที่ที่คุณอยู่นั้นเหมาะสมครึ่งหนึ่งพวกเขาจะทำสิ่งที่ถูกต้อง และทำสิ่งที่ถูกต้องโดยคุณเช่นกัน ถ้าไม่เช่นนั้นคุณจะมีประวัติย่อของคุณในตลาดล่วงหน้า ... คุณกำลังจะออกไปในโอกาสแรกต่อไป (และดูเหมือนว่าคุณจะทำในที่สุด) ความเป็นผู้นำจะแบ่งออกเป็นสองกลุ่ม - ไม่ว่าพวกเขาจะเข้าใจในด้านเทคนิคและพวกเขาจะเห็นมุมมองของคุณทันที หรือพวกเขาไม่ได้และพวกเขาจะทำอะไรกับมันนอกเหนือจากรอยยิ้มและแบกมัน? หากพวกเขาสามารถทำสิ่งที่คุณทำแล้วพวกเขาก็จะทำเช่นนั้น พวกเขาจะทำอะไรกับมันนอกเหนือจากรอยยิ้มและรับมัน หากพวกเขาสามารถทำสิ่งที่คุณทำแล้วพวกเขาก็จะทำเช่นนั้น พวกเขาจะทำอะไรกับมันนอกเหนือจากรอยยิ้มและรับมัน หากพวกเขาสามารถทำสิ่งที่คุณทำแล้วพวกเขาก็จะทำเช่นนั้น

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

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

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

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

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

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

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

เช่นเดียวกับผู้ตอบแบบสอบถามคนอื่น ๆ ฉันไม่สามารถตกลงกันได้มากกว่านี้ว่าควรยกธงสีแดง

ดูเหมือนว่า PM ไม่ต้องการมีส่วนร่วมในกระบวนการพัฒนา

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

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

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

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

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

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

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

ลองดูที่ Agile Manifesto: http://agilemanifesto.org/มันอาจดังก้องกับคุณ หนังสือที่ดีในการอ่านก็คือ "การพัฒนาซอฟต์แวร์แบบ Lean" ของ Mary Poppendieck

โชคดี.

ดูเหมือนว่าผู้จัดการกำลังมองหาคนที่จะตำหนิเมื่อเขารายงานต่อหัวหน้าของเขา

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

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

ในที่สุดผู้จัดการโครงการได้รับความคิดและแผนตาม

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

คำตอบที่ดีรอบตัว แต่ขอเพิ่ม 2 เซนต์

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

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

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

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

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

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

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

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

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

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

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

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

หากคุณต้องการแสดงให้เห็นว่าสัญญาดังกล่าวไร้สาระเป็นอย่างไรต่อไปนี้เป็นคำแนะนำสองข้อ:

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

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

ถ้าผู้จัดการโครงการเห็นด้วยกับคำแนะนำสองข้อนี้ที่คุณรู้ว่าพวกเขาอยู่ในใจ

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

ฉันจะไปต่อต้านข้าวที่นี่

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

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

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

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

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

"การเดินบนน้ำและการพัฒนาซอฟต์แวร์จากสเปคนั้นง่ายถ้าทั้งคู่ถูกแช่แข็ง"

-Edward V. Berard

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

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