P5.6 — Product Definition, PRD và hợp đồng hiểu biết với đội delivery

Module: P5 - Prioritization, Roadmap và Delivery
Mục tiêu đọc: Phân biệt Product Brief, Product Requirements Document (PRD), Product Specification, User Story, Technical Design và các lớp bằng chứng; viết yêu cầu đủ rõ để đội đưa ra quyết định; quản trị thay đổi theo rủi ro; truy vết từ vấn đề tới kết quả sau phát hành; biết quyền quyết định, đánh đổi và ranh giới leo thang.

Nguồn tổng hợp: Inspired; User Story Mapping; Shape Up; Scrum Guide 2020; ISO/IEC/IEEE 29148 Requirements Engineering.

Giới hạn năng lực: Đọc chương giúp người học hiểu mô hình và cách ra quyết định. Đọc không thay kinh nghiệm dự án. Năng lực thực tế cần va chạm với dữ liệu thiếu, bất đồng quyền hạn, lỗi phát hành, thay đổi phạm vi và hậu quả vận hành.

---

Mental model

Product Definition không phải một tài liệu. Nó là hệ thống artifact, hội thoại, quyết định và bằng chứng giúp Product, Design, Engineering, QA, Data, Security, Legal, Finance và Operations hiểu cùng vấn đề, cùng ranh giới, cùng tiêu chuẩn chất lượng.

Chuỗi định nghĩa sản phẩm cần trả lời:

• Vấn đề nào đáng giải?
• Ai gặp vấn đề và trong bối cảnh nào?
• Outcome nào chứng minh tiến bộ?
• Phạm vi đầu tư hiện tại là gì?
• Hệ thống phải hành xử ra sao?
• Chất lượng tối thiểu nào không được cắt?
• Ai có quyền quyết định từng loại vấn đề?
• Điều kiện nào cho phép bắt đầu, hoàn tất, phát hành và đánh giá?
• Khi thông tin đổi, quyết định nào phải xem lại?

Artifact tốt giảm một loại mơ hồ cụ thể. Artifact xấu lặp nội dung, khóa giải pháp quá sớm, tạo cảm giác chắc chắn giả hoặc biến hội thoại thành bàn giao.

Source mermaid — có thể chỉnh sửa

flowchart TB
    A["Product Brief: cơ hội, vấn đề, outcome"]
    B["PRD: bối cảnh, scope, yêu cầu"]
    C["Product Specification: hành vi chi tiết<br/>(trong PRD hoặc tách riêng)"]
    D["User Story: lát công việc"]
    E["Technical Design: cách xây và vận hành"]
    F["Acceptance Evidence: đáp ứng acceptance criteria<br/>và chất lượng tối thiểu"]
    G["Release Evidence: bằng chứng sẵn sàng"]
    H["Success Evidence: bằng chứng outcome"]

    A --> B
    A -->|thay đổi nhỏ| F
    B --> C
    B --> D
    C --> D
    D --> E
    D --> F
    E --> F
    E -->|Constraint làm đổi scope| B
    F --> G
    G --> H
    H -->|xem lại PRD, giả định hoặc outcome| B

Chuỗi này không tuyến tính tuyệt đối:

• Product Brief có thể đủ cho thay đổi nhỏ.
• Product Specification có thể nằm trong PRD hoặc tách riêng.
• User Story có thể xuất hiện trước khi mọi chi tiết rõ.
• Technical Design có thể làm lộ Constraint khiến Scope phải đổi.
• Success Evidence có thể tạo bằng chứng khiến PRD, giả định hoặc Outcome phải xem lại.

Mục tiêu không phải tạo nhiều trang. Mục tiêu là Shared Understanding có thể kiểm chứng.

Hợp đồng hiểu biết không phải hợp đồng giao hàng

“Hợp đồng hiểu biết” là cam kết chung về:

• Vấn đề đang giải.
• Outcome cần tạo.
• Ranh giới Scope và Non-goal.
• Hành vi bắt buộc.
• Rủi ro không được bỏ qua.
• Quyền quyết định.
• Bằng chứng cần tạo.
• Cách xử lý khi giả định sai.

Nó không phải cam kết rằng mọi chi tiết đã bất biến. Product Manager giữ bối cảnh và ranh giới sản phẩm; Engineering giữ quyền kỹ thuật; Design giữ quyền trải nghiệm; chuyên gia chức năng giữ quyền chính sách thuộc lĩnh vực; người sở hữu Outcome chịu trách nhiệm đọc kết quả.

---

Core

1. Sáu artifact, sáu công việc

Product Brief và One-Pager

Product Brief mô tả cơ hội hoặc khoản đầu tư ở mức đủ để quyết định có nên khám phá, định hình hoặc cấp nguồn lực.

One-Pager chỉ mô tả giới hạn trình bày. Nó không phải loại nội dung riêng. One-Pager có thể là Product Brief, bản tóm tắt PRD hoặc bản cập nhật quyết định.

Product Brief thường chứa:

• Problem và bằng chứng.
• Target User.
• Outcome.
• Liên kết chiến lược.
• Assumption lớn.
• Constraint chính.
• Scope sơ bộ.
• Non-goal.
• Appetite nếu tổ chức dùng cơ chế này.
• Quyết định cần đưa ra.

Dùng khi: cần quyết định có đầu tư tiếp không.
Không dùng để: mô tả đầy đủ hành vi hệ thống hoặc giao việc trực tiếp cho Engineering.

Product Requirements Document

PRD giữ bối cảnh chung của sáng kiến:

• Vì sao cần thay đổi.
• Ai bị tác động.
• Outcome.
• Scope và Non-goal.
• Requirement và Constraint.
• Decision Rights.
• Open Question.
• Success Criteria.
• Liên kết tới thiết kế, công việc, quyết định và bằng chứng.

PRD là tài liệu sống khi nhiều người cần chung Context. PRD không mặc nhiên là nguồn chính thức cho mọi thông tin. Thiết kế giao diện có thể nằm trong công cụ thiết kế; Technical Design nằm trong kho kỹ thuật; trạng thái công việc nằm trong công cụ theo dõi. PRD liên kết tới các nguồn đó, không sao chép khiến phiên bản lệch nhau.

Product Specification

Product Specification mô tả hành vi quan sát được của sản phẩm hoặc Capability cụ thể:

• Luồng chính.
• Trạng thái và chuyển trạng thái.
• Business Rule.
• Data.
• Permission.
• Validation.
• Error.
• Edge Case.
• Tương tác giữa vai trò.
• Yêu cầu chất lượng có thể kiểm chứng.

Product Specification nói hệ thống phải biểu hiện thế nào. Nó không quyết định Architecture, cấu trúc mã, giao thức nội bộ hoặc cách triển khai, trừ khi đó là Constraint đã được người có thẩm quyền xác nhận.

User Story

User Story là đơn vị hội thoại và lập kế hoạch nhỏ, mô tả giá trị hoặc hành vi từ góc nhìn người dùng hay tác nhân.

Mẫu phổ biến:

Là [vai trò], tôi muốn [hành động hoặc khả năng], để [lợi ích].

Mẫu không bắt buộc. Mẫu cũng không đủ làm đặc tả. User Story cần Context, Acceptance Criteria, liên kết thiết kế và Constraint liên quan.

User Story không nhất thiết vừa một Sprint. Nếu quá lớn, đội cắt thành lát giá trị nhỏ hơn. Scrum Guide 2020 không yêu cầu dùng User Story.

Technical Design

Technical Design mô tả cách hệ thống đáp ứng yêu cầu và vận hành an toàn:

• Architecture.
• Phân chia thành phần.
• API.
• Data Model.
• Migration.
• Failure Mode.
• Observability.
• Security Control.
• Rollback.
• Trade-off.
• Phương án bị loại và lý do.

Engineering hoặc Architect giữ quyền chuyên môn chính, tùy mô hình tổ chức. PM cung cấp Problem, Outcome, Requirement, Constraint và Trade-off sản phẩm. PM không chỉ đạo Architecture. Engineering không tự đổi Business Rule hoặc Outcome.

Bảng chọn artifact

