需求管理先别谈工具，先把入口收住

外包项目最怕的不是需求多。是需求散。客户在微信群说一句，销售在电话里答应一句，开发在工单里补一句。改完没留痕，验收时谁都说不清。最后不是返工，就是拖尾款。

我见过比较稳的做法：所有需求只进一个池子。客户提、销售转、PM 补，都走同一个表单。每条写清楚：编号、提出人、业务场景、优先级、期望上线时间、验收人。聊天记录可以当补充，不能当需求文档。

Stepwise 里可以用客户门户收需求，提交后直接进项目需求池，PM 审核、合并重复项，再排期。客户能看到进度，PM 不用天天截图同步。

先分类，再答应

别急着说“这个能做”。先看它属于哪一类：

类型 例子 处理方式 谁确认
合同内需求 登录、订单列表、权限 进迭代，正常估工时 PM + 客户负责人
范围变更 新增审批流、接第三个支付 出变更单，评估工时和报价 PM + 商务 + 客户
优化建议 按钮换个颜色、加个导出 进建议池，排优先级 PM + 产品

小改动最容易漏。客户说“顺手加一下”，开发真顺手加了。月底一算工时，没人认。规矩要提前讲：涉及范围、接口、数据结构、验收标准的，都走变更单。口头答应不算数。

验收标准别写“体验好”

“体验好”这种词，最后一定扯皮。写成场景。比如：客户在订单列表按状态筛选，10 万条数据下 3 秒内出结果。再补上异常提示、字段规则、权限范围。有原型放原型，有接口说明放附件。

验收人也要写。不是“客户方”，是具体到谁点验收。没人点，需求就不算完成。

排期留缓冲，冻结要硬

需求评审控制在 30 分钟：目标、范围、依赖、风险。开发估工时，PM 加 20% 缓冲。每周冻结一次范围，插单走变更。常见坑就几个：客户直接找开发；PM 不知道；测试按旧文档测；上线前一天加需求。每个坑都能用流程堵住，前提是团队真执行。

交付和结算留一条线

每次交付列清单：需求编号、改动点、已知问题、验收人。客户邮件确认或门户点验收。遗留问题进缺陷池，别混在需求里。结算时按需求条目、工时、变更单对账，别月底翻聊天记录。

如果团队现在还是 Excel 加群聊管需求，可以先用 Stepwise 把需求池、变更单、工时和客户门户串起来。少开几次扯皮会，比多写几页制度有用。