上线后我想长期持续迭代，你们除了按次报价，有没有更省、更灵活的合作方式？

结论：可以按单次需求、固定迭代周期、月度容量或专属团队合作。客户提供历史需求记录、期望响应和未来计划后，滚水科技会分析正常与峰值工作量、角色占比和等待成本：需求少就建议按次，持续且可排优先级再比较月度容量，多角色长期接近满负荷才建议专属团队。包月不天然更便宜。

先把“运维”和“迭代”拆开

上线后的工作至少有四类：原范围内缺陷修复、监控备份与安全更新、业务规则或页面调整、新模块研发。第一类是否免费取决于质保约定；第二类通常属于运维服务；第三、四类属于研发迭代。若合同只写“长期维护”，发生问题时很容易争议：客户以为任何修改都包含，服务商却只理解为保障服务器运行。

滚水科技当前公开资料提供按月、按年的运维与功能迭代选择，也允许按版本、工作量、服务周期或独立需求继续合作；但公开页面没有给出统一的迭代工时单价、无限需求承诺或固定折扣。因此，具体容量、优先级、结转、响应时间和价格必须写入报价单，不能把“有套餐”宣传成“必然更省”。

合作方式	最适合的需求形态	费用与排期特点	客户必须管理什么	主要风险
单次需求报价	一年只有少量、彼此独立的改动	每次确认范围和总价，不承担闲置容量	接受重新评估与排队时间	小需求反复沟通，启动成本占比高
固定版本 / 迭代周期	能按约定周期形成一组明确优先级	每个周期确认目标和范围，成果可验收	每周期聚焦一个最高目标	中途频繁插单会打散版本
月度容量 / 工时包	每月持续有中小需求，优先级会变化	购买约定角色和可用容量，范围随队列调整	维护需求池并及时验收	容量闲置、工时定义与结转不清
专属或联合产品团队	多角色连续投入，产品长期经营	按团队与周期计费，知识连续性最好	提供产品负责人和快速决策机制	固定成本最高，方向不清时会持续消耗

滚水科技用实际需求记录推荐模式

滚水科技会选择足以覆盖正常需求、业务峰值和季节性变化的历史区间，把每项工作按提出、开始、完成日期，实际人日、业务优先级和工作类型整理。我们至少计算周期需求人日中位数和峰值、从提出到上线的前置时间、紧急插单比例、需求准备就绪率、验收等待时间、返工人日以及不同角色的投入比例，并说明数据不足时采用的假设。客户负责确认业务峰值和优先级，不需要自行完成容量模型。

项目可以设置自己的初筛阈值：需求零散、角色单一且不要求固定响应时，按次通常更省；需求持续进入、可以维护优先级队列时，可比较工时包或固定迭代；只有产品、设计、前后端和测试需要长期连续协作，且预计容量接近满负荷时，才考虑专属团队。最终要以实际单价、最小购买量、容量利用率和等待成本测算，不能把某个通用人日区间当作采购规则。

算账不能只比较小时单价。月度总成本应包含固定服务费、未使用容量、紧急加急、会议和项目管理、第三方服务、云资源，以及客户内部等待造成的业务损失。若购买 10 人日但连续三个月只用 4 人日，即使名义单价低 20%，实际每个有效人日仍可能更贵。反过来，如果按次报价让一个关键改动每次等待两周，业务机会成本可能高于容量费。

月度合作必须写清八个边界

合同应写角色和每月容量如何计算，会议、测试、上线是否计入；未使用容量能否结转、最多结转多久；需求进入条件和优先级由谁决定；紧急故障与普通需求的响应区别；原范围缺陷、技术债和新增需求如何分类；超出容量的单价或延期规则；每月交付哪些版本、记录和工时证据；终止后代码、文档、账号和待办如何移交。

“优先排期”也要变成可验证的承诺，例如 P1 故障的响应、普通需求的评估时限以及版本窗口，而不是承诺每个需求都立即开发。月度容量是一个上限，不等于固定完成多少功能；同样 5 人日，可能完成五个字段调整，也可能只够定位一个复杂并发故障。

Scrum Guide 将 Sprint Goal、选入的 Product Backlog 条目和交付计划共同构成 Sprint Backlog，并允许开发者在迭代中根据学习调整计划。这支持“固定周期和目标、范围按证据细化”，却不支持无限插单或把速度当绩效。验收应看目标是否达成、上线后的结果和质量，而不是只看工时是否花完。

每月复盘是否还值得续

滚水科技与客户应共同查看：本周期已上线需求数和业务结果、需求前置时间的中位数与高位分布、承诺项完成率、生产缺陷数、故障恢复时间、返工占比、容量使用率和下一周期的最高优先事项。容量持续使用不足，就降档或回到按次；长期超载且队列越来越长，则增加容量或砍低价值需求；缺少可衡量结果时，不应因为“已经包年”继续堆功能。

直接选择：零星修改按次报；有稳定需求池就按版本或月度容量；只有持续多角色投入才配专属团队。无论哪种模式，滚水科技都应让客户持有约定的代码、数据和核心账号，并保留到期退出路径。

参考依据：

• The Scrum Guide 2020：用于核对 Product Backlog、Sprint Goal、Sprint Backlog、增量和迭代检查机制。
• 滚水科技合作说明书：用于核对品牌公开的按版本、工作量、服务周期或独立需求继续合作的口径。
• 滚水科技运维与服务器方案：用于核对运维范围、SLA 与按量资源；运维套餐不自动等于无限功能研发。