คนเดียวหรือทีม? วิธีกำหนดทีมขั้นต่ำของโครงการจากทักษะ การพึ่งพา และความเสี่ยง

งานวิจัยไม่สนับสนุนกฎง่าย ๆ ว่า "ทีมเล็กดีกว่าเสมอ" หรือ "ทีมใหญ่ทำงานได้มากกว่าเสมอ".

การวิเคราะห์อภิมานในปี 2023 ซึ่งครอบคลุมผลอิสระ 208 รายการและทีม 21,435 ทีม พบว่าโดยรวมความสัมพันธ์ระหว่างขนาดทีมกับผลการทำงานแทบเป็นศูนย์ แต่มีความแตกต่างตามบริบทสูงมาก ผู้เขียนชี้ว่าความสำคัญของขนาดทีมเปลี่ยนไปตามปัจจัยอย่างความซับซ้อนของงานและความต้องการด้านการประสานงาน. [4]

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

ข้อสรุปเชิงปฏิบัติคือ จำนวนคนควรมาจากลักษณะของงาน ไม่ใช่จากตัวเลขมหัศจรรย์.

Scrum Guide ปี 2020 อธิบาย Scrum Team ว่าเป็นทีมขนาดเล็ก มีทักษะครบข้ามสายงาน และจัดการงานของตนเอง โดยระบุว่าทีมแบบนี้โดยทั่วไปมี 10 คนหรือน้อยกว่า. [3]

นี่เป็นแนวทางที่มีประโยชน์ ในบริบทของ Scrum แต่ไม่ใช่กฎสากลสำหรับทุกโครงการ บริการ อุตสาหกรรม หรือรูปแบบการทำงาน.

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

Service Standard ของสหราชอาณาจักรกำหนดให้ทีมบริการดิจิทัลเป็นทีมหลายสาขาและเข้าถึงชุดทักษะที่เหมาะสมได้ พร้อมระบุว่าโครงสร้างทีมควรสอดคล้องกับสิ่งที่ต้องทำให้สำเร็จในแต่ละช่วง. [1]

คำแนะนำอีกฉบับของ GOV.UK ระบุว่าขนาดทีมและบทบาทที่ต้องใช้จะเปลี่ยนไปตามช่วงต่าง ๆ ของการสร้างบริการ. [2]

จึงได้หลักเชิงปฏิบัติว่า:

เริ่มจากแยกงานและความรับผิดชอบ จากนั้นกำหนดทักษะ แล้วค่อยผูกกับบุคคลจริง.

กำหนดทีมได้ยากหากขอบเขตไม่ชัด.

อย่างน้อยควรระบุ:

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

โครงการ "สร้างแอป" กับโครงการ "ออกแบบ สร้าง ทำให้ปลอดภัย นำขึ้นใช้งาน และดูแลแอปเป็นเวลาหนึ่งปี" ต้องการการครอบคลุมงานที่ต่างกันอย่างสิ้นเชิง.

อย่ารีบกำหนดชื่อตำแหน่ง ให้เขียนประเภทงานที่ต้องเกิดขึ้นจริงก่อน.

สำหรับบริการดิจิทัลอาจมี:

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

โครงการประเภทอื่นจะมีรายการต่างออกไป.

GOV.UK ระบุว่าทีมที่สร้างและดูแลบริการดิจิทัลต้องมีทักษะกว้าง ตั้งแต่ความต้องการผู้ใช้ การออกแบบ การสร้าง การทดสอบ ความปลอดภัย การนำขึ้นใช้งาน ไปจนถึงการดำเนินงาน. [2]

ไม่ใช่ทุกทักษะที่จำเป็นต้องมีคนเต็มเวลาในทีม.

สำหรับแต่ละพื้นที่ให้กำหนดว่า:

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

GOV.UK ระบุชัดว่าทีมสามารถเข้าถึงความเชี่ยวชาญเฉพาะทางได้โดยผู้เชี่ยวชาญไม่จำเป็นต้องเป็นสมาชิกประจำ. [1]

