Hôm nay mình chứng kiến một câu chuyện rất quen thuộc trong dự án.
Cả team được giao nhiệm vụ: đọc requirement, hiểu tính năng cần làm, rồi vào họp để thống nhất nhận thức.

Sau khi thống nhất nhận thức phía nội bộ về những công việc cần làm, team sẽ thực hiện estimate tính năng cũng như những công việc cần làm để đáp ứng được mong muốn và mục tiêu của dự án & khách hàng.

Nghe thì tưởng đơn giản. Nhưng sau khi họp xong, thay vì có định hướng rõ ràng, cả team lại rơi vào trạng thái chạy vòng vòng:

  • Lúc thì hỏi flow của user

  • Chưa clarify business flow của user lại nhảy sang confirm flow của admin

  • Đang confirm nghiệp vụ lại quay qua bàn về tech stack

Càng hỏi, team càng loạn – vì không có một trục confirm rõ ràng.
Lý do gốc rễ: sau khi đọc requirement, dev không biết phải bắt đầu từ đâu.

🌱 Vấn đề thường gặp của cả team khi nhận req mới

  1. Requirement toàn chữ
    Tài liệu nhiều chữ, nhiều case, nhưng thiếu sơ đồ trực quan → dễ “ngợp” và lạc lối.

  2. Thiếu kim chỉ nam
    Khi không biết nên đào từ đâu, dev dễ nhảy cóc từ phần này sang phần khác mà không có bức tranh tổng thể.

  3. Không phân tầng requirement
    Requirement có nhiều lớp: mục tiêu → flow → tính năng → chi tiết kỹ thuật.
    Nhưng nhiều bạn mới đọc theo kiểu “dàn trải”, nên rất nhanh rơi vào hỗn loạn.

💡 Bài học rút ra: Sau khi nhận requirement, đừng lao ngay vào chi tiết

Thay vào đó, hãy đi theo một trình tự “mở bản đồ” như sau:

Thay vì đọc tài liệu xong là nhảy ngay vào phân tích loạn xạ, hãy đi theo từng tầng phân tích như sau:

  1. Vẽ sơ đồ toàn cảnh dự án (Big Picture)

    • Dự án có những role nào? (user, admin, guest, doctor, patient…)

    • Các tính năng chính là gì? (booking, payment, notification, report…)

    • Dự kiến sẽ dùng những công nghệ gì để đáp ứng tính năng đó? (mobile/web, cloud/on-premise, framework)?

    • Có sử dụng third-party hay external system nào không (payment gateway, API bên ngoài…)?
      👉 Đây là “bản đồ cấp cao” để cả team thấy phạm vi dự án và định hình trước khi đi sâu.

  2. Đi vào phân tích business flow chi tiết

    • Với mỗi role, vẽ flow nghiệp vụ từ lúc bắt đầu → tới khi đạt mục tiêu.

    • Xác định rõ input, output, và interaction giữa các role.

    • Flow này giúp phát hiện các điểm mơ hồ, chỗ cần confirm với khách.

  3. Phân rã requirement thành các khối tính năng nhỏ

    • Từ business flow, tách thành các chức năng dev có thể estimate theo kiểu WBS (Work breakdown structure)

    • Gắn với deliverable cụ thể để quản lý scope.

  4. Confirm lại với khách hàng bằng flow + use case

    • Đừng confirm bằng chữ, hãy confirm bằng sơ đồ và ví dụ.

    • Cách này giúp khách dễ visualize và team đỡ mơ hồ.

🥀 Đúc kết

Requirement không phải là một “bài văn” để đọc thuộc lòng, mà là một mê cung cần bản đồ để dẫn đường.

Nếu bạn chỉ đọc rồi nhảy ngay vào chi tiết, bạn sẽ dễ chạy vòng vòng, vừa mất sức vừa mất phương hướng.
Nhưng nếu bạn biết dừng lại: xác định mục tiêu → vẽ flow → phân rã tính năng → confirm có hệ thống, thì mọi thứ sẽ sáng rõ.

👉 Với Dev: đây là cách làm việc logic, tránh “chạy tán loạn”.
👉 Với BrSE mới: đây là kỹ năng sống còn – biết cách bóc requirement và biến nó thành bản đồ hệ thống rõ ràng.

 

💬 “Không biết bắt đầu từ đâu” không phải dấu hiệu bạn kém, mà là tín hiệu bạn cần một phương pháp dẫn đường.
Hãy để requirement không chỉ là chữ, mà trở thành câu chuyện hệ thống bạn thật sự hiểu.