Nợ kỹ thuật của customization: hóa đơn tới sau go-live

Danh sách đó gần như không xuất hiện trong bất kỳ buổi trình bày giải pháp nào, và đó là chỗ bài này muốn nói tới.

Vì sao hóa đơn tới muộn

Cấu trúc của vấn đề rất đơn giản, nhưng chính vì đơn giản mà nó dễ bị bỏ qua.

Chi phí của một hạng mục customize được ghi nhận đúng một lần, vào lúc báo giá, và nó xuất hiện ở chỗ mà mọi người đang chú ý. Trong khi đó, chi phí thật của hạng mục ấy phát sinh nhiều lần, ở những thời điểm cách xa nhau, và ở những chỗ mà lúc ký hợp đồng chưa ai nghĩ tới.

Do đó câu hỏi nên thay thế câu hỏi quen thuộc là thế này.

Đừng hỏi hạng mục này tốn bao nhiêu, hãy hỏi mỗi lần nâng cấp nó tốn thêm bao nhiêu, và trong ba năm tới có mấy lần nâng cấp.

Câu hỏi đó nghe khó trả lời, nhưng vế thứ hai của nó thì tra được, và tra được chính xác tới từng tháng.

Lịch trả nợ có ngày tháng

Đây là chỗ biến nợ kỹ thuật từ một khái niệm mơ hồ thành một lịch trả nợ có ngày tháng.

Mỗi phiên bản chính của Odoo chỉ được hỗ trợ tiêu chuẩn trong một số năm cố định, hết hạn đó thì phải trả thêm phí và không còn cam kết cập nhật bảo mật; các mốc cụ thể và lịch nâng cấp bắt buộc của từng nền tảng thì tôi đã nói riêng ở bài về vòng đời phiên bản.

Từ hai chi tiết đó suy ra một điều rất thực tế: nâng cấp không phải là chuyện làm khi rảnh, nó là chuyện phải làm trước một mốc thời gian. Doanh nghiệp nào cũng có quyền chọn ở lại phiên bản cũ, nhưng chọn như vậy nghĩa là chấp nhận trả thêm phí và chấp nhận không còn cam kết về bản vá bảo mật, và đó là một quyết định nên được đưa ra có ý thức chứ không phải bị đẩy vào.

Đồng thời còn một quy tắc nữa cần biết khi lập kế hoạch, đó là bạn chỉ nâng cấp lên được những phiên bản còn trong thời gian hỗ trợ. Để hệ thống tụt lại quá xa thì chặng nhảy trở nên dài hơn và đắt hơn, chứ không phải là hoãn được mãi.

Vì vậy khi bạn ngồi trước một hạng mục customize và tự hỏi nó tốn bao nhiêu, hãy nhân con số bảo trì của nó với số lần nâng cấp trong vòng đời mà doanh nghiệp dự định dùng hệ thống.

Đó mới là con số đang được quyết định.

Thang chi phí mang vác theo loại hạng mục

Đây là phần mà tôi thấy nội dung về nợ kỹ thuật hay nói thiếu, và nói thiếu thì dẫn tới một kết luận sai là đừng customize gì cả.

Chi phí mang vác của một hạng mục phụ thuộc vào việc nó đứng cạnh hệ thống hay đứng chen vào giữa hệ thống. Thang dưới đây là cách tôi tự xếp để trao đổi với khách, chứ không phải một chuẩn có sẵn, và nó đi theo mức độ can thiệp tăng dần.

Theo những gì tôi quan sát được thì hai hàng cuối chiếm phần lớn chi phí nâng cấp, trong khi chúng thường chỉ là một phần nhỏ trong danh sách hạng mục. Do đó việc đáng làm không phải là cắt hết mọi tùy biến, mà là nhận diện đúng hai hàng đó rồi hỏi kỹ hơn về chúng.

Cần lưu ý thêm một điều kiện làm đảo lộn cả bảng này. Nếu dự án đã có ít nhất một yêu cầu bắt buộc phải viết code thì những hạng mục ở hai hàng đầu cũng không còn rẻ nữa, bởi khi đó chúng phải được làm bằng code chứ không được làm bằng công cụ kéo thả; lý do của ràng buộc đó tôi đã nói ở bài về nguyên tắc bàn giao mã nguồn.

Ba thứ làm chi phí mang vác tăng lên

Ngoài loại hạng mục thì còn ba yếu tố nữa, và cả ba đều thuộc quyền quyết định của bạn ở giai đoạn thiết kế.

Yếu tố đầu tiên là số điểm chạm vào lõi. Một hạng mục thay đổi hành vi ở đúng một chỗ thì lần nâng cấp nào cũng chỉ phải kiểm một chỗ, còn một hạng mục len vào nhiều chỗ khác nhau thì mỗi lần nâng cấp là bấy nhiêu lần kiểm, và xác suất có ít nhất một chỗ đã đổi tăng theo số điểm chạm chứ không đứng yên. Do đó khi có hai cách làm cho cùng một yêu cầu, cách chạm vào ít chỗ hơn gần như luôn là cách đúng, kể cả khi nó tốn thêm chút thời gian ban đầu.

Bên cạnh đó là phụ thuộc bên ngoài. Mỗi tích hợp là một cam kết dài hạn với lịch phát hành của một bên mà bạn không kiểm soát, và mỗi module tải về từ bên thứ ba là một cam kết với việc người viết nó có tiếp tục cập nhật hay không. Cần lưu ý rằng phần rủi ro này không nằm ở chất lượng code mà nằm ở chuyện ai còn duy trì nó sau vài năm nữa.

