Vì sao SDD lại chọn User Scenario làm đơn vị thiết kế và triển khai trung tâm?

1.Hệ thống chạy đúng yêu cầu, nhưng chuyển đổi số không mang lại kết quả

Tại doanh nghiệp sản xuất, trưởng bộ phận chia sẻ họ vừa triển khai xong hệ thống quản lý đơn hàng mới. Về mặt kỹ thuật, mọi thứ đều “chuẩn”: workflow đầy đủ, các bước được số hóa, dữ liệu lưu trữ tập trung. Nhưng chỉ sau vài tháng, đội ngũ lại rủ nhau quay về dùng Excel và gọi điện nội bộ.

Hệ thống được xây dựng để đáp ứng yêu cầu của dự án, nhưng lại không giúp họ xử lý những tình huống thực tế phát sinh hàng ngày: đơn hàng thiếu thông tin, khách thay đổi yêu cầu phút chót, hay những lúc cần quyết định linh hoạt vượt quy trình.

Câu chuyện này không hiếm trong các dự án tư vấn tại Cleeksy. Nó là hệ quả của 3 vấn đề phổ biến trong việc thực thi chuyển đổi số:

  • Process giả định sự tuyến tính: Quy trình chỉ mô tả luồng công việc lý tưởng (happy path), bỏ qua vô số ngoại lệ (exceptions) và biến động trong thực tế.

  • Feature không gắn liền với giá trị: Tính năng chỉ mô tả khả năng của hệ thống (system capability), không đảm bảo công việc của người dùng được giải quyết tốt hơn.

  • Business và IT thiếu ngôn ngữ chung: Business nói về vấn đề và kết quả (Outcome), IT nói về tính năng (Feature). Thiếu một đơn vị trung gian để đồng bộ hai thế giới này.

Và tại đây, SDD (Scenario-Driven Development) xuất hiện với một hướng tiếp cận hoàn toàn mới: Lấy User Scenario làm đơn vị thiết kế và triển khai trung tâm.

2. User Scenario là gì?

User Scenario là mô tả một tình huống cụ thể, trong đó một vai trò thực hiện công việc trong một bối cảnh nhất định để đạt được một kết quả rõ ràng. Nó phản ánh chính xác cách doanh nghiệp vận hành & triển khai trong thực tế.

Một User Scenario chuẩn luôn bao gồm 5 yếu tố cốt lõi:

  1. Role: Một vai trò cụ thể thực hiện công việc.

  2. Trigger: Điểm kích hoạt tình huống.

  3. Context/Pre-condition: Bối cảnh dữ liệu hoặc trạng thái hệ thống hiện tại.

  4. Action & Decision: Chuỗi hành động, quyết định và cách xử lý ngoại lệ (Exception).

  5. Outcome: Kết quả cuối cùng có thể đo lường được.

Ví dụ

Value stream: Order to Cash

Scenario: Xác nhận đơn hàng B2B hợp lệ

  • Role: Sales Admin

  • Trigger: Đơn hàng mới được tạo

  • Context: Khách hàng đã tồn tại trong hệ thống

  • Action:

    • Kiểm tra thông tin đơn hàng

    • Kiểm tra hạn mức tín dụng

    • Xác nhận đơn

  • Exception:

    • Nếu vượt hạn mức → chuyển duyệt
  • Outcome:

    • Đơn được xác nhận trong < 2h

    • Tỷ lệ đơn bị hold < 5%

3. Tại sao User Scenario quan trọng?

Việc lấy User Scenario làm trung tâm giải quyết 3 vấn đề cốt lõi của việc thiết kế hệ thống, từ vận hành, giao tiếp đến quản lý vòng đời dự án:

3.1. Vượt qua giới hạn của “Happy-path thinking”

Vận hành thực tế không phải là một đường thẳng, nó là tập hợp của các tình huống (scenarios) với:

  • Exception (ngoại lệ)

  • Decision (quyết định thực tế)

  • Variability (biến động theo tình huống)

Tiếp cận Process-based

  • Thiết kế flow xử lý đơn hàng end-to-end
  • Số hóa từng bước
  • Đảm bảo dữ liệu đi đúng luồng

Vấn đề phát sinh:

  • Đơn thiếu thông tin, hệ thống bị treo
  • Vượt hạn mức hoặc khách thay đổi, nhân viên xử lý thủ công

Tiếp cận User-Scenario-based

Thay vì một theo một vài happy-path flow, hệ thống được thiết kế xoay quanh các tình huống:

  • Xử lý đơn hàng đầy đủ thông tin
  • Xử lý đơn hàng thiếu thông tin
  • Xử lý đơn vượt hạn mức tín dụng
  • Xử lý thay đổi đơn sau xác nhận

Mỗi scenario có:

  • Logic rõ ràng
  • Quyền quyết định cụ thể
  • Dữ liệu cần thiết
  • Outcome đo được

Hệ thống lúc này cover được đến 95% thực tế thay vì chỉ 80% happy-path. |

3.2. Kết nối business với system design

Trong giao tiếp dự án, một trong những vấn đề lớn của chuyển đổi số:

  • Business nói bằng problem

  • IT build bằng feature

Theo đó, giữa business và ID không có một đơn vị trung gian rõ ràng. User Scenario đóng vai trò cầu nối, mô tả cách công việc thực sự diễn ra để đạt được outcome, và system thiết kế các tính năng để hỗ trợ cho scenario đó.

3.3. Tạo tính truy vết end-to-end

Trong quản lý dự án theo SDD (Scenario-Driven Development), User Scenario là trung tâm của toàn bộ vòng đời:

BRD → User Scenario → Design → Build → Test → Adopt

Điều này đảm bảo:

  • Mỗi tính năng đều có lý do tồn tại

  • Mỗi test case đều gắn với outcome thực tế

  • Mỗi thay đổi đều có thể truy vết

Kết luận

User Scenario không chỉ là một cách viết requirement trong dự án. Nó là một cách tiếp cận khác cho việc thiết kế và triển khai các dự án chuyển đổi số.

  • Từ việc thiết kế luồng quy trình lý tưởng sang thiết kế theo tình huống thực tế.

  • Từ việc bàn giao tính năng sang kích hoạt giá trị.

Nếu Value Stream trả lời “chúng ta tạo giá trị như thế nào” thì User Scenario trả lời: “công việc thực sự diễn ra như thế nào để tạo ra giá trị đó”. Đó là lúc Digital Operations được chuyển từ một khái niệm thành một hệ thống có thể thực sự vận hành được.

Khi chuyển sang thiết kế theo User Scenario, team có thể gặp tình trạng scenario explosion (scenario tăng quá nhiều). Vậy đâu là cách tốt để tổ chức và ưu tiên scenario backlog để hệ thống vẫn giữ được tính đơn giản?

Trong nhiều dự án phần mềm, backlog thường được viết theo feature hoặc module. Nếu chuyển sang tư duy scenario-based, liệu backlog nên được tổ chức theo scenario, feature, hay value slice, hay tuỳ chủ đích của người làm?

Trong dự án phát triển phần mềm, backlog thường tổ chức quản lý các user stories, trong SDD, backlog dùng quản lý các user scenarios.

Khi triển khai, user scenario bị phình lên (về độ phức tạp, không phải về số lượng) là dấu hiệu cho thấy giai đoạn Define làm chưa đủ tốt dẫn đến chưa xác định đầy đủ hoặc chính xác happy path, alternative/exception paths nên khi vào triển khai thì mới phát hiện ra dẫn đến kéo dài thời gian chu kỳ triển khai SDD.

1 Like