软件外包项目的需求管理怎么做：从接需求到验收的实操清单

外包项目最容易翻车的地方，不是代码写不出来，是需求没对齐。合同里就几页功能清单，开工后客户在群里每天加需求；销售说“都能做”，研发按自己理解做完，验收时客户一句“这不是我想要的”，大家都下不来台。需求管理就管三件事：谁说了算，什么叫完成，改了怎么算钱。

合同阶段：把范围拆到能验收

别写“支持订单管理”这种大词。拆到模块、功能、子功能，再写谁用、什么场景、输入输出、异常怎么处理。订单列表不能只写“有列表”，要写字段、筛选、权限、导出上限、状态流转。

至少留三样：功能清单带优先级；原型或页面字段说明；每条需求的验收标准。

合同里写清变更条款：包含多少条需求、变更怎么报价、多久响应、上线前几天冻结。坑是写“类似某系统”“改到满意为止”，后面全是扯皮。

启动阶段：口头承诺要落到需求池

Kickoff 别只讲进度。客户、销售、研发一起逐条过需求。销售在场，客户当场提的新承诺，要么进变更，要么明确不做。

需求入口只能有一个。微信群、电话、邮件来的需求，PM 都录进需求池，给编号、提出人、业务价值、优先级、期望时间、验收人。研发别直接接客户电话改需求，接了就说不清。

原型评审让研发问三个问题：数据从哪来？异常怎么显示？和已有功能冲突吗？客户答不上来先标“待确认”。优先级让客户拍板：P0本期必须，P1可延，P2下期。PM 给建议，别替客户猜。

常见坑：把“客户说了”当需求；会议纪要不回传；需求没负责人；销售承诺没进合同。

开发阶段：需求要追到任务和工时

每条需求拆任务，任务关联需求ID。提测清单按需求走，BUG 也关联需求。上线前能回答：改了哪些代码、测了没有、花了多少工时。

变更单写清楚：改什么、为什么、影响哪些模块、加多少工时和费用、是否影响上线。客户确认后再排期。别先做再补单，补单时客户不认。上线前留冻结期，冻结后只收P0，其他走下一期或加急变更。

工时别靠回忆。研发每天记，PM 每周对。外包利润薄，变更没算工时就是白干。Stepwise 这类工具把需求池、变更、任务、工时放在一条线上，PM 不用翻三个月聊天记录对账。

验收阶段：拿基线对，不靠感觉

验收会前发清单：需求ID、验收标准、测试结果、截图或录屏。客户逐条勾。未通过项分三类：缺陷、理解偏差、新增需求。缺陷免费修；理解偏差翻合同和原型；新增需求走变更。混在一起就是免费加班。

验收单签字或邮件确认，遗留问题写清处理时间和责任人。坑是验收才拉客户看，没验收标准，把新增需求当BUG免费做。

最小节奏

• 周一30分钟需求对齐，只过变动和待确认。
• 周三变更评审，客户确认再排期。
• 上线前3天冻结需求。
• 每次验收留清单和确认记录。

需求管理不用搞很重，先把需求编号、验收标准、变更单跑起来。要是你正被变更拖住，下个项目让每个需求都有出处、有负责人、有验收标准。Stepwise 也就是帮外包团队把这些记录串起来，少在群里翻旧账。