Small Teams, Large Organization (ทีมเล็ก องค์กรใหญ่)

Adding manpower to a late software project makes it later.

Fred Brooks (Brooks's Law)

ใน เรียงความชื่อดังของเขา "The Mythical Man-Month," 6 ผู้เขียน Fred Brooks พยายามอธิบายว่าทำไมการใช้ "man-month" เป็นเทคนิคการประเมินงานถึงมีปัญหา เพราะมันทำให้เราตกหลุมพรางความคิดที่ว่าเราสามารถโยนคนเพิ่มเข้าไปแก้ปัญหาเพื่อให้เร็วขึ้นได้ ทฤษฎีมีอยู่ว่า ถ้างานชิ้นหนึ่งใช้เวลานักพัฒนาคนเดียวหกเดือน ถ้าเราเพิ่มนักพัฒนาคนที่สอง งานก็ควรจะใช้เวลาแค่สามเดือน ถ้าเราเพิ่มนักพัฒนาอีกห้าคน รวมเป็นหกคน งานก็ควรจะเสร็จภายในหนึ่งเดือน! แน่นอนว่าซอฟต์แวร์ไม่ได้ทำงานแบบนั้น

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

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

ต้นทุนที่ใหญ่ที่สุดในการทำงานอย่างมีประสิทธิภาพในระดับ scale สำหรับการส่งมอบซอฟต์แวร์ คือความจำเป็นในการประสานงาน ยิ่งมีการประสานงานระหว่างทีมที่ทำงานคนละงานมากเท่าไร คุณก็จะยิ่งช้าลงเท่านั้น Amazon ในฐานะบริษัทตระหนักถึงเรื่องนี้ และจัดโครงสร้างตัวเองเพื่อลดความจำเป็นในการประสานงานระหว่าง two-pizza team เล็กๆ ของตัวเอง อันที่จริงมีความพยายามอย่างจงใจในการจำกัดปริมาณการประสานงานระหว่างทีมด้วยเหตุผลนี้เอง และจำกัดการประสานงานนี้ไว้เฉพาะจุดที่จำเป็นจริงๆ เท่าที่เป็นไปได้—นั่นคือระหว่างทีมที่มีขอบเขตร่วมกันระหว่างไมโครเซอร์วิส จากหนังสือ Think Like Amazon , 7 โดย John Rossman อดีตผู้บริหารของ Amazon:

Two-Pizza Team เป็นทีมที่เป็นอิสระ การปฏิสัมพันธ์กับทีมอื่นมีจำกัด และเมื่อเกิดขึ้น ก็จะมีการบันทึกเป็นเอกสารอย่างดีและมี interface ที่ชัดเจน ทีมนี้เป็นเจ้าของและรับผิดชอบทุกแง่มุมของระบบของตัวเอง หนึ่งในเป้าหมายหลักคือการลด overhead ด้านการสื่อสารในองค์กร รวมถึงจำนวนการประชุม จุดประสานงาน การวางแผน การทดสอบ หรือการ release ทีมที่เป็นอิสระมากกว่าจะเคลื่อนที่ได้เร็วกว่า

การทำความเข้าใจ ว่าทีมหนึ่งๆ เข้ากับองค์กรที่ใหญ่กว่าอย่างไรนั้นสำคัญมาก Team Topologies ได้นิยามแนวคิดของ team API ซึ่งกำหนดในภาพรวมว่าทีมนั้นปฏิสัมพันธ์กับส่วนที่เหลือขององค์กรอย่างไร ไม่ใช่แค่ในแง่ของ interface ของไมโครเซอร์วิสเท่านั้น แต่รวมถึงในแง่ของแนวทางการทำงาน ด้วย: 8

team API ควรพิจารณาความสามารถในการใช้งานโดยทีมอื่นอย่างชัดเจน ทีมอื่นจะรู้สึกว่าปฏิสัมพันธ์กับเราง่ายและตรงไปตรงมาหรือไม่ หรือจะรู้สึกยากและสับสน ทีมใหม่จะเรียนรู้โค้ดและแนวทางการทำงานของเราได้ง่ายแค่ไหน เราตอบสนองต่อ pull request และข้อเสนอแนะจากทีมอื่นอย่างไร backlog และ roadmap ของผลิตภัณฑ์ของทีมเรามองเห็นและเข้าใจได้ง่ายสำหรับทีมอื่นหรือไม่