Chọn sản phẩm điểm mẫu khi xây design system

Chốt nhanh

Với tổ chức có từ ba sản phẩm số trở lên, thử trên một sản phẩm điểm mẫu trước khi nhân rộng là cách tiếp cận đúng. Sản phẩm điểm mẫu giúp phát hiện điểm yếu của kiến trúc hệ thống trước khi những điểm yếu đó được sao chép sang nhiều sản phẩm khác. Tuy nhiên, sản phẩm được chọn phải đại diện cho độ phức tạp điển hình, không phải sản phẩm dễ nhất trong danh sách.

Với tổ chức đa sản phẩm, câu hỏi này xuất hiện gần như ngay lập tức sau khi quyết định xây design system (hệ thống thiết kế dùng chung). Câu trả lời của Sinh Vũ là: nên, nhưng điều quan trọng hơn là chọn đúng sản phẩm để thử. Chọn sai sản phẩm pilot (sản phẩm điểm mẫu) thì kết quả thu về sẽ không phản ánh thực tế, và khi nhân rộng Anh Chị vẫn gặp đủ thứ bất ngờ như chưa từng thử.

Vì sao thứ tự này quan trọng

Một lỗi kiến trúc phát hiện ở giai đoạn pilot chỉ cần sửa một lần. Cùng lỗi đó phát hiện sau khi đã nhân rộng sang năm, bảy sản phẩm, Anh Chị sẽ phải sửa ở nhiều nơi cùng lúc, với nhiều đội kỹ thuật khác nhau, và có thể mỗi đội đã xây thêm lớp logic riêng phía trên. Chi phí sửa tăng theo cấp số nhân, không phải cộng. Đây là lý do nguyên tắc "thử trước, nhân rộng sau" tồn tại trong quản lý thay đổi tổ chức từ lâu, không chỉ trong ngành thiết kế.

Ngoài kỹ thuật, pilot còn tạo ra nhóm người dùng nội bộ đầu tiên, những người đã tích hợp thật, gặp vấn đề thật và giải quyết được. Họ trở thành người lan truyền hệ thống hiệu quả hơn bất kỳ tài liệu nào Anh Chị viết ra, vì họ nói chuyện được với đồng nghiệp theo đúng ngôn ngữ kỹ thuật của tổ chức.

Chọn sản phẩm điểm mẫu đúng cách

Đây là điểm dễ sai nhất. Nhiều tổ chức chọn sản phẩm đơn giản nhất để pilot vì muốn chắc thành công. Kết quả là pilot "xanh đèn" nhưng khi sang sản phẩm phức tạp hơn, design system bắt đầu thiếu đủ thứ.

Tiêu chí Sinh Vũ dùng để chọn sản phẩm pilot:

Có đội thiết kế và kỹ thuật đang hoạt động, không phải dự án đang đóng băng hay sắp bàn giao.
Không có lịch release (phát hành) trong ba tháng tới, vì đội đang chạy deadline sẽ không có thời gian báo cáo vấn đề đúng lúc.
Có đủ số màn hình và loại giao diện để kiểm tra hệ thống, đại diện cho độ phức tạp điển hình của toàn bộ danh sách sản phẩm.
Đội kỹ thuật của sản phẩm đó sẵn sàng tham gia sớm và phản hồi thẳng thắn khi component (thành phần giao diện) thiếu hoặc token (đơn vị giá trị thiết kế như màu, khoảng cách) chưa đúng.

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

Nên làm pilot khi: tổ chức có từ ba sản phẩm số trở lên sẽ dùng chung design system; các sản phẩm có đội kỹ thuật riêng biệt cần thuyết phục từng đội; đây là lần đầu tổ chức xây design system và chưa có kinh nghiệm vận hành.

Có thể bỏ qua pilot khi: chỉ có một đến hai sản phẩm, triển khai song song không phức tạp hơn nhiều so với pilot; hoặc đây là greenfield (dự án mới hoàn toàn, chưa có code cũ), không có legacy (mã nguồn cũ) cần tích hợp và rủi ro nhân rộng lỗi về bằng không.

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

Chọn sản phẩm đơn giản nhất để chắc thành công, bỏ lỡ các vấn đề của sản phẩm phức tạp hơn.
Pilot thành công nhưng không rút ra bài học thành tài liệu. Mỗi đội tiếp theo lại gặp đúng vấn đề cũ, chỉ là không ai ghi lại.
Kéo dài pilot vì muốn design system hoàn hảo trước khi nhân rộng. Trong thời gian đó, các sản phẩm khác tiếp tục xây theo cách riêng và khoảng cách càng khó thu hẹp.
Không có người chịu trách nhiệm bảo trì design system sau khi pilot thành công, hệ thống mồ côi dần.

Design system adoption thường thất bại không phải vì kỹ thuật xấu, mà vì đội sản phẩm không được tham gia từ đầu.
Quan điểm thực hành ngành, ghi nhận từ kinh nghiệm Sinh Vũ Studio

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

Sinh Vũ luôn đề xuất bắt đầu với một sản phẩm điểm mẫu khi làm việc với tập đoàn đa sản phẩm. Lý do không chỉ là kỹ thuật. Pilot tạo ra câu chuyện thật trong nội bộ: đội nào đó đã dùng, đã gặp khó, đã giải quyết được và sẵn sàng kể lại. Câu chuyện đó thuyết phục các đội còn lại hiệu quả hơn bất kỳ bản trình bày nào từ nhóm xây dựng hệ thống.

Sau khi pilot kết thúc, bước Sinh Vũ không bao giờ bỏ qua là cùng khách viết adoption guide (tài liệu hướng dẫn tích hợp) trước khi mở rộng sang sản phẩm tiếp theo. Không có tài liệu này, nhân rộng chỉ là sao chép rủi ro, không phải sao chép thành công.

Nguồn tham khảo

Kotter, Leading Change (8-step change model), dùng nguyên tắc thay đổi tổ chức an toàn. Tài liệu dịch vụ A3 của Sinh Vũ Studio.

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

Pilot kéo dài bao lâu là hợp lý?

Đủ để thấy vấn đề thực tế trong điều kiện làm việc bình thường. Sinh Vũ thường quan sát tối thiểu hai đến ba tháng sử dụng thực, không phải demo. Ngắn hơn thì chưa đủ dữ liệu, dài hơn thì các sản phẩm còn lại sẽ tiếp tục xây ngoài hệ thống và khoảng cách càng khó thu hẹp.

Nếu tổ chức chỉ có hai sản phẩm thì có cần pilot không?

Không nhất thiết. Khi chỉ có một đến hai sản phẩm, triển khai song song thường không phức tạp hơn pilot là bao. Sinh Vũ chỉ đề xuất pilot khi số sản phẩm đủ lớn để một lỗi kiến trúc nhân rộng thành gánh nặng thực sự.

Pilot thành công rồi thì bước tiếp theo là gì?

Trước khi nhân rộng, cần rút ra bài học và viết thành tài liệu hướng dẫn tích hợp (adoption guide). Nếu bỏ bước này, mỗi đội sản phẩm tiếp theo sẽ lại gặp đúng những vấn đề mà pilot đã giải quyết, chỉ là không ai ghi lại. Sinh Vũ luôn đi cùng khách trong bước viết adoption guide trước khi bàn giao cho đội kỹ thuật mở rộng.