Đội nhỏ tới mức nào thì thư viện 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 (hệ thống thiết kế dùng chung cho sản phẩm số)? 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, thời gian dành riêng để 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 là việc làm đều đặn, lâu dài.
• Không có quy trình đóng góp ngược: các đội chỉ dùng 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ũ

Về phạm vi dịch vụ, Sinh Vũ nói thẳng: khi đội kỹ thuật quá mỏng và không ai được giao nuôi hệ, dựng cả hệ thiết kế số lúc này dễ bị bỏ xó. Khi đó nên dồn sức cho sản phẩm, chỉ giữ phần gọn là token và vài component lõi.

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

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

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