นักพัฒนาที่หมุนอยู่ในโครงการเป็นแนวคิดที่ดีหรือไม่ดีใช่หรือไม่

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

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

ฉันต้องการทราบถึงประโยชน์และข้อเสียของการหมุนผู้พัฒนาจากโครงการทุก 2-3 เดือน

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

ฉันประหลาดใจที่ทุกคนคิดว่านี่เป็นสิ่งที่ดี ผู้เขียนPeopleware (ซึ่ง IMO ยังคงเป็นหนึ่งในหนังสือการจัดการโครงการซอฟต์แวร์ที่มีค่าเพียงไม่กี่เล่มที่ควรค่าแก่การอ่าน) ไม่เห็นด้วยอย่างยิ่ง เกือบทั้งหมดของเล่ม IV อุทิศให้กับเรื่องนี้มาก

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

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

ตอนนี้คุณอาจพูดว่า "โอ้ แต่เราไม่ได้เลิกทั้งทีมแค่ขยับคนไม่กี่คน" แต่ให้พิจารณา (ก) ว่าการที่พวกเขาไม่สามารถทดแทนคนตาบอดได้อย่างไรในตอนแรกและ (ข) กี่ครั้งที่คุณจะพบว่าตัวเองหรือทีมอื่นพูดโดยไม่คิดแม้แต่ว่า"ฉันชอบ X"หรือ"สิ่งนี้จะมี ง่ายขึ้นเมื่อ Y ยังคงอยู่รอบ ๆ " , สร้างความขุ่นเคืองให้กับสมาชิกใหม่อย่างละเอียดและไม่รู้ตัวและสร้างความแตกแยกภายในทีมที่มีอยู่แม้กระทั่งหว่านความไม่พอใจในหมู่สมาชิก" เก่า "

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

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

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

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

ฉันไม่เห็นข้อเสียของตัวเองมากนัก การหมุนทำให้คุณได้รับ:

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

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

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

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

ประโยชน์ที่เป็นไปได้สองประการที่ไม่ได้กล่าวถึง:

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

การหมุนเป็นสิ่งที่ดีสำหรับ บริษัท และอาจเป็นสิ่งที่ดีสำหรับนักพัฒนาเช่นกัน

มีเหตุผลที่ดีมากมายและไวแอตต์ได้พูดถึงพวกเขามากมายในคำตอบของเขา

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

มันอาจจะเป็นการดีถ้าคุณไม่เปลี่ยนทีมขายส่งเพื่อเริ่มต้นและหมุน 1 หรือ 2 devs เพื่อเริ่มต้นแม้ว่ามันอาจดูเหมือนว่าจะแยกแยะผู้คนออกจากการลงโทษ (ซึ่งบางคนอาจเห็น)

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

ฉันเห็นด้วยกับคำตอบที่ดีที่สุดของ Aaronaught และฉันมีบางส่วนเพิ่มเติม

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

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

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

เพียงแค่สับคนเพื่อกระจายความรู้มีแนวโน้มที่จะเพิ่มการหมุนเวียน วิธีนั้นจะกระจายความรู้ออกไป แต่มันจะกระจายออกไปนอก บริษัท ซึ่งอาจไม่ใช่เจตนา

TL; DR ทำให้เป็นหนึ่งทีมจากนั้นก็เป็นหนึ่งในทีมที่สนับสนุน 2 โครงการ

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

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

ประโยชน์ที่จะได้รับจากผู้คนในโครงการเป็นที่รู้จักกันดีเช่นเดียวกับค่าใช้จ่าย

การหมุนของโปรแกรมเมอร์เป็นสิ่งที่ดีจากมุมมองของ บริษัท และมุมมองของนักพัฒนา

จากมุมมองของ บริษัท

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

จากมุมมองของนักพัฒนา

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

สิ่งสำคัญเพียงข้อเดียวเท่านั้นที่ต้องจำไว้ว่า

การหมุนของโปรแกรมเมอร์ไม่ควรเกิดขึ้นบ่อยนัก หลังจากการพัฒนา 60% - 70% เสร็จแล้วการเลื่อนเท่านั้นจะเป็นประโยชน์