Nhu cầu quyết định	Artifact tối thiểu	Tăng mức chi tiết khi
Chọn có đầu tư không	Product Brief hoặc One-Pager	Cược lớn, nhiều bên, bằng chứng mâu thuẫn
Giữ bối cảnh chung	PRD	Nhiều luồng, đội, ràng buộc
Mô tả hành vi phức tạp	Product Specification	Nhiều trạng thái, luật, quyền, lỗi
Lập kế hoạch lát công việc	User Story	Cần Acceptance Criteria riêng
Chọn cách xây	Technical Design	Ảnh hưởng kiến trúc, dữ liệu, bảo mật, vận hành
Chứng minh sẵn sàng phát hành	Release Evidence	Rủi ro cao, nhiều approver, yêu cầu lưu bằng chứng

Decision Rule: dùng artifact ít chi tiết nhất vẫn giúp người nhận đưa quyết định đúng. Không tạo tài liệu mới nếu trường hoặc liên kết trong nguồn hiện có đã đủ.

2. Cấu trúc PRD tối thiểu

Metadata và trạng thái

PRD cần có:

• Tên sáng kiến.
• Owner.
• Trạng thái: Draft, In Review, Approved Boundary, In Delivery, Released hoặc Archived.
• Phiên bản hoặc ngày cập nhật.
• Người phê duyệt ranh giới nếu cần.
• Liên kết tới Product Brief, thiết kế, Technical Design, công việc và bằng chứng.

Owner giữ tài liệu và điều phối cập nhật. Owner không mặc nhiên có quyền quyết định mọi nội dung.

Problem

Problem mô tả:

• Ai gặp vấn đề.
• Bối cảnh xảy ra.
• Hành vi hoặc trở ngại hiện tại.
• Hậu quả với người dùng hoặc doanh nghiệp.
• Bằng chứng và mức tin cậy.
• Điều chưa biết.

Problem tốt không chứa giải pháp ngụy trang.

Yếu: “Người dùng cần dashboard mới.”
Tốt hơn: “Người phụ trách phải ghép dữ liệu từ nhiều nguồn trước khi chọn trường hợp cần xử lý; quy trình chậm, dễ bỏ sót và khó kiểm tra.”

Outcome

Outcome mô tả thay đổi mong muốn ở hành vi, vận hành hoặc kinh doanh.

Outcome cần:

• Metric hoặc tín hiệu.
• Baseline nếu dữ liệu đủ tin cậy.
• Target chỉ khi có cơ sở.
• Khung thời gian quan sát.
• Guardrail.
• Chủ thể xác nhận dữ liệu.

Không bịa Target khi chưa có Baseline hoặc cơ sở. Khi dữ liệu yếu, Success Criteria có thể bắt đầu bằng Instrumentation đáng tin cậy.

User và actor

Ghi theo vai trò và bối cảnh, không chỉ dùng Persona:

• User trực tiếp.
• Buyer.
• Payer.
• Administrator.
• Approver.
• Subject Matter Expert.
• Người bị tác động nhưng không trực tiếp dùng.

Các vai trò khác nhau có thể cần Business Rule, Permission, thông điệp và Success Criteria khác nhau.

Scope và Non-goal

Scope định nghĩa:

• Nhóm người dùng.
• Luồng hoặc Capability.
• Kênh, nền tảng hoặc thị trường.
• Loại dữ liệu.
• Ranh giới phiên bản.

Non-goal định nghĩa phần liên quan nhưng chủ ý không làm. Mỗi Non-goal nên nêu hậu quả chấp nhận được.

Ví dụ:

• Không hỗ trợ chỉnh sửa hàng loạt trong lần phát hành này.
• Người dùng vẫn xử lý thủ công từng mục.
• Quyết định chỉ hợp lệ nếu thao tác thủ công nằm trong ngưỡng Process Owner chấp nhận.

Non-goal không được dùng để bỏ Security, Privacy, Data Integrity, Accessibility, nghĩa vụ pháp lý hoặc điều kiện vận hành bắt buộc.

Assumption

Assumption là điều được coi là đúng nhưng chưa đủ bằng chứng.

Mỗi giả định quan trọng cần có:

• Phát biểu cụ thể.
• Loại rủi ro bị ảnh hưởng.
• Bằng chứng hiện có.
• Cách kiểm tra.
• Owner.
• Hạn hoặc điểm quyết định.
• Hậu quả nếu sai.

Giả định đã xác nhận phải chuyển thành bằng chứng hoặc Constraint. Không để nó mãi trong danh sách chưa rõ.

Constraint

Constraint là giới hạn giải pháp phải tuân theo. Nguồn có thể gồm:

• Chiến lược và thương hiệu.
• Công nghệ và Architecture.
• Security.
• Privacy.
• Legal.
• Finance.
• Hợp đồng.
• Operations.
• Data.
• Thời gian hoặc năng lực đội.

Phân biệt:

• Constraint thật: luật, hợp đồng, chính sách đã duyệt, nền tảng hoặc điều kiện vận hành tạo ra.
• Preference: mong muốn có thể thương lượng.
• Assumption: điều chưa xác minh.
• Technical Decision: lựa chọn thuộc Technical Design.

PM làm rõ Constraint. Legal, Security, Finance, Engineering, Data Owner hoặc Process Owner xác nhận ràng buộc thuộc chuyên môn của họ.

Decision Rights

Quyền quyết định gắn với loại quyết định, không gắn mơ hồ với tài liệu.

Quyết định	Quyền chính	Input bắt buộc
Problem, Target User, Outcome	Product leadership hoặc PM trong phạm vi được giao	Data, Design, Engineering, Business
Scope và Non-goal	PM hoặc nhóm sản phẩm theo governance	Design, Engineering, Operations
User Experience	Product Designer	PM, Engineering, Research, Accessibility
Architecture và cách xây	Engineering hoặc Architect	Product Constraint, Security, Operations
Yêu cầu pháp lý	Legal hoặc approver được chỉ định	Product, Operations, Security
Kiểm soát an toàn thông tin	Security và Engineering	Product, Legal, Operations
Business Rule	Process Owner hoặc Business Owner	PM, BA, Legal, Operations
Định nghĩa và chất lượng dữ liệu	Data Owner hoặc Data Lead	PM, Engineering, Privacy
Kiểm chứng chất lượng	Delivery team và QA	Product, Design, Security
Release readiness	Chủ thể phát hành và vận hành	Product, QA, Security, Legal khi cần
Thành công sản phẩm	Owner của Outcome cùng Sponsor	Data, Finance, Operations

Bất đồng cần Escalation Path rõ. PM không tự phê duyệt thay Legal, Security, Finance, Data Owner, QA hoặc Engineering.

3. Viết yêu cầu kiểm chứng được

Requirement tốt cần:

• Necessary: phục vụ Problem, Outcome hoặc Constraint.
• Unambiguous: chỉ có một cách hiểu hợp lý.
• Feasible: Engineering đánh giá khả thi trong bối cảnh.
• Verifiable: có cách quan sát đúng hoặc sai.
• Consistent: không mâu thuẫn.
• Bounded: rõ đối tượng và điều kiện áp dụng.
• Traceable: nối được về nguồn và xuống bằng chứng.
• Modifiable: dễ sửa có kiểm soát.

Tránh “nhanh”, “dễ dùng”, “bảo mật”, “thân thiện”, “linh hoạt” nếu không có tiêu chí đo.

Functional Requirement

Functional Requirement mô tả hệ thống phải làm gì trong điều kiện cụ thể.

Mẫu:

Khi [điều kiện], hệ thống phải [hành vi quan sát được] cho [vai trò], với [kết quả hoặc trạng thái].

Ví dụ mô phỏng:

Khi quản trị viên gửi lời mời hợp lệ, hệ thống phải tạo lời mời ở trạng thái chờ và thông báo cho người nhận qua kênh đã cấu hình.

Yêu cầu vẫn cần Business Rule, Permission, Data, Error và Acceptance Criteria liên quan.

Non-functional Requirement

NFR mô tả thuộc tính chất lượng hoặc giới hạn vận hành:

• Performance.
• Reliability.
• Availability.
• Scalability.
• Security.
• Privacy.
• Accessibility.
• Maintainability.
• Observability.
• Recoverability.
• Compatibility.
• Data Quality.

NFR cần:

• Đối tượng đo.
• Điều kiện đo.
• Ngưỡng hoặc kỳ vọng.
• Cách kiểm chứng.
• Owner xác nhận.
• Ngoại lệ được phép.

PM không tự đặt ngưỡng kỹ thuật. Engineering, Security, Data, Operations và chuyên gia liên quan cùng xác định ngưỡng theo nhu cầu sản phẩm và năng lực hệ thống.

Business Rule

Business Rule mô tả chính sách, điều kiện hoặc phép tính hệ thống phải thực thi.

