Một người hay một nhóm? Cách xác định đội hình tối thiểu cho dự án dựa trên kỹ năng, phụ thuộc và rủi ro

Nghiên cứu không ủng hộ quy tắc đơn giản như "nhóm nhỏ luôn tốt hơn" hoặc "nhóm lớn luôn làm được nhiều hơn".

Một phân tích tổng hợp năm 2023 với 208 hiệu ứng độc lập và 21.435 nhóm cho thấy mối liên hệ tổng thể giữa quy mô nhóm và hiệu suất nhiệm vụ gần như bằng không, đồng thời có biến thiên rất lớn theo bối cảnh. Các tác giả cho thấy tác động của quy mô nhóm thay đổi theo những yếu tố như độ phức tạp của nhiệm vụ và nhu cầu phối hợp. [4]

Một thí nghiệm về nhiệm vụ lập bản đồ khủng hoảng phức tạp cũng cho thấy cả lợi ích lẫn chi phí của nhóm lớn hơn: mức hợp tác tăng khi nhóm lớn lên, trong khi cách phân bổ nỗ lực cá nhân thay đổi. Trong thí nghiệm cụ thể đó, các nhóm lớn nhất đạt kết quả tốt hơn số người tương đương làm việc độc lập. Đây không phải công thức chung cho mọi loại công việc. [5]

Kết luận thực tế rất đơn giản: số người nên xuất phát từ tính chất công việc, không phải một con số thần kỳ.

Scrum Guide 2020 mô tả Scrum Team là một nhóm nhỏ, đa kỹ năng và tự quản lý công việc. Tài liệu cũng nói rằng nhóm như vậy thường có 10 người hoặc ít hơn. [3]

Đây là hướng dẫn hữu ích trong bối cảnh Scrum, nhưng không phải quy luật chung cho mọi dự án, dịch vụ, ngành nghề hay mô hình triển khai.

Một dự án xây dựng, chiến dịch tiếp thị, đánh giá an ninh, hệ thống tài chính và trang thông tin nhỏ có nhu cầu rất khác nhau. Không nên áp dụng trực tiếp cùng một con số cho tất cả.

Service Standard của Anh yêu cầu nhóm xây dựng dịch vụ số phải đa ngành và có quyền tiếp cận dải kỹ năng phù hợp. Tài liệu cũng nêu rằng đội hình phải phù hợp với điều nhóm cần đạt được ở từng giai đoạn. [1]

Một hướng dẫn khác của GOV.UK cho biết quy mô nhóm và các vai trò cần thiết thay đổi qua các giai đoạn xây dựng dịch vụ. [2]

Từ đó có một nguyên tắc thực tế:

trước hết lập bản đồ công việc và trách nhiệm, sau đó xác định kỹ năng, rồi cuối cùng mới gán cho từng người cụ thể.

Không thể xác định đúng đội hình nếu phạm vi không rõ.

Ít nhất hãy ghi:

• kết quả cần tạo ra,
• những gì nằm trong phạm vi,
• những gì nằm ngoài phạm vi,
• yêu cầu chất lượng quan trọng nhất,
• giới hạn thời gian và ngân sách,
• ai sẽ chấp nhận kết quả,
• nhóm chỉ bàn giao hay còn phải vận hành giải pháp.

Dự án "xây một ứng dụng" và dự án "thiết kế, xây, bảo vệ, triển khai và vận hành ứng dụng trong một năm" cần mức bao phủ công việc hoàn toàn khác nhau.

Thay vì ghi chức danh ngay lập tức, hãy liệt kê những loại công việc thực sự phải xảy ra.

Với dịch vụ số, có thể gồm:

• hiểu nhu cầu người dùng,
• thiết kế giải pháp,
• xây phần người dùng nhìn thấy,
• xây logic phía máy chủ và tích hợp,
• kiểm thử,
• an ninh,
• khả năng tiếp cận,
• triển khai và vận hành,
• phối hợp phạm vi và quyết định.

Một loại dự án khác sẽ có danh sách khác.

GOV.UK nêu rằng nhóm xây dựng và vận hành dịch vụ số cần một dải kỹ năng rộng, bao gồm nhu cầu người dùng, thiết kế, xây dựng, kiểm thử, an ninh, triển khai và vận hành trực tiếp. [2]

Không phải kỹ năng cần thiết nào cũng đòi hỏi một người toàn thời gian trong nhóm.

Với mỗi vùng, hãy phân loại:

Thường trực - cần đều đặn và ảnh hưởng trực tiếp đến quyết định hằng ngày.
Định kỳ - cần ở giai đoạn hoặc điểm kiểm soát cụ thể.
Có thể lấy từ bên ngoài - do người hoặc nhóm khác cung cấp nếu thời gian phản hồi và trách nhiệm đủ rõ.

