软件外包项目的需求管理怎么做｜从入口到验收的落地方法

外包项目最怕的不是技术难，是需求一开始就没说清。客户在微信里甩一句“做个审批”，销售先答应，PM 拉群开会，开发照着自己的理解开工。两周后演示，客户说“我不是这个意思”，返工、加人、延期，最后大家都不痛快。

需求管理不是写一份漂亮文档，而是把“谁要什么、做到什么程度、变了怎么办”管住。

1. 需求只留一个入口

别让需求散在微信、邮件、会议纪要里。每条需求进一个池子，记清来源、客户、提出人、业务场景、期望时间、验收人。谁都能提，但只能进这个池子。Stepwise 的需求管理加客户门户就是干这个的：客户提需求，内部评审后转迭代，状态客户能看到，少很多“做到哪了”的追问。

客户说“加个导出”，先问：导给谁看？多久导一次？字段有哪些？数据量多大？要不要权限？导出失败怎么通知？需求卡至少写清：

尤其“不在范围”要写。外包扯皮，多数是边界没写。

评审不是 PM 给开发念文档。客户业务负责人、最终用户、开发、测试都要在。输出三样：问题清单、决策记录、原型或流程图。会上没定的事写“待确认”，别默认。客户老板拍板，不代表最终用户能用。

版本开始前，把需求清单冻结成基线。后面新增、修改、删除都走变更单：影响哪些功能、增加多少工时、费用谁承担、上线时间变不变。口头说“顺便改一下”不算。关系好可以先做，但变更单要补，不然项目越做越亏。

需求别停在文档。每条需求拆任务，关联迭代、负责人、预估工时。开发每天更新状态，PM 看阻塞，不看“感觉”。Stepwise 里需求、任务、工时、BUG 能串起来，客户门户只看他该看的进度和验收项。

别等 UAT 才问“怎样算通过”。每条需求写验收清单，比如：审批通过后状态变“已通过”；驳回必须填原因；附件不超过 20MB；列表按提交时间倒序。越具体，返工越少。验收人邮件或系统确认，别只靠群里一句“可以”。

需求变更率、返工工时、验收一次通过率。每周看一次。变更率高，说明前期没问透；返工工时涨，说明评审或测试漏了；一次通过率低，说明验收标准太虚。

常见坑就几个：需求入口太多、范围没边界、变更不评估、验收靠感觉、客户看不到进度。工具能解决一部分，剩下靠流程和脸皮——该问的细节要问，该签的变更要签。

如果你们现在还在用 Excel 加微信群管外包需求，可以先从“一个入口 + 一张需求卡 + 一张变更单”开始。Stepwise 把这些做成现成流程，私有化部署也能用，省得自己拼表格。