Chi phí nền của phần mềm
Khi làm product, có một thói quen là chúng ta dành nhiều thời gian cho việc thêm tính năng mà quên rằng mỗi tính năng thêm vào đều có một chi phí bảo trì ngầm đi kèm.
“Basal Cost” – Chi phí duy trì ngầm của phần mềm
Khái niệm này được Eferro — một product dev, giới thiệu. Đây là chi phí liên tục phát sinh sau khi một tính năng được triển khai lần đầu đến người dùng.
Giống như cơ thể con người tiêu tốn năng lượng để duy trì sự sống, phần mềm cũng tiêu tốn tài nguyên để duy trì các tính năng hiện có, ngay cả khi không có thay đổi nào được thực hiện.
Chi phí này bao gồm:
Tăng độ phức tạp của hệ thống, khiến việc hiểu và bảo trì trở nên khó khăn hơn.
Ảnh hưởng đến việc phát triển các tính năng mới, do phải đảm bảo tính tương thích và tránh gây lỗi cho các phần hiện có.
Chi phí đào tạo và truyền đạt kiến thức cho các thành viên mới trong nhóm.
Timeline chi phí của một tính năng
f1: Chi phí ban đầu để tạo tính năng.
Lớp trên: Chi phí ngầm của tính năng mới được thêm vào.
Lớp dưới: Chi phí ngầm của các tính năng trước đó.
Đường nét đứt dọc: Thời điểm công nghệ của tính năng trở nên lỗi thời, khó bảo trì
Sự hiểu nhầm tai hại
Một sai lầm phổ biến là việc thiếu cân nhắc chi phí bảo trì về sau, mà cứ mặc định là nếu không sửa gì thêm thì ko tốn chi phí. Không phải như vậy.
Hệ quả
1. Team giảm dần dư địa nguồn lực để phát triển tính năng mới (vì phải phân bổ thêm cho việc bảo trì)
2. Thậm chí sẽ tới lúc việc bảo trì chiếm gần hết nguồn lực, ko có nguồn lực để tạo những tính năng mới cho người dùng.
3. Hoặc lúc đó team phải giảm tốc độ tạo tính năng mới, do phải tiêu tốn nhiều vào chi phí nền.
Giải pháp
1. Tối thiểu hoá chi phí ngầm này ← Kỹ sư
Nếu có thể, hãy cố gắng giải quyết được vấn đề mà không cần phải viết thêm code. Hãy tự đặt các câu hỏi trước khi làm:
Nó có thật sự cần thiết không? Nếu không có nó thì sao?
Liệu có thể giải quyết vấn đề mà không cần code không?
Khi thêm vào, có làm hệ thống phức tạp thêm nhiều không?
Sau 3 tháng, tính năng này có thể sẽ gây ra vấn đề bảo trì gì không? v.v.
Sửa lại tính năng để phù hợp tối đa với nhu cầu thực tế của người dùng, và luôn giữ giải pháp ở mức tối giản.
Thiết kế và code nên càng đơn giản càng tốt. Hệ thống cần dễ dàng mở rộng khi cần mà không bị thiết kế quá phức tạp ngay từ đầu (tuân theo nguyên tắc YAGNI).
2. Theo dõi liên tục mã nguồn sản phẩm để phát hiện các thư viện, ngôn ngữ hoặc công nghệ lỗi thời để xử lý sớm (nếu ko chi phí sẽ đột ngột tăng mạnh) ← Kỹ sư, CTO
Nếu có thư viện nào đã ko còn được bảo trì, nên tìm cách thay thế sớm.
3. Ngăn chặn việc đưa các tính năng ít giá trị vào sản phẩm hoặc xoá bỏ các tính năng ko còn phù hợp ra khỏi sản phẩm ← Product Manager, CTO
Nguồn tham khảo: https://www.eferro.net/2021/02/basal-cost-of-software.html