Mở đầu — vì sao bài này quan trọng
Hãy hình dung tình huống này: team của bạn đang chuẩn bị xây một tính năng lớn — ví dụ chuyển toàn bộ hệ thống thanh toán sang một payment gateway mới. Quyết định này sẽ ảnh hưởng đến hàng chục nghìn giao dịch mỗi ngày, đụng chạm tới đội ngũ engineering, finance, customer support, và cả pháp lý. Nếu bạn viết một PRD và đưa thẳng vào sprint, gần như chắc chắn bạn sẽ gặp rắc rối: ai đó từ finance sẽ phản đối vì phí giao dịch, một senior engineer sẽ chỉ ra rằng cách tiếp cận của bạn không scale được, và bạn phải làm lại từ đầu sau khi đã tốn ba tuần.
Đây chính là khoảnh khắc mà RFC — Request for Comments — trở thành công cụ cứu mạng cho một Product Manager.
Trong dàn bài khóa học này, bạn đã học về PRD, Spec và One-pager. Đó là những tài liệu mô tả cái bạn sẽ làm. RFC khác về bản chất: nó là tài liệu để đề xuất một hướng đi và mời gọi tranh luận có cấu trúc trước khi cam kết. Nói cách khác, PRD trả lời câu hỏi "chúng ta xây cái gì", còn RFC trả lời câu hỏi "tại sao chọn cách này thay vì cách kia, và mọi người có đồng ý không".
Rất nhiều PM Việt Nam, kể cả những bạn đã có 3-4 năm kinh nghiệm, chưa từng viết một RFC đúng nghĩa. Họ hoặc là ra quyết định một mình rồi áp xuống, hoặc tổ chức vô số cuộc họp lan man không đi đến đâu. RFC là kỹ năng giúp bạn ra những quyết định lớn một cách minh bạch, có dấu vết, và quan trọng nhất — được mọi người buy-in (đồng thuận và cam kết) thật sự thay vì gật đầu cho qua. Bài học này sẽ giúp bạn hiểu khi nào cần RFC, và viết nó ra sao.
Khái niệm cốt lõi
RFC là gì
RFC (Request for Comments) là một tài liệu đề xuất một quyết định hoặc một hướng tiếp cận kỹ thuật/sản phẩm, được chia sẻ công khai trong tổ chức để thu thập phản hồi trước khi quyết định được chốt. Thuật ngữ này bắt nguồn từ cộng đồng kỹ sư internet những năm 1960 (chính các giao thức như HTTP, TCP/IP đều khởi đầu từ RFC), và ngày nay được các công ty như Stripe, Uber, Squarespace dùng rộng rãi cho cả quyết định kỹ thuật lẫn sản phẩm.
Điểm mấu chốt nằm ở chữ "Comments" — mục tiêu của RFC không phải để thông báo, mà để mời gọi phản biện. Một RFC tốt giả định rằng tác giả có thể sai, và chủ động đặt ra những câu hỏi mở để người khác đóng góp. Đây là sự khác biệt văn hóa rất lớn so với cách "sếp quyết, team làm".
Khi nào nên dùng RFC
Không phải quyết định nào cũng cần RFC — viết RFC cho mọi thứ sẽ làm tổ chức tê liệt. Bạn nên dùng RFC khi quyết định thỏa mãn ít nhất một trong các tiêu chí sau:
- Tác động lâu dài và khó đảo ngược (long-lasting, hard-to-reverse). Đây là loại quyết định mà Jeff Bezos gọi là "one-way door" — cánh cửa một chiều. Ví dụ: chọn kiến trúc hệ thống, thiết kế public API mà đối tác sẽ tích hợp, thay đổi business model, hay chọn vendor mà bạn sẽ phụ thuộc nhiều năm. Một khi đã đi qua, quay lại rất đắt.
- Cần input rõ ràng từ nhiều bên liên quan (cross-functional). Khi quyết định đụng chạm đồng thời engineering, design, legal, finance, ops... và mỗi bên có góc nhìn mà bạn không thể tự nắm hết.
- Có nhiều phương án khả thi và sự đánh đổi không hiển nhiên. Khi câu trả lời "đúng" không rõ ràng, và bạn cần làm rõ trade-off để cả team cùng cân nhắc.
- Quyết định gây tranh cãi hoặc nhạy cảm về chính trị. Khi bạn cần tạo một "biên bản" minh bạch để mọi người thấy lập luận, tránh chuyện sau này có người nói "tôi đâu có đồng ý".
RFC khác gì các tài liệu khác
Để bạn định vị rõ — và nhớ rằng các bài khác trong khóa sẽ đào sâu từng loại:
- One-pager thiên về thuyết phục, "bán" một ý tưởng ở mức cao để xin nguồn lực.
- PRD/Spec mô tả chi tiết cái sẽ xây sau khi đã chốt hướng đi.
- RFC đứng trước PRD: nó tranh luận và chốt hướng tiếp cận, đặc biệt những phần có sự đánh đổi và cần đồng thuận. Sau khi RFC được approve, bạn mới viết PRD để triển khai.
Cấu trúc một RFC điển hình
Một RFC tốt thường có các phần: tiêu đề và metadata (tác giả, ngày, trạng thái, reviewers), bối cảnh & vấn đề, các phương án đã cân nhắc kèm trade-off, đề xuất được chọn và lý do, tác động (rủi ro, chi phí, ảnh hưởng tới các team), open questions, và phần để mọi người comment. Chúng ta sẽ đi chi tiết ở mục "Hướng dẫn từng bước".
Tình huống thực tế
Ví dụ 1: Sàn TMĐT chọn lại kiến trúc tìm kiếm
Một sàn thương mại điện tử cỡ trung tại Việt Nam (giả định tên Shoppee Việt, ~2 triệu user hoạt động hàng tháng) gặp vấn đề: tính năng tìm kiếm sản phẩm chậm và cho kết quả kém liên quan, tỷ lệ tìm-kiếm-rồi-mua chỉ 4%. PM phụ trách, anh Huy, đứng trước ba lựa chọn: (1) tối ưu hệ thống search hiện tại chạy trên MySQL, (2) chuyển sang Elasticsearch tự host, hoặc (3) dùng dịch vụ search-as-a-service như Algolia.
Thay vì họp bàn lan man, Huy viết một RFC dài 4 trang. Anh nêu rõ vấn đề kèm số liệu (latency p95 là 1.8 giây, conversion 4% so với benchmark ngành 8%), liệt kê ba phương án với bảng so sánh: chi phí hàng tháng, thời gian triển khai, độ phức tạp vận hành, khả năng scale. Algolia nhanh nhất để triển khai nhưng tốn ~3.000 USD/tháng ở quy mô của họ; Elasticsearch rẻ hơn về license nhưng cần một kỹ sư dành 30% thời gian để vận hành.
Anh chia sẻ RFC cho team engineering, finance và CTO, để mở comment trong một tuần. Kết quả bất ngờ: CTO chỉ ra rằng họ sắp mở rộng sang sản phẩm thực phẩm tươi sống cần search theo vị trí địa lý — điều mà Algolia hỗ trợ tốt nhưng đội của Huy chưa hề nghĩ tới. Finance thì đàm phán được mức giá khởi nghiệp với Algolia. Quyết định cuối cùng chọn Algolia, nhưng nó tốt hơn nhiều nhờ những góc nhìn mà một mình Huy không có.
Bài học: Giá trị lớn nhất của RFC không phải là tài liệu đẹp, mà là những input bạn không ngờ tới từ người khác. Một quyết định "one-way door" như chọn search infrastructure xứng đáng có một tuần tranh luận.
Ví dụ 2: Fintech và quyết định mô hình thu phí
Một startup fintech ví điện tử (giả định tên là PayGo) cần quyết định mô hình thu phí cho tính năng chuyển tiền liên ngân hàng mới. Đây là quyết định business model — đụng chạm cả product, finance, growth và compliance. PM trẻ tên Linh ban đầu định chỉ làm một bài thuyết trình rồi xin sếp duyệt.
May mắn, manager của Linh gợi ý viết RFC. Linh đề xuất hai phương án: thu phí cố định 5.000đ/giao dịch, hoặc miễn phí hoàn toàn để cạnh tranh và bù lại bằng phí từ merchant. Trong phần "open questions", cô thẳng thắn ghi: "Tôi không chắc về tác động dòng tiền nếu chọn miễn phí — cần input từ finance."
Chính phần open questions này đã mở ra một cuộc tranh luận chất lượng. Compliance cảnh báo rằng theo quy định của Ngân hàng Nhà nước, một số loại giao dịch có ràng buộc về hiển thị phí. Finance chạy mô hình và chỉ ra rằng miễn phí sẽ khiến công ty lỗ ~800 triệu/tháng ở mục tiêu tăng trưởng năm nay — không bền vững. Cuối cùng team chọn phương án lai: miễn phí 5 giao dịch đầu mỗi tháng, sau đó thu phí.
Bài học: Khi bạn không chắc, hãy viết ra rằng bạn không chắc. Open questions không phải dấu hiệu yếu kém — nó là lời mời gọi đúng người vào đúng chỗ. Một RFC thừa nhận điểm mù sẽ tạo ra quyết định tốt hơn một bài thuyết trình tỏ ra biết tất cả.
Ví dụ 3: RFC bị dùng sai — bài học ngược
Tại một công ty SaaS B2B ở Singapore, một PM viết RFC dài 12 trang đề xuất xây lại toàn bộ dashboard. Nhưng anh ta đã âm thầm quyết định từ trước, và viết RFC chỉ để "hợp thức hóa". Khi một engineer đưa ra phản biện hợp lý về việc nên làm từng phần thay vì rebuild toàn bộ, PM phớt lờ comment đó và chốt theo ý mình. Lần sau anh ta đăng RFC, gần như không ai buồn comment nữa — vì mọi người hiểu rằng đó chỉ là hình thức.
Bài học: RFC chỉ có sức mạnh khi tác giả thật sự sẵn sàng đổi ý. Nếu bạn dùng RFC như con dấu cao su để hợp thức hóa quyết định đã rồi, bạn sẽ giết chết văn hóa phản biện và làm mất niềm tin. RFC là một lời hứa: "Tôi sẽ lắng nghe trước khi chốt."
Hướng dẫn từng bước
Đây là quy trình viết và vận hành một RFC từ đầu đến cuối.
Bước 1 — Xác định đây có thực sự cần RFC không. Tự hỏi: quyết định này có khó đảo ngược không? Có cần input cross-functional không? Có nhiều phương án với trade-off thật sự không? Nếu không có câu nào "có", hãy dùng One-pager hoặc tin nhắn — đừng lãng phí thời gian cả team.
Bước 2 — Viết phần Bối cảnh & Vấn đề. Mở đầu bằng việc giải thích tại sao chúng ta đang nói chuyện này. Người đọc bận rộn cần hiểu ngữ cảnh trong 2 phút. Nêu vấn đề kèm số liệu cụ thể, đừng nói chung chung. "Search chậm" thì yếu; "latency p95 là 1.8 giây, khiến 35% người dùng bỏ giữa chừng" thì mạnh.
Bước 3 — Liệt kê các phương án đã cân nhắc. Đây là trái tim của RFC. Trình bày ít nhất 2-3 phương án, mỗi phương án kèm ưu điểm, nhược điểm và trade-off. Bao gồm cả phương án "không làm gì" (do nothing) như một baseline. Một bảng so sánh theo các tiêu chí (chi phí, thời gian, rủi ro, khả năng mở rộng) rất hữu ích.
Bước 4 — Nêu đề xuất và lý do. Sau khi trình bày các phương án, hãy nói rõ bạn nghiêng về phương án nào và vì sao. Đừng giấu quan điểm — RFC không phải khảo sát trung lập. Bạn là người đề xuất, hãy có lập trường, nhưng để ngỏ khả năng bị thuyết phục.
Bước 5 — Mô tả tác động và rủi ro. Quyết định này ảnh hưởng team nào? Tốn bao nhiêu? Rủi ro lớn nhất là gì và bạn dự định giảm thiểu ra sao? Phần này giúp các stakeholder thấy bạn đã suy nghĩ thấu đáo.
Bước 6 — Viết Open Questions. Liệt kê thẳng thắn những điều bạn chưa chắc, những chỗ cần input cụ thể. Tag đích danh người bạn muốn nghe ý kiến: "@finance: liệu mô hình này có ảnh hưởng dòng tiền quý sau?"
Bước 7 — Chia sẻ và đặt deadline comment. Gửi RFC qua kênh phù hợp (Notion, Google Doc, Confluence) và nêu rõ thời hạn nhận comment — thường 3 đến 7 ngày. Không có deadline thì RFC sẽ trôi mãi không bao giờ được chốt.
Bước 8 — Phản hồi từng comment và cập nhật. Đây là bước nhiều người bỏ qua. Trả lời mọi comment một cách nghiêm túc — kể cả khi bạn không đồng ý, hãy giải thích lý do. Cập nhật RFC dựa trên phản hồi xác đáng. Điều này cho mọi người thấy comment của họ được tôn trọng.
Bước 9 — Chốt quyết định và đổi trạng thái. Khi hết hạn và các tranh luận chính đã được giải quyết, ghi rõ quyết định cuối cùng và đổi trạng thái RFC sang "Approved" (hoặc "Rejected"). Tài liệu này giờ trở thành "trí nhớ tổ chức" — sáu tháng sau khi ai đó hỏi "tại sao hồi đó mình chọn cái này", câu trả lời nằm ngay trong RFC.
Lỗi thường gặp & mẹo
Lỗi 1 — Chỉ trình bày một phương án. Nếu RFC chỉ có một lựa chọn, nó không phải RFC mà là một thông báo. Sức mạnh của RFC nằm ở việc so sánh trade-off. Luôn có tối thiểu hai phương án thực sự.
Lỗi 2 — Viết quá dài, quá kỹ thuật. Một RFC 15 trang sẽ không ai đọc hết. Mục tiêu là đủ chi tiết để tranh luận, không phải là một bản spec hoàn chỉnh. Nếu dài quá, hãy đưa chi tiết vào phụ lục và giữ phần chính ngắn gọn. Mẹo: viết phần TL;DR (tóm tắt 3-4 câu) ở đầu.
Lỗi 3 — Không thực sự sẵn sàng thay đổi. Như ví dụ 3, dùng RFC để hợp thức hóa quyết định đã rồi sẽ phá hủy niềm tin. Chỉ viết RFC khi bạn thật lòng muốn nghe.
Lỗi 4 — Không có deadline, không có người ra quyết định cuối. RFC cần một "decider" rõ ràng — người có quyền chốt sau khi đã nghe. Nếu không, RFC sẽ trở thành tranh luận vô tận. Mô hình tốt là phân biệt rõ ai cho ý kiến và ai ra quyết định.
Lỗi 5 — Bỏ qua phương án "không làm gì". Đôi khi quyết định đúng là chưa làm gì cả. Luôn đưa do-nothing vào để có baseline so sánh.
Mẹo quan trọng: Hãy chuẩn hóa một template RFC cho cả team và lưu tất cả RFC ở một nơi (một folder Notion hay Confluence). Theo thời gian, kho RFC trở thành tài sản quý — người mới vào đọc lại sẽ hiểu vì sao hệ thống được thiết kế như hiện tại, thay vì chỉ thấy kết quả mà không hiểu lý do.
Mẹo về văn hóa: Khuyến khích phản biện thẳng thắn nhưng tôn trọng. Một RFC chỉ toàn comment "LGTM" (looks good to me) thường là dấu hiệu mọi người chưa thực sự đọc kỹ, chứ không phải đề xuất hoàn hảo.
Bài tập thực hành
Bài tập 1 — Phân loại quyết định. Lấy 5 quyết định sản phẩm gần đây nhất bạn (hoặc team bạn) đã ra. Với mỗi cái, phân loại: đây là "one-way door" hay "two-way door"? Cái nào lẽ ra nên có một RFC? Viết một câu giải thích cho mỗi quyết định.
Bài tập 2 — Viết một RFC thật. Chọn một quyết định bạn đang phải đối mặt (hoặc một quyết định giả định về một sản phẩm bạn dùng hàng ngày, ví dụ "Grab có nên cho phép đặt nhiều điểm dừng trong một chuyến không"). Viết một RFC khoảng 1-2 trang theo đúng cấu trúc ở mục Hướng dẫn từng bước: bối cảnh, ít nhất 2 phương án kèm trade-off, đề xuất, tác động, và ít nhất 3 open questions.
Bài tập 3 — Đóng vai reviewer. Đưa RFC ở Bài tập 2 cho một đồng nghiệp (hoặc bạn cùng học) và yêu cầu họ comment thẳng thắn ít nhất 3 điểm. Sau đó, luyện kỹ năng quan trọng nhất: phản hồi từng comment và cập nhật RFC. Quan sát xem đề xuất của bạn tốt lên thế nào sau khi tiếp nhận góc nhìn khác.
Tóm tắt
RFC là công cụ giúp PM ra những quyết định lớn, khó đảo ngược và cần đồng thuận một cách minh bạch và có chất lượng. Khác với PRD (mô tả cái sẽ xây) hay One-pager (thuyết phục xin nguồn lực), RFC đứng trước chúng và tập trung vào việc tranh luận hướng đi qua các trade-off.
Hãy dùng RFC khi quyết định là "one-way door", đụng chạm nhiều bên, hoặc có nhiều phương án với đánh đổi không hiển nhiên. Một RFC tốt luôn có nhiều phương án để so sánh, một đề xuất rõ lập trường, phần tác động/rủi ro, và quan trọng nhất là open questions thẳng thắn cùng một deadline để comment. Cuối cùng, hãy phản hồi mọi góp ý và chốt quyết định rõ ràng — biến RFC thành trí nhớ tổ chức.
Nhưng nhớ cốt lõi này: RFC chỉ thực sự có sức mạnh khi bạn thật lòng sẵn sàng đổi ý. Đó không chỉ là một định dạng tài liệu — đó là một cam kết lắng nghe trước khi chốt. Khi bạn làm đúng, RFC sẽ giúp bạn ra quyết định tốt hơn, được team buy-in thật sự, và xây dựng một văn hóa product nơi ý tưởng hay thắng thế bất kể đến từ ai.