The Surgical Team

การศึกษาเหล่านี้เผยให้เห็นความแตกต่างมหาศาลระหว่างบุคคลของผู้ปฏิบัติงานที่มีผลงานดีเยี่ยมและแย่ ซึ่งบ่อยครั้งความแตกต่างนั้นสูงถึงสิบเท่า (order of magnitude)

— SACKMAN, ERIKSON, AND GRANT!

UPI Photo/The Bettman Archive

ในการประชุมสมาคมคอมพิวเตอร์ เรามักจะได้ยินผู้จัดการโครงการซอฟต์แวร์รุ่นใหม่ยืนยันอยู่เสมอว่าพวกเขาชอบ "ทีม (team) ขนาดเล็กที่เฉียบคมและเต็มไปด้วยคนระดับแนวหน้า" มากกว่า "โครงการ (project) ที่มี programmers นับร้อย" ซึ่งโดยนัยแล้วสื่อถึงกลุ่มคนที่ฝีมือธรรมดาๆ เราทุกคนก็คิดเช่นนั้นเหมือนกัน แต่คำกล่าวที่ไร้เดียงสานี้เป็นการเลี่ยงปัญหาที่ยากกว่า นั่นคือ—เราจะสร้างระบบขนาดใหญ่ตาม schedule ที่มีความหมายและเป็นไปได้จริงได้อย่างไร? ให้เรามาดูรายละเอียดของแต่ละด้านของคำถามนี้กัน

The Problem

ผู้จัดการโครงการซอฟต์แวร์ทราบดีมานานแล้วว่ามีความแตกต่างของผลิตภาพ (productivity) อย่างมหาศาลระหว่าง programmers ที่เก่งและที่ด้อยฝีมือ แต่ขนาดของความแตกต่างที่วัดได้จริงนั้นทำให้พวกเราทุกคนต้องตกตะลึง ในการศึกษาครั้งหนึ่งของ Sackman, Erikson และ Grant พวกเขาได้วัดผลการทำงานของกลุ่ม programmers ที่มีประสบการณ์ ภายในกลุ่มนี้กลุ่มเดียว อัตราส่วนระหว่างผลงานที่ดีที่สุดและแย่ที่สุดเฉลี่ยอยู่ที่ประมาณ 10:1 ในการวัดผลิตภาพ และที่น่าทึ่งคือ 5:1 ในการวัดความเร็วของโปรแกรมและพื้นที่หน่วยความจำที่ใช้! พูดง่ายๆ คือ programmer ที่มีเงินเดือน 20,000 ดอลลาร์ต่อปี อาจมีผลิตภาพสูงกว่าคนที่ได้รับ 10,000 ดอลลาร์ต่อปีถึง 10 เท่า และในทางกลับกันก็อาจเป็นจริงได้เช่นกัน ข้อมูลยังแสดงให้เห็นว่าไม่มีความสัมพันธ์ใดๆ ระหว่างประสบการณ์และผลงาน (ผมสงสัยว่าสิ่งนี้จะเป็นจริงในทุกกรณีหรือไม่)

ผมได้แย้งไว้ก่อนหน้านี้ว่าจำนวนของจิตใจที่ต้องประสานงานกันนั้นส่งผลต่อต้นทุนของความพยายาม เพราะส่วนสำคัญของต้นทุนคือการสื่อสารและการแก้ไขผลเสียที่เกิดจากการสื่อสารที่ผิดพลาด (system debugging) สิ่งนี้ยังชี้ให้เห็นว่าเราต้องการให้ระบบถูกสร้างขึ้นโดยใช้จำนวนคนให้น้อยที่สุดเท่าที่จะเป็นไปได้ อันที่จริง ประสบการณ์ส่วนใหญ่กับระบบการเขียนโปรแกรมขนาดใหญ่แสดงให้เห็นว่าวิธีการแบบใช้กำลังเข้าว่า (brute-force approach) นั้นมีต้นทุนสูง ช้า ไร้ประสิทธิภาพ และสร้างระบบที่ไม่สอดคล้องกันในเชิงแนวคิด (conceptually integrated) ไม่ว่าจะเป็น OS/360, Exec 8, Scope 6600, Multics, TSS, SAGE ฯลฯ รายชื่อเหล่านี้ยาวเหยียดออกไปไม่สิ้นสุด

