Giá trình tạo ứng dụng AI phụ thuộc vào cách tính công việc

Gói rẻ nhất cho 100 vòng lặp yêu cầu mỗi tuần thường là gói tính ít công việc nhất xoay quanh từng yêu cầu. Mức giá tháng niêm yết gần như không nói lên điều gì cho đến khi bạn biết một lần thử lại, một lượt lập kế hoạch, một lần chạy kiểm thử, một lần triển khai và một tác nhân chạy nền có bị tính vào cùng một đồng hồ đo hay không.

Tôi từng thấy các nhóm so sánh gói bằng cách lấy giá đăng ký chia cho 100 yêu cầu. Phép tính đó gọn gàng nhưng sai. Một yêu cầu đổi câu chữ trên nút bấm và một yêu cầu tái cấu trúc cơ sở dữ liệu đều là một tin nhắn với người đang gõ, nhưng chúng có thể tạo ra hóa đơn rất khác nhau. So sánh trung thực phải bắt đầu bằng nhật ký khối lượng công việc, rồi áp dụng quy tắc tính phí của từng nhà cung cấp vào cùng nhật ký đó.

Bài viết này dùng bảng giá giả định, không phải giá của bất kỳ nhà cung cấp nào được nêu tên. Mục tiêu là đưa cho bạn một phép tính mà bạn có thể thay bằng điều khoản gói thực tế trước khi mua.

Cùng số lượng yêu cầu có thể che giấu ba hóa đơn khác nhau

Số tin nhắn của người dùng đo cuộc hội thoại, không đo năng lực tính toán hay công việc hoàn thành. Gói tín dụng thường đo hoạt động của mô hình, gói theo tác vụ đo một đơn vị công việc do nhà cung cấp xác định, còn gói cố định bán quyền truy cập trong một ranh giới nhất định. Những ranh giới đó tạo ra tổng chi phí khác nhau ngay cả khi ứng dụng và 100 yêu cầu hằng tuần vẫn y hệt.

Giả sử một nhà sáng lập yêu cầu 70 thay đổi nhỏ ở giao diện, 20 thay đổi chạm đến nhiều tệp và 10 thay đổi về tạo bản dựng hoặc triển khai mỗi tuần. Con số nhìn thấy là 100. Đằng sau nó, trình tạo có thể kiểm tra kho mã, lập kế hoạch, gọi mô hình nhiều lần, chạy kiểm thử, sửa một chỉnh sửa thất bại, dựng lại ứng dụng và giữ một tác nhân chạy sau khi phản hồi trò chuyện đã xuất hiện. Một gói có thể tính phí mỗi lượt gọi mô hình. Gói khác có thể gọi toàn bộ chuỗi đó là một tác vụ. Gói đăng ký có thể bao gồm, giới hạn hoặc loại trừ một phần thành phí vượt mức.

Đây là điểm người mua thường lẫn lộn: một vòng lặp là chu kỳ quyết định của người dùng, còn một sự kiện tính phí là bất cứ thứ gì người bán chọn để đo. Coi hai khái niệm này như đồng nghĩa sẽ có lợi cho gói có trang giá mơ hồ nhất. Nó cũng khiến một gói trông rẻ trở nên đắt sau khi nhóm đã gắn ứng dụng của mình vào nền tảng.

Để so sánh, hãy dùng hệ số tháng là 4.33 tuần thay vì giả vờ tháng nào cũng có bốn tuần. Một trăm vòng lặp hằng tuần trở thành 433 vòng lặp mỗi tháng. Điều chỉnh nhỏ này thêm 33 vòng lặp, trước khi đưa bất kỳ lần thử lại hay tác vụ nền nào vào phép tính.

Một yêu cầu báo giá hữu ích sẽ đề nghị nhà cung cấp phân loại công việc, thay vì chỉ ước tính tổng. Hãy hỏi: Điều gì khởi động đồng hồ đo? Khi nào nó dừng? Lần chạy thất bại có được tính không? Lần thử lại tự động có được tính không? Công việc nào tiếp tục sau khi giao diện nói phản hồi đã hoàn tất? Dung lượng chưa dùng có được chuyển tiếp không? Câu trả lời quyết định hóa đơn.

