软件外包项目的需求管理怎么做

外包项目翻车，十次有八次不是技术问题，是需求问题。合同签了 30 万，做到一半甲方说「这个功能不是本来就应该有吗」，你说没有，他说合同里写了「等」字。

下面这些是踩过的和见过的做法，不谈方法论，只谈怎么少赔钱。

一、需求只能从一个口子进来

最常见的场景：甲方老板在饭桌上跟你们销售提了一句，销售答应了，开发不知道，验收时变成「你们答应过的」。

定死两条：

群公告直接写：「需求请提到 XX，口头沟通不作为交付依据。」丑话说前面，比后面吵架体面。

别写成一本书，没人看。六样东西就够：

最容易被糊弄的是验收标准。写「界面美观、操作流畅」等于没写。要写「导出 Excel 含订单号、客户名、金额三列，1000 行以内 5 秒出结果」。甲方签字时可能嫌你啰嗦，验收时会感谢你。

外包最危险的结构是：总价包死 + 需求模糊。

澄清会上这几件事问不到，就先别报：

问完出一版需求清单，让甲方项目负责人签字。这一版就是你的边界，后面所有「这个也要」都从这儿开始算。

没有不变更的外包项目。决定这个项目赚不赚钱的，是变更怎么处理。

变更单写四件事：改什么、多几天、多多少钱、影响哪个里程碑。24 小时内给回复，别拖——拖三天甲方就觉得你效率不行，还觉得这事不严重。

规矩提前定。合同里写清楚「验收前 3 次小变更免费，超出按人天计」。第一次免单是人情，第二次开始走单是本分。关键是提前说，别等做完了才翻脸。

按人天结算的项目，需求和工时要是两张皮，结算那天一定吵架。

做法很简单：每条需求挂工时，谁做的、做了几小时。月底或者里程碑拉一张表，超支的需求一眼就能看出来。

超了要复盘：是需求没写清造成返工，还是当初估算拍脑袋。这个数据攒上两个项目，下次报价心里就有底，不用再靠「感觉差不多」。

一半的扯皮来自信息不对称。甲方不知道你在干嘛，就只能催；催多了你觉得他烦，他觉得你拖。

每周一页纸就够：上周做完哪几条（带编号）、本周计划做哪几条、有哪些需求在等甲方确认、等了多少天。

最后一条最有用。「REQ-017 等贵方确认接口文档，已等 6 天」——写上去，责任就清楚了。

这些事用表格加微信群也能跑，就是项目一多、人一多必散。Stepwise 里需求条目、变更记录、工时统计和客户门户在一条线上，改一条需求能直接看到影响哪个迭代、多花多少工时，省掉不少来回对账。手头有项目的话，挑个小的先跑两周看看。