Cách phân chia công việc giữa nhiều người thực hiện

Có một ứng dụng nhỏ quản lý danh sách mua sắm, và bạn muốn bổ sung hai tính năng: lọc các mục và xuất danh sách ra CSV. Hai việc gần như không liên quan, nên ý nghĩ chia đôi công việc để hoàn thành cả hai trong nửa giờ thay vì một giờ nghe khá hợp lý. Một người thực hiện phụ trách bộ lọc, người kia lo phần xuất dữ liệu; mỗi bên có thư mục làm việc riêng để các thay đổi không lẫn vào nhau. Nhưng họ chưa hề thống nhất trước cách biểu diễn một mục trong danh sách. Ai cũng nghĩ chuyện đó đã quá rõ ràng.

Nửa giờ sau, cả hai phần đều xong. Các bài kiểm tra riêng đều đạt, việc ghép mã cũng không có xung đột nào. Thế nhưng kịch bản chung lại không chạy đúng: bộ lọc hiển thị ba mục trên màn hình, còn trong file xuất thì một cột bị trống. Nguyên nhân khá tầm thường. Một trong hai người thực hiện tiện tay đổi tên trường completed thành done vì thấy tên này dễ đọc hơn, nhưng người còn lại không biết.

Các thư mục riêng giúp tách file, chứ không giúp thống nhất quyết định. Hãy xem vấn đề qua ba bước: trước tiên quyết định có nên chia công việc không, sau đó phân chia phạm vi thay đổi và thống nhất các quy ước chung, cuối cùng kiểm tra kết quả đã ghép để tránh gặp bất ngờ như vậy vào phút chót.

Kiểm tra các phụ thuộc

Thường có hai lý do để chia công việc. Thứ nhất là tìm hiểu độc lập các phần khác nhau: cùng lúc xác định cách hiển thị danh sách và cách tạo file xuất. Thứ hai là làm đồng thời những phần đã có phạm vi rõ ràng và kết quả có thể kiểm tra. Chỉ riêng việc chia thành "lập kế hoạch, thực hiện, kiểm tra" không có nghĩa là cần ba người; một session có thể làm lần lượt từng việc. Với nhiệm vụ nhỏ, nên bắt đầu với một người thực hiện.

Nếu có lý do để chia việc, câu hỏi tiếp theo là: phần B có thể làm được những gì trong khi chưa biết kết quả của A? Nếu B phụ thuộc hoàn toàn vào A, hai bước này phải thực hiện tuần tự. Đôi khi B có thể chuẩn bị trước một phần độc lập, nhưng việc ghép kết quả vẫn phải chờ A.

Hãy xem ba tình huống trong ví dụ danh sách mua sắm:

Dòng thứ ba là cái bẫy thường gặp nhất. Bạn có thể nghĩ rằng bộ lọc nằm trong src/filter.js, còn phần xuất dữ liệu ở src/export-csv.js, vậy hai phần độc lập vì chúng ở hai file khác nhau. Nhưng cả hai cùng đọc một mục và trường completed. Tình huống ở đầu bài viết hỏng chính vì điều này, và hai file riêng không giúp ích gì. Tính độc lập nằm ở hành vi và các quy ước chung, chứ không phải số lượng file chứa mã.

Bạn có thể giao agent chia nhiệm vụ thành các phần, nhưng chưa khởi chạy người thực hiện nào:

Chia nhiệm vụ thành các phần. Với mỗi phần, hãy nêu đầu vào, kết quả,
phụ thuộc và cách kiểm tra. Đánh dấu phần nào có thể bắt đầu ngay.
Tạm thời đừng khởi chạy người thực hiện nào.

Bạn có thể kiểm tra câu trả lời đó trước khi bắt đầu. Những phần không còn phụ thuộc chưa giải quyết là ứng viên để khởi chạy đồng thời. Nếu cột phụ thuộc để trống, hãy đối chiếu lại với project: agent có thể đã bỏ sót một mô hình dữ liệu hoặc cấu hình dùng chung.