ข้อสรุปนั้นง่ายมาก: หากโครงการที่มีคน 200 คน มีผู้จัดการ 25 คนที่เป็น programmers ที่มีความสามารถและมีประสบการณ์มากที่สุด ให้ไล่ลูกทีมอีก 175 คนออก แล้วส่งผู้จัดการกลับไปเขียนโปรแกรมซะ

ทีนี้ลองพิจารณาแนวทางนี้ดู ในแง่หนึ่ง มันไม่สามารถเข้าใกล้ภาพในอุดมคติของ small sharp team ได้ ซึ่งโดยทั่วไปมีความเห็นพ้องกันว่าไม่ควรเกิน 10 คน มันใหญ่จนต้องมีระดับการบริหารจัดการอย่างน้อยสองระดับ หรือผู้จัดการประมาณห้าคน นอกจากนี้ยังต้องการการสนับสนุนด้านการเงิน บุคลากร สถานที่ เลขานุการ และเจ้าหน้าที่ควบคุมเครื่อง ในอีกแง่หนึ่ง ทีมที่มี 200 คนตั้งแต่แรกนั้นยังไม่ใหญ่พอที่จะสร้างระบบที่ใหญ่จริงๆ ด้วยวิธีการแบบ brute-force ได้ ลองพิจารณา OS/360 เป็นตัวอย่าง ในช่วงที่พีคที่สุด มีคนทำงานมากกว่า 1,000 คน—ทั้ง programmers นักเขียน, เจ้าหน้าที่ควบคุมเครื่อง, เสมียน, เลขานุการ, ผู้จัดการ, กลุ่มสนับสนุน และอื่นๆ ตั้งแต่ปี 1963 ถึง 1966 มีความพยายามรวมประมาณ 5,000 คน-ปี (man-years) ที่ทุ่มเทให้กับการออกแบบ การสร้าง และการทำเอกสารประกอบ หากใช้ทีม 200 คนตามที่สมมติไว้ข้างต้น จะต้องใช้เวลาถึง 25 ปีเพื่อให้ผลิตภัณฑ์มาถึงระดับปัจจุบัน หากคนและเดือนสามารถแลกเปลี่ยนกันได้อย่างเท่าเทียม!

นี่คือปัญหาของแนวคิด small, sharp team: มันช้าเกินไปสำหรับระบบที่ใหญ่จริงๆ ลองพิจารณางาน OS/360 หากต้องจัดการด้วยทีมขนาดเล็กที่เฉียบคม สมมติว่าเป็นทีมที่มี 10 คน เพื่อให้เห็นขอบเขตที่ชัดเจน ให้พวกเขามีผลิตภาพสูงกว่า programmers ทั่วไปถึงเจ็ดเท่าทั้งในด้านการเขียนโปรแกรมและการทำเอกสารประกอบ เพราะพวกเขาเฉียบคม สมมติว่า OS/360 ถูกสร้างขึ้นโดย programmers ทั่วไปเท่านั้น (ซึ่งห่างไกลจากความจริงมาก) และสมมติว่าปัจจัยการปรับปรุงผลิตภาพอีกเจ็ดเท่ามาจากการลดการสื่อสารเนื่องจากเป็นทีมขนาดเล็ก และสมมติว่าทีมเดิมนี้ทำงานตั้งแต่ต้นจนจบงาน เมื่อคำนวณแล้ว 5,000 / (10 x 7 x 7) = 10; พวกเขาสามารถทำงาน 5,000 คน-ปีให้เสร็จได้ใน 10 ปี

แต่ผลิตภัณฑ์นั้นจะยังน่าสนใจอยู่หรือไม่ในอีก 10 ปีหลังจากเริ่มออกแบบครั้งแรก? หรือมันจะล้าสมัยไปแล้วด้วยเทคโนโลยีซอฟต์แวร์ (software technology) ที่พัฒนาอย่างรวดเร็ว?

