从产品小白到产品经理，我用了三个月时间_产品发布、测试、跟进-CSDN博客

本文链接：https://blog.csdn.net/2401_84008929/article/details/137206074

2)数据分析

当你与领导或同事对于某个决策有争议时，用数据说话是最简单直接的解决办法。PC端用百度统计、移动端一般用友盟，可以很方便的查看网站的PU、UV、平均访问时间、数据漏斗等关键性指标。

3)A/B测试

A/B测试用于比较两个相似的版本，除了一个影响用户行为的变量之外，其他的条件要相同。当样本量很大时，A/B测试的效果会非常显著。

比如向用户推荐福利的时候，是用“残忍拒绝”还是用“有钱任性”的文案作为关闭按钮时，对比一下就能看到点击率的区别。

需求分析

4.1 需求来源

A.被动告知需求

1)主要业务部门：包括市场、运营、管理层等主要业务部门，可能是一个新的业务、活动或者机制的更改;

2)客服：当用户频繁咨询或投诉一个问题时，客服会将问题提交给产品经理评估;

3)用户意见反馈：用户通过挑错建议等方式反馈的问题，需主动收集，评估并及时处理。

B.主动收集或挖掘需求

1)竞品分析

竞品分析的方法在前面已经说过了，通过竞品分析我们可以挖掘部分本产品未解决的用户需求。

2)用户研究

作为产品经理，前期的竞品分析、用户研究都是在挖掘用户需求。另外，在挖掘用户需求的时候，我经常会用画脑图穷举法用来做最后的需求梳理。“遇到的问题”即用户需求，“解决办法”即相应的功能。

4.2 需求类型

对于已上线的产品，在做产品迭代的时候，可以对需求池的产品进行分类，以帮助我们来确定需求的优先级。主要的需求类型有：新增功能、功能改进、体验优化、BUG修复等。

4.3 需求优先级分析

我常常会用两个四象限分析法来综合评估需求的优先级，这里建议一个团队的产品经理以来做这一项评估。很多时候我们会遇到很多需求都在一个象限里，所以这里推荐两个四象限分析法，可以综合评估。

1)“用户量-使用频率”四象限

2)“见效快慢-开发难度”四象限

经过分析和评审之后基本可以决定全部需求的优先级了，优先级最高的需求在第一期的MVP(最小可行性产品)中实现，优先级较低的需求放在下一版或下几版的产品规划中分批实现。

产品策划

5.1 业务流程图

A.什么是业务流程图?

描述具体某个业务实际处理步骤和过程的流程图。

B.为什么要画业务流程图

1)了解业务：帮助整个团队了解产品的业务是如何运转的，并且对业务流程中不合理的地方进行优化;

2)梳理需求：帮助产品经理梳理业务需求在产品线的各个阶段中功能模块之间的关系;

3)传达需求：研发工程师构建技术架构和明确技术分工会主要参考业务流程图。

C.怎样画业务流程图?

1)确定范围

确定业务流程的起点和终点，是截取某一段业务进行详细描述，还是整体业务模块进行描述。

2)确定要素

谁，在什么情况下，做了什么事，这个事需要什么前置条件，又输出了什么，是在哪里完成的?搞明白这几个问题，我们的要素就确定了。

2)梳理呈现

怎么画流程图这里不赘述了，用什么工具、怎样更精美都是不重点，重点是关键要素的搜集和确认。泳道图是常用的一种表现形式，一般横向代表用户角色，纵向代表各阶段。

4)评审确认

a.让涉众参与评审：业务流程图中涉及到的用户角色或部门要尽可能让他们参与到评审中来，切忌自己YY;

b.层次分解，重点突出：流程很复杂的，可以在一个主图里展示主要流程，在其他图里分别将主流程中待展开的流程进行展开。

5.2 页面流程图

A.什么是页面流程图?

描述产品的全部页面相互间关联的流程图。

B.为什么要画页面流程图?

1)了解全局：对于整个团队，页面流程可以从表现层了解产品的全局;

2)梳理业务：反复研究页面流程图并优化，可以使整个产品变得更加简约;

传达需求：设计师要设计多少个页面，前端工程师要写多少个页面一目了然。

C.怎样画页面流程图?

1)找出所有的页面：找出所有物理层面的、真实存在的页面，切忌不要像业务流程图一样具体到某个功能和模块;

2)用有向线条关联：把所有相关跳转页面用有向线条关联，页面流程图较复杂的可以反复研究如何让其更简约的呈现;

3)增加条件判断：从上一个页面跳转至下一个页面的条件是什么，在页面流程图里体现出来，对于设计师来说非必须，但是技术来说可以了解业务。

5.3 功能结构图

A.什么是功能结构图?

描述功能之间从属关系的图表。

B.为什么要画功能结构图?

1)梳理需求：帮助产品经理思考并清晰产品的功能模块及其功能组成，避免在产品需求转化为功能需求时，功能点出现缺失;

2)传达需求：对于不确定的产品样式问题，可以一种较为简洁明了的方式来表达;

3)提高效率：发现功能结构不合理的地方可以快速做出调整，避免在产品设计的细节上浪费时间。

C.怎样画功能结构图?