Tính thời gian để có kết quả chung

Người ta thường đo mức tăng tốc bằng một con số: thời gian để hoàn thành phần việc. Nhưng điều cần tính là thời gian để đạt được kết quả chung được chấp nhận. Ngoài thời gian thực hiện, còn có thời gian giao việc cho từng người thực hiện, thời gian để mỗi người đọc lại project, thời gian chờ, kiểm tra hai kết quả và ghép chúng lại.

Thử tính theo ví dụ của chúng ta. Các con số chỉ nhằm minh họa phép tính, không phải số liệu đo hiệu năng:

Phần chuẩn bị chung cho nhiệm vụ cần thiết trong cả hai phương án nên không tính vào đây. Một lần làm lại đã đủ xóa sạch 10 phút tiết kiệm; chi phí ghép mã càng cao thì làm đồng thời càng phải tiết kiệm được nhiều thời gian.

Ngoài thời gian còn có hai khoản dễ bị bỏ quên. Mỗi người thực hiện bổ sung phải đọc lại project, tiêu tốn tài nguyên; khi quay về, báo cáo chi tiết của họ cũng chiếm chỗ trong cuộc hội thoại chung. Khoản thứ hai quan trọng hơn: sự tập trung của chính bạn. Bạn cần đọc hai kết quả, đối chiếu chúng và quyết định bước tiếp theo. Nếu không đọc xuể những gì được gửi về, bạn không còn làm chủ tốc độ nữa.

Có thể nhanh gần gấp đôi nếu chia thành hai phần độc lập, tương đương nhau và chi phí phối hợp thấp. Nhưng chỉ tăng số người thực hiện thì không đảm bảo được điều đó.

Làm trùng hay kiểm chứng độc lập

Bạn sẽ không thấy việc làm trùng trong báo cáo. Hai người thực hiện âm thầm mở cùng file, cùng tìm hiểu cách biểu diễn mục trong danh sách, rồi ai cũng thành thật báo rằng mình đã tìm hiểu mã. Nhưng đôi khi cần chủ động kiểm chứng lần thứ hai: giả định này rất quan trọng, nên bạn muốn một người chưa biết lập luận của người thứ nhất kiểm tra lại. Khác với việc làm trùng ngẫu nhiên, lần kiểm chứng này cần xác định trước nội dung, lý do và cách xử lý nếu hai kết luận khác nhau. Nếu không có bước cuối, việc kiểm chứng chỉ thành màn gom ý kiến.

Giờ xét tình huống ngược lại. Bạn hỏi hai người thực hiện trường completed trong mục danh sách có nghĩa gì. Cả hai trả lời giống nhau: đánh dấu mục đã mua. Nghe như đã có hai xác nhận độc lập.

Thực ra cả hai cùng đọc một dòng trong README.md viết từ một năm trước, trong khi trong mã trường này từ lâu đã mang ý nghĩa khác. Điều trùng nhau không phải kết luận, mà là nguồn thông tin.

Rút ra hai thói quen hữu ích:

• Hãy yêu cầu chỉ rõ căn cứ cho câu trả lời: file, dòng hoặc đoạn mã. Đừng nhận lời kể lại; cần thứ bạn có thể tự mở ra xem;
• Hãy kiểm tra riêng và thực chất một giả định chung: mã thực sự làm gì và kịch bản diễn ra thế nào. Kể cả khi mọi người đều đồng ý.

Các session riêng không đảm bảo lỗi cũng độc lập: cùng một nguồn có thể dẫn đến cùng một sai sót. Khi câu trả lời không khớp, hãy kiểm tra căn cứ chứ đừng đếm phiếu: một người có thể đang xem mã mới nhất, còn hai người kia dựa vào ghi chú cũ.

Giá trị của trường đã được xác minh trong mã sẽ trở thành nền tảng cho mô hình chung mà mọi người thống nhất trước khi bắt đầu. Nếu sau cả ba lần kiểm tra, việc chia nhỏ vẫn có vẻ đáng làm, hãy chuyển sang phân công.

