需求是永恒存在（需求的尽头是什么）

编辑导读：需求需求，戴在每个产品经理头上的紧箍咒。当我们处理完一个又一个的需求后，不禁会问，需求的尽头是什么？对于这个问题，作者给出了自己的解答，一起来看看吧。

产品经理的工作和需求密不可分 ，那么你有没有思考过一个问题：需求的尽头是什么？

不妨来跟我一起找答案吧！

假设你是R企销售平台的产品经理，A是R企的产品，并在你负责的平台上销售。现在A的产品经理找到你，对你提出了一个需求：用户1通过销售平台购买了产品A，不论用户1是否离职，都不影响订单的升级续费等操作，也不影响A的使用。

一、判断是否是伪需求

首先，我们需要了解产品A的定位和销售模式。

A是一款项目协作类的软件，在销售平台上的销售方式分为两种：个人和企业。

• 个人订单，只有购买人有查看&操作订单权限。
• 企业订单，购买人以及同企业的成员都有操作按钮，也能够正常使用。

由此我们可以下一个结论：这是一个伪需求！

但你真的觉得这合理吗？我们依然从两种销售方案的角度分析。

• 我们分析A这个软件本身，这是一款项目协作类软件，它的使用场景是多人协作办公。因此，哪怕是个人购买，实际上却是公司或项目使用，那么有可能出现人员离职的情况。所以针对个人订单，离职转交是真需求。
• 有操作按钮一定代表能正常使用吗？正常使用的定义是什么？前面的背景说到，销售平台与A是两个系统，涉及到两个系统，那么底层的数据是否互通就显得尤为重要。对于两个系统，正常使用是在销售平台上操作后，数据也应传到A上。在实际操作后发现，企业订单中，只有购买人的操作是有效的！即非购买人操作后的订单信息未传输到A的数据库中。

由此，我们抽丝剥茧发现这是一个真需求！

二、查看竞品玩法

确定需求后，我们需要查看头部的企业中类似产品的销售模式，拓宽思路。

1. 阿里云-云效

在阿里云平台购买云效时，利用企业id取代用户id来确认订单信息。因此，如果购买云效的用户离职，后续企业人员仍可使用企业id进行升级、续费，从根源上避免了离职人转交的需求。

2. 华为云-软件开发平台

软件开发平台并未强制限制购买主体为企业，是利用用户id来确认订单信息。

查看购买记录与软件开发平台页面，并未发现订单转交的按钮。提交工单询问后得知，若以个人为主体购买软件开发平台，离职后会导致订单无法升级续费，企业将无法使用软件开发平台。只有将个人账号做企业认证，或直接以企业方式购买，无论是否离职都不会对订单或使用造成影响。显然，华为云是通过角色来控制权限，并未做离职人转交的逻辑。

三、梳理解决方案

我们了解了竞品玩法后，提出以下三种解决方案。

1. 利用企业id确认订单信息

在看完竞品-阿里云的销售模式后，你是否觉得醍醐灌顶？我们从起点开始就错了：既然A是一款项目协作的软件，对于此类软件，支持个人购买明显不合理。

有了质疑，我们再结合个人购买和企业购买的场景，仔细分析区别。

• S企的采购部购买了产品，但是企业购买需要上传公司的营业执照在销售平台认证，财务部不愿提供信息或很麻烦。
• 个人工作室买了产品A想二开，无法提供营业执照等信息。
• 这个平台和产品已经运行一段时间了，之前存在一些真实的订单，我们不方便更改软件的购买方式。

结合上述场景，若我们把购买方式贸然限制为企业购买，会失去（1）（2）类客户，并且导致（3）类用户出问题。华为并未限制个人购买软件开发平台应该也是出于这三点的考量。

oh，此路不通！

2. 修复bug，使企业内非购买人的订单操作生效

这个方案和软件开发平台的销售模式相似，即个人订单个人使用，企业订单管理员均可操作。但若A仍保留个人购买的模式，那么个人订单中，离职后仍可正常使用或升级续费的需求无法被满足。