Xác định một khối lượng công việc trước khi mở máy tính

Hãy xây dựng một tuần mang tính đại diện từ công việc bạn thực sự dự kiến, rồi giữ nguyên nó trước khi so sánh các gói. Nếu bạn thay đổi khối lượng công việc cho từng mô hình giá, bạn đang kiểm tra lời quảng cáo bán hàng chứ không phải giá.

Trong phép so sánh mẫu, tôi sẽ dùng khối lượng công việc hằng tuần sau:

• 70 chỉnh sửa nhỏ, mỗi chỉnh sửa dùng một đơn vị tín dụng
• 20 thay đổi nhiều tệp, mỗi thay đổi dùng ba đơn vị tín dụng
• 10 thay đổi tạo bản dựng hoặc triển khai, mỗi thay đổi dùng năm đơn vị tín dụng
• 25 lần chạy lại, trung bình hai đơn vị tín dụng mỗi lần
• 35 lượt chạy nền, tiêu thụ tổng cộng 45 đơn vị tín dụng

100 vòng lặp được yêu cầu tiêu thụ 180 đơn vị tín dụng giả định ở lượt đầu. Các lần thử lại thêm 50. Công việc lập kế hoạch, lập chỉ mục, kiểm thử và triển khai thêm 45. Tổng mỗi tuần là 275 đơn vị, tương đương 1,190.75 đơn vị trong một tháng trung bình.

Cùng hoạt động đó có hình dạng thứ hai dưới cách tính theo tác vụ. Nó tạo ra 100 lần bắt đầu tác vụ do người dùng khởi tạo, 25 lần bắt đầu lại và 35 lần bắt đầu tác vụ nền mỗi tuần. Đó là 160 sự kiện mỗi tuần và 692.8 sự kiện mỗi tháng. Tất cả 692.8 sự kiện có được tính phí hay không phụ thuộc vào định nghĩa tác vụ trong hợp đồng.

Hãy ghi riêng công việc thành công và thất bại. Tỷ lệ thất bại chỉ dựa trên thông báo lỗi nhìn thấy sẽ bỏ sót các lần sửa âm thầm, phương án dự phòng mô hình tự động và lần chạy lại kiểm thử. Dữ liệu xuất mức sử dụng của nền tảng, nếu có, là bằng chứng tốt hơn lịch sử trò chuyện vì cuộc trò chuyện có thể gộp nhiều lượt chạy của tác nhân thành một phản hồi.

Hãy dùng một tuần có cả những rắc rối thông thường: một yêu cầu chưa rõ, một xung đột phụ thuộc, một bài kiểm thử thất bại vì lý do không liên quan và một lần sửa triển khai. Một tuần trình diễn hoàn hảo chỉ tạo ra ngân sách kéo dài đến khi quá trình phát triển thực tế bắt đầu.

Đừng thổi phồng khối lượng công việc để tự bảo vệ mình. Hãy thêm một khoản dự phòng biến động riêng sau khi tính mức cơ sở quan sát được. Giữ tách mức cơ sở và khoản dự phòng giúp bạn biết gói đắt vì công việc bình thường hay vì bạn đã mua bảo hiểm cho một tháng bận rộn.

Gói tín dụng tính phí cho chuyển động bên trong trình tạo

Gói tín dụng ít tốn hơn khi đơn giá của nền tảng thấp, tín dụng chưa dùng còn hiệu lực đủ lâu để dùng và trình tạo cần ít lượt sửa. Chúng tốn hơn khi một yêu cầu đơn giản phân nhánh thành nhiều lượt gọi mô hình mà người dùng không thấy.

Tín dụng không phải đơn vị tiêu chuẩn. Nó có thể đại diện cho token, lượt gọi mô hình, bước của tác nhân, giây hoặc một tổ hợp có trọng số. Nhà cung cấp cũng có thể tính số tín dụng khác nhau cho mô hình nhanh và mô hình mạnh hơn. So sánh số tín dụng trong hai gói là vô nghĩa nếu cả hai nền tảng không xác định mức tiêu thụ theo cùng cách, điều hiếm khi xảy ra.