Mỗi luật cần:

• Rule ID.
• Phát biểu.
• Nguồn thẩm quyền.
• Đối tượng áp dụng.
• Ngoại lệ.
• Ngày hiệu lực nếu có.
• Process Owner hoặc Business Owner.
• Ví dụ hợp lệ và không hợp lệ.
• Liên kết Acceptance Criteria.

Không biến chính sách chưa phê duyệt thành Requirement chính thức.

Data

Phần Data cần làm rõ:

• Dữ liệu đầu vào và đầu ra.
• Nguồn dữ liệu.
• Data Owner.
• Định nghĩa nghiệp vụ.
• Kiểu, định dạng và đơn vị.
• Trường bắt buộc hoặc tùy chọn.
• Validation.
• Độ mới và chất lượng.
• Retention khi chuyên gia xác nhận.
• Auditability.
• Instrumentation cho Success Criteria.

Data Lead hoặc Data Owner xác nhận định nghĩa, chất lượng và quyền sử dụng. PM xác nhận dữ liệu cần cho hành vi và Outcome.

Permission

Permission cần mô tả:

• Actor.
• Action.
• Resource.
• Condition.
• Scope dữ liệu.
• Denied Behavior.
• Audit Requirement nếu có.

Vai trò	Xem	Tạo	Sửa	Xóa	Phê duyệt
Người dùng thường	Theo phạm vi	Theo quy tắc	Dữ liệu của mình	Theo chính sách	Không
Quản trị viên	Theo phạm vi quản trị	Theo quy tắc	Theo phạm vi quản trị	Theo chính sách	Nếu được phân quyền

Bảng trên chỉ là cấu trúc. Security, Legal, Process Owner và Engineering xác nhận chính sách thật.

Error và Edge Case

Mỗi luồng quan trọng cần xét:

• Dữ liệu thiếu, sai định dạng, trùng hoặc quá hạn.
• Người dùng mất quyền giữa luồng.
• Thao tác lặp.
• Yêu cầu sai thứ tự.
• Dịch vụ phụ thuộc không phản hồi.
• Mạng gián đoạn.
• Công việc hoàn tất một phần.
• Hai người sửa đồng thời.
• Phiên hết hạn.
• Dữ liệu đến muộn.
• Múi giờ, ngôn ngữ hoặc định dạng khác.
• Hủy, hoàn tác và khôi phục.
• Retry tạo bản ghi trùng.
• Người dùng rời luồng rồi quay lại.

Mỗi trường hợp cần quyết định:

1. Hệ thống phát hiện bằng cách nào.
2. Chặn hay tiếp tục.
3. Giữ hay hoàn tác dữ liệu.
4. Người dùng thấy thông báo gì.
5. Có thể thử lại hoặc khôi phục không.
6. Sự kiện có được ghi để hỗ trợ và điều tra không.
7. Ai xử lý nếu cần can thiệp thủ công.

Red Flag: đặc tả chỉ có Happy Path.

4. Năm lớp “đạt” không được trộn

Acceptance Criteria

Acceptance Criteria là điều kiện cụ thể xác nhận User Story, Requirement hoặc lát công việc đáp ứng hành vi thống nhất.

AC cần:

• Kiểm chứng được.
• Bao phủ luồng chính và rủi ro liên quan.
• Không lặp tiêu đề User Story.
• Không mô tả triển khai nếu không phải Constraint.
• Có ví dụ khi luật dễ hiểu sai.
• Gắn Requirement ID khi cần truy vết.

Given–When–Then phù hợp với hành vi theo tình huống:

Given tài khoản đang hoạt động và người dùng có quyền mời thành viên
When người dùng gửi địa chỉ hợp lệ chưa thuộc tài khoản
Then hệ thống tạo lời mời ở trạng thái chờ
And hiển thị trạng thái đó trong danh sách thành viên

Bảng quyết định phù hợp với nhiều luật giao nhau. Ví dụ dữ liệu phù hợp với Validation. Checklist phù hợp với yêu cầu tài liệu hoặc vận hành.

AC xác nhận hành vi của hạng mục. AC không thay DoD, Release Criteria hoặc Success Criteria.

Definition of Ready

DoR là thỏa thuận tùy chọn về điều kiện để đội nhận hạng mục vào kế hoạch gần. Scrum Guide 2020 không định nghĩa DoR.

DoR hữu ích khi kiểm tra:

• Giá trị và mục đích rõ.
• AC đủ để bắt đầu.
• Rủi ro và phụ thuộc lớn đã lộ diện.
• Đúng người có thể trả lời khi xây.
• Thiết kế hoặc dữ liệu sẵn ở mức phù hợp.
• Hạng mục đủ nhỏ hoặc có cách cắt.
• Không còn Constraint bắt buộc chưa giải quyết.

DoR không phải cổng yêu cầu mọi chi tiết đóng băng. “Ready” nghĩa đủ để bắt đầu an toàn, không nghĩa hết bất định.

Definition of Done

DoD mô tả trạng thái Increment khi đạt chuẩn chất lượng cần thiết.

Theo Scrum Guide 2020:

• Nếu tổ chức có DoD, Scrum Team tuân theo mức tối thiểu đó.
• Nếu không có, Scrum Team tạo DoD phù hợp sản phẩm.
• Nhiều Scrum Team cùng sản phẩm tuân theo DoD chung.

DoD có thể gồm:

• Code review theo chính sách kỹ thuật.
• Kiểm thử cần thiết đã chạy.
• AC đã kiểm chứng.
• Security Control đã áp dụng.
• Data Migration đã kiểm tra.
• Observability đủ dùng.
• Tài liệu vận hành hoặc hỗ trợ cập nhật.
• Không có lỗi vượt ngưỡng.
• Increment có thể phát hành.

DoD không chứng minh sản phẩm đã phát hành hoặc tạo Outcome, trừ khi tổ chức chủ ý đưa điều kiện đó vào DoD.

Release Criteria

Release Criteria xác định phiên bản có thể tới nhóm người dùng mục tiêu chưa.

Có thể gồm:

• Hạng mục bắt buộc đạt DoD.
• Rủi ro tồn dư được đúng người chấp nhận.
• Rollback hoặc Contingency Plan sẵn sàng.
• Monitoring và cảnh báo hoạt động.
• Support và Operations sẵn sàng.
• Data Migration được kiểm tra.
• Security, Legal, Privacy hoặc Finance phê duyệt khi cần.
• Tài liệu người dùng sẵn sàng.
• Feature Flag, phân nhóm hoặc kế hoạch khôi phục đã xác nhận.
• Không có Defect vượt ngưỡng.

Release Criteria áp dụng cho đợt phát hành, không nhất thiết cho từng User Story.

Success Criteria

Success Criteria xác định bằng chứng sau phát hành cho thấy khoản đầu tư tạo Outcome.

Cần có:

• Metric hoặc tín hiệu.
• Định nghĩa và nguồn dữ liệu.
• Population.
• Baseline nếu có.
• Target nếu có cơ sở.
• Khung thời gian.
• Guardrail.
• Người đọc và xác nhận kết quả.
• Quy tắc tiếp tục, điều chỉnh hoặc dừng.

Lớp	Câu hỏi
Acceptance Criteria	Hạng mục hành xử đúng chưa?
Definition of Ready	Đủ rõ và an toàn để bắt đầu chưa?
Definition of Done	Increment đạt chuẩn chất lượng chưa?
Release Criteria	Phiên bản có thể tới người dùng chưa?
Success Criteria	Outcome sau phát hành có xuất hiện chưa?

Anti-pattern: dùng “đã release” làm Success Criteria. Release chứng minh Output, không chứng minh Outcome.

5. Traceability và governance nhẹ

Traceability nối:

Strategy/Objective
  → Product Brief
  → PRD Outcome
  → Requirement
  → User Story hoặc Work Item
  → Technical Design
  → Test/Evidence
  → Release
  → Success Measurement

Traceability nhẹ không cần ma trận lớn cho mọi thay đổi. Nó cần giúp người đọc trả lời:

• Requirement đến từ vấn đề, luật hoặc Constraint nào?
• Hạng mục nào thực hiện Requirement?
• Bằng chứng nào chứng minh Requirement đáp ứng?
• Phiên bản nào chứa thay đổi?
• Metric nào đánh giá Outcome?

Dùng ID ổn định cho Requirement rủi ro cao hoặc bị chia qua nhiều hạng mục:

