Giải Đúng Bài Toán Trong Kỷ Nguyên AI Tác Nhân: Khuôn Khổ 6 Bước Trước Khi Triển Khai

Trước khi AI xuất hiện, năng lực triển khai phần mềm là thứ khan hiếm. Một yêu cầu tồi có thể làm lãng phí thời gian của vài kỹ sư. Ngày nay, với sức mạnh của AI tác nhân, năng lực đó đã tăng lên gấp bội. Một yêu cầu tồi giờ đây có thể tạo ra hàng trăm thay đổi sai lệch với chi phí rất rẻ. Do đó, điểm nghẽn của quy trình phát triển đã dịch chuyển lên phía thượng nguồn: đến việc xác định vấn đề, bối cảnh, ràng buộc cũng như các quyết định và sự xác thực. Nếu hướng đi đã sai, mọi tốc độ tăng thêm chỉ giúp bạn đến nơi sai nhanh hơn gấp mười lần mà thôi.

Bài viết này giới thiệu một khuôn khổ thực tế nhằm giảm thiểu sự không chắc chắn trong các dự án phần mềm, đặc biệt là khi có sự tham gia của các tác nhân AI. Điều này giúp chúng ta xây dựng đúng thứ (giải pháp giải quyết đúng vấn đề thực tế), theo đúng cách (không lãng phí tiền bạc, thời gian hay nguồn lực) và một cách hiệu quả nhất có thể (rõ ràng trong suốt quá trình phát triển để tránh phải làm lại).

Vì sao điều này lại quan trọng?

Những vấn đề khó khăn nhất trong phát triển phần mềm hiếm khi thuần túy là kỹ thuật. Chúng thường xoay quanh khâu giao tiếp và sự liên kết giữa các bên liên quan. Ngay cả những kỹ sư giỏi nhất cũng khó lòng cứu vãn một dự án nếu các bên không thống nhất được họ đang xây dựng cái gì, tại sao và cho ai. Sự thiếu liên kết này làm chậm nhịp độ nhóm và khiến những kỹ sư giỏi kiệt sức vì thiếu định hướng rõ ràng.

Khi đưa các tác nhân AI vào, rủi ro này càng lớn hơn. Một kỹ sư đi sai hướng trong một ngày có thể chỉ gây ra thiệt hại giới hạn. Nhưng chính kỹ sư đó nếu triển khai cả một đội quân agent thì có thể gây ra hậu quả lớn hơn nhiều, và nhanh hơn nhiều: một giả định sai không chỉ dừng lại trong một tệp tin, mà nó có thể bị sao chép vào mọi thay đổi do agent tạo ra và đụng đến cùng một mô hình trước khi con người kịp xem xét.

Bạn sẽ không xây một ngôi nhà mà không có bản thiết kế. Vậy tại sao lại xây dựng một dự án phần mềm mà không có sự chuẩn bị kỹ lưỡng?

Đúng là điều này đòi hỏi sự đầu tư ban đầu. Nhưng câu nói "chúng ta không có thời gian cho việc đó" thường trở thành một câu nói rất đắt giá khi bạn tính đến chi phí cho việc vi phạm tuân thủ, tổn hại danh tiếng, mất lợi thế cạnh tranh và việc phải làm lại ở quy mô lớn.

Chiến lược dữ liệu

Chi phí của việc sai lầm

Không phải quyết định nào cũng xứng đáng nhận được cùng một mức độ phân tích. Một nguyên tắc cốt lõi của khuôn khổ này là: Quyết định nào càng khó đảo ngược, bạn càng nên loại bỏ nhiều sự không chắc chắn trước khi đưa ra quyết định đó.

Ví dụ, việc chọn nhãn cho một nút bấm là một quyết định dễ dàng thay đổi. Hãy quyết định nhanh và có thể điều chỉnh sau. Ngược lại, việc chọn một hợp đồng dữ liệu (data contract), ranh giới hệ thống hay kiến trúc tích hợp có thể rất tốn kém để gỡ bỏ nếu sai. Đó mới là nơi cần sự xem xét kỹ lưỡng. Điều này không có nghĩa là dự đoán mọi thứ từ đầu, mà là dành nỗ lực chuẩn bị cho những nơi mà một quyết định sai sẽ thực sự gây tổn hại và chủ động để những phần khác được linh hoạt.