Chỉ định người phụ trách từng phạm vi

Quy tắc khi làm song song rất đơn giản: mỗi phạm vi thay đổi chỉ có một người phụ trách. Không phải "file này tuyệt đối không được để hai người cùng đụng vào", mà là "trong lúc hai nhiệm vụ này đang chạy, người này sẽ sửa file đó". Đây là thỏa thuận có thời hạn, không phải đặc tính cố định của project.

Nửa sau của quy tắc còn quan trọng hơn và thường bị quên mất. Kết quả chung cũng cần có người phụ trách: người ghép các phần lại và quyết định liệu toàn bộ đã sẵn sàng chưa. Nếu không chỉ định ai ghép mã, việc đó sẽ rơi vào tay người hoàn thành sau cùng, cũng là người ít hiểu phần việc của người khác nhất.

Trước khi khởi chạy, hãy xem project và kiểm tra xem các phần cần thiết đã được tách biệt ở mức nào. Nếu chưa, đừng vội làm một đợt refactor lớn chỉ để có thể làm song song: refactor có thể trở thành nhiệm vụ lớn nhất trong ngày, rồi chẳng còn gì để chia nữa.

Với danh sách mua sắm của chúng ta, có thể phân công như sau:

Bảng này phân công trách nhiệm thay đổi, chứ không phải quyền truy cập: ai cần thì đều có thể đọc các file chung.

Dòng nhắc đến package.json không phải để làm khó ai: lệnh npm install thay đổi cả hai file cùng lúc, nên hai lần cài đặt song song dễ gây xung đột; hai phiên bản khác nhau của cùng một thư viện cũng có thể tạo bất ngờ khi build. Nếu cả hai người thực hiện đều cần thư viện đó, họ chỉ gửi lại yêu cầu: cần gì và vì sao. Một người sẽ quyết định và thực hiện thay đổi đúng một lần.

Thống nhất mô hình chung trước khi bắt đầu

Chỉ phân chia file mà không có thỏa thuận chung thì khó làm việc hiệu quả. Bộ lọc và phần xuất dữ liệu cùng dựa trên một mô hình mục trong danh sách. Bên dưới là phác thảo interface, không phải ví dụ có thể chạy: phần triển khai các hàm chưa được trình bày. Trước khi bắt đầu, mọi người cũng thống nhất giữ nguyên thứ tự các mục, không sửa mảng ban đầu và ghi giá trị boolean trong CSV dưới dạng true/false. Quy tắc escape CSV vẫn giữ nguyên.

// một mục trong danh sách: thống nhất ba trường này trước khi bắt đầu và không đổi tên chúng
const item = { id: 41, title: "oat milk", completed: false };

// filter.js trả về tập hợp mục đã sẵn sàng, không định dạng hay xuất dữ liệu
filterItems(items, mode);   // mode: "all", "active", "completed"

// export-csv.js nhận tập hợp đã lọc, không tự lọc thêm
exportCsv(items);           // trả về một chuỗi CSV có các cột id,title,completed

Hãy để ý rằng thỏa thuận ở đây không nói về tên file mà là đầu vào và đầu ra. "Phần xuất dữ liệu nhận danh sách đã lọc" nghe có vẻ nhỏ nhặt, nhưng chính câu này xác định ai chịu trách nhiệm lọc các mục. Nếu không thống nhất, cả hai đều có thể cho rằng mình phải lọc, khiến file nhận được tất cả các mục hoặc bị lọc hai lần.

Trước khi bắt đầu, mọi người cũng cần thống nhất cách nghiệm thu kết quả. Kịch bản chung trong ví dụ của chúng ta là các mục 41 và 43 có completed: true, còn mục 42 có false. Chế độ "completed" phải hiển thị mục 41 và 43 theo thứ tự ban đầu; CSV cũng phải chứa đúng hai mục đó, có tiêu đề id,title,completed và giá trị true ở cột cuối. Kịch bản này chạy qua cả hai phần cùng lúc và bắt đúng lỗi đã mở đầu bài viết.

