外包项目最怕的不是代码写不出来，是做完客户说“这不是我要的”。需求管理不是写一本厚文档，而是把四件事定清楚：谁提、做什么、怎么验收、改了谁买单。这四件事含糊，项目后面一定吵架。
先把需求入口收拢
需求散在微信、电话、邮件、会议纪要里，最后没人认账。客户跟销售说一句，销售跟PM说一句，PM跟开发说一句，传到开发耳朵里已经变样。
做法很简单：只留一个入口。客户提需求进需求池，销售或PM先登记，写清提出人、使用场景、期望时间、优先级。开发不直接接客户口头需求，要接也先在需求池里补一条。有客户门户更好，客户自己提单、看进度，少掉很多“我问一下”的来回。Stepwise 的需求池和客户门户就是干这个的，至少让每条需求有主、有状态、有记录。
需求拆到能验收，再排期
“报表要灵活”“权限要细一点”这种话没法排期。不是开发听不懂，是每个人心里的“灵活”不一样。
拆成用户故事和验收标准：谁在什么场景下做什么，结果是什么，异常怎么处理。拿导出Excel举例，验收标准要写到字段有哪些、筛选条件是什么、谁能导、10万行大概多久、失败怎么提示。写到这个程度，开发和客户才不会各说各话。
| 需求项 | 验收标准 | 优先级 | 预估工时 | 验收人 |
|---|---|---|---|---|
| 订单导出Excel | 支持按日期/状态筛选；字段固定12列；权限跟随角色；10万行5分钟内；失败有提示 | P1 | 3人天 | 客户对接人 |
| 角色权限配置 | 可新增角色；按菜单和按钮授权；变更后立即生效 | P1 | 2人天 | 客户对接人 |
表不用漂亮，能把“做完没有”说清楚就行。验收标准最好让客户确认一遍，哪怕只回一句“可以”。
变更要收费，也要留痕
外包利润经常被变更吃掉。不是不让改，是每次改都走影响评估：影响哪些模块、加几天、加多少钱、原排期怎么变。变更单至少三件事：客户书面确认、PM更新需求基线、开发按新版本做。
常见坑是先做再补单。做的时候客户说“这个小功能顺手加一下”，PM不好意思拒绝，顺手三次，项目就亏了。还有客户直接找开发改个字，开发改了没记录，验收时对不上。Stepwise 里变更记录能挂在需求下面，工时也能关联，扯皮的时候至少能翻账。
每周对焦，别等验收才见客户
每周30分钟需求对焦会，讲四件事：本周完成什么、下周计划什么、哪些问题待客户确认、有没有变更。客户不来就发书面纪要，别默认他同意。
让客户早点看到能点的东西，比最后看文档有用。验收前一周冻结需求，只收BUG不改范围。要改，走变更。这个规矩提前说，别到上线前才翻脸。
需求、任务、BUG、工时串起来
需求ID要从头跟到尾：需求→任务→BUG→工时→验收。没有这条线，项目复盘只能拍脑袋。外包还要多留个心眼：私有化部署的客户环境差异、数据迁移、第三方接口，这些单独列需求，别混在功能开发里，不然工时永远对不上。
交接也一样。需求文档、验收记录、变更单归档，客户换对接人、团队换人，都能接得上。
几个常见坑
- 把POC当免费需求，做着做着变成正式范围。
- 销售承诺的功能没进需求池，PM排期时才知道。
- 需求文档写完没人更新，开发看的还是旧版。
- 验收标准写“符合业务要求”，最后只能靠吵架验收。
- 客户绕过PM直接找开发，开发不好意思拒绝。
需求管理不复杂，难在坚持。先把入口、验收、变更这三件事跑顺，项目能少吵一半架。用 Stepwise 的话，可以先从一个需求池和客户门户开始，把口头需求变成能追踪的记录。
