三节课产品经理P2（18期）第一周话题讨论回顾
【话题】如何对需求进行深入理解并学会表达?
【背景】
1. 产品工作中，产品经理在做一个需求时，如果不对需求进行深入理解，往往导致两个问题，一方面造成做出来的产品不符合真实的用户需求，另一方面在需求在设计过程中三番两次的改稿导致效率低下。
2. 很多刚做产品经理不久的新人，经常在需求表达上不到位，从而每次导致研发失去耐心，有时甚至一句话即把产品经理“怼死”，长久以来往往导致开发同事不在信任产品经理，导致在工作开展难度上升；
【讨论方向】
1.作为一名产品经理，你是否遇到过以上情景，导致工作问题的出现，当时你是如何进行解决的？
2.我们在需求理解和表达上是否存在一种方法，可以分享给产品新人让他们避免发生类似悲剧呢？
3.在需求理解上产品经理如何做到理解清楚领导向你提出的需求？保证在执行上不偏差？
一、产品经理需求来源
第一阶段：用户反馈
第二阶段：业务部门
第三阶段：领导需求
产品经理在整体方面上来看经常接触的需求来源于包括以上但不限于此三类，分别是（用户反馈、业务部门、领导需求），此时很多刚入职的新人会出现的问题就是“用户、业务、领导”说要某个功能，所以我们要做，此时抱着需求要求去和开发说明，我要做A、B、C需求，而开发往往都会问此一句为什么要做，而刚入行不久的产品经理，总会说，因为领导、业务部门需要，所以我们要做。
而此时导致两方面的问题
就是开发先信任你把功能做完之后不了了之，功能没效果，大家都没达到预期，后期开发也不信任你了；
另一方面开发问了你一大堆问题，但你回答不出，此时给开发怼回需求，甚至不打算做你提的需求（如：开发会问为什么实现这个需求啊？这个需求实现的过程你能给我说下吗？实现之后能给我带来什么呀？）
此外我们在提需求让开发实现时务必要经过一个流程：
理解清楚需求→与研发在线下初步沟通（测试研发态度）→组织需求评审会
2、如何理解需求
基于以上的情况其实作为产品经理的我们，在拿到需求时，千万不要着急拿着就向开发表达，而是参考以下经验：
很多时候老板和业务方都会向产品经理提出需求，但产品经理接完需求后，就想当然的接受执行了，导致最终实现方案做出来效果不好，没达成预期。而这个原因在于产品经理没有对需求进行充分理解。其实从需求接受到需求转化都会存在一个鸿沟（比如：收集老板与业务方需求反馈→转化产品需求）此时误把老板和业务方提的反馈当成产品需求，没有对需求进行转换理解和追溯，所以在理解老板和业务方向我们提需求的过程上，务必追老板和业务方需求的来源，找到来源后在梳理清楚他们在什么场景下遇到什么问题而得出的需求。
在理解需求时盘清楚用户-场景-问题-现在的解决方案，理解清楚这个需求在用户什么场景下是能帮助用户解决什么类型问题的，且解决这个问题后能给大部分用户带来体验提升（如：优化流程步骤、提高效率等、满足需求）
先把自己的需求在产品结构理顺清楚，比如这个需求如果要实现的话，它应该放置在什么产品结构上？它涉及什么页面，实现逻辑是如何的？每个节点逻辑走向是否通顺？是否有业务流程图？
案例
需求真的是不能按照领导说的去做，一定要去找提出需求的人去了解，去沟通，领导们谈的层次和实际操作是不一样的，记得是很早的时候了，和销售合作一个项目，领导传达的就是我们做一个h5页面，呈现内容，可报名参加，但是实际过程，沟通，需求不是这样的，需要分享，每个人的二维码都要加个人参数，用户统计每个人的数据以及价格，且要根据年龄去换算细节，很多不一样的，开始我们以为就是一个小宣传活动，最后都变了。
——源于胖虎助教
3、提前进行需求沟通：
另外各位产品经理在开需求评审会之前，需要与核心人员（研发、需求提出关键人）先沟通一遍，然后把一些沟通上总结出来改进点提前改进，确保本次需求没有大的问题。另外在需求中明确 需求背景，目的，问题等，然后再具体讨论本次需求业务流程，实现方案。
在需求沟通完后接下来就会进入需求评审环节，此时在需求评审前需要准备以下内容（包括但不限于）
一定要想产品需求得细节，比如需求的边界情况；
明确功能使用涉及各个节点的页面和细节，尽量不要有遗漏；
梳理清楚产品业务流程、页面流程「尤其是异常判断处理（程序员重点怼你的地方）」
想清楚RD可能会怼你的问题，一般集中在三个地方：流程、异常判断、字段；
4、需求评审环节
当产品经理想清楚需求后，接下来会进入需求评审会议，产品经理可能会面对（研发、测试、UI、运营）部门的同事进行需求表达，一般情况下需求评审会议主要分为两个环节：
需求内审（评估实现的需求以及说需求可行性）
需求评审（评估具体需求实现方案）
有些公司会把两个环节合在一起开，有些公司会把两个环节分开，大部分公司都会把内审和评审合起来开，所以我们以此为基础去了解产品经理在需求评审的
需求评审会议讲解流程：
需求背景、目的
版本Feature List
需求的“用户-场景-需求”
讲解功能涉及页面、主业务流程，以及异常情况判断处理（建议：讲完后让RD用他的思路复述你的内容）确保理解无差异，再讲解页面和分支流程。
当然在需求评审过程不一定每次都是顺利的，有些时候产品经理会在需求评审中遇到挑战和质疑以及团队同事陷入细节中深入讨论，降低需求评审效率。
所以此时我们作为产品经理遇到需求评审挑战质疑时，要去对问题进行划分（明确是自我问题还是别人问题），如果是产品经理在产品实现上没想清楚的问题，该承认就承认，而不是去争辩。如果是研发或他人的问题，也要学会挖掘研发以及其他同事对你挑战背后的目的（比如：有一些研发是因为是因为开发实现难，不想做复杂需求）。另外如果在需求评审会中大家陷入细节后，产品经理是要把大家拉出来。核心讨论需求可行性，如果实现细节很细的话，可以会议下来之后再找开发讨论。
感谢本次讨论参与的成员：
朱斌-开发-北京、boo博-产品-北京、助教-菁菁、Steven-产品经理-上海、野草-产品经理-上海、小钱-PM-广州深圳、助教-佳伟、大叶子-其他-深圳、perry 产品 深圳、段亚轩-运营转产品-上海、助教-胖虎不胖、张了了－pm-安徽、焦叔
班期：产品经理P2十八期
网友评论