PM กำลังเลือกการตั้งค่าที่ซับซ้อนเกินไปซึ่งไม่มีใครมีประสบการณ์กับ [ปิด]

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

สำหรับสิ่งนี้ฉันเริ่มต้นใช้ประโยชน์อย่างชาญฉลาดของไลบรารี่ของ Python ( ThreadPoolExecutor) และใช้ไลบรารี่ที่ใช้งานง่ายสำหรับ front-end (ฉันเลือก Flask เพราะมันง่ายสำหรับผู้เริ่มต้นและง่ายต่อการบำรุงรักษาและทดสอบ)

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

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

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

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

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

นี่ไม่ใช่สิ่งที่เหมาะสมสำหรับ PM ถึง "รัฐ" เพียงฝ่ายเดียว เหตุผลสองประการ:

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

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

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

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

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

อะไรจะโง่คือการปล่อยให้ตัวเองได้รับการตายเดิน

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

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

สิ่งที่คุณควรทำคือคิดอย่างหนักเกี่ยวกับสิ่งที่คุณมีสิทธิ์ที่จะคาดหวัง

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

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

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

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

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

อย่างจริงจังเพียงให้ในสิ่งนี้ไม่เป็นมืออาชีพและเป็นอันตรายต่อโครงการ

ฉันเคยมาที่นี่ชาย มากกว่าหนึ่งครั้ง มันทำให้คุณรู้สึกงี่เง่า ไม่จริงหรอก คุณเพิ่งหลงทาง

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

ถ้ามันไม่ได้ผลก็ดีเพราะคุณจะต้องใช้มันเร็ว ๆ นี้ ไม่ทางใดก็ทางหนึ่ง

นี่ควรจะเป็นใน working.stackexchange.com เพราะปัญหาไม่ใช่คำถามพัฒนาซอฟต์แวร์ แต่เกี่ยวกับความสัมพันธ์ในที่ทำงาน

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

การไม่ทราบบริบทและกลยุทธ์ผลิตภัณฑ์ที่ดำเนินการโดยฝ่ายจัดการของคุณจึงเป็นการยากที่จะตอบคำถามของคุณอย่างเป็นกลาง

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

• " เก็บไว้ในใจว่าไม่มีใครรู้วิธีการใช้ผลิตภัณฑ์เหล่านี้เลย "
• การใช้เครื่องมือและเทคนิคที่รู้จักกันดีเท่านั้นจะช่วยเพิ่มความมั่นใจในการผลิต แต่มันจะจำกัดความสามารถในการคิดค้น ในบางตลาดอาจเป็นอันตรายถึงชีวิตสำหรับผลิตภัณฑ์ของคุณ ตัวอย่างเช่นเกือบ 30 ปีที่แล้วฉันเสนอให้ใช้ windows 3.0 เพื่อพัฒนาผลิตภัณฑ์ CAD รุ่นใหม่ที่ประสบความสำเร็จภายใต้ MS-DOS ผู้จัดการผลิตภัณฑ์คัดค้านว่านี่ไม่ใช่สภาพแวดล้อมที่พิสูจน์แล้วว่ามันจะซับซ้อนเกินไปและยากเกินกว่าที่จะเรียนรู้สำหรับทีมและต่อไปว่า " Windows จะไม่เป็นสภาพแวดล้อมที่สำคัญ " ... ฉันขอให้คุณเดาความสำเร็จของ ผลิตภัณฑ์ของเขา 2 ปีต่อมา
• มันเป็นเรื่องของต้นทุนและผลประโยชน์ ค่าใช้จ่ายในการทดลองเทียบกับประโยชน์ของความสามารถในการปรับขนาดและความสามารถในการปรับใช้ทำให้มั่นใจได้โดยบุคคลที่สามที่มีประสบการณ์กับการติดตั้งจำนวนมากและภาระงานหนัก
• ข้อเสียของการเพิ่มเทคโนโลยีใหม่สามารถทำให้ราบรื่นขึ้นด้วยการฝึกอบรมที่เหมาะสมหรือการสนับสนุนเบื้องต้น / การฝึกสอนโดยที่ปรึกษาที่มีประสบการณ์

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

