BA viết User Story?

Hế lô anh em!

Đây là bài thứ 3 trong chuỗi series bài notes về FS. Nếu anh em nào chưa đọc 2 notes trước thì hãy dừng lại & đọc ngay để không bỏ lỡ bất kỳ thông tin nào nhóe ?

• BA viết FS như nào?
• FS kiểu truyền thống

Ở 2 phần này mình đã cùng nhau đi rất chi tiết về:

VIẾT FS KIỂU TRUYỀN THỐNG
1. Overview
2. User Requirement
3. Functional Requirement
     3.1. BPMN
     3.2. Use Case
     3.3. Business Rule
     3.4 Wireframe
     3.5 ERD
4. Non-Functional Requirement
5. Transition Requirement
6. Supporting Document

VIẾT FS KIỂU AGILE
(Mới mở đầu về cách viết theo User Story…).

Nên tiếp theo đây mình sẽ đi chi tiết vào cách viết User Story & các phần liên quan nhé.

1. User Story

Cách viết User Story chắc cũng quá quen thuộc với anh em rồi, nên mình đi sơ qua thôi. Nôm na nó có dạng:

Một vài ví dụ cho anh em dễ hình dung:

1. As a rider, I want to choose my favorite driver, so that I feel enjoyable and safe in my ride
2. As a system admin, I want to configure recruitment criteria, so that I can control recruitment quality
3. As an engineer, I want to scan the Barcode of the laptop, so that I can enter data more accurately and faster
4. As a reader, I want to cancel my subscription at any time, so that I do not lose money unintentionally

Căn bản thì User Story không khác gì User Requirement. Nhưng so với User Requirement, thì User Story được gói gọn trong một tính năng rõ ràng mà người dùng cần. Đâu đó nó mang lại cảm giác gọn gàng, có tổ chức và dễ quản lý hơn rất nhiều. Đặc biệt trong những dự án có tính biến động cao.

Tuy nhiên mình cũng có vài lưu ý cho anh em khi viết User Story.

1.1. <User> là người

<User> ở đây nên là NGƯỜI thực tế. Khác với Use Case, Actor có thể là Human hoặc System. Nhưng <user> trong User Story phải là người.

Vì sao?

Vì tiếp cận theo hướng User Story, là anh em đang setup mindset: lấy gốc ra làm người dùng, à nhầm, lấy người dùng ra làm gốc. Các giải pháp đưa ra đều nhằm mục đích giải quyết vấn đề của người dùng, chứ không chỉ đơn thuần là làm tính năng cho system.

Cụm từ “giải quyết gốc rễ vấn đề của user” nó khác hoàn toàn cụm “làm tính năng cho system” nhé anh em.

Làm cho system có tính năng đó, không có nghĩa là đã giải quyết được triệt để vấn đề của user. Mà chỉ khi mình suy nghĩ và phân tích tới tận cùng cái pain-point mà user đang gặp phải, thì khi đó mình mới đủ mường tượng được tính năng này có giải quyết được pain-point đó hay không.

Nó là cách suy nghĩ “user-oriented”. Là cái mà anh em mình nên lưu tâm khi phân tích bất cứ tính năng nào.

Có nhiều tính năng khi làm FS, anh em chỉ mới hình dung về nó thôi. Dù có phân tích kỹ đến cỡ nào, nhưng nếu chưa có trải nghiệm thực tế & suy xét kỹ càng, thì tất cả cũng chỉ là mường tượng của mình cho đến khi tính năng đó được thành hình thực tế.

Nhiều lúc cứ nghĩ: tính năng này đã ổn áp, đã giúp giải quyết vấn đề của user rồi. Nhưng khi deliver ra, tận tay test, tận tay trải nghiệm thì mới thấy có gì đó lấn cấn, cợn cợn mà khó có thể giải thích được.

Nên nếu từ đầu không đặt mình vào tâm thế của User, thì rất khó để hiểu và giải quyết vấn đề một cách hoàn chỉnh được. Nên ngay từ đề bài, User Story cần phải có “yếu tố con người” trong đó nhé anh em.

Ví dụ có lần mình làm tính năng “Global Search” trên trang chủ cho một website.

