Chi Phí Bảo Trì Phần Mềm: Khoản Không Ai Dự Trù

Chi phí bảo trì phần mềm là con số biến một dự án thành công thành cuộc trò chuyện khó khăn mười tám tháng sau đó. Phần xây dựng đã được lập ngân sách, phê duyệt và bàn giao. Còn những gì xảy ra sau khi hệ thống lên sóng thì được gọi gọn là “hỗ trợ” và gán cho một con số ai đó đoán ra, và con số ấy gần như luôn quá nhỏ.

Nguyên nhân nằm ở cấu trúc chứ không phải ở sự cẩu thả. Một dự án xây dựng có phạm vi để định giá. Bảo trì thì không có phạm vi, bởi nó được định nghĩa bằng những việc chưa xảy ra: một thư viện lộ ra lỗ hổng, một nhà cung cấp thay đổi API, một người dùng rơi vào tình huống không ai lường trước.

Quy tắc kinh nghiệm mà ai cũng nhắc là 15 đến 20 phần trăm chi phí xây dựng mỗi năm, và nó đúng vừa đủ để trở nên nguy hiểm. Nó trúng đủ nhiều lần để tạo cảm giác an toàn, và sai theo một hướng có thể đoán trước: nó đếm thiếu năm đầu tiên, giai đoạn các lỗi lộ diện, và sụp đổ hoàn toàn với những hệ thống có nghĩa vụ tuân thủ hoặc nhiều tích hợp bên thứ ba, nơi công việc bị thúc đẩy bởi các sự kiện bên ngoài chứ không phải bởi mã nguồn của bạn.

Chi phí bảo trì phần mềm thực sự bao gồm những gì

Năm nhóm việc tách bạch, và chính việc trộn lẫn chúng lại với nhau tạo ra con số sai.

Công việc sửa lỗi. Khắc phục các khiếm khuyết. Nhóm này dồn về giai đoạn đầu, vì phần lớn lỗi lộ ra trong những tháng sử dụng thực tế đầu tiên, và đây cũng là nhóm mà quy tắc phần trăm mô tả sát nhất.

Công việc thích ứng. Chạy theo những thứ nằm ngoài tầm kiểm soát của bạn. Một thư viện phụ thuộc phát hành bản vá bảo mật. Một nhà cung cấp thanh toán khai tử một phiên bản API. Một trình duyệt đổi cách hành xử. Không việc nào trong số đó thêm tính năng, và tất cả đều bắt buộc.

Công việc phòng ngừa. Nâng cấp trước khi bị buộc phải làm. Bỏ qua nó không xóa được chi phí, chỉ dời lại và cộng dồn, và đó là cách một lần nâng cấp framework thông thường biến thành dự án ba tháng.

Vận hành thường ngày. Hạ tầng lưu trữ, giám sát, sao lưu, chứng chỉ, và thời gian của con người để theo dõi chúng. Thường được hạch toán riêng, điều đó không sao cả miễn là có ai đó hạch toán.

Những thay đổi nhỏ. Dòng chảy đều đặn các điều chỉnh mà một hệ thống đang chạy sinh ra ngay khi có người dùng thật. Từng cái một thì không đáng kể, gộp lại thì là nhóm lớn nhất trong hầu hết các năm.

Chỉ nhóm đầu tiên mới là thứ người ta thường gọi là bảo trì. Bốn nhóm còn lại là lý do ngân sách cạn kiệt.

Vì sao quy tắc phần trăm gây hiểu lầm

Nó neo vào đại lượng sai. Công sức bảo trì đi theo số lượng bộ phận chuyển động và tốc độ mà thế giới bên ngoài thay đổi chúng, chứ không theo số tiền dự án xây dựng tình cờ tiêu tốn.

