How Much Involvement? (ควรมีส่วนร่วมมากแค่ไหน?)

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

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

Team familiarity (ความคุ้นเคยของทีม)

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

Team size (ขนาดของทีม)

เราถือว่าทีมที่มีนักพัฒนามากกว่า 12 คนเป็นทีมใหญ่ และทีมที่มี 5 คนหรือน้อยกว่าเป็นทีมเล็ก ยิ่งทีมใหญ่เท่าไหร่ ก็ยิ่งต้องการสถาปนิกมากขึ้นเท่านั้น เราจะพูดถึงหัวข้อนี้ในรายละเอียดเพิ่มเติมใน "Team Warning Signs"

Overall experience (ประสบการณ์โดยรวม)

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

Project complexity (ความซับซ้อนของโครงการ)

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

Project duration (ระยะเวลาของโครงการ)

โครงการนี้สั้น (เช่น สองเดือน) ยาว (สองปี) หรือระยะเวลาปานกลาง (ประมาณหกเดือน)? การมีส่วนร่วมของสถาปนิกที่จำเป็นจะเพิ่มขึ้นตามความยาวของโครงการ

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

เพื่อแสดงให้เห็นวิธีใช้ปัจจัยเหล่านี้ในการกำหนดระดับการมีส่วนร่วมที่เหมาะสม สมมติว่ามีมาตราส่วนคงที่ 20 คะแนนสำหรับแต่ละปัจจัย ดังแสดงใน Figure 24-4 ฝั่งของมาตราส่วนที่มีค่าเป็นลบบ่งบอกถึงการมีส่วนร่วมน้อยลง จนถึงจุดสุดขั้วของสถาปนิกเก้าอี้นวม ส่วนค่าที่เป็นบวกบ่งบอกถึงการมีส่วนร่วมมากขึ้น จนถึงจุดสุดขั้วของสถาปนิกจอมควบคุม

Figure 24-4. มาตราส่วนสำหรับวัดปริมาณการมีส่วนร่วมของสถาปนิกกับทีมพัฒนา

มาตราส่วนนี้ไม่ใช่ค่าที่แม่นยำแน่นอน แต่มันช่วยในการกำหนดปริมาณการมีส่วนร่วมที่สถาปนิกควรมีกับทีมพัฒนา ตัวอย่างเช่น ลองพิจารณาสถานการณ์ตัวอย่างของโครงการ Scenario 1 ที่แสดงใน Table 24-1 และ Figure 24-5 ค่าของแต่ละปัจจัยในตารางจะขยับ "เข็ม" ไปทางฝั่งใดฝั่งหนึ่ง คือ +20 สำหรับปัจจัยที่บ่งบอกถึงการมีส่วนร่วมมากขึ้น และ -20 สำหรับปัจจัยที่บ่งบอกถึงการมีส่วนร่วมน้อยลง คะแนนของปัจจัยที่ประเมินไว้สำหรับ Scenario 1 รวมกันได้ -60 ซึ่งบ่งบอกว่าสถาปนิกควรจำกัดการมีส่วนร่วมในกิจกรรมประจำวัน อำนวยความสะดวกแต่คอยอยู่ห่างจากการทำงานของทีม พวกเขาจะจำเป็นต้องตอบคำถามและตรวจสอบว่าทีมยังอยู่ในแนวทางที่ถูกต้อง แต่ส่วนใหญ่แล้วสถาปนิกควรวางมือเป็นส่วนใหญ่และปล่อยให้ทีมที่มีประสบการณ์ ทำในสิ่งที่พวกเขาทำได้ดีที่สุด นั่นคือการพัฒนาซอฟต์แวร์อย่างรวดเร็ว

Table 24-1. ตัวอย่าง Scenario 1 สำหรับปริมาณการมีส่วนร่วม | Factor (ปัจจัย) | Value (ค่า) | Rating (คะแนน) | Personality (บุคลิก) | | --- | --- | --- | --- | | Team familiarity | สมาชิกในทีมเป็นคนใหม่ | +20 | Control freak | | Team size | เล็ก (4 คน) | -20 | Armchair architect | | Overall experience | มีประสบการณ์ทั้งหมด | -20 | Armchair architect | | Project complexity | ค่อนข้างเรียบง่าย | -20 | Armchair architect | | Project duration | 2 เดือน | -20 | Armchair architect | | | | | | | คะแนนสะสม | | -60 | Armchair architect |

Figure 24-5. ปริมาณการมีส่วนร่วมสำหรับ Scenario 1

ทีนี้ลองพิจารณา Scenario 2 ที่อธิบายไว้ใน Table 24-2 และแสดงใน Figure 24-6 ซึ่งสมาชิกในทีมรู้จักกันดี แต่ทีมมีขนาดใหญ่ (12 คน) และส่วนใหญ่เป็นนักพัฒนาระดับจูเนียร์ โครงการมีความซับซ้อนค่อนข้างสูง ใช้เวลาหกเดือน ในกรณีนี้ คะแนนสะสมออกมาที่ +20 ซึ่งบ่งบอกว่าสถาปนิกที่มีประสิทธิภาพควรรับบทบาทเป็นเมนเทอร์และโค้ช และมีส่วนร่วมค่อนข้างมากในกิจกรรมประจำวัน แต่ไม่มากจนไปรบกวนการทำงานของทีม

Table 24-2. ตัวอย่าง Scenario 2 สำหรับปริมาณการมีส่วนร่วม | Factor (ปัจจัย) | Value (ค่า) | Rating (คะแนน) | Personality (บุคลิก) | | --- | --- | --- | --- | | Team familiarity | รู้จักกันดี | -20 | Armchair architect | | Team size | ใหญ่ (12 คน) | +20 | Control freak | | Overall experience | ส่วนใหญ่เป็นจูเนียร์ | +20 | Control freak | | Project complexity | ซับซ้อนสูง | +20 | Control freak | | Project duration | 6 เดือน | -20 | Armchair architect | | | | | | | คะแนนสะสม | | +20 | Control freak |

Figure 24-6. ปริมาณการมีส่วนร่วมสำหรับ Scenario 2

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

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

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