Team Warning Signs (สัญญาณเตือนของทีม)

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

Process Loss (การสูญเสียประสิทธิภาพจากกระบวนการ)

คำว่า process loss ถูกบัญญัติขึ้นโดย Fred Brooks ในหนังสือของเขาชื่อ The Mythical Man-Month (Addison-Wesley, 1995) แนวคิดพื้นฐานของ process loss หรือที่รู้จักกันในชื่อ Brooks's Law คือ ยิ่งคุณเพิ่มคนเข้าไปในโครงการมากเท่าไหร่ โครงการก็จะยิ่งใช้เวลานานขึ้นเท่านั้น ดังที่ Figure 24-7 แสดงให้เห็น group potential ถูกกำหนดโดยความพยายามร่วมกันของทุกคนในทีม อย่างไรก็ตาม Brooks ระบุว่าผลิตภาพ ที่แท้จริง ของทีมใดๆ ก็ตามจะน้อยกว่าผลิตภาพ ที่มีศักยภาพ ของมันเสมอ ส่วนต่างนี้เรียกว่า process loss ของทีม

Figure 24-7. Brooks's Law ระบุว่าขนาดของทีมส่งผลต่อผลิตภาพที่แท้จริงของทีม

Process loss เป็นปัจจัยที่ดีในการกำหนดขนาดทีมที่ถูกต้องสำหรับโครงการหนึ่งๆ และสถาปนิกซอฟต์แวร์ที่มีประสิทธิภาพจะคอยสังเกตทีมพัฒนา เพื่อหาสัญญาณของ process loss ตัวอย่างเช่น ถ้าสมาชิกในทีมเจอ merge conflict บ่อยครั้งเวลา push โค้ดขึ้น repository นั่นเป็นสัญญาณว่าพวกเขากำลังทำงานกับโค้ดชุดเดียวกันและอาจกำลังขวางทางกันเอง

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

Pluralistic Ignorance (ความไม่รู้ร่วมกันของกลุ่ม)

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

แนวคิดเรื่อง pluralistic ignorance กลายเป็นที่รู้จักผ่านนิทานเด็กชาวเดนมาร์กเรื่อง "The Emperor's New Clothes" โดย Hans Christian Andersen ในเรื่องนี้ นักต้มตุ๋นสองคนปลอมตัวเป็นช่างตัดเสื้อ หลอกกษัตริย์ว่าชุดใหม่ที่พวกเขา "ตัด" ให้พระองค์นั้น มองไม่เห็นสำหรับใครก็ตามที่ไม่คู่ควรจะเห็น กษัตริย์ผู้มองไม่เห็นชุดแต่ไม่ยอมรับว่าตัวเองอาจไม่คู่ควร จึงเดินอวดโฉมตัวเปล่าเปลือยไปทั่ว ถามราษฎรทุกคนว่าพวกเขาชอบชุดใหม่ของพระองค์แค่ไหน ราษฎรที่กลัวจะถูกมองว่าไม่คู่ควร ต่างยืนยันว่าชุดใหม่ของกษัตริย์นั้นดีที่สุด เรื่องราวความโง่เขลานี้ดำเนินต่อไปจนกระทั่งเด็กคนหนึ่งตะโกนออกมาว่ากษัตริย์ไม่ได้สวมเสื้อผ้าอะไรเลย

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

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

Figure 24-8 แสดงภาพคนคนหนึ่งยืนอยู่ข้างรถที่เสียอยู่ริมถนนในชนบท ในสถานการณ์นี้ จะมีคนกี่คนที่หยุดรถและถามคนขับว่าทุกอย่างเรียบร้อยดีไหม? เพราะเป็นถนนสายเล็ก มันคงอยู่ในชุมชนเล็กๆ ดังนั้นทุกคนที่ผ่านมาอาจจะหยุดช่วย แต่ถ้าคนขับคนเดียวกันนี้ติดอยู่ริมทางหลวงที่พลุกพล่าน ในเมืองใหญ่ล่ะ? รถหลายพันคันอาจแค่ขับผ่านไปโดยไม่มีใครหยุดถามว่าทุกอย่างโอเคไหม นี่เป็นตัวอย่างที่ดีของ diffusion of responsibility ยิ่งเมืองพลุกพล่านและแออัดมากขึ้นเท่าไหร่ คนก็ยิ่งคิดว่าคนขับได้โทรขอความช่วยเหลือไปแล้ว หรือคิดว่าคนอื่นในฝูงชนที่เห็นเหตุการณ์ จะเข้าไปช่วยเอง อย่างไรก็ตาม ในกรณีส่วนใหญ่ ความช่วยเหลือมักไม่มาถึง และคนขับก็ติดอยู่กับมือถือที่แบตหมดหรือถูกลืมไว้

Figure 24-8. Diffusion of responsibility

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