互联网产品不像实体硬件，一旦制作出来，就无法变更；它是程序、是服务，是可以根据需求不停被优化的。但它的需求是如此之多、变化又如此之快，Boss的一句话是需求，用户的一个吐槽也是需求，所以产品经理最重要的能力，我认为就是处理需求的能力，如何从纷乱繁杂的需求中进行筛选判断，如何快速高效、保质保量的产出需求。
1、需求获取
需求获取阶段主要是收集需求，一般主要是内部和外部两个渠道。对外部来说，用户不会直接提需求，一般提的就是问题或者是功能需要，需要洞察背后的焦虑及诉求，然后提炼出真正的需求，比如B端客户提出打卡微信分享背景图需要个人定制，实际其背后的焦虑是担心每天同样的背景图会导致下打卡用户不愿意分享，所以真正诉求是提升用户分享率。外部的需求还可以是行业规范，比如新电商法要求商品评价必须保留给到消费者查看；对内部来说，除了你自己规划设想出来的需求外，还有部门同事或者Boss的需求，对于后者提出的需求，一般来说首先要做的是记录，因为一开始你不一定能明白其全部意图。对这种政治任务，如果实在觉得不合理，需要比如全面的数据反馈、严谨的逻辑推导等有把握的情况下，然后提出合理的需求和方案应该是怎么样的。
在这个阶段，要做的事情是聆听、广泛的收集，在第一现场做一个大致判断及记录判断后的关键信息，一些能明显判断出不合理的需求可第一时间驳回，一些无法当场判断的先记录下来，后续在需求梳理阶段再深入斟酌。如果不做判断，只是记录后堆在那里，那后面梳理的时候会发现，你不太认识这个需求，导致疲于奔命。
输出内容：需求池，细项如下图。注：这里的需求背景需要描述一下原始问题，避免后续做了方案却并没有解决问题，方案可以是个初步的设想，然后大致评估一下是否合理（不合理可以写下原因）。
2、需求梳理
需求梳理阶要对每一个需求做一次深入的研究，并对这一段时间的需求池做一个优先级排序。深入研究首先是要对需求本身做一个细致入微的分析，回顾一下需求背景、真实需求及初步方案，看看这个推到逻辑是否有问题，比如上面这个需求其实仔细分析不仅仅是提升分享动力，本质是提升打卡的互动性从而带来更多曝光和裂变，分享出去后如果不能吸引其他用户去点击查看，这个分享的链路是不全的。然后可以从紧急重要四象限法则去梳理优先级，重要度一般是做了产生巨大价值效益到不做会有重大损失，依次梳理；紧急度可以从做了立即产生很好的效果到不做立即会有重大损失，依次梳理。
梳理需求优先级是一件非常考验产品功力的事情，需要你对当前的产品和业务十分了解，知道接下去的方向，知道哪里薄弱。同时也是一件蛮纠结、痛苦的事情，运营很着急要上线一个活动能提升活跃率、老板又很关注接下去的某个功能，不过有舍才有得，需求梳理重要的不是做哪些需求，而是决定不做哪些需求。
输出内容：版本迭代计划。主要是厘清下一个版本的研发优先级，一般一个版本会有一个整体的定位和目标，然后与技术、运营等部门进行宣讲、同频，保持对整体产品研发节奏的一致性，这里需要能把事情说清楚的能力。另外如果是多个产品经理一起协作的话，一定要把需求指定给产品经理，另外最好能定下方案设计的产出时间。
3、需求设计
在大家讨论、确定要做这些需求之后，接下来就是需求设计的阶段。这个阶段切记不要觉得自己脑海里有方案了，然后马上打开sketch或axure开始画原型了，结果画着画着发现某个流程没考虑清楚，又开始推到重来浪费工时。一开始要做的事情先把大的框架搭好，如需求背景、用户场景、业务流程、功能规划等分析好，然后在这个框架梳理清楚之后，再去设计原型，这时会觉得顺很多。原型更多的是考验体验设计、逻辑闭环等细节层面的功力，需要仔细琢磨、推敲。
输出内容：产品PRD，如下是一个较为完整的PRD组成结构。
4、需求研发
有了完整的PRD方案后，需要进行产品评审，一般是小组产品成员、设计师以及以及业务相关方的产品参与，这里开始产品们的讨（撕）论（逼）环节，当然目的还是保证需求的合理性、方案的可行性；评审通过之后产出交互、视觉稿，这个时候需要与技术同学进行技术评审，需要注意的是一般还是要先让技术同学们了解需求的背景、价值，然后再深入讨论细节，一些方案细节上需要技术或测试同学进行把关，提前把产品的开发风险规避掉。需求技术评审阶段需要关注以下几点：
产品方案的可行性。这个是技术同学需要确认的，若是方案不完整、不可行，需要及时提出来。
支持部门尽可能全部到场进行评估。一般一个较为大型的方案基本是多个部门一起支持，这个时候评审前需要先找到对方产品或也有可能是对方技术leader进行确认，这里可按照每个公司的对接流程进行，原则上是合理高效、减少不必要的踢皮球现象。
方案成本如何，有没有替代方案或更好的方案。一般技术同学会评估方案的开发成本，产品经理可能会想当然的认为“这么简单的一个搜索功能，肯定是可以的”，但其实技术评估下来确涉及到很复杂的索引结构，导致开发成本过高，所以要考虑可能的替代方案。
保证需求理解一致。产品有义务要把需求的重要信息如背景、价值同步给技术同学，这样在开发过程中，可以减少很多“为什么”的问题。
关于需求变更，在开发过程中，不可避免的会存在需求变更的问题，有时候是方案的某个逻辑缺失、有的时候是领导需求变了等，抽象总结一下是这么几个变更原因：
产品方案不完整。技术同学在开发过程中，突然发现“我擦，这里的留言怎么没有字数上限，赶紧找产品”，这种现象确实经常发生。一般如果是产品自己确实没有考虑到的逻辑或者方案不够好，那么这个问题如果追究起来属产品的锅；如果是产品确实很难考虑到的偏技术侧环节，而在技术评审时技术同学也没提到，那么技术同学也有责任。另外测试同学很多时候参与并讨论后，也能避免这种问题的发生。作为产品还是需要在方案上多下功夫的，之前自己由于不太关注逆向逻辑，就出过一些问题。
业务方向变更。这种情况可能是公司的业务策略改变导致，可能的结果是方案小改或大改甚至是项目暂停砍掉等。如果涉及到大改或者项目暂停的，需要耐心与相关方进行沟通同步，说清楚更改的背景、原因，否则很容易弄得大家都不开心。如果是大改，必要的时候需要重新开一次产品评审与技术评审，重新评估开发周期。
在整个开发周期中，要关注一些关键时间节点的完成情况，比如联调、测试、上线等。如果碰到时间delay，需要问清楚delay的原因比如是工时评估不准确或者人力被抽调走了，避免下次再犯。
输出内容：需求上线，保质、准时上线。
5、从需求到业务
需求上线，仅仅是开始，更需要了解上线后的业务运作情况。如果产品经理不了解自己做出来的产品到底是怎么被市场、运营、销售甚至是财务运作的，认为这些超出了职责范畴，不知道这个需求在整体业务中的价值，也不清楚用户对这个如何反馈，那么产品经理自身的价值也就无法体现。
为什么要讲到业务？其实所有需求的目的都是发展业务，比如一个顺风车业务，涉及到车主的招募、入驻审核，车主财务结算，市场运营、推广，法务合规，乘客的路线匹配、支付、评价，客服服务等环节，只有这里的每一个环节都是正常运作的，顺风车业务才能跑起来，而不是单单是产品、技术做出来的一个App。了解业务的全流程环节，一方面有助于判断需求在业务内的价值高低，另一方面在考虑需求时能够更加全面、更为前瞻。
输出内容：关键数据与复盘。需求上线一段时间后，需要看下关键数据情况、用户反馈以及业务发展情况，然后在总结、复盘下。
需求价值可以通过一些定量的数据来总结，并同步给团队，好的结果是团队最好的凝聚力。
对需求研发流程中碰到的问题需要记录下来，如果是一些较为严重的问题比如delay一周而且是原因不清晰的，就可以组织大伙一起开一个复盘会，重点是就问题论问题，并且拿到改进方式。
网友评论