1)提炼主要功能模块：我们可以通过业务流程中涉及到的功能需求去提炼出主要功能模块;

2)细化功能粒度：根据自身业务，将主要功能模块拆分到更细的粒度。

5.4 信息结构图

A.什么是信息结构图?

从产品的实际页面中将数据抽象出来，组成分类的图表。

B.为什么要画信息结构图?

1)梳理信息：帮助产品经理梳理产品的信息组成，避免信息内容在展示过程中出现遗漏和重复;

2)传达需求：作为技术建立数据库的参考依据。一条信息的存储有很多附加属性，具体的是存成字段还是数据表，还是中间表或者关联表，这些都需要在完成PRD之后与数据库技术人员进行讨论。

C.怎么画信息结构图?

1)将产品的全部信息进行罗列，建议使用脑图;

2)将产品的信息进行梳理使其结构化。

5.5 原型图

在产品策划阶段，产品经理通过业务流程图、页面流程图、功能结构图和信息结构图确定了产品都有哪些页面、页面里有哪些功能和信息、哪些操作是如何跳转的之后，就需要通过原型图将我们的产品直观的表达出来。

对于设计师，原型图是最重要的参考物，他们关心的是产品各元素之间的排版和布局;对于研发，原型图是他们了解功能，评估功能复杂程度，边界条件是什么，异常情况怎么处理的最直接的参照物;对于测试，他们需要通过原型图辅助写测试用例，以及原型图是否穷尽各个场景;对于领导，他们的事情比较多，原型图的易读性也成了他们最关心的产出物。

画原型的工具一般使用Axure，网上的教程有很多，不会的同学可以自学。这里想说一下什么样的原型图才算得上专业。

1)设计符合用户的认知模型

相同属性的功能进行分组，相近属性的功能放在一起。例如：我的资料、我的订单、我的收藏、我的资产会归纳放到“我的”里边;“加入购物车”和“立即购买”经常会放在一起。

2)交互逻辑无缺失

例如：商品列表页浏览前和浏览后的文案的颜色有无区分?商品列表页过长时导航栏是否需要悬浮置顶?

3)异常场景不遗漏

例如：页面加载失败时提示用户什么?用户从WiFi切断到数据流量时提示用户什么?

4)关键字段有规则定义

例如：发布时间的字段是显示年/月/日还是月/日?显示月/日的话跨年了怎么办?发布时间在一天以内的话是显示多少个小时前还是显示月/日?

5)极限情况有定义

例如：用户名最长为多少字?页面没有数据时展示什么?页面数据过多是怎么展示?

6)全局组件有说明

全局组件指的是产品通用的组件，例如：断网、操作成功、操作失败、正在加载、空数据界面、404等。

产品推进

产品策划的方案，主要是原型图，经过部门内评审、技术可行性评审、公司高层评审(根据项目的实际情况而定)之后，就进入到了产品推进阶段。这个阶段你需要经历的过程有编写产品需求文档(PRD)，需求对接、设计跟进、前端跟进、研发跟进、测试跟进和上线跟进。本阶段涉及的专业性知识不多，但是雷区却不少，我结合自己的工作经验来分享一下哪些雷区是你需要避开的?

1)PRD编写不细致

技术在开发时会按照你的PRD来执行，如果你对需求的描述不够细致甚至是逻辑缺失，会导致技术在开发时加入自己的理解来实现，最后达不到产品预期。其次，因为需求描述不完整导致在开发过程中新增需求，是技术最痛恨的事情。为了不增加研发工作量，PRD编写越细致越严谨越好。

2)需求对接不透彻

设计师、前端、技术和测试会根据你的原型图和PRD来开展相关工作，有时候你以为需求已经通过原型图和PRD表达的很清楚了，但是在需求的理解上一定存在信息不对称的情况。集体需求对接会是必不可少的，将需求的对接做到尽可能的透彻，对接会结束之后一定要给相关人员发邮件;在产品推进过程中，要及时与相关人员沟通和跟进，将需求理解不透彻导致返工的风险降到最小。

3)需求中途变更

前期的需求分析、方案评审等环节，产品经理是必不能偷工减料的，一旦对某一环节的忽略抱有侥幸心理，最后的后果就是研发过程中需求变更。如果需求中途变更，一方面会增加相关人员的工作量，另一方面会损害自己的口碑。如果中途因为一些事先没有预料到的因素，比如领导临时变更需求，作为产品经理要做好需求管理，实在需要变更的要尽量说服相关人员，推动大家去完成。

4)技术砍需求

一个需求有时候从技术的角度来考虑，为了减小自己的工作量或者根据他们自己对业务的理解，会出现砍需求的情况。产品经理需要做的首先是倾听，合理的话可以讨论，不合理的话要拿出我们的用户研究、需求分析结果以及需求对接邮件据理力争。

5)工作进度模糊

在需求对接会上，项目规划和确认是必不可少的一环，相关人员需要根据工作量评估自己工作的时间节点，大家根据约定的时间来完成工作。如果缺失这一环节就会导致工作进度模糊，上线日期延期。其次，根据项目的需要可以考虑每日站会和阶段性的产出物评估会。