ฉันสนใจที่จะรู้วิธีจัดการกับกระบวนการพัฒนาซอฟต์แวร์ในปัจจุบันซึ่งไม่ได้เปลี่ยนแปลงมานานหลายปีและในที่สุดจะนำไปสู่ความล้มเหลวของผลิตภัณฑ์และทีม ใช่อาจเป็นวิธีที่ง่ายกว่าในการแก้ปัญหานี้คือการเปลี่ยนงาน แต่ด้วยเศรษฐกิจแบบนี้พูดง่ายกว่าทำ อย่างไรก็ตามหากคุณมีตัวอย่างที่เฉพาะเจาะจงและได้เห็นหรืออยู่หลายครั้งในสถานการณ์เดียวกันและคิดว่าทางออกที่ดีที่สุดในการแก้ไขปัญหาเหล่านี้คือการออกจาก บริษัท โปรดสนับสนุนคำตอบของคุณ ประเด็นคือคำถามนี้มีคำตอบจริง ๆ โดยเฉพาะอย่างยิ่งหากผู้เชี่ยวชาญหลายคนในหัวเรื่องจบลงซึ่งบ่งชี้ว่าเส้นทางที่ดีที่สุดที่จะไปคือ: เส้นทาง A.
ฉันรู้ว่านักพัฒนาซอฟต์แวร์จำนวนมากเคยเป็นหรืออยู่ในสถานการณ์ที่คล้ายคลึงกัน นี่คือหนึ่งในเหตุผลหลักว่าทำไม บริษัท จึงกลายเป็นอันดับ 1 ในตลาดของพวกเขาจนกลายเป็นตลาดสุดท้ายหรือแม้แต่ในตลาด หวังว่าคำตอบในโพสต์นี้จะช่วยให้ผู้พัฒนารายอื่นเผชิญกับอุปสรรคที่คล้ายกัน ในทีมพัฒนาขนาดเล็กหรือใหญ่สิ่งนี้มักจะเกิดขึ้น:
- นักพัฒนาบางคนดูเหมือนจะไม่สนใจและตัดสินใจที่จะไปกับกระแสและชอบที่จะปล่อยให้รหัสที่มีจำนวนมากของรหัสกลิ่นในแบบที่มันเป็นและกระบวนการพัฒนาตามที่เป็นอยู่
- บางคนเบื่อที่จะไม่มีการเปลี่ยนแปลงลาออกและย้ายไปที่ บริษัท อื่น
- คนอื่น ๆ ดูเหมือนกลัวที่จะพูดคุยและชอบที่จะอยู่เงียบ ๆ
- ในบางครั้งนักพัฒนาน้อยมากหรือเพียงแค่พยายามพูดเพื่อปรับปรุงผลิตภัณฑ์และบอกทีมว่าสำคัญอย่างไรที่ต้องปฏิบัติตามวิธีปฏิบัติที่ดีที่สุดในการเขียนโค้ดและผลประโยชน์ของการทำเช่นนั้นสำหรับลูกค้าผู้ใช้และทีม นักพัฒนาประเภทนี้มักตัดสินใจที่จะอยู่กับทีมเนื่องจากเหตุผลต่าง ๆ เช่น บริษัท เสนอผลประโยชน์ที่ บริษัท ซอฟต์แวร์มีให้น้อยมากหรือผลิตภัณฑ์มีศักยภาพมากมายเป็นต้น
ผลิตภัณฑ์ในทีมของเราเป็นเพียงเศษเสี้ยวที่ บริษัท ได้รับรายได้เนื่องจากมีผลิตภัณฑ์ (บริษัท นี้ไม่ใช่ บริษัท ซอฟต์แวร์ / ฮาร์ดแวร์ดังนั้นจึงไม่มีการดำเนินคดีสิทธิบัตรอย่างต่อเนื่องอย่างน้อยตอนนี้ซึ่งสร้างงาน ความไม่แน่นอน) สิ่งที่ฉันได้เรียนรู้ในช่วงหลายปีที่ผ่านมาจากประสบการณ์ของนักพัฒนาคนอื่นและประสบการณ์ของฉันคือการรู้จักทีมพัฒนาจริง ๆ ต้องใช้เวลาไม่ใช่วันหรือสัปดาห์ แต่ไม่กี่เดือน ระหว่างการสัมภาษณ์หากทีมต้องการจ้างคุณหรือต้องการคุณ พวกเขาทำให้ทุกอย่างดูดีและพวกเขาอาจบอกคุณว่าคุณต้องการได้ยินอะไร อย่างไรก็ตามความเป็นจริงจะแตกต่างกันเมื่อคุณเริ่มทำงานในทีมนั้นและเริ่มขุดในโค้ดและเคลื่อนไปสู่กระบวนการ SDLC ที่สมบูรณ์ นี่คือเมื่อเป็นนักพัฒนาคุณเริ่มเห็นความเป็นจริงของงานที่คุณได้รับ ความเป็นจริงนี้ทำให้มันยากที่จะต้องการย้ายจาก บริษัท หนึ่งไปอีก บริษัท หนึ่งเพราะมันยากที่จะรู้ว่า บริษัท ที่คุณย้ายไปจะดีกว่าหรือแย่กว่านั้น ใช่คุณสามารถอ่านบทวิจารณ์ Glassdoor ฯลฯ .. แต่ความคิดเห็นออนไลน์เหล่านั้นมีอยู่จริงและไม่ใช่จาก HR กี่คน?
อะไรจะเป็นวิธีที่ดีที่สุดในการแก้ไขปัญหาที่ระบุไว้ด้านล่างเมื่อพิจารณาว่าผู้จัดการตั้งแต่เริ่มต้นต่อต้านการเปลี่ยนแปลงเสมอและนักพัฒนาก่อนหน้านี้ทำแบบเดียวกันมานานหลายปี?
การขาดนวัตกรรมของผลิตภัณฑ์มานานหลายปี: ผลิตภัณฑ์มีศักยภาพมากมายและนำรายได้ที่ดีมาสู่ บริษัท แต่ผลิตภัณฑ์ดูเหมือนว่าจะสร้างขึ้นเมื่อ 20 ปีก่อน ผู้ใช้บางคนบ่นว่าผลิตภัณฑ์นั้นไม่เป็นมิตรกับผู้ใช้และไม่เข้าใจง่ายและคนอื่น ๆ ได้กล่าวถึงที่ใช้กับแอพเช่น Gmail และผิดหวังเมื่อใช้ผลิตภัณฑ์เพราะไม่มีคุณสมบัติที่คล้ายกัน ปัญหาหลักของที่นี่คือเมื่อคุณพยายามเป็นนักพัฒนาซอฟต์แวร์เพื่อทำการเปลี่ยนแปลงผลิตภัณฑ์และเริ่มที่จะย้ายองค์ประกอบหลักของผลิตภัณฑ์ที่อยู่ห่างออกไปเพียงไม่กี่พิกเซล (เพื่อให้ผู้ใช้เป็นมิตรมากขึ้นหรือใช้งานง่ายขึ้น) เพื่อนำกลับไปใช้ในที่เดิม หากคุณพยายามที่จะเพิ่มฟีเจอร์ที่จะเป็นประโยชน์ต่อผู้ใช้งานผู้จัดการขอให้คุณลบออกเพราะ "ผู้ใช้จะใช้ในการทำกระบวนการในลักษณะที่เป็น ฯลฯ " ฉันคิดว่าคุณมีจุดที่ต้านทานต่อการเปลี่ยนแปลงการปรับปรุงและนวัตกรรม (ผู้จัดการไม่เปิดให้มีการเปลี่ยนแปลงแม้ว่าคุณจะเป็นนักพัฒนาให้ข้อโต้แย้งของผลประโยชน์ที่แข็งแกร่ง) บริษัท มีคู่แข่งน้อยในเขตข้อมูล (ผลิตภัณฑ์ของพวกเขาน้อยมีวิธีการแข่งขันเพิ่มเติม) แต่อย่างใด บริษัท ได้รักษาลูกค้าปัจจุบันสำหรับปี
การขาดการประสานงานการจัดการโครงการ: ด้วยเหตุนี้ทำให้บางโครงการส่งมอบล่าช้าด้วยบั๊กและลูกค้าบางคนบ่น (ลูกค้ารายงานข้อผิดพลาดด้วย) หรืองบประมาณถูกใช้เร็วเกินไปก่อนส่งมอบโครงการ ฯลฯ ฉันให้พวกเขา เคล็ดลับการประสานงานโครงการสองสามข้อและแนวคิดต่างๆได้ถูกนำไปใช้อย่างสม่ำเสมอเพื่อติดตามความคืบหน้าของโครงการและงานที่ต้องทำ
แนวทางปฏิบัติในการพัฒนาซอฟต์แวร์ที่ไม่ดี: กลิ่นของรหัสถูกพบในไฟล์ส่วนใหญ่หากไม่ใช่ไฟล์ทั้งหมด, ไม่มีเอกสาร, ความซ้ำซ้อนของรหัส, ระดับหน้าส่วนท้ายและส่วนหลังรวมกันในไฟล์เดียวกัน, เครื่องมือพัฒนาที่ล้าสมัย, ไม่มีสภาพแวดล้อมการทดสอบจริง ๆ ไฟล์จากสภาพแวดล้อม dev สู่การใช้งานจริงจากนั้นทดสอบด้วยตนเองว่าสิ่งต่าง ๆ ดูดีและมีการเปิดตัว) เครื่องมือการพัฒนาส่วนใหญ่ที่ฉันใช้สำหรับการพัฒนาและการทดสอบที่ไม่รู้จักโดยทีมเนื่องจากทีมใช้ IDE 2 ตัวเท่านั้นสำหรับการพัฒนาโค้ดและการควบคุมซอร์สนั้นมีให้สำหรับสภาพแวดล้อมการพัฒนาเท่านั้น นักพัฒนาคนอื่นพยายามใช้เฟรมเวิร์กล่าสุดเพื่อปรับปรุงปัญหาในปัจจุบัน แต่ผู้จัดการไม่ชอบเพราะ "ถ้าคุณออกไปแล้วใครจะเป็นผู้ดูแลรหัสนั้น? ลองปล่อยให้มันเป็นแบบนี้" นักพัฒนาบางคนแล้ว ออกไปและย้ายไปที่ บริษัท อื่น
โดยสรุปแล้วฉันมั่นใจว่าสถานการณ์ที่คล้ายคลึงกันเกิดขึ้นกับผู้พัฒนาจำนวนมากใน บริษัท อื่น แต่เนื่องจากสถานการณ์ต่าง ๆ ผู้พัฒนาอาจต้องการอยู่ในทีมมากกว่าไปที่ บริษัท อื่นด้วยเหตุผลเช่น (ความสะดวกในการทำงานความยืดหยุ่นในการทำงานผลประโยชน์ของ บริษัท หรือ เพียงเพราะโอกาสที่ดีกว่ายังไม่มาถึง) ไม่มี บริษัท ที่สมบูรณ์แบบที่ฉันรู้ แต่คุณจะทำอย่างไรในฐานะนักพัฒนาที่ทำงานและเข้าถึงปัญหาเหล่านี้เพื่อให้สิ่งต่าง ๆ เป็นไปในทางบวกและในที่สุดก็ส่งเสริมการเปลี่ยนแปลงเพื่อปรับปรุงผลิตภัณฑ์และปรับปรุงกระบวนการพัฒนาซอฟต์แวร์ให้ดีขึ้น ประสบการณ์การพัฒนาปีหรือเพียงไม่กี่)? ฉันรู้ว่าโพสต์นี้มีความยาว แต่ฉันต้องการให้รายละเอียดเพิ่มเติมเพื่อเพิ่มโอกาสในการรับข้อเสนอแนะที่เป็นประโยชน์มากขึ้น
ขอบคุณมากสำหรับทุกความคิดเห็นและเวลาของคุณ