แนวทางนี้ช่วยหลีกเลี่ยงการขยายทีมเกินจำเป็นโดยยังรักษาความเชี่ยวชาญสำคัญไว้.

คนสองคนอาจมีทักษะครบทุกอย่างเมื่อรวมกัน แต่ยังเป็นทีมที่ไม่ดีได้ หากงานทั้งหมดอยู่ในสายการพึ่งพาแคบ ๆ.

ตรวจสอบว่า:

• งานใดทำพร้อมกันได้,
• งานใดต้องรออย่างอื่น,
• ใครตัดสินใจเรื่องที่อาจปิดกั้นงานถัดไป,
• โครงการพึ่งพาทีมหรือผู้ให้บริการภายนอกใด,
• จุดใดที่การขาดคนหนึ่งคนหยุดหลายส่วนพร้อมกัน.

GOV.UK นับการจัดการการพึ่งพาทีมอื่นเป็นหนึ่งในความสามารถที่จำเป็นต่อการสร้างบริการดิจิทัล. [2]

หากมีหลายทีมทำบริการเดียวกัน จะมีความต้องการเพิ่มเติมในการประสานแผนและความคืบหน้าระหว่างทีม. [8]

ความเชี่ยวชาญบางอย่างไม่ปรากฏในรายการฟังก์ชันของผลิตภัณฑ์ แต่การไม่มีสิ่งเหล่านี้อาจมีต้นทุนสูง.

ขึ้นอยู่กับโครงการ อาจรวมถึง:

• ความปลอดภัย,
• การคุ้มครองข้อมูล,
• การเข้าถึง,
• ข้อกำหนดทางกฎหมายหรืออุตสาหกรรม,
• ความน่าเชื่อถือ,
• การย้ายข้อมูล,
• การเชื่อมต่อระบบสำคัญ,
• เทคโนโลยีที่ทีมไม่เคยใช้มาก่อน.

GOV.UK แนะนำให้ทีมเข้าถึงความเชี่ยวชาญเฉพาะเมื่อโครงการต้องการ และระบุว่าโครงสร้างทีมควรสะท้อนสมมติฐานที่เสี่ยงที่สุดของช่วงนั้นด้วย. [1]

ไม่ได้หมายความว่าทุกความเสี่ยงต้องมีตำแหน่งเต็มเวลาแยกต่างหาก แต่ ต้องมีคนที่มีความสามารถรับผิดชอบอย่างชัดเจนและมีอิทธิพลต่อการตัดสินใจจริง.

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

เนื้อหาของ PMI ด้านการวางแผนทรัพยากรเน้นการจับคู่ทักษะ ความพร้อม ต้นทุน และประสบการณ์กับความต้องการของโครงการ. [7]

สำหรับแต่ละคนให้ตรวจสอบ:

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

มีทักษะครบแต่ไม่มีเวลาพอ ก็ยังไม่ถือว่าครอบคลุมโครงการครบ.

ทีมขั้นต่ำควรคำนึงถึงความต่อเนื่องด้วย.

ถามว่า:

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

ไม่ใช่ทุกโครงการเล็กต้องมีคนสำรองเต็มรูปแบบ สำหรับโครงการสั้นและความเสี่ยงต่ำ การยอมรับความเสี่ยงนี้อย่างตั้งใจอาจสมเหตุสมผล.

ในโครงการสำคัญ การพึ่งพาคนเดียวแบบเดียวกันอาจยอมรับไม่ได้.

โครงการไม่จำเป็นต้องมีคนแยกสำหรับทุกชื่อบทบาท.

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

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

อย่ารวมความรับผิดชอบเพียงเพราะ "ต้องมีใครสักคนทำ" การรวมมีเหตุผลเมื่อคนคนนั้นทำทั้งสองส่วนได้ในระดับที่ต้องการและมีเวลาพอ.

