作为一个产品新人，一开始往往满腔热心投入产品工作中，然而在项目流程中，还是会因为出错而被团队、被老板质疑。笔者结合这样的疑问，向我们分析了如何应对这样的状况。

不久前，老同学说自己最近转行做产品了，由入行时的信心满满到现在的满脸疲惫，也不过几个月的光景。

比如最近在跟的一个项目，光是需求评审就过了不下五遭，哪怕线下准备很充分了，但依然每次都被开发测试怼得无地自容。现在一提起过需求，就很紧张。

于是我问了下她的项目流程，她说：接到需求后，她大概了解了情况，就开始画原型图，画的时候有疑问，再去找甲方沟通确认，然后反复更改原型图。

画完后，就拉着老板和项目组同学开始一页页过原型，然后再回去改。于是，这样的故事每天在不停地上演着，直至自己心力憔悴，团队不信任你，老板对你质疑……

的确，刚入坑产品经理时，很多人都曾想象自己是来指点江山挥斥方遒的，但事实上除了一地鸡毛还是一地鸡毛。

这种现象更多地出现在创业公司，或是没有前人引路的产品，俗称“野路子产品经理”。

这些人只能凭着自己的直觉去闯去试去摸索，不停地在挖坑填坑中让自己成长。极少数幸运的同学从坑里爬出来了，但更多的都是被坑给埋了。

所以，想通过这篇文章跟大家聊聊，刚接手一个项目时该怎么下手，能让自己更加游刃有余，能让开发测试更加信服。文章将从业务意向沟通、业务梳理、方案设计、交付产出四个产品核心技能方面进行阐述。（本篇仅局限于接手项目的讨论，不包含自主探索类产品）

Step1：业务意向

业务意向沟通，主要是了解项目的背景、目的和价值。

所谓背景，就是要了解这个项目是由谁提出来的，是基于什么场景什么考虑提出的这个业务意向？提出的意向是想解决哪些用户群体的哪些问题？解决之后能带来什么样的价值？这个项目涉及到哪些干系方？如果延期或者不做，又会怎么样？

这个时候，趁着手干事儿前，尽可能多问几个为什么，通过为什么来了解这个项目更多的信息，尤其是业务方（或其他项目提出者）未告诉你或者不想告诉你的事儿。

要知道，为了让你尽快推动实施项目，业务方也会想方设法找出不得不做的理由/借口；这时候就要你擦亮眼睛，辨别这确是客观的理由，还是主观的借口。这对你接下来每一步的判断，至关重要。

Step2：业务分析梳理

在沟通确认完业务意向后，就要开始对业务意向抽丝剥茧，一层一层剥洋葱式的对业务进行拆解、梳理，最终组装成产品语言，交付至项目团队。

本章节，我们将会从用户故事、产品业务形态、状态流程图、业务流程图、页面流程图等维度展开。

1. 用户故事

产品设计最核心的三个要素，分别是：用户、场景、需求。产品设计，就是不断地解决用户在特定的场景下的需求。

• 用户：用户是谁，有哪些角色，也就是涉及到哪些干系方；
• 需求：核心需求是什么，即不同的用户，分别在什么场景下会使用；
• 场景：产品满足了用户的哪些需求。

而用户故事，就是这三要素的组成。理清用户故事后，也就明确了不同的用户角色需要系统支持哪些功能了。以网点充值为例：

因此，当开始接触一个项目的时候，首先需要梳理的就是这个项目里涉及到了哪些用户，分别在什么样的场景下有什么样的需求。而在这里面，最核心的用户、场景、需求是什么，辅助核心元素打造整个业务生态的又是什么。分清主次之后，产品的规划节奏随之就很明朗了。

（注意：增加、减少功能并不是关键，关键在于能不能解决用户的问题。而很多产品新人也最容易在功能点上纠结，这时候就需要考虑下产品设计的三要素了。

2. 产品业务形态

产品业务形态，主要是用来描述产品的基本框架，简述业务的整体面貌。

这个环节更关注用户角色、信息和渠道，以及各自之间的流转关系。简单来说，就是通过这样一张简单的图，能够让人快速理解这个业务是怎么运作的。

比如，站点在系统里的关系，就是发起充值；站点发起之后，其他参与系统又分别在其中担任了怎样核心的角色。

或者可以再看下抖音的业务形态：只是简单提到了内容生产者和内容消费者，当然这期间还有平台运营者在运筹帷幄，如果加上那会更加完整。

3. 状态流程图

状态流程图，顾名思义，就是以“状态”为对象的流程图，描述的是状态的正常、异常分支的流向，前置后置条件。

要注意的是，状态流程图不是每个项目必须的，而是要取决于实际的项目，根据项目实际来判断。比如抖音没有状态也就不会有状态流程图。

对于状态流程图来说，建议按下述三个步骤进行：

1. 梳理主流程，明确主流的状态
2. 拆解各个环节的异常分支，对各类异常情况分析完成后进行整合
3. 完成整个业务生命周期里的状态流转图

4. 业务流程图

业务流程图，这个大家应该都很熟悉了。不管是toC还是toB，都会有业务流的概念，比如APP注册/登录的流程，淘宝购物的流程，天猫退货的流程等等。这块的技能已经有太多人讲了，这里就不详细展开了。注意以下两点就行：

• 涉及到多个业务方或者多个系统时，泳道图一定要“切图”。横向，相关系统；纵向，拆解的阶段。
• 根据状态流程图梳理的业务，绘制业务流程图，梳理流程的前置、后置条件和异常分支等。

以充值的为例，看下大概的框架：

5. 页面流程图

需要交互的系统较多，在原型评审前，帮助组内同学快速建立产品的页面概貌。那页面流程图和原型图有什么差别呢？

页面流程图，只要把涉及到的页面整理出来，然后把每个界面参与到的核心事件（核心操作按钮）表述出来即可。这个地方一定要克制，要克制，要克制。

Step3：方案设计

经过上述的业务拆解之后，这时候原型该是怎么样的：会有哪些界面，每个界面分别做些什么事，有哪些按钮，哪些字段，这些按钮字段的定义分别是什么。这些应该都在你心里了对不对？

然后就是绘制原型图的时候，注意细节，不要有遗漏，那就很棒啦。

1. 页面交互图

2. 相关注释

① 权限说明：数据权限、菜单权限

② 数据内容：

• 筛选条件的范围、规则和交互
• 列表数据的排序规则
• 列表字段的定义、来源、限制、规则等描述

③ 操作说明：

• 操作的前置条件、后置结果
• 异常逻辑
• 交互样式

Step4：交付产出物

走到这一步的话，恭喜你，再把资料整理整理，然后就愉快地去约你的项目组同学去评审吧。相信我，这个时候，开发小哥哥们肯定会很喜欢你咯。

不过更建议在业务梳理完成的时候，就先找开发测试同学先沟通一遍，剔除无法实现、实现复杂的，甚至可能在沟通中会有更好的方案哦。当然啦，这个阶段可以只约核心同学哈。

结语

好啦，关于项目分析的分享就到这里啦~~在最后，预祝各位野路子的产品新人，能够在产品之路上越走越远，与开发测试的小哥哥小姐姐们都能和睦相处哦。

本文由 @泡泡 原创发布于人人都是产品经理，未经作者许可，禁止转载

题图来自Unsplash，基于CC0协议