Khi nào nên sử dụng khuôn khổ này?

Không phải mọi thay đổi phần mềm đều cần đến sáu tài liệu. Một bản sửa lỗi (bug fix), một script nội bộ nhỏ hay một bản prototype dùng một lần thường không cần đến mức độ chuẩn bị này. Việc áp dụng khuôn khổ đầy đủ cho mọi thay đổi sẽ tạo ra sự quan liêu thay vì sự rõ ràng.

Khuôn khổ này trở nên hữu ích khi chi phí cho việc đi sai hướng là đáng kể. Hãy sử dụng nó khi có một vài điều sau đây là đúng:

• Nhiều bên liên quan hoặc nhiều nhóm cần phối hợp.
• Vấn đề hoặc kết quả mong muốn còn mơ hồ.
• Giải pháp phụ thuộc vào các hệ thống, dữ liệu hoặc ràng buộc tổ chức hiện có.
• Các quyết định kiến trúc hoặc dữ liệu quan trọng sẽ tốn kém để đảo ngược.
• Nhiều người hoặc nhiều tác nhân AI sẽ làm việc song song.
• Một sai lầm có thể gây ra thiệt hại đáng kể về tài chính, vận hành, tuân thủ hoặc danh tiếng.
• Dự án đủ lớn để việc làm lại có thể ảnh hưởng đáng kể đến kết quả.

Khuôn khổ này không nhằm mục đích tạo ra sáu tài liệu hoàn hảo, mà là để giảm thiểu sự không chắc chắn quan trọng trước khi bắt đầu triển khai. Nó cũng không thay thế cho việc thử nghiệm (experimentation). Khi một giả định còn mơ hồ, một prototype hay thử nghiệm nhỏ có thể là cách nhanh nhất để giảm sự không chắc chắn đó. Kết quả của thử nghiệm nên được phản hồi vào bước liên quan thay vì âm thầm thay đổi hướng đi của dự án.

Kiến trúc phân lớp

Khuôn khổ 6 bước: Từ Rủi ro thành Tài sản

Khuôn khổ Chuẩn bị Dự án này hoạt động bằng cách hệ thống hóa việc giảm thiểu sự không chắc chắn thông qua từng lĩnh vực quyết định. Mỗi bước xây dựng dựa trên bước trước, đưa những câu hỏi hệ trọng nhất lên phía trước trong khi chi phí thay đổi vẫn còn thấp. Các diễn giải, giả định, quyết định và lý do sẽ được ghi chép trong một tệp dùng chung mà các bên liên quan có thể xem xét.

Khuôn khổ này mang tính tuần tự, nhưng không phải là mô hình thác nước (waterfall). Việc khám phá ở các bước sau có thể làm cho một quyết định trước đó không còn hiệu lực. Khi điều đó xảy ra, hãy quay lại, cập nhật tài liệu bị ảnh hưởng và làm rõ sự thay đổi quyết định đó. Mục tiêu là ngăn chặn sự thay đổi không được thừa nhận, chứ không phải ngăn chặn mọi thay đổi.

Bước	Tài liệu	Mục đích
1. Điều kiện tiên quyết về Kinh doanh	PID.md	Thống nhất về vấn đề kinh doanh, phạm vi, tổ chức, mục tiêu
2. Điều kiện tiên quyết về CNTT	discovery-report.md	Hiểu rõ dữ liệu, hệ thống hiện có (khả thi, rủi ro, ràng buộc)
3. Yêu cầu chức năng	functional-requirements.md	Xác định những gì giải pháp phải làm
4. Yêu cầu kỹ thuật	technical-requirements.md	Xác định cách giải pháp sẽ hoạt động
5. Quản trị	governance.md	Xác định ai tham gia, ai quyết định và ai chịu trách nhiệm
6. Kế hoạch	roadmap.md	Xác định thời điểm, thứ tự thực hiện và người thực hiện

