企业微信定制开发怎么评估

先把「定制开发」拆成三段成本

「定制开发」这个词在报价单上是一次性工程，在需求文档里是一条会持续变化的业务线。这两种理解之间的差价，就是大多数项目超支的那部分钱。

可算的拆法是三段：建设期把第一版做出来，变更期跟着业务改，运维期让它每天活着。三条路的差别不在总价高低，在于把成本堆在哪一段，以及哪一段的单价你控制不了。

• 建设期：一次性，可估、可谈、可比价，也是唯一一段会被认真评审的。
• 变更期：按次发生，单价差异最大 —— 同一个改动，自研是半天，外包可能是两周加一份补充协议。
• 运维期：按月发生，包含机器、值班、掉线处理、版本跟进。最不显眼，三年累计常常超过建设期。

三条路把钱堆在不同的地方

自研团队

建设期最贵，而且贵在看不见的地方：招人或抽人、学习曲线、把频控退避和掉线重连这类异常路径亲自踩一遍。这段时间通常比排期表长一半。换来的是变更期单价最低 —— 需求改了是自己人改，当天能上。

它的真实风险在运维期，而且是组织风险不是技术风险：写这套东西的两个人走掉一个，剩下那个大概率也待不长，然后就没人敢动这份代码了。判断标准很直接 —— 这套系统在你们公司能不能长期保持两个人以上懂。答案是否，自研的账就算不平，跟技术实力无关。

外包项目制

建设期最可预测，这是它唯一的核心优势：一个总价、一个交付日期、一份验收清单。代价全在后面两段。变更期单价最高，因为每一次超出合同范围的需求都要重新报价、重新排期，而「范围」这个词在签合同的时候没人能定义准。

运维期是真正的黑洞。项目结束后原班人马已经去了别的项目，出问题时你联系的是一个客服流程，不是当初写代码的人。所以外包的关键不在选谁，在合同写成什么样 —— 这一点值得单开一节。

平台加轻自研

把账号接入、登录态维持、事件投递这些非业务部分交给平台，自己只写业务逻辑。它的成本形状和前两条不一样：建设期被削掉一大块，运维期被摊成一笔可预测的订阅。以 wecomapi 为例，接入按账号订阅、订阅内不再按调用次数计费，也不需要自备服务器跑接入层，于是运维期的账从「几台机器加一张值班表」变成一个固定数字。

代价是能力边界由平台的覆盖面决定，不由你自己决定。所以这条路的评估重点不是价格，是选型阶段对着文档逐项核能力，并在预发环境实测。核漏了一项，后面要么绕，要么补一条自研分支，这笔钱要提前算进去，而不是等它变成变更单。

一个能算的粗模型

三年成本 ≈ 建设期 + 变更单价 × 季度变更次数 × 12 + 运维期月成本 × 36

                 建设期    变更单价   运维期月成本
自研             最高      最低       人力为主，随团队稳定性波动
外包项目制       中        最高       低但不可控，取决于响应条款
平台 + 轻自研    最低      低         订阅费，可预测

# 关键变量是「季度变更次数」：它一乘，三条路的排序会整个翻过来
# 接入层的订阅口径以 wecomapi 文档为准，业务侧按你自己的人力成本算

这个模型不精确，但足够把讨论从「哪家便宜」拉回到「一年改几次」。多数团队第一次认真填这张表时会发现，结论和第一直觉相反 —— 而直觉错的方向几乎总是同一个：低估了变更次数。

用两个轴决定，不要用预算决定

预算是约束，不是决策依据。真正决定选哪条路的是两个变量：需求变更频率，和业务逻辑的独特性。

• 变更频繁 + 逻辑独特：自研。这是唯一一种自研能把账算平的组合，因为变更期的单价优势会被频率放大。
• 变更频繁 + 逻辑标准：平台加轻自研。业务逻辑薄，自己写的那部分改起来快，接入层不用操心。
• 变更稀少 + 逻辑独特：外包，但要按下一节的方式签合同。这是外包最合适的场景，也基本是唯一合适的场景。
• 变更稀少 + 逻辑标准：先问要不要做。这个象限里的需求多半用现成产品配置一下就能覆盖，定制开发是过度投入。

最常见的两种错配：变更频繁却签了固定总价的外包，第二个月开始每次沟通都在谈钱；业务高度标准却养了一个五人团队，做出来的东西和市面产品没有区别。这两种都不是技术问题，是在没算变更频率的情况下拍的板。

外包合同里必须写死的四条

选了外包，交付质量的上限就由合同决定，不由供应商的技术水平决定。下面四条不写进去，验收那天你没有任何抓手。

1. 1验收标准必须包含异常路径。只测「能发出消息」等于没验收 —— 频控被拒后有没有退避、事件重复投递会不会重复执行、账号掉线能不能自愈，这三项要写成可执行的验收用例。它们在演示环境一次都不会出现，上线第一周会全部出现。
2. 2账号、凭证与数据的归属和交接方式。凭证注册在谁名下、账号实例绑在谁的订阅上、历史数据存在谁的库里、合作结束怎么迁移。这四个问题写清楚的合同不到一半，而它决定了你有没有换供应商的自由。
3. 3交付物包含运行手册与日志规范，不只是源码。源码交了但没人知道怎么部署、日志里查不到任何东西，接手成本和重写差不多。
4. 4变更计价方式与响应时限。按人天、按功能点还是包干，故障多久响应，写进合同而不是写在邮件里。变更期是外包成本最高的一段，把单价定死比在总价上砍五个点有用得多。

还有一个常被忽略的选项：把接入层和业务层拆成两份合同。接入这部分交给 wecomapi 这类现成能力，外包只做业务逻辑，验收范围立刻清晰一大截 —— 供应商不能再用「平台侧的问题」解释交付延期，你也不会因为换供应商而丢掉账号和历史数据。

什么时候该重新评估一次

路线不是一锤子买卖。有三个信号出现时，值得把上面那张表重新填一遍：变更请求开始排队等预算审批、运维值班开始占用业务开发的时间、或者第二条业务线要接进同一套系统。这三个信号都说明原来估的变更次数已经不准了。

重新评估的成本主要取决于一件事：业务代码有没有直接依赖某一侧的字段形状。有一层薄薄的业务动作抽象，换路线是几天的活；没有，就是重写数据层。这层抽象在项目最开始只值几十行代码，是三条路都该做的一件事。