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

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

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

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

ฉันจะจัดการกับสถานการณ์ได้อย่างไร

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

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

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

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

Iceberg Secretสุดคลาสสิคของมันกลับมาอีกครั้ง ความลับที่จะทำอย่างไรกับความจริงที่ว่าเช่นเดียวกับภูเขาน้ำแข็งเป็น 90% ใต้น้ำเพื่อที่จะเป็นส่วนใหญ่ของใด ๆโครงการพัฒนา: 90% ของการทำงานเป็นไปได้อย่างสมบูรณ์ที่มองไม่เห็นให้กับผู้ใช้ รหัสนั้นจะมีผลกระทบต่อผู้ใช้ แต่การจัดการมีปัญหาในการคิดว่าทำไมคุณใช้เวลาหกชั่วโมงในการปรับสภาพการบำรุงรักษา / การปล่อยและการอ้างอิงอัตโนมัติเมื่อพวกเขาไม่เห็นความแตกต่างและทุกอย่างทำงานได้ดี

ข้อเท็จจริงบางประการที่คุณสามารถนำติดตัวคุณไปได้ในเรื่องนี้

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

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

คุณทำไม่ได้

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

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

ฉันได้ตอบคำถามที่คล้ายกันที่นี่มาก่อนเพื่อให้นี่อาจเป็นเรื่องซ้ำ โดยทั่วไปคุณจะไม่ได้รับการลงทะเบียนเพื่อทำการ "refactoring พยายาม" วิธีที่คุณใช้ในการทำความสะอาดรหัสคือปฏิบัติตามกฎลูกเสือ: ออกจากตัวทำความสะอาดรหัสทุกครั้งเมื่อคุณปล่อยให้มันมากกว่าเมื่อคุณมาถึง

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

ฉันขอแนะนำให้อ่านBob Coderโดย "ลุง" Bob Martin การเขียนรหัสที่ดีเป็นส่วนหนึ่งของงานของคุณ คุณไม่ได้รับอนุญาตให้ทำงาน แต่คุณก็ทำได้

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

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

โชคดี!

นำเสนอกรณีศึกษาทางธุรกิจ

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

• ค่าใช้จ่ายล่วงหน้าคืออะไร?
• ค่าใช้จ่ายต่อเนื่องคืออะไร?
• การประหยัดเงิน / เวลาที่คาดการณ์ไว้คืออะไรและมาจากไหน
• จะใช้เวลานานเท่าใดก่อนที่เราจะเห็น ROI

เมื่อทำกรณีธุรกิจคุณควรสำรองอาร์กิวเมนต์ด้วยข้อมูลเสมอ

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

จัดเรียงตัวเลขและทำให้เป็นสมการหยาบ แต่ง่าย จะมีค่าใช้จ่าย X ในการทำและจะเป็นประโยชน์ต่อ บริษัท Y

หมายเหตุ: อย่าแปลกใจถ้ามันมีราคาแพงในการใช้ความคิดเชิงวิชาการที่ดี

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

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

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

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

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

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

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

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

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

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

บางทีนี่อาจไม่ใช่คำตอบ แต่การตอบกลับตามความผิดพลาดที่ฉันทำ ยังขัดแย้งกับปรัชญาบางอย่างที่ฉันอ่านที่นี่

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

แต่แน่นอนทำตามคำแนะนำที่ดีเยี่ยมในการปรับปรุงสิ่งต่าง ๆ

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

ซีอีโอ (ที่จริงมีอินเดียนแดง) ชอบ PHB เพราะ PHB มอบคุณสมบัติ การวิ่งทุกครั้งที่เขาแสดงให้เห็นถึงกล่องติ๊กใหม่ (ไม่ตรงแนวกับฉลากที่ไม่ชัดเจน) ไอคอนประกาย (ยังไม่สามารถใช้งานได้ในทุกสภาพแวดล้อม แต่มีสี 8 บิตเหนือ Citrix) และรูปแบบ (ที่มีการขัดข้องแบบสุ่มเนื่องจากสภาพการแข่งขัน ใน C ตาม xml bespoke ใช้ฐานข้อมูลท้องถิ่นที่ไม่มีใครในทีม dev กล้าสัมผัสเพราะมันถูกเขียนโดยหนึ่งในตำนาน dev dev ยามเก่าเมื่อ 10 ปีที่แล้วและทุกสิ่งที่มีมาโครกับชื่อ 5 ตัวอักษรไม่ว่าพวกเขาต้องการ 5 ตัวอักษรหรือ ไม่).

โปรแกรมเมอร์ที่ทำ "work bit" (คุณรู้ว่าบิตนั้นเกิดขึ้นไม่สะดวกหลังจากการทำงานจริงทั้งหมดเช่นวาดวงกลมบนกระดานไวท์บอร์ดตะโกนและกิน Battenburgs จิ๋ว) รู้ว่าในระบบสติงานที่ใช้ 10 คน 10 วันในการแฮ็กออกมาจากป่าที่ไม่มีใครดูแลอย่างขยันขันแข็งอาจจะใช้เวลาประมาณหนึ่งหรือสองวันรวมถึงการทดสอบ แต่การได้รับระบบจากจุดที่มีสติอยู่นั้นอาจต้องใช้เวลา 6 เดือนในการทำงานอย่างแท้จริงโดยมีรางวัลจากภายนอกเล็กน้อย

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

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

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

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

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

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

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

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

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

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

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

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

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

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

หากคุณมีการตรวจสอบรหัสให้สร้างตั๋วทางเทคนิคที่ระบุว่าควรปรับปรุงรหัสโดยใช้ ARC และมอบหมายให้ผู้จัดการ

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

