AI in practiceSeptember 22, 2026 · 7 min read

Đội Agent Của Tôi: PM Thời AI

Mấy tuần nay, mỗi sáng mở máy lên, việc đầu tiên tôi làm không phải là viết code hay soạn tài liệu, mà là hỏi một câu: đêm qua đội của tôi đã làm được gì. Đội ở đây không phải người. Đó là một Active Lead ngồi điều phối, và hai đứa worker cắm cúi build. Tôi vẫn là người quyết định làm gì, nhưng phần chia việc, theo dõi tiến độ, nhắc ai đang rảnh tay, giờ có một lớp trung gian lo giúp.

Tôi làm PM đủ lâu để biết cảm giác một dự án chạy tốt là gì, không phải vì không ai bận, mà vì không ai đứng yên chờ việc, và không có việc nào trôi mà không ai chịu trách nhiệm theo dõi. Hóa ra dựng một đội AI cũng chỉ là bài toán y hệt vậy, chỉ khác là người thợ không cần ngủ.

Active Lead: người trực ca, không phải người thay tôi quyết định

Active Lead là vai tôi giao cho mô hình AI đứng đầu ca. Nó không tự bịa việc ra làm. Nó theo dõi hàng đợi công việc tôi đã duyệt, xem worker nào đang rảnh, xem còn bao nhiêu ngân sách xử lý (quota) trong tuần để không tiêu quá tay, rồi tự quyết định giao gì tiếp theo. Giống hệt một trưởng nhóm ca sáng: không cần hỏi sếp từng việc nhỏ, nhưng biết rõ việc nào vượt thẩm quyền của mình.

Ranh giới đó tôi vạch rõ từ đầu. Active Lead được tự xử lý trong phạm vi dự án đã duyệt, tự ghép code worker làm xong vào môi trường thử để tôi coi, tự quyết định khi nào cần chạy bộ test toàn diện. Nhưng có những việc nó không bao giờ tự bấm: động vào dữ liệu thật trên production, gửi tin nhắn ra ngoài, hoặc sửa yếu một bài test đang bảo vệ hệ thống. Những việc đó luôn quay lại hỏi tôi, ngay tại thời điểm sắp làm, không phải từ một cái gật đầu từ tuần trước. Tôi thích cách chia này vì nó giống hệt cách tôi phân quyền cho một Delivery Lead giỏi trong đời thật: tin tưởng họ xử lý vận hành hằng ngày, nhưng giữ lại quyền bấm nút ở những chỗ không thể làm lại.

Giao việc cho Worker: brief trước, code sau

Worker của tôi là hai công cụ coding-agent, mỗi đứa nhận một nhánh việc riêng, làm trong một bản sao code riêng để không dẫm chân nhau. Trước khi worker gõ dòng code nào, luôn có một brief: phạm vi làm gì, không được đụng vào đâu, tiêu chuẩn nào coi là xong. Không có brief rõ, không giao việc. Đó cũng là việc tốn thời gian nhất trong toàn bộ quy trình, nhưng là phần không thể cắt, giống hệt viết ticket tử tế cho một developer trong đời thật, làm ẩu phần này thì cả chuỗi sau trả giá.

Worker làm xong tự chạy một cổng kiểm tra của riêng nó: định dạng code, kiểm tra kiểu dữ liệu, lỗi cú pháp, và bộ test tự động. Chỉ khi cổng đó xanh, kết quả mới đứng vào hàng chờ tôi duyệt. Và một nguyên tắc tôi giữ rất chặt: ai tìm ra lỗi thì không tự sửa lỗi đó. Nếu Active Lead phát hiện một chỗ sai, một worker viết bài test chứng minh nó sai, Active Lead kiểm lại test đó đúng bệnh, rồi một worker khác mới viết phần sửa. Người viết không bao giờ là người tự chấm điểm cho mình, y hệt nguyên tắc tách dev và QA tôi áp dụng trong nghề từ trước giờ.

Bảng Kanban: không đứa nào được đứng yên