此方案的优势在于改动少，但是不能满足个人订单的场景需求。因此也不会采纳。

3. 新增个人和企业订单的离职人转交功能

优点：更贴合用户习惯，符合认知

缺点：销售平台中不仅销售这一个产品，需要A做特殊的逻辑，销售平台的开发工作量重

优点：销售平台无需做特殊逻辑，仅提供修改接口即可

缺点：A的开发工作量重

两种方案都各有利弊，根据实际的项目情况，A较之销售平台可提供更多的技术资源，因此选择方式（2）。

四、冰山露出来的只是一角，潜伏在冰山下的才是一个优秀的产品经理需要看到的

到现在为止，你是否发现了流程的不合理处？

1. 企业订单中，所有成员都有操作权限？

显然不合理，应该限制企业管理员才能以企业方式购买，如非企业管理员的用户只支持个人购买。

但，真的这么简单吗？

结合离职人转交的功能，若企业管理员将订单转交给了企业成员，那么就存在非企业管理员可以再次以企业方式购买产品。因此，我们不仅需要在购买时做角色校验，还需在再次购买和升级续费时校验。

2. 个人订单和企业订单的续费问题

对于A这个产品，我们保留了个人订单和企业订单两种购买方式，这就涉及到一个场景：第一年C以个人方式购买了产品，第二年C以企业方式购买，发现没有升级续费的优惠价，且A的使用有效期没有叠加。为了避免这个问题，我们需要对已购买过A的用户的购买方式做限制，即若C以个人方式购买过产品，后续C也仅支持个人购买。

但，真的这么简单吗？

首先，如何定义已购买的用户？是提交订单后，还是付款后算购买。如果提交订单后就算购买，那么用户发现购买方式选择错误取消订单后，却发现无法修改购买方式；如果付款后算购买，那么用户先提交一个个人订单不付款，再提交一个企业订单后，接着支付两个订单。那么就会存在一个用户既有个人订单又有企业订单，限制无效。好像走进了一个死胡同。不妨跳出这两个方案来看，加一些别的限制组成方案C：付款后就算购买，但是用户若有未付款订单，则不允许再提交新的订单。

其次，结合离职人转交的功能，针对同一款产品，可能存在一个用户既有个人订单又有企业订单的情况。比如，用户1以个人方式购买了A，后续用户2将企业订单转交给用户1。因此，再转交前还需加被转交人的校验逻辑。

五、总结启发

需求的尽头是什么？还是需求，不过这个需求是从冰山下挖出来的更深层次的需求。

所以我们思考一个需求，他不应是一个点，而是一条线，更复杂的时候是一个面或多个面。

以销售平台为例，对于用户来说，只是在A上增加了一个转交的按钮，但是销售平台的功能一环扣一环，关联性非常强，需要产品看到更多，以下两种方法可以辅助我们思考。

1. 流程图思考法

当我们在设计离职转交时，可以画一个简单的流程图来帮助我们梳理上游和下游，关键的节点标注所需的数据。

比如，订单结算需要用户信息，那么需要销售平台和A做用户打通或用户绑定，才能支持离职转交操作；订单结算需要个人/企业实名信息，若A未提供，则销售平台需要在每一次提交订单时做实名校验，增加去实名的跳转引导；转交后可能涉及到退款，而退款仅支持原路退回，那么我们需要在用户支付时或转交时添加提示。

2. 权限矩阵思考法

只考虑订单数据流转过程是远远不够的，因为订单还涉及到多个角色，多种状态。

不同角色在订单的不同状态下，可操作的按钮不一致，例如企业成员仅能在订单状态为生效中时使用产品而无法查看订单详情，而企业管理员应从未授权时就能够查看订单详情了。

本文由 @玛卡巴卡 原创发布于人人都是产品经理。未经许可，禁止转载。

题图来自Unsplash，基于CC0协议。

,