GOV.UK cho phép nhóm tiếp cận chuyên môn đặc thù mà không bắt buộc chuyên gia phải là thành viên thường trực. [1]

Điều này thường tránh việc phình nhóm một cách giả tạo mà vẫn giữ được năng lực quan trọng.

Hai người có thể cộng lại đủ mọi kỹ năng cần thiết nhưng vẫn tạo thành đội hình kém nếu toàn bộ công việc nằm trong một chuỗi phụ thuộc hẹp.

Hãy kiểm tra:

• nhiệm vụ nào có thể chạy song song,
• nhiệm vụ nào phải chờ nhiệm vụ khác,
• ai đưa ra quyết định có thể chặn công việc tiếp theo,
• dự án phụ thuộc vào nhóm hoặc nhà cung cấp bên ngoài nào,
• ở đâu việc thiếu một người sẽ dừng nhiều khu vực cùng lúc.

GOV.UK liệt kê quản lý phụ thuộc vào các nhóm khác là một trong các năng lực cần thiết khi xây dịch vụ số. [2]

Khi nhiều nhóm cùng làm một dịch vụ, còn phát sinh nhu cầu phối hợp kế hoạch và tiến độ giữa các nhóm. [8]

Một số chuyên môn cần thiết không xuất hiện trong danh sách tính năng sản phẩm, nhưng thiếu nó có thể rất tốn kém.

Tùy dự án, có thể gồm:

• an ninh,
• bảo vệ dữ liệu,
• khả năng tiếp cận,
• yêu cầu pháp lý hoặc ngành,
• độ tin cậy,
• di chuyển dữ liệu,
• tích hợp với hệ thống quan trọng,
• công nghệ nhóm chưa từng sử dụng.

GOV.UK khuyến nghị tiếp cận chuyên môn khi dự án cần và cho rằng đội hình cũng nên phản ánh những giả định rủi ro nhất của giai đoạn hiện tại. [1]

Điều này không có nghĩa phải tạo một vị trí toàn thời gian cho mỗi rủi ro. Nó có nghĩa một người đủ năng lực phải có trách nhiệm rõ và khả năng thực sự tác động đến quyết định.

Một người có thể biết thiết kế, phát triển, kiểm thử và triển khai. Điều đó không có nghĩa người ấy có thể làm tất cả cùng lúc dưới bất kỳ thời hạn nào.

Tài liệu PMI về hoạch định nguồn lực nhấn mạnh việc khớp kỹ năng, khả năng sẵn sàng, chi phí và kinh nghiệm với nhu cầu dự án. [7]

Với mỗi người, hãy kiểm tra:

• thực tế có thể dành bao nhiêu thời gian,
• nhiệm vụ nào cạnh tranh sự chú ý,
• công việc nào phải diễn ra song song,
• thời hạn có giả định việc chuyển đổi không thực tế giữa quá nhiều loại công việc hay không,
• sau khi ra mắt có còn cần người vận hành giải pháp không.

Bao phủ kỹ năng mà không bao phủ thời gian không phải bao phủ đầy đủ dự án.

Đội hình tối thiểu cũng phải tính đến tính liên tục.

Hãy hỏi:

• điều gì xảy ra nếu người chủ chốt không có mặt,
• chỉ một người hiểu phần quan trọng của giải pháp hay không,
• quyết định và kiến thức có được ghi lại không,
• người khác có thể tiếp quản nhiệm vụ quan trọng không,
• dự án có thể tạm dừng an toàn trong thời gian vắng mặt không.

Không phải dự án nhỏ nào cũng cần thay thế hoàn toàn. Với dự án ngắn và ít rủi ro, chấp nhận rủi ro này một cách có ý thức có thể hợp lý.

Với dự án quan trọng, cùng sự phụ thuộc vào một người có thể không chấp nhận được.

Dự án không cần một người riêng cho mỗi tên vai trò.

Nếu một người thực sự có kỹ năng cần thiết, đủ năng lực thời gian và không tạo rủi ro không chấp nhận được, họ có thể chịu trách nhiệm cho nhiều vùng.

Ví dụ, trong dự án nhỏ một người có thể kết hợp thiết kế giao diện và triển khai. Ở dự án khác, một người có thể kết hợp phân tích kinh doanh và phối hợp phạm vi.

Đừng gộp trách nhiệm chỉ vì "phải có ai đó làm". Chỉ nên gộp khi người đó có thể làm cả hai trách nhiệm ở mức yêu cầu và có đủ thời gian.

Một người có thể là đội hình hợp lý khi đồng thời:

• phạm vi nhỏ và rõ,
• kỹ năng cần thiết thực sự nằm trong khả năng của người đó,
• nhiệm vụ không cần nhiều công việc song song,
• phụ thuộc bên ngoài hạn chế,
• rủi ro có thể chấp nhận,
• thời hạn phù hợp với năng lực thực,
• việc không có người thay thế được chấp nhận có ý thức.

