Quy trình đề xuất và duyệt thay đổi (RFC) là gì

Chốt nhanh

RFC (Request for Comment, đề xuất thay đổi) là tài liệu ngắn mô tả vấn đề, giải pháp đề xuất, tác động và câu hỏi cần giải đáp trước khi một thay đổi lớn được triển khai. Anh / Chị cần RFC khi thay đổi ảnh hưởng nhiều đội, phá vỡ API hiện tại, hoặc là quyết định khó đảo ngược. Với đội nhỏ hoặc thay đổi nhỏ, dùng RFC là thừa và sẽ làm chậm cả hệ thống.

RFC không phải thủ tục hành chính. Đây là công cụ giúp một đội tránh những quyết định mà sau này phải trả giá để tháo gỡ. Vấn đề không phải là có dùng RFC hay không mà là biết áp dụng đúng lúc: dùng sai ngữ cảnh sẽ làm chậm cả tổ chức; bỏ qua khi thật sự cần sẽ để lại nợ kỹ thuật và mâu thuẫn nội bộ kéo dài.

RFC là gì, cấu trúc ra sao

RFC (Request for Comment, đề xuất thay đổi) là một tài liệu ngắn, thường gồm sáu phần: vấn đề đang gặp phải, giải pháp đề xuất, các lựa chọn thay thế đã cân nhắc, tác động với người dùng hiện tại, kế hoạch chuyển đổi (migration), và câu hỏi mở cần giải đáp trước khi quyết định. Mục đích không phải là mô tả đầy đủ thiết kế kỹ thuật mà là tạo cơ hội để các bên liên quan nhìn thấy vấn đề và phản hồi trước khi thay đổi được triển khai.

Các design system lớn như Primer (GitHub), Carbon (IBM), Material Design (Google) đều có quy trình RFC công khai với cấu trúc tương tự. Điểm chung là: ngắn gọn, có deadline phản hồi rõ ràng, và có một người chịu trách nhiệm ra quyết định cuối.

Khi nào cần RFC, khi nào không

Cần RFC đầy đủ khi thay đổi là quyết định một chiều (one-way door decision, tức quyết định khó hoặc tốn kém để đảo ngược): thay đổi token màu cốt lõi ảnh hưởng toàn hệ thống, đổi tên API component đang được nhiều đội dùng, thêm peer dependency mới, hoặc thay đổi hành vi mặc định của component quan trọng.

Không cần RFC khi thay đổi là quyết định hai chiều (two-way door decision, tức có thể điều chỉnh sau dễ dàng): thêm variant mới vào component có sẵn, sửa bug không thay đổi API, cập nhật tài liệu, hoặc thay đổi nội bộ không lộ ra ngoài. Với những trường hợp này, hành động và điều chỉnh sau nhanh hơn là viết RFC dài.

Khung phân biệt một chiều và hai chiều này xuất phát từ cách Jeff Bezos mô tả quyết định tại Amazon: không phải mọi quyết định đều cần cùng mức độ cẩn trọng. Áp dụng sai chiều là lãng phí hoặc mạo hiểm.

Đội nhỏ: lightweight RFC là đủ

Với đội dưới mười người dùng một stack duy nhất, RFC đầy đủ thường không cần thiết trong hai năm đầu. Sinh Vũ thường tư vấn khách dùng lightweight RFC (RFC rút gọn) dạng GitHub Issue template hoặc Notion page ngắn gồm ba phần: thay đổi là gì, tại sao cần, ai bị ảnh hưởng. Không cần nhiều hơn thế ở giai đoạn này.

Điều quan trọng hơn biểu mẫu là hai thói quen: chỉ định một người ra quyết định cuối, và ghi lại lý do quyết định trong changelog. Thiếu hai điều này, dù dùng RFC hay không, đội vẫn sẽ tranh luận lại những vấn đề cũ mỗi khi thành viên thay đổi.

Lỗi phổ biến khi triển khai RFC

Áp RFC cho mọi thay đổi: quy trình trở nên nặng nề, các đội bắt đầu bỏ qua hệ thống theo thói quen.
RFC quá dài hoặc quá kỹ thuật: ít người đọc hết, phản hồi ít, thay đổi vẫn đi theo ý người đề xuất ban đầu và quy trình chỉ là hình thức.
Không đặt deadline phản hồi: RFC treo lơ lửng vô thời hạn, không ai chịu trách nhiệm kết thúc.
Không có DRI (directly responsible individual, người chịu trách nhiệm trực tiếp): RFC kết thúc bằng sự đồng thuận mờ nhạt, không ai rõ quyết định là gì và vì sao.

Góc nhìn của Sinh Vũ

Quy trình duyệt thay đổi tốt nhất là quy trình đội thật sự dùng, không phải quy trình hoàn hảo nhất trên giấy. Bắt đầu từ đơn giản nhất có thể vận hành được, rồi thêm độ phức tạp khi thật sự cần.
Kinh nghiệm thực hành của Sinh Vũ

Trong thực tế tư vấn, Sinh Vũ thấy nhiều đội bỏ qua RFC vì nghĩ mình còn nhỏ, đến khi design system lớn lên thì đang gánh hàng chục quyết định không có lý do ghi lại và không ai nhớ tại sao làm vậy. Ngược lại, cũng có đội áp RFC quá sớm và quá nặng, làm mọi sự chậm lại đến mức đội product ngừng dùng design system vì "quá khó đóng góp".

Điểm cân bằng không phải là một con số cố định. Nó phụ thuộc vào số đội dùng hệ thống, mức độ ổn định của API, và năng lực thật sự của đội trong việc đọc và phản hồi tài liệu. Bắt đầu nhẹ, quan sát xem loại vấn đề nào xuất hiện lặp lại, rồi thêm cấu trúc đúng chỗ cần.

Nguồn tham khảo

Amazon One-Way Door vs Two-Way Door, Jeff Bezos. GitHub Primer Design System RFC process (công bố công khai). IBM Carbon Design System contribution process (công bố công khai). Kinh nghiệm thực hành của Sinh Vũ khi tư vấn thiết lập design system cho khách.

Câu hỏi thường gặp

RFC phải dài bao nhiêu mới đủ?

Không có con số cố định. Độ dài lý tưởng là đủ để người đọc hiểu vấn đề và phản hồi có ích, không phải tài liệu thiết kế đầy đủ. Thực tế, một RFC hiệu quả thường ngắn hơn nhiều so với người viết nghĩ. Nếu RFC dài đến mức ít ai đọc hết, chính sách duyệt thay đổi sẽ bị bỏ qua theo thói quen.

Đội chỉ có năm người có cần RFC không?

Thường không cần RFC đầy đủ. Với đội nhỏ dưới mười người dùng một stack duy nhất, Sinh Vũ khuyên dùng lightweight RFC dạng GitHub Issue hoặc Notion page ngắn mô tả thay đổi và lý do. Quan trọng hơn cả biểu mẫu là có một người được chỉ định ra quyết định cuối và ghi lại lý do trong changelog.

Nếu không ai phản hồi RFC thì sao?

Đây là dấu hiệu RFC quá dài, quá kỹ thuật, hoặc đội chưa có thói quen đọc. Cần đặt deadline phản hồi cụ thể, ví dụ một đến hai tuần, và người đề xuất chủ động ping trực tiếp những người bị ảnh hưởng nhiều nhất. Sau deadline, DRI (directly responsible individual, người chịu trách nhiệm trực tiếp) ra quyết định có ghi lý do, dù ít hay nhiều ý kiến.