需求管理的核心：把“大概”变成“可验收”

外包项目翻车，十有八九不是技术做不出来，而是需求没锁死。客户一句“先做出来看看”，后面就是免费返工。需求管理不是写文档，是把模糊话变成能验收、能报价、能追责的东西。入口先统一：微信、电话、邮件里说的需求，当天汇总到一个清单，别让它们散在聊天记录里。每条需求至少写清：谁用、解决什么问题、主流程、字段和权限、验收标准、优先级、提出人、期望时间。复杂页面别只写文字，画原型、给样例数据，让客户点一遍。

报价前先划边界

外包不是做产品，范围一定会变。报价阶段拿需求清单拆工作项，把“本期必须做、本期不做、二期候选”写明白。别怕写得细，前面偷懒，后面就要用加班补。

要写清的内容 具体怎么写 不写的后果
功能范围 模块、角色、核心流程、对接系统 客户觉得“顺手加一个”
验收口径 什么算通过，谁签字，样例数据 做完还说不是想要的
变更规则 谁提、谁评估、怎么计价、排期怎么顺延 口头改需求，成本自己扛

变更控制：改可以，算账

客户改需求很正常，坑在PM当场答应。做法很简单：任何变更走一张单子，写清改什么、为什么改、影响哪些模块、增加几天、多少钱、上线推到哪天。客户书面确认再开工。微信确认也算，但要截图归档。小变更别随叫随到，每周固定一个窗口打包处理，不然迭代天天被打断。需求状态也要固定：待评审、已确认、开发中、待验收、已验收、已关闭。每个状态有人负责，别一个需求挂三周没人管。

开发过程别做黑盒

需求确认后拆任务，任务挂到迭代里，提交代码关联需求编号。测试用例按验收标准写，BUG别只记“有问题”，要写复现步骤、环境、期望结果。每天站会看阻塞，每周给客户发一页进度：做完什么、下周做什么、风险在哪。外包客户最怕不知道你在干嘛，透明比事后解释便宜。

验收和收尾

验收前自己先按清单走一遍，别让客户当测试。验收单写清范围、已知问题、遗留项、上线时间、双方确认人。文档归档：原型、接口说明、数据库变更、部署文档。私有化部署的项目，再补一份运维手册。工时记到需求和任务上，下次报价、复盘都有据可查。

工具不用多，入口要少

需求池、任务、BUG、工时、客户可见的进度，放在一个地方就够了。Stepwise 把这几件事放在一起，外包团队少维护几张表，变更和验收也有记录；需要私有化部署的客户也省得反复解释。你们要是现在需求还散在微信群，先收拢入口，再谈工具。