Bốn bước đầu tiên thiết lập những gì chúng ta biết và những gì chúng ta dự định xây dựng. Các bước này đã bao gồm các quyết định và quyền sở hữu quyết định. Do đó, bước 5 (Quản trị) không tạo ra sự quản trị mới, mà biến cấu trúc quyết định đã được thiết lập ở trên thành một thỏa thuận rõ ràng cho quá trình xây dựng, ra mắt và vận hành giải pháp. Mọi người có thể thách thức một quyết định, nhưng sự bất đồng nên dẫn đến việc người sở hữu quyết định đưa ra lựa chọn cuối cùng, thay vì để quyết định đó nằm im trong hộp thư của ai đó.

Đi sâu vào chi tiết từng bước

Bước 1: Điều kiện tiên quyết về Kinh doanh

Đây là bước giải quyết một trong những thất bại đắt giá nhất của dự án: giải sai bài toán. Bước này đảm bảo bạn tập trung vào vấn đề kinh doanh thực sự mà các bên liên quan mong muốn được giải quyết, với phạm vi rõ ràng. Nó giúp đạt được sự đồng thuận và liên kết sớm, ngăn chặn sự lãng phí công sức vào những thứ không ai cần. Các kỹ sư đọc tài liệu này sẽ hiểu được "lý do" đằng sau công việc của họ, giúp việc ra quyết định hàng ngày dễ dàng hơn và giảm bớt sự mơ hồ.

Một câu chuyện điển hình: Khách hàng từng yêu cầu khẩn cấp một webhook. Nhóm phát triển đã bỏ hết công việc khác để xây dựng. Khi hoàn thành, hóa ra khách hàng không thực sự biết webhook là gì và họ cần một API. Kết quả là một giải pháp kỹ thuật hoàn hảo cho một vấn đề không tồn tại.

Bài học kinh nghiệm: Khách hàng sở hữu vấn đề, bạn sở hữu giải pháp. Nếu bạn để khách hàng định nghĩa giải pháp, bạn đang không làm đúng công việc của mình. Một cuộc phỏng vấn ngắn về các mục tiêu kinh doanh có thể phát hiện ra điều này ngay lập tức. Cách thực hiện là tạo một tài liệu PID.md xác định vấn đề, mục tiêu, người dùng và thước đo thành công.

Bước 2: Điều kiện tiên quyết về CNTT

Hầu như mọi giải pháp đều phải tích hợp với các hệ thống và quy trình hiện có. Mức độ thành công của nó phụ thuộc rất lớn vào những gì hệ thống sẵn có có thể hỗ trợ. Bước này đánh giá tính khả thi của việc giải quyết vấn đề trong môi trường hiện tại bằng cách hiểu rõ dữ liệu, hệ thống và các phụ thuộc. Mục tiêu là đảm bảo mọi bên liên quan đều biết những gì khả thi và không khả thi trước khi bắt đầu phát triển.

Một tình huống khác, nhóm đã dành vài sprint để xây dựng một hệ thống xử lý dữ liệu thời gian thực cho một dashboard. Hóa ra nguồn dữ liệu không thể cung cấp dữ liệu thời gian thực mà chỉ có dữ liệu theo mẻ (batch) mỗi 12 giờ. Sản phẩm hoạt động hoàn hảo nhưng không thể kết nối với hệ sinh thái hiện có của công ty. Đây chính là loại thất bại mà bạn muốn phát hiện ra sớm nhất có thể để tránh việc "đóng một chuyến tàu cho một tổ chức không có đường ray".

Bước 3: Yêu cầu chức năng

Sau khi đã hiểu rõ bối cảnh kinh doanh và CNTT, chúng ta cần xác định những gì giải pháp phải thực sự làm được. Cần thấu hiểu người dùng, hành vi mong đợi, tần suất sử dụng và phạm vi trước khi tối ưu hóa việc triển khai. Các câu chuyện người dùng (user stories) rất hữu ích trong bước này. Một mô tả rõ ràng về tính năng cũng giúp bước tiếp theo (Kỹ thuật) dễ dàng hơn nhiều.