Tôi có một bảng worker cập nhật mỗi giây, mở ra là thấy ngay ai đang làm gì. Nó có 5 cột kiểu Kanban quen thuộc, chỉ khác là người kéo thẻ không phải con người. Các thẻ dưới đây là ví dụ minh họa, không phải việc thật:

Cần làm

Đang làm

Đang test

Chờ duyệt

Xong

Cần làm là việc đã có brief chờ worker rảnh; Đang làm kèm thời gian đã chạy; Đang test là bộ kiểm tra tự động; Chờ duyệt là đã xanh cổng kiểm tra, chờ tôi hoặc Active Lead coi qua; Xong là đã gộp vào code chính. Thẻ chỉ đi một chiều từ trái sang phải.

Phía trên bảng luôn có một dòng nhỏ: Active Lead đang làm gì, sắp làm gì, và đang chờ tôi quyết định chuyện gì, cộng thêm phần trăm ngân sách xử lý đã dùng trong tuần. Tôi liếc bảng này y hệt cách tôi liếc board Jira của một nhóm thật: không phải để soi việc, mà để thấy ngay chỗ nào đang ứ đọng.

Luật duy nhất tôi đặt ra: worker nào vừa xong việc phải có việc tiếp theo ngay trong lượt đó, không được ngồi chờ. Nếu chưa có việc mới đủ sẵn sàng, nó chuyển sang đọc và phản biện lại việc một worker khác vừa làm, còn hơn để năng lực chạy không tải. Đó là cái tôi học từ nghề quản lý năng lực đội nhóm, áp sang cho một đội không bao giờ buồn ngủ.

Vì sao PM biết dùng AI sẽ có lợi thế

Nhiều người nghĩ dùng AI giỏi là biết viết prompt hay. Tôi nghĩ khác. Cái quyết định không phải câu lệnh gõ vào ô chat, mà là những thứ một PM đã luyện cả chục năm: cắt một việc lớn thành những phần đủ nhỏ để giao, viết tiêu chí nghiệm thu rõ đến mức không còn chỗ hiểu lầm, xếp thứ tự việc nào phụ thuộc việc nào, giữ một cổng kiểm tra trước khi cho qua, và biết chính xác chỗ nào mình phải đứng ra chịu trách nhiệm chứ không được đẩy xuống.

Đó chính là những thứ đang vận hành cái đội AI của tôi, không thêm không bớt. Một kỹ sư giỏi có thể dạy AI viết code tốt hơn tôi. Nhưng ai quản lý nhiều việc chạy song song, ai biết lúc nào cần siết lượng kiểm tra và lúc nào được đi nhanh, ai biết tách người làm và người kiểm ra hai vai khác nhau, đó là bản năng của nghề quản lý dự án, không phải của nghề code.

Tôi không nghĩ AI thay thế PM. Tôi nghĩ nó làm rõ ai đang thật sự giỏi quản lý. Một PM chỉ quen họp và điền status sẽ thấy AI là mối đe dọa, vì nó không biết giao việc cho một thứ không biết phản ứng bằng cảm xúc. Còn một PM quen cắt việc, quen ra quyết định dựa trên bằng chứng, quen biết khi nào nên tin và khi nào phải kiểm tra lại, sẽ thấy mình vừa có thêm một đội không bao giờ nghỉ phép.

Kết

Tối qua tôi đóng laptop lúc trẻ con đã ngủ, liếc lại bảng worker lần cuối thấy mọi thứ vẫn đang chạy đều, không có gì phải can thiệp. Cảm giác đó không phải hào hứng gì lớn lao, chỉ là yên tâm. Và tôi nghĩ đó mới là thứ đáng theo đuổi, không phải một đội AI làm việc nhanh hơn người, mà là một cách làm việc không còn làm tôi mất ngủ.

Bài liên quan: Managing AI Like a Team, Not a Tool, viết hồi tháng 9 về nền móng của cả hệ thống này.

Nguyễn Hải Nam

Nguyễn Hải Nam

Project Management Lead. 16+ years from code to delivery. PMP®. Writing here about project management and engineering.

About me
← The Bug That Couldn't Exist Until Production Existed