Hãy định giá khối lượng công việc giả định bằng gói 500 đơn vị giá $30. Nhu cầu tháng là 1,190.75 đơn vị. Vì gói không thể chia nhỏ, người mua cần ba gói và trả $90. Tài khoản kết thúc tháng với 309.25 đơn vị còn lại nếu tín dụng không hết hạn. Chi phí hiệu quả cho công việc đã tiêu thụ là khoảng 7.56 xu mỗi đơn vị, dù gói quảng cáo 6 xu, vì người mua phải mua dung lượng chưa dùng.

Khả năng chuyển tiếp làm thay đổi kết quả. Nếu 309.25 đơn vị còn lại vẫn có hiệu lực, tháng sau có thể chỉ cần mua hai gói thay vì ba. Qua nhiều tháng ổn định, chi phí trung bình tiến gần mức giá quảng cáo. Nếu tín dụng hết hạn hằng tháng, số dư bị bỏ lại là một phần của giá. Đừng bao giờ bỏ nó khỏi mô hình.

Việc chọn mô hình có thể thay đổi mức tiêu thụ mà không đổi số yêu cầu. Nếu nền tảng chuyển các chỉnh sửa phức tạp sang mô hình có hệ số bốn đơn vị, mười yêu cầu khó nhất có thể chi phối hóa đơn. Hãy hỏi việc định tuyến có tự động không, bạn có thể xem lại nó không và có thể đặt mức trần không. Mô hình rẻ hơn nhưng thất bại rồi thử lại hai lần có thể đắt hơn mô hình mạnh thành công ngay lần đầu.

Gói tín dụng phù hợp với dự án không đều vì bạn trả tiền khi công việc xảy ra, miễn tín dụng có thời hạn hữu ích. Chúng khó lập ngân sách hơn với nhóm thích thử nghiệm thoải mái. Đồng hồ đo có thể làm thay đổi hành vi: mọi người gộp các yêu cầu không liên quan thành yêu cầu quá lớn, tránh kiểm thử hoặc chấp nhận đầu ra yếu để tiết kiệm tín dụng. Những lựa chọn này giảm hóa đơn bằng cách làm hại ứng dụng.

Câu hỏi khó là công việc nền có nên tiêu thụ tín dụng không. Nó dùng tài nguyên nên thu phí là hợp lý. Vấn đề xuất hiện khi người mua không thể dự đoán hoặc dừng nó. Đánh giá công bằng cần xem giao diện có hiển thị từng khoản phí nền không và giới hạn chi tiêu có dừng công việc mới trước khi số dư về không không.

Tính phí theo tác vụ phụ thuộc vào điểm bắt đầu và kết thúc của tác vụ

Tính phí theo tác vụ có thể là mô hình rẻ nhất khi một mức giá bao trọn lần thử, gồm lập kế hoạch, lượt gọi mô hình, kiểm thử và sửa lỗi. Nó trở thành mô hình đắt nhất khi mỗi hành động nội bộ biến thành một tác vụ mới.

Áp dụng mức giá giả định $0.14 cho mỗi sự kiện đã bắt đầu trong nhật ký. Với 692.8 sự kiện mỗi tháng, chi phí là $96.99 sau khi làm tròn đến xu. Con số này cao hơn kết quả $90 của gói tín dụng, dù mười bốn xu nghe có vẻ nhỏ trên trang giá.

Giờ hãy đổi một câu trong hợp đồng: chỉ tính phí 433 vòng lặp do người dùng yêu cầu, còn lần thử lại và công việc nền được bao gồm trong mỗi tác vụ. Chi phí tháng giảm xuống $60.62. Ứng dụng không thay đổi gì. Ranh giới tác vụ thay đổi, và ranh giới đó dịch chuyển $36.37.

Tính phí theo tác vụ hoàn thành cần thêm một định nghĩa. Nếu một lượt chạy thay đổi tệp nhưng triển khai thất bại, nền tảng đã hoàn thành tác vụ chưa? Nếu người dùng từ chối kết quả và yêu cầu chỉnh sửa, đó là tác vụ mới hay phần tiếp tục? Nhà cung cấp cần quy tắc để ngăn công việc không giới hạn dưới một mức phí, nhưng người mua cần quy tắc có thể tái hiện từ nhật ký hoạt động.

