软件开发外包流程：八个节点是直的，毁掉项目的是中间那句「我改个想法」

外包流程这事儿，网上写的都是一条直线。

需求、报价、合同、原型、开发、验收、上线、交接。八个节点，画得清清楚楚。

真做起来，没一个是直的。

十个项目里，有八个不是卡在节点上，是卡在节点之间那句"我改个想法"。

这篇不写流程怎么走。写流程走着走着要改，怎么办。

一、先给结论：毁掉一个项目的不是需求变了，是变了没人记账

需求一定会变。

这话我说过很多遍。做软件的怕的不是改，是改了以后谁都说不清改了多少。

甲方觉得"就加个小东西"。乙方觉得"这个得加钱"。两边都没记账，账就烂在心里。

到最后验收那天一起算。一算就崩。

所以流程里真正要紧的那一环，不是节点，是变更单。

二、需求为什么会变：三种来源，处理方法不一样

我把这些年遇到的变更归了归类，大致三种。

第一种：自己想明白了

最常见。

开发之前你脑子里是个模糊的东西。等原型摆到眼前，你才真正看见它。

看见了就会改。这种变更是好事，说明你在认真想。

但它要算钱。因为人天是真花出去的。

第二种：外部变了

微信改了接口规则。支付要补新的证书。行业出了新规定。

这种不是谁的错。处理方式也不该让一方全扛。

通常的做法：改动量小的，各自担一半；改动量大的，走变更单重新排期。

第三种：当初没说清

文档里写了，但两边理解不一样。

这种最麻烦，也最容易吵。

我的处理一贯是：乙方担大头。因为写文档的是我们，没写清楚是我们的失职。

但也不是全担。如果甲方手上有资料没给，那另算。

说实话，这三种里我栽过跟头的就是第三种。

早几年有个项目，文档里写了一句"支持批量导入"。我以为是一条条加，客户以为是传一张表格。

演示那天他愣了半天，一摊手："我要的是传表格啊。"

那次多出来的 2 个人天，我们自己担了。文档是我们写的。

三、一张变更单该写什么

很多人以为变更单就是一张"同意加钱"的纸。

不是。它是把口头的东西变成白纸黑字，让三个月后还能对得上。

七项。看着多，填起来五分钟。

真正费时间的是不填，然后花三个星期吵架。

四、三种变更，三种算法

同样是"改一下"，算法完全不一样。

文档里写了，但两边理解不同

不加钱。

责任在写文档的一方。我们写的需求文档，没写明白是我们的事。

这条我们写进合同了，不是嘴上说说。

文档里没有，你临时要加

算加需求。

按人天算钱，工期顺延。这是最标准的一种。

推翻已经做完的，重做

这个最贵。

原来那个人天照算，因为它真的花了。新的再另算。

我一般会给一句提醒：先别急着推翻，让它上线跑一周。很多时候看着别扭的东西，用起来并不别扭。

真要推翻也行。我会先把推翻的代价算给你看，你再拍板。

五、变更要花多少：按改动类型算人天

这张表是我们自己用的估算口径，你可以照着核。

最后一行我一般直接劝退。能不动地基就别动，代价跟重做一个差不多。

还有一点要说明：表里的人天是纯干活的。没算沟通。

改需求这事，一半时间花在说清楚上。一个 3 人天的改动，来来回回确认能占掉半天。

六、工期顺延不是简单相加

这是最容易算错的地方。

加了 3 个人天，工期不是往后推 3 天。也不是推 6 天。

得看它插在哪儿。

• 插在还没做的模块里。 可以并着做，工期基本不增，只加人天。
• 插在正在做的模块里。 要等手上这块收尾，工期加 1-2 天。
• 插在已经做完的模块上。 最贵，得重新过一遍测试，工期加 3-5 天。

所以同样是加一个字段，早说和晚说，差出来的可能是五天。

上周还有个客户问我："改个字段也要算工期？"

我说看它插在哪儿。插在还没动工的模块里，工期不动；要是插在已经测完的地方，光回归测试就得加两天。

他听完说了一句：那我早点说。

想起来就早说。这句话我每个项目都要重复两三遍。

七、这四种情况不该加钱

说完了该加的，说不该加的。这四种我们一律不加。

• 出了 bug。 这是我们的活没干好，算不到你头上。
• 性能不达标。 合同里写了多少并发，达不到就是我们的。
• 文档写了但没做到。 同上，写文档的是我们。
• 机型兼容出问题。 主流机型跑不起来，属于没测到位。

