Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng bạn vừa được giao một tính năng mới: "Cho phép người dùng đặt lịch hẹn với bác sĩ qua app". Bạn gật đầu, đội kỹ thuật gật đầu, ai cũng nghĩ mình hiểu rõ. Ba tuần sau, đội dev giao ra một màn hình đặt lịch — nhưng nó không có chức năng huỷ lịch, không gửi thông báo nhắc, và sập ngay khi 50 người đặt cùng lúc. Bạn bực bội: "Sao không làm những cái đó?" Đội dev đáp lại, cũng bực không kém: "Trong tài liệu của anh có ghi đâu?"
Đây là tình huống xảy ra hàng ngày ở các công ty sản phẩm tại Việt Nam, từ startup nhỏ ở Quận 1 đến những đội lớn của Tiki hay MoMo. Nguyên nhân gốc rễ gần như luôn giống nhau: yêu cầu sản phẩm (product requirements) không được viết rõ ràng, đầy đủ và đúng cách.
Là một Product Manager, công cụ quan trọng nhất của bạn không phải là Figma hay Jira — mà là khả năng diễn đạt chính xác sản phẩm cần làm được gì và làm tốt đến mức nào. Yêu cầu sản phẩm chính là cây cầu ngôn ngữ nối ý tưởng kinh doanh với dòng code thực thi. Cầu xây ẩu thì sản phẩm sập. Bài học này sẽ dạy bạn nền tảng của việc viết yêu cầu: phân biệt hai loại yêu cầu cốt lõi (functional và non-functional), và cách diễn đạt chúng sao cho đội ngũ không thể hiểu nhầm.
Khái niệm cốt lõi
Requirement là gì?
Một requirement (yêu cầu) là một phát biểu mô tả điều gì đó mà sản phẩm phải làm được, hoặc một ràng buộc mà sản phẩm phải tuân theo. Nó không phải là ý tưởng mơ hồ ("app phải tiện lợi"), cũng không phải là giải pháp kỹ thuật chi tiết ("dùng Redis để cache"). Một requirement tốt nằm ở giữa: đủ cụ thể để đội ngũ biết phải xây gì, nhưng đủ mở để không tự trói tay cách triển khai.
Trong thực tế, requirement được chia làm hai nhóm lớn, và việc phân biệt được chúng là dấu hiệu đầu tiên của một PM trưởng thành.
Functional requirements — Sản phẩm LÀM GÌ
Functional requirement trả lời câu hỏi: Sản phẩm cần làm được những gì? Đây là các hành vi, chức năng, tính năng mà hệ thống phải thực hiện. Nó mô tả input vào, hệ thống xử lý ra sao, và output đi đâu.
Ví dụ với tính năng đặt lịch khám:
- Người dùng có thể chọn bác sĩ theo chuyên khoa.
- Người dùng có thể chọn khung giờ còn trống.
- Hệ thống gửi email và thông báo đẩy xác nhận sau khi đặt thành công.
- Người dùng có thể huỷ lịch trước giờ hẹn ít nhất 2 tiếng.
Non-functional requirements — Sản phẩm làm tốt ĐẾN MỨC NÀO
Đây là phần mà 80% PM mới vào nghề bỏ quên, và cũng là nơi gây ra phần lớn các thảm hoạ. Non-functional requirement (NFR) trả lời câu hỏi: Sản phẩm phải làm tốt đến mức nào? Nó không nói về chức năng mới, mà nói về chất lượng của các chức năng đó. Các nhóm NFR quan trọng:
- Performance (Hiệu năng): Tốc độ tải, thời gian phản hồi, khả năng chịu tải. Ví dụ: "Trang kết quả tìm bác sĩ phải tải trong dưới 2 giây", "Hệ thống chịu được 500 lượt đặt lịch đồng thời mà không lỗi".
- Security (Bảo mật): Bảo vệ dữ liệu, phân quyền, mã hoá. Ví dụ: "Thông tin bệnh án phải được mã hoá khi lưu trữ và truyền tải", "Chỉ bác sĩ được gán mới xem được hồ sơ bệnh nhân".
- Accessibility (Khả năng tiếp cận): Sản phẩm dùng được với người khuyết tật. Ví dụ: "Tất cả nút bấm phải đọc được bằng trình đọc màn hình", "Độ tương phản màu chữ tối thiểu đạt chuẩn WCAG AA".
- Reliability & Availability (Độ tin cậy): Ví dụ: "Hệ thống đạt uptime 99,9%", "Khi mất mạng, app vẫn lưu nháp đơn đặt lịch".
- Scalability, Usability, Compatibility: Khả năng mở rộng, tính dễ dùng, tương thích thiết bị/trình duyệt.
Đặc tính của một requirement tốt
Dù là loại nào, một requirement chất lượng cần đạt vài tiêu chí (người trong ngành hay gọi tắt là tiêu chí "INVEST" hoặc "SMART" cho từng phần). Quan trọng nhất với người mới:
- Cụ thể và đo được: "Nhanh" là vô nghĩa; "dưới 2 giây ở mạng 4G" mới dùng được.
- Không mơ hồ: Mỗi người đọc phải hiểu giống nhau.
- Khả thi và có thể kiểm chứng: Phải có cách để QA xác nhận nó đạt hay không.
- Tập trung vào "cái gì", không phải "làm như thế nào": Để chừa không gian cho đội kỹ thuật chọn giải pháp tối ưu.
Tình huống thực tế
Ví dụ 1 — MoMo và requirement bảo mật bị xem nhẹ (giả định hợp lý)
Một đội sản phẩm fintech tại Việt Nam (lấy bối cảnh giống MoMo) xây tính năng "Chuyển tiền cho người gần đây". Functional requirement được viết rất kỹ: hiển thị 5 người chuyển gần nhất, cho phép chọn nhanh, nhập số tiền, xác nhận. Tất cả đều hoạt động mượt khi demo.
Vấn đề: đội PM quên hẳn non-functional requirement về bảo mật. Khi lên production, danh sách "người gần đây" được cache ở client và không bị xoá khi đăng xuất. Một người dùng mượn điện thoại bạn để đăng nhập ví của mình, đăng xuất xong, người chủ máy vẫn thấy được danh sách người mà bạn từng chuyển tiền — lộ thông tin riêng tư. Đội phải hotfix khẩn cấp trong đêm.
Bài học: Functional đúng nhưng thiếu NFR về security/privacy có thể gây hậu quả nghiêm trọng hơn cả việc thiếu tính năng. Với mỗi tính năng đụng đến dữ liệu nhạy cảm, hãy luôn hỏi: "Dữ liệu này được lưu ở đâu, xoá khi nào, ai được xem?"
Ví dụ 2 — Tiki và requirement hiệu năng trong ngày sale (bối cảnh Đông Nam Á)
Một sàn thương mại điện tử như Tiki tổ chức flash sale 12/12. Đội PM viết functional requirement cho trang flash sale rất đầy đủ: đếm ngược thời gian, hiển thị số lượng còn lại, nút "Mua ngay". Nhưng requirement non-functional về tải hệ thống chỉ ghi chung chung: "trang phải tải nhanh".
Đến 0h ngày sale, hàng trăm nghìn người vào cùng lúc. "Nhanh" không có con số nên đội backend chỉ chuẩn bị cho lượng tải gấp 3 ngày thường — thực tế cao gấp 40 lần. Trang treo, người dùng bấm "Mua ngay" mà không có phản hồi, tồn kho bị bán âm vì hệ thống xử lý trùng đơn.
So sánh với cách viết đúng: NFR lẽ ra phải là "Trang flash sale chịu được 100.000 người dùng đồng thời với thời gian phản hồi p95 dưới 1,5 giây; hệ thống khoá tồn kho phải đảm bảo không bán quá số lượng dù có 5.000 lượt bấm mua/giây cho cùng một sản phẩm." Có con số thì đội kỹ thuật mới biết phải chuẩn bị hạ tầng đến đâu.
Bài học: Trong các sự kiện tải cao, NFR về performance và data integrity (toàn vẹn dữ liệu) quan trọng ngang functional. "Nhanh" phải được lượng hoá bằng con số cụ thể (số người đồng thời, thời gian phản hồi p95/p99).
Ví dụ 3 — Startup giáo dục và requirement về accessibility bị bỏ qua
Một startup edtech ở Hà Nội làm app học tiếng Anh cho trẻ em, nhắm cả nhóm trẻ khiếm thị. Functional requirement đầy đủ: bài học, quiz, huy hiệu, bảng xếp hạng. Nhưng vì áp lực ra mắt nhanh, đội bỏ qua mọi NFR về accessibility.
Kết quả: khi một trường khiếm thị muốn mua bản quyền cho 200 học sinh — một hợp đồng B2B lớn — họ thử app bằng trình đọc màn hình và phát hiện các nút không có nhãn, hình ảnh không có mô tả thay thế. Trẻ khiếm thị hoàn toàn không dùng được. Hợp đồng đổ bể, và đội phải làm lại UI gần như từ đầu để bổ sung nhãn accessibility — tốn gấp 3 lần so với nếu đưa NFR vào ngay từ đầu.
Bài học: NFR như accessibility không chỉ là "điều tốt nên có" — nó có thể là điều kiện sống còn để mở một thị trường. Đưa NFR vào sớm rẻ hơn nhiều so với vá sau.
Hướng dẫn từng bước
Đây là quy trình bạn có thể áp dụng ngay khi nhận một tính năng mới để viết requirement:
Bước 1 — Xác định mục tiêu và người dùng. Trước khi viết gì, trả lời: Tính năng này phục vụ ai và giải quyết vấn đề gì? Một câu mục tiêu rõ ràng làm kim chỉ nam cho mọi requirement phía sau.
Bước 2 — Liệt kê functional requirements dưới dạng User Story. Với mỗi việc người dùng cần làm, viết: "Là [vai trò], tôi muốn [hành động] để [lợi ích]." Liệt kê cả luồng chính (happy path) lẫn các trường hợp ngoại lệ: lỗi mạng, dữ liệu trống, người dùng bấm hai lần, huỷ giữa chừng.
Bước 3 — Viết Acceptance Criteria cho từng story. Dùng cấu trúc Given–When–Then (Cho trước – Khi – Thì): "Cho trước người dùng đã đặt lịch, khi họ bấm Huỷ trước giờ hẹn 2 tiếng, thì lịch được huỷ và họ nhận thông báo xác nhận." Đây là thước đo để biết tính năng đã "xong".
Bước 4 — Bổ sung non-functional requirements. Đi qua checklist NFR như một thói quen cho mọi tính năng: Performance (cần nhanh đến đâu, chịu tải bao nhiêu?), Security (dữ liệu nào nhạy cảm, ai được truy cập?), Accessibility (người khuyết tật dùng được không?), Reliability (lỗi thì xử lý sao?), Compatibility (chạy trên thiết bị/trình duyệt nào?). Lượng hoá bằng con số mỗi khi có thể.
Bước 5 — Rà soát với đội kỹ thuật và thiết kế. Đưa bản nháp cho dev và designer đọc trước. Họ sẽ chỉ ra những chỗ mơ hồ, bất khả thi, hoặc những trường hợp bạn chưa nghĩ tới. Requirement là tài liệu sống — nó được làm rõ qua đối thoại, không phải ném qua tường.
Bước 6 — Đánh độ ưu tiên. Không phải requirement nào cũng "must have". Phân loại bằng MoSCoW (Must / Should / Could / Won't) để biết cái gì làm trước, cái gì để sau.
Lỗi thường gặp & mẹo
Lỗi 1 — Chỉ viết functional, quên non-functional. Đây là lỗi phổ biến nhất. Mẹo: gắn một checklist NFR vào template viết requirement của bạn, buộc bản thân điền (hoặc ghi rõ "không áp dụng") cho từng mục.
Lỗi 2 — Viết mơ hồ, dùng tính từ không đo được. "Nhanh", "thân thiện", "an toàn", "nhiều" — đều vô nghĩa với người triển khai. Mẹo: cứ thấy một tính từ, hãy hỏi "bao nhiêu? đo bằng cách nào?" và thay bằng con số.
Lỗi 3 — Lẫn lộn requirement với giải pháp. Viết "dùng PostgreSQL để lưu lịch hẹn" là bạn đang chỉ định giải pháp, không phải yêu cầu. Hãy viết "lịch hẹn phải được lưu bền vững và truy vấn được theo bác sĩ và theo ngày" — để đội kỹ thuật chọn công nghệ.
Lỗi 4 — Quên các trường hợp biên (edge cases). Đa số bug đến từ những tình huống không ai viết ra: mạng rớt giữa chừng, người dùng nhập emoji vào ô tên, hai người đặt cùng một khung giờ. Mẹo: với mỗi happy path, ép mình nghĩ ra ít nhất hai trường hợp "điều gì xảy ra nếu...".
Lỗi 5 — Viết quá dài, không ai đọc. Một tài liệu 40 trang sẽ bị bỏ qua. Mẹo: ưu tiên rõ ràng hơn đầy đủ; dùng bảng, gạch đầu dòng, ví dụ minh hoạ thay vì văn xuôi dài dòng.
Mẹo vàng: Trước khi gửi requirement đi, đọc lại và tự hỏi: "Nếu một dev hoàn toàn không nói chuyện với mình đọc tài liệu này, họ có xây ra đúng thứ mình muốn không?" Nếu câu trả lời không chắc chắn, requirement của bạn chưa đủ rõ.
Bài tập thực hành
Hãy chọn một trong hai tính năng sau (hoặc một tính năng từ chính sản phẩm bạn đang làm):
- Tính năng "Đặt bàn nhà hàng qua app giao đồ ăn" (kiểu ShopeeFood/GrabFood).
- Tính năng "Gửi tin nhắn cho người bán" trên một sàn TMĐT.
- Một câu mục tiêu mô tả tính năng phục vụ ai và giải quyết vấn đề gì.
- Ít nhất 4 functional requirements dưới dạng User Story, kèm Acceptance Criteria theo cấu trúc Given–When–Then cho ít nhất 2 trong số đó. Nhớ bao gồm ít nhất một trường hợp lỗi (ví dụ: bàn vừa hết chỗ, người bán không online).
- Ít nhất 4 non-functional requirements, mỗi cái thuộc một nhóm khác nhau (performance, security, accessibility, reliability...). Bắt buộc mỗi NFR phải có con số cụ thể đo được.
- Một bảng độ ưu tiên MoSCoW xếp các requirement trên thành Must/Should/Could/Won't.
Tóm tắt
- Requirement là phát biểu mô tả sản phẩm phải làm gì hoặc phải tuân theo ràng buộc nào — nằm giữa ý tưởng mơ hồ và giải pháp kỹ thuật chi tiết.
- Có hai loại cốt lõi: Functional (sản phẩm làm gì — các chức năng, hành vi) và Non-functional (sản phẩm làm tốt đến mức nào — performance, security, accessibility, reliability...).
- PM mới hay viết kỹ functional nhưng quên non-functional, và chính NFR bị bỏ quên thường gây ra những thảm hoạ lớn nhất: lộ dữ liệu, sập trang ngày sale, mất hợp đồng vì không tiếp cận được người dùng.
- Một requirement tốt phải cụ thể, đo được, không mơ hồ, kiểm chứng được, và tập trung vào "cái gì" chứ không phải "làm thế nào".
- Quy trình: xác định mục tiêu → viết User Story (functional) → Acceptance Criteria (Given–When–Then) → bổ sung NFR có con số → rà soát cùng đội kỹ thuật → đánh ưu tiên MoSCoW.
- Câu thần chú để kiểm tra cuối cùng: "Một dev không nói chuyện với mình đọc tài liệu này có xây đúng thứ mình muốn không?"