Khuyến nghị phổ biến là so sánh chi phí trên mỗi yêu cầu thành công, nhưng cách này sai khi thành công do người dùng tự báo. Người dùng chấp nhận kết quả một phần, chia nhỏ yêu cầu lớn và sửa đầu ra thủ công. Chi phí thấp trên mỗi thành công được ghi nhận có thể che giấu nhiều giờ dọn dẹp. Thay vào đó, hãy so sánh chi phí trên mỗi thay đổi được chấp nhận, tại thời điểm nhóm sẽ gộp mã, triển khai hoặc giữ kết quả theo cách khác.

Giá theo tác vụ có lợi thế lập ngân sách khi đơn vị tương ứng với điều con người nhận ra. Một nhóm có thể ước tính 400 thay đổi được chấp nhận tự tin hơn hàng triệu token. Lợi thế này biến mất nếu sản phẩm gọi việc lập chỉ mục, lập kế hoạch, kiểm thử và triển khai là các tác vụ riêng. Hãy đọc tên sự kiện trong hóa đơn thực tế hoặc dữ liệu xuất mức sử dụng trước khi coi đơn vị này là ổn định.

Hãy hỏi cả cách tính đồng thời. Hai tác nhân chạy cùng lúc có thể rút ngắn thời gian thực hiện nhưng nhân đôi số lần bắt đầu tác vụ. Một lượt sửa nền sinh ra tác nhân kiểm thử có thể tính một lần, hai lần hoặc không tính. Hóa đơn đi theo đồng hồ đo, không theo thời gian thực trôi qua.

Gói đăng ký cố định chỉ thắng trong ranh giới được bao gồm

Gói đăng ký cố định có chi phí thấp nhất cho khối lượng công việc này khi phí tháng bao gồm toàn bộ 433 vòng lặp người dùng, 108.25 lần bắt đầu lại và 151.55 lần bắt đầu nền. Nếu bất kỳ nhóm nào nằm ngoài gói đăng ký, hãy cộng chúng trước khi kết luận gói cố định rẻ hơn.

Dùng gói giả định $79 mỗi tháng, bao gồm tối đa 600 lượt chạy tương tác và thử lại cùng 200 lượt chạy nền. Ví dụ này tạo ra 541.25 lượt chạy tương tác và thử lại cùng 151.55 lượt chạy nền mỗi tháng. Cả hai đều nằm trong hạn mức, nên chi phí giữ ở $79. Theo các giả định này, giá cố định tốt hơn gói tín dụng $90 và gói tính theo tác vụ đã bắt đầu $96.99.

Từ không giới hạn không có giá trị trong bảng tính. Hãy thay nó bằng ngưỡng sử dụng hợp lý, giới hạn đồng thời, hạn chế mô hình hoặc quy tắc làm chậm thực tế. Nếu nhà cung cấp không nêu ranh giới, hãy lập tình huống thấp và cao. Một gói chỉ rẻ khi diễn giải nó không có giới hạn chưa đem lại cho bạn mức giá đáng tin cậy.

Gói cố định cũng tạo chi phí theo bậc. Ở 599 lượt chạy được bao gồm, thêm một lượt có thể không tốn gì. Ở 600, lượt tiếp theo có thể kích hoạt phí vượt mức hoặc buộc nâng hạng. Hãy vẽ ít nhất ba mức khối lượng công việc: tháng yên ắng, tháng dự kiến và tháng phát hành. Chỉ nhìn trường hợp dự kiến sẽ che khuất điểm gói đăng ký tăng giá.

Số ghế quan trọng khi tính phí theo người dùng thay vì công việc. Gói $79 cho một người thành $316 cho bốn ghế bắt buộc, ngay cả khi nhóm dùng chung 433 vòng lặp. Đừng giả định được phép chia sẻ tài khoản. Hãy định giá những người cần xem lại yêu cầu, phê duyệt triển khai hoặc kiểm tra mức sử dụng.

