需求

产品第一关，需求。
当客户提出想要OA要BPM的时候，必须要多问他们为什么。为什么需要呢，是不是非得要这样的系统呢？

通常客户很难清楚自己需要什么（否则早就自己做了）。当他们提出的需求越具体时，甚至到达功能界面，那要更谨慎对待。一旦认知有偏差，那么这个坑会就越来越大。
同样是企业说要OA或者BPM。一些企业只是需要系统帮助审批业务表单；一些企业内部门各有各的业务系统，当出现跨部门业务时，才想到需要集成能力串接不同业务系统；一些企业是因为业务系统多了，数据各自为政，需要拉通不同系统的数据。用OA或BPM的确能解决这些需求，但难免有些大材小用，不是那么“对口”。

上面的需求，单独安排开发做可能十几人天基本能搞成。若是做OA或BPM，没半年几个月搞不下来，即便产品化程度很高，只需简单实施，也要一个月左右。

因此，了解需求不是要了解客户具体要什么产品什么功能，而是了解其业务场景和诉求痛点。毕竟软件不过是个工具，无论什么工具，只要能帮助业务快速达成都是好工具，比如抡起铁铲打钉子也是可以的。所以更需要关心客户背后的故事是什么，才能从中提炼出痛点对症下药。

流程

怎么了解客户背后的故事？用业务流程法。业务流程，就是将业务从流程的维度描述出来。

跟客户聊需求，怎么让他们按我们所想讲出他们的需求呢？记住，千万别问客户想要什么功能，应该问他们为什么想要用流程系统，想做什么事情，这些事是如何发生的，顺便了解他们期望如何发生。引导其通过先后次序来描述“事情经过”。这样的“事情”以及“事情经过”，才是“业务需求”和“业务流程”。

做不同产品可能在需求环节的关注点不同，但流程这一点是相同的。在C端表现为关注用户操作流程（使用路径），B端则关注业务流程（有些也会关注信息流、数据流、资金流）。B端产品需要将业务流程毫无遗漏地描述出来，才能保证业务上没有缺失，否则当其中一环中断，必然带来整个业务的停滞。

需求与流程

B端业务需求大多都很复杂，以上引导描述业务流程的思路，实际上也是对需求的分解方法。通过业务流程分解得到业务活动，能从中获得很多业务需求；而在了解业务需求同时，又可细化某个业务活动的业务流程。

这里列一种思路方法供参考：整体到局部。
每个业务都包含着一条流程，流程每一步又代表着一个业务。那么找出“尽可能最大”的业务，就得到这个主干流程，在这主干流程上又能得到子业务。就像树干长出树杈，层层递进，就能梳理出业务关系。
每个业务都有很多维度的信息，例如业务之间关系和次序、前置条件、输入的信息、输出的信息、业务干系人、业务目标、业务期望等等，这就得到了每一个业务的场景和诉求了。
通过从整体到局部，一点点追踪到各个业务，了解业务的场景和诉求。也就采集到需求，同时将这个业务的内容和流程都梳理出来了。

你还有什么思路吗？