基本跟楼上一致，但是想细化一下：

1、需求怎样聊？

多用开放性问题，询问背后的原因，而不是先带入自己的主观意识，使用封闭性问题让用户只是点头或摇头，那样的回答缺少他们本身的思考，所挖掘出的信息非常有限；

2、在什么节点安排会议？参会角色有哪些？

1）参会角色：需求提出方及需求相关方，参会节点详列如下：

• 需求提出后：如果需求涉及面较广，那么需要组织一个会议，将所有需求干系人都召集起来，听听各方想要达到的目标及意见；
• 方案输出后：产品经理根据收录的需求，进行需求设计（流程图、原型图等），待方案输出后，将所有需求干系人都召集起来，确认自己的理解与他们提出的需求是否存在出入，以保证需求设计方案的可行性；
• 需求评审后：在需求评审的过程当中，有可能会发现需求设计问题，从而引发需求设计方案的调整，针对调整后的方案也需要与需求相关方再次确认方案是否影响他们的需求；

2）参会角色：开发团队内部（其他产品经理、UX人员、开发人员、测试人员），参会节点详列如下：

• 方案（与需求方）确认后：产品经理与需求方将需求全部确认完成后，需要将需求的业务场景及设计思路宣贯给开发人员、UI设计人员、测试人员，此为需求评审会议，除了需求实现人员之外，还会有其它产品经理一起参与需求评审，以尽可能多地在设计环节发现问题。发现问题后，需要再次对方案进行调整，调整后再次与需求相关方确认，并再次进入需求评审阶段；
• 需求实现进度会议：通过每日早会，了解需求实现层人员的设计、开发、测试进度；

3）UI等设计在哪个节点提出？

需求相关方、开发团队内部对需求设计方案都没有异议时，可进入UI设计阶段；

4）测试环节中，产品需要做的工作

测试前期：确认测试用例的合理性及是否存在逻辑遗漏的问题。对于有成熟（熟悉业务、测试技能娴熟、高责任心）测试配套的团队，个人认为产品经理可以跳过这个环节。

测试中期：测试开发人员已经完成单元测试的模块，了解大概的开发质量；

测试后期：做一个测试质量的验收；

1-需求怎样聊？

首先分析出需求的相关方有哪些，再通过会议或者一对一会谈了解需求，从而分析需求的必要性、优先级，以及实现需求的最佳方案；

2-在什么节点安排对接会议？参会角色有哪些？

原则：在有条件的情况下多进行相关方对接和确认，避免无效工作。

在确定需求要做之后，可以先出初版方案，找相关方对一下，如果方案没问题，再出具体原型，再次和相关方确认，再写具体逻辑说明，进行开发评审。

3-UI等设计需求在哪个节点提出？

设计需求在确定了原型方案就可以提出了，在不影响的情况下不一定要等全部逻辑说明写完再给设计。

4-测试的环节中，你（PM）需要参与哪些工作？

测试前，与测试和开发进行用例评审，再次确保三方对需求的认知是一致的。

在测试进行的过程中，可以跟进一下进度，看看有没有意料外的大问题，明确是否能按时上线；

在测试确定没问题后，再进行一轮验收。

#产品经理挑战赛#

作为一个加班时长3年的B产，发表下自己小小的不成熟的建议

1-需求怎样聊？

先熟悉，再定性定量

B端需求里，客户用户，场景，目的一般是明确。要注意的B端的业务线逻辑耦合度极高，作为PM要绝对绝对绝对熟悉自己的产品，清楚所负责的业务功能逻辑，任何改动可能都是致命性的。需求方提出A，然后我们把B的逻辑做闭环了,A也好了，这是B端产品的常态。所以熟悉度是聊需求的前提，没有调查没有发言权。

回到问题，在有发言权的前提下，聊需求时定性定量是老生常谈了。是谁?在什么场景？做了什么？做了多少？遇到什么问题？希望达到什么目的？成本高吗？

2-在什么节点安排对接会议？参会角色有哪些？

大会解决共识，小会推进进度

3-UI等设计需求在哪个节点提出？

大改在0到1的0时提出，小改在0到1的0.4时提出

