决定toB产品经理的，从来都不是一时兴起

最近在做需求时，遇到了一个值得注意的点。这个需求的功能是检定资产，名字不重要，关键是过程，在这之前公司没有人做过这个功能，于是就派我去现场调研，到了之后没有见到对方领导或者其他负责人，最后就与基层操作人员进行的沟通。说实话，效果着实不太好，他们可能也不知道怎么表达，他们只是把之前系统的流程、操作方式又跟我描述了一遍，并没有提出什么建设性的意见，即使我不听他们讲，我自己走一遍流程跟他们描述的效果一样，但是既然是要重新做，那就证明原来的功能已经不适合业务场景了。当时没有经验，没有深度挖掘客户需求，直接上手就开始做，于是我做了一个流程极为繁琐，分支极为庞大的功能，结果导致了比他们之前的系统还难操作，还好最后我们通过看别的系统大概知道了这个功能的流程，最后做了优化。这次的教训让我也知道了，做产品，从来都不是一时兴起，说干就干。

下面是在做toB产品过程中的一些经验：

1.了解项目背景和目的

我们通常在做一个项目的时候，一开始是要调查项目的背景和搞清楚做这个项目的目的是什么，这个很简单，一般项目资料中都有关于项目背景及目的的说明，例如：项目可行性研究报告、项目招标文件等。从资料内容中了解到为什么要做这个项目？项目要达到什么效果？明确的项目目的有助于聚焦核心功能，围绕目的开展项目需求分析工作。

2.了解用户

分析项目用户，目的是要明确系统的使用用户，针对不同类型用户分析需求。不同类型的用户关注点不同，对系统的需求存在差异，甚至有可能出现需求冲突。

用通俗的例子就是，当你跟领导沟通的时候，调研出来的结果可能是美观大方，结构看起来庞大，但是跟基层人员沟通的时候，调研出来的结果可能就是方便好用，当然还会涉及到不同部门对应不同功能，操作习惯也不太一样。当按照领导意愿做出来的时候，真正用这个系统的基层人员可能就会叫苦连天，还会吐槽这做的什么系统啊。所以如何权衡，一方面要引导负责的人，一方面就需要我们真正了解用户了。

3.需求获取方式

包括用户访谈、实地参观工作流程、发调查问卷、与同行，专家交谈，听取他们的意见、竞品分析、从行业标准、规则中提取需求、网络获取、公开的文献资料获取、调查之前已用的系统等。最常见的就是用户访谈。

就拿用户访谈来说：

在正式开始用户访谈前，应对项目已有资料进行整理，适度调查分析。通过前期了解分析，猜测用户需求，提出我们的解决方案，形成文档、原型或系统演示。在客户角度分析问题，以系统可以为客户创造的价值为核心。作为需求调研的基础。尽量采用原型、系统等直观方式。确定访谈人员、访谈内容，编写访谈议程，确认访谈时间。

在访谈时，要进行适当的引导：

在系统使用场景下，详细地询问用户思考和执行的过程，收集用户需求。把之前考虑过的方案拿出来展现给用户，并简单讲解，询问客户意见，引导用户说出自己的想法。重点关注新方案对用户是否有吸引力，在哪些方面，并追问为什么。

接下来是很重要，很宝贵的引导经验，这个是公司老人总结出来的，我觉得真的可以收藏一下：

1）尽量少发表评论和交谈，因为这次访谈是为了获取信息，而不是推销你的思想；

2）给答话者以思考时间，不要去建议这样那样的答复或提出另外的问题；谈话过程中的暂停有利于答话人回忆一些关键的信息；

3）避免可能打断他思路的外界干扰；

4）尽可能确定一下所获得的信息是事实还是意见。如果是意见，要考虑不同意见存在的可能；

5）请求复述一遍或小结一下以便表达得更精确些；

6）弄清答话人的背景和与所讨论事物的联系，因为只有知道了他与组织或已有软件系统的关系才能了解他的评论的价值；

7）对答话人所谈的内容要表示出感兴趣；

8）要重视对同一问题的不同意见，然后用在初步需求中标明这些意见并解决矛盾；

9）给对方积极的回应，表明你在专注地聆听。

最后做访谈总结：记录用户访谈过程意见，汇总本轮调研用户的过程和结论，决定是否需要继续调研。细化讨论内容，不断完善项目需求。

这个时候大多数会遇到意见不一致的情况：

a.如果同一部门意见不一致，则由部门领导确定意见；

b.如果不同部门意见不一致，则应再召开部门间会议统一意见。注意：这时的会议需要不同部门的领导参加，并且不同部门的与会人的级别应相同。如会议上不能统一意见，则报请上级确定。

接下来都是干货

3.对于用户提出的每个需求都要知道“为什么”，并判断用户提出的需求背后的理由

4.将“如何实现”的表述方式转换为“采用A方案或B方案”的方式

客户没有明确的需求时，为客户提供解决方案供其进行选择。

5.分析由用户需求衍生出的隐含需求

识别用户没有明确提出来的隐含需求（有可能是实现用户需求的前提条件），这一点往往容易忽略掉，经常因为对隐含需求考虑得不够充分而引起需求变更。

6.项目必须平衡需求（包括功能和质量）、进度、成本三者。

权衡时为保证进度、成本，则必须对需求进行删减，其删减依据就是需求优先级。需要内部沟通理解，分析建设内容可行性，综合考虑开发难度，围绕项目中心，非项目核心功能可适当进行优化。

7.了解自身系统功能，尽量以现有系统为基础向客户介绍解决方案，有利用项目后期实施节约成本。

可以根据招标文件提出的功能画一个原型或利用现有原型。

在写文档画原型之前要准备以上工作，我们最终要思考的，是把项目转化为产品，达到之后接到的项目都可以复用的效果，这其实并不容易，要求我们的不仅仅是逻辑能力的、业务能力的考验，还有对客户、对用户、对项目的了解，大量的厚实积累和充足准备，才促成了一个“好”项目的诞生。

所以，决定toB产品经理的，从来都不是一时兴起。