RFC trong design system: khi nào cần quy trình duyệt

RFC (Request for Comments, quy trình đề xuất và lấy ý kiến) không phải thủ tục hành chính. Đây là cơ chế để một thay đổi quan trọng được nêu rõ, bàn có căn cứ và duyệt có trách nhiệm, trước khi ảnh hưởng tới toàn bộ những ai đang dùng hệ thống. Câu hỏi không phải "có nên làm RFC không?" mà là "thay đổi này lớn cỡ nào và bao nhiêu bên bị ảnh hưởng?"

RFC là gì trong thực tế

Mô hình RFC phổ biến trong lập trình nguồn mở, được cộng đồng Rust và Ember áp dụng cho việc thêm tính năng lớn vào ngôn ngữ và framework. Nathan Curtis đề xuất design system học theo cách tiếp cận này: bàn sơ bộ trước, rồi đề xuất chính thức có mô tả, lý do và phạm vi, cuối cùng mới làm và duyệt bản hoàn chỉnh.

Trong bối cảnh design system, RFC thường gồm ba bước cơ bản:

• Đề xuất: người muốn thay đổi viết mô tả, lý do và phạm vi ảnh hưởng.
• Bàn: đội lõi và các bên liên quan cho ý kiến, đặt câu hỏi, phát hiện rủi ro.
• Duyệt: người có thẩm quyền chốt chấp nhận, điều chỉnh hoặc từ chối, có ghi lại lý do.

Độ nặng của từng bước tùy quy mô thay đổi và số đội cùng dùng hệ thống.

Các yếu tố quyết định mức quy trình

Không có một khuôn duy nhất đúng cho mọi trường hợp. Anh / Chị cần cân theo bốn yếu tố:

• Quy mô thay đổi: thêm một icon khác hẳn đổi cả thang màu biểu đồ hay điều chỉnh giao diện lập trình (API) của một component dùng chung. Mỗi loại cần mức kiểm soát khác nhau.
• Ai đề xuất: người trong đội lõi quen nguyên tắc hệ thống khác với đội sản phẩm ngoài lần đầu đóng góp.
• Độ rủi ro phá vỡ: thay đổi có gây lỗi ở các nơi đang dùng component đó không, hay an toàn hoàn toàn.
• Độ minh bạch cần thiết: mọi người có cần thấy đề xuất, lý do và quyết định không, hay chỉ đội lõi cần biết.

Khi nào cần RFC đầy đủ, khi nào duyệt nhanh là đủ

Brad Frost nhấn mạnh rằng cần một quy trình quản trị công khai để cân bằng giữa mở cho đóng góp và giữ chuẩn chung. Công khai ở đây không có nghĩa là phức tạp, mà nghĩa là ai cũng biết đề xuất đang ở đâu, ai quyết định và vì sao.

Lỗi thường gặp khi thiết kế quy trình

• Áp một quy trình nặng cho mọi thay đổi: việc nhỏ bị nghẽn, đội mất động lực đóng góp.
• Không có quy trình gì cả: ai muốn đổi thì đổi, hệ mất chuẩn theo thời gian mà không ai nhận ra cho đến khi hỏng nặng.
• Mở đóng góp mà không có người duyệt: đề xuất chất đống, không ai chốt, người đề xuất nản và ngừng tham gia.
• Duyệt bằng cảm tính: không có tiêu chí rõ thay đổi này có thực sự thuộc hệ thống không, dẫn tới mỗi lần duyệt là một lần tranh luận từ đầu.

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

Trong gói thiết kế và vận hành có quản trị, Sinh Vũ bàn giao sẵn quy trình RFC phù hợp quy mô đội khách: mọi thay đổi có người đề xuất và người duyệt, hệ tiến hóa có kiểm soát thay vì trôi dần. Trọng tâm là để đội khách tự đề xuất, tự thêm component mà vẫn giữ chuẩn, không phụ thuộc một người duy nhất biết toàn bộ hệ thống.

Mức nặng nhẹ của quy trình được cân theo quy mô đội và số bên cùng dùng. Sinh Vũ không bê nguyên khuôn của tập đoàn lớn vào một đội năm người. Nguyên tắc chính: nhiều mức song song, đường nhanh cho việc nhỏ, đường đầy đủ cho việc lớn và có rủi ro.

Đóng góp là bất kỳ đề xuất, thiết kế, mã nguồn, tài liệu hay tài sản của một tính năng mới do người ngoài đội lõi làm và phát hành lại cho người khác dùng. Nên cần khung tiếp nhận rõ ràng.

Nathan Curtis, Defining Design System Contributions, EightShapes