Đội tự vận hành design system sau bàn giao
Bàn giao một đống file rồi đi là cách chắc chắn nhất để hệ thiết kế chết trong vòng sáu tháng.
Đội tự vận hành được không nhờ một buổi bàn giao, mà nhờ hệ được thiết kế để tự vận hành ngay từ đầu. Ba thứ phải đi kèm hệ: tài liệu sống dùng được trực tiếp, một quy trình duyệt thay đổi rõ ràng, và một người hoặc nhóm nhận trách nhiệm nuôi hệ. Thiếu một trong ba, hệ sẽ loãng dần theo thời gian cho dù ban đầu được xây tốt đến đâu.
- đội kỹ thuật khách sẽ tự nuôi hệ ngay sau bàn giao
- cần Storybook, quy trình RFC và kèm cặp để đội tự đứng
- bàn giao gọn chỉ hợp khi đội đã có kinh nghiệm nuôi hệ từ trước
Giá trị của một design system (hệ thống thiết kế) chỉ hiện ra khi các đội sản phẩm thật sự dùng nó để ra tính năng, không phải khi thư viện được ra mắt. Nói cách khác, bàn giao thành công không đo bằng buổi ra mắt long trọng, mà đo bằng câu hỏi đơn giản hơn nhiều: ba tháng sau, đội Anh/Chị có tự thêm component mới được không, có tự tra cứu tài liệu được không, có tự duyệt thay đổi được không?
Ba thứ phải có trước khi bàn giao
Hầu hết các bàn giao thất bại không phải vì hệ được xây kém. Thất bại vì bàn giao chỉ chuyển file, không chuyển được khả năng vận hành. Để đội thật sự tự đứng được, ba yếu tố sau phải đi kèm hệ ngay từ đầu, không phải bổ sung sau.
- Tài liệu sống dùng được trực tiếp. Tài liệu tĩnh sẽ lỗi thời. Đội sẽ phải quay lại hỏi người làm gốc từng việc nhỏ, rồi dần mất niềm tin vào tài liệu. Công cụ như Storybook cho phép lập trình viên xem, thử và lấy mã ngay trên trình duyệt, gắn trực tiếp với mã đang chạy, không tách rời thực tế.
- Quy trình duyệt thay đổi rõ ràng. Không có quy trình này, mỗi lập trình viên sẽ tự sửa vào nguồn chuẩn theo cách riêng. Hệ vỡ nhanh mà không ai biết từ đâu. Một quy trình RFC (Request for Comments, tức đề xuất thay đổi) đơn giản đủ để giữ chuẩn mà vẫn để đội tự phát triển hệ.
- Người sở hữu rõ ràng. Hệ thiết kế cần được coi như một sản phẩm sống, không phải một dự án có ngày kết thúc. Phải có một người hoặc một nhóm nhỏ nhận trách nhiệm nuôi hệ, không để thành của chung vô chủ. Vô chủ là lý do phổ biến nhất khiến hệ tốt trở nên loãng dần.
Khi nào cần kèm cặp nhiều, khi nào bàn giao gọn được
Bàn giao gọn chỉ hợp lý khi đội đã có kinh nghiệm nuôi hệ từ trước và chỉ cần tiếp nhận thêm một hệ mới vào quy trình đang chạy.
Nếu không chắc đội thuộc loại nào, hãy hỏi thẳng: "Đội có ai đã từng thêm một component mới vào một thư viện chuẩn chưa?" Nếu câu trả lời là chưa, hãy tính đến kèm cặp.
Nối bản vẽ với bản chạy
Một vấn đề thường bị bỏ qua khi bàn giao: thiết kế trong Figma và mã thực tế chạy lệch nhau. Đội phát triển nhìn file Figma, đoán thông số, và dần dần hai phía đi hai hướng khác nhau. Figma Code Connect là cầu nối để khi lập trình viên nhìn vào một component trong Figma, họ thấy ngay đoạn mã tương ứng cần dùng, không cần đoán. Điều này giảm đáng kể việc đội phải hỏi qua lại giữa thiết kế và kỹ thuật.
Lỗi thường gặp khi bàn giao
- Bàn giao một đống file rồi đi. Không ai trong đội biết cách thêm component mới cho đúng quy trình, nên hoặc không thêm, hoặc thêm sai.
- Tài liệu tĩnh lỗi thời ngay sau vài sprint đầu. Đội mất dần niềm tin, bỏ tra cứu, tự làm theo kinh nghiệm cá nhân.
- Không có quy trình duyệt. Mỗi người sửa một kiểu. Sáu tháng sau hệ trở thành một mớ bản sao không đồng nhất.
- Bàn giao bị khóa vào một công cụ độc quyền. Khi công ty đổi công cụ hoặc đội muốn mở rộng, không thể chuyển được.
Bảo trì hệ là việc liên tục. Phải có người coi hệ như một sản phẩm sống và chăm đều, nếu không hệ sẽ loãng dần theo thời gian.
Brad Frost, Atomic Design, chương 5
Góc nhìn của Sinh Vũ
Trong cả ba giai đoạn làm việc, Sinh Vũ đều hướng tới một đích duy nhất: đội khách tự đứng được sau khi Sinh Vũ rút. Giai đoạn dựng đã có Storybook và Figma Code Connect để tài liệu sống cùng mã. Giai đoạn triển khai có quy trình quản trị RFC và bộ chỉ số theo dõi mức độ áp dụng thực tế. Sau bàn giao, Sinh Vũ ở lại đồng hành ba tháng đầu để đội quen tay với việc thêm component, đề xuất thay đổi và tự duyệt theo quy trình, trước khi thật sự độc lập hoàn toàn.
Điều Sinh Vũ quan sát thấy nhiều nhất là các đội thất bại không vì thiếu tài năng, mà vì không được trao đủ công cụ và quy trình để tự quyết định. Một hệ thiết kế tốt, bàn giao đúng, sẽ giảm sự phụ thuộc vào bất kỳ cá nhân nào, kể cả người đã xây nó.
Checklist quyết định
Chủ đề: Làm sao để đội tự vận hành sau khi bàn giao design system. Cẩm nang Sinh Vũ, sinhvu.com
Bấm chọn từng mục Anh / Chị thấy đúng, rồi bấm in hoặc lưu thành PDF để mang theo.
Nếu Anh / Chị đánh dấu phần lớn ở nhóm dấu hiệu trên, đây là lúc nên trao đổi kỹ hơn. Sinh Vũ có thể cùng Anh / Chị soi lại và đề xuất hướng đi.
Nguồn tham khảo
Nathan Curtis, EightShapes: Measuring Design System Success. Brad Frost, Atomic Design, chương 5: Maintaining Design Systems.
Câu hỏi thường gặp
Bao nhiêu buổi kèm cặp là đủ để đội tiếp quản được?
Không có con số tuyệt đối, vì phụ thuộc vào kinh nghiệm của đội. Với đội lần đầu tiếp quản một hệ thiết kế, Sinh Vũ thường làm khoảng 3 đến 5 buổi pairing trực tiếp, tập trung vào cách thêm component mới đúng quy trình và cách dùng Storybook hàng ngày. Quan trọng hơn số buổi là đội phải tự tay làm được ít nhất một thay đổi thật trước khi Sinh Vũ rút.
Có nhất thiết phải dùng Storybook không, hay có cách khác?
Storybook là công cụ phổ biến nhất hiện tại vì cho phép lập trình viên xem, thử và lấy mã trực tiếp trên trình duyệt mà không cần hỏi người thiết kế. Nếu đội đã có hạ tầng tài liệu khác đang chạy tốt, quan trọng hơn là đảm bảo tài liệu đó được cập nhật liên tục và đội thật sự tra cứu nó, không phải chỉ để đó cho có.
Quy trình RFC để làm gì, có phức tạp không?
RFC (Request for Comments, tức đề xuất thay đổi) là quy trình để bất kỳ ai trong đội cũng có thể đề xuất thêm hoặc sửa component mà không tự ý sửa vào nguồn chuẩn. Không cần phức tạp. Một mẫu đề xuất đơn giản kèm một bước duyệt từ người sở hữu hệ là đủ để tránh tình trạng mỗi người sửa một kiểu, hệ vỡ mà không ai biết từ đâu.