Đội nhỏ tới mức nào thì design system bị bỏ xó

Câu hỏi Sinh Vũ nghe nhiều là: đội mấy người thì mới nên làm design system? Câu hỏi đúng hơn là: trong đội đó, có ai được giao nuôi hệ thống không? Khi không ai được giao rõ, hệ thống sẽ bị bỏ xó, bất kể đội có năm người hay mười lăm người.

Tại sao số người không phải yếu tố quyết định

Hệ thống thiết kế là sản phẩm phục vụ các đội khác. Như mọi sản phẩm, nó cần người chủ sở hữu, ngân sách thời gian để duy trì, và quy trình để cập nhật. Thiếu một trong ba thứ đó, hệ thống sẽ đứng yên trong khi sản phẩm thật tiếp tục thay đổi. Sau vài tháng, khoảng cách giữa hệ thống và sản phẩm thật rộng ra, mọi người ngừng dùng và quay lại thiết kế tay.

Điều này xảy ra ở đội lớn lẫn đội nhỏ. Đội lớn thậm chí dễ rơi vào bẫy hơn vì ai cũng nghĩ người khác đang lo. Đội nhỏ ít nhất biết rõ mình không có người, nên dễ đưa ra quyết định thực tế hơn.

Ba mô hình đội và phạm vi phù hợp

Nathan Curtis của EightShapes phân loại ba mô hình đội cho hệ thống thiết kế:

• Đơn lẻ (solitary): một người kiêm nhiệm duy trì hệ thống bên cạnh công việc chính. Phù hợp với đội nhỏ, nhưng chỉ trụ được khi phạm vi hệ thống đủ nhỏ để một người ôm được.
• Tập trung (centralized): một đội chuyên trách chỉ làm hệ thống. Phù hợp khi tổ chức đủ lớn và đủ ngân sách để dành hẳn một nhóm cho việc này.
• Liên bang (federated): nhiều đội cùng đóng góp vào hệ thống chung. Phù hợp khi có nhiều đội cùng dùng và cần chia tải duy trì, thay vì dồn vào một người hay một đội trung tâm.

Đội càng nhỏ, mô hình thực tế nhất là đơn lẻ. Và mô hình đơn lẻ chỉ hoạt động khi phạm vi hệ thống tương xứng với sức của một người kiêm nhiệm.

Khi nào làm đầy đủ, khi nào làm gọn

Lỗi thường gặp khi đội nhỏ làm hệ thống

• Giao cho cả đội chung chung: nghĩa là không ai thật sự chịu trách nhiệm. Khi có vấn đề, mọi người đều chờ người khác xử lý.
• Dựng hệ lớn hơn sức nuôi: ra mắt với hàng trăm component, nhưng đội chỉ có một người kiêm nhiệm. Vài tháng sau hệ thống đứng yên, đội quay lại làm tay.
• Coi ra mắt là xong: không tính chi phí duy trì liên tục vào ngân sách và nhân sự ngay từ đầu. Duy trì hệ thống không phải việc làm một lần.
• Không có quy trình đóng góp ngược: các đội chỉ tiêu thụ hệ thống mà không có cách đóng góp cải tiến trở lại. Người sở hữu trở thành nút cổ chai duy nhất và kiệt sức dần.

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

Sinh Vũ nói thẳng trong ranh giới dịch vụ: khi đội kỹ thuật quá mỏng và không ai được giao nuôi hệ, hệ thiết kế số dễ bị bỏ xó, và trong trường hợp đó nên tập trung làm sản phẩm trước.

Theo quan sát thực hành của Sinh Vũ, đội dưới ba người thường rơi vào cảnh này. Nhưng đây là quan sát vận hành, không phải ngưỡng cứng. Biến số quyết định vẫn là có ai kiêm nhiệm việc duy trì hay không, chứ không phải con số đầu người.

Với những đội đủ sức triển khai, Sinh Vũ không chỉ giao hàng mà còn kèm cặp đội kỹ thuật qua các buổi làm việc cùng (pairing) và tài liệu Storybook để đội tự vận hành về sau. Trọng tâm là tỉ lệ áp dụng thật sự trong sản phẩm, không phải bàn giao xong là hết.

Hệ thống là sản phẩm phục vụ các đội khác. Không có chủ sở hữu thì hệ thống sẽ loãng và bị bỏ, dù đội to hay nhỏ.

Nathan Curtis, EightShapes