การต่อสู้: การจัดการขาดแรงจูงใจ


11

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


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

2
มันจะเป็นการดีถ้ามองหาเหตุผลที่อยู่เบื้องหลังการขาดแรงจูงใจ มีแนวโน้มที่จะมองข้ามปัจจัยมนุษย์ตั้งแต่ความขัดแย้งทางบุคลิกภาพภายในทีมไปจนถึงนโยบายทรัพยากรบุคคลขององค์กรที่ตำหนิมากกว่าการให้เครดิต (เช่น: "rank and yank")
jfrankcarr

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

คำตอบ:


14

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

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

ในความเป็นจริงนี่ไม่ใช่ Agile หรือ Scrum นี่เป็นเพียงการเปลี่ยนจากการจัดการรูปแบบหนึ่งไปสู่รูปแบบที่แตกต่างกันซึ่งทุกอย่างยังคงมีการควบคุมจากส่วนกลางและไม่เพียง แต่จะดูดชีวิตของฉันออกไปทั้งหมด เวลาที่จะอัปเดตประวัติของฉัน

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

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

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

4

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

กลุ่มของปัญหาเล็กน้อยสามารถเพิ่มขึ้นเพื่อ demotivating ตัวอย่างเช่นสิ่งหนึ่งที่เกิดขึ้นเมื่อสัปดาห์ที่แล้วคือสมาชิกในทีมที่ไม่ชอบการประชุม 4:00 แก้ไขได้อย่างง่ายดาย

กล่าวอีกนัยหนึ่งวิธีที่ดีที่สุดในการค้นหาว่าการลดทีมของคุณคือการถามพวกเขา


คุณไล่ออกสมาชิกในทีมที่ไม่ชอบการประชุม 4 โมงเย็นไหม? ;)
Dave Hillier

3

ด้วยการให้รหัสกรรมสิทธิ์แก่พวกเขา

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

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

ดูเพิ่มเติมที่: https://softwareengineering.stackexchange.com/a/33464/1204


ฉันจะเถียงเพื่อให้แน่ใจว่าสิ่งเหล่านี้เป็นพื้นที่การทำงานในแนวตั้งไม่ใช่พื้นที่โครงสร้างพื้นฐานแนวนอน คือสิ่งที่แย่ที่สุดที่คุณสามารถทำได้คือมี Guy UI, Backend Guy และ Guy ฐานข้อมูลเพราะสำหรับทุก ๆ ส่วนของฟังก์ชั่นการทำงานคุณจะต้องให้ทั้งสามคนทำงานร่วมกัน
Michael Brown

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

@pdr: คุณยกประเด็นที่น่าสนใจ ฉันคิดว่าฉันสามารถเรียนรู้ได้มากถ้าคุณกับ Robert Harvey ถกประเด็นนี้เพิ่มเติม
Jim G.

@JimG ดูคำตอบของ DXM สำหรับมุมมองที่ละเอียดและครอบคลุมมากขึ้น (ซึ่งฉันเห็นด้วยกับ)
Robert Harvey

1
@JimG มันเป็นความอัปยศบางครั้งที่เราไม่มีฟอรัม (การแชทอยู่ในทันทีเกินไปฉันไม่มีเวลาแบบนั้นที่จะอุทิศให้กับการสนทนา) ซึ่งเป็นนักพัฒนาที่มีประสบการณ์และสนใจจำนวนหนึ่งซึ่งประสบปัญหาแตกต่างกัน สามารถออกไปอภิปรายบางสิ่งและกลับมาพร้อมคำตอบที่รวมกัน ฉันสนใจสิ่งนี้เป็นพิเศษเพราะฉันไม่ค่อยเห็นด้วยกับคำตอบของ Robert ที่นี่และ (อาจน่าสนใจมากกว่า) เราได้เห็นด้วยกับคำตอบของ DXM
pdr
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.