Đây là bước thường bị bỏ qua nhất. Các kỹ sư đam mê thường bị cuốn theo những gì khả thi về mặt kỹ thuật và đánh mất những gì khách hàng thực sự yêu cầu là gì. Ví dụ, nhóm đã dành hơn 100 giờ để tự động hóa hoàn toàn một quy trình mà mọi người đều tin là cần thiết, kèm theo một giao diện đẹp mắt. Hóa ra quy trình đó chỉ tốn 10 phút làm thủ công mỗi tháng một lần. Và vì khách hàng chính là các nhà phát triển, họ chỉ muốn một API chứ không bao giờ có ý định dùng giao diện người dùng. Kết quả là giao một chiếc Ferrari với giá của chiếc Ferrari trong khi khách hàng chỉ cần một chiếc xe đạp.

Bước 4: Yêu cầu kỹ thuật

Với các tài liệu từ các bước trước, phần lớn sương mù đã được dỡ bỏ và hướng đi cho các lựa chọn kỹ thuật đã khá rõ ràng. Bước này biến điều đó thành một kế hoạch cụ thể và đưa ra các lựa chọn kỹ thuật có chủ đích. Kiến trúc nên được quyết định trước khi bắt đầu viết code, không phải trong lúc viết.

Một câu chuyện về "ca phẫu thuật tim hở" trên cơ sở dữ liệu: Nhóm đã chọn PostgreSQL vì đó là lựa chọn mặc định của team. Mãi sau này họ mới phát hiện ra mô hình miền (domain model) về cơ bản là khác nhau giữa các khách hàng và thay đổi thường xuyên. Họ đã mã hóa sâu những giả định này vào lược đồ và ứng dụng. Việc di chuyển sau đó rất khó khăn, không phải vì PostgreSQL là một cơ sở dữ liệu tồi, mà vì họ đã đưa ra một quyết định kiến trúc đắt đỏ trước khi hiểu rõ về miền (domain). Công cụ phù hợp không phải là công cụ bạn biết rõ nhất, mà là công cụ phù hợp nhất với vấn đề.

Một câu hỏi hữu ích cho mọi quyết định lớn trong bước này là: "Nếu chúng ta sai về điều này, chi phí để thay đổi sau này là bao nhiêu?"

Bước 5: Quản trị

Đến đây, vấn đề kinh doanh, môi trường, yêu cầu chức năng và hướng kỹ thuật đã được xem xét kỹ lưỡng. Đã đến lúc làm rõ cấu trúc quyết định cho việc triển khai. Nếu không có quản trị rõ ràng, ngay cả những kế hoạch tốt nhất cũng sẽ sụp đổ vì sự nhầm lẫn, chậm trễ và thiếu trách nhiệm giải trình.

Một dự án đã bị đình trệ hàng tuần vì không ai biết ai có quyền phê duyệt một thay đổi thiết kế quan trọng. Yêu cầu cứ luân chuyển trong các chuỗi email giữa ba nhóm, mỗi nhóm đều cho rằng nhóm khác có thẩm quyền. Khi tìm đúng người thì thời hạn đã qua từ lâu. Quyết định bị mắc kẹt trong tình trạng lấp lửng và chết ở đó khi không ai chắc chắn ai là người đưa ra quyết định. Sử dụng ma trận RACI (Responsible, Accountable, Consulted, Informed) trong tài liệu governance.md để làm rõ vai trò và trách nhiệm sẽ giúp dự án luôn tiến về phía trước.

Bước 6: Lập kế hoạch

Ở bước này, bạn đã hiểu đủ về những gì cần xây dựng và các ràng buộc. Bây giờ, hãy chia giải pháp thành các nhiệm vụ có thể thực hiện được với sự phụ thuộc, mốc thời gian và người phụ trách rõ ràng. Mục tiêu là một lộ trình với các nhiệm vụ rõ ràng, cho phép các tác nhân AI hoặc đồng nghiệp làm việc song song một cách hiệu quả.

Nếu bỏ qua bước này, bạn sẽ có các nhóm chờ đợi lẫn nhau, các nhiệm vụ quá lớn hoặc quá mơ hồ và chắc chắn sẽ trễ hạn. Một dự án từng thất bại vì mọi người bắt tay vào làm ngay mà không ai lập bản đồ các phụ thuộc: hai nhà phát triển xây dựng các tính năng phụ thuộc vào một API chưa được thiết kế. Một nhóm khác thì tích hợp với một giao diện sau đó bị thay đổi. Khi phát hiện ra vấn đề, nhiều người phải dừng lại, hủy bỏ công việc đã làm và làm lại theo đúng thứ tự. Một nhiệm vụ tốt cần đủ nhỏ để hiểu, có kết quả rõ ràng và thể hiện rõ sự phụ thuộc của nó với các nhiệm vụ khác.