Một khoản phí cố định có thể khuyến khích thử nghiệm lành mạnh vì mỗi ý tưởng thất bại không tạo ra khoản phí nhỏ dễ thấy. Nó cũng có thể che giấu lãng phí cho đến khi nền tảng điều tiết tài khoản. Khả năng hiển thị mức sử dụng vẫn quan trọng. Bạn cần biết tác nhân có đang lặp vô tận không và tháng phát hành có vượt ranh giới đi kèm không.

Hãy đưa chiết khấu hằng năm vào phép tính sau cùng. Trước hết, tìm mô hình rẻ nhất theo điều khoản tháng. Sau đó áp dụng chiết khấu và chi phí cam kết. Trả mười tháng cho một công cụ bị bỏ sau ba tháng không phải là tiết kiệm.

Lần thử lại thuộc mức cơ sở, không phải chú thích

Thử lại là công việc phát triển bình thường, vì vậy so sánh giá giả định đầu ra hoàn hảo ngay lượt đầu không phù hợp cho quyết định mua. Con số hữu ích là hệ số khuếch đại thử lại: tổng số lần thử chia cho số vòng lặp được yêu cầu.

Ví dụ có 125 lần thử tương tác cho 100 vòng lặp được yêu cầu, cho hệ số khuếch đại thử lại 1.25. Điều này không có nghĩa 25 phần trăm yêu cầu chỉ đơn giản là thất bại. Một số yêu cầu cần làm rõ, một số chỉnh sửa qua kiểm tra mã nhưng không đúng ý và một số thất bại đến từ công cụ hoặc phần phụ thuộc. Tác động lên chi phí vẫn như nhau khi gói tính thêm một lần thử.

Hãy đo lượt thử lại bằng quy tắc mà hai người có thể áp dụng nhất quán. Tính là thử lại khi người dùng lặp lại cùng kết quả mong muốn sau khi từ chối hoặc sửa đầu ra trước đó. Đừng tính yêu cầu mới thực sự là thử lại. Hãy gắn nhãn riêng các lần thử lại tự động vì người dùng có thể không bao giờ nhìn thấy chúng.

Một giai đoạn thử nghiệm nhỏ nên có những tác vụ bạn dự kiến khó. Nếu bạn chỉ kiểm tra câu chữ trang đích và đổi màu, tỷ lệ thử lại nói rất ít về chuyển đổi cơ sở dữ liệu, xác thực, quản lý trạng thái hoặc bản dựng di động. Hãy đưa ít nhất một thay đổi có rủi ro qua từng lựa chọn và kiểm tra bản ghi hoạt động.

Lần thử lại ảnh hưởng đến các mô hình theo những cách khác nhau:

• Tính phí tín dụng thường tính tài nguyên tiêu thụ ở mọi lần thử.
• Tính phí theo tác vụ đã bắt đầu thường tính mỗi lần thử nếu lần thử lại tạo một sự kiện.
• Tính phí theo hoàn thành có thể gánh các lần thử thất bại, tùy quy tắc hoàn thành.
• Tính phí cố định gánh các lần thử lại cho đến khi chạm giới hạn đi kèm hoặc cơ chế sử dụng hợp lý.

Đừng chấp nhận câu trả lời có thử lại miễn phí là đủ. Hãy hỏi lần thử lại có dùng cùng mô hình không, phương án dự phòng tự động có tiêu tốn hạn mức riêng không và cửa sổ thử lại miễn phí mở trong bao lâu. Một lần chỉnh sửa gửi vào sáng hôm sau có thể thành tác vụ mới dù công việc rõ ràng vẫn như cũ.

Cũng có chi phí thử lại của con người. Một gói có thể rẻ về tiền nhưng đắt về sự chú ý nếu người dùng phải giám sát từng lần sửa. Trong giai đoạn thử nghiệm, hãy theo dõi số phút xem xét trên mỗi thay đổi được chấp nhận. Đừng ép thời gian đó vào hóa đơn nền tảng, nhưng hãy đặt nó cạnh hóa đơn để giá thấp không che giấu quy trình kém.

Tác nhân nền là hệ số nhân vô hình