Search thì rõ ràng anh em phải mô tả cụ thể là search trên những object nào đúng không. Và khi search ra kết quả thì team Development gặp 1 technical issue là: khi user bấm vào kết quả thì có 1 vài trang vì build theo công nghệ cũ, nên không redirect đến trang chi tiết của kết quả tìm được. Mà chỉ đi được đến trang danh sách các sản phẩm bên ngoài là hết xí quách.

Lúc này team mình đang focus nhiều vào cơ chế search để đảm bảo trải nghiệm người dùng sẽ được tốt nhất. Nào là: search partial theo keyword như nào, hỗ trợ search có dấu/ không dấu như nào, rồi cách kết quả được hiển thị có đủ thông tin cần thiết hay không….

Vì quá focus vào các cơ chế search này, nên khi technical issue bên trên được raise, mình nghĩ cũng chả sao, và nghiễm nhiên ô kê với hạn chế này.

Đến hồi release ra để test, vô chính tay mình trải nghiệm thì mới thấy má ơi nó chuối. Mục đích user cần search là: để họ đến được chính xác nơi họ cần đến. Và cái họ cần là đến trang chi tiết của sản phẩm. Mà đằng này mới đưa người ta tới trang danh sách bên ngoài là đã đem con bỏ chợ rồi.

Đây chính xác chỉ là một trong những tính năng “trông có vẻ ổn”, nhưng sau cùng thì chỉ giải quyết được NỬA VỜI vấn đề của người dùng.

Nên mới thấy, khi chạy dự án, biết bao nhiêu thứ cần phải suy xét. Nên nhiều khi, thứ cơ bản nhất mình lại vô tình bỏ qua. Nếu không thường xuyên đặt mình vào tâm thế của End-User, thì chắc lỗi lầm bên trên phải lặp lại cả sớ dài.

Do đó, mục đích của viết User Story là để anh em hình dung tường tận vấn đề. Và luôn nhắc nhở mình phải “mang đôi giày” của chính end-user nhé anh em.

1.2. Viết dạng chủ động & tránh mang hình ảnh “system” vào

Này cũng là một mẹo mình muốn share với anh em.

Khi viết thì anh em phải viết theo hướng chủ động: là user chủ động, user cần cái này, cái kia, là một nhu cầu có thật, khẩn thiết, và cần mình giúp họ giải quyết vấn đề này.

Nghe nó thôi thúc và tích cực hơn đúng không anh em.

Còn tránh mang hình ảnh “system” vào là sao? Là mình chỉ nói theo ngôn ngữ của user: User cần gì mà thôi. Chứ không nói theo ngôn ngữ System có thể offer được gì cho user.

“System offer được gì cho user” là Solution Space.
Còn nói theo “User cần gì” là Problem Space.

Mình viết User Story thì chỉ nói trên Problem Space, đưa ra bài toán cần giải quyết rằng: tui đang bị zầy nè & tui đang muốn cái này. Mình không cần, không cần & không cần đưa ra solution chi tiết ở đây nhé anh em.

Hai lỗi này thường đi chung 1 cặp với nhau:

• US ổn áp: “Là nhà tuyển dụng, tôi muốn nhận thông báo về lịch hẹn phỏng vấn trước 2 ngày, để tôi có thời gian chuẩn bị phỏng vấn”
  (thông báo có thể qua email, SMS, zalo, in-app…, khi vào sâu phân tích sẽ biết thông báo qua đâu là tối ưu)
• US cần tránh: “Là nhà tuyển dụng, tôi muốn hệ thống bắn noti trên app về lịch phỏng vấn trước 2 ngày, để tôi có thời gian chuẩn bị phỏng vấn”
  (Lỗi 1: Chưa gì đã muốn nhận thông báo trên app, trong khi chưa chắc đây đã là phương án tối ưu khi chưa qua phân tích.
  Lỗi 2: Nói theo góc nhìn “system offer được gì” – cái cụm “hệ thống thông báo trên app” vô hình dung đã khóa cái đầu mình lại, không nghĩ thoáng ra được. Nếu lỡ system này củ chuối, không thể gửi thông báo trên app thì sao?!?!
  Nên mình chỉ cần tập trung vào Problem Space thôi nhé anh em).
  

