Khảo sát có cấu trúc và thu thập yêu cầu

"Chúng tôi muốn AI cải thiện trải nghiệm khách hàng, tuần sau bắt đầu thiết kế nhé." Một yêu cầu như vậy chưa đủ để thiết kế bất cứ thứ gì: chưa biết khách gặp khó ở đâu, đo bằng gì, AI phải hỗ trợ quyết định nào. Khảo sát (discovery) là bước biến câu đó thành thứ xây được và kiểm được.

Bài này giúp bạn trả lời: khảo sát và thu thập yêu cầu cho một giải pháp dùng Claude thế nào?

Ví dụ xuyên suốt: chuỗi phòng khám thú y

Giám đốc một chuỗi phòng khám thú y nói: "Tôi muốn AI cải thiện trải nghiệm khách hàng." Ông không nói được hành trình nào của khách đang hỏng, chỉ số nào cho thấy điều đó, hay AI sẽ hỗ trợ quyết định gì, và muốn bắt đầu thiết kế tuần sau.

Khảo sát trước, thiết kế sau

Khoá AI Fluency for Builders của Anthropic Academy gợi ý một bản mô tả vấn đề ngắn (một trang) với bốn câu hỏi:

Khoá học cũng nói giao việc cho AI bắt đầu từ chia nhỏ vấn đề, rồi mới quyết định AI đảm nhận gì ở từng bước. Khung AI Fluency gọi năng lực này là Delegation. Khoá học tách ba mức giao: AI làm rồi người kiểm (Automation), người và AI cùng làm (Augmentation), AI tự hành động trong ranh giới đặt sẵn (Agency).

Yêu cầu chức năng và phi chức năng

• Chức năng: hệ thống phải làm gì. Phân loại tin nhắn vào các loại cố định; trích các trường từ phiếu khám; soạn câu trả lời nháp cho lễ tân sửa.
• Phi chức năng: hệ thống phải làm tốt tới mức nào: độ trễ, độ sẵn sàng, chi phí, bảo mật, tuân thủ.

Tiêu chí thành công viết trước khi xây

Docs của Anthropic về tiêu chí thành công nói tiêu chí tốt phải cụ thể, đo được, làm được, đúng mục đích, và hầu hết ứng dụng cần nhiều tiêu chí cùng lúc (độ chính xác, độ trễ, chi phí, an toàn...). Một mục tiêu độ chính xác duy nhất là chưa đủ.

Trong ví dụ:

• Phân loại đúng mức khẩn cấp (cấp cứu, trong ngày, đặt lịch thường) cho ít nhất 95% tin nhắn trong bộ 300 tin nhắn mẫu có nhãn của bác sĩ.
• Không có ca cấp cứu nào bị xếp thành đặt lịch thường trong bộ mẫu (ngưỡng thất bại: một ca là dừng).
• Phản hồi đầu tiên dưới 3 giây cho 95% tin nhắn.

Tìm những yêu cầu chưa ai nói ra

Nhiều yêu cầu quan trọng nhất không ai nói ra, vì người trong nghề thấy chúng hiển nhiên. Bài blog của Anthropic về tìm "những điều chưa biết" chia thành bốn loại: điều biết là mình biết (đã có trong yêu cầu), điều biết là mình chưa biết, điều mình biết nhưng hiển nhiên tới mức không bao giờ viết ra, và điều chưa từng nghĩ tới. Các cách được gợi ý:

• Nhờ Claude phỏng vấn: yêu cầu Claude hỏi bạn từng câu một về những chỗ mơ hồ, ưu tiên câu mà câu trả lời làm thay đổi kiến trúc. Docs Claude Code có mẫu tương tự: "phỏng vấn tôi cho tới khi đủ để viết spec".
• Rà điểm mù (blind spot pass): nhờ Claude chỉ ra những gì bạn chưa xét tới.
• Làm prototype sớm: những điều "hiển nhiên" thường chỉ lộ ra khi người dùng thấy một bản chạy thử, và phát hiện lúc đó rẻ hơn nhiều so với lúc đang triển khai.
• Xem dữ liệu thật: đọc 50 tin nhắn thật của khách trước khi viết yêu cầu.

Trong ví dụ, đọc tin nhắn thật lộ ra một yêu cầu không ai nói: nhiều khách gửi ảnh thú cưng kèm tin nhắn, nên hệ thống phải đọc được ảnh.

Bài kiểm nghiệm thu viết trước code

Khoá AI Fluency for Builders khuyên viết bài kiểm nghiệm thu (acceptance test) trước khi có code, vì chúng là định nghĩa chung về "xong" cho cả bạn và AI. Mỗi bài phải cụ thể tới mức một người ngoài phán được đạt hay không đạt. Ví dụ tốt: "Chủ thú cưng dùng điện thoại cơ bản biết được nên đến ngay hay đặt lịch trong vòng 2 phút, không cần tạo tài khoản." Ví dụ tồi: "Hệ thống dễ dùng."

Khoá học còn mô tả một chuỗi diễn đạt (Description Chain): lời của người dùng, thành yêu cầu, thành spec kỹ thuật, thành chỉ dẫn cho AI. Prompt chỉ là mắt xích cuối. Khoá học nói rõ: test đạt mà người dùng vẫn không vui nghĩa là bạn đã mô tả sai ý định, và phải lần ngược lên tìm mắt xích hỏng.