产品整体框架
2025-11-19 10:48:07 0 举报AI智能生成
1
作者其他创作
大纲/内容
1.需求意向
1.1用户反馈
用户反馈并不等于用户的主动上报，也就是说用户反馈不单是用户对产品功能的吐槽，还有更复杂的情况。在很多情况下，是产品经理在发现产品数据异常后主动找到用户，请求用户提供信息的。
1.2事件上报、bug
1.3体验优化
1.4技术变革
1.5上级指示
1.6功能创新、新增机会点
业务需求
需求挖掘方法论
攀梯法
1）你现在在做什么？
子主题
（2）你是怎么做这件事的？
这个问题是为了确认我们的现有流程中有没有可简化和优化的部分。有时候，新开发的功能可以满足用户的需求，用户却习惯使用旧功能，有些用户甚至不知道新功能的存在。只有帮用户梳理清楚真正的操作流程，才能发现目前哪些流程存在问题，即哪些方案不合理。所以，梳理流程是做方案的前提。
（3）在你的整个工作流程中，最重要的是哪部分？
这个问题是为了确认用户最揪心的部分和用户觉得最重要的部分是什么。只有了解清楚这点，才能把以上需求的优先级划分清楚，同时也能在第一时间准确解决用户的核心痛点。从用户最揪心的部分也可以推测出整个流程的压力点，从而找到隐性提升点。
5W2H 分析法
挖掘做法
数据分析
用户访谈
用户调研
核心困难点
多方视角的偏差
举例
产品使用方用户关注的通常是产品载入快慢、界面是否好看、功能是否清晰易懂，而产品设计者产品经理是从交互设计理论、视觉风格、平台整体规划的视角来看问题的
解决方案
两个视角上的人的对话交流，需要创建一份双方能够达成共识的话题清单，把视角转移到共同关注的点上，进而理解对方的立场。
关键点
千万别问用户想要什么
2.需求分析
2.1市场、行业分析
2.2竞品分析
2.3用户研究
用研必要性
任何产品都是建立在解决用户痛点、需求；任何需求都是建立在用户第一的原则上存在，否则脱离了用户都是伪命题
用户研究是了解用户的重要途径，也是产品核心能力之一，是笼统概念，涉及多学科
切入点
目标
（1）了解用户，熟悉用户的诉求。
（2）与用户建立稳定的关系，做到感同身受。
（3）将自己变成用户，且可以随时切换不同的用户角色。
方法
具体方法
观察法
访谈法
用户调研
（1）调研前：整理需求意向模板，确定调研议题、调研目的及调研范围。调研目的要尽量完整，流程清晰，调研范围要和目的保持一致。
（2）调研中：把控调研节奏，避免跑题和冷场的情况出现。大会说小事，小会定大事。
（3）调研后：整理调研报告和会议纪要，发给调研对象并请他进行确认，之后汇报领导并争取资源，放进需求池。
数据分析法
要求
有目的性
否则
（1）研究过程没有主线。
（2）研究结果没有定论。
（2）研究结果没有定论。
目的可以是一个指标的提升，也可以是一个界面的重做，还可以是一个功能的改版。
原则
，无论是采用访谈、问卷，还是现场可用性测试等方法，都离不开和用户的交流。交流的目的是让用户主动提供或从侧面提供我们需要的信息。
问题设计
设计的问题要通俗易懂、没有歧义
我们团队在设计问卷时采用了很多专业术语，如「首页的布局合理吗」「配色对比度够吗」等，这导致用户反馈的信息很少且内容质量很差。后来，我们重新设计了一个问卷，采用了通俗化的表述，如「首页乱吗」「能找到你要的功能吗」等，修改后的问卷得到的用户反馈清晰了很多。
设计问题时要注意利益相关性
设计的问题不要对用户有指引性
让用户描述搜索自己最爱的一首歌的路径，因为在网页上「搜索」和「我的最爱」都是非常清晰的标题，这很容易引导用户做出不正确的反馈，但如果让用户放一首他最喜欢的歌，用户就会真实地展示自己的操作流程。
用研和市场调研的关系
它不仅包括研究用户群体的情况，还包括研究什么用户在什么时间、什么地点、什么场景下发生的什么动作，以及这些动作发生的原因。用户群体和特征会随着环境、政策、时代的发展而变化，用户研究也要随时随地地、有节奏地进行。
目的
子主题
2.4数据采集、分析
2.5可行性分析
2.6投产比预估
3.产品定义
3.1产品目标、痛点、战略
3.2产品定义、Slogan、一句话描述
3.3核心用户群体、关联拓展性
3.4核心功能点、产品关键点、核心竞争力
3.5产品系统关联情况、生态图
3.6产品广度、深度、未来发展方向
3.7商业模式
3.8产品报告、阶段汇报、启动报告
产品报告
阶段汇报
启动报告
3.9行事历、上下级汇报、项目管理机制
行事历
上下级汇报
项目管理机制
产品经理与项目经理的区别
项目管理是什么
项目管理怎么做
3.10合规、预算等事宜
合规
预算
4.产品设计
4.1需求列表、优先级、PRD
需求列表
需求管理
管理不妥当造成的问题
很多有价值的需求往往来自用户访谈及合作团队，如运营、市场等部门同事的想法。这些需求又杂又多，如果不合理安排时间妥善处理，就会导致应接不暇，影响了自己的工作不说，还会漏掉很多需求，进而影响和用户及合作团队的关系，引起领导的不满。
如何高效管理需求
（1）分析团队需求流向及特征。
（2）建立需求反馈模板。
（3）反复访谈，完善模板。
第一步，分析团队需求流向及特征。流向指的是当前的运营导向是什么，当前的强势部门有哪些，当前的产品趋势和形态是什么；特征指的是哪些用户是核心用户，哪些渠道是主要反馈渠道，哪些渠道搜集到的需求最有价值。
通过流向，我们可以知道哪些部门提出的需求要优先安排；通过特征，我们可以知道如何提升用户反馈的效率。需求流向一般可以从公司的政策和领导的要求中得出；需求特征一般可以通过对用户反馈流程进行梳理和对需求效果进行总结得出。
需求反馈模板
模板的价值在于，可以提前搜集很多原本需要访谈才能得到的信息。比如，事先在模板中注明「现在系统存在什么问题」「改动之后如何评判价值」，可以帮助用户或合作团队进行选择，避免他们按自己的理解来写需求意向，从而节省了双方的沟通成本。
随着公司业务的不断发展，为了保证需求模板的合理性，我们需要不断和用户及合作团队进行访谈，以完善模板。比如，根据企业数据经营战略的要求，我们需要在第一时间把新功能的报表系统规划好，因此我们在收集业务需求时，需要在模板中增加「请填写数据分析思路」一项。
需求点拆分
INVEST 原则
INVEST 原则是关于描述用户故事的一些要求
可以让用户故事变得更加清晰、便于估计、容易测试
Independent（独立的）：两个用户故事之间应该是互不依赖、互相独立的。
Negotiable（便于沟通的）：用户故事应该是便于沟通的，而且是无歧义、无疑问的。
Valuable（有价值的）：每个用户故事必须是有价值的，否则可以忽略这个用户故事。
Estimable（可估计的）：用户故事的工作量和成本应该是合适且可估计的。
Small（短小的）：一个好的用户故事应该是短小且具有代表性的，否则会无法分配工作。
Testable（可测试的）：一个用户故事要有完整的测试结论，即什么样算成功、什么样算失败。
关于用户故事，我们还需要了解一系列关于需求的概念。假设一个需求就是一个故事，那么一个庞大的需求（如销售报表自动化）就是一个大故事，我们称之为史诗故事（Epic）。它需要经过多个研发流程的开发、测试。再将史诗故事进行细分，就能获得若干主题故事（Theme）。主题故事还可以细分成若干小故事（Story）。将小故事拆解为更加细分且可落地的东西，就是任务（Task）。
比如，某公司要提升用户操作效率，这是一个史诗故事。而技术人员主要靠移动端的体验优化来达到提升操作效率的目的，其中的主题故事包括主页改版、重点功能改版等功能点。进一步细分，主页改版包括 Banner 位改版、增加搜索模块、增加用户操作历史功能等，这些都是小故事。再进一步细分，为了增加用户操作历史功能，设计师需要设计新的 UI，前端同事需要设计缓存机制，这两件事就是团队为达成目标所需要做的关键任务。
以上就是基本的需求粒度要求和需求拆分方法
需求池管理
需求模板
优先级
方案雏形阶段
方案梳理阶段
脑暴会
产品导向的头脑风暴会，它往往关注产品层面的方案及优先级的确定。
一个好的头脑风暴会一定要有一个原则，即根据头脑风暴会的议题充分发散、碰撞思维，但要避免互相评判攻击、打压对方的观点。
良好的氛围和环境是十分重要的。在良好的氛围和环境下，很多平时不能说的话也可以说出来。这样的环境通常是放松且愉快的，有利于减轻表达者的压力，从而提出更多创造性的观点。
同时，头脑风暴会是有协同效应的。很多时候，A 提出的意见会提醒 B，而 B 提出的进阶想法会刺激 C 发表意见。这样就会激发大家展开联想，引发条件反射，发散大家的思维。
子主题
初评方案梳理（BRD）
在方案梳理阶段，可以让研发、设计、测试人员参与进来。我们可以召开一个精简的短会，把多种方案的评审工作安排好，制作 DEMO，准备编写 BRD。BRD 主要包括以下几部分。
（1）当前产品情况概述：目前产品的运营状况是怎样的，遇到了哪些问题。
（2）问题分析：在遇到的问题中，哪些是核心问题，该如何解决。
（3）方案简述：解决问题的方案是什么，参考了哪些竞品，为什么选择这个方案。
（4）可行性分析：方案的可行性如何，有没有备选方案。
（5）成本预估：方案的投产比评估如何，其价值有多大。
（6）DEMO 演示：产品经理制作初稿 DEMO 并进行演示。
CQDACD
举例
PRD
cucumber 测试框架
结构逻辑
任务流程图（业务流程图）
对单一用户来讲，任务流程图一般是线性的，主要描述用户的操作过程
（1）确定用户的初始状态和结束状态，即用户出于什么目的，要做一件什么事情。
（2）确定中间有哪些分支流程，其判断条件是什么。
（3）连线并标注信息。
系统泳道流程图
下一步该分析后台系统层面涉及哪些交互动作和数据流转
系统泳道图可以说是任务流程图的另一个维度，它侧重于很多用户看不到的服务端数据流转。
系统泳道图的绘制步骤如下。
（1）列举哪些系统参与了该流程，用户操作在左侧，前后端依次排列成为泳道。
（2）按照任务流程图绘制系统泳道图，同时思考系统此时发生了哪些交互动作并补齐。
（3）连线标注系统交互动作名称。
（4）从左到右、从上到下重新布局，若动作同步（用户无须等待或需较短时间等待），尽量同行标注；若动作异步（用户需长时间等待），则跨行标注。
界面关系图
在梳理完用户的操作流程和系统层面的交互动作后，我们还需要绘制界面关系图，以便给用户呈现系统泳道图的进程。
绘制界面关系图时需注意以下几个方面。
（1）用户在每个步骤需要进行什么操作，他们可以看到哪些信息？
（2）这些步骤在几个界面中完成，每个界面分别包含什么元素？
（3）每个界面的上下级关系跳转逻辑是什么？
ER图
状态机图
时序图
4.2原型
原型图
包括元素、布局、数据、特性等要求
交互
：交互设计师或产品经理对原型图进行分析，进行交互层面的落地，包括布局和控件样式。
视觉稿
视觉设计师根据交互稿进行修正和视觉设计，包括色彩方案、字体、控件大小等。
4.3数据逻辑、关键表现数据、埋点
业务逻辑拆分
不同业务逻辑细分场景的数据表现
关键表现数据
埋点
4.4竞品调研
4.5数据系统、结构逻辑
数据系统
子主题
5.交互视觉
5.1视觉参考、调研对比
5.2竞品分析、风格梳理
5.3效果、动效梳理
5.4交互设计
5.5用户特点、习惯、情绪分析
5.6产品表现形式、重点
5.7切图兼容
6.开发落地
6.1完整需求定稿
6.2启动会议
会出现的情况和问题
（1）项目成员合作不畅，沟通混乱。
（2）目标不清晰，各自为战，浪费人力。
（3）信息共享不充分，项目实施效果不明显。
机制
15 分钟的站会
也能对当前的待办事宜进行同步。同步意味着减少了团队成员之间互相单点询问的时间成本，对团队的高效运作起到了很大的推动作用。
（1）敲定项目组成员和运作模式。
（2）高效同步项目信息，完成团队合作的破冰。
（3）同步项目目标，提高团队成员的积极性。
（2）高效同步项目信息，完成团队合作的破冰。
（3）同步项目目标，提高团队成员的积极性。
项目启动邮件下发
BATCM
子主题
（1）避免对方案进行深究，粗略计算工作量即可。
（2）引导各方提出风险点和疑问并给出解决方案。
（3）做好会议纪要并在第一时间告知领导及相关人员。
项目启动会议
BAOTO
项目启动邮件发出后，若无异常反馈，则可约各位干系人尽快召开项目启动会议。项目启动会议包括以下内容。
尊敬的各位领导、同事：
大家好！客户 App 体验优化项目启动会议将于本周五下午 3 点在 2001 会议室召开，请＠周总莅临指导，＠各位干系人务必到场，＠其他领导、同事酌情参会。
产品团队将负责会议的主持工作，议程如下。
BAOTO
（1）项目背景同步及确认。
（2）项目目标拆解及数据口径确认。
（3）组织架构干系人破冰。
（4）初期里程碑待办事项及时间节点确认。
（5）其他未尽事宜讨论。
整个会议时间不超过 1 小时，请各位拨冗参会，谢谢！
在会上，产品经理需要按照会议议程和每个议程的目标按部就班地组织讨论。在讨论的过程中，产品经理要注意以下 3 点。
（1）避免对方案进行深究，粗略计算工作量即可。
（2）引导各方提出风险点和疑问并给出解决方案。
（3）做好会议纪要并在第一时间告知领导及相关人员。
项目追踪材料准备
在团队开展项目时，产品经理需要时刻检视项目进度，发现问题并及时修正。这就需要产品团队站在统筹全局的角度，给出追踪材料和汇报材料，产品经理负责整理好这些材料并发送给各部门。这样做一方面可以保证团队的信息同步，另一方面可以使自己在高层领导面前保持一定的存在感，进而可以保持项目的活跃度，给团队以鼓励，使项目工作进入良性循环。
项目进展追踪材料的形式主要是周报或双周报（见下图），具体周期按团队节奏制定即可，切忌过于频繁而流于形式。若有重大进展，则可灵活安排。追踪材料有价值才是目的，周期和形式只是手段。
子主题
需求评审
会议安排及注意事项如下。
（1）主持人一般是产品经理，会议需要前端、后台、设计、测试等人员参与。
（2）会议议程是对照 PRD 逐项进行需求点的评审，由研发及测试人员给出工作量并确定方案，设计师和产品经理补充答疑。
（3）会议结尾要安排研发及测试人员复述需求，以确保没有错误。
（4）评审完成后，要总结好三方面内容：需求点工作量及排期情况；PRD 补充修改意见；初步的研发案例。
在评审会议结束后，我们可以以各方确认后的邮件形式代替会议纪要。邮件示例如下。
评审会议结束后
会议纪要
尊敬的各位领导、同事：
大家好！人脸识别需求已经于 6 月 19 日完成需求评审，共计 5 个工作日，暂定排期 8.1 版本。
感谢各位同事的大力支持，后续产品研发工作将由产品负责人花生酱及项目经理李研发跟进。
补充的 PRD 和研发素材包见附件。其他未尽事宜请反馈给以上两位负责人，谢谢！
在评审会议结束后，就进入了预研发阶段。在这个阶段，研发和测试人员需确认反馈的方案、用例，随后正式进入排期，开始研发。
会议期间，关键的人物必须到场，否则会影响后继工作的顺利开展。比如，我曾经提出了一个以后台为主导的需求，与后台、研发人员协商好，如果需要关联方配合，要及时和我沟通。但在需求快上线的时候，H5 开发团队突然发现这个需求需要 Native 支持，而此时 Native 已经没有人力安排，导致排期出现了问题。
在这个案例中，产品经理给主研发团队下发了任务，但邮件通知对研发人员来说是比较弱的通知。因此，在召开评审会议期间，研发、测试等相关人员必须全部到场，否则很容易出现信息传达不到位的情况。
总之，产品经理在这个阶段应第一时间发现团队存在的问题，协助团队解决问题。
6.3测试用例、走查
环境
测试环境
研发人员研发、测试人员测试所用的环境，统称为测试环境。测试环境是用来展示和遍历用例的。研发人员会在第一时间向测试人员展示自己的开发成果，对于这个环节，产品经理非常有必要参加。开发成果展示得越早，产品经理对结果干预参与得越早，产品可优化的空间就越大。
回归环境
回归测试
当研发人员在各自的分支上研发完毕后，就要把这些分支统一合并到主分支上进行测试，以防这些代码之间互相影响。这就是回归测试，回归环境是生产环境的初期形态。
预发布环境
在回归测试通过后，还需要在预发布环境中进行测试。此时，需要连接生产数据库，使用生产环境的真实数据进行测试。预发布环境的存在是为了消除那些不易被发现的测试环境和生产环境之间的差距。
生产环境
生产环境，这意味着代码已经完完全全以最新的形态在生产用户中运行。此时，生产环境的数据变更、代码修改等动作就需要严格管控了。当遇到生产问题时，不能草率行事，需要第一时间制定策略，如下发紧急版本、紧急公关等进行最高优先级处理。
回归测试
预发布
在预发布环境之后，若需要灰度，还会有一个灰度发布版本，操作方式就是在 10 台服务器中选择 1～2 台进行升级，若有问题，方便随时回滚。
验收
6.4需求变更记录
通常，一个需求是不会顺利上线的，需求变更的情况时常发生。如果不能妥善处理需求变更的情况，很容易引发团队成员之间的矛盾，甚至导致产品失败。
需求变更通常是各个团队最害怕发生的事情，因为需求变更意味着节奏被打乱了，已经打好的基础不适用了，前期分析的成果不准确了。这时，团队成员难免会产生抵触情绪。因此，我们要总结一套方法论，以应对需求变更。我们要做好预防工作，防止需求变更的情况发生，减少对团队造成的损失；如果发生需求变更的情况，我们应尽量凸显此次需求变更的必要性和价值。
第一，从源头上进行管控。从原则上来讲，我们并不希望发生需求变更的情况，因为需求变更是一种异于常规情况和流程的少数情况。但少数并不意味着不合理，需求变更往往是极大价值倒逼的结果，如领导层突然改变方向、监管政策突然调整、技术突然出现巨大革新。因此，我们的原则是，抵制伪需求带来的变更，拥抱有价值的变更。在面对需求变更时，我们要冷静处理，充分了解这次变更的价值和必要性，而不是在收到消息后匆忙找研发团队进行评估。
第二，从方案层面进行把关。如果有必要进行需求变更，那么我们就要决定是否变更了。是否变更取决于变更的价值增量是否大于变更成本，而变更成本要考虑产品的节奏和生命周期。这时，一定要和研发人员进行小范围评估，避免在还未下定论时牵扯太多人，造成不好的影响。当小范围评估完成后，要充分论证这次变更对未来的影响，并把变更历史记录在文档里。只有这样做才能保证这次变更不是草率的，且对下次评估和变更有警示作用。
第三，加强团队情绪管理。当发生需求变更时，团队成员的第一反应是担心、恐惧、不理解。为了减少给团队成员带来的伤害，需要帮助团队成员从情感上得到收获。最好的方式是使团队成员获得成就感和认同感，这就需要我们做好团队成员的心理建设工作。首先，要和团队成员达成共识，即这次变更是一件好事，并且要摆出事实数据来证明，如这次变更提高了点击率、转化率。通过这样的方式，改变团队成员对需求变更的不理解。其次，要提高团队成员的参与度，把每次需求变更变成团队成员的共同决策，而不是某个人的「一意孤行」。只有这样才能提升团队成员的成就感，使大家理解需求变更是不可避免的。
总而言之，需求变更即变化，变化是普遍存在的。在处理变化的过程中，我们要认识变化、评估变化、管理变化，从这 3 个层面递进式地拥抱变化。只有这样，我们才能做出优秀的决策，落地完美的变更。瞬息万变本身就是产品的属性，以不变应万变才是产品经理最好的状态。
需求变更通常是各个团队最害怕发生的事情，因为需求变更意味着节奏被打乱了，已经打好的基础不适用了，前期分析的成果不准确了。这时，团队成员难免会产生抵触情绪。因此，我们要总结一套方法论，以应对需求变更。我们要做好预防工作，防止需求变更的情况发生，减少对团队造成的损失；如果发生需求变更的情况，我们应尽量凸显此次需求变更的必要性和价值。
第一，从源头上进行管控。从原则上来讲，我们并不希望发生需求变更的情况，因为需求变更是一种异于常规情况和流程的少数情况。但少数并不意味着不合理，需求变更往往是极大价值倒逼的结果，如领导层突然改变方向、监管政策突然调整、技术突然出现巨大革新。因此，我们的原则是，抵制伪需求带来的变更，拥抱有价值的变更。在面对需求变更时，我们要冷静处理，充分了解这次变更的价值和必要性，而不是在收到消息后匆忙找研发团队进行评估。
第二，从方案层面进行把关。如果有必要进行需求变更，那么我们就要决定是否变更了。是否变更取决于变更的价值增量是否大于变更成本，而变更成本要考虑产品的节奏和生命周期。这时，一定要和研发人员进行小范围评估，避免在还未下定论时牵扯太多人，造成不好的影响。当小范围评估完成后，要充分论证这次变更对未来的影响，并把变更历史记录在文档里。只有这样做才能保证这次变更不是草率的，且对下次评估和变更有警示作用。
第三，加强团队情绪管理。当发生需求变更时，团队成员的第一反应是担心、恐惧、不理解。为了减少给团队成员带来的伤害，需要帮助团队成员从情感上得到收获。最好的方式是使团队成员获得成就感和认同感，这就需要我们做好团队成员的心理建设工作。首先，要和团队成员达成共识，即这次变更是一件好事，并且要摆出事实数据来证明，如这次变更提高了点击率、转化率。通过这样的方式，改变团队成员对需求变更的不理解。其次，要提高团队成员的参与度，把每次需求变更变成团队成员的共同决策，而不是某个人的「一意孤行」。只有这样才能提升团队成员的成就感，使大家理解需求变更是不可避免的。
总而言之，需求变更即变化，变化是普遍存在的。在处理变化的过程中，我们要认识变化、评估变化、管理变化，从这 3 个层面递进式地拥抱变化。只有这样，我们才能做出优秀的决策，落地完美的变更。瞬息万变本身就是产品的属性，以不变应万变才是产品经理最好的状态。
6.5确定发布范围、用户、时间
6.6UAT测试、生产验证
7.发布汇报
7.1试点推动计划
7.2业务、运营、运维宣导
7.3上下级、关联方通报汇报
关系主旨
存在的难题
在做 B 端产品的过程中，因为产品是为业务部门服务的，所以产品经理和业务部门打交道的机会将会很多。而业务部门又是产品的直接或间接用户，所以产品经理需要和业务部门建立良好的关系。
但业务部门和产品部门其实存在天然的冲突。业务部门直接关系到利润和销售额，是项目或产品的主体和需求方，因此业务部门对产品的要求非常高，且拥有很大的话语权。而产品经理的使命是最大限度地创造用户价值，这就难免要和业务部门产生碰撞、摩擦。由于话语权有限，产品经理很容易陷入被动，导致产品决策权弱化。所以，产品经理面临着在夹缝中生存的挑战。
● 亲近业务部门，会导致容易变成业务部门的执行人员，还会导致研发部门受到打压。
● 亲近研发部门，会导致和业务部门疏远，使自己在整体价值体系中处于弱势地位。
解决方案
这时，我们需要一套方法论，既要做好业务部门的预期管理，又要为研发部门减压。我的高效方法论是：守住研发部门的立场，一方面制定流程、制度约束业务部门，另一方面要尽可能亲近业务部门。这个方法看似矛盾，其实不然。因为研发流程对业务部门来说很陌生，但研发部门是有了解业务需求的诉求的，这样的立场关系造成了主动方和被动方的矛盾。
所以，我们要团结主动方（研发部门）与被动方（业务部门），让他们达成共识。
高效汇报
重要性
沟通和汇报是实际工作中非常重要的一部分，一个关系到业绩的考核，一个关系到与领导的距离，以及能否为以后的工作争取资源。但事实上很多人都忽略了沟通和汇报工作，觉得它们枯燥、无聊、没难度，不能提升能力。
其实不然，在团队协作的过程中，信息衰减是很严重的。比如，有的人很有能力，做 10 分，说 6 分，领导只看到 5 分；有的人很擅长汇报，做 9 分，说 8 分，领导能看到 7 分。所以，汇报是工作中尤为重要的一部分。
很多产品经理工作很用心，却无法引起领导的重视。出现这种情况的一个重要原因就是产品经理在汇报、沟通时缺乏逻辑、没有规划，导致自己的付出没有得到相应的回报。
流程
我们可以把沟通汇报的流程想象成一个 Feed 流，领导就是我们的用户，我们该如何运营呢？
沟通汇报的流程大致可分为三个阶段：沟通明确阶段、跟进进展阶段、总结汇报阶段。
在这三个阶段中，我们的汇报原则和汇报重点是不同的。在沟通明确阶段，当接到领导需求时，要厘清 6W3H 的九大点，不清楚的点要和领导当场确认。只有厘清这几点，才能完全领会领导的意图，从而进一步进行需求分析和方案确认。
那么，何为 6W3H 原则呢？
（1）Why：为什么要这样做？
（2）What：具体要做什么？
（3）When：什么时候开始？
（4）Where：针对哪个模块或哪个问题？
（5）Who：谁来负责？
（6）Whom：关联方是谁？
（7）How：具体怎么做？
（8）How Much：成本是多少？
（9）How Long：需要花多长时间？
举例
子主题
节奏
记录好项目的关键时间节点，做好汇报节奏的规划，不能事事都请示领导，否则会变得依赖领导；也不能不请示，否则领导会觉得我们的工作情况不在他的掌控之中。
具体的汇报节奏要根据领导的时间安排和工作习惯而定，如两天左右汇报一次或在下班时间汇报等。如果遇到方案确认或需求变更的情况，一定要及时告知领导，范例如下。
领导好！
报表精简项目正在推进中，目前进度正常，风险点暂无。
为提升体验，我们新增了筛选功能，后端工作量不变。
我们重新布局了信息展示，效果图见附件。
各项情况汇报完毕，谢谢！
在跟进进展阶段，我们既要让领导了解进度的情况，又不能给领导造成困扰。
总结汇报
在总结汇报阶段，当项目快要结束时，一定要把一开始的目标和最终结果进行对比。在总结汇报时要用数据说话，这样才会给领导留下深刻的印象，范例如下。
领导好！
报表精简项目已经推进完毕，11 月 6 日至 11 月 30 日，需求完成率达 100%。
目前页面使用次数增加 20%，载入时间减少 50%。业务部门反映，改进后的报表功能得到好评。
各项情况汇报完毕，请指示，谢谢！
心得
汇报工作做不好会导致很多项目石沉大海，因此我们一定要加以重视。
在职场中，沟通和汇报是非常重要的。一个成熟的职场人不应抱怨工作的繁杂，而是理解、运用职场的上下级运作规则来实现自己的利益最大化。不用心汇报的人可能会承受更大的压力，面临各方的质疑；而认真汇报的人，他的工作会变得越来越轻松、简洁。
7.4阶段性成果汇报、未来迭代优化
7.5数据进度知会
0 条评论
下一页
