Bốn thứ giữ hệ thiết kế không loãng

Hầu hết hệ thiết kế không chết vì thiết kế sai. Chúng chết vì sau khi nghiệm thu, không ai được giao trách nhiệm nuôi. Các đội sản phẩm bắt đầu tự chế, tài liệu ngày càng lệch với thực tế, rồi đến một lúc cả tổ chức thầm hiểu rằng hệ thống kia chỉ còn tồn tại trên slide báo cáo. Đây không phải vấn đề kỹ thuật mà là vấn đề tổ chức.

Tại sao hệ thiết kế loãng

Theo Brad Frost trong Atomic Design, hệ thiết kế không phải dự án có điểm kết thúc mà là sản phẩm sống phục vụ các sản phẩm khác. Nó cần được nuôi dưỡng liên tục thì mới thật sự sống được.

Cơ chế loãng thường diễn ra theo một trình tự quen thuộc: một đội đang gấp ra hàng, dùng component chuẩn mất công hơn tự code, nên tự chế một bản riêng. Lần sau đội khác thấy bản chế đó trong codebase, sao chép lại. Cứ thế nhân lên. Khi thư viện tình huống không còn phản ánh đúng sản phẩm thật, nó trở thành đồ bỏ và việc bảo trì rơi vào vá víu tạm bợ, phá hết công dựng ban đầu.

Bốn thứ phải đi cùng nhau

• Người sở hữu được giao rõ ràng. Không phải kiêm nhiệm mờ nhạt, không phải của chung. Khi không ai chịu trách nhiệm, mọi người đều né quyết định và hệ thống không ai giữ.
• Quy trình duyệt thay đổi. Mỗi khi cần thêm, sửa, hoặc bỏ component, phải qua một bước xét duyệt có ghi chép. Sinh Vũ gọi đây là RFC (yêu cầu thay đổi có tham chiếu, tức là đề xuất thay đổi có lý do và có người duyệt). Không có bước này, hệ thống tích lũy ngoại lệ cho đến khi không còn nhận ra hình dạng ban đầu.
• Đo lường mức áp dụng. Không đo thì không biết loãng ở đâu. Chỉ số cần theo dõi là tỉ lệ màn hình dùng component chuẩn so với component tự chế, và số component mồ côi sinh ra ngoài hệ thống theo từng đợt ra hàng.
• Đường chuẩn phải dễ đi hơn đường tự chế. Đây là yếu tố bị bỏ qua nhiều nhất. Nếu dùng component chuẩn khó hơn tự code, đội sản phẩm sẽ bỏ hệ thống, không phải vì họ không muốn tuân thủ mà vì họ đang bị áp lực ra hàng.

Khi nào cần ưu tiên việc gì trước

Lỗi thường gặp sau khi dựng xong

• Nghiệm thu xong coi là hết việc, không cấp ngân sách bảo trì cho giai đoạn tiếp theo.
• Chỉ giữ bản Figma đẹp, còn code trôi dần theo mỗi sản phẩm. Khi Figma và code lệch nhau, các đội theo code thật, không theo Figma.
• Thêm component ồ ạt sau mỗi yêu cầu nhưng không dọn cái cũ, kho phình mà tỉ lệ dùng lại thấp dần.
• Không ai được giao sở hữu, hệ thành của chung nên không ai thật sự giữ.

Khi thư viện tình huống không còn phản ánh đúng sản phẩm thật, nó trở thành đồ bỏ và việc bảo trì rơi vào vá víu tạm bợ, phá hết công dựng ban đầu.

Brad Frost, Atomic Design, ch.5

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

Sinh Vũ dựng sẵn cơ chế chống loãng ngay trong dự án, không để đến sau mới xử lý. Cụ thể là nối một đổi một giữa Figma và code qua Figma Code Connect, quy trình RFC cho mọi thay đổi hệ thống, và bộ chỉ số áp dụng theo từng đội để nhìn thấy loãng ở đâu trước khi nó lan rộng.

Giai đoạn bảo trì trong khung làm việc của Sinh Vũ tồn tại đúng để nuôi dưỡng hệ định kỳ, tránh các đội âm thầm quay lại làm thủ công. Nhưng Sinh Vũ không hứa hệ tự sống. Phần sống hay chết nằm ở người sở hữu và nhịp rà soát mà đội khách duy trì, không nằm ở chất lượng của bản dựng ban đầu.

Nếu Anh / Chị đang ở giai đoạn cân nhắc xem có nên đầu tư vào hệ thiết kế hay không, câu hỏi đúng để hỏi trước không phải là "hệ thống này thiết kế có đẹp không" mà là "chúng ta có người và ngân sách để nuôi nó không". Có câu trả lời cho câu hỏi đó thì mới nên bước tiếp.