Chi phí bảo trì design system: tính thế nào mới đúng

Chi phí bảo trì design system (hệ thống thiết kế dùng chung) hàng năm là câu hỏi Sinh Vũ nhận được thường xuyên khi khách đang cân nhắc ký hợp đồng dài hạn hoặc lập kế hoạch ngân sách. Câu trả lời thẳng thắn: không có con số tỷ lệ phần trăm nào đúng với mọi tổ chức. Nhưng có cách tính minh bạch để Anh Chị không bị bất ngờ sau khi hệ thống đã ra mắt.

Ba nhóm chi phí thường bị lẫn lộn

Trước khi tính tổng, cần tách rõ ba loại công việc bảo trì có bản chất khác nhau:

• Bảo trì kỹ thuật: cập nhật dependency (thư viện phụ thuộc), nâng version framework (nền tảng lập trình), vá lỗi tương thích khi trình duyệt hoặc hệ điều hành thay đổi. Loại này không tạo ra tính năng mới nhưng bắt buộc để hệ thống không bị lỗi thời.
• Mở rộng tính năng: thêm component (thành phần giao diện) mới, xây pattern (mẫu bố cục) cho luồng sản phẩm mới, đồng bộ khi team thiết kế ra quyết định hướng mới. Loại này tăng giá trị hệ thống nhưng cần ngân sách riêng, không phải "bảo trì" theo nghĩa hẹp.
• Cải tiến chất lượng: re-audit (kiểm tra lại) WCAG (Hướng dẫn tiếp cận nội dung web của W3C) khi assistive technology (công nghệ hỗ trợ người dùng khuyết tật) thay đổi hành vi, cải thiện performance (hiệu năng), refactor (tái cấu trúc) code đã phát sinh nợ kỹ thuật. Loại này hay bị cắt đầu tiên khi ngân sách eo hẹp và gây hậu quả chậm nhưng chắc.

Ước tính ba loại riêng rồi cộng lại sẽ chính xác hơn nhiều so với lấy một tỷ lệ phần trăm áp vào tổng chi phí ban đầu.

Nguyên tắc 15 đến 25 phần trăm dùng đến đâu

Trong ngành phần mềm tổng quát, nguyên tắc do Boehm (1981) đặt ra là chi phí bảo trì hàng năm thường rơi vào khoảng 15 đến 25 phần trăm chi phí phát triển ban đầu. Con số này được trích dẫn rộng rãi và không sai trong ngữ cảnh phần mềm doanh nghiệp truyền thống.

Tuy nhiên, design system hiện đại có đặc điểm khác: vòng đời ngắn hơn, cập nhật thường xuyên hơn, và phụ thuộc nhiều vào tốc độ thay đổi của sản phẩm lẫn hệ sinh thái kỹ thuật xung quanh. Anh Chị có thể dùng 15 đến 25 phần trăm như một điểm neo ban đầu để có cảm giác về quy mô, nhưng không nên lấy đó làm ngân sách chính thức mà không kiểm tra lại với khối lượng công việc cụ thể.

Chi phí bảo trì bằng không không phải dấu hiệu hệ thống không cần bảo trì. Đó là dấu hiệu hệ thống đang bị bỏ xó.

Quan điểm thực hành, Sinh Vũ Studio

Các yếu tố quyết định mức thực tế của từng tổ chức

• Số lượng component và token (biến thiết kế): hệ thống càng lớn, chi phí duy trì từng phần càng tăng tuyến tính.
• Tốc độ thay đổi sản phẩm: sản phẩm thay đổi nhanh đồng nghĩa design system cần cập nhật thường xuyên hơn. Đây là yếu tố có ảnh hưởng lớn nhất.
• Số lượng nền tảng cần đồng bộ: web, iOS, Android, hay thêm các kênh khác đều nhân chi phí lên tương ứng.
• Năng lực đội nội bộ: nếu phía khách có người đủ năng lực xử lý phần kỹ thuật thường ngày, chi phí thuê ngoài giảm đáng kể. Ngược lại, nếu toàn bộ phụ thuộc vào đối tác bên ngoài, chi phí sẽ cao hơn và dễ bị gián đoạn.
• Cam kết accessibility (khả năng tiếp cận): tổ chức có yêu cầu WCAG bắt buộc cần ngân sách re-audit định kỳ, đặc biệt sau mỗi lần trình duyệt lớn ra bản cập nhật ảnh hưởng đến hành vi của assistive technology.

Dấu hiệu ngân sách bảo trì đang thiếu

Thay vì chờ đến lúc hệ thống hỏng mới phát hiện, Anh Chị có thể nhìn vào các dấu hiệu sau:

• Component bị override (ghi đè) ở nhiều nơi trong codebase thay vì được cập nhật tại nguồn gốc.
• Token (biến thiết kế) trong file Figma và trong code đang lệch nhau, team thiết kế và team kỹ thuật dùng giá trị khác nhau.
• Version của thư viện chính không được nâng cấp trong nhiều tháng liên tiếp.
• Các component mới được xây ngoài hệ thống thay vì được đưa vào hệ thống.

Khi những dấu hiệu này xuất hiện cùng lúc, chi phí "bắt kịp" thường cao hơn nhiều so với chi phí bảo trì đều đặn từ đầu.

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

Sinh Vũ không đưa ra một con số tỷ lệ phần trăm cố định vì con số đó có thể gây hiểu nhầm theo cả hai chiều: quá thấp dẫn đến hệ thống bị bỏ bê, quá cao khiến Anh Chị chi tiền vào việc không cần thiết ở giai đoạn này.

Trong buổi tư vấn, Sinh Vũ thường đi qua danh sách cụ thể cùng khách: có bao nhiêu component cần theo dõi, tần suất cập nhật dự kiến trong năm tới là gì, ai làm phần nào ở phía khách và phần nào Sinh Vũ hỗ trợ. Từ danh sách đó, tính giờ công và ra chi phí thực tế. Quy trình này mất nhiều thời gian hơn so với áp tỷ lệ phần trăm, nhưng kết quả minh bạch và Anh Chị ra quyết định có cơ sở thay vì đoán mò.