Công việc của tác nhân nền phải có dòng riêng vì nó có thể tiếp tục sau khi người dùng thấy phản hồi. Lập chỉ mục kho mã, lập kế hoạch, kiểm tra phần phụ thuộc, kiểm thử, theo dõi bản dựng, triển khai và tác nhân sửa lỗi đều có thể tiêu tốn ngân sách mà không thêm tin nhắn trò chuyện nào.

Ví dụ của chúng ta phân bổ 35 lượt chạy nền và 45 đơn vị tín dụng mỗi tuần. Những con số này là giả định được nêu rõ có chủ ý. Hãy thay chúng bằng hồ sơ sử dụng từ giai đoạn thử nghiệm. Nếu nhà cung cấp chỉ đưa một tổng gộp, hãy chạy cùng một yêu cầu một lần khi tắt tự động hóa tùy chọn và một lần khi bật. Phần chênh lệch là ước tính, không phải bằng chứng, nhưng tốt hơn việc coi công việc đó là miễn phí.

Chế độ lập kế hoạch cần được chú ý đặc biệt. Kế hoạch có thể giảm việc triển khai thất bại tốn kém nhờ phát hiện xung đột sớm, hoặc có thể thêm một bước trả phí trước mọi chỉnh sửa nhỏ. Hãy thử riêng trên thay đổi nhỏ và lớn. Chính sách phù hợp có thể là dùng lập kế hoạch cho thay đổi lược đồ và công việc nhiều tệp, còn bỏ qua với chỉnh sửa câu chữ.

Lập chỉ mục có dạng chi phí khác. Lượt quét đầu tiên trên kho mã có thể tốn kém, trong khi cập nhật tăng dần sau đó tốn rất ít. Một tuần thử nghiệm có thể phóng đại chi phí ổn định nếu gồm lập chỉ mục ban đầu, hoặc đánh giá thấp nếu kho mã sản xuất lớn hơn nhiều. Hãy tách mức tiêu thụ thiết lập ban đầu khỏi mức tiêu thụ lặp lại.

Kiểm thử và triển khai không phải lãng phí tùy chọn. Tắt chúng để vừa hạn mức tín dụng là chuyển việc phát hiện lỗi sang người dùng. Hãy định giá quy trình an toàn mà bạn định vận hành, bao gồm các bước kiểm tra bảo vệ nó. So sánh dựa trên kiểm thử bị tắt đang trả lời sai câu hỏi kinh doanh.

Koder.ai hỗ trợ chế độ lập kế hoạch, triển khai và lưu trữ, ảnh chụp nhanh và khôi phục, cũng như xuất mã nguồn, nên giai đoạn thử nghiệm có thể quan sát những phần này của quy trình thay vì chỉ định giá tin nhắn trò chuyện. Tên gói và giá vẫn cần được kiểm tra trong giao diện sản phẩm hiện tại vì ngữ cảnh trang ở đây xác lập các hạng, không xác lập hạn mức hiện tại của chúng.

Hãy đặt ngân sách nền nếu sản phẩm cho phép, nhưng đừng nhầm mức trần với khả năng dự đoán. Mức trần ngăn chi tiêu vượt mức bằng cách dừng công việc. Ứng dụng vẫn có thể lỡ đợt phát hành khi tác nhân chờ thêm dung lượng. Hãy ghi cả giới hạn tài chính lẫn hệ quả vận hành.

Cho mọi lựa chọn đi qua cùng một nhật ký

Nhật ký giúp so sánh có thể tái hiện và phơi bày điểm mơ hồ của hợp đồng trước khi nó thành tranh chấp hóa đơn. Mỗi dòng nên mô tả một sự kiện được đo, với đủ ngữ cảnh để ánh xạ vào tín dụng, tác vụ và hạn mức đăng ký.

Hãy sao chép tiêu đề CSV này và dùng trong giai đoạn thử nghiệm:

week,event_id,requested_iteration,event_type,outcome,retry_of,background_kind,credit_units,task_events,flat_bucket,notes
2026-W01,001,1,user_edit,accepted,,,1,1,interactive,copy change
2026-W01,002,2,user_edit,rejected,,,3,1,interactive,multi file edit
2026-W01,003,2,retry,accepted,002,,2,1,interactive,repair after failed test
2026-W01,004,2,background,completed,,test,1,1,background,automatic test run

