（二）需求
产品经理存在的价值就是通过需求分析把用户提出的需求转化成产品需求。确定需求的基本属性、分析需求的商业价值、初评需求的实现难度从而计算出需求的性价比。
资源总是有限的，我们需要通过残酷的需求筛选，只做那些性价比高的事情。
对产品经理来说一个很重要的点就是：发现一个问题，然后设法转化为一个任务来解决
用户是需求之源
人类之所以有需求，是因为生活中存在太多的问题，从而产生了不满意，而问题就是“理想与现实的差距”，那么人类会很自然的产品“减少甚至消除这个差距”的愿望，这就产生了需求。比如：工资低，出行不方便，食物不好吃，房租太贵，生活中处处是问题……
产品存在的价值就是解决问题，满足用户的某些需求，用户提出需求时，往往说的都是用户自己知道的针对自己的需求的解决方案，但往往用户提出的方案都不是解决用户问题最佳的解决方案，这个时候作为产品经理，我们要做的就是多问几个为什么，找到用户真正的需求，提供最佳的解决方案。
小敏说：我需要买一个电钻
小红问：为什么？
小敏说：我想在墙上打个洞
小红问：为什么？
小敏说：我想要把一幅画挂在墙上
小红问：为什么？
小敏说：因为这面墙显得太空旷了，看着不舒服
小红问：为什么？
小敏说：因为太空旷就没有家的感觉，不够温馨
小红问：为什么？
小敏说：wennimei...
马斯洛需求层次理论：生理需求、安全需求、社交需求、尊重需求、自我实现需求。
从上面的例子我们可以发现小敏真正的需求是想让家里看起来更温馨，更有安全感，归属感。。。
通过上面的例子我们可以发现，通过研究需求，多问为什么，可以增强对用户的理解，理解用户是产品经理最重要的素质之一。
用户&客户
用户（End user）：使用产品的人
客户（Customer）：购买产品的人、为产品付钱的人
UCD（User Centered Design）：以用户为中心设计
BCD（Boss Centered Design）：以老板为中心设计
作为产品经理要尽可能地帮助老板明确问题和需求的价值，为其决定方向提出参考建议，或协助其实现目标。
不要试图满足所有的用户
试图满足所有用户的需求是一个灾难，会让产品变的臃肿不堪，谁都不满意。
我们应该结合产品的商业目标给用户排优先级，明确优先满足哪些用户的需求。
对于小公司，产品一般倾向满足大量一般用户的需求是为了让用户数快速增长。对于大公司产品倾向于关注核心用户的需求，是因为用户数已经见顶或者增长缓慢，需要在已有的用户身上深挖用户价值。
用户研究的方法
横向，用户的说 & 做
用户怎么说表现了目标和观点，用户怎么做反映了行为，用户怎么说和怎么做经常是不一致的。虽然用户很多时候说的不一定是真话，但是如果不听用户怎么说，只了解用户怎么做，很难知道用户背后为什么要这么做。
纵向，定性 & 定量
定性研究可以找出原因，偏向于了解，而定量研究可以发现现象，偏向于证实。
- 比如：
- 听用户定性的说，确定产品方向，做什么？随机抽样40个用户做访谈，据此写出需求列表。
- 听用户定量的说。确定需求优先级，先做什么？投放20万份调查问题，确定了需求优先级的排序。
- 看用户定性的做，要先做的那几个需求，应该怎么做？一边设计，一边陆续找了10个用户来验证，做可用性测试。
- 看用户定量的做，根据产品的用户使用情况做数据分析，不断改进产品。
需求采集
- 明确目标
- 选择采集方法
- 制定采集计划
- 执行采集
- 资料整理
- 需求分析
定性的说：用户访谈
找到几个或几十个用户针对事先准备好的特定问题通过一对一的聊天了解用户的问题，从而转化成需求。
一般在新产品的前期的调研工作中或者通过数据发现现象以后，去找到现象背后的原因。
常见问题与对策
- 问题一：说的和做的不一致。
- 出现这个问题的原因可能是用户自己也不知道自己喜欢哪个，也可能是我们问问题的方式有问题。
- 比如：
- 现在有红色的、金色的、白色的、黑色的iPhone X放在用户面前，让用户选择一个，用户可能会告诉你喜欢金色的，但也可能最后选择了白色或者黑色的，最后选择白色或黑色的原因可能是安全，大众色。在这个案例中，用户也不知道自己真正喜欢哪个颜色，很纠结~
- 现在有两辆车放在用户面前，一辆炫酷的黄色，一辆保守的黑色，你问用户喜欢哪一辆，用户可能会告诉你，喜欢黄色的，但真正买的时候会买黑色的。原因就是问的方式由问题，喜欢的角度单单只需要考虑当下的感受，但是买的时候还要考虑各种现实中的使用场景，所以这个情况下是问的方式，问问题的角度有问题。
- 问题二：样本过少，导致以偏概全。
- 出现这个问题的原因是往往基于成本考虑，我们只能选择相同城市的用户，而且数量也有限制，相同城市的用户是对用户的第一次筛选，导致这些用户这产品的整体用户有了差异。
- 解决方案：首先找出可能引起差异的因素，在访谈报告中注明，让读者了解到。通过增量的方式做用户访谈，具体实施比如先选取5个用户得到一个初步的结论，再选5个用户，看结论有没有变化，如果有继续增加访谈的用户，如果没有，结束访谈，节约成本。
- 问题三：用户过于强势，导致访谈时跑题。
- 问题四：产品过于强势，导致用户难以表达真实的想法。
- 有些时候因为产品是自己开发的，我们的产品受到质疑的时候，难免会想要为自己辩解，这个时候我们要记住自己的目的，尽可能倾听用户的想法，即使自己不认同，也要尽可能想想为什么用户会这么想。管好自己的嘴。
- 问题五：避免一组固定的问题：固定的问题会让访问者有被审问的感觉，我们应该准备好问题清单，但是清单只有一个引导的作用，不用照着顺序问。
- 问题六：首先关注目标，任务其次，比用户行为更重要的是背后的原因，多问问用户为什么这么做。
- 问题七：避免让用户成为设计师，听用户说，但不用照着用户说的做，用户的解决方案通常短浅、片面。
- 问题八：避免讨论技术，记住我们的目的，避免和用户套路产品的实现方式。
- 问题九：鼓励讲故事，讲故事是最好的帮助设计师理解用户的方法。
- 问题十：避免诱导性的问题，典型的问题比如：如果有xx功能，你会使用吗？
定量的说：调查问卷
用户访谈时，我们会通过很多开放性的问题去了解用户的需求，寻找新产品的方向。一般只能和较少的用户进行深入的交流。调查问卷可以和相对大量的用户进行浅层次的交流，可以获取一些明确问题的答案。
用户访谈中我们通过开放式的问题为调查问卷收集封闭式的问题。
调查问卷的好处
- 调查问卷一人一卷，独立填写，可以解决“焦点小组”，论坛发帖征集需求这种群体性讨论性质的的方法的弊端，在网络这种不用负责的环境中，部分最先开始表达的用户的观点，引导了群体性用户的观点。只有当你和那些跟风的用户单独聊，你就会发现他们可能并不是这么想的。
常见问题及对策
- 问题一：样本的偏差，即样本和想要了解的用户群体出现偏差。这种情况下，我们就要保证样本尽可能覆盖我们的用户群里，比如：性别、年龄、行业、收入。如果我们的用户群里男女比例是7：3，那么我们的样本最好也要保持这个比例。在实际的工作中我们难免没办法做到样本和用户群体完全吻合，这个时候我们最好在问卷上把样本和用户群体潜在的差异注明，然后问卷读者可以了解这些差异，带着疑问去阅读。
- 技巧：在问卷中增加一些群体特征的问题，在手机问卷结果时可以根据群体特征筛选问卷。
- 问题二：样本数量过少，如果我们只有10份问卷，其中有6个人的的答案相同，我们就理解该答案的比例达到60%是不合理的，再增加10个用户，可能答案就不是60%了，我们可以通过增量的方式，让答案趋于稳定。
- 问题三：问题的表述方式，我们要尽量避免引导式的疑问，比如：你喜欢某某功能吗？用户可能为了照顾提问者的情感说是，我们应该这样问：你是否喜欢某某功能？答案的顺序可能会影响用户的选择，打分式的问题用户趋向于选择中间分值，这种细节在设计问卷的时候都要考虑到，比如通过打乱问题的顺序，答案的顺序，尽可能减少这些因素影响问卷的结果的可靠性。
- 技巧：通过小范围试答，根据结果修改和调整问卷，防止出现上述问题是一个很好的避免上述问题的方式。
定性的做：可用性测试
可用性测试是通过让实际的用户使用我们产品来发现产品中的问题。一般只能找到较少的用户来使用产品，测试产品的可用性。
进行该测试，首先我们要找到最好能代表产品用户群体的测试用户。比如该产品的用户都是新手，那么我们找到的最好也是新手。然后准备测试任务，测试的组织者在测试前就要准备好任务，这些任务应当是产品实际使用中典型的任务。
接下来是用户通过使用产品完成我们事先安排好的任务，观察用户操作的全部过程，并把问题都记录下来。过程中也可以询问用户为什么要这么操作，以及用户对产品的主观看法，鼓励用户在使用过程中把自己使用产品的思考过程说出来。
最后是根据用户测试过程中的信息整理出一份可用性问题列表，根据问题的严重程度给问题分级，根据项目的进度考虑优先处理哪些问题。
常见问题及对策
- 问题一：如果可用性测试做的太晚，发现问题也于事无补。所以可用性测试在任何时候都可以做，在没有产品的时候可以拿竞争对手的做，在有了原型之后，可以拿手绘的产品做，在有了Demo后，可以拿Demo给用户做，在产品可以运行后，拿可运行的产品给用户做。不同阶段，不同做法都可以发现相应的问题。
- 问题二：看不到可用性测试的价值，或者觉得麻烦，不做可用性测试。
虽然可用性测试的收益无法量化，往往因为老板不在意或者项目时间过紧没做。一般可用性测试有5个左右的用户就可以发现常见的问题，但实际上哪怕只做一个也比没做好，一个用户，半个小时，几个任务往往可以发现不少问题。 - 问题三：跟用户明确我们是测试产品，而不是测试用户。
在可用性测试开始之前，我们应当明确告知用户，我们的目的是发现软件中存在的问题，而不是测试用户是否有能力使用这个产品，这样能保证用户尽可能在真实的使用场景下使用我们的产品，减小用户的压力。 - 问题四：测试过程中组织者该做的和不该做的
组织者应当在测试开始前明确告诉用户测试的内容，持续的时间，保证用户心中有数，在轻松的接近真实使用场景下完成任务。
组织者应该鼓励用户在测试过程中说出自己的思考过程，比如为了完成某个任务，用户打算先做什么，后做什么，为什么要做这个操作。
组织者在测试过程中不能有任何引导和提示，因为任何引导和提示都有可能导致原本存在的问题没有暴露出来。用户预想的和实际不一样的时候可以提问，实在进行不下去了，可以提问，保证可以进行下去。
记住：一些的问题都是产品和我们的问题，用户一定没有问题，即使觉得用户有问题，也是你找错人了。
在产品进行一次大的改版的时候，一定要尽早做可用性测试。不然一旦产品研发结束，可用性测试不过，就是一个灾难。QQ在2013年去除了隐身、离线功能，最后引起了用户的极大不满，迫于压力又改回去了。
如果可用性测试做的比较晚，也有补救的方法：1. 先从次级页面开始改；2. 新旧版本共存一段时间；3. 小面积实验，针对一小部分用户放出新版本，监测效果；4. 改成一个用户已经习惯的风格；
定量的做：数据分析
只要我们做的产品用户量很大，互联网产品基本都是，那么我不管是用户访谈，还是调查问卷都只能覆盖到整体用户的很小部分，这部分还可能是被筛选过的，比如测试用户得同意做这个测试。
数据分析，我们可以覆盖到大多数用户，且数据是最难被反驳的，用数据证明自己的决策是最有说服力的，就像对程序员来说，说的再好，不如：show me code！
数据的来源有：产品的日志、客户管理系统中的信息、网页访问情况的统计信息。根据不同的目的，来源不同。
数据分析的方法：Excel、统计软件、数据库软件、甚至直接通过Python写程序解决问题。
通常数据分析只能发现问题，没办法了解到原因，所以数据分析后可以通过用户访谈等等方式，听听用户的想法从而找到原因。
常见问题及对策
- 问题一：用户怎么说和怎么做是两回事，甚至怎么说和怎么做都会矛盾。通过用户的行为更能发现用户的真实需求，比如用户提出增加某个功能，根据用户提出的需求增加这个功能后有可能发现这个功能只有整体用户的1/100000使用了。那么这个功能的性价比其实很低，甚至该功能是可以通过一些操作替代的，就没有太大做的价值。
- 问题二：实际的生产环境注重性价比，不需要做出非常详细、严谨的数据分析，而是要在最小代价和最大价值之间达到一种平衡。产品经理需要锻炼自己对数据的敏感、对商业的敏感。
- 问题三：无意的误读数据，比如人的身高满足正太分布，取平均值是有意义的，但是对于收入，你和马云一平均，你都能上福布斯榜单了。统计学对于数据分析很重要，好好了解和学习。
- 注意：主动误读数据，我们在提取数据之前，心中往往都有一些结论了，数据分析的时候往往就注意到数据能验证我们结论的部分，忽视了数据中其它有价值的内容，甚至故意把数据往自己的结论上靠，去证明自己的决策多么英明。对于这个问题，我们要保持对数据的一个中心态度，在做数据分析之前要尽量排除已有结论对数据分析结果可能的干扰。
- 问题四：在设计产品的时候没有考虑到后期的数据分析，当产品上线后真正需要分析数据的时候，无数据可分析。对于这点，我们在设计产品的时候就要尽可能把将来可能需要的数据分析的需求加进去，比如记录用户的登录次数等等。
需求采集
-
单项需求卡片
工作中我们经常会接到来自运营、销售的需求，这个时候需求往往是简单的几句话，很难清楚的百分百理解需求，这其中的偏差往往要通过邮件等方式反复沟通来弥补，单项需求卡片就是解决这个问题的一个比较好的方式。
单项需求卡片模板
一个单项需求卡片包含的内容有一个用户在什么时间，什么地点，什么场景下产生了何种需求。很多时候我们永远也想不到用户会怎么使用我们的产品，单项需求卡片上面的内容，很多时候填写的会不完整，这时候我们需要主动和填写的人交流，完善卡片的内容。 -
多采集需求
需求采集不是只发生在产品设计之前，而是一个贯穿始终的过程。需求采集并不仅仅是产品人员的工作，而是所有的人的事情，要尽可能多的采集需求，不怕遇到什么奇怪的需求，而是怕遗漏合理的需求。 -
现场调查
和用户一起工作一段时间，深入了解用户的需求，由于受众面窄，要注意防止被“非典型”用户带偏了。 -
AB测试
当用户量很大，对于某个功能我们有几种方案无法确定哪种好，我们可以通过AB测试来判断。比如一个按钮放到左边还是右边好，我们无法确定，我们可以挑选部分用户，1000个放左边，1000个放右边。一段时间后分析结果，再决定真正上线时按钮位置。相当于让用户也参与了设计。 -
日记研究
很多业内的朋友会使用产品，写使用体会。这些体会可以带着疑问去参考，毕竟写这些的不一定是产品的“主流”用户。 -
卡片分类法
把产品的需求写在一张张卡片上，和用户一起讨论完成功能结构分类。用户的思维可能和产品不一样，如果产品来给功能结构分类可能会导致用户理解困难。 - 已经发布的产品，已经有用户的产品都会有一些粉丝，这些粉丝会主动给产品提需求。
- 注意：自己的产品做久了，容易对产品产生越来越完美的想法，主要是因为产品是自己设计的，导致会对产品特别的熟悉。所以要尽可能让更多的人来使用它，让他们来给我们的产品挑问题，提需求。
需求分析
有的用户在提需求时会同时给出一个解决方案，我们应该直接使用用户的参考方案吗？答案是很明显不，原因是用户很多时候给出的方案都是没有经过认真深度思考的，只是根据表明现象给出的一个最明显的方案，这个方案很可能很多时候都是自相矛盾的，经不住推敲的，即使用户给的方案看起来挺靠谱，我们应该听用户的按用户说的做吗？答案仍然是不，即使用户给的方案看起来还不错，作为产品经理，我们也要深挖用户内心的需求。比如之前的例子小红发现小敏表面上时想买一把锤子，如果只看表面现象，我们最多也只能提供一把最好的锤子，但是经过深挖用户内心的需求后，我们发现小敏的真正需求是安全感，家的感觉。那么我就有很多种方案可以提供给小敏，让小敏的家更有安全感，更温馨。这些方案可能性价比更高，效果更好。
深挖用户内心真正的需求也是产品经理的价值，用户需要一匹更快的马车，福特给了用户一辆汽车。想要一批更快的马车是用户需求，一辆汽车就是产品需求，产品经理就是要根据用户需求，找到真正的产品需求，用更好的产品去满足用户的需求。从用户需求到产品需求的过程就是需求分析
用户需求 VS 产品需求
用户需求：用户自以为的需求，并且经常表达为用户的解决方案。
产品需求：经过我们的分析，找到真实的需求，并且表达为产品的解决方案。
需求分析：从用户提出的需求出发，找到用户内心真正想要的，再转化为产品需求。
需求分析的思路：树枝 -> 树干 -> 树枝
先根据用户表达的需求（树枝），通过需求分析找到用户真正想要的（树干），然后根据用户真正想要的给出最好的解决方案（树枝）
小露：我想吃火锅（树枝：用户提出的需求）
小方：为什么？（找真正的原因）
小露：我饿了（树干）
小方：火锅店太远，这里有一些燕麦粥，吃这个吧（提出更好的解决方案）
销售人员经常会说：用户想为想要的东西买单，而不是需要的。用产品的话来说就是：用户愿意为自己提出的需求买单，而不是我们给出的解决方案。这个问题要看我们对用户的服务是长期的还是短期的，如果是一锤子买卖，那么就尽力满足用户想要的，这样成交几率最大。但是如果是长期的，后续我们还要继续为客户服务，希望客户满意我们的服务，从而更愿意使用我们的产品，购买我们的服务，那么我们就要给客户提供对客户而言最好的方案。客户想要的，往往不是最好的方案，最好的方案才能赢得客户的认可。
满足需求的三种方式
我们一般通过产品需求做出产品来满足用户，这是最劳民伤财的方法，其实我们也可以从问题的本质出发，寻找新的方法解决问题。为什么有需求，需求来源于理想和现实的差距，那么缩小这个差距，我们还有以下三种方式可以达到。
- 方式一：改变现状，把现实往理想靠近，也就是我们常用的方法，做产品满足用户的需求。
- 方式二：降低理想，不要忽视精神的力量，比如经常说的话，打预防针，丑话说在前头都是降低理想的方法。
- 方式三：转移需求，因为人的注意力是有限的，引导用户关注其他事物，他就不会当下的差距多么大了。人的行为是需求驱动的，想要改变人的行为，必须寻找更强烈的需求展现给他，让他不再纠结于原来有的需求。
- 方式四：创造需求。
需求分析过程
1. 需求转化：把用户需求转化为产品需求
我们的需求来源可能是用户，可能是老板，可能是市场部、运营部的同事等等，来源不同，用户需求的记录方式可能也不同，可能是用户在后台用户反馈提的bug；可能是老板的一句话；可能是同事的单项需求卡片。对于这些不同来源的需求，我们最好统一一种记录用户需求的方式，比如Excel表格、脑图等等。
对待这些不同的需求，产品人员需要在一起“头脑风暴”，经过激烈的讨论，从而对用户需求有了比较清楚的理解，对解决方案有了初步的想法。这个时候开始把明显不靠谱的需求筛选掉，把靠谱的用户需求一条条初步转化为产品需求。
2. 确定需求的基本属性
- 编号：需求的唯一标识，在需求很多时可以通过编号明确知道说的是哪条需求
- 提交人：解释需求的来源，需要充分理解原始的用户需求。
- 提交时间
- 模块：需求所属产品的哪个功能模块。比如用户反馈，帮助信息一般在设置模块。
- 名称：简要描述需求是什么，要给用户提供什么功能。
- 描述：描述名称里提高的功能是什么意思，要做什么。描述语言的无歧义性、完整性、一致性和可测试性。
- 提出者：需求的提出者，当对用户需求有疑惑时 ，可以进一步确认。
- 提出时间：原始需求的提出时间，不同于提交时间。
- bug编号：我们经常会把bug当做一个需求。
3. 需求的分类
需求的提出者需要分辨自己提出的需求的类别，为后续的商业价值判断提供一些辅助信息。
我们一般可以把产品需求分为：新增功能、功能改进、体验提升、Bug修复、内部需求等等类别。
通常来说：
产品需求 = 产品的功能性需求 + 产品的非功能性需求
产品包需求= 产品需求 + 市场需求 + 开发需求 + 测试需求 + 服务需求
产品功能性需求很好理解，那么什么是产品非功能性需求呢？比如：产品的性能（支持100万人同时在线），可培训（系统功能升级，完成对相关人员的培训）、可维护（产品异常，自动报警）、可扩展（用户数增加十倍，投入小于10倍）。有一些需求不是为终端用户做的，而是为销售、服务、测试团队做的，比如统计用户操作日志、统计某个功能按钮的点击次数等等
如果把需求按照层次来分，分为基础、扩展（期望需求）、增值（兴奋需求）。比如：邮箱的收发邮件功能是一个基础需求，在发邮件时填写收件人时，系统根据你输入的内容自动提示你曾经发送过的联系人这就属于一个增值需求。
但是在一些情况下，如果一个增值的功能被用户普遍接受后，几乎所有的同类型产品都有了之后，那么也逐渐变成一个基础功能。比如彩屏手机在最初由黑白屏往彩屏过渡时，彩屏是一个增值需求，但现在确是一个基础需求。
分析需求的商业价值
- 重要性：满足后由“一般”到“高兴”，未实现由“一般遗憾”到“非常懊恼”
- 紧急度：在时间维度上判断这个需求是否急于实现。
紧急不重要的需求一般有如下特点：解决了短期需求，如果熬过去没有做，对产品长期影响不大。或者解决了局部问题，如果没做对大多数用户没有影响。
某个大老板的朋友突然提出的一个需求，很可能就是紧急不重要的需求。 - 持续时间：需求实现后的功能使用的持续时间，比如支付宝新增余额宝功能该需求的持续时间就比较长，但是支付宝抢五福功能，该需求的持续时间就比较短。
- 商业价值：商业优先级，上述几种商业价值判断指标的综合评判，是整个需求列表中最核心的部分，直接影响产品做与不做，做的话怎么做，产品的未来走向。
- 商业价值描述：产品的卖点是什么，可以给用户提供什么价值，对公司又有什么帮助。
商业价值判断最后要需要让“老板”拍板要不要做
初评需求实现难度
不能因为某个需求的商业价值大就马上做，也不能因为某个需求的商业价值不大就不做。
当我们知道了每个需求的商业价值后，此时我们决定做哪个需求还要根据另一个关键指标：实现难度。在一般情况下，团队里最稀缺的是开发资源，我们需要根据团队中最稀缺的资源判断工作量，通过工作量衡量实现难度。当我们知道了需求的商业价值后，具体需求怎么做还不清楚，而不知道怎么做的话，此时技术人员通常很难判断工作量。这个时候就要有经验的开发人员、架构人员给出一个粗略的时间，允许误差，通过这个粗略的时间评估实现难度，考虑先做后做哪一个需求。
在项目开始后，此时我们已经确定每个需求怎么做，由哪个开发人员做，此时我们要对项目开发时间做一次更精确的评估，以此推算出工期，制定开发计划。
需求的性价比
不能因为某个需求实现难度小就马上做，也不能因为某个需求实现难度大就暂时不做。
需求的性价比 = 商业价值 / 实现难度（简化为开发量）
根据需求的性价比我们对所有的需求进行排列，从而决定先做哪一个，后做哪一个。
需求筛选
公司的组织架构有两种，一种是以产品划分，另一种以职能划分。
以产品划分，每个产品都有自己的产品经理、设计人员、开发、测试。以产品划分对产品本身是有利的，产品经理的权利更大，可以按照自己的想法做，资源有保证，产品规划不容易改变，各种职能的员工沟通顺畅，开发的领导、测试的领导都对产品经理负责。
以职能划分对多个产品间的资源共享有利，可以让资源流向更需要的地方，保证对核心产品的投入，缺点是效率不高，由于产品规划的决策需要在更高层面的领导决定，单个产品的发展速度会降低。此外，资源的争夺会让产品、设计为产品的发展更加有压力，也是一件好事。
这两种组织架构适用于公司发展的不同阶段，创业初期，需要公司产品全速发展，那么以产品划分，可以让产品经理带头让产品更快发展。当产品成熟后，需要做的事情变少了，此时以职能划分，可以保证充分利用资源。也能让相同职能的人员相互学习，利于个人的发展。
商业需求文档
项目背景：我们在哪里？为什么要做这个项目？解决了什么问题？通过数据表明项目的必要性
商业价值：我们去哪里？老板最关心的，做了这个项目后有什么价值？预测一下带来了具体数字的变化，提出这个项目的商业目标。
功能需求描述：我们怎么去？通过做哪些事情达成目标，描述一下准备做的需求列表，画出业务逻辑关系
非功能需求描述：重要的非功能需求描述
资源评估：老板需要知道花费多少资源才能达成目标，才能决策是否做
风险和对策：部分项目有一些潜在的风险，可以跟老板说下，并说出自己的对策，有可能你觉得很麻烦的问题，在老板那儿很简单。还有一个目的是让老板把把关，是否会和公司的未来战略冲突，由于信息不对称，普通员工很难了解到这些公司战略的问题。
少做就是多做
情愿把一半的功能做到完美也不要把全部功能做成半吊子，越来越觉得一个功能可有可无的时候，甚至还没有强烈理由要做的时候，要明确“不做”。
四两拨千斤，做的少不如做的巧
不是做了很多事情才是贡献，而是应该从目的出发，有一句话说的好，内部的（技术）大改动往往是外部的（商业）小改动，反之亦然。在动手前首先要看看有没有成本低，成效快的解决方案。
尽可能的多放弃
之前聊到在需求采集阶段要尽可能的多采集，现在尽可能的多放弃就是建立在前期尽可能的多采集的基础上。只有在收集阶段没有遗漏，才可以更加全面的看到事物的原貌，才知道孰轻孰重，放弃的时候也更清楚该放弃哪个。
一个需求完整的属性
需求管理的附加值
- 统计每个需求的数量，可以看出产品团队里每个人提交了多少需求，如果再加上时间段等信息就可以看出某段时间每个人的工作情况。
- 统计提交时间、发布时间等信息：按月统计，可以从需求数量的侧面看出产品发展是在增速还是在减速。如果需求提交的数量明显减少就能说明产品已经进入成熟期。
- 统计每个模块的需求数量：因为需求是从用户那里采集得到的，根据每个模块的需求数量就可以看出用户对哪个模块感兴趣，指导产品的发展方向。
- 统计每个分类的需求数量：从各种分类的需求数量的变化，就可以知道最近更多是做新功能还是老功能的优化，从而了解产品是在成长期还是成熟期。
- 统计需求商业价值和性价比的变化，可以看出产品的发展空间还有多大，如果连续几个月商业价值、性价比都不高就要考虑改变方向突破了。
需求管理工具
- Excel
- Mantis
- Quality Center
- Rational RequisitePro
一个需求的生命周期
新人：在高层决定公司战略的前提下，好的产品对新人的帮助会远远大于我们对产品的帮助。所以，产品经理的前若干年，好的公司、好的产品、好的老板，很重要。
如果有幸被你看到这里，我想先说一句：谢谢。接下来我会不断把自己空闲时间学习的笔记、工作中遇到的问题，思考总结后写成文章分享出来。下面是我的个人公众号，如果你觉得我写的东西给了你带来了一些启发，可以关注一下我的公众号bryanshen，接下来我会分享更多更优质的内容。谢谢！
