Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng bạn là PM tại một công ty fintech ở TP.HCM. Một sáng thứ Hai, đội Backend gửi vào Slack một đề xuất: "Mình muốn chuyển từ REST sang gRPC cho toàn bộ giao tiếp giữa các service." Câu này nghe có vẻ chỉ là chuyện kỹ thuật, nhưng thực ra nó ảnh hưởng đến đội Mobile (phải đổi cách gọi API), đội Data (phải đổi cách tracking), đội Infra (phải dựng hạ tầng mới), và cả lộ trình sản phẩm ba quý tới của bạn. Nếu quyết định này được "chốt" trong một cuộc họp 30 phút giữa hai engineer, ba tháng sau bạn sẽ phải dọn dẹp hậu quả.
Đây chính là lý do RFC tồn tại. RFC — Request for Comments — là cơ chế để một đề xuất thay đổi lớn được viết ra rõ ràng, được nhiều người đọc và phản biện trước khi bắt tay làm, thay vì sau khi đã lỡ tay làm. Với một Technical PM, RFC không phải tài liệu của riêng engineer. Nó là một trong những công cụ quyền lực nhất bạn có để định hình các quyết định kỹ thuật quan trọng mà không cần có "quyền" ra lệnh cho bất kỳ ai. Bạn ảnh hưởng bằng lập luận viết ra giấy, công khai, có thể tranh luận.
Ở các bài trước, bạn đã học cách đọc Pull Request (Bài 11) và viết Technical Spec Document (Bài 12). RFC nằm ở một tầng cao hơn TSD: TSD mô tả làm cái gì đó như thế nào khi quyết định đã rõ; RFC dùng để quyết định có nên làm hay không, và làm theo hướng nào khi vấn đề còn nhiều lựa chọn và ảnh hưởng nhiều team. Hiểu được sự khác biệt này — và biết khi nào dùng cái nào — là dấu hiệu của một PM kỹ thuật trưởng thành.
Khái niệm cốt lõi
RFC là gì và nguồn gốc của nó
RFC viết tắt của Request for Comments — "Yêu cầu góp ý". Đây là một tài liệu đề xuất một quyết định có ảnh hưởng rộng: một thay đổi kiến trúc, lựa chọn một framework hay công nghệ mới, thay đổi một quy trình làm việc, hay đặt ra một tiêu chuẩn chung. Thuật ngữ này được mượn từ IETF (Internet Engineering Task Force) — tổ chức chuẩn hóa Internet. Mọi tiêu chuẩn nền tảng của Internet (HTTP, TCP/IP, email) đều bắt đầu dưới dạng một văn bản RFC được đánh số và công khai để cộng đồng góp ý. Tinh thần cốt lõi từ thời đó vẫn còn nguyên: không ai một mình quyết được điều ảnh hưởng đến nhiều người; hãy viết ra, mời mọi người phản biện, rồi mới chốt.
Trong các công ty công nghệ hiện đại như Google, Stripe, Uber, hay nhiều startup Việt Nam như MoMo, Tiki, VNG, RFC trở thành một phần của văn hóa kỹ thuật. Nó có thể được gọi bằng nhiều tên: RFC, Design Doc, ADR (Architecture Decision Record), hay Tech Proposal. Bản chất giống nhau: một đề xuất được viết ra để mời góp ý trước khi triển khai.
Khi nào cần một RFC
Không phải mọi thay đổi đều cần RFC — viết RFC cho mọi thứ sẽ làm tê liệt đội ngũ. Bạn cần RFC khi quyết định có một hoặc nhiều đặc điểm sau:
- Ảnh hưởng nhiều hơn một team. Ví dụ đổi định dạng dữ liệu chung giữa các service.
- Khó hoặc tốn kém để đảo ngược. Chọn cơ sở dữ liệu, chọn cloud provider, chọn ngôn ngữ cho một service mới.
- Có nhiều phương án hợp lý mà người ta sẽ tranh cãi. Khi câu trả lời không hiển nhiên, viết ra để so sánh có hệ thống.
- Tốn nhiều công sức triển khai. Nếu một thứ ngốn vài người-tháng, đáng để bỏ vài ngày suy nghĩ trước.
Cấu trúc một RFC tốt
Một RFC chất lượng thường có các phần sau. Đây không phải khuôn cứng, nhưng là bộ khung đã được kiểm chứng:
- Tiêu đề, tác giả, ngày, trạng thái (Draft / In Review / Accepted / Rejected / Superseded).
- Bối cảnh và vấn đề (Context & Problem). Vì sao chúng ta nói chuyện này lúc này? Điều gì đang đau? Đây là phần PM đóng góp giá trị nhất — gắn vấn đề kỹ thuật với tác động kinh doanh.
- Mục tiêu và phi-mục tiêu (Goals & Non-Goals). Phi-mục tiêu cực kỳ quan trọng: nó ngăn cuộc tranh luận trôi dạt sang những thứ ngoài phạm vi.
- Các phương án đã cân nhắc (Considered Options). Ít nhất 2–3 phương án, mỗi cái có ưu/nhược điểm. Một RFC chỉ có một phương án là dấu hiệu của tư duy chưa chín.
- Phương án đề xuất (Proposed Solution) và lý do. Giải thích vì sao chọn cái này thay vì các cái kia.
- Đánh đổi (Trade-offs) và rủi ro. Sự trung thực ở đây xây dựng niềm tin.
- Tác động (Impact). Lên các team khác, lên timeline, lên chi phí, lên người dùng.
- Kế hoạch triển khai và rollback. Làm theo từng bước nào, nếu hỏng thì rút lui ra sao.
- Câu hỏi mở (Open Questions). Mời người đọc giải quyết những điểm bạn còn chưa chắc.
RFC khác TSD và ADR như thế nào
Nhiều người nhầm lẫn ba thứ này. Phân biệt đơn giản:
- RFC = "Chúng ta nên làm gì, và tại sao?" — tập trung vào quyết định và thuyết phục. Sống động trong giai đoạn còn tranh luận.
- TSD = "Chúng ta làm cái đã chốt như thế nào?" — tập trung vào triển khai chi tiết. (Đã học ở Bài 12.)
- ADR = "Chúng ta đã quyết điều gì, vì sao?" — một bản ghi ngắn, lưu lại lịch sử để người sau hiểu. Thường là phần kết tinh của một RFC sau khi được chấp thuận.
Tình huống thực tế
Tình huống 1: MoMo và quyết định chuyển sang event-driven architecture
Giả định một bối cảnh sát thực tế tại một ví điện tử lớn ở Việt Nam. Đội kỹ thuật đối mặt vấn đề: mỗi khi người dùng nạp tiền thành công, có 7 hành động phải xảy ra — cộng số dư, gửi thông báo, cập nhật điểm thưởng, ghi log chống gian lận, đồng bộ với đối tác ngân hàng, gửi sự kiện cho Data, cập nhật hạn mức. Tất cả đang được gọi tuần tự trong một service. Kết quả: nếu service thông báo chậm, cả giao dịch chậm theo; mỗi lần thêm một hành động mới phải sửa vào service lõi, rủi ro cao.
Một engineer senior viết RFC đề xuất chuyển sang kiến trúc hướng sự kiện (event-driven): service lõi chỉ phát ra một sự kiện "nạp tiền thành công", các đội khác tự lắng nghe và xử lý. RFC này so sánh ba phương án: giữ nguyên (tuần tự), dùng message queue đơn giản (RabbitMQ), hay dùng nền tảng streaming (Kafka).
PM tham gia vào RFC này không phải để chọn RabbitMQ hay Kafka — đó là chuyên môn của engineer. PM đóng góp ở phần Bối cảnh và Tác động: chỉ ra rằng quý tới sản phẩm cần ra mắt tính năng "hoàn tiền tự động" và "ưu đãi theo thời gian thực", cả hai đều cần kiến trúc linh hoạt hơn. PM cũng đặt câu hỏi quan trọng trong phần Open Questions: "Trong giai đoạn chuyển đổi, nếu một sự kiện bị mất thì người dùng có bị mất tiền không, và chúng ta phát hiện bằng cách nào?" Câu hỏi này buộc RFC phải bổ sung cơ chế đảm bảo nhất quán dữ liệu.
Bài học: PM không cần là người giỏi kiến trúc nhất, nhưng là người gắn quyết định kỹ thuật với nhu cầu sản phẩm và bảo vệ trải nghiệm người dùng. Một câu hỏi đúng từ PM trong RFC đáng giá hơn mười dòng code.
Tình huống 2: Startup SaaS chọn sai vì bỏ qua RFC
Một startup B2B SaaS ở Singapore với khoảng 25 engineer cần xây hệ thống tìm kiếm cho sản phẩm. Tech Lead, vì tin tưởng kinh nghiệm cá nhân, quyết định ngay trong một cuộc họp đứng: "Dùng Elasticsearch, mình từng làm rồi." Không có RFC, không ai phản biện. Sáu tháng sau, đội phát hiện chi phí vận hành Elasticsearch đắt gấp ba dự kiến, và 80% nhu cầu thực tế chỉ cần tìm kiếm cơ bản mà PostgreSQL full-text search có thể làm với chi phí gần như bằng không.
Khi PM truy lại, không ai trả lời được vì sao chọn Elasticsearch, vì quyết định nằm trong đầu một người, không trên giấy. Việc migrate ngược lại tốn thêm hai tháng.
Sau sự cố này, đội đặt ra quy tắc: mọi quyết định liên quan đến hạ tầng chạy quá ba tháng phải có RFC tối thiểu một trang, với ít nhất hai phương án và phần ước tính chi phí. PM trở thành người "gác cổng" nhẹ nhàng — không phải để cản, mà để nhắc: "Cái này có vẻ là quyết định cửa một chiều, mình viết nhanh một RFC nhé?"
Bài học: Cái giá của việc không viết RFC thường vô hình cho đến khi quá muộn. RFC không làm chậm bạn lại; nó giúp bạn không phải làm lại. Và PM là người ở vị trí lý tưởng để nhận ra khi nào một quyết định cần được viết ra.
Tình huống 3: Dùng RFC để giải quyết bất đồng giữa hai team
Tại một công ty thương mại điện tử, đội Web và đội Mobile tranh cãi gay gắt về việc thiết kế API cho trang chi tiết sản phẩm. Đội Mobile muốn một endpoint trả về tất cả dữ liệu trong một lần gọi (tiết kiệm pin, tiết kiệm mạng cho người dùng 3G ở vùng xa). Đội Web muốn nhiều endpoint nhỏ để cache linh hoạt. Hai bên họp ba lần không ngã ngũ, không khí căng thẳng.
PM đề nghị mỗi bên viết phần lập luận của mình vào cùng một RFC, dưới mục "Considered Options". Khi viết ra, một điều thú vị xảy ra: đội Web nhận ra lý do của đội Mobile về mạng yếu là chính đáng cho thị trường Việt Nam; đội Mobile nhận ra nỗi lo cache của đội Web cũng thật. Cuối cùng RFC chốt một phương án lai (BFF — Backend for Frontend, mỗi nền tảng có một lớp API riêng tổng hợp dữ liệu phù hợp). Quyết định này có lẽ không ai nghĩ ra nếu chỉ cãi miệng.
Bài học: RFC biến tranh luận cảm tính (ai nói to hơn) thành tranh luận có cấu trúc (lập luận nào mạnh hơn). Việc viết ra buộc mỗi người trình bày lý do rõ ràng, và thường chính quá trình viết làm lộ ra giải pháp dung hòa. PM ở đây đóng vai trò người điều phối (facilitator), không phải người phán quyết.
Hướng dẫn từng bước
Đây là quy trình để bạn — với tư cách PM — khởi xướng hoặc đồng hành một RFC hiệu quả:
Bước 1 — Xác định đây có thực sự là một RFC. Hỏi: quyết định này có ảnh hưởng nhiều team không? Có khó đảo ngược không? Có nhiều phương án không? Nếu phần lớn câu trả lời là "có", hãy đề xuất viết RFC. Nếu không, một tin nhắn Slack hay một cuộc họp nhanh là đủ.
Bước 2 — Chọn người chấp bút (author). RFC thường do người hiểu kỹ thuật sâu nhất viết — có thể là engineer, có thể là bạn nếu phần kỹ thuật trong tầm. Dù ai viết, PM nên đóng góp phần Bối cảnh và Tác động kinh doanh, vì đó là vùng mạnh nhất của bạn.
Bước 3 — Viết bản nháp (Draft) gọn. Đừng cố hoàn hảo ngay. Một RFC nháp tốt nên đọc hết trong 10–15 phút. Bắt đầu bằng vấn đề, không bằng giải pháp. Luôn có ít nhất hai phương án.
Bước 4 — Đặt thời hạn góp ý rõ ràng. Ví dụ: "Mời mọi người comment trước thứ Sáu, sau đó mình sẽ chốt." Không có deadline, RFC sẽ trôi vô tận. Đây là việc PM giỏi nhất — giữ nhịp.
Bước 5 — Mời đúng người và quản lý vòng phản hồi. Tag những người bị ảnh hưởng, không tag cả công ty. Khi comment đến, phân loại: cái nào là blocker (phải giải quyết), cái nào là gợi ý (nice-to-have). Trả lời từng comment, đừng để ai cảm thấy bị bỏ qua.
Bước 6 — Tổ chức một buổi review nếu cần. Khi tranh luận trên văn bản bế tắc, một cuộc họp 30 phút với những người đã đọc trước sẽ phá vỡ thế bí. Quy tắc vàng: chỉ họp khi mọi người đã đọc RFC.
Bước 7 — Chốt quyết định và cập nhật trạng thái. Đổi trạng thái thành Accepted hoặc Rejected. Ghi rõ lý do chốt. Nếu bị từ chối, một RFC bị reject vẫn có giá trị: nó ghi lại vì sao không làm theo hướng đó, để sau này không ai đề xuất lại.
Bước 8 — Lưu trữ và liên kết. RFC đã chốt nên được lưu ở nơi tìm lại được (Confluence, GitHub, Notion). Liên kết nó tới TSD và các task triển khai. Sáu tháng sau, khi có người mới hỏi "vì sao mình làm thế này?", RFC chính là câu trả lời.
Lỗi thường gặp & mẹo
Lỗi 1 — Viết RFC khi đã quyết xong trong đầu. Đây là lỗi phổ biến và nguy hiểm nhất. Nếu bạn viết RFC chỉ để "hợp thức hóa" một quyết định đã chốt, người đọc sẽ nhận ra ngay, và họ sẽ ngừng nghiêm túc góp ý cho mọi RFC sau. RFC chỉ có giá trị khi bạn thật sự sẵn lòng đổi ý.
Lỗi 2 — Chỉ trình bày một phương án. RFC không có mục "các phương án đã cân nhắc" là một bài thuyết trình bán hàng, không phải một đề xuất. Luôn buộc mình nghĩ ra ít nhất một phương án thay thế nghiêm túc, kể cả phương án "không làm gì cả".
Lỗi 3 — Quá dài. Một RFC 30 trang sẽ không ai đọc hết. Đặt mục tiêu: người bận nhất cũng đọc xong phần cốt lõi trong 15 phút. Đẩy chi tiết kỹ thuật sâu vào phụ lục.
Lỗi 4 — Không có deadline, để RFC chết dần. Rất nhiều RFC tốt chết vì "treo" mãi ở trạng thái Draft. PM phải là người giữ nhịp: đặt deadline, nhắc nhở, và chốt.
Lỗi 5 — Bỏ qua phi-mục tiêu (Non-Goals). Thiếu phần này, cuộc thảo luận sẽ trôi dạt. Ai đó sẽ hỏi "thế còn việc X thì sao?" và bạn mất nửa buổi. Ghi rõ "RFC này KHÔNG bàn về X" để khóa phạm vi.
Mẹo 1 — Bất đồng và cam kết (disagree and commit). Không phải mọi RFC đều đạt đồng thuận tuyệt đối. Đến lúc nào đó phải có người chốt. Văn hóa lành mạnh là: ai cũng được nói, nhưng khi đã chốt thì cùng cam kết thực hiện, kể cả người không đồng ý.
Mẹo 2 — Phần Trade-offs trung thực tạo niềm tin. Một RFC thừa nhận thẳng nhược điểm của phương án mình chọn đáng tin hơn nhiều một RFC tô hồng. Engineer giỏi đánh hơi được sự né tránh.
Mẹo 3 — Dùng RFC như công cụ onboarding. Kho RFC cũ là tài liệu lịch sử quý giá. Người mới đọc RFC sẽ hiểu vì sao hệ thống thành ra như hiện tại, điều mà code không bao giờ kể được.
Bài tập thực hành
Bài 1 — Phân loại quyết định. Với mỗi tình huống sau, hãy quyết định: cần RFC, hay chỉ cần một cuộc trao đổi nhanh? Giải thích lý do. (a) Đổi tên một biến trong code. (b) Chuyển toàn bộ hệ thống từ AWS sang Google Cloud. (c) Thêm một nút màu xanh vào trang chủ. (d) Quyết định ngôn ngữ lập trình cho một microservice mới. (e) Thay đổi quy trình review code của cả phòng kỹ thuật.
Bài 2 — Viết phần Bối cảnh. Chọn một vấn đề kỹ thuật thật trong sản phẩm bạn đang làm (hoặc sản phẩm bạn dùng hằng ngày). Viết phần "Context & Problem" của một RFC dài tối đa 200 từ, gắn vấn đề kỹ thuật với một tác động kinh doanh cụ thể. Đây là phần PM đóng góp giá trị nhất.
Bài 3 — Tìm phương án thứ ba. Lấy một quyết định nhị phân quen thuộc — ví dụ "tự xây hệ thống thanh toán hay tích hợp cổng có sẵn". Liệt kê ưu/nhược của hai phương án này, rồi cố nghĩ ra một phương án thứ ba (lai, hoặc hoàn toàn khác). Bài tập này rèn thói quen không bị kẹt trong tư duy "hoặc A hoặc B".
Bài 4 — Soạn ba câu hỏi mở. Cho RFC chuyển sang event-driven architecture ở Tình huống 1, viết ba câu hỏi cho phần "Open Questions" mà một PM nên đặt ra — tập trung vào rủi ro với người dùng, timeline, và tác động lên các team khác.
Tóm tắt
RFC — Request for Comments — là cơ chế viết ra một đề xuất thay đổi lớn để mời góp ý trước khi triển khai, kế thừa tinh thần chuẩn hóa Internet từ IETF. Bạn dùng RFC cho những quyết định ảnh hưởng nhiều team, khó đảo ngược, có nhiều phương án, hoặc tốn nhiều công sức — tức các quyết định "cửa một chiều".
Một RFC tốt bắt đầu bằng vấn đề chứ không bằng giải pháp, trình bày ít nhất hai ba phương án với ưu nhược điểm, trung thực về đánh đổi, nêu rõ tác động và kế hoạch rollback, và mời mọi người phản biện thật. Nó khác TSD (cách triển khai cái đã chốt) và ADR (bản ghi quyết định lịch sử).
Với một Technical PM, RFC là công cụ ảnh hưởng mạnh nhất mà không cần quyền lực hình thức: bạn định hình quyết định bằng lập luận viết ra, công khai. Vai trò của bạn là nhận ra khi nào cần RFC, đóng góp phần bối cảnh và tác động kinh doanh, đặt những câu hỏi đúng để bảo vệ người dùng, giữ nhịp bằng deadline, và giúp đội chốt được quyết định — rồi cùng cam kết thực hiện. Như ba tình huống đã cho thấy: cái giá của việc không viết RFC luôn vô hình cho đến khi quá muộn, còn một RFC tốt biến tranh cãi cảm tính thành quyết định có cấu trúc mà cả đội tin tưởng.