
Ngày bàn giao nghe như vạch đích, nhưng với phần mềm nó giống tiếng súng xuất phát hơn. Trước đó hệ thống chỉ được thử bởi vài người và vài tình huống đã tính trước. Sau đó là dữ liệu thật, người dùng thật và những cách dùng chẳng ai nghĩ ra. Câu hỏi lúc này không còn là phần mềm đã xong chưa, mà là ai chăm nó và theo thỏa thuận nào.
Một chữ "bảo trì", bốn loại việc
Chữ này gom quá nhiều thứ, và đó là chỗ nảy sinh hiểu lầm. Sửa lỗi là chỉnh những chỗ phần mềm chạy sai so với thiết kế đã thống nhất. Cập nhật kỹ thuật là nâng thư viện, hệ điều hành, vá lỗ hổng để hệ thống tiếp tục chạy ổn và an toàn. Vận hành là theo dõi, sao lưu, xử lý khi máy chủ gặp sự cố. Còn cải tiến là thêm hoặc đổi tính năng vì doanh nghiệp có nhu cầu mới.
Bốn loại này khác nhau về bản chất và cách tính tiền. Sửa lỗi trong phạm vi đã nghiệm thu thường nằm trong bảo hành. Tính năng mới gần như luôn là việc phát sinh có phạm vi riêng. Trộn chúng lại là cách nhanh nhất để hai bên cãi nhau vào tháng thứ ba.

Bảo hành không phải bảo trì
Bảo hành thường là khoảng thời gian sau bàn giao mà đơn vị thực hiện sửa miễn phí những lỗi thuộc phạm vi đã nghiệm thu. Bảo trì là thỏa thuận tiếp theo, hay có phí, để giữ hệ thống sống lâu. Không có định nghĩa chung. Mỗi hợp đồng ghi một kiểu, nên điều khoản mới là thứ cần đọc, còn tên gọi thì không đáng tin.
Đọc kỹ ba chỗ. Bảo hành kéo dài bao lâu và tính từ ngày nào. Lỗi thế nào thì được coi là thuộc bảo hành, và cái gì bị loại trừ, chẳng hạn lỗi do bạn tự thay đổi hoặc do dịch vụ bên thứ ba. Và khi hết bảo hành, bạn còn những đường nào để đi tiếp.
Thỏa thuận bảo trì tốt trông ra sao
Nó nói rõ phạm vi công việc, cách gửi yêu cầu, mức ưu tiên và thời gian phản hồi mong đợi cho từng mức, cùng cách tính phí. Có một đầu mối ở mỗi bên, một kênh liên lạc chính thức, và một cách xử lý sự cố gấp ngoài giờ nếu doanh nghiệp cần.
Cũng cần một câu về thay đổi yêu cầu: khi có tính năng mới, bên thực hiện ước lượng và báo tr��ớc, bạn đồng ý rồi mới làm. Chỉ cần giữ thứ tự ấy là tránh được phần lớn khoản phí gây bất ngờ. Cách tính chi phí nói chung được phân tích trong bài chi phí làm web app và phần mềm nội bộ gồm những khoản nào.
Một thói quen nhỏ giúp thỏa thuận bảo trì khỏi thành giấy tờ cất tủ: mỗi quý ngồi lại nửa giờ với đơn vị thực hiện, xem lại những yêu cầu đã xử lý, những lỗi lặp lại, những cập nhật đang chờ và những thay đổi doanh nghiệp sắp cần. Cuộc họp ngắn này thường lộ ra sớm những việc nếu để lâu sẽ thành nợ kỹ thuật, và cho cả hai bên cơ hội điều chỉnh phạm vi trước khi phát sinh tranh cãi. Ghi biên bản vài dòng cũng đủ, miễn là có.
Của ai là mã nguồn, tên miền và tài khoản máy chủ?
Hỏi điều này lúc ký hợp đồng thì dễ, hỏi lúc chia tay thì khó. Hãy thống nhất ai sở hữu mã nguồn, ai đứng tên tài khoản hạ tầng và tên miền, và có được bàn giao tài liệu kỹ thuật, hướng dẫn cài đặt, thông tin cấu hình không. Bài thuê ngoài làm website và phần mềm: checklist cho doanh nghiệp đi sâu hơn vào những điểm này khi chọn đơn vị.
Không phải ai cũng muốn tự giữ mọi thứ. Nhưng khả năng chuyển giao giống một loại bảo hiểm. Hệ thống mà chỉ một nơi hiểu được sẽ khiến bạn yếu thế ngay khi muốn đổi nhà cung cấp.

