B端产品调研方法论
写本篇文章的目的：第一个目的是作者即将步入第一个三年，对以往的工作进行总结，准备进阶突破；第二个目的就是与大家分享与讨论。
我们都知道B端产品的设计最主要的是业务逻辑与错综复杂的业务流程，设计B端产品的时候要有清晰的思路，否则就像身处在迷宫之中，迷失了方向。
那么接下来我给大家讲解一个梳理B端产品切实可行的方法，来帮助你们完成B端产品的设计。
下面我将从目的、需求收集/整理、设计模块、输出原型这几方面来完成我的方法论讲解：
第一步 明确目的
我把目的划分为三个层次：
- 第一层属业务层次，此层次目的为用信息化手段让业务流程标准化，从而形成有效数据，抛弃纸质或独立个体表格数据，形成部分可共享查看的数据；
- 第二层为管理目的，包括进一步改善不合理的流程，通过业务数据提取计算职工的部分PKI或通过系统约束职工的某种违规行为；
- 第三层为公司为了长远发展而提出的一些战略目的。
第一层和第二层的调研目标均为管理者和执行者，第一层偏向执行者，第二层偏向中层管理者，而第三层则需要和公司高层领导进行深入的沟通。
就我目前而言只修炼到了第二层，可通过系统帮助管理者完成一些业务流程的优化和提取KPI等目的，并不能驾驭第三层为产品注入公司的战略灵魂。
明确目的建议在项目启动会中完成，项目的相关负责人以及领导都会到场，此时明确目的是最佳时机，以免造成沟通障碍。调研目的时可从这几个问题中展开：
- 为什么要做此项目（做此项目的目的）？
- 希望此项目解决什么问题？
- 期望达到什么样的效果？
此外项目立项中我们还需要明确项目的范围和先关干系人。
第二步 需求调研/整理
需求调研对于初级者来说是个坑，常常是拿到项目之后就去组织召开调研会议，对于一头雾水的初级者不知道具体调研什么，也就成了调研对象说什么然后记什么，会议结束后发现这些需求根本连不上也无法整理。
所以调研一定要讲究方法去分步调研，文章开头说B端产品逻辑流程最重要，所以我们要先搞清楚业务流程与逻辑。调研业务流程的方法可是走访部门也可是会议的形式，无论是哪种形式，都需注意一点，要循序渐进的调研，什么意思呢？就是业务流程是分层级的，注意每次调研所处的层级。
在设计流程的时候要注意这几个问题：
- 有没有流程颠倒的情况？
- 每个流程点是否有分流程?
- 每个流程是否是必须存在的?
- 此流程的上下游是什么?
1. 明确流程
第一步
调研总体流程的时候就不要去纠结细节，调研时要首先声明此次调研的目的，如果有人过度展开时要即时提醒，不要被他的思路带入细节中去，否则你会有种盲人摸象的感觉。
比如以采购为例，那么我们首先要了解采购的大致流程：
这张图表达了采购流程的各个阶段，每个阶段需要做什么事情，具体由哪个部门去做。
如果第一步能做到把这张图调研清楚，那么此次调研就算是成功了，这里每个节点都可进行展开，但不要在此调研层级展开。
第二步
我们要继续进行深入调研，这步我们需要明确某个阶段的流程是怎样的，此时也需要继续注意层级的概念，此步骤要有种只见森林不见树的感觉，知道这是一片森林，但是里面具体都是什么树却看不清。
比如我们调研采购的付款环节：
虽然看上去这张图是很清晰每个步骤要干什么，但真正到了详细步骤的时候只根据这张图是看不出具体做法来的，所以这就叫做只见森林不见树。
2. 整理需求
要做到又见森林又见树，需要对业务进行详细的调研，并将调研的需求进行整理归类，以此来洞察用户行为，此步骤要捋清每个操作环节具体的流程以及业务逻辑，所以此步骤是最重要也是最容易混乱的，所以在调研此步骤时我借用了C端产品的用户故事地图，来完成此项任务：
第一个阶段是根据第二步得出的流程，用户需求是调研中用户所提出的需求，用户行为是需要将用户的需求整理成用户行为描述出来，这样每个节点的逻辑与流程就出来了，最后记录存在的问题。
在完成此步骤时需要考虑这几个问题：
- 某个流程节点下用户都需要做哪些行为？
- 需求中是否包括用户的所有行为？（伪命题，不要尝试穷举所有行为）
- 用户会在什么情况下做这个行为？
跟图这张图可画出详细的流程图或直接引用这张图也可：
这样我们就完成了业务流程与逻辑的调研，不过有人会问，这样真的满足了对方所有情况了吗？我的答案是否定的。一家公司一般意识到想要发展信息化，至少要有10年左右的历史，那么你要用短短的几个月时间把这个流程全部搞清楚是不可能的，这家公司也未必能和你说清楚，所以需要一个迭代过程。
3. 铸魂（管理）
以上是我们完成了一个关于应付账款的调研，如果按照上述需求去做设计，那肯定会满足他们的需求，实际操作中也不会出现什么问题，那为什么还要做第三步呢？
我认为我的产品是不能轻易被打败的，也不会别人介绍我的产品的时候说“和某某产品类似”之类的话，我希望我的产品是一个有灵魂的产品。
这个事情是很难做到的，这里我所说的给产品铸魂也是注入管理的灵魂，管理这东西虚无缥缈，你说他没有，但是他有，你说他有但又看不见。
所以管理是存在每个环节中的，甚至一个小小的按钮都能体现管理的作用。比如在采购物料编码存在过多重复性垃圾数据时，系统如何帮助物料管理者去除重复的垃圾；在供应商过多时，如何为管理者提供筛选供应商的依据；如何帮助管理者有效管理员工。这些都是管理，我们将这些细节注入到产品中，就形成了我们的产品“魂”。
第三步 设计模块
用脑图清晰的表述出每个模块的作用与功能，此步骤的目的在于帮助你再次回到全局的角度看此环节是否有遗漏或者不合理的地方。
模块设计分为两种：一种是站在系统角度将模块进行划分；一种是站在业务角度去划分模块。
其中我个人认为都有利弊，站在系统角度会更加清晰，开发人员理解起来也比较方便，但是使用者可能不是很习惯。业务角度去划分会便于使用者去操作系统，很容易就能看出下一步我该干什么，在哪干，但是和开发解释起来会比较麻烦，而且相对复杂。
比如同样是合同，一个公司可能有采购合同、施工合同、销售合同还有劳动合同，系统角度的话可以把合同单独建立一个模块，所有人只要做合同就来这个模块；但是业务角度来设计的话就是采购合同归属于采购系统下的模块，销售合同归属于销售系统下的模块，这样使用者操作起来是不是更方便。
当然你们从我的话语中可以感觉得到我更偏向第二种，但是要注意数据统一管理的问题，如果让公司老板看的话，他可能会从全局去看，更像是系统角度。
第四步 设计原型
设计原型的工具推荐Axure，我不是给Axure打广告，但是我认为这个确实比墨刀什么的强太多，Axure就好比PS，墨刀之类就好比美图秀秀，虽然都可以处理图片，但是自定义程度是不一样的。
设计原型时你只要按照脑图的模块去建目录按照用户故事地图去写功能和逻辑就好了，这里就不过多介绍了，还需要注意的就是你们公司的产品规范，一个好的产品一定是有一套好的产品规范去约束，所以怎样建立产品规范也是重中之重。
最后是这样的：
本文作者 @墨紫衣
版权声明
本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！