คนเดียวอาจเป็นทีมที่สมเหตุสมผลเมื่อทุกข้อเหล่านี้เป็นจริง:

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

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

อย่างไรก็ตาม ขอบเขตจริงยังเป็นตัวตัดสิน ป้ายว่า "โครงการเล็ก" ไม่ได้ให้คำตอบเอง.

ทีมมีเหตุผลมากขึ้นเมื่อมีหลายเงื่อนไขต่อไปนี้:

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

ในสถานการณ์เหล่านี้ การเติมความสามารถที่ขาดสำคัญกว่าการเพิ่มจำนวนคนเฉย ๆ.

การเพิ่มคนเพิ่มคลังความรู้และกำลังงานที่เป็นไปได้ แต่ก็อาจเพิ่มการพึ่งพา การส่งต่องาน และความต้องการในการประสานการตัดสินใจ.

งานศึกษาด้านโครงการซอฟต์แวร์ใน Journal of Systems and Software พบว่าความสัมพันธ์ระหว่างขนาดทีม ผลิตภาพ ความพยายาม และเวลา มีความซับซ้อนและไม่ตรงกับความคาดหวังตามสัญชาตญาณเสมอ. [6]

การวิเคราะห์อภิมานเรื่องขนาดทีมก็ชี้ว่าผลลัพธ์ขึ้นกับบริบทของงานและต้นทุนของกระบวนการทำงานร่วมกัน. [4]

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

ไม่ใช่ทุกความสามารถสำคัญต้องอยู่ทุกวัน.

การอยู่ประจำ เหมาะกว่าเมื่อคนนั้นตัดสินใจเป็นประจำ งานมีการพึ่งพากับพื้นที่อื่นมาก หรือจำเป็นต้องตอบสนองเร็ว.

การสนับสนุนเป็นช่วง อาจเพียงพอเมื่อความเชี่ยวชาญจำเป็นเฉพาะบางจุด เช่น การทบทวน การให้คำปรึกษา การประเมินความเสี่ยง หรือการตรวจรับเฉพาะทาง.

มีเงื่อนไขเดียวคือความพร้อมต้องเป็นจริง ต้องชัดว่า:

• ใครรับผิดชอบ,
• พร้อมเมื่อใด,
• เวลาตอบสนองเท่าไร,
• ตัดสินใจเรื่องใดได้,
• หากพบปัญหาแล้วเกิดอะไรต่อ.

มีชื่อผู้เชี่ยวชาญในแผนแต่ไม่มีความรับผิดชอบชัดเจนอาจดูดีบนแผนผัง แต่ใช้จริงไม่ได้.

สมมติเป้าหมายคือเปิดระบบจองออนไลน์.

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

แบบ B: บริการสาธารณะที่มีบัญชี การชำระเงิน และการเชื่อมต่อ
ต้องใช้ความเชี่ยวชาญ การทดสอบ การจัดการความเสี่ยง การพึ่งพา และงานขนานมากขึ้น ทีมหลายคนจึงมีเหตุผลมากกว่า.

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

เป็นผลิตภัณฑ์ประเภทเดียวกันโดยรวม แต่ ขอบเขต ความเสี่ยง และรูปแบบการดำเนินงานที่ต่างกันทำให้ต้องใช้ทีมต่างกัน.

1. เริ่มจากรายการตำแหน่งสำเร็จรูป แทนงานที่ต้องทำ.

2. คิดว่าทุกบทบาทต้องมีคนแยก.

3. ดูแต่ทักษะและไม่ดูเวลาที่มีจริง.

4. เพิ่มคนโดยไม่ลดการพึ่งพาและคอขวด.

5. มองข้ามทักษะที่เกิดจากความเสี่ยงเพราะไม่สร้างฟังก์ชันที่มองเห็นได้.

6. ให้หลายส่วนสำคัญพึ่งคนเดียวโดยไม่ได้ยอมรับความเสี่ยงอย่างตั้งใจ.

