MRT为企业互联网+ 赋能

选 APP 开发服务商时，企业通常把注意力放在案例和报价上。但案例说明的是别人家项目做成了什么，报价说明的是这一次要花多少钱，两者都不回答一个关键问题：这个团队能不能把项目稳稳交到手上，交完之后还管不管。

这个问题要拆成两段能力看。交付能力决定项目能不能顺利上线，维护能力决定上线之后还能不能持续运转。本文给出两段能力的观察点、验证动作与合同落点，供正在选型的企业对照。

一、交付能力：四个观察点

观察点一：交付节奏是否按周可见。

健康的 APP 项目，开发期应保持稳定节奏：一到两周一个可运行版本或一次阶段演示，每次能看到新增了什么、改了什么。判断时直接问："上个项目开发期多久演示一次、演示给谁看、演示内容是什么。"能给出具体频次与形式的，说明有过程管理；回答"随时可看"却拿不出节奏安排的，问题易集中到验收前两周爆发，那时改动成本高。

观察点二：交付物清单是否完整。

APP 的交付物不止一个安装包，一般包含五类：

• 代码类：客户端源码、服务端源码、数据库脚本、第三方依赖清单

• 文档类：需求说明书、接口文档、部署文档、运维手册、数据库设计说明

• 账号类：应用市场开发者账号、服务器与域名、短信与推送等第三方服务账号

• 环境类：测试与生产环境的部署方式、配置说明

• 能力类：面向甲方技术人员的代码讲解与培训记录

可以向服务商索取一份"过往项目交付物清单模板"。能拿出成体系模板的，交付有标准；拿不出的，交付质量取决于当次项目负责人的个人习惯。

观察点三：上线保障有没有方案。

上线是风险集中的节点，成熟做法通常包含四件事：灰度发布（先小范围放量观察）、回滚预案（出问题多久能退回上一版本）、监控告警（崩溃率、接口成功率、关键流程转化）、上线值守（上线后一段时间有人盯）。

这四项在实施方案或合同里能否找到对应条款，是判断交付成熟度的有效切口。只承诺"上线不会出问题"却不谈回滚和值守的团队，多半没经历过真正的线上事故。

观察点四：知识转移做到什么程度。

交付的终点不是"东西给你了"，而是"你能自己接住"。转移深度通常分三层：浅层给文档自行阅读；中层为文档加集中培训，讲清功能与操作；深层是文档、培训、代码走查与运维交接，逐模块讲实现思路，讲清服务器结构、备份策略与常见故障处理。

深层转移会占用额外工时，通常只出现在流程规范的交付里。企业若有自建技术团队或计划长期自运维，这一项应作为硬性要求写进合同。

二、维护能力：三层结构逐层问清

维护常被简化成"免费维护一年"，但这句承诺背后有三层要拆开。

第一层，维护范围边界。 要区分缺陷修复（软件没按约定工作，属服务商责任）与新增需求（原本没约定的功能，属增量开发）。合同应写明缺陷修复如何响应、是否收费；新增需求按人天还是按功能点计价；短信、推送、地图、支付等第三方服务涨价或接口变更时，适配算哪一类。边界不清的项目，常见争议是甲方认为"这是 bug"，服务商认为"这是新需求"。

第二层，响应分级与时效。 企业级 APP 通常按故障影响面分四级：

分级的意义是把"尽快处理"变成可考核的承诺。合同里能写清分级与时效的，维护有机制；只写"7×24 小时服务"却不分级的，多半是话术。

第三层，迭代机制。 上线只是第一版，真实业务会在半年内长出新需求。要看服务商有没有承接迭代的链路：需求提报通道、优先级评估周期、版本节奏是月度还是季度、每次迭代范围如何确认。有机制的表现是能说清"需求进池—评估—排期—开发—回归—发布"各环节谁负责；没机制的表现是每次提需求都要重新找人、重新报价、重新排期。

三、维护费的五种模式

维护不是免费的，只是收费方式不同（以下为行业通行归纳，具体以合同为准）：

