Mục đích của mệnh đề 'so that' trong định nghĩa câu chuyện của người dùng là gì?

Một câu chuyện người dùng có thể được định nghĩa trong một câu như:

As a <type of user> I want <some goal> so that <some reason>

Chỉ cần Google cho 'công thức câu chuyện người dùng' và các liên kết đầu tiên đều đề xuất công thức này.

Câu hỏi của tôi là, mục đích của điều khoản đó là gì? Có nó cho các nhà quản lý? Có phải để các nhà quản lý dự án và các bên liên quan có thể hiểu mức độ ưu tiên của mặt hàng tốt hơn? Tại sao nó ở đó?

Lưu ý: Tôi đã làm việc với as a <type of user> I want <some goal>công thức và nó hoạt động tốt. Tôi đã không nhận thấy bất kỳ vấn đề trong công việc của tôi bằng cách thực hiện định dạng này ngắn gọn hơn.

Mục đích là để tránh các công việc không cần thiết bằng cách buộc người dùng / khách hàng cung cấp lợi ích kinh doanh rõ ràng, hữu hình là lý do cho sự tồn tại của tính năng này.

Không có gì lạ khi các tính năng đó được thêm vào chỉ vì ai đó nghĩ rằng chúng nghe hay, hoặc vì phần mềm khác có nó, vì vậy chúng ta cũng phải có nó. Thường xuyên hơn không, những điều đó ít nhất là hoàn toàn không cần thiết, nếu không tích cực gây hại.

Tuy nhiên, thường dễ dàng phát hiện ra các tính năng đó, bởi vì những người đề xuất chúng nói chung sẽ gặp khó khăn khi cung cấp một lý do kinh doanh thuyết phục cho chúng.

Có một kỹ thuật gọi là Popping The Why Stack , trong đó bạn lấy phần "sao cho" và hỏi "Tại sao?", Sau đó bạn lấy câu trả lời đó và hỏi "Tại sao?" một lần nữa, đệ quy. Nếu, sau (giả sử) từ ba đến năm chữ "Tại sao", bạn chưa đến "bởi vì nó sẽ giúp chúng ta kiếm tiền" hoặc "bởi vì nó sẽ giúp chúng ta tiết kiệm tiền" (tốt nhất là với một mô tả chính xác về cách đó sẽ xảy ra), sau đó tính năng này không đáng để thực hiện.

Một số người tin rằng điều này quan trọng đến mức họ thực sự đặt nó lên hàng đầu trong mẫu câu chuyện:

Để mà [...]

Như một [...]

Tôi muốn [...]

Có một ví dụ tuyệt vời từ một cuộc nói chuyện của một số người của Th Thinkworks: một trong những khách hàng của họ muốn các báo cáo được in được định dạng theo một cách rất đặc biệt. Khi chuyên gia tư vấn hỏi "Tại sao", họ nói rằng bằng cách đó họ dễ dàng nhập lại hơn. Vì vậy, thay vì thực hiện tính năng định dạng báo cáo, họ chỉ chuyển các báo cáo qua mạng. Nếu không có điều khoản "vì vậy", họ vẫn sẽ in các giấy tờ theo một bộ phận, gửi chúng cho bộ phận khác và nhập lại.

"Vì vậy" cung cấp một lý do cho mục tiêu.

Ví dụ: mục tiêu có thể là hiển thị số liệu bán hàng của tháng trước. Bạn có thể làm việc với điều đó, nhưng một lý do bạn cần biết tại sao bạn muốn hiển thị chúng để bạn có thể nhận được các yêu cầu sâu hơn. Họ muốn làm gì với số liệu bán hàng hoặc triển vọng? Biết thông tin này sẽ giúp bạn hiểu rõ hơn về ứng dụng và có nhiều cơ hội thiết kế giao diện người dùng cho phép khách hàng thực hiện những gì họ muốn.

Một cách sử dụng khác cho lý do là ưu tiên các câu chuyện. Nếu bạn có hai câu chuyện:

Tôi muốn hiển thị số liệu bán hàng của tháng trước.
Tôi muốn hiển thị một danh sách các khách hàng tiềm năng.

nhưng chỉ có tài nguyên để làm một - bạn sẽ làm gì? Nếu không có lý do, bạn chỉ cần đoán và bạn có thể không cung cấp đúng thời điểm. Mặc dù điều này ít quan trọng hơn vì khách hàng nên nói cho bạn biết phải làm gì trước tiên, nhưng đôi khi không phải vậy.

Ngoài những gì đã được nói, việc cung cấp một lý do cho các yêu cầu cho phép bạn đánh giá tính hợp lệ của yêu cầu. Người dùng có thể muốn mọi thứ vì lý do sai. Có "vì vậy" làm rõ lý do do đó cho phép nhà phân tích xác nhận rằng yêu cầu được thỏa mãn tốt nhất theo cách này.

Thí dụ:

AI muốn có thể chọn nhân viên từ danh sách tất cả nhân viên công ty

BI muốn có thể chọn nhân viên từ danh sách tất cả nhân viên của công ty để tôi có thể xóa những người đã rời công ty 5 năm trước.

(B) không có ý nghĩa ngay cả trong một tổ chức trung bình, nhưng bạn có thể xác nhận yêu cầu của người dùng và đề xuất một cách khác để khách hàng thực hiện yêu cầu.