Cách quản lý dự án hiệu quả với AI

Quy trình quản lý dự án đã thay đổi rất nhiều trong thời đại LLM. Về cơ bản, cách chúng ta thực hiện công việc cũng như cách phát triển một sản phẩm và hoàn thành các nhiệm vụ kỹ thuật đã thay đổi hoàn toàn.

Trong bài viết này, tôi sẽ chia sẻ cách quản lý dự án hiệu quả trong thời đại AI, từ việc điều phối và xác định những công việc có thể thực hiện, cho đến cách xử lý từng nhiệm vụ để hoàn thành chúng nhanh và hiệu quả nhất.

Vì sao quản lý dự án đã thay đổi?

Lý do chính khiến quản lý dự án thay đổi trong thời đại LLM là cách chúng ta phân bổ thời gian cho từng nhiệm vụ đã thay đổi căn bản. Trước đây, thời gian của một kỹ sư phần mềm có thể được phân bổ tương đối như sau:

Tất nhiên, con số 30% thời gian được giải phóng chỉ là một ước tính. Khoảng thời gian này có thể được dành cho việc tìm hiểu những chủ đề mới, khởi chạy thêm agent, hoàn thành nhiều công việc hơn, kiểm thử nền tảng kỹ lưỡng hơn và nhiều nhiệm vụ khác.

Nói ngắn gọn, quản lý dự án đã thay đổi vì những thứ chúng ta dành thời gian thực hiện cũng thay đổi. Điều này đòi hỏi những cách tối ưu hóa mới để sử dụng thời gian hiệu quả nhất. Trong bài viết này, tôi sẽ tập trung vào cách một kỹ sư phần mềm có thể quản lý thời gian và dự án tốt hơn để hoàn thành được nhiều công việc hơn.

Ở đây, khi nói đến quản lý dự án, tôi chủ yếu đề cập đến khoảng thời gian một kỹ sư phần mềm dành cho những dự án khác nhau, cách quyết định nên làm dự án nào và cách tổ chức công việc để hoàn thành chúng.

Quản lý dự án hiệu quả trong thời đại AI

Dưới đây là những kỹ thuật tôi áp dụng để tận dụng LLM tốt nhất và làm việc hiệu quả hơn trong các dự án. Những phương pháp này không nhất thiết phù hợp hoàn toàn với mọi dự án, vì vậy điều quan trọng là bạn nên hiểu nguyên tắc phía sau và điều chỉnh chúng cho phù hợp với công việc của mình.

Lập kế hoạch công việc kỹ lưỡng hơn từ đầu

Điều đầu tiên tôi dành nhiều thời gian hơn trước đây là lập kế hoạch cho công việc ngay từ đầu. Nhiệm vụ của tôi thường đến từ một tin nhắn trên Slack, chẳng hạn phản hồi về sản phẩm hoặc báo lỗi, hoặc phát sinh từ một dự án đang thực hiện. Khi bắt đầu xử lý, tôi cố gắng hình dung và làm rõ công việc càng nhiều càng tốt trước khi giao cho agent.

Lý do là khi công việc được lập kế hoạch rõ ràng, agent có thể hoạt động tự động trong thời gian dài hơn mà không cần liên tục tương tác với con người.

Hãy tưởng tượng bạn giao cho agent một nhiệm vụ chưa được làm rõ, còn tồn tại nhiều điểm mơ hồ. Agent bắt đầu viết code và xử lý công việc, nhưng sớm muộn cũng gặp một vấn đề mà nó không biết nên giải quyết thế nào. Vì những điểm chưa rõ chưa được thống nhất từ đầu, agent phải dừng lại và hỏi bạn. Sau đó, rất có thể nó sẽ tiếp tục gặp những vấn đề tương tự và phải dừng lại nhiều lần trước khi hoàn thành nhiệm vụ.

Đây rõ ràng không phải cách sử dụng thời gian tối ưu. Bạn không muốn liên tục giải đáp những điểm mơ hồ trong khi agent đang chạy. Tốt nhất là làm rõ chúng trước khi bắt đầu, để agent có thể tự hoạt động cho đến khi hoàn thành công việc, thường được xác định bằng việc code đã được đưa lên nhánh dev.

Vì vậy, mỗi khi giao nhiệm vụ cho agent, tôi cố gắng làm rõ càng nhiều vấn đề càng tốt trước đó. Tôi có thể tự suy nghĩ kỹ về nhiệm vụ hoặc trao đổi với một LLM để xác định những điểm còn chưa rõ. Sau đó, tôi yêu cầu agent liệt kê toàn bộ những vấn đề này trong một báo cáo HTML. Tôi xem qua từng mục và đưa ra lựa chọn của mình. Khi agent bắt đầu làm việc, nó đã có đủ thông tin để hoạt động tự chủ trong một khoảng thời gian dài.

Sử dụng lệnh /goal

Điểm quan trọng thứ hai trong cách tôi quản lý dự án là chủ động sử dụng lệnh /goal. Điều này liên quan trực tiếp đến việc lập kế hoạch và làm rõ công việc từ trước.