คุณต้องขายการเปลี่ยนแปลงเหล่านั้นด้วยวิธีเดียวที่ฝ่ายบริหารยินดีที่จะซื้อ:

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

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

1. ใช้เวลานานแค่ไหนในการส่งมอบตามคำขอของลูกค้า?
2. คุณส่งมอบเมื่อคุณบอกว่าคุณจะ?

ส่วนใหญ่คุณจะบอกว่าจะใช้เวลา 6 สัปดาห์และส่งมอบใน 5 กว่าบอกว่าคุณจะส่งมอบใน 3 แต่ใช้เวลา 4

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

ฉันจะบอกคุณเกี่ยวกับโอกาส 2 พันล้านเหรียญที่เกือบจะหลุดมือเราเพราะความเฉื่อยของการจัดการ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

โชคดี!

นี่คือเหตุผลที่คำขอของคุณสำหรับการนับการอ้างอิงอัตโนมัติถูกปฏิเสธ:

1. มันไม่ได้ปรับปรุง เมื่อคุณมีอะไรที่ใหญ่กว่าโลกสวัสดีการเปลี่ยนแปลงใด ๆ ก็จะไปในทิศทางที่ผิด ไม่มีการปรับโครงสร้างจำนวนมากจะเปลี่ยนความจริงที่ว่าถ้าคุณต้องการทำการเปลี่ยนแปลงมันจะไปในทิศทางที่ผิดเสมอ เคล็ดลับคือการรู้ว่าการเปลี่ยนแปลงของคุณมีความสำคัญมากพอที่จะยังคงมีความเสี่ยงต่อการเกิดปัญหาใหม่ ๆ ฝ่ายบริหารของคุณกล่าวอย่างชัดเจนว่าหากผู้ใช้ไม่สามารถมองเห็นได้มันไม่คุ้มกับความเสี่ยง
2. การนับการอ้างอิงเป็นคุณสมบัติที่บ้าอย่างสมบูรณ์ คุณเห็น บริษัท ยักษ์ใหญ่ที่มีชื่อเสียงบางแห่งใช้คุณสมบัติบางอย่างและคิดว่าคุณต้องการคุณสมบัติเดียวกันทันที มีความเป็นไปได้มากที่โค้ดเบสของคุณจะแตกต่างจากแอปเปิ้ลที่ใช้อย่างสิ้นเชิง การนับการอ้างอิงอาจจะไม่ทำงานหรือเสียเวลา คุณควรหาวิธีที่แตกต่างกันซึ่งไม่จำเป็นต้องมีการกระจายการอ้างอิงแบบดั้งเดิมในทุกที่ในรหัสของคุณ น่าจะเป็นแผนการ refcounting ของคุณต้องการการแก้ไขหลายพันรายการใน codebase การเปลี่ยนแปลงเหล่านั้นส่วนใหญ่ไม่จำเป็น เพียงแค่เสียเวลาและเงิน
3. คุณกำลังแก้ไขปัญหาที่ผิด ผู้บริหารมักจะรู้ว่ามีปัญหาอะไรในระบบ ปัญหาการรั่วไหลของหน่วยความจำที่ไม่เกี่ยวข้องบางอย่างที่การแก้ปัญหาการอ้างอิงซ้ำกำลังแก้ไขไม่ใช่หนึ่งในนั้น มุ่งเน้นไปที่ปัญหาที่แท้จริงและไม่ใช่ปัญหาในจินตนาการกับวิธีที่คอมพิวเตอร์จัดการกับหน่วยความจำ
4. ใช้เวลานานเกินไปในการปรับใช้ Apple เป็น บริษัท ที่ใหญ่กว่าทีมที่ไม่มีนัยสำคัญเล็กน้อยของคุณโดยมีโปรแกรมเมอร์และผู้จัดการบางคน พวกเขาสามารถทำการเปลี่ยนแปลงครั้งใหญ่เพียงแค่จ่ายราคา ถ้าใช้เวลาไม่กี่ล้านในการดำเนินการบางอย่างก็คือถั่วลิสง หาก บริษัท ขนาดเล็กพยายามทำสิ่งเดียวกันพวกเขาจะหมดเงินเร็ว การพัฒนาซอฟต์แวร์มีราคาแพงมากอยู่แล้ว การเพิ่มค่าใช้จ่ายที่ไม่จำเป็นจะไม่ช่วยสักหน่อย หนึ่งในคุณสมบัติที่ไม่เกี่ยวข้องเช่นการจัดการหน่วยความจำกำลังจะเปิดประตูระบายน้ำ: หลังจากที่พวกเขาอนุมัติแล้วโปรแกรมเมอร์ครึ่งหนึ่งของคุณต้องการให้ "การปรับปรุง" ของตัวเองถูกนำไปใช้ มันเป็นเรื่องราวที่ไม่รู้จบและ บริษัท อาจทำสิ่งที่มีประโยชน์แทน

นี่คือขั้นตอนที่คุณสามารถใช้เพื่อจัดการปัญหา:

1. วางคุณสมบัติ
2. ค้นหาสิ่งที่เป็นปัญหาจริง
3. เริ่มทำสิ่งที่มีประโยชน์
4. วางแผนอย่างรอบคอบว่าคุณใช้เวลาอย่างไร
5. ค้นหาวิธีการที่คุณนำเงินมาปรับปรุง
6. เลือกเฉพาะคุณสมบัติที่นำเงินมาให้ได้จำนวนมากที่สุด
7. ตระหนักดีว่าการเขียนโปรแกรมด้านการพัฒนาซอฟต์แวร์เป็นเพียงส่วนเล็ก ๆ ของระบบทั้งหมด - การปรับปรุงให้ดีขึ้นจะไม่คุ้มค่ากับเวลา