7. ถือว่าทีมตอนเริ่มโครงการต้องเหมือนเดิมจนจบ.

GOV.UK ระบุชัดว่าขนาดและบทบาทของทีมเปลี่ยนตามช่วงการพัฒนาบริการ. [2]

หลักนี้ใช้ได้สมเหตุสมผลนอกบริการภาครัฐด้วย:

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

ทีมขั้นต่ำขึ้นกับช่วงและขอบเขต ไม่ใช่ตัวเลขตายตัวที่ผูกไว้กับโครงการตลอดไป.

สำหรับแต่ละพื้นที่สำคัญ ให้เขียนห้าสิ่ง:

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

จากนั้นจึงค่อยกำหนดคนจริง.

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

1. ทุกพื้นที่งานบังคับมีผู้รับผิดชอบหรือไม่?
2. ทุกความรับผิดชอบสำคัญมีคนที่มีทักษะถูกต้องหรือไม่?
3. มีใครรับหลายบทบาท และมีเวลาจริงเพียงพอหรือไม่?
4. โครงการต้องมีงานขนานที่ทีมปัจจุบันรองรับไม่ได้หรือไม่?
5. เรารู้การพึ่งพาหลักต่อคน ทีม และผู้ให้บริการอื่นหรือไม่?
6. ความเสี่ยงสำคัญเข้าถึงความเชี่ยวชาญที่ถูกต้องหรือไม่?
7. การขาดคนหนึ่งคนหยุดทั้งโครงการได้หรือไม่?
8. ทีมพอไม่เพียงสำหรับสร้าง แต่รวมถึงเปิดใช้และดำเนินงาน หากอยู่ในขอบเขตหรือไม่?
9. เรารู้ว่าทักษะใดใช้เป็นช่วงแทนการอยู่ประจำได้หรือไม่?
10. กำหนดจุดประเมินทีมใหม่เมื่อขอบเขตหรือช่วงเปลี่ยนแล้วหรือไม่?

การออกแบบทีมไม่ควรเริ่มจากคำถามว่า:

"โครงการแบบนี้ปกติต้องใช้กี่คน?"

ลำดับที่ดีกว่าคือ:

ผลลัพธ์ -> งาน -> ทักษะ -> การพึ่งพา -> ความเสี่ยง -> กำลังงาน -> คน.

หากผ่านลำดับนี้แล้วคนเดียวครอบคลุมทุกอย่างได้จริง คนเดียวอาจเป็นตัวเลือกที่ถูกต้อง.

หากขาดทักษะ เวลา การตรวจสอบอิสระ ความต่อเนื่อง หรือความสามารถทำงานขนาน ต้องเพิ่มคนหรือมีการเข้าถึงผู้เชี่ยวชาญอย่างเชื่อถือได้.

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

[1] GOV.UK Service Standard - Have a multidisciplinary team
เปิดแหล่งข้อมูล

[2] GOV.UK Service Manual - Set up a service team at each phase
เปิดแหล่งข้อมูล

[3] The Scrum Guide, 2020 - Scrum Team
เปิดแหล่งข้อมูล

[4] Bernerth, Beus, Helmuth, Boyd - The more the merrier or too many cooks spoil the pot? A meta-analytic examination of team size and team effectiveness, Journal of Organizational Behavior, 2023
เปิดแหล่งข้อมูล

[5] Mao, Mason, Suri, Watts - An Experimental Study of Team Size and Performance on a Complex Task, PLOS ONE, 2016
เปิดแหล่งข้อมูล

[6] Rodríguez, Sicilia, García, Harrison - Empirical findings on team size and productivity in software development, Journal of Systems and Software, 2012
เปิดแหล่งข้อมูล

[7] Project Management Institute - Solving The Resource Puzzle
เปิดแหล่งข้อมูล

[8] GOV.UK Service Manual - Running more than one service team
เปิดแหล่งข้อมูล

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