Một đội đang xây chức năng đổi lịch cho cổng đặt dịch vụ. Founder yêu cầu khách được tự đổi lịch. Sales cho biết một số khách đổi lịch nhiều lần. Designer đã thêm nút đổi lịch, nhưng dev vẫn thiếu các điều kiện để triển khai: khách được đổi trước giờ hẹn bao lâu, được đổi tối đa bao nhiêu lần, ai có quyền thao tác và hệ thống xử lý thế nào nếu khung giờ mới vừa có người đặt.
Vấn đề nằm ở đầu vào. Ghi chú hiện có mới mô tả nhu cầu, chưa xác định đầy đủ hành vi hệ thống. Nếu dev tự trả lời các câu hỏi còn thiếu, tính năng có thể chạy đúng theo code nhưng sai chính sách của doanh nghiệp.
Vì sao một yêu cầu ngắn chưa đủ để phát triển?
Thông tin đang nằm ở nhiều nguồn
Founder, sales, product và designer cập nhật yêu cầu qua cuộc họp, tin nhắn, bảng công việc và file thiết kế. Mỗi nguồn có một phần thông tin, nhưng đội chưa xác định đâu là phiên bản đã được duyệt.
Dev thiếu điều kiện và ngoại lệ
Câu "cho phép khách đổi lịch" chưa cho biết điều kiện được đổi, dữ liệu nào thay đổi, trạng thái nào bị ảnh hưởng và trường hợp nào phải từ chối. Nếu chỉ viết test case sau khi code gần xong, các câu hỏi về phạm vi xuất hiện quá muộn.
Một spec cần trả lời những gì?
Spec không cần dài nếu đội đã chốt được các thông tin cần thiết. Với chức năng đổi lịch, tài liệu cần nêu rõ vấn đề, người dùng, kết quả mong đợi, phạm vi và phần chưa làm trong phiên bản này.
Luồng chính phải được viết bằng hành động có thể quan sát. Ví dụ: khách mở lịch hẹn, chọn đổi lịch, hệ thống hiển thị các khung giờ hợp lệ, khách xác nhận, hệ thống cập nhật lịch và gửi thông báo. Mỗi bước cho dev biết cần xử lý gì và cho QA biết cần kiểm tra kết quả nào.
Các quyết định chưa có câu trả lời phải được ghi thành câu hỏi chờ duyệt. Nếu doanh nghiệp chưa chốt số lần khách được đổi lịch, spec cần chỉ rõ người chịu trách nhiệm quyết định. Dev và AI không nên tự đặt một con số để hoàn thiện tài liệu.
Bài cách ghi nhận yêu cầu tính năng phù hợp với giai đoạn thu thập đầu vào. Khi yêu cầu đã được chọn để phát triển, spec phải chuyển đầu vào đó thành phạm vi có thể triển khai.
Quy trình viết spec và test case từ ghi chú sản phẩm
1. Gom nguồn và xác định phiên bản đang dùng
Người phụ trách tập hợp biên bản họp, phản hồi khách hàng, link thiết kế, ticket và quyết định cũ vào một nơi. Nội dung trùng được gộp. Nội dung mâu thuẫn được đánh dấu để hỏi lại. Spec chỉ giữ thông tin phục vụ quyết định và triển khai, không sao chép toàn bộ lịch sử trao đổi.
2. Viết luồng chính bằng hành động và kết quả
Mỗi bước cần nói rõ ai thao tác, hệ thống phản hồi gì, dữ liệu nào thay đổi và trạng thái tiếp theo là gì. Thay các cụm như "xử lý thông minh" hoặc "trải nghiệm thuận tiện" bằng hành vi có thể kiểm tra trên giao diện, API, dữ liệu hoặc thông báo.
3. Liệt kê điều kiện và ngoại lệ
Đội rà các trường hợp thiếu quyền, dữ liệu không hợp lệ, hai người cùng thao tác, mất kết nối và yêu cầu vượt chính sách. Trường hợp chưa làm ở phiên bản đầu vẫn cần được ghi rõ là ngoài phạm vi. Cách này giúp dev không xây thêm theo suy đoán.
4. Chuyển tiêu chí hoàn thành thành test case
Mỗi kết quả quan trọng cần có tình huống kiểm thử gồm điều kiện ban đầu, hành động và kết quả mong đợi. Test case được review cùng spec trước khi dev bắt đầu. Nếu không viết được kết quả mong đợi, yêu cầu đó chưa đủ rõ để chuyển sang phát triển.
5. Duyệt theo đúng trách nhiệm
Người phụ trách sản phẩm chốt mục tiêu, chính sách và phạm vi. Tech lead xác nhận hướng triển khai và các rủi ro kỹ thuật. QA hoặc đại diện vận hành rà trường hợp lỗi có thể ảnh hưởng đến khách hàng. Sau khi các câu hỏi mở đã có người nhận xử lý, spec mới chuyển sang trạng thái sẵn sàng.
Đội nhỏ có thể chạy quy trình này bằng tài liệu dùng chung và bảng công việc hiện tại. Không cần mua thêm công cụ trước khi thống nhất cách ghi yêu cầu, cách duyệt và trạng thái của tài liệu. Nếu đội đang chọn phạm vi phiên bản đầu, checklist trước khi xây MVP giúp kiểm tra lại quyết định trước khi giao việc cho dev.
Viết test case trước khi code giúp phát hiện quyết định còn thiếu
Test case xác định cụ thể thế nào là xử lý đúng. Với chức năng đổi lịch, luồng chính kiểm tra khách chọn được khung giờ còn trống, lịch cũ được cập nhật và thông báo mới được gửi. Các trường hợp cần kiểm tra thêm gồm lịch quá sát giờ, khung giờ vừa bị người khác đặt, người dùng không có quyền sửa, lưu dữ liệu thất bại hoặc gửi thông báo không thành công.
Khi viết các trường hợp này, đội thường phát hiện ba loại quyết định khác nhau. Giới hạn số lần đổi là chính sách dịch vụ. Cách khóa khung giờ khi có nhiều thao tác đồng thời là quyết định kỹ thuật. Nội dung hiển thị khi gửi thông báo lỗi là quyết định về trải nghiệm. Spec cần phân loại và giao đúng người chốt, thay vì gộp tất cả vào một ticket.
Dùng AI để soạn nháp, không dùng AI để tự quyết định phạm vi
AI có thể đọc các nguồn đã được cấp quyền, nhóm thông tin trùng, chỉ ra nội dung mâu thuẫn và tạo bản nháp test case theo mẫu. Người phụ trách kiểm tra các câu hỏi về sản phẩm và kỹ thuật thay vì tự tổng hợp và định dạng toàn bộ tài liệu.
Bản nháp phải giữ nguyên những điểm chưa có dữ liệu. Nếu nguồn không nói khách được đổi lịch tối đa bao nhiêu lần, đầu ra đúng là một câu hỏi cần xác nhận. AI không được tự điền chính sách rồi trình bày nó như một quyết định đã có.
Phần nào giao cho AI, phần nào cần người duyệt?
AI hoặc hệ thống hỗ trợ
- Gom nội dung từ các nguồn đã được cấp quyền.
- Chuẩn hóa bản nháp theo mẫu spec của đội.
- Đánh dấu thông tin mâu thuẫn, thiếu điều kiện hoặc thiếu kết quả mong đợi.
- Gợi ý test case để product, dev và QA rà lại.
Người phụ trách xác nhận
- Chốt vấn đề, nhóm người dùng và kết quả cần đạt.
- Quyết định phạm vi, chính sách và ngoại lệ được chấp nhận.
- Xác nhận thiết kế phù hợp với quy trình phục vụ khách hàng.
- Duyệt spec trước khi chuyển sang phát triển.
Áp dụng trước với một loại yêu cầu thường bị hỏi lại
Đội không cần chuẩn hóa toàn bộ tài liệu trong một lần. Hãy chọn một loại yêu cầu thường khiến dev phải hỏi lại, chẳng hạn thay đổi trạng thái đơn hàng, phân quyền người dùng hoặc xử lý hoàn tiền. Dùng một yêu cầu sắp triển khai để thử mẫu spec, ghi lại các câu hỏi phát hiện trước khi code và sửa mẫu sau buổi review.
Sau vài yêu cầu, đội sẽ biết trường thông tin nào luôn cần có và phần nào không hỗ trợ triển khai. Dịch vụ Product Development của Auranium có thể cùng đội chốt phạm vi, viết luồng xử lý và thiết lập tiêu chí bàn giao cho từng mốc phát triển.