1.3. Benefit không nhất thiết chỉ hướng tới User

“As a” <user> thì không nhất thiết “so that” phải là <benefit của user>

Nghĩ thoáng ra một chút thì benefit anh em có thể ghi bất cứ thứ gì, miễn:

• Nó là benefit thật sự (để cung cấp được chính xác context của requirement này)
• Và nó có thể là benefit của end-user hoặc là benefit của customer

Ví dụ: Mình đang làm 1 cái app giúp các kỹ sư tìm đường tới tận nhà của khách hàng để sửa & thay thế linh kiện laptop theo các booking.

Sau khi hoàn tất công việc, anh kỹ sư có thể nhấn 1 nút để gửi thông tin thanh toán qua Momo cho khách hàng. Để khách hàng tiện lợi thanh toán hơn. Tránh phải lui cui lấy đủ tiền mặt ra thanh toán ngay lúc đó, rồi thối tiền tới lui mắc công.

Như vậy thì với Requirement mới này, mình sẽ viết dưới dạng User Story như sau: As an engineer, I want to share payment information via Momo to customers, so that THEY can pay more conveniently.

Benefit ở đây là benefit của khách hàng, chứ không nhất thiết phải là benefit của anh engineer (là user) nhé anh em 🙂

1.4. Không phải lúc nào cũng áp dụng format

Một ý nữa là không phải lúc nào mình cũng răm rắp làm theo: As ABC, I want XYZ, so that 123 blah blah…. Với vài thứ đơn giản thì chỉ cần ghi huỵch toẹt nó ra là được.

Ví dụ Apple vừa ra mắt iOS 15, theo đó là app mình cũng cần phải check impact và nâng cấp để có thể work tốt với iOS 15. Đây là một yêu cầu mới toanh. Nếu viết Requirement theo format User Story thì sẽ như sau:

“As a user, I want my app work smoothly on iOS 15, so that I…..không bị bug khi sử dụng hả” ? (thiệt mình cũng không biết ghi chỗ này sao…)

Gác format qua 1 bên. Câu trên được diễn giải gọn gàng – súc tích bằng đúng 1 dòng: “Check impact & upgrade app to iOS 15”. Bùmmmmm, xong, ez game!!!

Vì sao?

• Vì ngữ cảnh này đơn giản, quá dễ hiểu đúng không anh em.
• Requirement này cũng rất hiển nhiên và chẳng có gì lạ lẫm (mình cũng làm i chang như khi upgrade từ iOS 13 lên iOS 14 vậy)

Do đó, sẽ có những requirement tương tự – khá là rõ ràng & hiển nhiên. Thì khi đó anh em hãy cân nhắc nên viết sao cho tối ưu nhé. Linh hoạt là chia khóa, đừng lúc nào cũng khư khư theo template, theo format. Nếu không thì…

1.5. Ai viết User Story

Phần này cũng nhiều anh em hay hỏi mình. Như bên trên mình nói thì User Story nó như User Requirement vậy. Nhưng được đóng gói ngăn nắp trong một format rõ ràng và dễ quản lý.

Nếu dự án chạy theo SCRUM hoặc các framework tương tự thì Product Owner sẽ là người viết. Product Owner có thể đến từ các bộ phận Business hoặc IT.

Còn nếu không có Product Owner, thì BA sẽ là người viết User Story. Và cũng từ User Story đó, BA cùng team sẽ phân tích & thiết kế giải pháp tương ứng về sau.

Ô kê anh em, vậy coi như mình đã đi qua về User Story.

Nếu phần này trả lời cho các câu hỏi Who, What, Why, thì phần dưới đây sẽ trả lời cho How. Đó là Acceptance Criteria.

2. Acceptance Criteria

Phần Acceptance Criteria này tương đương với Use Case & Business Rules khi anh em viết FS kiểu truyền thống. Nhưng cách thể hiện của nó thì đơn giản hơn.

Đơn thuần mình chỉ cần: 1 cái bảng & liệt kê toàn bộ các Acceptance Criteria thuộc User Story đó là xong 🙂

