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

Sau khi nghiệm thu, không ai được giao trách nhiệm nuôi hệ. 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 trang trình chiếu báo cáo. Vấn đề này nằm ở cách tổ chức làm việc.

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

Theo Brad Frost trong Atomic Design, hệ thiết kế là một 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 tiến độ thấy dùng thành phần giao diện chuẩn (component) mất công hơn tự viết mã (code), nên tự chế một bản riêng. Lần sau, đội khác thấy bản chế đó trong kho mã nguồn và sao chép lại. Cứ thế nó nhân lên.

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, tức là đề xuất thay đổi có nêu rõ lý do và phải có người duyệt. Không có bước này, hệ thống tích luỹ ngoại lệ cho đến khi không còn nhận ra hình dạng ban đầu.
• Đo mức áp dụng thật. Định kỳ đếm xem bao nhiêu màn hình đang dùng component chuẩn và bao nhiêu chỗ đang tự chế. Không có con số này thì không ai biết hệ đang khoẻ hay đang loãng, và quyết định bảo trì chỉ dựa vào cảm giác.
• Đườ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ự viết mã, đội sản phẩm sẽ bỏ hệ thống vì đang chịu áp lực giao sản phẩm đúng hạn, dù họ vẫn muốn tuân thủ.

Nê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 thiết kế đẹp trên Figma (phần mềm thiết kế giao diện), 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 component không còn phản ánh đúng sản phẩm thật, nó thành đồ bỏ đi. Việc bảo trì khi ấy chỉ còn là vá tạm, 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ể gồm ba phần. Một là nối từng thành phần trong Figma với thành phần tương ứng trong code qua Figma Code Connect. Hai là quy trình RFC cho mọi thay đổi hệ thống. Ba là bộ chỉ số áp dụng theo từng đội. Nhờ vậy có thể thấy chỗ nào đang loãng trước khi nó lan rộng.

Giai đoạn bảo trì trong cách làm việc của Sinh Vũ có mục đích nuôi hệ theo định kỳ, để các đội không âm thầm quay lại tự chế riê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 cân nhắc có nên đầu tư vào hệ thiết kế hay không, trước khi hỏi hệ thiết kế có đẹp không, nên hỏi đội mình có người và ngân sách để nuôi nó không. Trả lời được câu sau rồi hãy bước tiếp.