Hãy giữ loại sự kiện và kết quả riêng biệt. Một bài kiểm thử nền có thể hoàn thành thành công trong khi thay đổi được yêu cầu vẫn không được chấp nhận. Nếu bạn gộp các thực tế đó thành một trạng thái, bạn không thể kiểm tra quy tắc tác vụ hoàn thành của nhà cung cấp.

Cuối tuần, hãy tính bốn giá trị:

monthly_iterations = weekly_requested_iterations * 4.33
monthly_credits = weekly_credit_units * 4.33
monthly_task_events = weekly_task_events * 4.33
retry_amplification = (user_attempts + retry_attempts) / requested_iterations

Sau đó áp dụng điều khoản gói mà không thay đổi các dòng. Với bảng giá giả định, phép tính là:

credit_cost = ceil(1190.75 / 500) * $30 = $90.00
started_task_cost = 692.8 * $0.14 = $96.99
flat_cost = $79.00, because 541.25 interactive runs < 600
             and 151.55 background runs < 200

Bảng tính cũng nên cho thấy tín dụng bị bỏ lại, dung lượng đi kèm còn lại và ranh giới giá tiếp theo. Gói thắng trong ví dụ còn 58.75 lượt chạy tương tác và 48.45 lượt chạy nền. Biên độ này không đủ lớn cho một tuần phát hành làm công việc triển khai tăng gấp đôi, vì vậy nhóm nên tính trường hợp đó trước khi cam kết.

Hãy nhờ nhà cung cấp xem một trang nhật ký đã ẩn danh. Đừng hỏi gói nào rẻ nhất; hãy hỏi mỗi dòng được phân loại thế nào. Phân loại bằng văn bản hữu ích hơn ước tính của nhân viên kinh doanh vì bạn có thể đối chiếu với hóa đơn đầu tiên.

Biến động quan trọng hơn giá niêm yết

Kết quả ví dụ là gói đăng ký cố định $79, gói tín dụng $90 và tính phí tác vụ đã bắt đầu $96.99. Thứ hạng này chỉ đúng với bảng giá và khối lượng công việc đã nêu. Một thay đổi nhỏ trong cách xử lý thử lại hoặc công việc nền đi kèm có thể đảo ngược nó.

Hãy tính điểm hòa vốn cho từng cặp. Gói cố định $79 tốt hơn gói tín dụng $30 bất cứ khi nào nhu cầu tháng cần ba gói trở lên, với giả định tín dụng chưa dùng không có giá trị trong tương lai. Nếu chuyển tiếp cho phép người mua dùng hết mọi đơn vị, $79 tương đương khoảng 1,316.7 đơn vị tín dụng ở mức sáu xu mỗi đơn vị. Dưới mức đó, tín dụng được dùng hết có chi phí thấp hơn.

So với tác vụ đã bắt đầu giá $0.14, $79 tương đương khoảng 564.3 sự kiện. Mức dự kiến 692.8 sự kiện vượt điểm này. Tuy nhiên, nếu gói tác vụ chỉ tính 433 vòng lặp được yêu cầu, chi phí là $60.62 và nó thắng. Một lần nữa, một định nghĩa quan trọng hơn mức giá tiêu đề.

Hãy chạy các trường hợp nhạy cảm thay vì giả vờ ước tính là chính xác. Với khối lượng công việc này, thay đổi hệ số khuếch đại thử lại từ 1.10 đến 1.50, công việc nền từ 20 đến 60 sự kiện hằng tuần và mức tiêu thụ của chỉnh sửa phức tạp theo hệ số hợp lý do nhà cung cấp công bố. Bạn không cần hàng chục kịch bản. Bạn cần vài biến số có thể thay đổi quyết định.

