Đội nhỏ tới mức nào thì design system bị bỏ xó

Design system (hệ thống thiết kế) là một sản phẩm nội bộ. Nó cần được maintain (bảo trì, cập nhật thường xuyên) giống như bất kỳ sản phẩm nào khác: có backlog (danh sách việc cần làm), có review, có versioning (quản lý phiên bản). Khi đội quá nhỏ để duy trì điều đó song song với công việc chính, hệ thống không chết đột ngột. Nó chết dần: component (thành phần giao diện) cũ không ai cập nhật, Figma library (thư viện thiết kế) lạc nhịp với code, rồi mọi người ngừng dùng mà không ai tuyên bố chính thức.

Ngưỡng loại trừ Sinh Vũ đặt ra

Sinh Vũ ghi thẳng vào điều kiện dịch vụ: đội kỹ thuật dưới 3 developer là cảnh báo đỏ. Không phải vì 3 là con số ma thuật, mà vì dưới ngưỡng đó, mỗi người đều phải gánh quá nhiều vai cùng lúc và design system sẽ thua trong cuộc cạnh tranh ưu tiên với tính năng mới.

Hai điều kiện cần kiểm tra trước khi quyết định:

• Tổng số developer trong đội: dưới 3 người là ngưỡng rủi ro cao.
• Số designer: nếu chỉ có 1 designer phải vừa thiết kế tính năng vừa chăm sóc thư viện, họ sẽ không có đủ thời lượng cho cả hai.

Lưu ý: đếm đầu người tổng cộng chưa đủ. Điều quan trọng hơn là ai trong số đó có thời lượng thực sự và quyền hạn để làm chủ hệ thống.

Vai trò không thể thiếu: người sở hữu hệ thống

Nathan Curtis từ EightShapes đặt nguyên tắc này rất rõ:

Design systems need a team. Không có owner rõ ràng, hệ thống rơi vào tragedy of the commons: tài sản chung thì không ai tự nguyện duy trì.

Nathan Curtis, EightShapes: Design systems need a team

Tragedy of the commons (bi kịch tài sản chung) là hiện tượng kinh tế học: khi một tài nguyên thuộc về tất cả mọi người mà không ai chịu trách nhiệm chính, nó sẽ bị khai thác đến kiệt quệ hoặc bị bỏ mặc. Với design system, biểu hiện cụ thể là: mọi người cứ dùng component cũ vì không biết ai có quyền sửa, hoặc mỗi người tự thêm component theo cách riêng mà không review.

Đội nhỏ vẫn có thể làm được nếu có ít nhất một người được giao vai trò 'component owner' (người chủ component) với thời lượng chính thức, không phải kiêm nhiệm lúc rảnh.

Mô hình vận hành và rủi ro đội nhỏ

Nielsen Norman Group xác định ba mô hình vận hành design system:

Đội dưới 3 người thường chỉ có thể làm Solitary. Mô hình đó không sai về mặt kỹ thuật, nhưng rủi ro tập trung vào một người là rủi ro tổ chức thật sự.

Conway's Law (Luật Conway, Melvin Conway, 1968) cũng chỉ ra một điều thực tế: kiến trúc hệ thống phản ánh cấu trúc giao tiếp của tổ chức. Đội nhỏ không có ranh giới vai trò rõ ràng sẽ tạo ra design system cũng không rõ ràng về cấu trúc, khó dùng, khó mở rộng.

Khi nào đội nhỏ vẫn nên làm

Có hai trường hợp đội dưới ngưỡng vẫn có thể đầu tư hợp lý:

• Đội sắp mở rộng trong 6 đến 12 tháng tới: đầu tư sớm giảm chi phí onboarding (đưa người mới vào làm việc) đáng kể, vì người mới có nền để học thay vì phải đọc hiểu từ đầu.
• Có ít nhất một người được giao vai trò 'component lead' với thời lượng chính thức: kể cả đội 2 đến 3 người, nếu phân vai rõ ràng và người đó có quyền ra quyết định về hệ thống, xác suất thành công cao hơn nhiều.

Ngược lại, nếu đội lớn nhưng không ai tự nguyện nhận sở hữu hệ thống, đó cũng là dấu hiệu cần xem lại trước khi đầu tư.

Lỗi thường gặp khi đội nhỏ cố làm

• Xây xong rồi không có người maintain: sau 3 đến 6 tháng, component cũ tồn tại song song với component mới, không ai biết nên dùng phiên bản nào.
• Giao cho intern hoặc junior mà không có senior review thường xuyên: hệ thống tích lũy nợ kỹ thuật (technical debt) nhanh hơn tính năng chính.
• Không có governance: mỗi người tự thêm component theo cách riêng, Figma library loạn trong vòng 3 tháng.
• Nhầm ngưỡng người: đếm tổng nhân sự mà không xem ai thực sự có thời lượng và quyền hạn để maintain.

Sinh Vũ đưa điều kiện loại trừ này vào dịch vụ không phải để từ chối khách, mà để bảo vệ khách khỏi một khoản đầu tư sẽ không mang lại kết quả. Một component library đơn giản hơn, được dùng đều và cập nhật được, có giá trị thực tế hơn một design system đầy đủ bị bỏ xó sau nửa năm.