มีสองวิธีในการเข้าถึงไลบรารีบุคคลที่สาม (และส่วนประกอบอื่น ๆ ):

1. ใช้มากเท่าที่จะทำได้
2. ใช้ให้น้อยที่สุด

แนวทางของฉันคือ (2) ดูเหมือนว่าวิธีการของคุณก็เช่นกัน (2) แต่ผู้จัดการโครงการชอบแนวทาง (1)

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

หากคุณต้องการโน้มน้าว PM ให้เปลี่ยนแนวทางพิจารณาข้อโต้แย้งเหล่านี้:

• ใช้เวลาในการเรียนรู้ แต่ละไลบรารีภายนอกต้องใช้เวลาในการเรียนรู้ซึ่งในเวลานั้นโปรแกรมเมอร์ผู้มีอำนาจอาจเขียนฟังก์ชันการทำงานที่ต้องการโดยเฉพาะอย่างยิ่งหากมีการเลือกไลบรารีขนาดใหญ่เพื่อทำสิ่งที่ง่ายมากที่สามารถทำได้ในหลายร้อยบรรทัดของโค้ด
• Replaceabilityหากคุณมีห้องสมุดภายนอกคุณจะมั่นใจได้อย่างไรว่าหากการพัฒนาหยุดลงคุณสามารถแทนที่ห้องสมุดนั้นด้วยห้องสมุดอื่นที่คล้ายกันได้ ทางออกของฉันคือการหลีกเลี่ยงไลบรารีภายนอกเมื่อใดก็ตามที่ฉันสามารถทำได้และเมื่อใดก็ตามที่มันเป็นไปไม่ได้ฉันเขียน wrapper ง่าย ๆ เพื่อย่อส่วนของอินเตอร์เฟสโปรแกรมมิงที่ฉันต้องการ โดยปกติแล้วอินเตอร์เฟสที่ฉันต้องการนั้นง่ายกว่าอินเทอร์เฟซที่ห้องสมุดมีให้ จากนั้นรหัสของฉันเข้าถึงไลบรารีภายนอกผ่านเสื้อคลุมนี้เท่านั้นทำให้การเปลี่ยนง่ายขึ้น การสร้างแอปพลิเคชันทั้งหมดของคุณในกรอบงานบางอย่างเป็นเรื่องใหญ่ Servlets? ใช่พวกเขาอยู่ที่นี่เป็นเวลานานและยังคงอยู่ที่นี่ต่อไปในอนาคต เครื่องมือเทมเพลต? ใช่แม้ว่าพวกเขาจะไม่สามารถเปลี่ยนได้อย่างแน่นอน (คุณมักจะเลือกหนึ่งและอยู่กับที่) ค่าที่พวกเขานำมามีขนาดใหญ่มาก ดังนั้นให้เลือกอย่างระมัดระวัง - และโปรดทราบว่าเมื่อสลับเทมเพลตเอ็นจิ้นคุณสามารถมีเทมเพลตเอ็นจิ้นสองตัวในแอพพลิเคชั่นเดียวกัน แต่คุณไม่สามารถมีสองเฟรมเวิร์กในแอปพลิเคชันเดียวกันได้ตามปกติ Apache Struts ไม่กรอบมากับแฟชั่นและล้าสมัยอย่างรวดเร็วและโดยปกติคุณไม่สามารถมีสองกรอบในแอปพลิเคชันเดียวกัน
• เวอร์ชั่นนรก ด้วยการเลือกไลบรารี่ภายนอกคุณจะต้องอัพเดตมันเพื่อหลีกเลี่ยงช่องโหว่ด้านความปลอดภัยและการอัพเดตมันอาจทำให้เกิดความเสียหายได้ ส่วนประกอบที่ออกแบบมาอย่างดี (เช่น Java JRE) เข้ากันได้กับเวอร์ชันที่แตกต่างกัน แต่ประสบการณ์ของฉันคือห้องสมุดส่วนใหญ่มีความผิดพลาด นอกจากนี้คอมโพเนนต์ X อาจต้องการ Z เวอร์ชัน 1 และคอมโพเนนต์ Y อาจต้องการ Z เวอร์ชัน 2 และคุณอาจไม่จำเป็นต้องเชื่อมโยง Z เวอร์ชั่น 1 และ Z เวอร์ชั่น 2 ในแอปพลิเคชันเดียวกัน
• ช่องโหว่ด้านความปลอดภัย ด้วยการเลือกไลบรารี่ภายนอกจำนวนช่องโหว่ความปลอดภัยที่ใช้ประโยชน์ได้ง่ายจากแอปพลิเคชันของคุณจะเพิ่มขึ้น บางคนอาจอ้างว่ารหัสที่พัฒนาขึ้นเองนั้นมีลักษณะคล้ายกับการรักษาความปลอดภัยผ่านความสับสน แต่แล้วอีกครั้งฉันจะบอกว่ามันยังคงเป็นรูปแบบความปลอดภัย
• ปัญหาใบอนุญาต ห้องสมุดภายนอกแต่ละแห่งกำหนดสิทธิ์ใช้งานของตนเองในส่วนของโปรแกรมของคุณ ตัวอย่างเช่นไลบรารี GPL ไม่สามารถใช้ในโปรแกรมที่ไม่ใช่ GPL และไลบรารี LGPL ยังต้องการการแจกจ่ายซอร์สโค้ดพร้อมกับไบนารีซึ่งอาจใช้แบนด์วิดท์จำนวนมาก
• เวลาเริ่มต้นแอปพลิเคชัน แต่ละไลบรารี่ภายนอกขนาดใหญ่จะชะลอเวลาเริ่มต้นแอปพลิเคชันของคุณ ด้วยการเขียนไลบรารี่แบบธรรมดาคุณสามารถทำให้เวลาเริ่มต้นของแอปพลิเคชันของคุณเร็วขึ้น
• หน่วยความจำรอยเท้า โดยการให้ X ต้องการ Y ต้องการ Z ต้องการ A ต้องการ B คุณต้องมี X + Y + Z + A + B ในหน่วยความจำในเวลาเดียวกัน ด้วยการติดตั้ง X ที่เทียบเท่าเท่านั้นลองเรียกมันว่า X ', ภายในองค์กรคุณต้องการเพียง X' ในหน่วยความจำ และโดยปกติรอยความทรงจำของ X 'น้อยกว่ารอยความทรงจำของ X
• ความเสี่ยงของข้อผิดพลาด ยิ่งมีบรรทัดในส่วนประกอบภายนอกมากเท่าไรความเสี่ยงที่คุณจะพบข้อผิดพลาดก็จะสูงขึ้นซึ่งยากที่จะแก้ไขเนื่องจากมีโค้ดจำนวนมากที่คุณต้องเข้าใจ หากคุณทำสิ่งที่อยู่ในบ้านคุณมักจะทำโดยใช้โค้ดน้อยกว่า (เพื่อทำสิ่งที่คุณต้องการไม่มีอะไรอื่น) และทำให้ความเสี่ยงของข้อบกพร่องเล็กลง
• customizability ถ้าฉันเขียนแบบสอบถาม SQL ด้วยตัวเองฉันรู้ว่าแบบสอบถามมีลักษณะอย่างไรและประสิทธิภาพในเครื่องมือฐานข้อมูลที่กำหนดและชุดดัชนีได้ดีเพียงใด ในทางกลับกันถ้าแบบสอบถาม SQL เขียนโดยองค์ประกอบภายนอกฉันไม่รู้อะไรเกี่ยวกับประสิทธิภาพของมัน ฉันเคยทำงานใน บริษัท ที่แต่ละเว็บเพจใช้เวลาหลายวินาทีในการดึงข้อมูล ฉันสงสัยว่าสาเหตุคือไลบรารี Hibernate ที่พวกเขาใช้ดึงข้อมูลมากเกินไปโดยอัตโนมัติจากฐานข้อมูลเมื่อสิ่งที่คุณต้องการคือหนึ่งรายการและไม่ใช่ทุกรายการที่เกี่ยวข้องกับรายการเฉพาะนี้ ฉันออกจาก บริษัท ก่อนที่จะค้นพบสาเหตุที่แท้จริงของความเชื่องช้าเพราะฉันไม่ชอบวิธีการใช้ห้องสมุดที่มีอยู่จำนวนมาก

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

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

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

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

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

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

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

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

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