วิธีการวัดมูลค่าที่อาจเกิดขึ้นจากการปรับสภาพ

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

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

นักพัฒนาแนะนำให้แทนที่องค์ประกอบภาษาเก่าที่มีอยู่ด้วยเวอร์ชันใหม่จะเป็น 'สิ่งที่ดี' อย่างไรก็ตามงานนี้จะไม่มีการเพิ่มคุณสมบัติพิเศษและจะเสียค่าใช้จ่าย x dev-days

พนักงานขายแนะนำให้เพิ่ม 'คุณสมบัติใหม่ที่ยอดเยี่ยม' บริษัท วัดมูลค่าของข้อเสนอแนะของเขาโดยใช้สูตร กล่าวคือ มันจะสร้างรายได้ให้กับ บริษัท F ล้านปอนด์ในช่วงเวลา t ปีที่ทำงาน x dev-days

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

มันจะสร้างรายได้ให้กับ บริษัท F ล้านปอนด์ในช่วงเวลา t ปีที่ทำงาน x dev-days

ซึ่งไม่สนใจค่าใช้จ่ายในการบำรุงรักษาค่าใช้จ่ายในการสนับสนุนค่าใช้จ่ายในการขาย / การตลาดและทำให้มีข้อสันนิษฐานมากมายเกี่ยวกับการใช้คุณลักษณะนี้ในตลาด

แต่อะไรก็ตาม คำถามของคุณชัดเจนเพียงพอเกี่ยวกับสิ่งที่คุณกำลังมองหา:

ฉันจะสร้างเคสธุรกิจสำหรับการปรับโครงสร้างใหม่ได้อย่างไร

สิ่งสำคัญที่ต้องตระหนักคือเวลานั้นเท่ากับเงิน คุณสามารถตรงไปที่ "5 นักพัฒนา 2 สัปดาห์ = 80 ชั่วโมง * 5 นักพัฒนา * $ 50 / ชม. -> $ 20,000" และนั่นสมเหตุสมผลสำหรับนักธุรกิจ นักธุรกิจที่ชาญฉลาดจะทราบว่านักพัฒนาทั้ง 5 รายนั้นได้รับการชำระเงินด้วยวิธีใดวิธีหนึ่งซึ่งคุณตอบโต้ว่าไม่ได้ใช้จ่ายหรือประหยัดเงิน $ 20,000 แต่ใช้เงิน 20,000 ดอลลาร์ในวิธีที่สร้างผลกำไรมากที่สุด ยังไงก็ตามกับรายการ

