Pragmatic Programmer – Topic 45: The Requirements Pit — Đào bới yêu cầu

Mở đầu

Hồi mới làm freelance, mình nhận một project từ khách: "Làm cái website bán hàng, đơn giản thôi". Mình gật đầu, tưởng hai tuần xong. Kết quả: khách nói "đơn giản" mà hoá ra muốn tích hợp đủ thứ — kho hàng, đa kênh, báo cáo theo từng chi nhánh. Mình hỏi lại thì khách ngạc nhiên: "Ủa, chuyện đó hiển nhiên mà?". Đó là lần đầu mình nếm cái gọi là The Requirements Pit — cái hố yêu cầu. Yêu cầu hiếm khi nằm trên bề mặt; nhìn phát thấy toàn nước bùn.

Ảnh: Kaboompics — Pexels

Yêu cầu không bao giờ nằm trên bề mặt

Topic 45 trong Pragmatic Programmer nói thẳng: đừng nhận yêu cầu như nhận hàng, phải đào bới (dig for requirements). Sách có câu mình nhớ mãi — yêu cầu hiếm khi nằm trên bề mặt, người ta nói một đằng nhưng cần một nẻo. User nói "tôi muốn nút export file Excel", nhưng ý thật là "tôi muốn gửi báo cáo cho sếp mà không cần gõ lại tay". Nếu chỉ code đúng câu chữ, mình ship đúng cái nút — và user vẫn bực.

Cách đào đơn giản nhất: hỏi "tại sao" liên tục. Mỗi câu trả lời là một lớp bùn được xúc đi:

# Bản ghi nhận yêu cầu dở — chỉ ghi bề mặt
requirements = [
    "Add export button",
]

# Sau khi đào bới — hiểu được ý định thật
requirements = [
    "User can export sales report to Excel",
    "Report must be readable by manager without editing",
    "Export must include branch-level breakdown",
]

Làm việc với user, không phải làm việc cho user

Điểm mình tâm đắc nhất là phần "Work with a User — Think Like a User". Sách bảo đừng xem user như cái máy cung cấp yêu cầu. Ngồi cạnh họ, xem họ làm việc thật, hỏi tại sao họ làm như vậy. Nhiều khi chính user cũng không biết mình cần gì cho tới khi thấy bản demo — nên "tracer bullets" ở topic 12 dính dáng với topic này ghê. Cứ dựng thứ nhỏ nhỏ cho user sờ thử, rồi để cuộc hội thoại tự nó đi tiếp.

Ảnh: cottonbro studio — Pexels

Requirements là cuộc hội thoại, không phải tài liệu

Cái bẫy lớn nhất của requirements: đóng băng. Team ngồi hai tháng viết tài liệu yêu cầu trăm trang, ký xác nhận, sáu tháng sau mới bắt đầu code — tới lúc đó yêu cầu đã thay đổi từ lâu. Sách nhấn mạnh: requirements phải là cuộc hội thoại liên tục, không phải hợp đồng một chiều. Ghi chép lại thì vẫn nên, nhưng đừng biến ghi chú thành văn kiện bất khả xâm phạm.

Một ý trong sách mình thấy nhóm nào cũng thiếu: abuser stories — nghĩ về kịch bản ai đó xài nhầm, xài sai. "Nếu user nhập ngày sai thì sao?", "Nếu cổng thanh toán down giữa chừng thì sao?". Kịch bản lạm dụng cũng là yêu cầu — chỉ là loại yêu cầu ít ai chịu viết ra.

Project glossary — cùng một ngôn ngữ

Chỗ cuối của topic 45 nói về project glossary — mình thấy đây là thứ nhiều team bỏ qua nhất. Cùng một từ "pending", business hiểu là "chờ thanh toán", dev hiểu là "chưa xử lý" — hai tuần sau mới vỡ lẽ mình đã build nhầm trạng thái. Sách đề nghị lập một cuốn từ điển nhỏ của project, ai cũng xài chung: đâu là Order, đâu là Invoice, trạng thái nào đi qua trạng thái nào. Tốn một buổi, tiết kiệm cả tháng hiểu lầm.

Ảnh: Kampus Production — Pexels

Kết bài

Đọc xong topic 45 mình nghiệm ra: requirements không phải tài liệu — là quá trình. Đừng ngại hỏi, đừng ngại đào sâu, và đặc biệt đừng tin câu "đơn giản thôi" của khách hàng. Mình đã tin, và đã trả giá bằng hai tuần làm lại.

Mấy bạn có bao giờ nhận yêu cầu xong rồi mới té ngửa phát hiện mình hiểu sai chưa? Lúc đó mình làm gì — ngồi xuống hỏi lại cho tường tận, hay cắm đầu code tiếp cho xong chuyện?