OUT-01   Outcome
FR-03    Functional Requirement
NFR-02   Non-functional Requirement
BR-04    Business Rule
AC-07    Acceptance Criterion
REL-02   Release Criterion

Không tạo ID cho mọi câu nếu chi phí bảo trì vượt giá trị.

Source of Truth

Loại thông tin	Nguồn chính thức
Problem, Outcome, Scope, Non-goal	Product Brief hoặc PRD
Hành vi và Business Rule	Product Specification hoặc PRD
Thiết kế trải nghiệm	Công cụ thiết kế được liên kết
Technical Design	Kho tài liệu kỹ thuật hoặc kho mã
Trạng thái công việc	Công cụ theo dõi công việc
Quyết định	Decision Log
Kết quả kiểm thử	Hệ thống kiểm thử hoặc Release Evidence
Số liệu sau phát hành	Nguồn dữ liệu được Data Owner xác nhận

Một loại thông tin có một nguồn chính. Nơi khác liên kết hoặc tóm tắt kèm nguồn.

Decision Log

Decision Log tối thiểu:

Trường	Nội dung
Decision ID	Mã ổn định
Ngày	Ngày quyết định
Bối cảnh	Vấn đề cần quyết định
Phương án	Các lựa chọn thực sự được xét
Quyết định	Lựa chọn được chấp nhận
Lý do	Bằng chứng và Trade-off
Decision Owner	Người có quyền
Người được tư vấn	Chuyên môn tham gia
Hậu quả	Chi phí, rủi ro, phần bị loại
Revisit Trigger	Điều kiện xem lại
Liên kết	PRD, thiết kế, Technical Design, Work Item

Decision Log không phải biên bản mọi cuộc họp. Ghi quyết định khó đảo ngược, gây tranh luận, ảnh hưởng nhiều bên hoặc có khả năng bị hỏi lại.

Open Question

Open Question cần có:

• Câu hỏi cụ thể.
• Vì sao quan trọng.
• Quyết định hoặc hạng mục bị chặn.
• Owner.
• Cách trả lời.
• Hạn hoặc điểm quyết định.
• Trạng thái.
• Kết luận và bằng chứng khi đóng.

Open Question không có Owner hoặc tác động quyết định là danh sách trang trí.

Change Control

Change Control bảo vệ tính toàn vẹn của cam kết. Không cần hội đồng cho mọi sửa đổi.

Loại	Ví dụ	Cách xử lý
Biên tập	Sửa câu, link, lỗi chính tả	Owner cập nhật
Làm rõ không đổi hành vi	Thêm ví dụ cho luật đã thống nhất	PM/BA cập nhật, đội liên quan xác nhận
Đổi hành vi cục bộ	Sửa AC	Đánh giá tác động, cập nhật work item và test
Đổi Scope hoặc Outcome	Thêm vai trò, luồng, mục tiêu	Người giữ quyền phạm vi phê duyệt
Đổi Constraint bắt buộc	Pháp lý, bảo mật, dữ liệu	Chuyên gia có thẩm quyền xác nhận
Đổi Technical Design	Đổi kiến trúc, migration	Engineering hoặc Architect quyết định
Đổi Release Criteria	Thêm hoặc bỏ cổng phát hành	Chủ thể release readiness và approver quyết định

Thay đổi đáng kể:

1. Ghi đề xuất và lý do.
2. Xác định artifact, requirement, test, dữ liệu, lịch và rủi ro bị ảnh hưởng.
3. Xin quyết định từ Decision Owner.
4. Ghi Decision Log.
5. Cập nhật nguồn chính thức và liên kết.
6. Thông báo nhóm bị tác động.
7. Xác nhận lại Release Criteria và cam kết.

Không yêu cầu PM và Tech Lead cùng duyệt mọi thứ. Mỗi người quyết định trong quyền của mình.

6. Mức chi tiết theo risk và reversibility

Mức đặc tả tỷ lệ với:

• Impact.
• Uncertainty.
• Reversibility.
• Blast Radius.
• Số đội và Dependency.
• Độ phức tạp Business Rule.
• Dữ liệu, tiền, an toàn, pháp lý và hợp đồng.
• Chi phí phát hiện lỗi muộn.
• Nhu cầu Audit.

Hồ sơ	Mức chi tiết phù hợp
Rủi ro thấp, cục bộ, dễ đảo ngược	Work Item ngắn, AC, liên kết thiết kế nếu cần
Rủi ro vừa, nhiều trạng thái hoặc người dùng	PRD gọn, Product Specification phần khó, Decision Log
Rủi ro cao, khó đảo ngược, nhiều đội	Bộ yêu cầu đầy đủ, Technical Design, ma trận quyền, kế hoạch dữ liệu, Release Evidence
Tiền, dữ liệu nhạy cảm, an toàn hoặc nghĩa vụ bắt buộc	Traceability chặt hơn, chuyên gia phê duyệt, kiểm thử và bằng chứng lưu giữ

Decision Rule:

• Thay đổi rẻ và dễ khôi phục: giảm tài liệu.
• Lỗi khó phát hiện hoặc hậu quả lớn: tăng rõ ràng, kiểm chứng và truy vết.
• Bất định nằm ở giá trị: tăng Discovery, không tăng đặc tả giải pháp.
• Bất định nằm ở hành vi: tăng ví dụ, trạng thái, Business Rule và AC.
• Bất định nằm ở kỹ thuật: Engineering tăng Spike hoặc Technical Design.
• Bất định nằm ở pháp lý, bảo mật, tài chính hoặc dữ liệu: đưa đúng chuyên gia vào sớm.

---

Applied

Bối cảnh mô phỏng

Một sản phẩm quản lý tài khoản doanh nghiệp cho phép Administrator mời thành viên. Support ghi nhận nhiều lời mời không hoàn tất. Dữ liệu cho thấy luồng bị bỏ dở, nhưng chưa đủ kết luận nguyên nhân.

Đội không tự đặt Target. Đội trước tiên làm rõ hành vi, rủi ro và Instrumentation.

Case 1: Có đầu tư tiếp vào luồng lời mời không?

Facts

• Administrator gửi lời mời thành viên.
• Support nhận phản ánh lời mời không hoàn tất.
• Dữ liệu hiện có cho thấy bỏ dở.
• Chưa biết nguyên nhân chính là trạng thái không rõ, liên kết hết hạn, lỗi thông báo hay sai danh tính.
• Mô hình Permission hiện tại không được phép tự đổi.

Current behavior

• Administrator không thấy trạng thái đủ rõ.
• Người nhận không có đường phục hồi rõ khi liên kết hết hạn.
• Đội chưa đo đầy đủ các bước gửi, mở, chấp nhận, hết hạn và gửi lại.
• Support xử lý thủ công khi người dùng hỏi.

Underlying need

Administrator cần biết lời mời đang ở trạng thái nào và bước xử lý tiếp theo. Người nhận cần hoàn tất lời mời hợp lệ mà không tạo truy cập sai quyền. Product cần bằng chứng để phân biệt vấn đề giá trị, khả dụng, độ tin cậy hay đo lường.

Options

1. Không thay đổi, chỉ tiếp tục xử lý thủ công.
2. Làm rõ trạng thái và bổ sung Instrumentation.
3. Thiết kế lại toàn bộ quản trị thành viên.
4. Tự động cấp quyền sau khi gửi lời mời.

Decision criteria

• Có giải quyết được nhu cầu cốt lõi không?
• Có giữ Permission và Security không?
• Có tạo bằng chứng nguyên nhân không?
• Scope có thể đảo ngược và kiểm soát không?
• Chi phí kỹ thuật, vận hành và hỗ trợ có phù hợp không?
• Có làm tăng dữ liệu trùng hoặc truy cập sai không?

Decision

Chọn Option 2: làm rõ trạng thái, tạo đường phục hồi phù hợp và bổ sung Instrumentation. Không thiết kế lại toàn bộ quản trị. Không tự động cấp quyền.

Authority

• PM quyết định Problem, Outcome, Scope và Non-goal trong ranh giới được giao.
• Process Owner quyết định Business Rule.
• Security và Engineering quyết định kiểm soát liên kết, token và Permission.
• Data Owner xác nhận định nghĩa sự kiện.
• Sponsor quyết định khoản đầu tư nếu vượt quyền PM.

Artifact

• Product Brief.
• PRD.
• Open Question Register.
• Decision Log.
• Technical Design.
• Release Evidence.
• Success Evidence.

Consequence if wrong

