无法得知完整的需求

B端产品的一个特点：对接的都是客户的具体需求，也就是需求过来的时候已经是很明确的了，工作内容集中在如何实现。在这基础上就伴随着另一个特点，就是本文即将提到的“无法得知完整的需求”

这个无法得知的原因有很多，比如说能够完整描述需求这件事对于客户来说是非常困难的；如果是从0-1孵化一个新项目，想通过需求调研来全部获取到完整信息也很困难。与此对应的我们要学会的另一个技能就是随着需求的深入要不断的对功能进行迭代，即渐进式迭代。

一个笔者亲身经历过的案例

需求背景

角色：作业人员、管理人员、仓库、工具

角色描述：作业人员需要去仓库借还工具，管理人员可以进出仓库的权限进行管理。

核心痛点：作业人员作业时需要想管理人员取得门禁权限，这个过程非常耗时。

经历

第一阶段：用户期望通过人脸识别的方案进行门禁管理，这就是客户提出的一个需求，听上去是不是特别简单，我们只需要接入一台人脸识别设备然后再将人脸信息录入就解决了。

第二阶段：在使用过程中出现了一个问题，作业人员在路过门口的时候门禁会打开，这是甲方不希望看到的。这个时候需要对识别权限进行控制，按照甲方的需求只有在需要作业的时候给到作业人员权限，即作业人员申请——管理人员审批——获得门禁权限这样一个流程，这样误操作问题得到了解决。

第三阶段：如果审批的时间过长，核心痛点又出现了。从第一阶段可以看出甲方并不是不可以直接给到作业人员权限，于是新的方案，如果长时间未得到审批，作业人员可以自行获取门禁权限（类似于自行审批的一个操作）

第四阶段：随着时间的推移，自行申请、自行审批作业人员觉得比较麻烦，期望能够直接开门。即跳过申请、审批、人脸识别这几步。这和我们最初给甲方提供的方案吻合，但被甲方以不够智能拒绝了。

中间还掺杂了一些人为因素，比如审批后作业人员的权限是持续到作业结束归还工具后的，作业人员如果不愿意结束任务则又会发生阶段二的问题，如果只在作业开始和作业结束时给门禁权限，则会增加审批流程的复杂度。

总结，如果将这些信息同时给到一个有着2年经验项目经验的产品经理，相信他能设计一个很优秀的产品。但这些信息是在一年中断断续续获取的，想要一开始就设计好可以说是难度非常大。这里就和笔者的另一个观点不谋而合，即领域专家的重要性。

当然整个过程远比我描述的要复杂，这也仅仅是一个门禁功能的描述，别的业务有过之而无不及，这就是B端项目的一个特点。