• ประสิทธิภาพ - สมมุติว่าคุณสามารถทำสิ่งต่างๆได้มากขึ้นด้วย C # มากกว่า VB6 เครื่องมือที่ดีกว่าห้องสมุดที่ดีกว่าอะไรก็ตาม เทคโนโลยีที่ใหม่กว่ามีแนวโน้มที่จะดีกว่าสิ่งเก่ากว่า หากคุณสามารถทำสิ่งต่าง ๆ ในเวลาที่น้อยลงนั่นหมายความว่าคุณประหยัดเงินของ บริษัท
• ค่าโสหุ้ย - การเขียนโปรแกรมไม่ใช่เพียงต้นทุนซอฟต์แวร์เท่านั้น พิจารณาว่าเกิดอะไรขึ้นเมื่อ Windows 2020 ออกมา คุณใช้เวลาและความพยายามมากแค่ไหนในการใช้งานแอพ VB6 นั้น มีเวลาและความพยายามมากไปกว่าแอป C # หรือไม่ นั่นคือการประหยัดเงินใน บริษัท ของคุณ
• คุณภาพ - น่าจะเป็นไปได้ว่าคุณสามารถทำสิ่งต่างๆได้ด้วยคุณภาพที่สูงขึ้นใน C # มากกว่า VB6 (หรือด้วยสถาปัตยกรรมที่สะอาดตาหรือเป้าหมายการปรับโครงสร้างใหม่ของคุณ) คุณภาพที่สูงขึ้นหมายถึงข้อบกพร่องที่น้อยลง ข้อผิดพลาดที่น้อยลงหมายถึงค่าใช้จ่ายที่น้อยลงในการแก้ไขข้อบกพร่องเหล่านั้นลดค่าใช้จ่ายในการสนับสนุนลูกค้าในการแก้ไขปัญหาเหล่านั้นการสูญเสียลูกค้าที่น้อยลงเนื่องจากปัญหาด้านคุณภาพ
• HR Savings - พบกับข้อเท็จจริง: ไม่มีใครต้องการทำงานร่วมกับแอป VB6 ที่น่ารังเกียจ นั่นหมายความว่าผู้คนจำนวนมากจะออกจาก บริษัท นำไปสู่เวลาและเงินที่ใช้ไปเพื่อแทนที่พวกเขา นั่นหมายความว่าต้องใช้เวลาและเงินมากขึ้นในการจ้างพนักงานใหม่ ที่แย่ที่สุดก็คือคุณจะมีนักพัฒนาซอฟต์แวร์ที่ฆ่าตัวตายด้วยการทำงานกับแอพ VB6 นักพัฒนาเหล่านั้นจะเร่งปัญหาการตายของปัญหาคุณภาพ การลดอัตราการลาออกและการจ้างงานช่วยให้ บริษัท ของคุณประหยัดเงิน การรักษาความพึงพอใจของนักพัฒนาเส็งเคร็งจะช่วย บริษัท ของคุณ
• ขวัญกำลังใจ - ทำนองเดียวกันโปรแกรมเมอร์ที่เกลียดการทำงานใน VB6 อยู่แล้ว พวกเขาจะทำมันและพวกเขาอาจทำได้ดี แต่มันดูด อาจไม่ใช่สำหรับทุกคน แต่สำหรับบางคน นั่นหมายถึงเวลาที่ใช้ในการเรียกดูเว็บเพื่อชดเชยแรงจูงใจ มันหมายถึงอาหารกลางวันอีกต่อไป มันหมายถึงการทำสิ่งต่าง ๆ ให้น้อยลงในขณะที่โปรแกรมเมอร์ของคุณใช้เวลาในการกู้คืนนานขึ้นจากงานที่ดูด
• ความสามารถ - ไม่สามารถใช้ได้กับ refactors ที่ขับเคลื่อนด้วยเทคโนโลยี แต่ใช้กับการเรียงลำดับ refactors สถาปัตยกรรม ปัญหารหัสบางอย่างทำให้คุณไม่สามารถใช้งานฟีเจอร์ X สุดยอดเพื่อสร้างรายได้มากมาย บางทีคุณไม่สามารถปรับขนาด บางทีคุณอาจไม่สามารถรับข้อมูลเพื่อทำสารสนเทศที่ยอดเยี่ยมได้ บางทีรหัสอาจเป็นรังของหนูซึ่งเป็นเรื่องยากที่จะทำงานได้จริง อะไรก็ตาม บางครั้งคุณอยู่ที่จุดนั้นบางครั้งคุณขับตรงไปที่จุดนั้น เป็นการยากที่จะแปลเป็นธุรกิจพูด แต่ถ้าคุณสามารถ "ปัญหานี้ทำให้เราไม่สามารถใช้ประโยชน์จากโอกาส X, Y และ Z" ได้อย่างมีประสิทธิภาพ

สรุปทั้งหมดคือ "สิ่งนี้จะช่วยให้เราทำงานได้ดีขึ้นถ้าเราทำงานได้ดีขึ้นเราสามารถทำ / ประหยัดเงินให้มากขึ้น"

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