• Không đầu tư: Support tiếp tục chịu chi phí; nguyên nhân thật không được xử lý.
• Làm quá rộng: đội tiêu nguồn lực vào vấn đề chưa được xác nhận.
• Tự động cấp quyền: tăng rủi ro truy cập sai.
• Đo sai: đội tuyên bố thành công dựa trên dữ liệu không đáng tin.

Product Brief mô phỏng

# Product Brief: Làm rõ và phục hồi lời mời thành viên

Problem:
Administrator gửi lời mời nhưng không biết người nhận đã nhận, hết hạn
hay gặp lỗi. Người nhận thiếu đường phục hồi khi liên kết không còn hợp lệ.

Target User:
- Administrator của tài khoản.
- Người nhận lời mời.

Desired Outcome:
- Nhiều lời mời hợp lệ được hoàn tất hơn.
- Administrator giảm gửi lại thủ công.
- Không tăng truy cập sai quyền.

Evidence:
- Dữ liệu luồng cho thấy bỏ dở.
- Support có nhóm vấn đề liên quan.
- Nguyên nhân gốc chưa được xác nhận.

Scope:
- Hiển thị trạng thái lời mời.
- Gửi lại theo quy tắc.
- Phục hồi khi liên kết hết hạn.
- Ghi nhận các bước chính.

Non-goals:
- Không thiết kế lại toàn bộ quản trị thành viên.
- Không thay đổi mô hình vai trò.
- Không tự động cấp quyền trước khi người nhận chấp nhận.

Key assumptions:
- Thiếu trạng thái và phục hồi là nguyên nhân đáng kể.
- Kênh gửi hiện tại đủ tin cậy cho phạm vi đầu tiên.

Decision needed:
Có nên đầu tư tiếp vào Discovery và Delivery trong phạm vi này không?

Case 2: Chọn hành vi và quyền

Facts

• Lời mời có thể chờ, được chấp nhận, hết hạn hoặc bị hủy.
• Administrator có thể mất quyền trong lúc thao tác.
• Hai yêu cầu chấp nhận có thể đến gần đồng thời.
• Liên kết hết hạn không được tái sử dụng tùy ý.

Current behavior

• Hệ thống chưa trình bày trạng thái nhất quán.
• Chưa thống nhất ai được gửi lại hoặc hủy.
• Chưa có quy tắc rõ khi lời mời đã hết hạn.
• Chưa có bằng chứng cho xử lý lặp hoặc đồng thời.

Underlying need

Hệ thống cần biểu hiện trạng thái và quyền nhất quán để Administrator biết hành động được phép, người nhận không vượt quyền, và Engineering có ranh giới hành vi trước khi chọn cách xây.

Options

1. Chỉ hiển thị “đã gửi”.
2. Hiển thị trạng thái chi tiết và hành động theo quyền.
3. Cho mọi Administrator gửi lại và hủy.
4. Cho người nhận dùng lại liên kết cũ sau khi hết hạn.

Decision criteria

• Tính đúng của Business Rule.
• Rủi ro Security và Permission.
• Khả năng kiểm chứng.
• Khả năng phục hồi.
• Chi phí hỗ trợ.
• Tính nhất quán dữ liệu.

Decision

Chọn Option 2. Administrator chỉ xem trạng thái và thực hiện hành động khi đủ quyền và Business Rule cho phép. Liên kết hết hạn bị từ chối; đường phục hồi dùng cơ chế được Security và Engineering xác nhận.

Authority

• Process Owner giữ quyền Business Rule.
• Security giữ quyền Security Control.
• Engineering giữ quyền xử lý trạng thái, token, đồng thời và transaction.
• PM giữ Scope và Outcome.
• QA xác nhận bằng chứng kiểm thử theo AC.

Artifact

• Product Specification.
• State Model.
• Business Rule table.
• Permission matrix.
• Technical Design.
• Acceptance Criteria.
• Test Evidence.

Consequence if wrong

• Hiển thị sai trạng thái: Administrator gửi thao tác không cần thiết hoặc bỏ sót xử lý.
• Cấp quyền sai: phát sinh Security Incident.
• Cho dùng lại liên kết: người không còn đủ điều kiện có thể truy cập.
• Không xử lý đồng thời: tạo thành viên trùng hoặc trạng thái mâu thuẫn.

Product Specification mô phỏng

State Model

Draft
  → Pending
  → Accepted
  → Expired
  → Cancelled

Chuyển trạng thái:

• Draft sang Pending khi yêu cầu gửi hợp lệ.
• Pending sang Accepted khi đúng người nhận hoàn tất và còn đủ điều kiện.
• Pending sang Expired khi vượt chính sách hiệu lực.
• Pending sang Cancelled khi người có quyền hủy.
• Accepted không quay lại Pending bằng thao tác gửi lại.

Business Rules

ID	Quy tắc	Authority
BR-01	Chỉ vai trò được phân quyền mới gửi lời mời	Process Owner
BR-02	Lời mời hết hạn không được chấp nhận trực tiếp	Process Owner, Security
BR-03	Gửi lại tuân theo chính sách hiệu lực của liên kết	Security, Engineering
BR-04	Địa chỉ đã là thành viên không tạo thành viên trùng	Process Owner, Data Owner

Permission

Hành động	Administrator đủ quyền	Thành viên thường	Người nhận
Xem danh sách lời mời	Có	Không	Không
Gửi lời mời	Có	Không	Không
Gửi lại	Theo BR-03	Không	Không
Hủy	Theo chính sách	Không	Không
Chấp nhận	Không	Không	Chỉ lời mời của mình

Error và Edge Case

• Địa chỉ sai định dạng.
• Địa chỉ đã là thành viên.
• Lời mời đang chờ đã tồn tại.
• Người gửi mất quyền trước khi gửi lại.
• Liên kết hết hạn trong lúc thao tác.
• Liên kết đã được dùng.
• Hai yêu cầu chấp nhận đến gần đồng thời.
• Dịch vụ thông báo thất bại.
• Thông báo thành công nhưng lưu trạng thái thất bại.
• Người nhận đăng nhập bằng danh tính khác.
• Tài khoản bị khóa hoặc xóa khi lời mời còn chờ.

Mỗi trường hợp cần hành vi, thông báo, trạng thái dữ liệu, khả năng thử lại và người xử lý ngoại lệ.

Case 3: Viết User Story và Acceptance Criteria

Facts

• Administrator đủ quyền cần xem trạng thái.
• Người không có quyền không được thấy dữ liệu lời mời.
• Trạng thái hết hạn phải khác trạng thái đang chờ.
• Gửi lại chỉ xuất hiện khi BR-03 cho phép.

Current behavior

• Trạng thái chưa đủ rõ.
• Quyền xem chưa được thể hiện nhất quán.
• AC cũ chỉ mô tả Happy Path.

Underlying need

Delivery team cần hành vi quan sát được để xây và kiểm thử. Product cần bảo đảm AC không vô tình thay đổi Business Rule hoặc Technical Design.

Options

1. Viết một câu “hiển thị trạng thái lời mời”.
2. Viết AC theo tình huống, gồm quyền và trạng thái biên.
3. Mô tả toàn bộ API trong User Story.

Decision criteria

• Có kiểm chứng được không?
• Có bao phủ rủi ro chính không?
• Có giữ ranh giới giữa Product và Technical Design không?
• Có truy vết được tới FR và BR không?

Decision

Chọn Option 2. API và cấu trúc mã để Technical Design quyết định.

Authority

• PM cùng Design và Engineering làm rõ hành vi.
• Process Owner xác nhận Business Rule.
• Security xác nhận hành vi từ chối và không lộ dữ liệu.
• QA xác nhận khả năng kiểm thử.
• Engineering quyết định cách triển khai.

Artifact

STORY-01

Là Administrator đủ quyền,
tôi muốn xem trạng thái lời mời,
để biết bước xử lý tiếp theo.

Given tài khoản đang hoạt động và lời mời đang chờ chưa hết hạn
When Administrator đủ quyền mở danh sách lời mời
Then hệ thống hiển thị trạng thái "Đang chờ"

Given lời mời đã hết hạn
When Administrator đủ quyền mở danh sách lời mời
Then hệ thống hiển thị trạng thái "Hết hạn"
And hành động gửi lại chỉ hiển thị khi BR-03 cho phép

Given người dùng không có quyền quản trị
When người dùng truy cập danh sách lời mời
Then hệ thống từ chối truy cập theo chính sách
And không lộ dữ liệu lời mời