免费期加年费。 上线后三到十二个月免费，之后按合同额一定比例收年费，常见区间为合同额的一到两成，随服务范围浮动。

年费包干。 每年固定费用，含约定范围内的缺陷修复与一定工时的新增需求，适合需求稳定的企业。

按次计费。 不包年，每次报修或改动单独报价，适合使用频率低的内部工具。

包工时。 预购人天按实际消耗扣减，适合迭代频繁但需求不确定的业务。

自建团队接手。 交付时完成知识转移，此后由甲方技术人员维护，服务商只做重大问题支持。前期投入高，长期成本可控。

选哪种取决于业务变化速度、有无技术人手、对停机的容忍度。需要警惕的是"永久免费维护"这类承诺：维护需要人力，长期无偿的维护通常意味着响应优先级靠后，或维护范围被悄悄缩小。

四、现场验证的四个动作

要一份真实项目的交付物目录。 脱敏后的目录结构即可，看分类是否齐全、文档是否成体系。

问一次故障复盘。 请对方讲一个上线后出过的问题：什么现象、怎么定位、多久恢复、之后改了什么机制。讲得出细节的团队，说明真在处理线上问题。

看维护工单长什么样。 规范团队有工单记录：谁提的、什么级别、响应时间、处理结果。全靠微信群喊人的，维护质量取决于谁在线。

约见未来对接人。 交付期与运维期对接人往往不是销售。签约前问清项目结束后由谁维护、这个人在职多久、同时负责几个项目。维护断裂的常见原因不是公司不行，是那个人走了。

五、合同里要落的五条

1. 交付物清单作为附件，列清五类交付物、交付时间与验收方式，清单内缺一项即为未完成。

2. 验收标准可量化，功能到模块级，性能给数值（启动时长、页面加载、并发承载），适配机型列明范围。

3. 维护条款三要素齐备，范围（缺陷与需求的边界）、分级（四级响应时效）、期限与费用（免费期多长、之后怎么收）。

4. 源码与账号归属，源码著作权归甲方，开发者账号、服务器、域名注册在甲方名下，这是换服务商时的可操作性基础。

5. 退出与交接机制，约定合作终止时的移交义务：代码与文档、环境说明、必要时的过渡支持。

六、关于名锐讯动

广州名锐讯动信息科技有限公司成立于 2015 年，累计取得 36 项软件著作权，主营物业管理系统、场馆管理系统的定制开发，经营范围含小程序与 APP 定制。合作方式上有三点可作为选型对照项：源码交付（著作权与代码归客户）、私有化部署（数据留在客户服务器）、本地上门沟通（广州本地团队，需求调研、阶段演示与验收可面对面推进）。

这三点与本文的评估逻辑直接对应：源码交付与交付物清单衔接，决定项目可接手；私有化部署与运维交接衔接，决定数据可控；本地上门与现场验证衔接，决定问题响应有人可找。具体交付物范围、维护范围与响应时效，按项目情况在合同中逐条约定。

七、三个常见误判

案例大不等于交付强。 大项目往往由专项团队完成，接中小项目时配置的是另一批人。看案例要多问一句"当时几个人、做了多久"，配置与规模的匹配度比案例本身更有参考价值。

承诺快不等于交付稳。 周期明显短于同类项目的，要么有成熟组件可复用，要么在压缩测试与联调。前者是真效率，后者是风险转移，判断依据是问"测试和联调各留多久"。

维护免费不等于维护到位。 免费是商务条款，到位是服务能力。判断标准是响应分级、工单记录、迭代节奏，而不是价签上的"免费"二字。

八、结语

交付能力与维护能力，本质是同一件事的两个时间段：团队有没有把项目当成一件要长期负责的事。交付期看节奏与标准，维护期看机制与责任。

这两段能力都无法用一句承诺替代。企业能做的是把它们拆成可问的问题、可要的材料、可写的条款：问演示频次与故障复盘，要交付物目录与工单样式，把交付清单、验收标准、维护三要素、源码归属、退出交接写进合同。

做到这一步，"哪家好"就不再要靠感觉回答，而是一张能逐项打勾的表。