Hai hệ thống làm ra với cùng số tiền có thể chênh nhau ba lần. Một ứng dụng khép kín với hai thư viện phụ thuộc và không chịu ràng buộc pháp lý thì rẻ để duy trì. Một hệ thống tích hợp sáu dịch vụ bên thứ ba, xử lý dữ liệu cá nhân và chịu quy định ngành thì không, bởi mỗi tích hợp ấy là một nguồn công việc mà bạn không tự lên lịch được.

Tỷ lệ phần trăm còn giả định một trạng thái ổn định vốn không tồn tại trong năm đầu. Việc sử dụng thật sẽ tìm ra lỗi, và sáu tháng đầu sau khi ra mắt thường cao hơn hẳn mức trung bình năm trước khi mọi thứ lắng xuống.

Một ước tính tốt hơn bắt đầu từ các bộ phận chuyển động. Hãy đếm số tích hợp, các nghĩa vụ tuân thủ và số người dùng tạo ra yêu cầu hỗ trợ, rồi định giá khoảng thời gian mà chúng thực sự ngốn mất. Hướng dẫn về chi phí phát triển phần mềm đặt riêng của chúng tôi bàn về vế xây dựng của cùng phép tính này.

Những khoản mục các đội hay bỏ quên

Nâng cấp thư viện phụ thuộc. Không phải tùy chọn, vì thư viện chưa vá là con đường mà hệ thống bị xâm nhập, và khối lượng việc thì thật sự khó đoán bởi nó phụ thuộc vào việc người bảo trì thượng nguồn làm gì.

Thay đổi ở API bên thứ ba. Một nhà cung cấp khai tử một phiên bản và đưa cho bạn một hạn chót. Bạn không chọn thời điểm ấy và cũng không thể từ chối.

Gia hạn chứng chỉ và tên miền. Chuyện vặt, cho đến khi một cái hết hạn vào cuối tuần và trang web ngừng hoạt động.

Giám sát và việc phản hồi cảnh báo. Cảnh báo vô dụng nếu không có người phản ứng, và sự sẵn sàng đó là chi phí thật, dù có hỏng hóc gì hay không.

Chuyển giao tri thức. Người ta sẽ rời đi. Cái giá để người tiếp theo hiểu được hệ thống là một khoản chi phí bảo trì, và nó tỷ lệ thuận với mức độ ít ỏi của những gì đã được ghi chép lại.

Dữ liệu phình to. Chi phí lưu trữ tăng, những truy vấn từng nhanh trở nên chậm, và công việc xử lý chuyện đó đến theo lịch do chính thành công của bạn đặt ra. Hướng dẫn về hiệu năng cơ sở dữ liệu của chúng tôi cho thấy điều đó trông ra sao trong thực tế.

Chi phí này ở Anh là bao nhiêu

Các khoảng chi phí hằng năm ước chừng để bảo trì một hệ thống đặt riêng, giả định thuê nhà cung cấp bên ngoài thay vì nhân sự nội bộ.

Các con số này chưa gồm hạ tầng lưu trữ và giấy phép, vốn được tính riêng và dao động rất mạnh. Chúng cũng giả định hệ thống đang ở tình trạng chấp nhận được. Bảo trì một thứ không ai viết tài liệu, không có kiểm thử và chỉ một người hiểu, sẽ tốn hơn và mang theo rủi ro mà không hợp đồng trọn gói nào xóa được.

Nên cấu trúc thỏa thuận thế nào

Hợp đồng trọn gói với số giờ đã định phù hợp khi khối lượng công việc tương đối dự đoán được. Nó mua sự sẵn sàng, tức phần lớn thứ bạn trả tiền, và số giờ không dùng đến không lãng phí, vì phương án còn lại là không có ai.

Tính theo thời gian và vật liệu hợp với những hệ thống ít thay đổi, nhưng thời gian phản hồi phụ thuộc vào các cam kết khác của nhà cung cấp, và đó là cái giá phải đánh đổi.

