Có nên thử sản phẩm điểm mẫu trước khi nhân rộng design system?

Khi design system (hệ thống thiết kế dùng chung) đã được xây xong ở mức cơ bản, câu hỏi tiếp theo luôn là: triển khai thế nào? Nhiều tổ chức muốn làm nhanh, áp dụng cùng lúc cho tất cả sản phẩm để sớm thu lại lợi tức đầu tư. Sinh Vũ hiểu tư duy đó. Nhưng kinh nghiệm thực tế, và cả khung tư duy của Nathan Curtis từ EightShapes, đều dẫn đến kết luận giống nhau: bắt đầu bằng một sản phẩm điểm mẫu là con đường an toàn hơn và thường nhanh hơn về tổng thể.

Tại sao cần sản phẩm điểm mẫu

Hệ thống thiết kế được xây trong môi trường tương đối sạch: Figma, Storybook, tài liệu nội bộ. Nhưng khi hệ đó va vào một sản phẩm thật đang chạy, với code legacy (mã cũ kế thừa), quy trình phát hành riêng và đội có thói quen làm việc riêng, những lỗ hổng mới sẽ xuất hiện mà không cách nào thấy trước được.

Pilot (sản phẩm chạy thử) làm đúng một việc: bộc lộ những lỗ hổng đó trước khi cả tổ chức phụ thuộc vào hệ. Sửa lỗi gốc khi mới một đội bị ảnh hưởng rẻ hơn rất nhiều so với sửa khi mười đội đã dựa vào hệ đó để phát hành.

Ngoài ra, pilot tạo ra bằng chứng sống. Khi Anh / Chị đến gặp đội thứ hai và nói "hệ này hoạt động tốt", lời nói đó không nặng bằng việc chỉ vào một sản phẩm đang chạy thật và nói "đây là kết quả".

Chọn sản phẩm pilot như thế nào

Không phải sản phẩm nào cũng phù hợp làm điểm mẫu. Cần cân nhắc ba tiêu chí:

• Đủ thật để bộc lộ vấn đề. Sản phẩm quá đơn giản hoặc quá bên lề sẽ không bộc lộ được vấn đề thật của hệ. Pilot đó chạy tốt không có nghĩa là hệ đã sẵn sàng cho sản phẩm phức tạp hơn.
• Không quá rủi ro nếu trục trặc. Không nên chọn sản phẩm có lưu lượng người dùng cao nhất hoặc đang trong giai đoạn nhạy cảm về kinh doanh làm điểm mẫu đầu tiên.
• Đội của sản phẩm đó có sẵn sàng và có tiếng nói. Đội không muốn tham gia sẽ đưa ra phản hồi hời hợt. Đội có tiếng nói trong tổ chức sẽ làm cho bài học từ pilot được nghe và được sửa.

Khi nào làm pilot, khi nào có thể bỏ qua

Lỗi thường gặp trong giai đoạn này

• Nhân rộng cả tổ chức cùng lúc. Khi lỗi gốc xuất hiện, chi phí sửa nhân lên theo số đội đang phụ thuộc vào hệ.
• Chọn sản phẩm pilot quá an toàn. Pilot chạy tốt nhưng không phản ánh độ phức tạp thật của các sản phẩm còn lại. Khi nhân rộng, vấn đề mới xuất hiện và bị gán nhầm cho hệ thay vì cho việc pilot không đại diện.
• Pilot xong không có đường phản hồi ngược. Bài học từ pilot phải có cơ chế đi ngược về hệ để sửa, không chỉ nằm trong biên bản họp hoặc ghi chú cá nhân của đội pilot.

Thử vài nhóm trên một hoặc vài sản phẩm trước để trải nghiệm quyền truy cập, onboarding và quy trình. Thành công rồi mới mở rộng ở đợt sau.

Nathan Curtis, EightShapes, Adopting Design Systems

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

Trong giai đoạn triển khai A3 tại Sinh Vũ, chúng tôi bắt đầu bằng cách chuyển một sản phẩm điểm mẫu sang hệ thống trước, kèm quy trình quản trị RFC (yêu cầu thay đổi có kiểm soát) và bộ chỉ số theo dõi mức độ áp dụng. Không phải vì quy trình đòi hỏi, mà vì chúng tôi cần biết hệ chạy thật như thế nào trước khi để các đội khác phụ thuộc vào nó.

Sản phẩm đó vừa là bài kiểm tra, vừa là bằng chứng. Khi đội tiếp theo hỏi "hệ này có ổn không", chúng tôi không cần thuyết phục bằng lời. Chỉ cần trỏ vào sản phẩm đang chạy.

Anh / Chị không cần pilot hoàn hảo. Cần một pilot đủ thật để dạy được điều mà không môi trường lab nào dạy được.