Còn một điểm nữa: thay đổi thỏa thuận chung. Nếu trong lúc làm việc phát hiện cần sửa định dạng chung, đó không phải thay đổi nhỏ ở một file. Hãy xem lại tất cả nhiệm vụ phụ thuộc vào định dạng này, vì một phần công việc đã làm có thể dựa trên phiên bản cũ.

Các thư mục làm việc riêng (git worktree) không thể thay thế thỏa thuận chung. Chúng tách biệt các thay đổi về mặt vật lý, điều này hữu ích: trong một thư mục chung, bước kiểm tra có thể vô tình bao gồm thay đổi chưa hoàn tất của nhiệm vụ khác và xác nhận trạng thái mà không người thực hiện nào kiểm tra riêng. Nhưng thư mục không thể thống nhất định dạng mục trong danh sách; còn .env, port và database vẫn được dùng chung theo mặc định.

Giao nhiệm vụ ngắn gọn cho từng người thực hiện

Nhiệm vụ không cần quá dài. Thường bảy mục là đủ: mục tiêu, phiên bản bắt đầu, các file được phụ trách, thỏa thuận chung, kết quả có thể kiểm tra, thông tin cần phản hồi và cách xử lý nếu cần thay đổi phần của người khác.

Mục tiêu: bộ lọc danh sách hiển thị tất cả mục, chỉ mục chưa hoàn thành hoặc chỉ mục đã hoàn thành.
Bắt đầu từ: commit mới nhất trên branch chính có mô hình mục đã thống nhất.
Các file của bạn: src/filter.js và tests/filter.test.js.
Thỏa thuận chung: trường completed vẫn là boolean, không đổi tên các trường;
bộ lọc trả về một mảng mục và không xuất dữ liệu.
Kết quả: các bài kiểm tra bộ lọc đều đạt; với ba mục, mỗi chế độ
trả về danh sách như mong đợi.
Phản hồi: danh sách file thực tế đã thay đổi, output của lần chạy kiểm tra,
phiên bản mã đã dùng để chạy và các câu hỏi còn lại.
Nếu cần sửa src/item-model.js hoặc src/app.js: hãy dừng lại,
mô tả thay đổi cần thiết cùng lý do và chờ phản hồi.

Nhiệm vụ của người thực hiện thứ hai cũng tương tự: một cặp file riêng, cùng định dạng mục, kết quả có thể kiểm tra và cách xử lý tương tự khi cần vượt ra ngoài phạm vi. Không cần chép lại toàn bộ ở đây.

Tiếp theo là phần phản hồi. Cần có danh sách file thực tế đã thay đổi và output thực tế của các lần kiểm tra. Viết câu "không sửa file của người khác" rất dễ, và agent càng được nhắc nhiều thì câu đó càng dễ xuất hiện trong phản hồi. Hãy đối chiếu với danh sách thay đổi thay vì tin vào câu chữ. Ranh giới trong nhiệm vụ là một thỏa thuận, không phải lệnh cấm: nội dung yêu cầu không ngăn agent ghi vào file, còn quyền truy cập được cấu hình riêng.

Thống nhất lại phạm vi bị chồng lấn

Sớm muộn gì cũng có người cần chạm đến phạm vi của người khác. Người thực hiện B nhận ra rằng nếu không sửa src/app.js thì chẳng có chỗ nào để kết nối phần xuất dữ liệu: nút xuất chưa được gọi.

Một phản hồi tốt cần nêu lý do, thay đổi cần thiết và phần phụ thuộc. Người phụ trách ghép mã đã nhận phần kết nối trong src/app.js, nên B có thể hoàn tất module của mình rồi gửi yêu cầu kết nối. Nếu không thể tiếp tục phần việc riêng khi chưa có thay đổi chung, hãy tạm dừng phần việc phụ thuộc đó.