Các tác nhân AI

Tổng hợp lại: Khuôn khổ trong thực tế

Hãy xem xét một tổ chức muốn xây dựng một hệ thống hỗ trợ AI để xử lý các hồ sơ đến. Yêu cầu ban đầu nghe có vẻ đơn giản: "Dùng AI để đọc các tài liệu đến, trích xuất thông tin liên quan và tự động quyết định cách xử lý từng hồ sơ."

Nếu triển khai ngay, dự án sẽ thất bại theo những cách rất quen thuộc. Vài tuần sau, các tài liệu nguồn hóa ra lại không nhất quán, dữ liệu chính nằm trong một hệ thống khác, và các nhân viên xử lý hồ sơ không hề muốn AI đưa ra quyết định thay họ. Họ chỉ muốn một công cụ giúp tìm kiếm thông tin bị thiếu và sắp xếp thứ tự ưu tiên công việc. Bộ phận pháp lý lại yêu cầu phải có con người trong quy trình (human-in-the-loop), điều mà kiến trúc ban đầu rất khó để bổ sung.

Nếu áp dụng khuôn khổ này, mọi bất ngờ đó sẽ được phát hiện ra trước khi chúng trở nên đắt đỏ:

• Bước 1 (Kinh doanh) sẽ cho thấy vấn đề thực sự không phải là "tự động hóa quyết định" mà là "giảm thời gian chuẩn bị thủ công trong khi vẫn giữ cho nhân viên xử lý nắm quyền kiểm soát".
• Bước 2 (CNTT) sẽ phát hiện ra sự không nhất quán của dữ liệu và mô hình định danh mà giải pháp phải tuân thủ.
• Bước 3 (Chức năng) sẽ cắt giảm phạm vi xuống còn phân loại, tóm tắt và khả năng truy vết, loại bỏ việc ra quyết định tự động không cần thiết.
• Bước 4 (Kỹ thuật) sẽ đưa yêu cầu "con người trong quy trình" vào kiến trúc ngay từ đầu thay vì phải gắn thêm sau.
• Bước 5 (Quản trị) sẽ gán quyền sở hữu để câu hỏi "AI có được phép quyết định không?" có câu trả lời trước khi nó được đặt ra trong sản xuất.
• Bước 6 (Kế hoạch) sẽ sắp xếp công việc để các giả định về chất lượng tài liệu được xác thực trước khi nhóm mở rộng quy mô.

Kết luận

AI làm cho việc triển khai trở nên rẻ và nhanh hơn. Vậy nên, việc quyết định triển khai cái gì lại càng trở nên quan trọng hơn. Năng lực triển khai nhanh này chỉ có giá trị khi nó được hướng vào đúng vấn đề. Khuôn khổ Chuẩn bị Dự án này không loại bỏ sự không chắc chắn, mà giúp các nhóm tìm ra sự không chắc chắn thực sự quan trọng và giải quyết nó ở mức tối đa trong khi chi phí thay đổi còn rẻ.

Sự phát triển phần mềm với các tác nhân AI không làm thay đổi bản chất của kỹ thuật phần mềm tốt. Nó chỉ làm tăng cái giá phải trả cho việc làm sai mà thôi. Việc xây dựng những tài liệu rõ ràng, có thể chia sẻ không chỉ cho con người mà còn cho chính các tác nhân AI hành động là chìa khóa để đạt được sự liên kết và tránh được sự đoán mò, làm lại và những bất ngờ không đáng có.

Bạn có thể thử áp dụng khuôn khổ này cho dự án sắp tới của mình tại repo GitHub của tác giả (Project Preparation Framework). Việc đầu tư thời gian để hiểu đúng vấn đề và thống nhất cách làm trước khi viết code chưa bao giờ quan trọng đến thế.