การต่อรองและเอาชนะความพยายามในการประมาณค่าการแย่งชิงส่วนที่ถูกต้องของกระบวนการหรือไม่

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

PO มักจะเอาชนะประมาณการเช่น: "คุณต้องการอะไร 13 เรื่อง [4 วัน] สำหรับเรื่องนี้ไม่เป็น! ฉันไม่สามารถอธิบายสิ่งนี้กับฝ่ายบริหารได้ ด้วย 3 SP [ใน 4 ชั่วโมง]! " เป็นผลให้นักพัฒนาได้รับแขนของพวกเขาบิดที่จะมอบให้กับประมาณ 5 หรือ 8 เรื่องราว [1.5 ถึง 2 วัน] ประมาณการ (การต่อสู้แย่งชิงยังคงเป็นภาระผูกพันไม่ได้เป็นเพียงการคาดการณ์)

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

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

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

แนวทางการแย่งชิงกันพูดในหัวข้อนี้หรือพวกเขาพูดอะไรเกี่ยวกับมัน?

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

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

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

หากคุณต้องการเมืองhttp://www.scrumguides.org/scrum-guide.htmlในฐานะผู้มีอำนาจฉันจะเน้น:

มีเพียงทีมพัฒนาเท่านั้นที่สามารถประเมินสิ่งที่จะประสบความสำเร็จใน Sprint ที่กำลังจะมาถึง

และ

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

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

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

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

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

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

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

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

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

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

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

แนวทางการแย่งชิงกันพูดในหัวข้อนี้หรือพวกเขาพูดอะไรเกี่ยวกับมัน?

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

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

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

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

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

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

ใช่และไม่.

ใช่ทีมการวิ่งควรเจรจากับเจ้าของผลิตภัณฑ์เกี่ยวกับสิ่งที่จะเข้าสู่การวิ่ง

ไม่เจ้าของผลิตภัณฑ์ไม่ได้บอกว่าต้องใช้เวลานานเท่าใด คุณเป็นผู้เชี่ยวชาญไม่ใช่พวกเขา

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

"ไม่"

พวกเขากำลังจะทำอะไร? เขียนรหัสด้วยตัวเอง?

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

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

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

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

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

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

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

ฉันว่ามันขึ้นอยู่กับแรงจูงใจมากที่นี่ เป้าหมายที่ครอบคลุมของการประมาณค่าคือการได้รับความคิดว่าทีมสามารถบรรลุผลสำเร็จได้มากแค่ไหนในระหว่างการวิ่งที่กำหนด ตัวอย่างเช่นหากทีมทำคะแนนให้เสร็จ 30 คะแนนในแต่ละการวิ่งและมีคะแนนประมาณ 60 เรื่องก่อนรายการ X ใน backlog เจ้าของผลิตภัณฑ์สามารถพูดได้ว่ารายการ X จะเสร็จสมบูรณ์ในเวลาประมาณ 6 สัปดาห์ (ขึ้นอยู่กับ การวิ่งสองสัปดาห์มาตรฐาน)

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

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

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