Story liên kết FR-01, BR-01, Permission matrix, thiết kế và Test Evidence.

Consequence if wrong

• AC quá ngắn: đội hiểu khác nhau, lỗi xuất hiện cuối chu kỳ.
• AC mô tả API: Product khóa giải pháp và cản Engineering chọn phương án tốt hơn.
• Bỏ trường hợp từ chối: hệ thống có thể lộ dữ liệu.
• Không nối BR: thay đổi chính sách không lan tới test.

Case 4: Release và Success

Facts

• Increment có thể đạt DoD nhưng chưa chắc sẵn sàng phát hành.
• Release cần Migration, Monitoring, Support và Rollback.
• Outcome chỉ đọc được sau phát hành.
• Dữ liệu đo lường chưa chắc đáng tin.

Current behavior

• Đội có xu hướng coi “QA pass” là đủ phát hành.
• Chưa thống nhất ai chấp nhận rủi ro tồn dư.
• Chưa phân biệt Completion Rate với số lời mời được gửi.
• Chưa có quy tắc khi Guardrail xấu đi.

Underlying need

Tổ chức cần quyết định Go/No-Go dựa trên rủi ro và bằng chứng; sau phát hành cần biết nên mở rộng, sửa, dừng hoặc khôi phục.

Options

1. Phát hành ngay khi tất cả story đạt DoD.
2. Phát hành sau Release Criteria và bằng chứng sẵn sàng.
3. Chờ mọi bất định biến mất.
4. Tuyên bố thành công khi tính năng đã phát hành.

Decision criteria

• Rủi ro người dùng và dữ liệu.
• Khả năng phát hiện và khôi phục.
• Mức sẵn sàng của Support và Operations.
• Chất lượng đo lường.
• Quyền chấp nhận rủi ro.
• Chi phí trì hoãn so với chi phí sai.

Decision

Chọn Option 2. Phát hành theo nhóm hoặc Feature Flag nếu Technical Design hỗ trợ. Không chờ mọi bất định biến mất. Không tuyên bố thành công khi chỉ có Output.

Authority

• Engineering xác nhận Technical Readiness và Rollback.
• Security, Legal, Privacy, Finance phê duyệt phần thuộc quyền.
• Support và Operations xác nhận khả năng xử lý.
• Release Owner đưa Go/No-Go trong governance.
• Owner của Outcome đọc Success Evidence.
• Sponsor hoặc Product leadership quyết định mở rộng nếu vượt phạm vi PM.

Artifact

Release Criteria:

• Story bắt buộc đạt DoD.
• Migration được kiểm tra.
• Security review hoàn tất khi cần.
• Support biết lỗi phổ biến.
• Dashboard giám sát hoạt động.
• Rollback được xác nhận.
• Sự kiện đo lường xuất hiện đúng.
• Rủi ro tồn dư có người chấp nhận.

Success Evidence:

• Completion Rate theo định nghĩa đã chốt.
• Tỷ lệ gửi lại.
• Tỷ lệ lỗi theo trạng thái.
• Support Contact Rate.
• Guardrail về truy cập sai quyền và bản ghi trùng.
• Chất lượng Instrumentation.

Consequence if wrong

• Phát hành thiếu Rollback: lỗi lan rộng và khôi phục chậm.
• Đo sai Completion Rate: quyết định mở rộng sai.
• Guardrail xấu đi nhưng tiếp tục mở rộng: tăng rủi ro bảo mật hoặc dữ liệu.
• Dừng vì dữ liệu lỗi: bỏ lỡ cơ hội dù Outcome chưa được đánh giá đúng.

Decision rules sau phát hành

• Dữ liệu không đáng tin: sửa đo lường trước khi kết luận.
• Outcome cải thiện và Guardrail ổn: cân nhắc mở rộng.
• Adoption thấp: kiểm tra Value Risk và Usability Risk.
• Hành vi sử dụng tốt nhưng Outcome không đổi: xem lại giả thuyết nhân quả.
• Guardrail xấu đi: dừng mở rộng, giảm Scope hoặc khôi phục theo mức nghiêm trọng.
• Không mặc định thêm Feature.

Specification Theater và Handoff Factory

Specification Theater

Specification Theater xảy ra khi tài liệu tạo cảm giác kiểm soát nhưng không cải thiện quyết định.

Dấu hiệu:

• Độ dài được dùng làm thước đo.
• Nội dung lặp trong Product Brief, PRD, ticket và slide.
• Không có người đọc hoặc quyết định mục tiêu.
• Chi tiết giải pháp vượt bằng chứng.
• Open Question không có.
• Từ mơ hồ không có tiêu chí kiểm chứng.
• Không ai biết phiên bản hiện hành.
• Requirement đổi nhưng test và release plan không đổi.
• Template đầy mục nhưng mục quan trọng chứa khẩu hiệu.

Cách chống:

• Viết cho quyết định cụ thể.
• Liên kết thay sao chép.
• Đánh dấu Known, Assumed, Decided và Open.
• Dùng ví dụ, bảng quyết định và State Model ở vùng phức tạp.
• Xóa mục không phục vụ rủi ro.
• Review bằng walkthrough.
• Kiểm tra truy vết từ Outcome tới bằng chứng.

Handoff Factory

Handoff Factory xảy ra khi mỗi chức năng hoàn tất tài liệu rồi chuyển trách nhiệm sang chức năng tiếp theo.

Dấu hiệu:

• PM viết xong mới mời Design và Engineering.
• Design hoàn tất màn hình trước khi Engineering đánh giá khả thi.
• QA chỉ thấy yêu cầu khi code xong.
• Security, Legal hoặc Operations chỉ được hỏi trước release.
• Người nhận chỉ được hỏi “khi nào”, không được hỏi “vì sao”.
• Mọi thay đổi quay về PM dù thuộc kỹ thuật hoặc thiết kế.
• Demo chỉ để xin chấp nhận bất ngờ.

Cách chống:

• Product, Design và Engineering cùng làm rõ Problem, Outcome, Scope và rủi ro.
• QA tham gia sớm ở vùng nhiều luật, trạng thái và lỗi.
• Data tham gia trước khi chốt Success Criteria.
• Security, Legal, Finance và Operations tham gia theo Constraint.
• Dùng User Story Mapping, Example Mapping hoặc walkthrough.
• Giữ quyền chuyên môn tại đúng vai trò.
• Ghi quyết định sau hội thoại; không dùng tài liệu thay hội thoại.

Quality test: người xây, kiểm thử, vận hành và đo lường có thể giải thích bằng lời của họ Problem, Outcome, ranh giới và rủi ro chính.

---

Senior Lens

1. Senior PM nhìn artifact như hệ thống quyền lực

Junior thường hỏi: “PRD cần những mục nào?”
Senior hỏi:

• Quyết định nào cần được đưa ra?
• Ai có quyền đưa quyết định?
• Bằng chứng nào đủ để quyết định?
• Nếu sai, ai chịu hậu quả?
• Quyết định có đảo ngược được không?
• Thay đổi lan tới artifact nào?
• Escalation xảy ra ở ngưỡng nào?

PRD tốt không làm PM thành người duyệt mọi thứ. PRD làm rõ nơi PM có quyền và nơi PM phải chuyển quyền.

2. Quality criteria

Correctness

• Business Rule có nguồn thẩm quyền.
• Constraint được đúng chuyên gia xác nhận.
• Requirement không mâu thuẫn.
• Technical Design không tự đổi Outcome.

Completeness theo risk

• Luồng chính, quyền, dữ liệu, lỗi và Edge Case quan trọng được bao phủ.
• Không cần mô tả mọi trường hợp tưởng tượng.
• Rủi ro cao nhận mức chi tiết cao hơn.

Clarity

• Thuật ngữ có định nghĩa.
• Không dùng từ chủ quan thiếu tiêu chí.
• Ví dụ làm rõ luật phức tạp.
• Known, Assumed và Open được tách.

Verifiability

• Requirement có AC hoặc cách xác minh.
• NFR có điều kiện đo.
• Release Criteria có bằng chứng.
• Success Criteria có nguồn dữ liệu.

Traceability

• Requirement quan trọng nối về mục tiêu hoặc Constraint.
• Test và Release Evidence nối tới Requirement.
• Phiên bản và quyết định thay đổi tìm thấy được.

Maintainability

• Không sao chép cùng nội dung.
• Source of Truth rõ.
• Owner rõ.
• Tài liệu hết hiệu lực được lưu trữ hoặc đánh dấu.