Về cơ bản, /goal là một hook được agent kích hoạt mỗi khi nó cho rằng mình đã hoàn thành nhiệm vụ. Hook này yêu cầu agent tự kiểm tra xem nó thực sự đã hoàn thành toàn bộ công việc được giao hay chưa. Nếu chưa, agent sẽ tiếp tục làm việc cho đến khi mọi thứ được xử lý xong.

Nói cách khác, đây là một cách buộc agent tiếp tục làm việc trong thời gian dài hơn thay vì dừng lại quá sớm.

Gần đây, đặc biệt khi sử dụng Opus 5, tôi nhận thấy nếu không dùng /goal, agent đôi khi không thực sự hoàn thành toàn bộ công việc. Tôi có cảm giác nó hơi "lười", thậm chí ở một mức độ nào đó còn lười hơn Opus 4.8 và chắc chắn lười hơn Fable 5.

Tất nhiên, việc coding agent cần một hook bên ngoài để tiếp tục làm việc không phải điều lý tưởng. Về lý thuyết, agent nên mặc định làm việc cho đến khi hoàn thành nhiệm vụ. Tuy nhiên, cho đến khi điều đó trở thành mặc định, /goal là một giải pháp nhanh và khá hiệu quả. Tôi gần như sử dụng /goal cho tất cả những nhiệm vụ kéo dài của mình.

Giảm thời gian kiểm thử ứng dụng không cần thiết

Một vấn đề khác tôi muốn đề cập là giảm thời gian dành cho việc kiểm thử ứng dụng. Điều này tiếp tục liên quan đến hai phương pháp ở trên: lập kế hoạch trước và sử dụng /goal.

Một trong những việc tôi dành nhiều thời gian hơn đáng kể kể từ khi LLM bắt đầu viết code thay mình chính là kiểm thử ứng dụng. Như tỷ lệ thời gian ở phần đầu bài viết cho thấy, thời gian tương đối dành cho kiểm thử của tôi đã tăng khoảng gấp đôi. Lý do đơn giản là lượng code và số lượng công việc được thực hiện cũng tăng lên, kéo theo nhu cầu kiểm thử nhiều hơn.

Khi kiểm thử trở thành nút thắt mới, cách hợp lý là tìm cách giảm tác động của nút thắt này. Tôi cố gắng tự động hóa quá trình kiểm thử nhiều nhất có thể bằng LLM có khả năng tương tác với trình duyệt.

Đây cũng là một lý do khác khiến việc lập kế hoạch công việc từ đầu rất quan trọng. Bạn cần nói rõ cho agent biết chính xác cách xác định một nhiệm vụ đã được thực hiện đúng hay chưa. Agent phải hiểu cụ thể và rõ ràng điều gì được xem là hoàn thành nhiệm vụ. Nếu không, rất khó để nó tự đánh giá liệu công việc đã thực sự hoàn tất hay chưa.

Thiết lập đơn giản mà tôi sử dụng là cung cấp Playwright MCP cho tất cả agent Claude Code và Codex, cho phép chúng khởi chạy máy chủ localhost, truy cập Chrome và kiểm thử ứng dụng trực tiếp trên trình duyệt.

Điều này giúp tôi tiết kiệm rất nhiều thời gian. Trong nhiều trường hợp, agent có thể tự phát hiện rằng khi nhấn một nút, ứng dụng chuyển đến trang 404, hoặc một nút khác không tạo ra hành vi như mong đợi. Nhờ đó, agent không chỉ nhìn thấy code mà mình đang viết mà còn có thể kiểm thử ứng dụng từ đầu đến cuối, xác nhận rằng sản phẩm thực sự hoạt động đúng như cả tôi và agent kỳ vọng.

Trong bài viết này, tôi đã chia sẻ cách quản lý dự án của mình thay đổi như thế nào trong thời đại LLM. Công việc của một kỹ sư phần mềm giờ đây đã khác đáng kể: tôi dành ít thời gian hơn cho việc viết code, nhiều thời gian hơn cho kiểm thử và đồng thời có thêm thời gian để làm những công việc khác hoặc đơn giản là khởi chạy thêm agent.

Bạn cũng nên xem xét lại toàn bộ cách thức quản lý dự án của mình. Phương pháp từng hiệu quả trước thời đại LLM có thể không còn phù hợp khi AI đã thay đổi đáng kể cách chúng ta thực hiện công việc. Nếu vẫn giữ nguyên tư duy quản lý cũ, bạn có thể đang bỏ lỡ một lượng lớn lợi ích về năng suất.

Hãy thử nghiệm những phương pháp mới trong quản lý dự án và tự động hóa càng nhiều công việc càng tốt. Khi LLM ngày càng mạnh và trở thành công cụ phổ biến, biết cách tổ chức công việc xung quanh chúng sẽ là một trong những yếu tố quan trọng giúp bạn khai thác tối đa sức mạnh của AI.