Mở đầu — vì sao bài này quan trọng
Nếu bạn đang là QA/Tester và muốn chuyển sang BA, thì PRD (Product Requirements Document) và Process Flow chính là hai "vũ khí" đầu tiên mà nhà tuyển dụng sẽ kiểm tra. Trong các bài trước, bạn đã học cách chuyển từ test case sang user story, hiểu được mối quan hệ giữa QA và BA. Bài này tập trung vào một việc rất cụ thể: làm sao để bạn cầm bút (hoặc mở Confluence) lên và viết ra được một tài liệu yêu cầu sản phẩm hoàn chỉnh, kèm theo sơ đồ luồng nghiệp vụ mà developer và stakeholder đều đọc hiểu.
Đây là điểm rẽ quan trọng trong sự nghiệp. Khi còn làm QA, bạn là người đọc tài liệu do người khác viết để soi lỗi. Khi trở thành BA, bạn là người viết ra tài liệu đó — và mọi người sẽ soi lỗi bạn. Nghe có vẻ áp lực, nhưng tin tốt là: chính những năm tháng soi tài liệu của người khác đã trang bị cho bạn con mắt phát hiện chỗ mơ hồ, chỗ thiếu, chỗ mâu thuẫn — thứ mà rất nhiều BA "tay ngang" không có. Bạn không bắt đầu từ con số không. Bạn bắt đầu với một lợi thế ẩn.
Trong bài này, tôi sẽ giúp bạn hiểu cấu trúc một PRD chuẩn, cách vẽ Process Flow đúng quy ước, và quan trọng nhất: cách tận dụng tư duy QA để viết hai tài liệu này tốt hơn người thường. Chúng ta sẽ đi qua khái niệm, ví dụ thực tế tại các công ty Việt Nam, hướng dẫn từng bước, lỗi hay gặp và một bài tập để bạn luyện tay ngay.
Khái niệm cốt lõi
PRD là gì và khác gì với những tài liệu bạn từng đọc
PRD — Product Requirements Document — là tài liệu mô tả cái gì cần được xây dựng và tại sao, chứ không phải làm thế nào (cái "làm thế nào" thuộc về phần thiết kế kỹ thuật của dev). Một PRD tốt trả lời được: Chúng ta giải quyết vấn đề gì? Cho ai? Khi xây xong thì biểu hiện như thế nào là đúng? Phạm vi đến đâu?
Khi còn làm QA, có thể bạn quen với SRS (Software Requirements Specification) hoặc test plan. PRD nằm ở tầng cao hơn một chút — nó thiên về sản phẩm và người dùng, ít chi tiết kỹ thuật hơn SRS, nhưng vẫn đủ cụ thể để dev và QA dựa vào đó làm việc. Một PRD điển hình gồm các phần:
- Bối cảnh & mục tiêu (Background & Goals): Vì sao làm tính năng này? Mục tiêu kinh doanh là gì (ví dụ: giảm 30% tỷ lệ bỏ giỏ hàng)?
- Phạm vi (Scope / Out of scope): Cái gì làm, cái gì không làm trong phiên bản này. Phần "out of scope" cực kỳ quan trọng mà người mới hay bỏ qua.
- User personas / đối tượng người dùng: Ai sẽ dùng tính năng này.
- Yêu cầu chức năng (Functional Requirements): Hệ thống phải làm được gì, thường viết dưới dạng user story hoặc danh sách yêu cầu được đánh số.
- Yêu cầu phi chức năng (Non-functional Requirements): Hiệu năng, bảo mật, khả năng chịu tải.
- Acceptance Criteria: Điều kiện để coi là "xong và đúng".
- Process Flow / Wireframe đính kèm: Sơ đồ luồng và phác thảo giao diện.
- Giả định, ràng buộc, rủi ro, câu hỏi mở: Những điều chưa chắc chắn.
Process Flow là gì
Process Flow (sơ đồ luồng nghiệp vụ) là hình vẽ thể hiện chuỗi các bước, quyết định và tác nhân trong một quy trình. Nó trả lời câu hỏi: "Khi người dùng làm việc X, hệ thống và con người tương tác với nhau theo trình tự nào?". Có nhiều cấp độ, từ flowchart đơn giản đến BPMN 2.0 chuẩn doanh nghiệp (BPMN sẽ được học sâu ở bài 21). Ở bài này, ta dùng flowchart cơ bản — vừa đủ để diễn đạt rõ ràng.
Các ký hiệu cơ bản bạn cần nhớ:
- Hình bầu dục (oval): Điểm bắt đầu / kết thúc.
- Hình chữ nhật (rectangle): Một bước xử lý / hành động.
- Hình thoi (diamond): Một điểm ra quyết định — luôn rẽ nhánh thành "Có/Không" hoặc các điều kiện.
- Mũi tên: Hướng đi của luồng.
- Swimlane (làn bơi): Khi có nhiều tác nhân (người dùng, hệ thống, nhân viên duyệt), mỗi tác nhân một làn để thấy rõ ai làm gì.
Vì sao QA viết PRD và Process Flow rất nhanh "lên tay"
Đây là phần tôi muốn bạn ghi nhớ nhất. Tư duy QA cho bạn ba siêu năng lực khi viết hai tài liệu này:
Thứ nhất — tư duy edge case. Khi vẽ Process Flow, người thường chỉ vẽ "happy path" (luồng thuận lợi). Bạn — với bản năng của một tester — sẽ tự động hỏi: "Nếu mạng rớt giữa chừng thì sao? Nếu người dùng bấm nút hai lần thì sao? Nếu số dư không đủ thì sao?". Mỗi câu hỏi đó là một nhánh trong sơ đồ mà BA khác hay quên.
Thứ hai — tư duy về tính kiểm chứng. Khi viết Acceptance Criteria trong PRD, bạn vốn quen nghĩ "điều kiện này test kiểu gì?". Nhờ vậy AC của bạn sẽ cụ thể, đo được, không mơ hồ kiểu "hệ thống phải nhanh" mà sẽ là "trang tải xong trong vòng 2 giây với 1000 user đồng thời".
Thứ ba — tư duy truy vết. Bạn quen với requirement traceability matrix, nên khi viết PRD bạn tự nhiên đánh số yêu cầu, liên kết yêu cầu với mục tiêu kinh doanh, tránh tình trạng "viết một tính năng mồ côi chẳng phục vụ mục tiêu nào".
Tình huống thực tế
Ví dụ 1 — Chị Hương, QA tại một ngân hàng số ở TP.HCM
Chị Hương làm QA 4 năm cho một ngân hàng số (giả định tên là Timo-style). Khi được giao việc viết PRD đầu tiên cho tính năng "Đặt lịch chuyển khoản định kỳ", chị mắc đúng lỗi của người mới: chị viết PRD dày 12 trang, mô tả chi tiết từng màn hình, từng nút bấm, thậm chí ghi cả tên field trong database. Product Owner đọc xong nhận xét: "Em đang viết spec kỹ thuật, không phải PRD. Anh không thấy tại sao khách hàng cần tính năng này, và thành công trông như thế nào".
Chị Hương về viết lại. Lần này chị mở đầu bằng mục tiêu: "35% khách hàng phải thao tác chuyển tiền trả góp/tiền nhà mỗi tháng một cách thủ công, gây ra 1.200 lượt gọi tổng đài/tháng vì quên hạn. Tính năng đặt lịch định kỳ nhằm giảm 50% số cuộc gọi này trong quý". Sau đó chị mới đi vào yêu cầu chức năng, và đính kèm Process Flow.
Điều thú vị: chính ở Process Flow, lợi thế QA của chị Hương tỏa sáng. Chị vẽ ra nhánh "Nếu đến ngày chuyển mà số dư không đủ thì sao?" — một câu hỏi mà cả Product Owner lẫn dev đều chưa nghĩ tới. Cuộc họp dừng lại 20 phút chỉ để thống nhất xử lý: thử lại sau 24h, gửi thông báo, và sau 3 lần thất bại thì hủy lịch. Nhánh đó về sau cứu team khỏi một sự cố nghiêm trọng.
Bài học: PRD bắt đầu từ "tại sao" và "thành công là gì", không phải từ chi tiết màn hình. Và tư duy edge case của QA chính là thứ làm Process Flow của bạn giá trị hơn người khác.
Ví dụ 2 — Anh Tuấn tại công ty outsource ở Đà Nẵng
Anh Tuấn là QA tại một công ty outsource (giả định tên FPT-style) làm dự án e-commerce cho khách Nhật. Anh được luân chuyển thử sang vai BA. Tính năng cần viết PRD: "Áp mã giảm giá khi thanh toán".
Anh Tuấn vẽ Process Flow trước khi viết chữ nào — một thói quen rất tốt. Anh dùng swimlane với ba làn: Khách hàng, Hệ thống Web, Hệ thống Khuyến mãi. Nhờ vẽ ra, anh phát hiện một câu hỏi nghiệp vụ mà tài liệu khách gửi sang không nói rõ: "Nếu khách áp hai mã giảm giá cùng lúc thì có cộng dồn không?". Anh ghi câu này vào mục "Câu hỏi mở" trong PRD và gửi cho khách.
Khách trả lời: chỉ cho phép một mã. Nếu anh Tuấn không vẽ flow và không có thói quen liệt kê câu hỏi mở, dev có thể đã code mặc định cho cộng dồn, và đến UAT mới phát hiện — tốn cả tuần sửa.
Bài học: Vẽ Process Flow trước khi viết PRD giúp lộ ra những lỗ hổng nghiệp vụ. Mục "Câu hỏi mở / Giả định" trong PRD không phải để cho đẹp — nó là nơi bạn biến sự mơ hồ thành câu hỏi cụ thể cho stakeholder.
Ví dụ 3 — Lỗi của một BA tay ngang để bạn so sánh
Tôi từng review PRD của một bạn BA chuyển từ marketing sang (không có nền QA). Bạn ấy viết PRD cho tính năng "đăng ký tài khoản" rất trôi chảy, văn phong mượt mà. Nhưng khi đọc kỹ, tôi đếm được: không có nhánh xử lý email đã tồn tại, không có điều kiện cho mật khẩu yếu, không nói gì về việc verify OTP hết hạn, và Acceptance Criteria chỉ ghi chung chung "người dùng đăng ký thành công".
Một QA chuyển BA gần như không bao giờ mắc những lỗi này, vì bạn đã từng test hàng trăm form đăng ký và biết tất cả những chỗ có thể vỡ.
Bài học: Nền tảng QA giúp bạn viết PRD "kín kẽ" — đầy đủ các luồng phụ và điều kiện biên. Đây là điểm bán hàng (selling point) của bạn khi phỏng vấn BA. Hãy nói rõ điều này với nhà tuyển dụng.
Hướng dẫn từng bước
Dưới đây là quy trình thực tế để bạn viết một PRD kèm Process Flow từ đầu.
Bước 1 — Làm rõ mục tiêu và vấn đề. Trước khi viết bất cứ chữ nào, trả lời: Vấn đề là gì? Ai gặp? Mục tiêu kinh doanh đo bằng con số nào? Nếu không trả lời được, đừng viết vội — hãy đi hỏi stakeholder. Đây là kỹ năng elicitation sẽ học sâu ở các bài sau, nhưng ngay bây giờ hãy tập thói quen: không viết PRD khi chưa rõ "tại sao".
Bước 2 — Xác định phạm vi (Scope & Out of scope). Liệt kê rõ phiên bản này làm gì và không làm gì. Ví dụ: "Phiên bản 1 chỉ hỗ trợ chuyển khoản nội bộ ngân hàng. Chuyển liên ngân hàng là out of scope". Mục out-of-scope chống "phình phạm vi" (scope creep) — kẻ thù số một của dự án.
Bước 3 — Vẽ Process Flow trước, viết chi tiết sau. Đây là mẹo của dân QA giỏi. Mở Draw.io, Lucidchart, Miro hoặc thậm chí Figma. Bắt đầu từ điểm Start, đi qua các bước happy path, rồi quay lại thêm các nhánh quyết định (hình thoi). Với mỗi hình thoi, hỏi: "Nhánh Không/thất bại đi đâu?". Dùng swimlane nếu có nhiều tác nhân. Việc vẽ flow sẽ tự động lộ ra các yêu cầu bạn cần viết.
Bước 4 — Viết yêu cầu chức năng dựa trên flow. Mỗi bước và mỗi nhánh trong flow tương ứng với một hoặc vài yêu cầu chức năng. Đánh số chúng (FR-01, FR-02...) để dễ truy vết. Viết dưới dạng user story nếu team theo Agile: "Là khách hàng, tôi muốn... để...".
Bước 5 — Viết Acceptance Criteria đo được. Với mỗi yêu cầu, viết AC theo kiểu Given-When-Then hoặc checklist. Tận dụng tư duy QA: hỏi "cái này test thế nào?". Nếu một AC không test được thì nó chưa đủ tốt.
Bước 6 — Bổ sung yêu cầu phi chức năng, giả định, rủi ro, câu hỏi mở. Đừng quên hiệu năng, bảo mật. Liệt kê mọi giả định bạn đang dựa vào và mọi câu hỏi chưa có lời giải.
Bước 7 — Review chéo. Gửi cho dev lead và một QA để soi. Nghịch lý thú vị: giờ bạn là người viết, và bạn sẽ rất biết ơn người soi — đúng vai trò cũ của bạn.
Lỗi thường gặp & mẹo
Lỗi 1 — Viết PRD quá kỹ thuật. Như chị Hương ở ví dụ 1, người từ QA hay sa đà vào chi tiết kỹ thuật vì đó là vùng an toàn. Hãy nhớ: PRD nói cái gì và tại sao, để chừa phần làm thế nào cho dev. Nếu bạn thấy mình đang ghi tên cột database, hãy lùi lại.
Lỗi 2 — Process Flow chỉ có happy path. Một flow không có nhánh thất bại là một flow chưa hoàn thiện. Mẹo: sau khi vẽ xong, đếm số hình thoi (quyết định). Nếu ít hơn hai trên một quy trình thông thường, gần như chắc chắn bạn đang bỏ sót.
Lỗi 3 — Acceptance Criteria mơ hồ. "Hệ thống phải thân thiện, nhanh, dễ dùng" là AC vô dụng vì không đo được. Mẹo từ QA: với mỗi AC, tự hỏi "tôi sẽ viết test case nào để verify nó?". Nếu không nghĩ ra test case, AC đó cần viết lại cụ thể hơn.
Lỗi 4 — Quên mục Out of scope. Không ghi rõ cái gì không làm khiến stakeholder kỳ vọng sai, dev làm thừa. Luôn có mục này.
Lỗi 5 — Flow vẽ rối, không theo quy ước. Dùng sai ký hiệu (ví dụ dùng hình chữ nhật cho điểm quyết định) khiến người đọc bối rối. Mẹo: nhất quán — bầu dục cho start/end, chữ nhật cho hành động, hình thoi cho quyết định. Mỗi mũi tên ra từ hình thoi phải có nhãn (Có/Không).
Mẹo vàng: Luôn vẽ Process Flow trước khi viết phần chữ. Hình vẽ buộc bạn nghĩ tuần tự và lộ ra lỗ hổng nhanh hơn nhiều so với viết văn xuôi. Đây là thói quen phân biệt BA chuyên nghiệp với BA mới vào nghề.
Bài tập thực hành
Hãy chọn một trong hai tình huống sau và hoàn thành sản phẩm:
Tình huống A — Đặt món trên app giao đồ ăn (kiểu ShopeeFood/GrabFood). Viết một mini-PRD (khoảng 1–2 trang) cho tính năng "Hủy đơn hàng đã đặt", kèm một Process Flow.
Tình huống B — Rút tiền tại ví điện tử (kiểu MoMo/ZaloPay). Viết mini-PRD cho tính năng "Rút tiền từ ví về tài khoản ngân hàng liên kết", kèm Process Flow.
Yêu cầu cụ thể cho sản phẩm của bạn:
- Mục tiêu: Viết 2–3 câu nêu vấn đề và mục tiêu kinh doanh (có con số giả định hợp lý).
- Scope & Out of scope: Mỗi mục ít nhất 2 gạch đầu dòng.
- Process Flow: Vẽ bằng Draw.io hoặc Lucidchart (miễn phí). Bắt buộc có ít nhất ba điểm quyết định (hình thoi), trong đó phải có ít nhất một nhánh thất bại (ví dụ: hủy đơn quá thời gian cho phép, hoặc rút tiền vượt hạn mức). Dùng swimlane với tối thiểu hai tác nhân.
- Yêu cầu chức năng: Liệt kê tối thiểu 5 yêu cầu, đánh số FR-01 trở đi.
- Acceptance Criteria: Viết AC cho ít nhất 2 yêu cầu theo dạng Given-When-Then, và đảm bảo mỗi AC đều "test được".
- Câu hỏi mở: Liệt kê ít nhất 3 câu hỏi nghiệp vụ bạn sẽ hỏi stakeholder (hãy tận dụng con mắt QA của bạn để tìm ra các tình huống biên).
Tóm tắt
PRD và Process Flow là hai sản phẩm đầu ra cốt lõi của một BA, và cũng là hai tài liệu mà người chuyển từ QA có lợi thế tự nhiên để làm tốt. Hãy nhớ ba ý chính:
- PRD trả lời "cái gì" và "tại sao", không phải "làm thế nào". Bắt đầu từ vấn đề và mục tiêu đo được, có scope rõ ràng, yêu cầu được đánh số, Acceptance Criteria test được, và đừng quên mục out-of-scope, giả định, câu hỏi mở.
- Vẽ Process Flow trước khi viết chữ. Dùng đúng quy ước ký hiệu, luôn thêm các nhánh thất bại, dùng swimlane khi có nhiều tác nhân. Hình vẽ sẽ lộ ra những lỗ hổng nghiệp vụ mà văn xuôi giấu đi.
- Biến tư duy QA thành lợi thế. Con mắt edge case, thói quen nghĩ về tính kiểm chứng, và bản năng truy vết yêu cầu — đó chính là những thứ làm PRD và Process Flow của bạn kín kẽ hơn người thường. Hãy tự tin gọi tên lợi thế này khi phỏng vấn.