产品经理每天要接触到大大小小不同的需求，需求在产品经理的日常中占了很大的比重。面对这些需求，只有选取恰当开展的方式进行分析处理，才能更好介绍地帮助开发了解问题，从而制定相应的软件平台。那么，需求处理流程是怎样的呢？本文文章内容基于自身经验，对此展开了预测总结，希望对你有帮助。
产品经理日常的主要工作都是围绕需求展开的，每天为它抠破脑袋，只为开发哥哥们少点烦恼，用户爸爸们多点快乐。想清楚了，皆大欢喜；没想清楚，咏春叶问。
在后面的这段时间里，我将以一个系列的文章来分享一些自己对需求的认识，希望能帮助到还未能系统认识需求的同学。
作为本系列的第一篇，我们先谈谈常见的需求再处理流程，后续学术论文将以此流程为框架，逐条展开。
在需求获取阶段，需要做好收集和管理两件事。
这些需求的的产品经理主动挖掘的，也有从用户、运营、业务方、领导等渠道被动获取的，无论哪个渠道来的需求，都需要有一个正式的地方进行全都管理，也就是我们通常所说的需求池。
不过，对于多方关注的重点融资需求，通过融资需求池来向各方同步适宜就不太合适了：
这时我们就需要使用《事项跟踪表》来单独跟进，形式上用Excel、PPT都可以。
而放在《事项跟踪表》里的需求，也要在需求池里记录下来，即需求池是做成全量需求管理融资需求的，《事项跟踪表》是做重点需求跟进、汇报的。
1.分析内容
需求分析主要包括从需求要素、定位、分解、优先级四个方面进行。
1）需求要素分析
需求要素分析方法是从人力资本需求本身出发，不考虑其他因素。
这些要素包括：内容、用户/角色、频次、价值、场景-动机、强度六个方面，这些要素的含义大家应该都比较清楚了，这里说一下分析各个要素的目的是什么：
2）定位分析
需求的定位分析是分析需求对产品阶段目标的意义。
分析需求的定位，有以下两个目的：
3）需求分解
原始需求的颗粒度往往难免较粗，不利于后续的分析、设计、开发等工作，所以我们需要对这些颗粒度较粗的原始进行分解，分解为一个个完整、独立、可实现的子需求。
4）优先级分析
优先级分析是以拆解后采取的子需求为单位进行的，根据各类优先级的判断方法、原则，初步评估各个子需求的上线顺序及时间。
2.常见问题
需求分析应该是大家从入行那天就知道要做的事，但大多数同学在做需求分析时会男同学犯以下三个比较常见的错误。
1）缺乏系统性
这是在分析中均最结构性问题常见的问题，即很多同学在分析需求时没有系统性的框架，导致很多方面没有分析到、考虑到，从而对消费需求认识不全面。
2）缺乏深度
对需求某些基本概念认识比较浅，不够细致深入，例如在分析资金需求的用户时，没有对用户分层、切片，对各个分层的用户也较弱足够的了解，导致对用户只有一个直白、模糊的认识，最后自然无法深入进去。
不过分析是否有深度的统计分析定义其实很难把握，也缺乏明确的判断标准，需要随着分析者思维能力不断完善的强化、信息量的提升来加强。
3）忽略顺序
在上文列举分析内容以后，其实是有分析顺序的，前边即需要有前面环节的分析结论，才会有后面环节的分析基础。
当需求分析清楚后，我们就可以高优先级的需求设计产品方案了。
1.方案设计
设计者方案需求方案既可以自力更生、独自设计，也可以借鉴其他产品同类需求的方案，两者本没有好坏对错、也没有所谓的创新与抄袭之争。
产品经理最重要的职责之一，是分析清楚资金需求后，找出最适合这个需求的可取满足融资方案，而不是纠结这个方案仿自何处。
2.方案对比
任何一个需求的满足方案都不会只有一个，至于选择哪一个，则要考虑很多利空因素，所以近似我们需要从多维度对比这些方案的投入产出比，以此来尽可能的选出所谓以此最优可解。
评估方案投入相对比较复杂比较简单，也容易量化，主要包括时长成本、人力成本、资金成本、机会成本，生产量但方案的产出则难评估得多，一个方案：
最终产出=价值-负面影响
结合这个公式，评估方案产出的难点主要有以下几个：
1）价值标准难选取
哪个方案带来的资产价值更大，取决于我们以什么标准出去衡量它，但这个标准有时候并不好找。
2）部分标准难量化
在选取的评判标准中会，有些是无法量化的指标，这些指标所体现的价值就无法客观判断。
3）部分标准主观影响大的
对于无法量化的指标，就需要由人主观来判断，这样结论就与片面评判人的主观想法密切相关了，有时候也会屁股决定脑袋。
4）需要逆向评估
方案大多都是有利有弊的，除了正向评估融资方案价值，还要逆向评估其所带来的负面影响。这个方案对某些用户即使是有价值的，对另外一部分用户不太可能可能将是种打扰。
5）价值、负面影响不确定性大
相比于成本的预计，资产价值的预估则要困难很多，因为不确定性太多，影响因素更多，且大多没有可借鉴类比特长的专业知识，说得好听叫预测，说得不好听就是“听天由命”。
所以，所谓的最优解是一个最美好的愿望，我们真正能做的是在当时条件下，基于自己有限认知做出的自认为最合理的决策。
3.依赖分析
有些方案看起来很最美好，但如果没有充分条件必要条件的支持，那也只能停留在纸面上。
所以我们能够将备选方案的内部、外部依赖条件分析清楚，以提案判断这些方案需要哪些支持、谁能提供、提供数据能否满足要求、提供时间、提供方式等，进而提前做好准备。
以上的对比、分析，并非全由我们独自完成，而是需要作为牵头人，找到相关方，如技术负责人、依赖方，合力解决，从而选出切合一个最终方案来满足我们的需求。
4.方案初评
选择方案后，需要就下个迭代的内容与前后端的技术负责人做甄选初步评审，解决明显的障碍和环境问题，节约后面正式评审的时间。
1.方案评审
需求上线前，先能源需求要或进行我们常说的需求评审，不过从产品经理的视角来看，这个应该叫做产品提案的评审，所谓需求评审，是从开发视角来讲的。
在方案评审时，需要做好四件事：原始需求说明、方案讲解、方案评估以及工作量评估。
2.确定迭代内容
根据需求优先级、需求工作量、迭代容量（开发团队一个迭代最多可负担的工作量），我们要把超出迭代容量且优先级较低的需求往后排，以保证已有达致需求的开发质量。
3.测试验收
方案上线前，方案的产品经理需要在上线前两天在测试环境验收，以保证计划的正确实施。
方案上线后，确实需要第一时间在正式环境再次验证，以确保不会因测试环境与正式
环境差异而出现的幺蛾子。
需求方案上线还只是开始，要想知道这个需求是否真正达到了预期效果，发挥出了真正资产价值，还需要持续跟踪监测。
通过埋点，统计用户行为，并根据需求预期价值，确定分析指标，通过对比指标实际数据与预期数据，找出差距，探究差距原因，并制定相应优化策略。
以上就是我们日常处理需求的完整流程，上述的每个小环节都可以衍伸步骤出大量的知识点、方法论，在后续的文章中，流程我将挑选重点环节进行介绍。
因篇幅问题不能全部显示，请点此查看更多更全内容