Ví dụ có thể là một tài liệu thông tin nhỏ, phân tích đơn giản, tư vấn một lần hoặc triển khai giới hạn trong môi trường quen thuộc.

Dù vậy, vẫn phụ thuộc vào phạm vi cụ thể. Nhãn "dự án nhỏ" không tự quyết định câu trả lời.

Nhóm trở nên hợp lý hơn khi xuất hiện nhiều điều kiện sau:

• kỹ năng cần thiết quá rộng cho một người,
• nhiều công việc phải diễn ra song song,
• thời hạn ngắn hơn thời gian thực hiện tuần tự thực tế,
• dự án có nhiều phụ thuộc và điểm giao tiếp,
• rủi ro cần chuyên môn độc lập,
• giải pháp vừa phải được xây vừa phải được vận hành,
• một người sẽ trở thành điểm quan trọng của toàn bộ dự án,
• trách nhiệm trải trên nhiều lĩnh vực khác nhau.

Trong những điều kiện này, bổ sung năng lực còn thiếu quan trọng hơn chỉ tăng số người.

Thêm người làm tăng nguồn kiến thức và năng lực tiềm năng, nhưng cũng có thể làm tăng phụ thuộc, bàn giao công việc và nhu cầu đồng bộ quyết định.

Một nghiên cứu dự án phần mềm đăng trên Journal of Systems and Software cho thấy quan hệ giữa quy mô nhóm, năng suất, nỗ lực và thời gian rất phức tạp và không phải lúc nào cũng phù hợp với trực giác. [6]

Phân tích tổng hợp về quy mô nhóm cũng cho thấy kết quả phụ thuộc vào bối cảnh nhiệm vụ và chi phí của quá trình làm việc nhóm. [4]

Vì vậy câu hỏi không phải "chúng ta có thể thêm bao nhiêu người?", mà là "người tiếp theo có loại bỏ một ràng buộc thật của dự án nhiều hơn chi phí phối hợp mà họ tạo ra hay không?"

Không phải năng lực quan trọng nào cũng cần hiện diện mỗi ngày.

Hiện diện thường trực hợp lý hơn khi người đó thường xuyên ra quyết định, công việc có nhiều phụ thuộc với vùng khác hoặc cần phản hồi nhanh.

Hỗ trợ định kỳ có thể đủ khi chuyên môn chỉ cần ở điểm cụ thể, như rà soát, tư vấn, đánh giá rủi ro hoặc nghiệm thu chuyên môn.

Có một điều kiện: khả năng sẵn sàng phải là thật. Cần rõ:

• ai chịu trách nhiệm,
• khi nào họ sẵn sàng,
• thời gian phản hồi dự kiến,
• họ có thể đưa ra quyết định nào,
• điều gì xảy ra nếu phát hiện vấn đề.

Có quyền tiếp cận một chuyên gia nhưng không có trách nhiệm rõ có thể đẹp trên sơ đồ tổ chức nhưng không hoạt động trong dự án thật.

Giả sử mục tiêu là ra mắt hệ thống đặt chỗ trực tuyến.

Phương án A: nguyên mẫu đơn giản để kiểm tra ý tưởng
Phạm vi hạn chế, không có thanh toán hay dữ liệu đặc biệt nhạy cảm, và mục tiêu là kiểm tra quy trình với nhóm người dùng nhỏ. Một người đa năng có thể bao phủ thiết kế và triển khai, với tư vấn định kỳ khi cần.

Phương án B: dịch vụ công khai có tài khoản, thanh toán và tích hợp
Xuất hiện thêm chuyên môn, kiểm thử, rủi ro, phụ thuộc và công việc song song. Một nhóm vài người trở nên hợp lý hơn nhiều.

Phương án C: dịch vụ chạy liên tục và cần phản hồi nhanh với sự cố
Ngoài xây dựng còn có vận hành, giám sát, phản ứng sự cố và duy trì kiến thức. Đội hình đủ để ra mắt có thể không đủ để vận hành bền vững.

Đó vẫn là cùng loại sản phẩm nói chung, nhưng phạm vi, rủi ro và mô hình vận hành khác nhau tạo ra nhu cầu nhóm khác nhau.

1. Bạn bắt đầu từ danh sách chức danh có sẵn thay vì công việc cần làm.

2. Bạn cho rằng mỗi vai trò cần một người riêng.

3. Bạn chỉ nhìn kỹ năng và bỏ qua thời gian có sẵn.

4. Bạn thêm người mà không loại bỏ phụ thuộc và nút thắt.

5. Bạn bỏ qua kỹ năng do rủi ro yêu cầu vì chúng không tạo tính năng nhìn thấy được.

