1 需求来源概述
1）依渠道优先级进行排序，需求来源如下
用户反馈、领导、运营、数据反馈、竞品、开发测试反馈、合作部门。
2）需求验证方式
真伪性验证：通过流程体验来核实需求的真实性、可代替性；
必要性佐证：通过用户高频反馈、数据表现、竞品动态，为需求找到支撑理由。
2 各需求方的特点总结
用户反馈：优先级最高，即时性要求高，验证后需火箭处理。用户反馈，非常重要，其问题通常表现为：Bug反馈、业务反馈、操作反馈、情感反馈等。及时关注该渠道，并做好妥善处理，否则会造成用户报障量增大，用户情绪爆发，一旦蔓延到其它社交网络上就会演化成毁灭性灾难；
领导需求：上级下的需求，一般是在战略层面需求，可能是新功能的接入、新业务的接入；这里的新功能和新业务不一定对等。跟领导对接需求时，应视需求的熟悉程度，判断是否需要问清楚目标、场景，这对后续的推动工作有重要作用。我们有必要让开发同事、UI同事明白某需求的意义与价值。
运营需求：一般为活动性需求，其目的是拉新、促活；接到这种需求一般验证其活动形式的支撑功能，在过去是否有过同类逻辑的功能，如果有则可修改调用、或增加一种活动类型；若无，则需验证其过程逻辑，重新开发一套。
除活动策划外，运营人员也是后台系统的主要使用对象，会提出后台的业务性需求。其目的为 提高工作效率、减少重复性工作。接收这种需求之后，需要进行一遍验证，查验其需求的真实性，并与技术同事分析可行性，寻找最有方案；
产品自发需求：自行进行验证，其流程为发现问题-提出方案-验证方案；通过流程体验、数据表现、竞品动态等渠道尽可能挖掘需求；目前提出一个需求后，笔者会通过对比竞品功能、数据表现等方式去验证需求。产品新人容易拍脑袋提需求，这就需要一套思维方法去纠正，并时常践行直至习惯养成。
合作部门、开发同事／测试同事，其发起需求频率较低，视优先级先后排序。合作部门需求视紧急情况、与当前版本关联情况等方面进行优先级排定；开发需求多为程序优化需求；测试需求集中为迭代历史中还没来得及填补的体验性需求，一般不影响主要流程的使用。
3 需求沟通踩过的坑
列举两个例子，是作为新人，笔者亲身踩过的坑，以血泪史的形式记录下来。
其一：被开发打脸，需深入了解原有逻辑
客户端有过一个发卡券的需求，要求是分发量大、即时性强，在实现过程中，原需求为卡券到账用户即可收到一个提示弹窗；后台已经存在一套首页广告弹窗逻辑，以及卡券分发逻辑；
笔者对原逻辑没有深刻理解，重新提出一套卡券关联逻辑和卡券广告弹窗逻辑。结果是开发关都没有过，打回重新调整需求；最后还是接入原有的首页广告弹窗逻辑，并且沿用原有的卡券分发逻辑；
其二：被运营打脸，需换位思考，说运营话
曾跟运营沟通一个很简单的需求，在手机浏览器的自家网站上线一个Banner广告位。笔者很傻逼的表述：图片尺寸高度不统一，在切换的过程会很不友好，切换到该图片，高度会缩小。随后被运营一句话怼得哑口无言：你直接说图片尺寸不对，不就完事了吗。
新人笔者的思维视角，是这样看这个事的：首先不确定这个图片的尺寸是不是错误的，出于对职场老人的信任和权威，一开始也没有提出质疑；其次直接从因果关系的PM思维去解释，并没有转换角色进行思考。以上，导致了一幕崩溃的沟通场景。
总结：深入了解原有的业务逻辑 + 沟通表达需谨慎，三思而后言。
