วิธีจัดโครงสร้างทีมพัฒนา

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

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

• มีผู้พัฒนารุ่นเยาว์รายงานถึงรุ่นพี่ สิ่งนี้จะช่วยลดเวลาที่ใช้ในการพัฒนาโดยช่างที่ดีที่สุด
• แบ่งทีมตามผลิตภัณฑ์ซอฟต์แวร์เช่นนักพัฒนา 1-6 ทำงานบนอินทราเน็ตและทำงาน 7-11 ในไซต์ภายนอกโดยแต่ละส่วนจะมีผู้นำทีมใหม่ (อาจเป็นคำอธิบายงานใหม่ที่มีความรับผิดชอบด้านการจัดการ / ให้คำปรึกษา / ฝึกสอนมากกว่าผู้พัฒนาอาวุโสในปัจจุบัน ) นี่เป็นการเพิ่มไซโลประดิษฐ์และอาจทำให้ "นักพัฒนาอินทราเน็ต" ทำงานบนเว็บไซต์ภายนอกได้ยากหากฉันต้องการให้พวกเขาทำ
• รักษาโครงสร้างให้เรียบและเพิ่มการสนับสนุนด้านการจัดการในรูปของ Project Managers / Team Administrators เพียงเพื่อลดแรงกดดัน สิ่งนี้ไม่ได้แก้ปัญหาเนื่องจากทีมไม่สามารถเติบโตอย่างนี้ตลอดไป

มีวิธีมาตรฐานในการแก้ปัญหานี้ซึ่งฉันพลาดหรือไม่?

ถ้าไม่คุณมีคนอื่นในการแก้ไขปัญหานี้อย่างไร?

ความคิดสั้น ๆ บางอย่าง:

• ทีมย่อยเป็นแนวคิดที่ดี: 11 รายงานโดยตรงที่ไม่มีโครงสร้างใด ๆ ใหญ่เกินไปสำหรับทีมที่สามารถทำงานได้ (คุณไม่มีเวลาเพียงพอสำหรับการฝึกสอนโดยตรงและการประชุมทีมกับคนจำนวนมากมักจะไม่เกิดผล)
• พิจารณาแยกการดำเนินงานออกจากการพัฒนา - มันเป็นชุดทักษะที่แตกต่างกันเล็กน้อยและถูกขัดจังหวะโดยปัญหาการดำเนินงานตลอดทั้งวันสามารถเป็นอันตรายต่อผลผลิตการพัฒนาในโครงการอย่างจริงจัง
• จากสองประเด็นแรกฉันคิดว่าคุณน่าจะมี 3 กลุ่มย่อยนั่นคืออินทราเน็ตไซต์ภายนอกและการปฏิบัติการ ผู้ดำเนินการจะจัดการกับปัญหาในแต่ละวัน / การแก้ไขการบำรุงรักษา ฯลฯ ในขณะที่ทั้งสองทีมพัฒนามุ่งเน้นไปที่การส่งมอบโครงการ / คุณค่าใหม่ให้กับธุรกิจ
• หมุนเวียนผู้คนระหว่างทีมเป็นประจำ สิ่งนี้อาจเป็นครั้งคราว (เช่นให้ผู้คนทบทวนโค้ดในอีกกลุ่มย่อย) สำหรับโครงการหรือเป็นการถาวร แต่ให้แน่ใจว่าเข้าใจว่าบทบาทของทีมจะเปลี่ยนแปลงเมื่อใดก็ตามที่มีความต้องการทางธุรกิจไม่มีใคร "เป็นเจ้าของ" บทบาทที่เฉพาะเจาะจงตลอดไป
• อย่าเพิ่มผู้จัดการ / ผู้ดูแลระบบมากขึ้น - นี่เป็นวิธีที่แน่นอนในการลดประสิทธิภาพ / ประสิทธิผลโดยรวมของทีมของคุณ ให้บุคคลที่มีประสบการณ์มากที่สุดในแต่ละกลุ่มย่อยมีบทบาทเป็นหัวหน้าทีม / โค้ช ตรวจสอบให้แน่ใจว่าพวกเขาเห็นบทบาทของพวกเขาที่นี่ในฐานะผู้ฝึกสอนและทำให้ทั้งทีมประสบความสำเร็จและตรวจสอบให้แน่ใจว่าพวกเขาพร้อมที่จะประพฤติตนในลักษณะนี้แทนที่จะทำหน้าที่ "ผู้จัดการงาน"
• บทบาทของคุณควรมุ่งเน้นไปที่การจัดการผู้มีส่วนได้เสียภายนอกจัดลำดับความสำคัญของทรัพยากร / งานภายในกลุ่มและทำหน้าที่เป็น "หัวหน้าโค้ช" คุณจะต้องจัดการกับปัญหาที่เพิ่มขึ้นเป็นครั้งคราวจากทีมย่อย แต่โดยทั่วไปคุณควรสนับสนุนให้พวกเขาแก้ปัญหาด้วยตัวเองโดยไม่ต้องมาหาคุณ
• หากคุณมีความเชี่ยวชาญด้านเทคนิคสูงคุณอาจเลือกที่จะมีบทบาทในการรับประกันสถาปนิก / ออกแบบ ถ้าไม่พบคนที่สามารถทำได้ภายในทีมหรือที่อื่น ๆ .....

นอกจากนี้ก็คุ้มค่าเสมอไปและ (อีกครั้ง) อ่านเปรียวและโดยเฉพาะอย่างยิ่งหลักการสิบสอง

โครงสร้างนั้นส่วนใหญ่จะ depend on project specifications

ตามหลักแล้วควรมี 3 รุ่นต่อนักพัฒนาอาวุโสในทีม ดังนั้นจึงมีนักพัฒนาอาวุโส 2-3 คนต่อการสอนหลัก

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

หนึ่งในทีมพัฒนาซอฟต์แวร์ที่ค่อนข้างประสบความสำเร็จฉันเป็นส่วนหนึ่งของการทำงานแบบนี้ในแต่ละโครงการ:

ผู้จัดการฝ่ายพัฒนาซอฟต์แวร์ / ผู้พัฒนาอาวุโส / ที่ปรึกษาซึ่งทุกคนรายงานโดยตรง

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

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

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

หากต้องการอ้างอิงบทความในบริบทของคุณ:

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

โครงสร้างการจัดการ / ทรัพยากรบุคคลที่แท้จริงนั้นไม่เกี่ยวข้องเลยไปกว่านั้น

มีวิธีมาตรฐานในการแก้ปัญหานี้ซึ่งฉันพลาดหรือไม่?

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

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

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

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

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

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