ภาวะกลืนไม่เข้าคายไม่ออกนี้ช่างโหดร้าย เพื่อประสิทธิภาพและความสอดคล้องทางแนวคิด (conceptual integrity) เราย่อมชอบให้คนเก่งเพียงไม่กี่คนเป็นผู้ออกแบบและสร้างงาน ทว่าสำหรับระบบขนาดใหญ่ เรากลับต้องการวิธีที่จะระดมกำลังคน (manpower) จำนวนมากเข้ามาจัดการ เพื่อให้ผลิตภัณฑ์สามารถเปิดตัวได้ทันเวลา เราจะทำให้ความต้องการทั้งสองประการนี้สอดคล้องกันได้อย่างไร?

Mills's Proposal

ข้อเสนอโดย Harlan Mills มอบแนวทางแก้ไขที่สดใหม่และสร้างสรรค์ Mills เสนอว่าแต่ละส่วนของงานขนาดใหญ่ควรได้รับการจัดการโดยทีม แต่ทีมนั้นควรได้รับการจัดองค์กรเหมือนกับ "ทีมผ่าตัด" (surgical team) มากกว่าจะเป็น "ทีมชำแหละหมู" กล่าวคือ แทนที่สมาชิกแต่ละคนจะต่างคนต่างหั่นส่วนแบ่งของปัญหาไปทำ แต่ควรมีเพียงคนเดียวที่ทำหน้าที่ "ผ่าตัด" และคนอื่นๆ ทำหน้าที่สนับสนุนเขาทุกวิถีทางเพื่อเพิ่มพูนประสิทธิผลและผลิตภาพ (productivity) ของเขา

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

ศัลยแพทย์ (The surgeon): Mills เรียกเขาว่าหัวหน้านักเขียนโปรแกรม (chief programmer) เขาเป็นผู้กำหนด specifications ทั้งในด้านหน้าที่และการทำงานด้วยตนเอง ออกแบบโปรแกรม เขียนโค้ด ทดสอบ และเขียนเอกสารประกอบ เขาเขียนโปรแกรมด้วยภาษาโปรแกรมแบบมีโครงสร้าง (structured programming language) เช่น PL/I และสามารถเข้าถึงระบบคอมพิวเตอร์ได้อย่างมีประสิทธิภาพ ซึ่งไม่เพียงแต่รันการทดสอบของเขาเท่านั้น แต่ยังเก็บรักษาโปรแกรมเวอร์ชันต่างๆ ของเขา ช่วยให้อัปเดตไฟล์ได้ง่าย และมีเครื่องมือแก้ไขข้อความสำหรับเอกสารประกอบของเขาด้วย เขาต้องการพรสวรรค์ที่ยิ่งใหญ่ ประสบการณ์สิบปี และความรู้อย่างมากในด้านระบบและแอปพลิเคชัน ไม่ว่าจะเป็นในด้านคณิตศาสตร์ประยุกต์ การจัดการข้อมูลธุรกิจ หรือด้านอื่นๆ

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

ผู้บริหารจัดการ (The administrator): ศัลยแพทย์ (surgeon) คือหัวหน้า และเขาต้องมีอำนาจตัดสินใจเด็ดขาดในเรื่องบุคลากร (personnel) การขึ้นเงินเดือน สถานที่ และอื่นๆ แต่เขาต้องไม่เสียเวลาไปกับเรื่องเหล่านี้เลย ดังนั้นเขาจึงต้องการผู้บริหารจัดการมืออาชีพที่ทำหน้าที่ดูแลเรื่องเงิน คน สถานที่ และเครื่องจักร และเป็นผู้ประสานงานกับหน่วยงานบริหารส่วนอื่นๆ ขององค์กร Baker เสนอว่าผู้บริหารจัดการจะมีงานเต็มเวลาได้ก็ต่อเมื่อโครงการนั้นมีข้อกำหนดทางกฎหมาย สัญญา การรายงาน หรือทางการเงินที่สำคัญเนื่องจากความสัมพันธ์ระหว่างผู้ใช้และผู้ผลิต มิฉะนั้น ผู้บริหารจัดการคนเดียวก็สามารถดูแลสองทีมได้

