需求人员作为项目的源头，他们直接对接客户或市场，他们决定着项目的实际走向，甚至成败。在过去的几年中，无论是作为测试人员还是项目经理，都与需求人员有过深度的合作。其中有两个更是以需求人员的身份参与了项目。在总结了合作过的需求人员和自己亲身经历之后，我发现需求在项目中永远绕不开的是下面4个问题近些你那需求人员作为项目的源头，他们直接对接客户或市场，他们决定着项目的实际走向，甚至成败。在过去的几年中，无论是作为测试人员还是项目经理，都与需求人员有过深度的合作。其中有两个更是以需求人员的身份参与了项目。在总结了合作过的需求人员和自己亲身经历之后，我发现需求在项目中永远绕不开的是下面4个问题：
```
1 项目启动过程中的需求如何能做到更高的准确度，即需求人员如何能做对第一版需求
2 项目过程中需求人员如何做到拥抱变更，即如何控制需求变更
3 二期项目如何挖掘全部与往期项目的关联
4 如何做到闭环需求，即如何确保新功能或变更点的相关分析是闭环
```
针对上述问题，我们逐条的不太严谨的（没有太多详细数据支撑，可能会存在偏差）分析一下。
**1 项目启动过程中的需求如何能做到更高的准确度，即需求人员如何能做对第一版需求**
在整理这部分内容的时候发现了一个很有意思的事情，我们最常见的2个月左右的项目中，需求文档版本更新往往能达到三四十个版本，极端项目甚至近百个版本。这些版本迭代中，虽然没有精确统计发布类型（也是工作中欠缺的一环），但属于需求变更的所占极少。大部分版本迭代都是由于需求错误导致的。
这些错误大概有以下几类：
1 开发或测试过程中发现需求逻辑错误
2 开发或测试过程中发现需求中重要场景缺失
3 开发或测试过程中发现需求描述前后矛盾
4 开发或测试过程中发现需求描述错误（错别字等）
错误归类也表现的很有趣，都是【开发或测试】 阶段才能发现需求的错误，为什么没有需求自查发现的错误呢？因为没有时间自查。在第一版需求发布之后，项目之后的流程就随之展开，而需求人员此时将要面临的就是来自项目组的问题轰炸，一部分讲解一部分改错。既然没有自查，那问题就只能放到下一阶段被内部客户（开发和测试）挖掘了。而此时暴露的错误就不再是改个文档那么简单了。开发修改、测试重测甚至推翻重做带来都是周期的延长和成本的增加。
开发不能自查可能受限于多种原因，如项目周期，如并行工作等等。正因如此，需求人员如何做对第一版需求，变成刚需。结合自己短暂的需求工作履历，总结了两个可尝试的突破点：
**积累业务背景，挖掘客户痛点**
想不清楚往往是因为陌生不熟悉，如果分析自己每天都用的或非常熟悉的需求，不能说不出错，但至少出错的概率会非常低。但是项目需求是各种各样的，怎么在短时间去熟悉呢？一个字“聊”，两个字“引导”，三个字“讲故事”。
怎么聊呢？没啥特殊的，就是可劲儿聊，有互动的聊，千万不能光听客户一个人在那说。只有互动才能得到更多的信息。但是大家聊天都会有一个共性的问题，聊着聊着就沉浸在自己的世界了，也就是跑题或者发泄情绪了，这个时候再聊下去就都是废话了。那改怎么办呢？引导。引导客户往业务上聊，引导客户往工作痛点上聊。他越聊得慷慨激昂，越是要引导他说出重点。挖到痛点怎么办？讲故事。你给客户讲一个用户故事，验证一下你的理解是不是对的，如果客户认同，说明你理解对了。如果客户不认同，那就接着聊。
**体现专业，利用工具**
我看到的和我自己实际干的时候，都是先出功能列表，画流程图，然后画原型，写文档。看似很合理的流程，却又不那么合理。
功能列表更多的是堆砌，功能是否合理，相互关联等几乎等于零思考。流程图涵盖不全，此阶段的流程对整理项目过于简洁，颗粒大到某个模块之后对应某个模块，如加工之后到审核，一条线搞定。原型和文档更是建立在前两项基础上的纯码字输出。
流程图是项目需求的核心框架，需要花更多的精力来处理，纵不能做到与开发的详细设计一样，也至少应包含业务逻辑和数据流转。画流程图可能是需求分析的吃饭家伙了，但是又有几个人能对着流程图清晰的讲解系统逻辑与数据流转。
至于工具，这些年觉得对工作帮助最大的就是思维导图。无论是逻辑的梳理还是场景的扩展，一图在手，等心应手。
**2 项目过程中需求人员如何做到拥抱变更，即如何控制需求变更**
变更对于项目一直如梦魇般存在，但是“唯一不变的就是变化”确实这个世界的真理。 近些年大热的敏捷项目管理也在提倡拥抱变更，那做为需求人员处在这个不断变化的项目环境中，该如何拥抱变更呢？