3. Trade-off khi tăng chi tiết

Tăng chi tiết tạo lợi ích	Chi phí
Giảm cách hiểu khác nhau	Tăng thời gian viết và review
Phát hiện lỗi sớm	Có thể khóa giải pháp sớm
Hỗ trợ đội phân tán	Có thể giảm hội thoại
Tạo bằng chứng kiểm toán	Tăng gánh bảo trì
Hỗ trợ onboarding	Dễ sinh bản sao lỗi thời
Làm rõ quyền và lỗi	Có thể tạo chắc chắn giả

Thêm chi tiết nơi hậu quả hiểu sai lớn. Giữ vùng dễ đảo ngược ở mức linh hoạt.

4. Red flag và phản ứng

Dấu hiệu	Chẩn đoán	Phản ứng
PRD thiếu Problem hoặc Outcome	Feature list trá hình	Viết lại vấn đề trước
Mọi thay đổi cần PRD dài	Quy trình không theo risk	Dùng artifact tối thiểu
PM quyết Architecture	Lẫn Decision Rights	Trả Technical Design cho Engineering
Engineer tự đổi Business Rule	Thiếu Process Owner	Xác nhận và ghi quyết định
Legal hoặc Security xuất hiện sát release	Constraint vào muộn	Mời chuyên gia sớm
AC chỉ có Happy Path	Rủi ro dồn cuối	Thêm quyền, lỗi, dữ liệu, phục hồi
DoR đóng băng mọi chi tiết	Cổng hành chính	Giữ điều kiện đủ để bắt đầu
DoD đổi theo story	Chuẩn chất lượng không ổn định	Tách AC khỏi DoD chung
Release Criteria chỉ là QA pass	Thiếu vận hành	Thêm Monitoring, Support, Rollback
Success Criteria là ship đúng hạn	Nhầm Output với Outcome	Định nghĩa đo sau release
Một luật nằm ở nhiều tài liệu	Source of Truth mơ hồ	Chọn nguồn chính, nơi khác liên kết
Open Question không có Owner	Danh sách trang trí	Giao Owner và hạn
PRD chỉ gửi sign-off	Handoff Factory	Walkthrough cùng đội
Tài liệu luôn Final dù sản phẩm đổi	Versioning giả	Dùng Change Log và trạng thái
Mọi Requirement cùng mức chi tiết	Không theo risk	Phân tầng theo Impact và Reversibility
Test không nối Requirement	Mất Traceability	Gắn ID cho vùng quan trọng
Release bị chặn bởi Preference cá nhân	Approver mơ hồ	Làm rõ Constraint và Decision Right

5. Khi không cần PRD

Không cần PRD riêng khi:

• Thay đổi nhỏ, cục bộ, dễ đảo ngược.
• Problem, hành vi và AC nằm gọn trong Work Item.
• Không có Business Rule, Permission, Data hoặc Dependency phức tạp.
• Không cần nhiều bên dùng chung Context.
• Lịch sử quyết định không có giá trị lớn.

Vẫn không được bỏ:

• Input Validation tại trust boundary.
• Error Handling để tránh mất dữ liệu.
• Security.
• Privacy.
• Accessibility.
• Nghĩa vụ pháp lý.
• Điều kiện vận hành.
• Measurement nếu cần đánh giá Outcome.

6. Quyền và Escalation

PM cần leo thang khi:

• Scope vượt quyền đầu tư.
• Outcome mâu thuẫn với chiến lược hoặc cam kết cấp cao.
• Constraint pháp lý, bảo mật, dữ liệu hoặc tài chính chưa có chủ thể xác nhận.
• Hai Decision Owner hợp lệ bất đồng.
• Rủi ro tồn dư vượt ngưỡng PM được phép chấp nhận.
• Technical Design làm thay đổi hành vi hoặc Outcome.
• Release Owner không có quyền chấp nhận rủi ro.
• Dữ liệu sau release không đủ tin cậy để kết luận.

Escalation tốt mang theo:

• Facts đã xác nhận.
• Current behavior.
• Underlying need.
• Options.
• Decision criteria.
• Khuyến nghị.
• Quyền quyết định cần kích hoạt.
• Consequence nếu trì hoãn hoặc chọn sai.
• Artifact cần cập nhật.

Không leo thang bằng câu “mọi người cho ý kiến”. Nêu rõ quyết định cần ai đưa và trước thời điểm nào.

7. Governance tối thiểu

1. Một Source of Truth theo loại thông tin.
2. Một Owner cho PRD.
3. Decision Rights theo loại quyết định.
4. Decision Log cho quyết định lớn.
5. Open Question Register có Owner.
6. Change Control theo tác động.
7. Traceability từ Outcome đến Release Evidence.
8. Review sau release dựa trên Success Criteria.

Không thêm Committee nếu đúng người có thể quyết định trực tiếp và quyết định được ghi lại.

---

Quick reference

Product Brief

# [Tên cơ hội]

Owner:
Status:
Decision needed:

## Problem
## Evidence
## Target user
## Desired outcome
## Strategic fit
## Scope
## Non-goals
## Assumptions
## Constraints
## Appetite, nếu dùng
## Risks
## Open questions

PRD

# [Tên sáng kiến]

Owner:
Status:
Version:
Last updated:
Approvers by decision type:
Linked artifacts:

## 1. Problem
## 2. Evidence
## 3. Outcome and guardrails
## 4. Users and affected actors
## 5. Scope
## 6. Non-goals
## 7. Assumptions
## 8. Constraints
## 9. Decision rights
## 10. User flows or scenarios
## 11. Functional requirements
## 12. Non-functional requirements
## 13. Business rules
## 14. Data
## 15. Permissions
## 16. Errors and edge cases
## 17. Acceptance criteria
## 18. Dependencies
## 19. Open questions
## 20. Release criteria
## 21. Success criteria
## 22. Decision log
## 23. Change log

Không giữ mục không phục vụ rủi ro. Ghi “không áp dụng” kèm lý do khi người đọc có thể hiểu là bỏ sót.

Decision Rules

Tình huống	Quyết định
Chỉ cần quyết định có đầu tư	Product Brief
Nhiều người cần chung bối cảnh	PRD
Nhiều trạng thái, luật, quyền	Product Specification
Cần lát công việc	User Story và AC
Cách xây có rủi ro hệ thống	Technical Design do Engineering dẫn
Bất định về giá trị cao	Discovery trước, không đặc tả sâu giải pháp
Thay đổi dễ đảo ngược	Giảm tài liệu
Tiền, dữ liệu, an toàn, pháp lý	Tăng rigor, Traceability và approval đúng quyền
Nội dung đã có nguồn chính	Liên kết, không sao chép
Requirement đổi sau khi bắt đầu	Change Control theo tác động
Increment đạt DoD nhưng chưa release	Chưa qua Release Criteria
Đã release nhưng chưa có Outcome Evidence	Chưa tuyên bố thành công

Checklist chất lượng

• [ ] Problem không phải giải pháp ngụy trang.
• [ ] Outcome tách khỏi Output.
• [ ] User, Buyer, Payer và Approver được tách khi cần.
• [ ] Scope và Non-goal có ranh giới.
• [ ] Assumption có Owner và cách kiểm tra.
• [ ] Constraint có nguồn thẩm quyền.
• [ ] Decision Rights rõ theo loại quyết định.
• [ ] Functional Requirement kiểm chứng được.
• [ ] NFR có điều kiện đo.
• [ ] Business Rule có Owner và ngoại lệ.
• [ ] Data, Permission, Error và Edge Case được bao phủ theo risk.
• [ ] AC, DoR, DoD, Release Criteria và Success Criteria không bị trộn.
• [ ] Source of Truth rõ.
• [ ] Versioning, Decision Log, Open Question và Change Control hoạt động.
• [ ] Requirement quan trọng nối tới Test Evidence và Release Evidence.
• [ ] Mức chi tiết phù hợp risk và Reversibility.
• [ ] Đội cùng tạo hiểu biết; tài liệu không thay hội thoại.
• [ ] Release Evidence nối được tới Success Evidence.

---

Thuật ngữ sử dụng trong chương