Có hai cách xử lý. Người phụ trách ghép mã tự sửa file chung vì đó là phạm vi của mình. Hoặc họ chuyển giao rõ ràng phạm vi này cho người thực hiện B, nhưng trước hết phải xác nhận chủ sở hữu cũ không còn sửa file đó: chuyển giao mà không dừng việc đang làm sẽ dẫn đến đúng tình huống mà cách phân công này muốn ngăn chặn.

Điều chắc chắn không nên làm là bắt người thực hiện tìm cách lách phạm vi. Yêu cầu "đừng đụng vào app.js, hãy nghĩ cách khác" thường khiến họ sao chép logic của người khác sang file riêng hoặc thêm một lớp trung gian không ai giải thích nổi. Trên giấy tờ, bảng phân công vẫn được tuân thủ. Nhưng trong project đã xuất hiện cách hiểu thứ hai về quy trình xuất dữ liệu.

Ghép hành vi, không chỉ ghép file

Trước khi ghép mã, người phụ trách cần nắm ba điều: mỗi phần bắt đầu từ phiên bản nào, mỗi người thực hiện kiểm tra những gì trên phiên bản nào và file nào thực sự đã thay đổi. Tất cả thông tin này cần có trong phản hồi cho nhiệm vụ; danh sách file thì phải đối chiếu với các thay đổi thực tế.

Sau đó ghép các phần lại. Việc quan trọng nhất là chạy kịch bản chung đã thống nhất trước khi bắt đầu. Có hai vấn đề rất khác nhau có thể xảy ra.

Xung đột văn bản. Các phần thay đổi cùng một đoạn theo những cách khác nhau, hoặc một bên xóa hay đổi tên file, và Git không thể tự ghép. Hãy giải quyết xung đột rồi kiểm tra hành vi cuối cùng.

Không tương thích về ý nghĩa. Không ai cùng sửa một dòng, các thay đổi ghép lại gọn gàng và không có thông báo xung đột. Nhưng chính lúc này lỗi đổi tên trường của chúng ta xuất hiện: bộ lọc đọc done, phần xuất đọc completed nên kết quả trống. Bài kiểm tra của cả hai phần vẫn đạt vì mỗi bên chỉ kiểm tra phần riêng với dữ liệu riêng.

Hãy nhìn mũi tên phía dưới trong sơ đồ. Nửa trên mô tả điều thường được gọi là chia việc: hai phần độc lập nằm trong các file riêng. Còn kết luận về mức độ sẵn sàng nằm ở bước bên dưới, trong kịch bản chạy qua cả hai phần cùng lúc. Chừng nào chưa chạy xong bước này, bạn chỉ có hai kết quả riêng lẻ chứ chưa có kết quả chung. Nếu quy tắc của project yêu cầu chạy đầy đủ bộ kiểm tra, kịch bản chung không thay thế yêu cầu đó.

Chốt quyết định chung

Sau khi ghép mã, người phụ trách kết quả chung sẽ chọn bước tiếp theo. Ví dụ:

1. Chấp nhận kết quả chung: kịch bản chạy đạt, các thay đổi đều giải thích được và đáp ứng tiêu chí.
2. Gửi một phần cụ thể đi chỉnh sửa, nói rõ điểm nào không khớp với điều gì. Đừng nói "phần xuất có gì đó lạ", hãy nói "phần xuất đọc trường không còn tồn tại trong mô hình".
3. Xem lại cách chia việc: giảm số người thực hiện hoặc chuyển các phần sang làm tuần tự.

Chọn phương án thứ ba cũng bình thường, không phải thất bại. Bạn sẽ nhận ra khá nhanh các dấu hiệu cho biết đã đến lúc xem lại cách phân công:

• định dạng chung của mục liên tục thay đổi, và mỗi lần như vậy cả hai phần đều phải sửa lại;
• những người thực hiện phải chờ nhau - nghĩa là có phụ thuộc nhưng chưa được nêu ra;
• kết quả được gửi về nhanh hơn tốc độ bạn đọc chúng.

