Viết các câu chuyện người dùng hiệu quả là kỹ năng nền tảng cho bất kỳ ai bước vào quản lý sản phẩm. Đó là cầu nối giữa những ý tưởng mơ hồ và công việc phát triển cụ thể. Không có sự giao tiếp rõ ràng, các đội sẽ xây dựng sai tính năng, các bên liên quan mất niềm tin và nguồn lực bị lãng phí. Hướng dẫn này cung cấp một cách tiếp cận có cấu trúc để xây dựng các câu chuyện mang lại giá trị, đảm bảo sự rõ ràng và đồng bộ hóa nỗ lực kỹ thuật với mục tiêu kinh doanh.
Câu chuyện người dùng là gì? 🧩
Một câu chuyện người dùng là mô tả đơn giản, súc tích về một tính năng được kể từ góc nhìn của người mong muốn khả năng mới, thường là người dùng hoặc khách hàng. Nó không phải là tài liệu quy định. Đó là một chỗ trống cho một cuộc trò chuyện. Mục tiêu là ghi lại lý do tại sao, chứ không chỉ là điều gì.
Khi bạn viết một câu chuyện, bạn đang xác định một đơn vị giá trị. Điều này cho phép đội ngũ ước lượng nỗ lực, lập kế hoạch các đợt sprint và theo dõi tiến độ. Nó chuyển trọng tâm từ việc triển khai kỹ thuật sang lợi ích cho người dùng.
Tại sao điều này quan trọng
- Rõ ràng:Giảm sự mơ hồ cho các nhà phát triển và nhà thiết kế.
- Tập trung:Giúp đội ngũ thống nhất về kết quả cụ thể.
- Hợp tác:Khuyến khích thảo luận thay vì suy đoán.
- Giá trị:Đảm bảo mỗi dòng mã phục vụ nhu cầu của người dùng.
Định dạng chuẩn 📄
Mặc dù có sự linh hoạt, định dạng chuẩn trong ngành tuân theo một mẫu cụ thể. Cấu trúc này đảm bảo tính nhất quán trong danh sách công việc của bạn. Mỗi câu chuyện cần trả lời ba câu hỏi: Ai, Điều gì và Tại sao.
Là một [loại người dùng],
Tôi muốn [thực hiện một hành động],
Để rằng [thu được lợi ích].
Phân tích mẫu cấu trúc
- Là một:Xác định nhân vật. Điều này xác định ai đang gặp phải vấn đề. Có phải là quản trị viên? Một khách truy cập? Một thành viên cao cấp?
- Tôi muốn:Mô tả chức năng hoặc hành động. Đây là cơ chế giải pháp.
- Để rằng:Nêu rõ đề xuất giá trị. Đây là kết quả hoặc lợi ích đạt được.
Hãy xem ví dụ sau:
- Là mộtkhách hàng,
Tôi muốnlọc kết quả tìm kiếm theo phạm vi giá tiền,
Để rằngTôi có thể tìm thấy sản phẩm trong ngân sách của mình một cách nhanh chóng.
Mô hình INVEST ✅
Không phải ý tưởng nào cũng là một câu chuyện người dùng hợp lệ. Để đảm bảo chất lượng, hãy sử dụng mô hình INVEST như một danh sách kiểm tra. Chữ viết tắt này giúp bạn xác minh cấu trúc và tính hữu dụng của các câu chuyện trước khi chúng đến hàng đợi phát triển.
| Nguyên tắc | Mô tả | Kiểm tra |
|---|---|---|
| IĐộc lập | Các câu chuyện không nên phụ thuộc vào các câu chuyện khác để được triển khai. | Câu chuyện này có thể được xây dựng độc lập không? |
N
| Chi tiết được thảo luận, không được xác định đầy đủ ngay từ đầu. |
Có chỗ cho cuộc thảo luận không? |
|
| VCó giá trị | Phải mang lại giá trị cho người dùng hoặc doanh nghiệp. | Liệu điều này có giải quyết được một vấn đề không? |
E
| Đội ngũ phải có thể ước lượng được nỗ lực cần thiết. |
Chúng ta có thể ước lượng được điều này không? |
|
| Strung tâm mua sắm | Phải phù hợp trong một lần lặp lại hoặc một sprint duy nhất. | Kích thước phạm vi có thể kiểm soát được không? |
| Tổn định | Phải có các tiêu chí rõ ràng để xác minh việc hoàn thành. | Chúng ta biết nó hoạt động như thế nào? |
Thu thập các yêu cầu 🗣️
Trước khi viết một từ duy nhất, bạn cần hiểu rõ không gian vấn đề. Bạn không thể viết một câu chuyện trong khoảng trống. Giai đoạn này bao gồm nghiên cứu và khám phá.
1. Xác định nhân vật người dùng
Bạn đang xây dựng cho ai? Tạo ra hoặc tham khảo các nhân vật người dùng. Đây là những mẫu hình đại diện cho nhóm người dùng của bạn. Việc hiểu rõ động cơ, điểm đau và trình độ kỹ thuật của họ sẽ giúp bạn điều chỉnh câu chuyện phù hợp.
- Phương pháp nghiên cứu:Phỏng vấn người dùng, khảo sát, phân tích vé hỗ trợ và dữ liệu sử dụng.
- Câu hỏi then chốt:Điểm gây khó khăn hiện tại đối với người dùng này là gì?
2. Xác định bối cảnh
Hiểu rõ tính năng này nằm ở đâu trong sản phẩm tổng thể. Nó có kết nối với dữ liệu hiện có không? Nó có thay thế quy trình thủ công không? Bối cảnh giúp ngăn ngừa sự tách biệt và đảm bảo tích hợp.
3. Xác minh giá trị
Hỏi vì sao tính năng này cần thiết. Nếu bạn không thể nêu rõ lợi ích, đừng viết câu chuyện. Phần “Để mà” ở đây rất quan trọng. Nếu nó không mang lại giá trị, thì không nên xây dựng.
Soạn thảo tiêu chí chấp nhận 🎯
Tiêu chí chấp nhận là những điều kiện mà sản phẩm phần mềm phải đáp ứng để được người dùng, khách hàng hoặc bên liên quan chấp nhận. Chúng xác định ranh giới của câu chuyện. Không có chúng, “hoàn thành” sẽ mang tính chủ quan.
Hướng dẫn cho tiêu chí
- Cụ thể hóa:Tránh các từ mơ hồ như “nhanh” hay “dễ”. Sử dụng các chỉ số khi có thể.
- Có thể kiểm thử:Người kiểm thử phải có thể đọc tiêu chí và viết một trường hợp kiểm thử.
- Giữ tính trung lập:Tập trung vào hành vi, không phải chi tiết triển khai.
Ví dụ tiêu chí
- Hệ thống xác minh rằng trường email chứa ký tự @.
- Nút bấm thay đổi màu thành màu xanh khi gửi thành công.
- Trang được tải trong vòng 2 giây trên kết nối tiêu chuẩn.
- Các thông báo lỗi xuất hiện ngay lập tức nếu mật khẩu quá ngắn.
Chiến lược ưu tiên 📊
Bạn sẽ có nhiều câu chuyện hơn thời gian. Việc ưu tiên đảm bảo bạn xây dựng những điều quan trọng nhất trước tiên. Dưới đây là các phương pháp phổ biến để xếp hạng danh sách công việc của bạn.
1. Phương pháp MoSCoW
| Thể loại | Ý nghĩa |
|---|---|
| MPhải có | Yêu cầu không thể thương lượng. Nếu thiếu những điều này, sản phẩm sẽ thất bại. |
| SNên có | Quan trọng nhưng không thiết yếu. Có thể hoãn lại nếu cần thiết. |
| CCó thể có | Tính năng mong muốn. Chỉ thêm nếu có thời gian. |
| WKhông có | Loại bỏ trong khung thời gian hiện tại. |
2. Giá trị so với nỗ lực
Vẽ các câu chuyện của bạn trên ma trận. Đặt các mục có giá trị cao, nỗ lực thấp ở trên cùng. Đây là những chiến thắng nhanh của bạn. Những mục có nỗ lực cao, giá trị thấp nên tránh hoặc xem xét lại.
3. Tác động so với rủi ro
Xem xét rủi ro nếu không xây dựng tính năng đó. Những mục có tác động cao và rủi ro cao thường đòi hỏi sự chú ý ngay lập tức để ngăn ngừa kết quả tiêu cực.
Những sai lầm phổ biến cần tránh ⚠️
Ngay cả những người có kinh nghiệm cũng mắc sai lầm. Nhận thức được những điểm nguy hiểm phổ biến sẽ giúp bạn duy trì tiêu chuẩn cao.
1. Viết cho nhà phát triển
Tránh dùng thuật ngữ kỹ thuật trong tiêu đề hoặc mô tả câu chuyện. Viết cho người dùng cuối. Các chi tiết kỹ thuật nên nằm trong tiêu chí chấp nhận hoặc một nhiệm vụ kỹ thuật riêng biệt.
2. Quá nhiều chi tiết
Câu chuyện là một chỗ trống cho cuộc trò chuyện. Nếu bạn viết một tài liệu 10 trang, bạn đã ngăn cản sự hợp tác. Hãy giữ câu chuyện ngắn gọn và khuyến khích đặt câu hỏi.
3. Bỏ qua các trường hợp biên
Đừng chỉ viết theo đường đi suôn sẻ. Hãy cân nhắc những gì xảy ra khi mạng bị lỗi, hoặc người dùng nhập dữ liệu không hợp lệ. Những trường hợp biên này cần được đưa vào tiêu chí.
4. Một câu chuyện lớn
Các cốt truyện lớn là những khối công việc lớn cần được chia nhỏ. Đừng cố xây dựng toàn bộ hệ thống đăng nhập trong một câu chuyện. Hãy chia nhỏ thành các đơn vị nhỏ hơn, có thể kiểm thử.
Chỉnh sửa và Hợp tác 🔁
Viết câu chuyện chỉ là khởi đầu. Quá trình chỉnh sửa, thường được gọi là làm sạch, là nơi câu chuyện trở nên rõ ràng hơn.
Phiên họp chỉnh sửa
Tổ chức các cuộc họp định kỳ với đội kỹ thuật của bạn. Cùng nhau đi qua từng câu chuyện.
- Đặt câu hỏi: “Bạn sẽ triển khai điều này như thế nào?” “Những rủi ro là gì?”
- Ước lượng:Sử dụng điểm câu chuyện hoặc giờ để đánh giá độ phức tạp.
- Chia nhỏ: Nếu một câu chuyện quá lớn, hãy chia ngay thành các phần nhỏ hơn.
Vòng phản hồi
Sau khi câu chuyện được xây dựng, hãy cùng đội ngũ xem xét lại. Kết quả có khớp với tuyên bố ‘Vì vậy để’ không? Nếu không, hãy cập nhật quy trình của bạn. Cải tiến liên tục là chìa khóa.
Ví dụ: Câu chuyện Tốt vs. Xấu 📝
So sánh các ví dụ làm nổi bật sự khác biệt giữa các yêu cầu mơ hồ và các câu chuyện có thể hành động.
| Ví dụ xấu | Tại sao nó thất bại | Ví dụ tốt |
|---|---|---|
| Thêm chế độ tối. | Ai quan tâm? Giá trị là gì? Chỉ mang tính kỹ thuật. | Là mộtngười dùng thường xuyên hoạt động về đêm,Tôi muốnmột chủ đề chế độ tối,đểtôi có thể đọc nội dung mà không bị mỏi mắt trong điều kiện ánh sáng yếu. |
| Sửa lỗi tìm kiếm. | Lỗi nào? Ai bị ảnh hưởng? Phạm vi không rõ ràng. | Là một người mua sắm, Tôi muốnkết quả tìm kiếm hiển thị các sản phẩm liên quan, đểtôi có thể tìm thấy các mặt hàng mình đang tìm một cách nhanh chóng. |
| Làm cho bảng điều khiển nhanh hơn. | “Nhanh hơn” không thể đo lường được. Không có góc nhìn người dùng. | Là mộtnhà phân tích dữ liệu, Tôi muốnbảng điều khiển tải trong dưới 3 giây, đểtôi có thể đưa ra quyết định đúng thời điểm. |
Suy nghĩ cuối cùng về giao tiếp 💬
Câu chuyện người dùng tốt nhất là câu chuyện khơi gợi được cuộc trò chuyện đúng đắn. Đó là một công cụ cho sự thấu cảm. Khi bạn viết một câu chuyện, bạn đang bước vào đôi giày của người dùng. Bạn đang đấu tranh cho trải nghiệm của họ.
Đừng coi đây là một nhiệm vụ hành chính. Hãy coi đây là một bài tập chiến lược. Mỗi câu chuyện bạn viết đều phải thúc đẩy sản phẩm tiến lên. Nếu không, hãy đặt câu hỏi về sự tồn tại của nó.
Hãy nhớ:
- Giữ cho ngắn gọn và tập trung.
- Tập trung vào kết quả, chứ không phải đầu ra.
- Khuyến khích hợp tác từ sớm.
- Kiểm tra các giả định của bạn.
Bằng cách tuân theo các bước này và tuân thủ các nguyên tắc được nêu ra, bạn sẽ xây dựng được danh sách công việc mang lại kết quả. Bạn sẽ chuyển từ việc đoán mò sang hiểu rõ. Bạn sẽ tạo ra những sản phẩm mà con người thực sự muốn sử dụng.
Danh sách kiểm tra cho các quản lý sản phẩm mới 📋
Trước khi chuyển một câu chuyện sang phát triển, hãy thực hiện danh sách kiểm tra này:
- ☐ Nó có tuân theo định dạng “Là một… Tôi muốn… Để…” không?
- ☐ Nhân vật đại diện có được xác định rõ ràng không?
- ☐ Lợi ích cốt lõi có rõ ràng không?
- ☐ Các tiêu chí chấp nhận có cụ thể và kiểm thử được không?
- ☐ Câu chuyện này có độc lập với các câu chuyện khác không?
- ☐ Đội đã ước lượng nỗ lực chưa?
- ☐ Nó có phù hợp với năng lực hiện tại của sprint không?
Sự kỷ luật này đảm bảo chất lượng. Nó tiết kiệm thời gian trong dài hạn bằng cách ngăn ngừa công việc phải làm lại. Nó xây dựng niềm tin giữa sản phẩm, kỹ thuật và các bên liên quan. Bắt đầu nhỏ, lặp lại thường xuyên, và luôn đặt người dùng ở trung tâm của mọi quyết định.
