Chuyên môn · Quản trị và vận hành lâu dài

Chi phí bảo trì design system: tính thế nào

Bảo trì không phải tùy chọn vì hệ thiết kế là sản phẩm sống, không phải dự án giao một lần rồi thôi.

Chốt nhanh

Sinh Vũ định mức bảo trì khoảng 15 đến 30% phí dự án mỗi năm, mức cụ thể tùy quy mô hệ và số đội dùng chung. Đây là khung của Sinh Vũ, không phải chuẩn thị trường phổ quát, và luôn được chốt qua tư vấn theo phạm vi thật. Điều quan trọng hơn con số là đặt sẵn dòng ngân sách này từ đầu dự án, vì một hệ không có khoản bảo trì sẽ loãng nhanh và chi phí thật là các đội phải tự làm lại từ đầu.

Đối sánh nhanh
Nên chọn hướng này khi
  • nhiều đội dùng chung, hệ còn lớn nhanh, phủ đa nền tảng (mức cao)
  • đặt sẵn dòng ngân sách bảo trì từ đầu, không coi là khoản phát sinh
Chưa cần khi
  • không đặt dòng ngân sách bảo trì nào, coi là xong hẳn
  • so chi phí bảo trì với con số 0 thay vì so với chi phí loãng

Bảo trì design system (hệ thiết kế số) không phải khoản phát sinh ngoài dự toán. Đây là chi phí vận hành định kỳ cần được đặt sẵn từ lúc quyết định xây hệ, bởi hệ là sản phẩm sống, không phải tài liệu giao một lần rồi để đó.

Khung tính của Sinh Vũ

Trong mô hình dịch vụ của Sinh Vũ, mức bảo trì được định ở khoảng 15 đến 30% phí dự án mỗi năm. Con số này bao gồm các bản nâng cấp định kỳ, rà soát hàng quý và hỗ trợ các đội khi có vướng mắc trong quá trình dùng chung.

Sinh Vũ nói thẳng: đây là khung của Sinh Vũ, không phải mức chuẩn thị trường phổ quát. Mức cụ thể luôn được chốt qua tư vấn theo phạm vi thật của từng hệ, vì chênh lệch giữa hệ nhỏ và hệ lớn rất đáng kể.

Các yếu tố quyết định mức

Anh Chị không cần nhớ một con số, mà cần hiểu những gì đẩy chi phí lên hoặc kéo xuống:

  • Quy mô hệ: số component (thành phần giao diện), số token (biến thiết kế dùng chung) và số nền tảng phủ. Hệ càng lớn, công bảo trì càng nhiều.
  • Số đội và sản phẩm phụ thuộc: mỗi đội dùng hệ là thêm một nguồn câu hỏi, yêu cầu và xung đột cần xử lý. Nhiều đội đồng nghĩa với nhiều việc điều phối.
  • Mức đóng góp từ bên ngoài: nếu các đội được phép đóng góp component ngược lại vào hệ chung thì cần người duyệt và giữ chất lượng. Đóng góp nhiều thì công duyệt nhiều.
  • Nhịp thay đổi của sản phẩm và nền tảng nền: khi khung lập trình hoặc trình duyệt cập nhật lớn, hệ cần được kiểm tra và điều chỉnh theo.
  • Chi phí không chỉ là tiền: bảo trì còn là thời gian của người sở hữu nội bộ. Nếu doanh nghiệp không có người được phân công giữ hệ, chi phí thật sẽ nằm ở sự loãng dần của hệ.

Khi nào nghiêng về mức cao, khi nào mức thấp

Nghiêng về mức cao (gần 30%): nhiều đội dùng chung, hệ đang còn lớn nhanh, phủ đa nền tảng, có đóng góp từ ngoài cần duyệt thường xuyên, sản phẩm thay đổi nhanh.