有个边界要说明白：性能不达标指的是合同里写了指标的。没写指标就没标准，那种只能协商着来。

八、小变更别一笔一结，攒着做

改一个字、换张图，也走一遍变更单？那太累了。

我们的做法是开个共享表。你随时往里扔，攒到三五个，我们挑个下午一次性做完。

这样做有两个好处。

一个是你不用为改一个字纠结要不要走流程。另一个是我们不用被打断七次。打断开的代价，最后是算在项目里的。

九、做到一半想停，钱怎么算

这事发生过不止一次。说清楚比藏着好。

结算分三块：

• 已经过的节点，钱照付。 原型确认过了、中期演示过了，那两笔就是该给的。
• 正在做的部分，按已投入人天算。 做了 6 个人天就结 6 个，没做完不收尾款。
• 源码和文档要交出来。 整理成能接手的样子，这部分单独算 3-4 人天。

第三条最容易被跳过。

但恰恰是这条最重要。停了不代表这堆代码废了，它能接着用。

前提是你拿得到，且看得懂。

还有一样容易漏：第三方服务的账号归谁。

支付商户号、短信余额、域名，这些挂在谁名下，停了以后就归谁。趁着人还在，一并过户，别拖。

拖过一次的都知道，找回一个绑定在别人手机上的账号有多麻烦。

十、三个项目，三种改法

案例 A：加一个"临时改约"，3 个人天

一个预约类的小程序，做到一半，客户说要能改时间。

原来只做了取消。改约比取消复杂，因为要通知到另一端。

拆开算：改约页面 1 个人天，通知逻辑 1 个人天，把已经生成的订单重新排 1 个人天。

加起来 3 个人天，3000 元。工期顺延 4 天。

他签了。后来跟我说，这 3000 花得比后面哪一项都值——没这个功能的时候，客服电话一天接二十来个。

案例 B：改结算规则，5 个人天砍成两期

另一个项目，上线前两周要改提成算法。

原来是固定比例，要改成阶梯。估下来 5 个人天，5000 元，工期顺延 9 天。

他嫌贵，也嫌慢。

我们拆成两期：第一期只做两档阶梯，2 个人天 2000 元，跟着上线；第二期做完整的，等跑一个月看数据再定。

完整的那期后来没做。因为两档够用，这是真省下来的 3000 元。

案例 C：第 6 个人天要停，结算 9000 元

去年夏天的一个项目，做了 6 个人天，客户那边资金断了。

结算：原型和中期那两笔 4200 元已付，剩下按投入的 6 个人天补 6000 元，源码交接 3000 元。

一共 9000 元。他拿走了一套能跑的半成品，外加一份部署文档。

三个月后他回来了，接着做完了。

要是当时没把源码和文档整理清楚，那三个月基本等于从头再来。

十一、常见问题

改需求要签补充协议吗？

小的不用。超过 3 个人天的建议签。因为涉及到钱和工期，口头说不清。

变更单不签，能先做吗？

能，但我不建议。做过一次，做完对方说"我没让你做这个"。那 2000 元最后是我们自己咽了。

报价里能不能包含几次免费修改？

能。很多合同会写"含三轮免费修改"。

但我更建议写成人天：含 2 个人天的修改额度。轮数说不清大小，人天说得清。

口头说一句算不算数？

算。微信里说一句"这个改一下，钱没问题"，我们截图存档，一样有效。

但口头有个毛病：当时两边都觉得说清楚了，两周后各记各的。能落到纸上还是落一下，两分钟的事。

改完之后又要改，算谁的？

看改的是什么。改完的东西出了 bug，算我们的；改完之后你又想要别的样子，那是新的变更。

这条在变更单里写清楚，就不会吵。

十二、最后说个题外话

我见过最省钱的客户，不是砍价最狠的那个。是想得最清楚的那个。

他把要什么写在纸上，改的次数比别人少一半，最后花的钱也少三成。

省下来的不是我们的利润，是他自己的人天。

十三、一句话

外包流程不是一条直线，是一段一段的。

段和段之间，靠变更单连着。

你不在乎这张纸，那十个项目里有八个要吵。记下来，剩下的两个也谈得下来。

拿不准这次改动该算多少，把要改的列出来发给我。估个人天给你，误差一般不超过一天。