ทีมพัฒนาซอฟต์แวร์ละทิ้งการแก้ปัญหาเชิงสร้างสรรค์ เปลี่ยนมาเป็นการประมวลผลงานแบบไร้สมอง

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

ความตายของความเป็นอิสระของนักพัฒนา

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

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

Product Manager: บทบาทที่รวมหน้าที่ของนักวิเคราะห์ธุรกิจแบบดั้งเดิมเข้ากับความรับผิดชอบในการเป็นเจ้าของผลิตภัณฑ์ โดยมักจะไม่มีความรู้ทางเทคนิคเชิงลึก

ไทม์ไลน์ของการเปลี่ยนแปลงบทบาทในการพัฒนาซอฟต์แวร์:

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

การเพิ่มขึ้นของผู้ตัดสินใจที่ไม่ใช่ด้านเทคนิค

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

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

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

การพัฒนาบทบาทในทีมซอฟต์แวร์:

• แบบดั้งเดิม: ผู้เชี่ยวชาญเฉพาะด้าน + นักวิเคราะห์ธุรกิจ + การออกแบบที่นำโดยนักพัฒนา
• แบบสมัยใหม่: Product Managers (รวมหลายบทบาทเข้าด้วยกัน) + นักออกแบบ UX/UI + นักพัฒนา (ทำหน้าที่เพียงการพัฒนาเท่านั้น)
• ผลกระทบ: ใช้คนและง예산มากขึ้น 10 เท่า แต่มีโอกาส 75% ที่จะได้ผลลัพธ์ระดับปานกลาง

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

การกัดเซาะของงานฝีมือ

สิ่งที่สูญหายไปในการเปลี่ยนแปลงนี้ไปไกลกว่าประสิทธิภาพ มันคือธรรมชาติพื้นฐานของการพัฒนาซอฟต์แวร์ในฐานะวินัยการแก้ปัญหาเชิงสร้างสรรค์ นักพัฒนาอธิบายว่ารู้สึกขาดการเชื่อมโยงกับงานของตน ปฏิบัติต่อโค้ดเป็นสิ่งที่เป็นของคนอื่นมากกว่าการภาคภูมิใจในงานฝีมือของตน

ฉันชอบอาชีพของฉันน้อยลงเรื่อยๆ ในช่วง 10 ปีที่ผ่านมา เพราะฉันเห็นทุกบริษัทไปในทิศทางนี้

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

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

สัญญาณของการพัฒนาแบบขับเคลื่อนด้วยตั๋ว:

• ไม่เข้าใจจุดประสงค์ของฟีเจอร์นอกเหนือจากกำหนดเวลาส่งมอบ
• Pull request ได้รับการอนุมัติโดยไม่มีการอภิปราย
• หนี้ทางเทคนิคถูกเพิกเฉยจนกว่าจะเกิดเหตุฉุกเฉิน
• การปรับปรุงทั้งหมดต้องการตั๋วและการอนุมัติแยกต่างหาก
• วิศวกรมองโค้ดเป็นของคนอื่น

คำสัญญาเท็จของความเร็ว

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

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

การค้นหาเส้นทางไปข้างหน้า

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

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

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

อ้างอิง: Ticket-Driven Development: The Fastest Way to Go Nowhere