Và đặc biệt, thứ ít ai tính vào nhất là những thay đổi không có đường lùi. Trong công cụ kéo thả của Odoo, một đối tượng dữ liệu đã tạo ra thì không xóa đi được nữa, còn một phân hệ tạo bằng chính công cụ đó thì lại xóa được vì nó thực chất chỉ là một menu; bất đối xứng đó tôi đã nói kỹ ở bài về ranh giới cấu hình và customize, và điều đáng nhớ ở đây chỉ là một lần thử nghiệm trên hệ thống thật có thể để lại vết vĩnh viễn, nên thử nghiệm phải làm trên bản sao.

Bằng chứng từ cộng đồng

Nhóm thứ nhất là các thread về hiệu năng trên diễn đàn chính thức của Odoo, trong đó nhiều thread xuất hiện ngay sau một lần nâng cấp; trong một thread bàn về việc hệ thống có chậm sẵn hay không, nhận định nổi lên là các module tùy biến có thể ảnh hưởng rất nhiều tới hiệu năng nếu không được viết cẩn thận. Nhóm thứ hai nằm ở các review người dùng trên những trang đánh giá phần mềm, nơi có người mô tả nền tảng ngày càng khó và đắt để bảo trì và nâng cấp.

Tuy nhiên đây là chỗ cần đọc cho đúng mức, và cần đọc kỹ hơn cả hai câu trên. Diễn đàn là nơi người ta lên khi gặp vấn đề còn trang đánh giá là nơi người ta lên khi có cảm xúc mạnh, nên tần suất một chủ đề xuất hiện ở đó không phải là tỷ lệ xảy ra trong thực tế; riêng câu về việc bảo trì ngày càng đắt là ý kiến của một người dùng cụ thể chứ không phải kết luận của một khảo sát nào. Tôi đưa nó vào bài như một dấu hiệu chứ không như một thống kê, và bạn cũng nên trình bày với khách theo đúng cách đó, bởi dùng nó như con số thì tới lúc bị hỏi nguồn bạn sẽ mất uy tín cho cả những phần đúng.

Chỗ đặt con số trong tài liệu GAP

Phần khó nhất không phải là hiểu, mà là nói ra mà không nghe như đang tìm cách từ chối làm việc.

Cách tôi dùng là thêm một dòng vào chính chỗ mà quyết định đang được đưa ra, tức tài liệu GAP. Với những hạng mục thuộc hai hàng cuối của bảng ở trên, tôi ghi thêm ước lượng công sức phải bỏ ra mỗi lần nâng cấp cho hạng mục đó. Không cần chính xác, một khoảng là đủ, và điều quan trọng là nó nằm cạnh con số chi phí lần đầu chứ không nằm trong một tài liệu riêng mà không ai mở.

Kèm theo đó là ba câu hỏi tôi đặt cho khách, và ba câu này thường làm cuộc trao đổi đổi hướng theo cách có lợi cho cả hai bên.

1. Đầu tiên là doanh nghiệp dự định dùng hệ thống này trong bao nhiêu năm.
2. Tiếp theo là có kế hoạch nâng cấp định kỳ hay chỉ nâng cấp khi buộc phải.
3. Và cuối cùng, nếu tính năng này chỉ đáp ứng được phần lớn mong muốn nhưng đổi lại không đụng vào lõi, thì phần còn thiếu có đáng để đánh đổi không.

Câu cuối là câu tạo ra nhiều giá trị nhất, bởi rất nhiều yêu cầu đắt tiền hóa ra chỉ đắt ở phần cuối cùng của nó, và khi được hỏi thẳng thì khách thường sẵn sàng bỏ phần đó.

Nợ kỹ thuật vay đúng chỗ

Cuối cùng cần nói rõ một chuyện, để bài này không bị đọc thành lời khuyên đừng customize.

Nợ kỹ thuật vay đúng chỗ là một công cụ tốt. Nếu một tùy biến giúp doanh nghiệp bỏ được một khâu nhập liệu tay tiêu tốn vài người mỗi ngày, thì phần tiết kiệm được trong vòng đời hệ thống thường lớn hơn nhiều so với chi phí mang vác của nó, và phép so sánh đó nên được làm ra giấy chứ không nói miệng. Nếu một tùy biến là điều kiện để doanh nghiệp mở được một kênh bán hàng mới, thì đặt câu hỏi chi phí nâng cấp lên trước là đặt sai thứ tự ưu tiên.

Điểm khác nhau giữa nợ tốt và nợ xấu không nằm ở số tiền mà nằm ở chỗ có ai biết mình đang vay hay không. Một hạng mục được duyệt sau khi hai bên đã nhìn thấy cả chi phí lần đầu lẫn chi phí mang vác là một quyết định kinh doanh; cũng hạng mục đó được duyệt vì không ai nhắc tới vế thứ hai thì là một khoản nợ giấu, và khoản nợ giấu bao giờ cũng đắt hơn.

Do đó việc của bạn không phải là bảo vệ hệ thống khỏi khách hàng, mà là đảm bảo rằng mọi con số đều nằm trên bàn vào lúc quyết định. Và cách rẻ nhất để giảm số lượng hạng mục phải quyết định là đừng để những yêu cầu không cần thiết đi được tới bàn ngay từ đầu, tức là làm cho tử tế ở khâu khảo sát.