การประชุมทีมที่มีประสิทธิภาพ

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

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

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

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

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

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

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

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

ใน Retros ที่ผมทำงานเราจะมีสามคอลัมน์บนไวท์บอร์ดมักจะวางยิ้ม Meh และหน้าเศร้าที่ด้านบนเช่น:), และ:| :(จากนั้นสมาชิกในทีมจะได้รับทุกสิ่งบนกระดานที่พวกเขาต้องการพูดคุยกับทั้งกลุ่ม

ในคอลัมน์ความสุขคุณสามารถเฉลิมฉลองความสำเร็จ (เช่นแสดงความยินดีกับอลิซและบ็อบในการเปิดตัวโครงการที่พวกเขาทำงานด้วยกัน) และคุณสามารถประกาศชัยชนะด้วยกระบวนการใหม่ที่คุณพยายาม (เช่นตัวติดตามบั๊กใหม่นั้นดีกว่า อันเก่า).

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

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

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

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

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

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

ยินดีต้อนรับสู่โลกของผู้บริหารระดับกลาง!

คุณจะพบปัญหาประเภทนี้เกิดขึ้นมากมาย!

คุณมี 3 ตัวเลือก:

บิ๊กสติ๊ก ทำอย่างนี้หรือคุณถูกไล่ออก - ไม่ทำงาน อย่าทำมัน

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

พูดไม่ได้พูด จากสิ่งที่คุณพูดทุกคนเบื่อแล้วทำไมไม่ถามพวกเขาว่า? คุณเบื่อไหม ? / นี่เป็นการเสียเวลา ฯลฯ ทำไมเราถึงได้ยิน คุณค่าของสิ่งนี้คืออะไร?

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

ลองให้นักพัฒนามีค่ามากขึ้นในการประชุมของคุณ ตัวอย่างบางส่วนอาจเป็น:

• การสาธิตสั้น ๆ แสดงคุณสมบัติใหม่ที่พัฒนาขึ้นในการวิ่งล่าสุด (นำเสนอโดยทุกคน)
• การอภิปรายในบทเรียนที่พวกเขามีโอกาสที่จะเปลี่ยนวิธีการทำงานของทีมและปรับปรุง (การอภิปรายนำมือขวาของคุณในทีมและคุณอยู่ที่นั่นเพื่อปรับการตัดสินใจการจัดการของคุณคล้ายกับเซสชั่นแบบ 1 ต่อ 1 แต่ใหญ่กว่า)
• การบรรยายเกี่ยวกับโครงการโอเพนซอร์สใหม่ที่อาจเกี่ยวข้องหรือภาษาการเขียนโปรแกรมที่แตกต่างกันเช่นฟังก์ชั่น Lang หรือ Golang หรือเธรดสีเขียวในหลาม (อาจนำเสนอโดยหนึ่งในนักพัฒนาที่อายุน้อยกว่าหรือในรูปแบบของวิดีโอออนไลน์)
• การอภิปรายที่นำโดยวิศวกรฝ่ายขายอธิบายถึงปัญหาทางวิศวกรรมที่ยากมากที่ลูกค้าของเขาพยายามแก้ไข (ข้อตกลงเดียวกันกับผู้จัดการฝ่ายสนับสนุน / บริการพยายามลดต้นทุนการสนับสนุนโดยการปรับปรุงการใช้งานผลิตภัณฑ์)
• รางหญ้าที่แสดงให้เห็นถึงกลยุทธ์ทางเลือกต่าง ๆ ที่ บริษัท สามารถดำเนินการได้และวิธีการที่จะส่งผลกระทบต่องานวิศวกรรมในแนวการแข่งขัน
• ที่ปรึกษาภายนอกที่ให้ช่วงการให้คำปรึกษาเกี่ยวกับเทคโนโลยีที่คุณใช้อยู่แล้ว แต่ไม่ใช้สูงสุด (โดยปกติคือ nosql, cep, RDBMS, ระบบเครือข่าย, ความปลอดภัย, การตรวจสอบ ... )
• โค้ดที่ทุกคนสามารถเรียนรู้การเข้ารหัสใหม่หรือการดีบักหรือทดสอบเคล็ดลับการเพิ่มประสิทธิภาพ (โดยผู้พัฒนาที่มีประสิทธิภาพการผลิต 10x)
• เซสชันการเข้ารหัสที่ไม่อนุญาตให้ใช้เมาส์ เรียนรู้ทางลัด IDE อย่างรวดเร็ว
• พูดคุยโดยนักบัญชีเรื่องเงิน 101 ปัญหาที่เกี่ยวข้องกับบำนาญการลงทุน
• พูดคุยเกี่ยวกับการเขียนโปรแกรมทางสังคมและอาชีพ (การแลกเปลี่ยนสแต็คทวิตเตอร์ github บล็อกส่วนตัว LinkedIn การพบปะในพื้นที่ของคุณ)

สามารถประชุมหรือถือมันน้อยกว่ามาก เขียนการบรรยายของคุณในอีเมลปกติและส่งให้ทุกคน

มีการประชุมถ้าผู้คนในนั้นมีเหตุผลที่จะเข้าร่วมเท่านั้น มิฉะนั้นคุณจะเสียเวลาของคนจริงๆ

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

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

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

ใช้แนวทางเกี่ยวกับวิธีการจัดการโครงการของคุณและส่งเสริมแนวทางการพัฒนาที่ดีโดยนำตัวอย่าง