大改：设计部对整个产品的视觉提出方案，PM是要给用户调研，时刻保证“我们真的在说同一堆客户用户”，然后相信设计的专业能力

小改：B端需求一条业务逻辑的原型确定就应该提出设计需求了，给设计师留充足时间。

4-测试的环节中，你（PM）需要参与哪些工作？

引导式参与

我相信拥有大厂测试实力的项目还是占小数的，大部分PM同学都要分心顾及其他环节，以我自身举例，最好能给到测试用例、需求主要终端场景、验收测试报告，甚至去体验测试。毕竟对测试同学来说PM就是最大的需求方。

 #产品经理挑战赛# 

1-需求怎样聊？

想起很久前我第一次接触产品，我的领导和我说的乔布斯名言“用户不知道他们想要什么”

其实需求都来源于业务的痛点、痒点；但是业务方在表述这些问题的时候，往往会加上自己的期望，期望这个东西变成什么样子的，很多时候，我很难完全摒弃自己听到的第一时间业务期望改成的样子，但是这样就对问题和现象缺少本质的思考，更多的时候需求需要我们去挖掘，什么现象下有这个问题？为什么会出现什么问题？业务为什么觉得有问题？他为什么想要改成那样？这些问题都了解清楚了之后，做出来的才是最终那个合格的产品；

2-在什么节点安排对接会议？参会角色有哪些？

需求确定会——明确需求方以及涉及业务线后：业务方、产品

需求评审会——产品定稿：产品、UI、研发、测试

测试用例评审会——即将进入测试阶段：测试、产品、研发

上线培训会——产品上线：产品、业务

3-UI等设计需求在哪个节点提出？

在产品需求确定后，UI介入；

4-测试的环节中，你（PM）需要参与哪些工作？

测试用例的完善、测试过程的验收、测试结果发现流程问题后的优化

1-需求怎样聊？

需求沟通的技巧很多，从我自己的经验出发，有两个要注意的点：1、问对人；2、结合场景进行需求沟通。

2-在什么节点安排对接会议？参会角色有哪些？

一开始用户初步提出需求以后，需要针对已知的文件或描述进行需求初步分析和需求会议问题提纲设计，设计好后即可安排第一次会议。对接需求后，形成需求说明书或原型初稿，此时可以进行第二次会议，需求确认。

参会角色一定要找到需求直接使用者和决策者。

3-UI等设计需求在哪个节点提出？

UI在原型定稿后提出即可。

4-测试的环节中，你（PM）需要参与哪些工作？

测试环节产品主要参与测试用例确认，功能测试的协助，功能逻辑的讲解即可。

#产品经理挑战赛# day3

1-需求怎样聊？

我认为，在你聊需求之前，应该是已经准备好了前期的调研工作，例如项目概况、客户情况、项目现状、行业情况和竞品分析等等，如果这些工作都已经准备充分，那么你的需求访谈应该就已经很明了了，也已经准备好，你需要问的问题和方向其实已经很明了了。

2-在什么节点安排对接会议？参会角色有哪些？

需求确认的节点：叫上甲方的实际业务对接人，项目负责人还有相关的领导，乙方的项目经理和需求，技术和ui也可以叫上。

需求评审节点：基本上就是你们项目组的所有人了，项目经理，需求，开发，测试，UI都要参加

3-UI等设计需求在哪个节点提出？

其实我觉得是在评审会的时候提出设计需求，或者一开始的时候就先和甲方沟通好整体的设计风格，这样也能避免后期的风格大调整。

4-测试的环节中，你（PM）需要参与哪些工作？

测试计划的安排和执行，以及测试工作的随机抽查吧，你一个PM不可能全程参加测试工作。做好测试工作的管理就行

1-需求怎样聊？

我个人的原则是：先看再问

提问一定要注意的情况是：避免提一些有引导性的问题。

举例说：你觉得白色比黑色好吗？

这种问题在提问时已经具有倾向性，下意识会让用户觉得，好像“应该”白色比黑色好，才是符合预期的答案

如果一定要提问题，我多半会这样问：

需要什么颜色呢？为什么呢？

提问一定要有层次，有推进，要问到本质

不能上来就问：你要这个功能干嘛

而是问：下一步是什么呢，再下一步呢