บรรณาธิการ (The editor): ศัลยแพทย์มีหน้าที่สร้างเอกสารประกอบ (documentation) เพื่อความชัดเจนสูงสุดเขาต้องเป็นผู้เขียนมันเอง ไม่ว่าจะเป็นคำอธิบายภายนอกหรือภายใน อย่างไรก็ตาม บรรณาธิการจะนำร่างหรือต้นฉบับ (manuscript) ที่ศัลยแพทย์จัดทำไว้มาวิจารณ์ ปรับปรุงใหม่ ใส่ข้อมูลอ้างอิงและบรรณานุกรม ดูแลผ่านหลายๆ เวอร์ชัน และกำกับดูแลขั้นตอนการผลิตทั้งหมด

เลขานุการสองคน (Two secretaries): ผู้บริหารจัดการและบรรณาธิการต่างต้องการเลขานุการคนละหนึ่งคน โดยเลขานุการของผู้บริหารจัดการจะดูแลเรื่องการโต้ตอบในโครงการและไฟล์ที่ไม่เกี่ยวกับตัวผลิตภัณฑ์

เสมียนโปรแกรม (The program clerk): เขามีหน้าที่รักษาบันทึกทางเทคนิคทั้งหมดของทีม (team) ไว้ในคลังผลิตภัณฑ์โปรแกรม (programming-product library) เสมียนจะได้รับการฝึกฝนมาอย่างดีแบบเลขานุการ และมีความรับผิดชอบต่อทั้งไฟล์ที่เครื่องอ่านได้และไฟล์ที่มนุษย์อ่านได้ ข้อมูลนำเข้าคอมพิวเตอร์ทั้งหมดจะส่งไปที่เสมียน ซึ่งเขาจะลงบันทึกและป้อนข้อมูลหากจำเป็น รายการข้อมูลส่งออกจะกลับมาที่เขาเพื่อจัดเก็บและทำดัชนี ผลการรันล่าสุดของโมเดลใดๆ จะถูกเก็บไว้ในสมุดบันทึกสถานะ ส่วนผลการรันก่อนหน้าทั้งหมดจะถูกจัดเก็บไว้ในจดหมายเหตุตามลำดับเวลา

สิ่งที่สำคัญอย่างยิ่งยวดต่อแนวคิดของ Mills คือการเปลี่ยนการเขียนโปรแกรม "จากศิลปะส่วนตัวไปสู่การปฏิบัติในที่สาธารณะ" โดยการทำให้สมาชิกทุกคนในทีมสามารถมองเห็นการรันคอมพิวเตอร์ทั้งหมด และระบุว่าโปรแกรมและข้อมูลทั้งหมดเป็นทรัพย์สินของทีม ไม่ใช่ทรัพย์สินส่วนบุคคล หน้าที่เฉพาะทางของเสมียนโปรแกรมจะช่วยแบ่งเบาภาระงานธุรการของ programmers ทำให้งานธุรการที่มักถูกละเลยเหล่านั้นเป็นระบบและมั่นใจได้ว่ามีการดำเนินการที่เหมาะสม และเสริมสร้างทรัพย์สินที่มีค่าที่สุดของทีม นั่นคือ ผลผลิตของงาน (work-product) เห็นได้ชัดว่าแนวคิดที่กล่าวมาข้างต้นสมมติให้ใช้การรันแบบแบตช์ (batch runs) เมื่อมีการใช้เทอร์มินัลแบบโต้ตอบ (interactive terminals) โดยเฉพาะอย่างยิ่งรุ่นที่ไม่มีข้อมูลส่งออกเป็นกระดาษ หน้าที่ของเสมียนโปรแกรมไม่ได้ลดน้อยลงไปเลย แต่กลับเปลี่ยนไป ตอนนี้เขาจะบันทึกการอัปเดตทั้งหมดของสำเนาโปรแกรมของทีมจากสำเนาส่วนบุคคลที่ใช้ทำงาน ยังคงจัดการการรันแบบแบตช์ทั้งหมด และใช้เครื่องมือแบบโต้ตอบของเขาเองเพื่อควบคุมความสมบูรณ์และความพร้อมใช้งานของผลิตภัณฑ์ที่กำลังเติบโตขึ้น

