软件外包项目的需求管理怎么做：从需求入口到变更签收的实操清单
外包项目最容易出问题的地方，不是写代码，是需求没管住。客户在微信里说“这里加个按钮”，销售顺口答应“没问题”，开发按自己理解做完，验收时客户说“这不是我要的”。工时烧掉，回款卡住。
需求管理不是画甘特图，也不是让 PM 当人肉传话筒。它解决三件事：客户说的算不算数，做完怎么算验收，中途改了谁买单。
一、需求只留一个入口
别让需求散在微信、QQ、邮件、会议纪要里。每个项目一个需求池，客户走客户门户，内部提需求走同一张表单。表单只问五个字段：谁提的、解决什么问题、期望结果、验收标准、期望时间。少问“用什么技术”，那不是客户该回答的。
Stepwise 的客户门户就是干这个的：客户自己提交，PM 审核后进 backlog，聊天记录不再当需求文档用。
二、写到能验收，再排期
“做一个报表导出”不能开发。至少补三样：
- 输入：筛选条件、数据范围、权限
- 输出：Excel 还是 PDF，字段有哪些
- 异常：没数据、超时、超过 5 万行怎么办
验收标准写成清单。比如“财务可按月导出订单明细，字段含订单号、客户、金额、状态；无数据时提示空结果；超 5 万行走异步导出”。开发看得懂，客户也赖不掉。
三、状态别搞十几级，够用就行
建议每个需求只放这几个状态：
| 状态 | 谁负责 | 出口条件 |
|---|---|---|
| 草稿 | 客户/销售 | 信息补全 |
| 已确认 | PM + 客户接口人 | 验收标准双方认可 |
| 已基线 | PM | 进入排期，变更走 CR（变更单） |
| 开发中 | 研发 | 提测 |
| 验收中 | 客户 | 签字或列问题清单 |
| 已验收 | PM | 归档，可结算 |
关键在“已基线”。基线之后再加需求，不是不能做，是要走变更单：加多少工时、影响哪个里程碑、费用怎么算，写清楚再动手。否则项目越做越亏。
四、变更靠记录，不靠嘴
常见坑：销售为了签单答应“送一点”，PM 不敢得罪客户，开发默默加班。最后没人知道范围怎么膨胀的。变更单不用复杂，一张表就够：变更内容、原因、影响范围、工时估算、报价、客户确认。每次变更关联原需求，后面扯皮能翻记录。
Stepwise 里需求、任务、工时、变更记录能串在一条线上，谁改了、什么时候改的、影响多少工时，都查得到。需要私有化部署的团队，数据放自己服务器。
五、每周 30 分钟对齐
PM 每周拉客户接口人和 tech lead 过一遍需求池：新需求评审、已基线需求排期、验收中的问题清单。只过三件事：哪些要确认，哪些要报价，哪些要验收。会议结束更新需求状态，不发散。
常见坑
- 把会议纪要当需求文档，没人签字
- 需求没有唯一编号，开发问“你说的是哪个”
- 验收标准写“符合业务要求”，等于没写
- 变更不报价，做完再谈钱
- 客户接口人不明确，三个人都能提需求
需求管理做到位，外包项目不一定不吵架，但吵的时候有记录、有边界、有报价依据。如果你们现在需求还散在微信和 Excel 里，可以先用 Stepwise 把需求入口、变更记录和验收签收管起来，再慢慢优化流程。