Nghiêng về mức thấp (gần 15%): hệ đã ổn định, ít đội dùng, ít thay đổi về thiết kế lẫn công nghệ, không có đóng góp ngược từ các đội khác.

Nếu Anh Chị tiếp tục làm việc với cùng một đơn vị qua nhiều năm, có thể xem xét ghép khoản bảo trì vào gói hợp tác lớn hơn hoặc khấu trừ vào dự án tiếp theo, tùy thỏa thuận cụ thể.

Lỗi thường gặp khi tính ngân sách

  • Không đặt dòng bảo trì nào: coi hệ là dự án giao xong là hết. Đây là lỗi phổ biến nhất. Kết quả là hệ loãng dần trong im lặng, đến lúc nhận ra thì chi phí làm lại đã lớn hơn rất nhiều.
  • So chi phí bảo trì với con số 0: thay vì so với chi phí thật khi mỗi đội tự xây lại riêng. Bảo trì hệ chung luôn rẻ hơn nhiều đội mỗi đội tự duy trì một phiên bản riêng.
  • Đòi một con số cố định cho mọi hệ: không có mức bảo trì đúng cho mọi trường hợp, vì nó phụ thuộc vào quy mô và số đội dùng chung. Số không gắn với phạm vi thật là số không đáng tin.

Hệ thiết kế cần được đối xử như sản phẩm: được cấp ngân sách, được phân công người sở hữu và được chăm sóc liên tục. Thiếu bảo trì, hỗ trợ và chăm sóc, hệ sẽ thoái hóa và việc bảo trì rơi vào vá víu tạm bợ.

Brad Frost, Atomic Design, chương 5

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

Sinh Vũ coi khoản bảo trì không phải là phí duy trì hình thức mà là khoản để hệ không loãng. Một hệ loãng thì về mặt kỹ thuật vẫn còn đó, nhưng các đội đã ngừng tin tưởng và bắt đầu tự làm riêng. Lúc đó doanh nghiệp không phải đang tiết kiệm phí bảo trì, mà đang trả giá gấp nhiều lần dưới dạng công sức trùng lặp và thiết kế không đồng nhất.

Khoản 15 đến 30% mỗi năm nghe có vẻ lớn khi so với con số 0. Nhưng khi so với chi phí mỗi đội tự duy trì phiên bản riêng, đây thường là con số hợp lý hơn nhiều. Bài toán đúng không phải là "bảo trì tốn bao nhiêu?" mà là "nếu không bảo trì, chi phí thật là gì?"

Công cụ mang về

Checklist quyết định

Chủ đề: Chi phí bảo trì design system hàng năm bao nhiêu là hợp lý. Cẩm nang Sinh Vũ, sinhvu.com

0 trên 5 mục

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.

Dấu hiệu cho thấy Anh / Chị nên làm
Câu hỏi cần trả lời trước khi quyết định

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

Brad Frost, The Design System Ecosystem; Brad Frost, Atomic Design, chương 5; Sinh Vũ, khung dịch vụ A3 Hệ thiết kế số (nội bộ).

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

Tại sao không thể báo một con số cố định cho mọi hệ?

Vì bảo trì phụ thuộc trực tiếp vào quy mô hệ, số đội dùng chung và nhịp thay đổi của sản phẩm. Hệ 5 đội dùng chung trên 3 nền tảng sẽ tốn công gấp nhiều lần hệ 1 đội dùng ổn định. Báo một con số cố định mà không biết phạm vi thật là báo không trung thực.

Nếu năm đầu không có ngân sách bảo trì, hệ có hỏng ngay không?

Không hỏng ngay, nhưng sẽ bắt đầu loãng. Các đội sẽ tự điều chỉnh component theo nhu cầu riêng mà không có người duyệt, tài liệu sẽ lạc hậu so với thực tế, và đến lúc muốn đồng bộ lại thì chi phí thường lớn hơn nhiều so với bảo trì đều đặn từ đầu.

← Về Hệ thiết kế số
{INJ}