Thuật ngữ	Acronym	Giải nghĩa tiếng Việt
Product Brief	—	Bản tóm tắt cơ hội, vấn đề và khoản đầu tư
One-Pager	—	Tài liệu giới hạn trong một trang
Product Requirements Document	PRD	Tài liệu yêu cầu giữ bối cảnh, phạm vi và yêu cầu
Product Specification	—	Đặc tả hành vi chi tiết
User Story	—	Đơn vị hội thoại và lập kế hoạch từ góc nhìn người dùng
Technical Design	—	Thiết kế cách hệ thống được xây và vận hành
Artifact	—	Hiện vật công việc lưu bối cảnh, quyết định hoặc bằng chứng
Problem	—	Vấn đề cần giải quyết
Outcome	—	Thay đổi có giá trị cần tạo
Output	—	Thứ được xây hoặc phát hành
Scope	—	Phạm vi thuộc khoản đầu tư hiện tại
Non-goal	—	Phần liên quan nhưng chủ ý không làm
Assumption	—	Điều được coi là đúng nhưng chưa đủ bằng chứng
Constraint	—	Giới hạn giải pháp phải tuân theo
Decision Rights	—	Quyền quyết định theo loại vấn đề
Functional Requirement	FR	Yêu cầu về hành vi hệ thống
Non-functional Requirement	NFR	Yêu cầu về chất lượng hoặc vận hành
Business Rule	BR	Quy tắc nghiệp vụ hệ thống phải thực thi
Permission	—	Quyền thực hiện hành động trên tài nguyên
Error	—	Tình trạng luồng không hoàn tất như mong đợi
Edge Case	—	Trường hợp biên có thể xảy ra
Acceptance Criteria	AC	Điều kiện kiểm chứng hành vi
Definition of Ready	DoR	Mức đủ rõ để bắt đầu
Definition of Done	DoD	Chuẩn chất lượng của Increment
Release Criteria	—	Điều kiện cho phép phát hành
Success Criteria	—	Điều kiện chứng minh Outcome
Traceability	—	Khả năng nối mục tiêu, yêu cầu, công việc và bằng chứng
Versioning	—	Quản lý phiên bản và lịch sử thay đổi
Decision Log	—	Nhật ký quyết định và lý do
Open Question	—	Điểm chưa có câu trả lời ảnh hưởng quyết định
Change Control	—	Cơ chế đánh giá và phê duyệt thay đổi
Source of Truth	—	Nguồn chính thức của một loại thông tin
Release Evidence	—	Bằng chứng phiên bản sẵn sàng phát hành
Success Evidence	—	Bằng chứng Outcome sau phát hành
Specification Theater	—	Đặc tả tạo vẻ kiểm soát nhưng không tăng chất lượng quyết định
Handoff Factory	—	Mô hình bàn giao tuần tự làm mất bối cảnh
Reversibility	—	Khả năng đảo ngược quyết định
Guardrail	—	Chỉ số hoặc điều kiện bảo vệ khỏi tác dụng phụ
Instrumentation	—	Cơ chế ghi nhận dữ liệu sử dụng và vận hành
Observability	—	Khả năng hiểu trạng thái hệ thống qua tín hiệu
Rollback	—	Quay lại trạng thái trước thay đổi
Process Owner	—	Người có thẩm quyền với quy trình nghiệp vụ
Data Owner	—	Người có thẩm quyền với định nghĩa và quyền dùng dữ liệu
Approver	—	Người có quyền phê duyệt trong phạm vi xác định
Decision Owner	—	Người chịu quyền đưa quyết định cụ thể
Release Owner	—	Người điều phối quyết định sẵn sàng phát hành
Release Readiness	—	Mức sẵn sàng để phát hành
Test Evidence	—	Bằng chứng kiểm thử yêu cầu hoặc hành vi
Feature Flag	—	Cơ chế bật hoặc tắt tính năng theo điều kiện
Population	—	Tập đối tượng được đo lường
Baseline	—	Mức hiện tại trước thay đổi
Target	—	Mức mục tiêu có cơ sở
Data Integrity	—	Tính toàn vẹn dữ liệu
Security Control	—	Kiểm soát an toàn thông tin
Migration	—	Chuyển đổi dữ liệu hoặc hệ thống
Dependency	—	Thành phần hoặc điều kiện phụ thuộc
Blast Radius	—	Phạm vi ảnh hưởng khi thay đổi sai
Spike	—	Thử nghiệm kỹ thuật để giảm bất định
Discovery	—	Hoạt động giảm rủi ro về vấn đề, giá trị và khả năng dùng
Appetite	—	Ngân sách thời gian đáng đầu tư
Shared Understanding	—	Hiểu biết chung có thể kiểm chứng

---

Nguồn và giới hạn

Inspired

Đóng góp:

• Artifact phục vụ Outcome, không biến đội thành Feature Factory.
• Product, Design và Engineering cộng tác sớm.
• Discovery và Delivery cùng giảm rủi ro.
• PM không chiếm quyền thiết kế hoặc kỹ thuật.
• Release không đồng nghĩa thành công.

Giới hạn:

• Không cung cấp cấu trúc yêu cầu chi tiết như Requirements Engineering.
• Cần bổ sung governance chặt hơn trong ngành chịu quản lý, dữ liệu nhạy cảm hoặc hệ thống rủi ro cao.
• Các nguyên tắc cần điều chỉnh theo quyền hạn, hợp đồng, phụ thuộc và năng lực tổ chức thực tế.

User Story Mapping

Đóng góp:

• Shared Understanding được tạo qua hội thoại và mô hình trực quan.
• User Story là lời nhắc hội thoại, không phải đặc tả đầy đủ.
• Lát cắt cần giữ luồng giá trị đầu-cuối.
• Story Map giữ hành trình; backlog giữ trạng thái công việc.

Giới hạn:

• Story Map không thay PRD, Product Specification, Technical Design hoặc Release Evidence.
• Thay đổi nhỏ, cục bộ không cần workshop hoặc bản đồ lớn.
• Bản đồ không tự giải quyết quyền quyết định, Security, Legal hoặc Data Governance.

Shape Up

Đóng góp:

• Appetite, No-go và Rabbit Hole giúp quản lý khoản đầu tư.
• Mức định hình đủ tránh rủi ro lớn nhưng giữ quyền đội xây.
• Scope linh hoạt trong ranh giới Outcome, chất lượng và khoản đầu tư.

Giới hạn:

• Không phải chuẩn Requirements Engineering.
• Cần điều chỉnh theo nhịp tổ chức, Dependency, nghĩa vụ pháp lý và mức rủi ro.
• Appetite không cho phép bỏ Security, Privacy, Accessibility, Data Integrity hoặc điều kiện vận hành bắt buộc.

Scrum Guide 2020

Đóng góp:

• DoD tạo minh bạch về chất lượng Increment.
• Product Backlog Item được làm rõ liên tục.
• Scrum Team chịu trách nhiệm tạo Increment có giá trị và dùng được.

Giới hạn:

• Không quy định phải dùng PRD, User Story, AC hoặc DoR.
• DoR là thực hành tùy chọn, không phải thành phần chính thức của Scrum Guide 2020.
• Không cung cấp mẫu Product Specification hoặc Change Control.
• Scrum không tự xác định Decision Rights giữa PM, Engineering, Legal, Security và các bên khác.

ISO/IEC/IEEE 29148 Requirements Engineering

Đóng góp:

• Phân loại và thuộc tính chất lượng của Requirement.
• Nhấn mạnh tính cần thiết, rõ ràng, khả thi, kiểm chứng, nhất quán và truy vết.
• Hỗ trợ quản lý yêu cầu, thay đổi và truy vết trong vòng đời.

Giới hạn:

• Cần điều chỉnh mức nghiêm ngặt theo risk và reversibility.
• Không sao chép toàn bộ quy trình hình thức vào mọi đội hoặc mọi thay đổi.
• Chương dùng nguyên tắc tổng quát, không thay việc đọc chuẩn hoặc quy trình chuyên ngành khi có nghĩa vụ tuân thủ.
• Không có nguồn nào thay được quyết định của người có thẩm quyền trong bối cảnh cụ thể.

Kết luận vận hành

Product Brief giúp chọn khoản đầu tư. PRD giữ bối cảnh và ranh giới. Product Specification làm rõ hành vi. User Story tổ chức hội thoại và lát công việc. Technical Design xác định cách xây. Acceptance Evidence chứng minh hành vi. Release Evidence chứng minh mức sẵn sàng. Success Evidence chứng minh Outcome.

Mỗi artifact làm một việc. Mỗi quyết định có Owner. Mỗi Constraint có nguồn thẩm quyền. Mỗi thay đổi đáng kể có đánh giá tác động. Mỗi tuyên bố thành công cần bằng chứng sau phát hành.