ช่างทำเครื่องมือ (The toolsmith): บริการแก้ไขไฟล์ แก้ไขข้อความ และ debugging แบบโต้ตอบได้กลายเป็นสิ่งที่หาได้ง่ายในปัจจุบัน จนทำให้ทีม (team) แทบไม่จำเป็นต้องมีเครื่องจักรและเจ้าหน้าที่ควบคุมเครื่องเป็นของตัวเองอีกต่อไป แต่บริการเหล่านี้จะต้องมีความเร็วในการตอบสนองและความน่าเชื่อถือที่น่าพึงพอใจอย่างไม่มีข้อสงสัย และศัลยแพทย์ (surgeon) จะต้องเป็นผู้ตัดสินเพียงผู้เดียวถึงความเพียงพอของบริการที่เขามี เขาต้องการช่างทำเครื่องมือเพื่อรับผิดชอบในการรับรองความเพียงพอของบริการพื้นฐานนี้ และสำหรับการสร้าง บำรุงรักษา และอัปเกรดเครื่องมือพิเศษ—ซึ่งส่วนใหญ่เป็นบริการคอมพิวเตอร์แบบโต้ตอบ—ที่ทีมของเขาต้องการ แต่ละทีมจะต้องมีช่างทำเครื่องมือเป็นของตัวเอง ไม่ว่าบริการส่วนกลางจะยอดเยี่ยมและน่าเชื่อถือเพียงใด เพราะงานของเขาคือการดูแลเครื่องมือที่ศัลยแพทย์ของเขาต้องการหรือปรารถนา โดยไม่ต้องคำนึงความต้องการของทีมอื่น ช่างสร้างเครื่องมือมักจะสร้างโปรแกรมอรรถประโยชน์เฉพาะทาง (specialized utilities), กระบวนงานที่จัดหมวดหมู่ไว้ (catalogued procedures) และคลังคำสั่งแมโคร (macro libraries)

ผู้ทดสอบ (The tester): ศัลยแพทย์ต้องการคลังของกรณีทดสอบ (test cases) ที่เหมาะสมสำหรับการทดสอบชิ้นงานในขณะที่เขากำลังเขียน และสำหรับการทดสอบงานทั้งหมดในภายหลัง ดังนั้นผู้ทดสอบจึงเป็นทั้ง "คู่ปรับ" ผู้คิดค้นกรณีทดสอบระบบจาก specs หน้าที่การทำงาน และเป็น "ผู้ช่วย" ผู้คิดค้นข้อมูลการทดสอบสำหรับการทำ debugging ในแต่ละวัน นอกจากนี้เขายังต้องวางแผนลำดับการทดสอบและจัดเตรียม "นั่งร้าน" (scaffolding) ที่จำเป็นสำหรับการทดสอบส่วนประกอบ (component tests)

ผู้เชี่ยวชาญกฎเกณฑ์ภาษา (The language lawyer): เมื่อถึงยุคของภาษา Algol ผู้คนเริ่มตระหนักว่าในหน่วยงานคอมพิวเตอร์ส่วนใหญ่มักจะมีคนหนึ่งหรือสองคนที่หลงใหลในการเชี่ยวชาญความซับซ้อนของภาษาโปรแกรม และผู้เชี่ยวชาญเหล่านี้กลับกลายเป็นคนที่มีประโยชน์มากและได้รับคำปรึกษาอย่างกว้างขวาง พรสวรรค์ในด้านนี้ค่อนข้างแตกต่างจากของศัลยแพทย์ ซึ่งเป็นผู้ออกแบบระบบและคิดในเชิงของการแสดงแทนเป็นหลัก ผู้เชี่ยวชาญกฎเกณฑ์ภาษาสามารถหาวิธีที่ประณีตและมีประสิทธิภาพในการใช้ภาษาเพื่อทำสิ่งที่ยาก คลุมเครือ หรือซับซ้อน บ่อยครั้งที่เขาจำเป็นต้องทำการศึกษาเล็กๆ น้อยๆ (สองหรือสามวัน) เกี่ยวกับเทคนิคที่ดี ผู้เชี่ยวชาญกฎเกณฑ์ภาษาหนึ่งคนสามารถให้บริการศัลยแพทย์ได้สองหรือสามคน

