需求模型.png
先放上一个图，这个图是“乌木说需求”系列的基础哦，首先先对模型做一些解释：
需求的产生一般有三个来源，用户、竞品和自己。而所谓用户，可能是产品的真实受众，也可能是公司的操作人员（比如客服）。需求一旦确立，我们就需要对需求进行处分析和处理，或者放大或者缩小，然后将其传递到需求池中进行管理。需求传递的目的在于减少信息损失，而针对需求池，我们应力求池子水量的合理和输入输出的平衡。在最终传递到开发之前，我们还需要对需求进行方案设计，方案的目的是解决问题并尽可能维持产品系统的整体统一。
“乌木说需求”的第一节先来聊聊需求传递
需求传递的目标只有一个，减少信息损耗！！！当然这是默认在接到需求后你已经进行过需求调研和挖掘，这个在之后讲需求处理的时候会细说。
重要的事再说一遍，需求传递的目标就是减少信息损耗，那么如何减少损耗呢？需求的传递一般有两个方向，一个是输入需求池（接受需求部门的提案），一个是输出需求池（给到技术、ui等等角色开发）。求人的总处于弱势，所以对于需求提出方来说，我们是优势部门，而对于开发部门来说，我们是弱势部门。
所以需求传递的原则很简单，针对需求来源方，尽可能多的来回沟通，确保信息无误。针对需求输出方，尽可能的精简需求传递步骤，减少干扰。
先说对接需求来源方的会用到的工具：
- 纸笔，当面沟通的神器。
- 邮件，正式通知。
- 即时通讯，非当面沟通神器。
然后说一说对接需求来源方时的工作步骤：
- 接受需求，需求的提出可能来自于口头也可能来自即时通讯，但我们必须确认正式提出的需求一定用邮件来发，否则不受理。
- 初步了解需求之后，列出所有的疑惑点，带上纸和笔当面和需求提出人一步一步进行确认，确保你的理解是没有错的。
- 分析挖掘需求，这点之后的章节会详说，（所以大家记得公众号搜索wumuwizard，简书@乌木，哈哈）
- 回来后用邮件正式把你们达成的共识回复给需求提出方并且抄送给自己部门的老大。
- 不允许再变更需求，如需变更，重新提案。
接着说需求输出方会用到的工具：
- 邮件。
- 即时通讯。
- 能不当面打扰就尽量不当面打扰吧。
针对需求输出方的工作步骤：
- 精简和易读化方案，这点一样在之后的章节细说（不打广告了T-T）。
- 发送正式的邮件和方案，并表明会对方案进行当面沟通。
- 当面沟通，了解技术难点，（这里注意了，技术说不能实现时，千万要打破砂锅问到底，了解明白为什么技术上不能实现，不要被忽悠了）。
- 酌情更改方案，并告知需求提出方，这一步比较麻烦，尽可能的不做这一步。
- 确认技术的排期，不允许拖延，拖延需要有很合理的原因。
- 尽量不再打扰，等待验收。
乌木的需求模型一定有很多不完善的地方，真心的欢迎大家以各种联系方法来告知我你们对需求模型的建议（联系方法正文已有广告，哈哈），感谢啦。最后附上思维导图一份哦
需求传递思维导图.png
