Trong hầu hết các dự án, thứ team nhận được ban đầu không phải là requirement rõ ràng, mà là các mô tả rời rạc. Trong ví dụ sau tại một doanh nghiệp xây dựng triển khai hệ thống quản lý đề xuất vật tư và phê duyệt nội bộ, với mục tiêu thay thế việc trao đổi qua Excel, Zalo và giấy tờ rời rạc giữa công trường và văn phòng.
-
Kỹ sư công trường (end user): “Hệ thống nhập liệu lâu, tụi em ngoài công trường không dùng được.”
-
Trưởng phòng dự án (PM phía business): “Cần kiểm soát chặt vật tư, tránh thiếu – sai – vượt ngân sách.”
-
Developer: “Quy trình đang mô tả không rõ, mỗi người nói một kiểu, không biết build theo logic nào.”
Đây là một tình trạng khá phổ biến khi khởi động 1 dự án chuyển đổi số. Và vấn đề tựu chung đó là: requirement chưa rõ ràng.
1.Hiểu đúng về Ambiguity và Clarity
Ambiguity là gì?
Ambiguity là trạng thái một bài toán chưa đủ rõ để design, build và test một cách chắc chắn. Dấu hiệu thường gặp gồm:
-
Còn nhiều điều chưa biết
-
Các bên nói chưa thống nhất
-
Chưa rõ phạm vi đến đâu
-
Chưa rõ ai làm gì, khi nào, và kết quả mong đợi là gì
Ví dụ, người dùng/khách hàng yêu cầu: “Bên em cần một hệ thống quản lý mua hàng nội bộ.” Thoạt đầu, requirement tạo cảm giác khá rõ, nhưng thực ra nếu đào sâu, bạn sẽ còn rất nhiều câu hỏi khác:
-
Ai tạo yêu cầu mua?
-
Có mấy cấp phê duyệt?
-
Nếu bị từ chối thì sao?
-
Có liên quan ngân sách không?
-
Phase này chỉ xử lý yêu cầu nội bộ hay cả PO và thanh toán?
Nếu chưa trả lời được những câu hỏi này mà đã đi vào thiết kế màn hình hay workflow, thì trong quá trình triển khai chắc chắn sẽ phát sinh việc phải thiết kế lại.
Clarity không phải là viết thật nhiều tài liệu
Nhiều người nghĩ làm rõ requirement là phải viết dài nhưng điều này không chính xác. Clarity không nằm ở số trang tài liệu. Clarity là khi team trả lời được rõ ràng:
-
Chúng ta đang giải quyết bài toán gì?
-
Scope của phase này là gì?
-
Actor chính là ai?
-
Họ sẽ dùng hệ thống trong những scenario nào?
-
Scenario nào cần làm trước?
-
Khi nào thì đủ rõ để development?
Nói ngắn gọn, clarity là khi requirement đã đủ rõ để đội ngũ có thể hành động.
2.Quy trình Discover → Define → Backlog
Để chuyển từ mơ hồ sang rõ ràng, bạn có thể sử dụng quy trình sau để toàn bộ team dự có thể đạt được một sự clarity và một sự thống nhất chung:
Discover - Hiểu đúng bài toán
-
Quy trình hiện tại (as-is) như thế nào
-
Điểm đau ở đâu
-
Ai tham gia
-
Các điểm chưa rõ / mâu thuẫn
Define - Làm rõ requirement
-
Viết BRD
-
Chốt scope
-
Xác định actor
-
Tách các scenario chính
-
Mô tả main flow và exceptions
Backlog - Chuẩn bị cho development
-
Sắp xếp scenario theo ưu tiên
-
Xác định mức độ sẵn sàng
-
Chọn scenario nào đi vào phase hiện tại
Đây là cách biến một cuộc trao đổi còn mờ thành một tập scenario có thể build và test được.
3.Ba công cụ quan trọng giúp các requirement đạt được tính clarity
Để đi từ ambiguity đến clarity, có ba công cụ rất quan trọng. Ba công cụ này đi theo nhau, không thay thế nhau.
BRD: Dùng để chốt bài toán ở góc nhìn business.
User Scenarios: Dùng để mô tả các tình huống sử dụng thực tế.
Scenario Backlog: Dùng để tổ chức, ưu tiên và chuẩn bị cho development.
3.1. BRD
BRD - Chốt bài toán trước khi nghĩ đến giải pháp
BRD không phải là nơi tổng hợp mọi chi tiết. Mục tiêu của BRD là làm rõ những thứ nền tảng nhất:
-
Bối cảnh nghiệp vụ
-
Vấn đề hiện tại
-
Mục tiêu cần đạt
-
Stakeholders liên quan
-
In scope / Out-of-scope
-
Business rules quan trọng
-
Các ràng buộc, giả định chính
Một BRD tốt giúp team trả lời được câu hỏi: “Chúng ta đang xây cái gì, để giải quyết vấn đề gì, trong phạm vi nào?” Sai lầm phổ biến là viết BRD quá chung chung, không chốt out of scope, hoặc nhảy vào solution trước khi hiểu rõ problem.
Scope - Nếu không chốt thì requirement sẽ phát sinh trong quá trình triển khai
Rất nhiều dự án trượt không phải vì team yếu, mà vì scope không được chốt lại một cách rõ ràng. Ví dụ với bài toán mua hàng nội bộ:
In scope
-
Tạo yêu cầu mua hàng
-
Phê duyệt nhiều cấp
-
Trả lại để bổ sung
-
Theo dõi trạng thái
Out of scope
-
Tạo PO nhà cung cấp
-
Nhận hàng vào kho
-
Đối soát thanh toán
-
Tích hợp ERP ở phase 1
Scope rõ giúp team biết phase này làm đến đâu, chưa làm gì, và tránh kéo requirement đi quá xa.
3.2. User Scenario
Use scenario là nơi gắn requirement với các thực tế vận hành
Sau khi đã hiểu bài toán và chốt phạm vi, bước tiếp theo là chuyển sang user scenarios.
Scenario là mô tả một tình huống cụ thể trong đó một actor/user thực hiện một mục tiêu cụ thể.
Người dùng không nghĩ theo kiểu “tôi muốn tính năng approval”. Họ nghĩ theo kiểu “tôi cần gửi một yêu cầu để quản lý duyệt”. Đó là scenario.
Một scenario tốt nên làm rõ:
-
Actor là ai
-
Trigger là gì
-
Điều kiện đầu vào là gì
-
Luồng chính diễn ra thế nào
-
Ngoại lệ xử lý ra sao
-
Kết quả mong đợi là gì
Ví dụ
- Scenario: Tạo yêu cầu mua hàng
- Actor: Nhân viên
- Trigger: Có nhu cầu mua vật tư
- Main flow: Tạo yêu cầu → nhập thông tin → gửi duyệt
- Exceptions: Thiếu dữ liệu, vượt ngân sách, không đủ quyền
- Outcome: Yêu cầu được tạo và chuyển sang chờ phê duyệt
Khi đi đến mức này, requirement mới thực sự hữu ích cho design, workflow, validation, permission và testing.
Sai lầm phổ biến: chỉ viết happy path
Một lỗi rất phổ biến là chỉ mô tả luồng công việc chính (lý tưởng), ví dụ:
-
Tạo yêu cầu
-
Quản lý duyệt
-
Hoàn tất
Nhưng hệ thống thực tế không sống bằng happy path. Nó sống bằng cả các tình huống như:
-
Thiếu dữ liệu
-
Trả lại để sửa
-
Từ chối
-
Quá hạn
-
Sai approver
-
Hủy giữa chừng
Cho nên khi làm scenario, bạn không nên chỉ hỏi “luồng chính là gì”. Phải hỏi thêm “nếu không diễn ra đúng như mong đợi thì sao”. Chính phần exception mới là nơi requirement trở nên đầy đủ, và hạn chế phát sinh.
3.3. Scenario Backlog
Biến trao đổi nghiệp vụ thành đầu vào delivery
Khi đã có các scenario chính, bước tiếp theo là tổng hợp chúng thành một scenario backlog. Scenario backlog = danh sách scenario đã xác định, ưu tiên, sẵn sàng triển khai. Backlog tốt giúp team chuyển từ “nói về requirement” sang “quản lý delivery”.
Ví dụ:
| Priority | Scenario | Purpose |
|---|---|---|
| P1 | Tạo yêu cầu mua hàng | Khởi tạo yêu cầu |
| P1 | Quản lý phê duyệt | Chấp thuận hoặc từ chối |
| P1 | Trả lại để bổ sung | Xử lý thiếu thông tin |
| P2 | Theo dõi trạng thái | Minh bạch tiến độ |
| P3 | Báo cáo | Theo dõi tổng quan |
Kết luận
Requirement mơ hồ luôn là điểm xuất phát của bất kỳ dự án nào. Tuy nhiên, phương pháp biến sự mơ hồ và phức tạp trở nên rõ ràng là tạo ra khoảng cách giữa các dự án thành công và thất bại.
Một cách làm rất hiệu quả là: Discover → Define → Backlog với 3 công cụ BRD, User Scenario và User Scenario Backlog. Làm tốt ba bước này sẽ giúp team giảm hiểu sai, giảm rework và tăng khả năng build đúng ngay từ đầu. Đó là lúc requirement thực sự sẵn sàng cho development.