Hai kỹ thuật cuối bổ sung cho nhau ở hai đầu: phân tích tài liệu khai thác kiến thức đã được ghi lại, còn prototyping làm hiện hình những yêu cầu chưa ai diễn đạt nổi.
---
PHẦN 1 — PHÂN TÍCH TÀI LIỆU (DOCUMENT ANALYSIS)
Vì sao đừng bỏ qua tài liệu
Trước khi làm phiền stakeholder bằng hàng loạt câu hỏi, hãy tự trả lời những gì có thể qua tài liệu sẵn có. Điều này thể hiện sự chuyên nghiệp (bạn không hỏi những thứ đã ghi rõ trong quy định) và giúp bạn đặt câu hỏi sắc hơn.
Những loại tài liệu giá trị
- Quy trình nghiệp vụ (SOP), biểu mẫu, hợp đồng, hóa đơn.
- Tài liệu hệ thống cũ: user manual, báo cáo, cấu trúc dữ liệu.
- Quy định pháp lý: với ngân hàng, bảo hiểm, y tế, giáo dục — luật và thông tư là nguồn yêu cầu bắt buộc, không thương lượng.
- Dữ liệu vận hành: log, báo cáo lỗi, số liệu bán hàng — cho biết thực tế đang xảy ra gì.
Cách phân tích
- Đối chiếu tài liệu với thực tế: quy trình trên giấy thường khác thực tế (đây là lý do vẫn phải quan sát/phỏng vấn). Khoảng cách đó chính là insight.
- Trích ra business rule: ví dụ từ biểu mẫu "đơn trên 20 triệu cần 2 chữ ký" → một quy tắc nghiệp vụ.
- Chú ý tài liệu lỗi thời: hỏi lại "cái này còn áp dụng không?" — đừng tin mù quáng.
Ví dụ thực tế Việt Nam
Một công ty bảo hiểm số hóa quy trình bồi thường. BA đọc bộ hồ sơ bồi thường mẫu và phát hiện có tới 14 loại chứng từ tùy loại tai nạn, cùng nhiều quy định về thời hạn nộp theo Luật Kinh doanh bảo hiểm. Nếu chỉ hỏi miệng, không nhân viên nào nhớ hết 14 loại. Tài liệu là nguồn đầy đủ và chính xác nhất cho các quy tắc phức tạp kiểu này.
---
PHẦN 2 — PROTOTYPING
Vì sao "thấy mới biết mình muốn gì"
Có một nghịch lý kinh điển: stakeholder thường không biết mình muốn gì cho đến khi thấy một thứ mình không muốn. Mô tả bằng lời rất dễ hiểu nhầm — 10 người đọc "màn hình dashboard" sẽ tưởng tượng 10 kiểu khác nhau. Prototype (bản mẫu) biến yêu cầu trừu tượng thành thứ nhìn thấy và bấm được, khiến phản hồi trở nên cụ thể và nhanh chóng.
Prototyping vừa là công cụ elicitation (khơi ra yêu cầu mới), vừa là công cụ xác thực (kiểm tra ta hiểu đúng chưa).
Các mức độ prototype
- Low-fidelity (phác thảo giấy / wireframe): vẽ tay hoặc bằng công cụ đơn giản (Balsamiq, Figma wireframe). Nhanh, rẻ, dễ vứt đi — hợp giai đoạn đầu. Ưu điểm tâm lý: bản thô khiến người ta thoải mái chê, thay vì ngại vì "trông đã hoàn chỉnh".
- High-fidelity (mockup gần thật): chi tiết màu sắc, tương tác. Dùng khi cần kiểm tra trải nghiệm chi tiết hoặc demo cho lãnh đạo.
Nguyên tắc dùng prototype để elicit
- Làm nhanh, làm thô trước: đừng đầu tư quá công vào bản mẫu ban đầu, vì nó sẽ thay đổi nhiều.
- Đưa cho người dùng thật bấm thử, không chỉ mô tả. Quan sát chỗ họ lúng túng.
- Hỏi "anh mong đợi bấm nút này ra gì?" trước khi họ bấm — lộ ra kỳ vọng ẩn.
- Ghi lại mọi phản hồi, coi mỗi lần sửa là một yêu cầu được làm rõ.
- Cảnh giác kỳ vọng sai: prototype đẹp khiến sếp tưởng "gần xong rồi". Nói rõ đây là bản mẫu để lấy ý kiến.
Ví dụ thực tế Việt Nam
Một startup giao đồ ăn làm màn hình đặt món. BA vẽ wireframe giấy và ngồi cạnh 5 người dùng thật cho họ "đặt một phần cơm gà". Ngay lập tức lộ ra: người dùng loay hoay tìm nút chọn topping, và ai cũng hỏi "phí ship bao nhiêu?" ngay từ đầu chứ không đợi tới bước thanh toán. Hai phát hiện này dẫn tới thay đổi lớn về luồng — phát hiện sớm trên giấy tốn vài giờ, phát hiện muộn sau khi code tốn vài tuần.
---
Checklist phân tích tài liệu và prototyping
Phân tích tài liệu:
- [ ] Đã thu thập SOP, biểu mẫu, quy định pháp lý, dữ liệu vận hành liên quan?
- [ ] Đã trích ra các business rule cụ thể?
- [ ] Đã đối chiếu tài liệu với thực tế và ghi lại khoảng cách?
- [ ] Đã xác nhận tài liệu còn hiệu lực?
- [ ] Bắt đầu bằng bản low-fidelity nhanh, rẻ?
- [ ] Cho người dùng thật bấm thử, không chỉ mô tả?
- [ ] Ghi lại mọi phản hồi như yêu cầu được làm rõ?
- [ ] Đã nói rõ đây là bản mẫu để tránh kỳ vọng sai?
Tổng kết
Phân tích tài liệu giúp bạn khai thác kiến thức đã có một cách đầy đủ và chính xác, đặc biệt cho các quy tắc phức tạp và ràng buộc pháp lý. Prototyping làm hiện hình những yêu cầu mơ hồ và xác thực cách hiểu của bạn. Sau khi đã có 6 kỹ thuật thu thập, bài cuối sẽ dạy bạn xử lý "chiến lợi phẩm": ghi nhận, xác thực, ưu tiên yêu cầu và tránh các sai lầm chết người.