Ba “đấu trường yêu cầu” và cách chọn mức khám phá, thử nghiệm, đặc tả phù hợp trước khi đội ngũ bắt tay xây dựng.
Một trợ lý AI viết nội dung nội bộ, một hệ thống đọc hồ sơ tín dụng và một chatbot chăm sóc khách hàng không thể đi qua cùng một quy trình. Dự án thứ nhất cần học nhanh từ người dùng. Dự án thứ hai cần chứng minh từng yêu cầu. Dự án thứ ba phải vừa tích hợp hệ thống cũ, vừa thích nghi với cách nhân viên đang làm việc.
Điểm chung của cả ba không phải là công nghệ, mô hình hay phương pháp quản lý dự án. Điểm chung là chúng đều phải giải đúng bài toán kinh doanh.
Đây là chỗ nhiều sáng kiến AI doanh nghiệp trượt ngay từ đầu. Ta hỏi “dùng mô hình nào?”, “có làm RAG không?”, “agent cần bao nhiêu công cụ?” trước khi làm rõ ai đang gặp vấn đề gì, kết quả nào thật sự có giá trị và sai số nào có thể chấp nhận. Công nghệ chạy được không đồng nghĩa công việc đã tốt hơn.
Luận điểm chính của bài này rất đơn giản:
Kiến trúc yêu cầu tốt không phải là một quy trình cứng. Đó là một hệ thống hoạt động có trật tự, nhưng co giãn theo rủi ro, độ mới và bối cảnh của từng dự án AI.
Yêu cầu AI không tự nhiên xuất hiện
Trong cuộc họp khởi động, một bên thường nói: “Chúng tôi cần chatbot trả lời chính xác.” Câu này nghe như một yêu cầu, nhưng chưa đủ để đội kỹ thuật xây bất cứ thứ gì có thể nghiệm thu.
“Chính xác” trên tập câu hỏi nào? Câu trả lời phải dẫn nguồn hay chỉ cần đúng ý? Khi không chắc, hệ thống nên từ chối, hỏi lại hay chuyển cho người thật? Dữ liệu nào được phép đưa vào ngữ cảnh? Một câu trả lời sai về giờ mở cửa và một câu trả lời sai về quyền lợi bảo hiểm có cùng mức độ nghiêm trọng không?
Yêu cầu chỉ dần hiện ra khi đội ngũ thực hiện những hoạt động có chủ đích:
Khởi động và khoanh vùng: xác định vấn đề kinh doanh, mục tiêu, phạm vi, bên liên quan và ràng buộc.
Khám phá: quan sát công việc, phỏng vấn, đọc tình huống ngoại lệ và tìm các quy tắc đang nằm trong đầu nhân viên.
Tạo mẫu: dùng bản phác thảo, prompt, luồng hội thoại hoặc bản thử nhỏ để kiểm tra giả định.
Thiết kế giải pháp kinh doanh: phân vai giữa con người, AI, phần mềm sẵn có và quy trình vận hành.
Phát triển, đo lường và học lại: bàn giao từng phần, nhận phản hồi, cập nhật kho yêu cầu.
Các hoạt động này không nhất thiết chạy thành hàng dọc. Chúng có thể chồng lấn, lặp lại và trả thông tin ngược cho nhau. Điều quan trọng là tri thức thu được phải đi về một kho yêu cầu chung: backlog, story map, đặc tả, bộ tiêu chí đánh giá, nhật ký quyết định hoặc tổ hợp của chúng.
Nếu không có kho chung, mỗi phòng ban sẽ sở hữu một phiên bản “sự thật”. Vận hành nhớ các ngoại lệ. Pháp chế nhớ điều cấm. Nhóm dữ liệu nhớ giới hạn nguồn. Kỹ thuật nhớ hành vi của mô hình. Đến ngày nghiệm thu, mọi người mới phát hiện họ đã xây bốn sản phẩm khác nhau trong đầu. Đây cũng là lý do một mô hình mạnh vẫn có thể làm sai khi doanh nghiệp chưa xây được “bộ nhớ tổ chức” đủ rõ để AI làm việc.
Ba đấu trường yêu cầu cho dự án AI
Thay vì chọn quy trình theo thói quen của công ty, hãy nhìn dự án như một “đấu trường yêu cầu”. Ba mẫu dưới đây không phải ba chiếc hộp tuyệt đối. Chúng là ba điểm tham chiếu để đội ngũ quyết định nên dồn sức vào đâu.
1. Đấu trường khám phá nhanh: mới, mơ hồ, cần học sớm
Đây là kiểu dự án có cơ hội mới nhưng chưa ai biết trải nghiệm đúng trông như thế nào. Ví dụ: trợ lý AI hỗ trợ nhân viên marketing tạo bản nháp chiến dịch từ brief.
Tốc độ quan trọng, nhưng tốc độ không có nghĩa là viết code ngay. Cách nhanh nhất thường là nghĩ chậm ở bài toán, hành động nhanh ở thử nghiệm.
Đội ngũ vẫn cần một vòng khởi động ngắn để thống nhất:
Người dùng chính là ai?
Công việc nào đang tốn thời gian hoặc tạo nhiều lần sửa?
Kết quả mong đợi đo bằng thời gian, chất lượng hay tỷ lệ được chấp nhận?
Dữ liệu và hành vi nào nằm ngoài phạm vi?
Rủi ro nào buộc con người phải duyệt?
Sau đó, trọng tâm chuyển sang tạo mẫu. Một giao diện giả, một bộ prompt thủ công hoặc quy trình “người đóng vai AI” đôi khi đủ để kiểm tra giá trị trước khi xây hệ thống. Mục tiêu của prototype không phải chứng minh phần mềm chạy. Mục tiêu là xem kết quả có giúp người dùng hoàn thành công việc tốt hơn hay không.
Khi một lát cắt đã có ích, đội ngũ chuyển nó thành câu chuyện người dùng, tiêu chí chấp nhận và bộ đánh giá nhỏ; rồi mới phát triển bản tăng trưởng đầu tiên. Các ý tưởng không đạt giá trị có thể bỏ đi với chi phí thấp.
2. Đấu trường cần chứng minh: rủi ro cao, cần đặc tả và truy vết
Một hệ thống AI tham gia gợi ý chẩn đoán, đánh giá hồ sơ, kiểm soát an toàn hoặc xử lý nghiệp vụ chịu kiểm toán không thể sống bằng câu “demo thấy khá ổn”.
Ở đây, yêu cầu phải đủ hoàn chỉnh, đo được và truy vết được. Mỗi yêu cầu quan trọng cần nối tới:
nguồn chính sách hoặc nhu cầu nghiệp vụ;
dữ liệu và điều kiện áp dụng;
cách xác nhận yêu cầu là đúng;
cách kiểm thử việc triển khai;
người chịu trách nhiệm phê duyệt;
phương án xử lý khi hệ thống thiếu tự tin hoặc gặp trường hợp ngoài phân phối.
Đội ngũ dành nhiều công sức hơn cho khoanh vùng và khai phá chi tiết. Phỏng vấn, workshop, kịch bản, trường hợp biên và tiêu chí kiểm thử đều có vai trò lớn. Bộ đặc tả ở đây không phải thủ tục làm đẹp hồ sơ. Nó là chuẩn đối chiếu để chứng minh hệ thống đã làm đúng điều được phép làm.
Tạo mẫu vẫn hữu ích, nhưng không thay thế bằng chứng. Một prototype có thể giúp lộ ra cách người dùng hiểu sai một cảnh báo. Sau đó, phát hiện ấy phải quay về đặc tả, thiết kế và kế hoạch kiểm thử. Nếu cần đào sâu cách tổ chức nhiều lớp kiểm tra, bạn có thể đọc thêm bài Đừng chấm AI bằng một bài thi cuối kỳ.
3. Đấu trường thương mại điển hình: tích hợp mới với cũ
Phần lớn dự án AI doanh nghiệp nằm ở giữa hai cực trên. Ta không tạo mọi thứ từ số không, cũng không cần đóng băng toàn bộ đặc tả trước khi phát triển. Giải pháp thường là tổ hợp của mô hình có sẵn, dữ liệu nội bộ, phần mềm nghiệp vụ, nhân viên và một quy trình mới.
Ví dụ là trợ lý chăm sóc khách hàng kết nối CRM, kho tri thức và hệ thống tạo ticket. Đội ngũ cần luân phiên:
làm rõ phạm vi và mục tiêu;
khai phá quy tắc nghiệp vụ hiện tại;
thử các mô hình hoặc cấu hình có sẵn;
thiết kế điểm bàn giao giữa AI và nhân viên;
phát triển theo từng lát cắt;
đo kết quả rồi quay lại sửa yêu cầu.
Với giải pháp có sẵn, câu hỏi yêu cầu đổi từ “ta cần xây gì?” sang “thành phần này có tạo đúng kết quả ta cần không?”. Đây là khác biệt nhỏ về câu chữ nhưng lớn về tư duy. Danh sách tính năng của nhà cung cấp không phải là bằng chứng phù hợp với công việc của doanh nghiệp; kết quả phải dẫn tới một quyết định triển khai cụ thể.
Hai tình huống rất “nhân viên công ty”
Tình huống 1: “Em chỉ cần AI viết email nhanh hơn”
Hãy tưởng tượng tôi là nhân viên kinh doanh. Mỗi chiều, tôi mất gần một giờ để đọc ghi chú cuộc gọi rồi viết email theo sát khách hàng. Tôi đề nghị công ty làm một công cụ AI: bấm nút là có email.
Nếu đội dự án nhận câu nói ấy như đặc tả, họ có thể xây một màn hình rất đẹp nhưng email lại chung chung, dùng sai cách xưng hô và đôi lúc hứa một điều chưa được phê duyệt. Tôi thử vài lần rồi quay lại tự viết.
Một quy trình khám phá nhanh sẽ làm khác. Đội ngũ lấy một số ghi chú đã ẩn dữ liệu nhạy cảm, phân loại mục tiêu của email, xác định những câu tuyệt đối không được tự sinh và dựng prototype ngay trong luồng CRM. Tôi cùng vài đồng nghiệp chấm bản nháp theo ba tiêu chí: đúng bước tiếp theo, đúng giọng điệu, ít phải sửa.
Sau vài vòng, đội ngũ phát hiện giá trị không nằm ở “viết email hoàn chỉnh”. Giá trị nằm ở việc tóm tắt cuộc gọi và đề xuất ba bước tiếp theo có dẫn chứng. Nhân viên vẫn là người chọn và gửi. Một thay đổi nhỏ trong yêu cầu đã tạo ra giải pháp vừa hữu ích vừa ít rủi ro hơn.
Tình huống 2: “Phòng nào cũng đã đồng ý rồi mà”
Hãy tưởng tượng tôi là nhân viên vận hành, phụ trách yêu cầu hoàn tiền. Công ty muốn AI đọc nội dung khách gửi và tự đề xuất quyết định. Trong buổi họp, kinh doanh muốn xử lý nhanh, tài chính muốn giảm thất thoát, chăm sóc khách hàng muốn ít chuyển tuyến, còn pháp chế muốn mọi quyết định có căn cứ.
Ai cũng “đồng ý làm AI”, nhưng chưa ai đồng ý thế nào là một quyết định đúng.
Nếu dự án chạy theo nhịp khám phá quá nhẹ, các ngoại lệ sẽ xuất hiện muộn: khách đã dùng một phần dịch vụ, đơn hàng qua đối tác, chính sách thay đổi theo thời điểm, hoặc chứng từ không đọc được. Đây là dự án cần nghiêng về đấu trường chứng minh. Đội ngũ phải lập bảng quyết định, truy vết từng nhánh tới chính sách, gắn ngưỡng tin cậy và buộc chuyển người thật ở trường hợp ngoại lệ.
Với tôi, trải nghiệm tốt không phải AI “cướp” việc. Nó là một màn hình cho biết hồ sơ còn thiếu gì, điều khoản nào liên quan và vì sao hệ thống đưa ra đề xuất. Tôi xử lý nhanh hơn nhưng vẫn hiểu và chịu trách nhiệm cho quyết định cuối cùng.
Hai tình huống cho thấy kiến trúc AI không dừng ở API, vector database hay orchestration. Nó bao gồm cả cách con người làm việc trước, trong và sau khi AI xuất hiện.
Chọn quy trình bằng bốn câu hỏi, không bằng tên phương pháp
Trước khi tuyên bố dự án “Agile”, “waterfall” hay “AI-first”, hãy trả lời bốn câu sau.
Mức độ mới cao đến đâu?
Nếu cả vấn đề lẫn trải nghiệm đều chưa rõ, tăng tạo mẫu và tiếp xúc người dùng. Nếu công việc đã ổn định, quy tắc rõ và dữ liệu đủ tốt, có thể dành nhiều sức hơn cho đặc tả cùng tích hợp.
Hậu quả của một kết quả sai là gì?
Sai một tiêu đề gợi ý khác với sai hạn mức tín dụng. Hậu quả càng lớn, yêu cầu về truy vết, kiểm thử, phê duyệt và cơ chế thoát an toàn càng cao.
Có bao nhiêu thành phần làm sẵn?
Mô hình nền tảng, SaaS, hệ thống cũ và API của đối tác đều là thành phần “có sẵn”. Hãy thử chúng bằng kịch bản nghiệp vụ thật. Đừng nhầm khả năng kỹ thuật với độ phù hợp.
Công việc của con người sẽ đổi thế nào?
Một giải pháp có thể không cần nhiều phần mềm mới nhưng vẫn đòi hỏi thay đổi quy trình, vai trò và trách nhiệm. Nếu không thiết kế phần việc của con người, ta mới tự động hóa một đoạn và đẩy tắc nghẽn sang đoạn kế tiếp. Có thể xem AI như một nhân viên mới cần đúng bối cảnh, quyền hạn và điểm dừng, thay vì một “nhà tiên tri” tự hiểu mọi thứ.
Từ bốn câu trả lời, đội ngũ có thể phân bổ mức nỗ lực cho từng hoạt động thay vì bê nguyên một bộ nghi lễ về áp dụng.
Một nhịp triển khai thực dụng cho 30 ngày đầu
Dù dự án thuộc đấu trường nào, 30 ngày đầu có thể đi qua năm nhịp sau. Độ sâu của mỗi nhịp thay đổi theo rủi ro.
Nhịp 1 — Chốt kết quả kinh doanh
Viết một câu mô tả vấn đề mà không nhắc tên công nghệ. Sau đó xác định tín hiệu thành công và đường biên. “Xây chatbot nội bộ” là đầu ra; “giảm thời gian tìm chính sách mà không làm tăng câu trả lời sai” mới gần với kết quả.
Nhịp 2 — Lập bản đồ công việc và ngoại lệ
Đi theo một ca làm việc thực tế. Ghi lại đầu vào, quyết định, người tham gia, hệ thống, điểm chờ và ngoại lệ. Đây là lúc yêu cầu ẩn bắt đầu lộ ra.
Nhịp 3 — Dựng lát cắt nhỏ nhất để học
Chọn một nhóm người dùng, một loại yêu cầu và một nguồn dữ liệu. Prototype đủ thật để người dùng phản hồi về kết quả, nhưng đủ rẻ để bỏ đi.
Nhịp 4 — Chuyển bài học thành tài sản kiểm chứng
Mỗi bài học phải trở thành thứ dùng lại được: tiêu chí chấp nhận, test case, bộ câu hỏi đánh giá, quy tắc chuyển người thật, quyết định kiến trúc hoặc dữ liệu cần bổ sung.
Nhịp 5 — Bàn giao tăng trưởng và lặp
Phát triển lát cắt đã đủ chắc trong khi đội yêu cầu tiếp tục khám phá lát cắt kế tiếp. Phản hồi từ kỹ sư và người dùng quay lại kho chung. Triển khai theo từng phần không có nghĩa yêu cầu bị chia vụn; nó có nghĩa tri thức được tích lũy có kiểm soát.
Một kho yêu cầu AI nên chứa gì?
Backlog chức năng là chưa đủ. Với AI, kho yêu cầu nên kết nối tối thiểu sáu lớp:
Kết quả kinh doanh: giá trị nào cần tạo ra, cho ai.
Bối cảnh sử dụng: ai dùng, khi nào, trong luồng công việc nào.
Quy tắc và ràng buộc: chính sách, quyền truy cập, dữ liệu cấm, yêu cầu pháp lý.
Hành vi mong đợi: hệ thống làm gì, hỏi lại khi nào, từ chối ra sao.
Bộ đánh giá: ví dụ tốt, ví dụ xấu, trường hợp biên và thước đo.
Vận hành: giám sát, phản hồi, chuyển tuyến, chủ sở hữu và cách cập nhật.
Mỗi khi thay mô hình hoặc prompt, đội ngũ có thể chạy lại bộ đánh giá. Mỗi khi chính sách đổi, ta biết test case và luồng nào bị ảnh hưởng. Mỗi khi nhân viên báo một lỗi, lỗi ấy trở thành tri thức của hệ thống thay vì nằm trong tin nhắn riêng.
Linh hoạt không có nghĩa tùy hứng
Một quy trình tốt cần ba phẩm chất.
Linh hoạt: dự án rủi ro thấp có thể học bằng prototype; dự án rủi ro cao có thể tăng đặc tả và kiểm chứng.
Mở rộng được: đội ngũ có thể thêm data profiling, red teaming, đánh giá thiên lệch, threat modeling hoặc kỹ thuật đặc thù ngành vào đúng chỗ.
Không lệ thuộc phương pháp: nó có thể phối hợp với Scrum, triển khai tuần tự, mua giải pháp có sẵn hoặc mô hình lai.
Nhưng linh hoạt không phải là bỏ qua kỷ luật. Luôn phải có người sở hữu quyết định, nơi lưu tri thức, tiêu chí để biết một lát cắt đã đủ tốt và vòng phản hồi sau triển khai.
Kết
Dự án AI thất bại hiếm khi chỉ vì chọn sai mô hình. Nó thường thất bại sớm hơn: đội ngũ xây đúng thứ đã được nói ra, nhưng thứ được nói ra chưa phải nhu cầu thật.
Đừng hỏi “quy trình chuẩn của dự án AI là gì?”. Hãy hỏi:
Ta cần học nhanh đến mức nào?
Ta cần chứng minh chặt đến mức nào?
Ta đang ghép bao nhiêu thành phần có sẵn?
Công việc của con người phải được thiết kế lại ra sao?
Từ đó, hãy tạo một đấu trường yêu cầu vừa đủ trật tự để mọi người cùng nhìn một hướng, vừa đủ co giãn để phù hợp với dự án. Nghĩ chậm để chốt đúng bài toán; rồi hành động nhanh trên lát cắt đúng.