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

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

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

ตำนานของการทำงานหลายอย่างพร้อมกันและความโกลาหลในการจัดลำดับความสำคัญ

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

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

สัญญาณของปัญหาผลิตภาพที่เกิดจากการจัดการ:

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

เครื่องมือที่สร้างงานมากขึ้น ไม่ใช่น้อยลง

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

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

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

หมวดหมู่เครื่องมือเพิ่มประสิทธิภาพทั่วไป:

  • เครื่องมือเพิ่มประสิทธิภาพที่แท้จริง: ระบบควบคุมเวอร์ชัน คอมไพเลอร์ IDE ระบบติดตามบัก - งานจะหยุดชะงักหากเครื่องมือเหล่านี้หายไป
  • เครื่องมือตรวจสอบความรับผิดชอบ: Asana , Trello , Jira - ทีมงานสามารถทำงานได้โดยไม่ต้องใช้เครื่องมือเหล่านี้เป็นระยะเวลานาน
  • ภาระงานด้านการบริหาร: แพลตฟอร์มการจัดการโครงการมักจะเพิ่มงานพิเศษมากกว่าที่จะลดงานลง

ปัญหาโรงงานฟีเจอร์

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

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

ช่องว่างความรับผิดชอบของผู้นำ

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

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

บทสรุป

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

อ้างอิง: THRASHING