จากประสบการณ์ของฉันพนักงานขายมักจะไม่ทำการประเมิน แต่คาดเดาเกี่ยวกับจำนวนเงินที่มากเกินไปสำหรับการจัดการหรือลูกค้า: ถ้าผู้บริหารพร้อมที่จะจ่าย 50 ชั่วโมงการทำงานต่อสัปดาห์ แต่จะปฏิเสธอย่างแน่นอน 75 คนต่อสัปดาห์ คุณลักษณะนี้จะใช้เวลา 70 สัปดาห์ชายในขณะที่พร้อมที่จะเจรจาใหม่ (สิ่งที่ไม่น่าสงสัยสำหรับการประเมินที่แท้จริง) ลดลงเหลือ 55 คนต่อสัปดาห์

• ในอีกด้านหนึ่งคุณมีการประมาณการโดยผู้เชี่ยวชาญด้านไอทีที่บอกบางสิ่งเช่น:

  ตามการตรวจสอบเฉพาะนี้เรากำลังเสียเงิน $ 8,000 ต่อวันโดยใช้เทคโนโลยีที่ล้าสมัยเมื่อเทียบกับโครงการขนาดใกล้เคียงกันซึ่งใช้เทคโนโลยีที่ใหม่กว่า นอกจากนี้ยังปรากฏว่าจะใช้เวลา 50 ถึง 80 คนต่อสัปดาห์ในการโยกย้ายฐานรหัสทั้งหมด ในช่วงเวลานี้จะไม่มีฟีเจอร์ใหม่ ๆ ออกมา นอกจากนี้ยังมีความเสี่ยง 10% ที่การย้ายองค์ประกอบเฉพาะอาจส่งผลให้มีงานเพิ่มอีก 20-30 สัปดาห์การทำงาน

• ในทางกลับกันคุณคาดเดาได้จากพนักงานขายโดยใช้ประโยชน์จากการเจรจาต่อรองกับบุคคลที่พวกเขาต้องการโน้มน้าวใจ

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

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

สำหรับการประมาณการมันยากมากที่จะสร้างสิ่งที่มีค่าที่นี่เนื่องจากมีพารามิเตอร์จำนวนมากที่ต้องพิจารณา ท่ามกลางคนอื่น ๆ:

• คุณรู้จริงหรือว่าทีมของคุณมีทักษะใน C # เทียบกับ VB6 อย่างไร มันขึ้นอยู่กับการวัดจริงหรือเพียงแค่เดา?

• ทีมนี้พัฒนาโครงการขนาดใหญ่ใน C # หรือไม่ พวกเขารู้เครื่องมือที่ควรใช้ (IDE, debuggers, profilers ฯลฯ ) หรือไม่? คุณต้องการสิทธิ์ใช้งานเพิ่มเติม (ซึ่งในโลกของ Microsoft หมายถึงหลายพันดอลลาร์ต่อเครื่อง)

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

• คุณมีโครงสร้างพื้นฐานที่รองรับ C # หรือไม่? สิ่งที่เกี่ยวกับการรวมอย่างต่อเนื่อง? แล้วเซิร์ฟเวอร์งานสร้างของคุณล่ะ? ไกด์สไตล์? ตัวตรวจสอบแบบคงที่?

• ในการผลิตเซิร์ฟเวอร์ (ถ้านี่คือเว็บแอป) หรือพีซีลูกค้า (หากนี่เป็นแอปเดสก์ท็อป) สามารถเรียกใช้เวอร์ชันของ. NET Framework ที่คุณต้องการใช้งานได้หรือไม่

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