Biết hệ thống ổn trước khi người dùng kêu
Khi hệ thống chạy thật, bạn cần biết nó còn khỏe không trước khi có ai phàn nàn. Theo dõi cơ bản gồm xem hệ thống còn sống không, thời gian phản hồi, dung lượng lưu trữ và các lỗi được ghi. Hãy chốt ai nhận cảnh báo và việc đầu tiên họ làm là gì. Nếu người nhận duy nhất là một cá nhân, hãy có thêm người dự phòng, vì cảnh báo gửi đến người đang nghỉ phép cũng giống như không gửi.
Sao lưu cũng thuộc phần này. Có lịch sao lưu, bản sao lưu để ở nơi tách biệt, và có người đã thử khôi phục thật. Những khuyến nghị cơ bản như trong bài bảo mật cơ bản cho web app doanh nghiệp cần được giữ sau bàn giao, chứ không chỉ lúc đang phát triển.
Nâng cấp nhỏ đều đặn rẻ hơn nâng cấp lớn muộn
Phần mềm đứng trên thư viện và nền tảng có vòng đời riêng. Khi một phiên bản hết được hỗ trợ thì lỗ hổng mới sẽ không còn được vá, và việc nâng cấp càng để lâu càng khó. Làm từng bước nhỏ theo nhịp đều thường ít rủi ro hơn dồn lại vài năm rồi nâng một lần.
Nợ kỹ thuật là những đường tắt trong mã nguồn giúp xong nhanh lúc đầu nhưng làm mọi thay đổi sau đó chậm hơn. Có khoản đáng vay để ra mắt sớm. Điều quan trọng là ghi nó lại và có kế hoạch trả dần trong thời gian bảo trì.
Lúc nào thì nên làm lại
Có vài dấu hiệu đáng để nghĩ nghiêm túc: sửa nhỏ nào cũng tốn nhiều công và sinh lỗi mới, nền tảng đã hết hỗ trợ, hệ thống không còn theo kịp cách doanh nghiệp làm việc, hoặc không ai còn hiểu mã nguồn. Làm lại hoàn toàn là quyết định đắt, nên hãy kiểm tra xem nâng cấp từng phần hay dọn dẹp đã giải quyết được chưa.
So chi phí giữ hệ thống hiện tại với chi phí thay thế, đừng quên khoản chuyển dữ liệu cũ sang. Một đơn vị đáng tin sẽ cho bạn thấy cả hai phương án chứ không chỉ đề xuất làm mới.

Nếu bạn đang cân nhắc một hệ thống mới, hoặc muốn có người đọc lại điều khoản bảo trì của hệ thống đang chạy, F2C Labs sẵn lòng trao đổi. Hãy xem phần dịch vụ phát triển web app và hệ thống quản trị hoặc gửi vài dòng về nhu cầu của bạn.
- [1] OWASP Top 10: các rủi ro bảo mật phổ biến của ứng dụng webowasp.org
- [2] Google: tạo nội dung hữu ích, đáng tin cậydevelopers.google.com
Bảo hành thường kéo dài bao lâu?
Không có mức chung, mỗi hợp đồng ghi riêng. Điều cần hỏi là thời hạn tính từ ngày nào, lỗi nào thuộc phạm vi và cái gì bị loại trừ.
Sửa lỗi và thêm tính năng khác nhau thế nào?
Sửa lỗi là chỉnh chỗ phần mềm chạy sai so với thiết kế đã nghiệm thu. Thêm tính năng là yêu cầu mới có phạm vi và ước lượng riêng.
Tôi có cần nắm mã nguồn không?
Không phải ai cũng cần tự giữ, nhưng nên thống nhất rõ quyền sở hữu và có tài liệu bàn giao để khi cần vẫn chuyển giao được.

Founder & CEO
Founder & CEO @ F2C Labs