นี่คือวิธีที่คน 10 คนอาจร่วมกันสร้างผลงานในบทบาทที่แยกแยะอย่างชัดเจนและเป็นเฉพาะทางในทีมเขียนโปรแกรมที่สร้างขึ้นตามโมเดลการผ่าตัด (surgical model)

How It Works

ทีม (team) ที่เพิ่งนิยามไปนั้นตอบโจทย์ความต้องการในหลายประการ คน 10 คน ซึ่ง 7 คนในนั้นเป็นมืออาชีพ กำลังทำงานร่วมกันเพื่อแก้ปัญหา แต่ระบบที่ได้คือผลผลิตจากจิตใจดวงเดียว—หรืออย่างมากที่สุดก็สองดวง ที่ทำงานสอดประสานเป็นหนึ่งเดียว (uno animo) สังเกตให้ดีถึงความแตกต่างระหว่างทีมที่มี programmers สองคนที่จัดองค์กรแบบดั้งเดิม กับทีมแบบศัลยแพทย์และนักบินผู้ช่วย (surgeon-copilot team)

อย่างแรก ในทีมแบบดั้งเดิม หุ้นส่วนจะแบ่งงานกัน และแต่ละคนจะรับผิดชอบในการออกแบบและการนำไปใช้งาน (implementation) ในส่วนของงานตนเอง ในขณะที่ทีมแบบศัลยแพทย์ ทั้งศัลยแพทย์ (surgeon) และนักบินผู้ช่วย (copilot) ต่างรับรู้ถึงการออกแบบทั้งหมดและโค้ดทั้งหมด สิ่งนี้ช่วยประหยัดแรงงานในการจัดสรรพื้นที่ การเข้าถึงดิสก์ และอื่นๆ อีกทั้งยังช่วยรับประกันความสอดคล้องทางแนวคิด (conceptual integrity) ของงานด้วย

อย่างที่สอง ในทีมแบบดั้งเดิม หุ้นส่วนมีฐานะเท่าเทียมกัน และความแตกต่างของดุลยพินิจที่ไม่อาจหลีกเลี่ยงได้จะต้องถูกนำมาพูดคุยหรือหาข้อสรุปแบบประนีประนอม เนื่องจากงานและทรัพยากรถูกแบ่งแยก ความแตกต่างในดุลยพินิจจึงจำกัดอยู่แค่ในส่วนของกลยุทธ์โดยรวมและการเชื่อมต่อประสานกัน แต่พวกมันมักจะถูกทำให้ซับซ้อนขึ้นด้วยความแตกต่างของผลประโยชน์—เช่น พื้นที่ของใครจะถูกนำไปใช้เป็นบัฟเฟอร์ (buffer) ในขณะที่ทีมแบบศัลยแพทย์จะไม่มีความแตกต่างของผลประโยชน์ และความแตกต่างของดุลยพินิจจะถูกตัดสินโดยศัลยแพทย์เพียงผู้เดียว ความแตกต่างสองประการนี้—คือการไม่แบ่งแยกตัวปัญหา และความสัมพันธ์แบบหัวหน้า-ลูกน้อง (superior-subordinate relationship)—ทำให้ทีมแบบศัลยแพทย์สามารถทำงานแบบเป็นน้ำหนึ่งใจเดียวกัน (uno animo) ได้

กระนั้นก็ตาม การแบ่งหน้าที่เฉพาะทางของสมาชิกส่วนที่เหลือในทีมคือหัวใจสำคัญของประสิทธิภาพ เพราะมันช่วยให้รูปแบบการสื่อสาร (communication pattern) ระหว่างสมาชิกเรียบง่ายขึ้นอย่างมาก ดังที่แสดงในรูปที่ 3.1