Nói nghe easy game vậy chứ phần này làm khá tốn máu nhé anh em. Làm FS kiểu Agile ăn tiền là ở chỗ này.

Chắc anh em sẽ có câu hỏi: Use Case thì có format, Business Rules cũng đơn thuần là note ra các rule của tính năng đó. “Vậy giờ kêu ghi Acceptance Criteria tương đương Use Case với Business Rules là ghi sao chaaaaa?”

Thì câu trả lời sẽ là: cứ liệt kê các Rules của User Story ra là được.

Cách tiếp cận này là mình đang làm theo hướng “rules-oriented”. Vì mình thấy đây là cách viết Acceptance Criteria một cách tự nhiên và dễ kiểm soát nhất.

Rules như thế nào thì cũng tương tự Business Rules mình có note ở 2 bài trước. Nhưng nhìn chung, Acceptance Criteria (AC) của anh em phải đảm bảo được 4 yếu tố sau đây.

2.1. Mỗi AC đều phải test được

Cái tên Acceptance Criteria đọc thôi là hiểu ngay ý nghĩa của nó đúng không anh em. Đây là những tiêu chí cần có để User Story được “accept”.

Mà ai cần “accept” User Story? Như ban đầu mình có nói thì FS dành cho 2 đối tượng đọc: phía Business & phía Tech. Vậy nên Acceptance Criteria mình cần ghi sao để cả 2 đối tượng này đều HIỂU và TEST được.

Phía Business đơn cử là những key-users, hay project cordinator.

Khi sản phẩm được release, họ sẽ dựa trên những gì mình viết ở Acceptance Criteria, để test xem thử hệ thống có chạy đúng như mô tả hông. Dĩ nhiên là trước đó họ cần agree với những gì mình viết. Để đảm bảo AC đã mô tả đúng với kỳ vọng của họ.

Còn phía Tech là những anh em QC, Dev, hay Designer.

• Dev hay Designer cần đọc Acceptance Criteria để break task và dựa vào đó để làm.
• QC thì cần đọc Acceptance Criteria để biết đường viết và chạy Test Case.

Do đó mỗi thứ được ghi ở Acceptance Criteria đều phải được LƯỢNG HÓA rõ ràng. 5 ký tự thì ghi rõ 5 ký tự. Flow đi từ A đến B như nào thì phải mô tả rõ. Hoặc có rule hay công thức tính toán phải viết thật cụ thể nhé anh em.

Tuyệt đối: không cảm thán, không định tính trong Acceptance Criteria. Như kiểu: “Màn hình claim điểm phải được làm tuyệt đẹp và đầy đủ thông tin. User chỉ cần vài ba cú nhấp chuột là đã claim thành công”.

Ối zồồồi ôiiiiii

Tuyệt đẹp là tuyệt đẹp xaoooo? Đầy đủ thông tin là đầy đủ như nàoooo?  Rồi “vài ba” cú nhấp là ba hay bốn?

Viết như vậy không ai test được hết. Viết như vậy là tạch Acceptance Criteria, và tạch luôn cả User Story, tạch luôn cả dự án. Viết vầy sớm muộn gì anh em cũng bị chém thôi nên…

2.2. Phải ghi RÕ RÀNG, chính xác, và dễ hình dung

Cái này thì quá hiển nhiên rồi. Xuyên suốt chuỗi bài về FS này mình luôn lặp đi lặp lại ý này. Cốt cũng chỉ để anh em nhớ nằm lòng nguyên tắc vàng này thôi.

Viết FS kiểu Agile mà chỉ có cái User Story không thôi thì chưa bao giờ là đủ. Nó như cái mở bài vậy. Mở bài anh em viết có khúc chiết đến cỡ nào. Mà thân bài nó dàiiiiiiii lêêêêê thêêêêê thì cũng không ổn.

Acceptance Criteria chính là thân bài. Nó nó cái ruột, là cái bo đỳ của cả FS. Nên bằng mọi cách, phải giữ cho nó đơn giản và dễ hiểu nhất có thể. Để ai cũng có thể tiếp cận nhé anh em.

