以终为始：如何一步步制定产品方案思维导图

免去过于细化的思考过程，我们直接拿出对应的可选方案。

从上图列出的3种方案中可以看到，每种方案都各有其优缺点，并不存在完美的临时方案。在这个时侯，我们就会产生困惑，到底该如何选择？

说了这么一大堆，中心思想终于该闪亮登场了。解决这个问题的方法就是：以终为始。

为了应对业务需求的紧急性而提出的临时方案，应该结合后续要实现的正式方案一起考虑。最好的结果是：临时方案是正式方案的一部分，完成了正式方案的10%的工作。这10%是个虚值，指的是少量的关键性工作。

还有一种情况，就是临时方案无法做到与正式方案统一，可能是完全不同的两种做法。在这种情况下，那就要求临时方案的工作量最小，尽量避免系统开发工作，而且后期的转换成本较低，不要因为临时方案产生了大量的垃圾数据且而以清理。因为这是真正的临时方案，过期作废。

因此，我们先放下手中的问题，继续向前思考。

对于正式方案，我们很直观地能想出来，即在订单系统的用户体系中接纳经纪人这样的人员角色，让经纪人可以像公司业务人员那样在单多多APP上实现系统登录且能实现业务操作。同时财务系统及薪酬结算系统完成相应的需求对接。貌似并不复杂。

但是要注意，这个时候我们需要问自己一个问题，这个方案合适吗？有没有更好的方案？因为作为正式方案，是需要持续使用的，一旦没有考虑清楚而轻易地对系统做出不合理的改造时，后续的系统迭代将很难进行。

我们首先要确定一个问题：系统边界。即哪些事在这个系统上是不应该做的？

细细思考后，我们就能得出这样的观点，订单系统是服务于所有业务人员的业务操作，是简单而稳定的。而经纪人与邀请人这种关系的特定需求，并不具有普遍性的，甚至可以与公司的业务人员相区隔。如果经纪人需求逻辑在订单系统中实现，那便是对基础系统的侵入。让一个承载基础服务的业务系统去承担特殊业务职责，这显然是不合适的。

基于这样的思考，我们可以很快地得出新的方案：为经纪人单独开发一个APP，比如叫“快经纪”，同时让此APP后台建立以经纪人为核心的账户体系。而邀请人则作为其一属性关系，且通过订单系统接口提交申请时，以其关联的邀请人作为客户经理参数进行提交。而最终的薪酬计算，可以在经纪人系统内进行，也可以纳入统一的薪酬系统中进行。

这种方案下，订单系统不用做任何改造。而经纪人业务需求则锁定在以快经纪APP为核心的系统中进行迭代。这样做使得各个系统的责任边界则非常清晰，更利于后续各自的产品迭代。

显然这种方案是更为合适的。用来作为正式方案基本上确定是可行的。那现在我们再回过头来看之前制定的临时方案。从前后方案对比可知，3种临时方案皆无法与正式方案实现统一，实现路径并不同向。因此可知其为真正的临时方案，即不可复用。

这种情况下，很显然，我们需要考虑的就是最简单的方案，最低成本的系统实现。从这个角度看，显然，方案3的客户经理模式是最为合适的。因为系统无任何改造，账号创建过程也简单，后续进行数据清理也更为方便。

至此，我们这个话题讨论的整个过程便结束了。现在，我们来总结一下。

以上便是我对制定产品方案思路和总结，希望对大家有帮助。