需求池|需求系列（一）——需求处理流程( 二 ) 需求分析|要素|产品经理|系列

三、方案设计与分析1. 方案设计设计需求方案既可以自力更生、独自设计，也可以借鉴其他产品同类需求的方案，两者本没有好坏对错、也没有所谓的创新与抄袭之争。
产品经理最重要的职责之一，是分析清楚需求后，找出最适合这个需求的满足方案，而不是纠结这个方案出自何处。
2. 方案对比任何一个需求的满足方案都不会只有一种，至于选择哪一个，则要考虑很多因素，所以我们需要从多维度对比这些方案的投入产出比，以此来尽可能的选出所谓最优解。
评估方案投入相对比较简单，也容易量化，主要包括时间成本、人力成本、资金成本、机会成本，但方案的产出则难评估得多，一个方案：
最终产出=价值-负面影响
结合这个公式，评估方案产出的难点主要有以下几个：
1）价值标准难选取
哪个方案带来的价值更大，取决于我们以什么标准去衡量它，但这个标准有时候并不好找。
2）部分标准难量化
在选取的评判标准中，有些是无法量化的指标，这些指标所体现的价值就无法客观判断。
3）部分标准主观影响大
对于无法量化的指标，就需要由人主观判断，这样结论就与评判人的主观想法密切相关了，有时候也会屁股决定脑袋。
4）需要逆向评估
方案大多都是有利有弊的，除了正向评估方案价值，还要逆向评估其所带来的负面影响。这个方案对某些用户可能是有价值的，对另外一部分用户可能是种打扰。
5）价值、负面影响不确定性大
相比于成本的预估，价值的预估则要困难很多，因为不确定性太大，影响因素更多，且大多没有可借鉴类比的经验，说得好听叫预测，说得不好听就是“听天由命”。
所以，所谓的最优解是一个美好的愿望，我们真正能做的是在当时条件下，基于自己有限认知做出的自认为最合理的决策。
3. 依赖分析有些方案看起来很美好，但如果没有必要条件的支持，那也只能停留在纸面上。
所以我们需要将备选方案的内部、外部依赖条件分析清楚，以判断这些方案需要哪些支持、谁能提供、提供数据能否满足要求、提供时间、提供方式等，进而提前做好准备。
以上的对比、分析，并非全由我们独自完成，而是需要作为牵头人，找到相关方，如技术负责人、依赖方，合力解决，从而选出一个最终方案来满足我们的需求。
4. 方案初评选择方案后，需要就下个迭代的内容与前后端的技术负责人做初步评审，解决明显的障碍和问题，节约后面正式评审的时间。
四、需求上线阶段1. 方案评审需求上线前，先要进行我们常说的需求评审，不过从产品经理的视角来看，这个应该叫做产品方案的评审，所谓需求评审，是从开发视角来讲的。
在方案评审时，需要做好四件事：原始需求说明、方案讲解、方案评估以及工作量评估。

原始需求说明是指向开发团队介绍经过分析后的需求要素，目的是为了让开发小哥们更好的理解需求，更有代入感，以免实现歪了；
方案讲解即介绍满足需求的方案，这是开发同学最关心的事情。有时候开发小哥们在理解了需求的情况下，可能会提出更好的方式；
方案评估是从实际开发人员角度评估方案的可行性、风险、成本，在方案设计阶段，我们虽然与前后端技术负责人做了初步评审，但粒度比较粗，且评估人不一定是一线开发人员，所以可能有些细节没有注意到，此时我们就要更深入、全面的进行评估；
工作量的评估是通过量化的方式评估迭代需求总量，有利于开发团队合理规划迭代的开发时间。

2. 确定迭代内容根据需求优先级、需求工作量、迭代容量（开发团队一个迭代最多可负担的工作量），我们要把超出迭代容量且优先级较低的需求往后排，以保证已有需求的开发质量。
3. 测试验收方案上线前，对应方案的产品经理需要在上线前两天在测试环境验收，以保证方案的正确实施。
方案上线后，还需要第一时间在正式环境再次验证，以确保不会因测试环境与正式环境差异而出现的幺蛾子。
五、需求优化阶段需求方案上线还只是开始，要想知道这个需求是否真正达到了预期效果，发挥出了真正价值，还需要持续跟踪监测。
通过埋点，统计用户行为，并根据需求预期价值，确定分析指标，通过对比指标实际数据与预期数据，找出差距，探究差距原因，并制定相应优化策略。
以上就是我们日常处理需求的完整流程，上述的每个小环节都可以引申出大量的知识点、方法论，在后续的文章中，我将挑选重点环节进行介绍。