2.3. Không mô tả chi tiết về technical

Dĩ nhiên rồi, vì FS còn có cả business users đọc nữa, nên “keep it as simple as possible”. Thường mình thấy điểm này hay gặp ở các anh em trước làm Dev xong chuyển qua BA. Nên đôi phần nhìn vấn đề sẽ hơi thiên về lăng kính technical.

Điểm này mình nghĩ cũng không quá to tát. Chỉ cần khách hàng hay anh em góp ý, rồi thay đổi dần là được.

2.4. Ai là người viết Acceptance Criteria

Câu trả lời là team dự án nhé anh em. Cụ thể hơn là BA, sau một loạt những nỗ lực lăn, lê, bò, trườn, phân tích, thiết kế, đổ máu & nước mắt, BA sẽ là người “đứng mũi chịu sào” viết Acceptance Criteria.

Có vài anh em hay nhầm lẫn là Product Owner là người viết Acceptance Criteria. Ý này vừa đúng, vừa không.

• Nếu project chạy theo SCRUM (hoặc các framework tương đương) định nghĩa được role Product Owner rõ ràng. Và cái anh PO này work được với Development Team. Thì khi đó Product Owner mới là người viết Acceptance Criteria và chịu trách nhiệm sau cùng.
• Các trường hợp còn lại (prj không hoàn toàn áp dụng SCRUM, hay Waterfall triệt để) mà có role BA, thì anh BA này phải là người làm Acceptance Criteria.

Sau cùng, PO hay BA thì cũng chỉ là title. Câu chốt đơn để anh em hình dung rõ nhất là: Người làm-công-việc-Business-Analyst sẽ là người chịu trách nhiệm cho Acceptance Criteria.

Nhưng rõ ràng BA không phải là người duy nhất được viết Acceptance Criteria. Mà là cả Development Team phải cùng trao đổi và đưa ra ý kiến để input vào AC.

Bắt đầu 1 quan điểm, BA sẽ trình bày và khơi mào thảo luận cho anh em.

Dev có thể bàn về cách làm. Các technical spike có thể gặp phải. Nói về system performance, scalable,…. và hàng ti tỉ thứ khác có thể được đem ra mổ xẻ. Còn QC sẽ share góc nhìn về logic hay các góc khuất nhìn từ khía cạnh testing.

Từ đó, gom góp lại toàn bộ, Business Analyst sẽ là người đóng gói cuối cùng và đưa lên FS dạng Acceptance Criteria. Cứ vậy triển cho từng User Story một.

Như vậy anh em có thể thấy:

• Cả Development Team (bao gồm cả BA) là người RESPONSIBLE cho việt làm Acceptance Criteria
• Nhưng BA lại là người ACCOUNTABLE cho Acceptance Criteria.

Anh tham khảo thêm mô hình RACI nhé

Và ý cuối cùng là anh em nên chia Acceptance Criteria theo từng tính năng nhỏ có trong User Story. Rồi viết theo từng mục như đã chia. Làm như vầy, mình sẽ dễ hình dung từng vấn đề một. Đảm bảo các khía cạnh đều được cover, và tránh bị sót.

Ô kê lý thuyết nhiều quá, dưới đây mình sẽ show cho anh em vài ví dụ tham khảo cụ thể nhé.

Ví dụ Acceptance Criteria

Ví dụ Acceptance Criteria

Dự án này mình viết bằng Tiếng Việt nên phần nào cũng dễ viết, dễ đọc & dễ hiểu hơn so với Tiếng Anh nên show cho anh em. Xem qua nếu có concern hay thắc mắc gì thì cứ comment bên dưới cho mình nhé.

3. BPMN & Wireframe

Ô kê nội dung sau cùng của FS viết theo kiểu Agile này cũng chính là BPMN và Wireframe. Phần này thì nội dung tương tự như FS kiểu truyền thống nên anh em xem tham khảo lại các bài trước đó nhé.

Tập này đã dài nên mình sẽ tạm kết ở đây nhé anh em. Tập sau mình sẽ đóng gói toàn bộ để anh em dễ hình dung & nhớ được lâu hơn. See yahh!!!