Dấu hiệu cuối khó chịu nhất vì nhìn bên ngoài có vẻ như thành công. Một lần chia việc hiệu quả chưa đủ để kết luận đó là quy luật: kết quả của agent thay đổi giữa các lần chạy, nên hãy thử lại trên một nhiệm vụ tương tự trước khi đưa ra kết luận quan trọng.

Kết quả một phần cũng là kết quả bình thường. Bộ lọc có thể đã hoàn tất và được kiểm tra, còn phần xuất thì chưa; hãy ghi đúng như vậy: một trong hai phần đã xong. Nhiệm vụ chung vẫn còn mở. Không thể xem là hoàn thành chỉ vì một nửa đã chạy được, dù bạn có phân công cẩn thận đến đâu.

Tự kiểm tra

Hai tình huống. Trước tiên hãy tự trả lời, rồi mới đối chiếu.

Chưa tìm ra nguyên nhân lỗi.
Đôi khi phần xuất tạo ra file trống, và bạn muốn giao ngay việc sửa lỗi cho hai người thực hiện. Hãy bắt đầu bằng cách tái hiện lỗi và tìm hiểu nguyên nhân. Nếu tìm ra các giả thuyết khác nhau có thể kiểm tra, bạn có thể giao mỗi giả thuyết cho một người thực hiện. Nhưng chỉ đề xuất hai cách sửa mà không có căn cứ thì chưa giải quyết được vấn đề: cần liên kết từng cách sửa với nguyên nhân và kiểm tra bằng kịch bản ban đầu.

Hai file khác nhau, nhưng cùng một con số.
Bộ lọc đếm số sản phẩm theo từng món, còn phần xuất ghi cùng số lượng đó theo gói. Bài kiểm tra của cả hai phần đều đạt, nhưng con số trên màn hình và trong file không khớp. Đây không phải lỗi mã: không phần nào vượt ra ngoài phạm vi của mình. Vấn đề là chưa thống nhất đơn vị đo. Hãy ghi rõ đơn vị trong mô hình chung trước khi bắt đầu; người phụ trách ghép mã sửa src/item-model.js, sau đó chạy lại kịch bản chung.

Claude Code có thể đảm nhận phần nào

Như đã nói ở đầu bài viết, agent có thể đề xuất cách chia việc và dựa trên các gạch đầu dòng của bạn để soạn một nhiệm vụ mạch lạc. Ngoài ra, agent còn hữu ích ở ba điểm sau, còn quyết định vẫn thuộc về bạn:

• Bản nháp sơ đồ phạm vi. Yêu cầu agent duyệt qua project và đề xuất file nào cần thay đổi cho từng phần việc, kèm đường dẫn. Đây chỉ là bản nháp: bạn sẽ chỉ định người phụ trách từng phạm vi.
• Ghép mã và chạy kịch bản chung. Agent sẽ ghép các phần, hiển thị danh sách đầy đủ các thay đổi và chạy kịch bản chung. Sau đó, hãy tự mình xem lại toàn bộ thay đổi.
• Điểm còn tranh luận. Hai lời giải thích chắc chắn không có nghĩa là quyết định đã được chấp thuận. Hãy yêu cầu căn cứ, file và dòng cụ thể; người sửa file chung phải được xác định trước trong bảng phân công, chứ không dựa vào việc câu trả lời của ai nghe thuyết phục hơn.

Cuối cùng, mọi thứ dựa trên một quyết định và hai vai trò được phân công. Quyết định là có nên chia việc không: lợi ích từ mỗi người thực hiện bổ sung phải xứng đáng với thời gian giao việc, kiểm tra và ghép kết quả. Hai vai trò gồm người phụ trách mỗi phạm vi thay đổi và người chịu trách nhiệm về kết quả chung. Trong câu chuyện danh sách mua sắm, điều còn thiếu chính là những việc này: chưa thống nhất trường completed và cũng chưa chỉ định ai chạy bộ lọc cùng phần xuất dữ liệu. Công cụ giúp xử lý phần việc cơ học; còn con người vẫn phải kết luận liệu hành vi sau khi ghép có đúng với yêu cầu hay không.