Hợp đồng hỗ trợ giá cố định chuyển rủi ro sang nhà cung cấp, và họ tính rủi ro đó vào phí. Hợp lý với các hệ thống trọng yếu, nơi tính dự đoán được đáng giá hơn phần lợi nhuận.

Dù chọn cách nào, hãy thống nhất thế nào là bảo trì và thế nào là tính năng mới trước khi bạn cần đến. Ranh giới ấy là nguồn cơn của gần như mọi tranh chấp trong quan hệ hỗ trợ, và định nghĩa nó ngay từ đầu thì không tốn gì.

Mecanik bảo trì cả hệ thống do chúng tôi xây dựng lẫn hệ thống của người khác, như một phần công việc phát triển phần mềm . Tháng đầu tiên của bất kỳ đợt tiếp nhận nào thường dành cho tài liệu, bởi chính nó quyết định chi phí của mọi tháng sau đó.

Bài liên quan: Hợp đồng giá cố định hay theo thời gian và vật liệu? , Cách viết hồ sơ mời thầu phần mềm để nhận báo giá hữu ích , Ký quỹ mã nguồn: ai thực sự cần đến và Phát triển MVP: phạm vi, chi phí và tiến độ .

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

Chi phí bảo trì phần mềm mỗi năm là bao nhiêu? Quy tắc kinh nghiệm phổ biến là 15 đến 20 phần trăm chi phí xây dựng mỗi năm, nhưng nó đếm thiếu năm đầu tiên khi các lỗi lộ diện và hỏng hoàn toàn với những hệ thống nhiều tích hợp hoặc có nghĩa vụ tuân thủ. Các khoảng ước chừng tại Anh chạy từ £6.000 đến £15.000 cho một công cụ nội bộ nhỏ, lên tới £60.000 hoặc hơn cho một nền tảng bị quản lý chặt hay có lưu lượng lớn, chưa gồm hạ tầng lưu trữ.

Bảo trì phần mềm thực sự gồm những gì? Năm nhóm: sửa lỗi để khắc phục khiếm khuyết, thích ứng để chạy theo thay đổi của thư viện phụ thuộc và API bên thứ ba, phòng ngừa để nâng cấp trước khi bị buộc phải làm, vận hành thường ngày như hạ tầng lưu trữ và giám sát, cùng dòng chảy đều đặn các thay đổi nhỏ mà hệ thống đang chạy sinh ra. Chỉ nhóm đầu tiên mới là thứ đa số người ta gọi là bảo trì.

Vì sao quy tắc lấy phần trăm chi phí xây dựng lại không đáng tin? Nó neo vào đại lượng sai. Công sức bảo trì đi theo số bộ phận chuyển động và tốc độ thế giới bên ngoài thay đổi chúng, chứ không theo giá xây dựng. Hai hệ thống làm ra với cùng số tiền có thể chênh nhau ba lần tùy số lượng tích hợp, mức ràng buộc pháp lý và lượng yêu cầu hỗ trợ.

Các đội hay quên đưa chi phí bảo trì nào vào ngân sách? Nâng cấp thư viện phụ thuộc, các API bên thứ ba bị khai tử kèm hạn chót mà bạn không chọn, gia hạn chứng chỉ và tên miền, sự sẵn sàng của con người phía sau các cảnh báo giám sát, chuyển giao tri thức khi người ta rời đi, và tác động của dữ liệu phình to lên chi phí lưu trữ cùng tốc độ truy vấn.

Nên chọn hợp đồng trọn gói hay trả theo nhu cầu? Hợp đồng trọn gói với số giờ đã định hợp với khối lượng dự đoán được và mua lấy sự sẵn sàng, tức phần lớn thứ bạn đang trả tiền. Tính theo thời gian và vật liệu hợp với hệ thống ít thay đổi, nhưng thời gian phản hồi phụ thuộc vào các cam kết khác của nhà cung cấp. Dù chọn cách nào, hãy định nghĩa thế nào là bảo trì và thế nào là tính năng mới trước khi bạn cần đến.