Tập đoàn nhiều thương hiệu: dùng chung ra sao

Khi tập đoàn có nhiều thương hiệu cùng dùng chung một mã nguồn, câu hỏi không phải là "dùng chung được không" mà là "tách phần riêng bằng cách nào để hai năm sau hệ vẫn còn nhất quán". Nếu không có kiến trúc và quản trị rõ ràng ngay từ đầu, gần như chắc chắn mỗi đội sẽ tự xử theo cách riêng. Khi đó hệ dùng chung chỉ còn trên giấy.

Kiến trúc token ba tầng

Nền tảng của mọi design system (hệ thiết kế) phục vụ nhiều thương hiệu là token (đơn vị biến số thiết kế như màu sắc, khoảng cách, cỡ chữ) được phân thành ba tầng rõ ràng:

• Tầng nguyên thuỷ (primitive): toàn bộ giá trị thô của tập đoàn, ví dụ tất cả các màu trong bảng màu chính, tất cả bậc khoảng cách. Tầng này không ai dùng trực tiếp.
• Tầng ngữ nghĩa (semantic): gán ý nghĩa cho giá trị thô, ví dụ "màu nút chính", "màu nền cảnh báo". Đây là tầng lõi dùng chung, nhất quán giữa mọi thương hiệu.
• Tầng chủ đề (theme): mỗi thương hiệu có một thư mục riêng, chỉ ghi đè những giá trị ngữ nghĩa cần khác biệt. Thương hiệu A có màu nút chính là xanh biển, thương hiệu B chọn đỏ đô, lõi chung không thay đổi gì cả.

Nguyên tắc đặt tên token cũng cần có tầng vùng tên (namespace) để phân biệt: hệ nào, thương hiệu nào, miền nào. Không làm bước này, sau vài tháng token của thương hiệu này bị thương hiệu kia ghi đè mà không ai hay.

Mô hình đội: tập trung hay liên bang

Trong thực tế, hầu hết tập đoàn nên bắt đầu bằng mô hình tập trung, rồi chuyển dần sang liên bang khi từng thương hiệu đã hiểu hệ và có người có thể đóng góp có trách nhiệm.

Quản trị: phần không thể bỏ qua

Ở quy mô nhiều thương hiệu, design system không còn là vấn đề kỹ thuật thuần tuý. Hai thứ tối thiểu cần có:

• Quy trình RFC (Request for Comment, tức đề xuất thay đổi có người duyệt): bất kỳ thay đổi nào ở lõi chung đều phải qua bước này. Ai đề xuất, ai duyệt, hạn bao lâu để các thương hiệu phản hồi. Không có bước này, một đội sửa lõi theo nhu cầu của mình sẽ vô tình phá vỡ trải nghiệm của thương hiệu khác.
• Đo mức áp dụng (adoption): biết được đội nào đang thực sự dùng hệ, đội nào đã âm thầm quay lại làm thủ công. Không đo thì không biết, không biết thì không sửa được.

Một design system không có quản trị là một thư viện component đang chờ phân rã.

Nathan Curtis, EightShapes

Lỗi thường gặp ở tập đoàn

• Fork (tách nhánh) mỗi thương hiệu một bản hệ riêng: ban đầu có vẻ linh hoạt, nhưng sau vài quý mỗi bản đi một hướng, cập nhật và sửa lỗi phải làm lại nhiều lần.
• Có thư viện component nhưng không có quản trị: thay đổi tuỳ tiện, thương hiệu này sửa làm hỏng thương hiệu kia mà không có cơ chế cảnh báo.
• Không đặt namespace trong token: phần chung và phần riêng trộn vào nhau, sau này muốn tách không tách được sạch.
• Để nhiều hệ song song tồn tại quá lâu mà không có kế hoạch hợp nhất: chi phí duy trì nhân lên, nhất quán giảm dần.

Chọn điểm mẫu trước khi mở rộng

Về triển khai, cách chắc tay là chọn một sản phẩm điểm mẫu chuyển sang hệ trước, kiểm chứng kiến trúc trong thực tế, rồi mới mở rộng sang các thương hiệu còn lại. Cách này giúp phát hiện vấn đề sớm thay vì triển khai ồ ạt rồi mới biết thiếu sót.

Hệ có thể xây rất tốt, nhưng nếu không có người chịu trách nhiệm duy trì và cập nhật theo thời gian thì dần dần sẽ không còn ai dùng. Ở quy mô tập đoàn, việc điều phối giữa các đội quan trọng ngang với phần kỹ thuật. Anh / Chị nên cân nhắc kỹ cơ cấu đội và nguồn lực bảo trì trước khi chốt phạm vi dự án.

Bài viết là thông tin tham khảo. Phạm vi, giá và cam kết cụ thể của Sinh Vũ ghi trong hồ sơ đề xuất và hợp đồng đã ký.