เมื่อคุณแสดงให้เห็นว่าคุณกำลังสูญเปล่าให้พูดว่า $ 8,000 ต่อวันเนื่องจาก VB6 (ซึ่งหมายความว่าคุณจะประหยัด $ 8,000 ต่อวันเมื่อคุณย้ายไปที่ C #) คุณจะอธิบายถึงประโยชน์ของการพัฒนาคุณลักษณะใหม่ทุกอย่างได้อย่างไรและ มุ่งเน้นไปที่การเขียนใหม่ทั้งหมดหรือไม่ ประโยชน์ที่ได้รับเมื่อเปรียบเทียบกับการเขียนซ้ำแบบก้าวหน้าที่คุณโอนย้ายส่วนประกอบของคุณเป็นชิ้นเล็กชิ้นต่อชิ้นในขณะที่จัดส่งคุณลักษณะใหม่

ประการแรกคุณต้องประเมินค่าใช้จ่าย dev สำหรับแฟ็กเตอริ่งอีกครั้งเหมือนที่คุณทำตามคำขอคุณสมบัติการขาย

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

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

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

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

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

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

มูลค่าของการปรับโครงสร้างเกิดขึ้นได้หลายวิธี

มันช่วยให้คุณทำการเปลี่ยนแปลงอื่น ๆ ได้ในภายหลังดังนั้นวัน X ที่คุณลักษณะนั้นจะต้องใช้เวลาจะใช้เวลา 2 / 3X วันจึงจะเสร็จสมบูรณ์ หากต้องการใช้คำศัพท์ที่คล่องตัวจะเพิ่มความเร็ว

การเปลี่ยนแปลงอย่างชัดเจนที่ระบุไว้จะช่วยตลอดเวลาเนื่องจากคุณไม่ต้องการบำรุงรักษานักพัฒนาด้วยประสบการณ์ VB6 อีกต่อไปเฉพาะผู้ที่มีประสบการณ์ C #

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

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

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

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

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

• ค่าใช้จ่ายในการปรับโครงสร้างเท่ากับหรือน้อยกว่าค่าใช้จ่ายในการไม่เปลี่ยนโครงสร้างหรือไม่?

• เป็นไปได้ไหมที่จะตัดค่าใช้จ่ายโดยให้ทีมเล็ก ๆ ของ rockstars refactor โค้ดก่อให้เกิดปัญหามากที่สุด? เราสามารถกระจาย refactor ออกไปได้หรือไม่? มีความไร้ประสิทธิภาพเล็กน้อยทุกที่: เราสามารถ "เติมช่องว่าง" เพื่อพูดกับงานพิเศษนี้ได้ไหม?

ประโยชน์ของการมีระบบ refactored

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

รายการงบประมาณหลักที่ได้รับผลกระทบจากการเปลี่ยนโครงสร้างมีดังนี้:

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

• ค่าใช้จ่ายในการเพิ่มคุณสมบัติใหม่ - อีกครั้งหากการออกแบบระบบและโครงสร้างปัจจุบันทำให้ใช้เวลาในการเขียนคุณสมบัติใหม่อย่างไม่มีเหตุผลสมควรการเขียนซ้ำอาจช่วยประหยัดได้ ดูงบประมาณที่คุณวางแผนไว้สำหรับฟีเจอร์ใหม่ ๆ แต่เป็นจริง - ถ้าคุณอ้างว่าคุณจะเห็นการปรับปรุง 50% แล้วคาดว่าจะพัฒนาฟีเจอร์ใน x man-เดือนที่ก่อนหน้านี้ใช้เวลา 2 * x เดือนคนที่จะรู้ สัญญาดังกล่าวอาจรักษาได้ยาก

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

หากสามคะแนนข้างต้นไม่ถึงค่าใช้จ่ายในการเขียนใหม่ที่คาดไว้ (และอื่น ๆ ; ค่าเสียโอกาสในการใช้จ่าย x dev-days ในคุณลักษณะที่ไม่เท่ากับค่าของคุณลักษณะเหล่านั้นซึ่งมีขนาดใหญ่กว่าต้นทุนที่แท้จริงของ x dev - วัน) ฉันกลัวว่านั่น - เงินออมที่คาดหวังไม่ได้พิสูจน์การเขียนใหม่

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

มูลค่าของการปรับโครงสร้างสามารถวัดได้ดังนี้: ฟีเจอร์ใหม่ x จะมีราคา 5 devs 2 สัปดาห์ หากเราปรับโครงสร้างส่วนประกอบเก่าค่าใช้จ่ายของคุณสมบัติใหม่จะลดลงประมาณ 20% ฟีเจอร์ใหม่ x จะเสียค่าใช้จ่าย 4 devs ใน 2 สัปดาห์

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