做外包的都遇到过这种事：客户在群里发一句「这个按钮改一下」，项目经理顺手转给开发，开发改了两天，验收时客户说「我没让你改这个」。然后开始扯皮。需求管理做不好，很多时候不是文档写得少，是没人把「谁在什么时候改了什么」记清楚。

先分清两类需求：合同内的和合同外的

外包跟自研不一样。自研的需求可以慢慢排优先级，外包的需求先看合同。合同范围里写清楚的，走正常迭代；合同范围外的，先出变更单、报价、客户签字，再动手。很多项目亏钱，就亏在「先做再说」。

建议在需求池里加一个字段：合同归属。选项就三个——合同内、合同外（增补）、待确认。每周跟客户过一次「待确认」，别攒到验收前。

需求卡别写成长篇小说

一张需求卡写清楚四件事就够了：谁提的、要解决什么问题、验收标准是什么、什么时候要。验收标准最好能写成「给谁看、看到什么、点哪里、出现什么结果」。写不出来的，说明需求还没聊透，别急着估工时。

一个需求从进来到验收，走完这五步

  1. 收集：客户那边只留一个入口。别让销售、实施、开发各自接需求。统一进需求池，谁提的、哪个项目、什么时间，一条记录。
  2. 澄清：项目经理拉客户对一遍，把「大概」「差不多」「你看着办」翻译成具体的页面和操作。这一步花半小时，后面省两天。
  3. 拆解与估算：开发拆任务、给工时，PM 把工时跟合同里的人天对上。超了就要预警。
  4. 变更控制：需求一改，先判断影响——工期加几天、费用加多少。出变更单，客户确认后再排期。
  5. 验收归档：每个需求挂验收标准，做完逐条对。验收通过的关掉，没通过的回到需求池，别口头说「下次一起改」。

几个常见的坑

  • 微信群拍板。聊天记录不是合同，客户换个对接人就说不清。重要结论回到需求卡里，让客户在门户点确认。
  • 需求文档写成一本书。没人看。一页纸的需求清单加验收标准，比五十页文档管用。
  • 开发直接对接客户。听着高效，实际上变更没人记录，工时也没人算。
  • 验收标准写「界面美观」「操作流畅」。这种话验收时一定吵架。

工具不用多，能把状态和变更串起来就行

我们用 Stepwise 管这块：需求进需求池，状态从「待澄清」到「开发中」到「待验收」，每一步谁改的、什么时候改的都有记录。需求卡上直接挂验收标准和关联工时，客户在门户里点确认，变更单跟着需求走。私有化部署的客户，数据放在自己服务器上，这点对外包公司谈客户时挺加分。

需求管理不是把文档写漂亮，是让「客户说的」和「我们做的」能对上。改了什么、谁同意的、加了多少工时，翻记录能查。做到这一步，扯皮少一半。