Vì sao đội âm thầm quay lại làm thủ công

Adoption (tỉ lệ áp dụng) design system tụt dần thường không đi kèm thông báo. Không ai gửi email nói "chúng tôi đang bỏ thư viện". Họ chỉ tự code một button hơi khác, rồi một card, rồi cả một flow. Đến khi Anh / Chị nhận ra thì khoảng cách đã lớn. Hiểu đúng nguyên nhân là bước đầu tiên trước khi can thiệp.

Nguyên nhân gốc rễ: không phải thái độ

Phản ứng đầu tiên của nhiều team lead là quy cho kỷ luật kém hoặc đội không chịu học. Sinh Vũ chưa gặp trường hợp nào đúng như vậy. Nguyên nhân thực tế thường rơi vào một trong ba nhóm:

• Component quá cứng: không đủ variant (biến thể) và prop (tham số) để xử lý edge case. Đội mất thêm thời gian hack around component hơn là tự code lại từ đầu.
• Tài liệu thiếu ví dụ thực tế: tài liệu mô tả component hoạt động thế nào, nhưng không có ví dụ theo use case của ngành. Đội không biết áp dụng vào màn hình thật của mình.
• Quy trình phê duyệt chậm: đội gặp gap (khoảng trống) trong thư viện, đề xuất component mới nhưng chờ hai tuần mà không có phản hồi. Sprint không chờ ai.

Ba nguyên nhân này có điểm chung: đúng chuẩn khó hơn làm thủ công. Khi đó, đội không cần lý do gì thêm để lựa chọn.

Khung tư duy: con đường trải nhựa

Netflix Engineering từng đúc kết một nguyên tắc gọi là Paved Road (con đường trải nhựa): làm cho con đường đúng chuẩn trở thành con đường dễ đi nhất, không phải con đường bắt buộc. Nếu chuẩn mà gồ ghề hơn đường tắt thì đội sẽ đi đường tắt, dù họ biết đó không phải lựa chọn tốt.

Người dùng, bao gồm cả developer, luôn chọn con đường ít ma sát nhất. Design system thành công không phải vì được bắt buộc dùng mà vì nó thực sự nhanh hơn làm thủ công.

Least Resistance Path, Behavioral Economics ứng dụng trong thiết kế hệ thống

Khi nhìn qua lăng kính này, mỗi lần đội tự làm thủ công là một tín hiệu hệ thống đang có điểm gồ ghề cụ thể cần vá, không phải tín hiệu đội cần kỷ luật thêm.

Tín hiệu sớm và cách phát hiện

Vấn đề thường âm thầm đủ lâu trước khi lộ ra trong báo cáo adoption. Sinh Vũ theo dõi hai tín hiệu chính trong giai đoạn bảo trì:

• Detach rate (tỉ lệ tách component): trong Figma, khi designer detach component khỏi thư viện để chỉnh trực tiếp, đó là dấu hiệu component không đáp ứng đủ. Tỉ lệ này tăng bất thường là cờ đỏ đầu tiên.
• Custom component trong codebase: audit định kỳ để đếm component không có trong thư viện. Nếu số lượng tăng mà không qua quy trình đề xuất, đội đang tự xử lý ngầm.

Ngoài số liệu, phỏng vấn trực tiếp trong buổi pairing (làm việc cùng nhau có quan sát) thường cho biết rào cản thực tế mà dashboard không thể ghi lại.

Cách chặn: giảm ma sát, không tăng rào cản

Một biện pháp quan trọng thường bị bỏ qua là thiết lập escape hatch (lối thoát có kiểm soát) rõ ràng. Cho phép đội làm khác chuẩn trong những trường hợp thực sự cần, nhưng yêu cầu ghi chú lý do và để lại dấu vết để audit. Điều này tốt hơn nhiều so với cấm tuyệt đối vì nó ngăn việc làm thủ công ngầm và tạo dữ liệu thực tế để cải thiện thư viện sau.

Khái niệm Inner Source (nguồn mở nội bộ) từ InnerSource Commons cũng phù hợp ở đây: cho phép đội sản phẩm đề xuất và đóng góp component mới qua quy trình RFC (Request for Comments, đề xuất có phản hồi) rõ ràng. Khi đội cảm thấy mình là người xây thư viện chứ không phải người bị thư viện quản lý, ownership (tinh thần làm chủ) thay đổi rõ rệt.

Lỗi thường gặp khi xử lý sai hướng

• Phạt đội dùng ngoài chuẩn mà không hỏi tại sao: chặn triệu chứng, nguyên nhân vẫn còn đó.
• Chỉ nhìn số adoption giảm mà không phỏng vấn đội: mất đi thông tin về rào cản thực tế mà số liệu không ghi lại.
• Cập nhật tài liệu chậm: đội tiếp tục dùng component cũ vì không biết có phiên bản mới phù hợp hơn.
• Không có kênh phản hồi dễ dùng: đội gặp vấn đề nhưng không biết báo cho ai, tự xử lý cho xong.

Câu hỏi thường gặp

Làm sao biết đội đang âm thầm làm thủ công nếu họ không báo cáo?

Tín hiệu sớm nhất là detach rate (tỉ lệ tách component khỏi thư viện) tăng trong Figma hoặc codebase xuất hiện nhiều custom component không có trong thư viện. Sinh Vũ thường phát hiện qua audit định kỳ và phỏng vấn đội trong buổi pairing, không phải chờ adoption report cuối quý.

Có nên cấm merge code nếu không dùng component từ thư viện không?

Không nên làm thế nếu chưa hiểu nguyên nhân. Cấm cứng chỉ chặn triệu chứng, đội sẽ tìm cách lách thông minh hơn hoặc mất thời gian chờ phê duyệt không cần thiết. Nên ưu tiên sửa component trước, sau đó mới xem xét quy trình kiểm soát nếu vẫn còn vi phạm có chủ đích.

Escape hatch là gì và có nên cho phép không?

Escape hatch (lối thoát có kiểm soát) là cơ chế cho phép đội làm khác chuẩn nhưng phải ghi chú rõ lý do và để lại dấu vết để audit. Cho phép escape hatch có tài liệu tốt hơn nhiều so với cấm hoàn toàn vì nó ngăn việc làm thủ công ngầm, đồng thời tạo dữ liệu để cải thiện thư viện sau.