Hãy xem xét dòng tiền và mức ràng buộc riêng với chi phí đơn vị. Gói tín dụng có thể giữ được sự linh hoạt. Gói đăng ký tháng tạo mức trần có thể dự đoán khi bạn ở trong ranh giới của nó. Gói đăng ký năm đánh đổi linh hoạt lấy chiết khấu. Xuất mã nguồn và ảnh chụp nhanh có thể giảm chi phí rời một trình tạo, nhưng không khiến việc chuyển đổi miễn phí; ứng dụng xuất ra vẫn cần bản dựng hoạt động, hạ tầng và người có thể duy trì nó.

Nhà sáng lập có mức sử dụng chưa chắc chắn nên chọn mô hình có mặt trái dễ thấy. Điều đó có thể là gói tín dụng có thời gian chuyển tiếp dài, dù tổng dự kiến mỗi tháng nhỉnh hơn một chút. Nhóm có công việc ổn định, đã đo lường có thể mua gói cố định gần giữa phạm vi đi kèm. Gói theo tác vụ hợp với công việc ánh xạ rõ ràng sang kết quả được chấp nhận và bao gồm công việc sửa trong tác vụ.

Đừng chọn theo gói thắng trong ví dụ. Hãy chọn sau khi thay mọi mức giá và hạn mức giả định bằng điều khoản bạn có thể chỉ ra, và thay mọi giả định khối lượng công việc bằng quan sát từ giai đoạn thử nghiệm.

Đưa mô hình tính phí qua bài kiểm tra chấp nhận

Mô hình giá sẵn sàng để quyết định khi người khác có thể tái hiện tổng theo tháng từ nhật ký và điều khoản gói. Nếu phép tính phụ thuộc vào nhân viên kinh doanh diễn giải một tác vụ nội bộ sau đó, mô hình đã không qua bài kiểm tra.

Hãy dùng danh sách kiểm tra chấp nhận ngắn gọn này:

1. Ghi nhận 100 vòng lặp được yêu cầu mang tính đại diện, hoặc mẫu nhỏ hơn bao gồm mọi loại công việc chính.
2. Gắn nhãn lần thử lại, lần thử lại tự động, kế hoạch, kiểm thử, bản dựng, triển khai và các lượt chạy nền khác.
3. Ánh xạ từng sự kiện vào quy tắc tín dụng, tác vụ hoặc hạn mức đi kèm của nhà cung cấp.
4. Tính tổng cho tháng dự kiến, tháng yên ắng và tháng phát hành bằng cùng hệ số 4.33.
5. Lưu điều khoản gói và so sánh hóa đơn thực đầu tiên với dự báo.

Hãy đặt mức dung sai trước giai đoạn thử nghiệm. Chẳng hạn, bạn có thể điều tra mọi tổng cao hơn dự báo hơn 10 phần trăm. Tỷ lệ này là lựa chọn quản lý, không phải tiêu chuẩn ngành. Mục đích là buộc phải xem xét khi lịch sử sự kiện vẫn còn.

Nếu mức sử dụng thực tế vượt dự báo, hãy tìm nhóm dòng chịu trách nhiệm. Nhiều công việc được chấp nhận hơn khác với nhiều lần thử lại hơn. Nhiều lượt triển khai đã lên kế hoạch khác với vòng lặp tác nhân. Cách khắc phục có thể là gói lớn hơn, chính sách tác nhân hẹp hơn, yêu cầu rõ hơn hoặc điều chỉnh hóa đơn. Một tổng duy nhất không thể cho bạn biết điều nào.

Hãy giữ nhật ký bên cạnh hóa đơn trong ba chu kỳ thanh toán đầu tiên vì giai đoạn thử nghiệm yên ắng có thể bỏ sót tác vụ theo lô, công việc phát hành và sửa tự động. Vì vậy, mô hình rẻ nhất cho 100 vòng lặp hằng tuần có điều kiện, nhưng quyết định không cần mơ hồ. Theo ví dụ rõ ràng, gói đăng ký cố định $79 thắng. Theo cách tính tác vụ giới hạn ở thành công, cùng công việc có giá $60.62 và tính theo tác vụ thắng. Gói tín dụng thắng ở mức tiêu thụ thấp hơn hoặc theo đợt khi chuyển tiếp ngăn lãng phí. Hãy ghi rõ thứ được tính, đo công việc ẩn và để hóa đơn chứng minh lời hứa.