6. Bạn để nhiều vùng quan trọng phụ thuộc vào một người mà không chủ động chấp nhận rủi ro.

7. Bạn coi đội hình lúc đầu là cố định cho đến hết dự án.

GOV.UK nói rõ rằng quy mô và vai trò của nhóm thay đổi theo các giai đoạn phát triển dịch vụ. [2]

Đây cũng là nguyên tắc hợp lý ngoài dịch vụ công:

• giai đoạn đầu có thể cần nhiều nghiên cứu và làm rõ vấn đề hơn,
• trong lúc xây dựng, năng lực triển khai và kiểm thử quan trọng hơn,
• trước khi ra mắt có thể cần tăng chú ý đến an ninh, chất lượng và sẵn sàng vận hành,
• sau khi ra mắt, cân bằng giữa phát triển và vận hành thay đổi.

Đội hình tối thiểu phụ thuộc vào giai đoạn và phạm vi, không phải một con số cố định cho toàn bộ dự án.

Với mỗi vùng quan trọng, hãy ghi năm điều:

Vùng công việc - cần làm gì?
Kỹ năng - cần kiến thức và khả năng nào?
Trách nhiệm - ai quyết định và chịu trách nhiệm về kết quả?
Khả năng sẵn sàng - kỹ năng thường trực, định kỳ hay bên ngoài?
Rủi ro thiếu vắng - điều gì xảy ra nếu thiếu kỹ năng hoặc người đó không có mặt?

Sau đó mới gán người cụ thể.

Nếu một người bao phủ nhiều dòng, hãy kiểm tra thời gian và phụ thuộc. Nếu một dòng cần nhiều người, hãy xem nguyên nhân là năng lực, kiểm soát độc lập hay công việc song song.

1. Mọi vùng công việc bắt buộc đã có người chịu trách nhiệm chưa?
2. Mọi trách nhiệm quan trọng đã có người đủ kỹ năng chưa?
3. Có ai giữ nhiều vai trò, và thực tế có đủ thời gian không?
4. Dự án có cần công việc song song mà đội hình hiện tại không hỗ trợ được không?
5. Chúng ta đã biết các phụ thuộc chính vào người, nhóm và nhà cung cấp khác chưa?
6. Các rủi ro quan trọng có quyền tiếp cận đúng chuyên môn không?
7. Việc một người vắng mặt có thể dừng toàn bộ dự án không?
8. Đội hình có đủ không chỉ để xây mà còn để ra mắt và vận hành nếu đó là phạm vi không?
9. Chúng ta biết kỹ năng nào có thể định kỳ thay vì thường trực không?
10. Đã xác định điểm đánh giá lại đội hình khi phạm vi hoặc giai đoạn thay đổi chưa?

Thiết kế nhóm không nên bắt đầu bằng câu hỏi:

"dự án như thế này thường cần bao nhiêu người?"

Trình tự tốt hơn là:

kết quả -> công việc -> kỹ năng -> phụ thuộc -> rủi ro -> năng lực -> con người.

Nếu sau khi đi qua trình tự này một người thực sự bao phủ tất cả, một người có thể là lựa chọn đúng.

Nếu thiếu kỹ năng, thời gian, kiểm tra độc lập, tính liên tục hoặc khả năng làm việc song song, cần thêm người hoặc quyền tiếp cận đáng tin cậy đến chuyên gia.

Mục tiêu không phải nhóm nhỏ nhất. Mục tiêu là đội hình nhỏ nhất có thể thực tế tạo ra kết quả yêu cầu ở mức rủi ro và chất lượng cần thiết.

[1] GOV.UK Service Standard - Have a multidisciplinary team
Mở nguồn

[2] GOV.UK Service Manual - Set up a service team at each phase
Mở nguồn

[3] The Scrum Guide, 2020 - Scrum Team
Mở nguồn

[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
Mở nguồn

[5] Mao, Mason, Suri, Watts - An Experimental Study of Team Size and Performance on a Complex Task, PLOS ONE, 2016
Mở nguồn

[6] Rodríguez, Sicilia, García, Harrison - Empirical findings on team size and productivity in software development, Journal of Systems and Software, 2012
Mở nguồn

[7] Project Management Institute - Solving The Resource Puzzle
Mở nguồn

[8] GOV.UK Service Manual - Running more than one service team
Mở nguồn

Ghi chú phương pháp: một số nguồn nói về dịch vụ công số, một số về Scrum Team, quản lý dự án hoặc nghiên cứu nhóm và phát triển phần mềm. Hướng dẫn này chỉ dùng từng nguồn trong phạm vi mà nguồn đó thực sự hỗ trợ. Phương pháp bảy bước để xác định đội hình tối thiểu là tổng hợp biên tập của các nguyên tắc đó, không phải tiêu chuẩn chính thức của bất kỳ tổ chức nào nêu trên.