作为产品经理，在我们日常工作中，经常会接收到各种各样的需求。面对这些需求，我们当然首先要弄清楚这需求背后的动因，以便挖出真正的“需求”，随后才是思考如何解决这个需求。这里我们不讨论需求分析的问题，而是重点关注如何制定产品方案。只有产品方案定下了，才能推导出交付开发的产品需求。

　　当然，对于一些简单的小需求，是谈不上什么产品方案的，因为很清楚地知道做什么改动就可以实现。而我们这里要讨论是比较大的需求，所谓大，就是工作量较大，可能是一个全新的需求，而且还需要跨系统协同。在这种情况下，我们对于需求的实现，则需要考虑产品方案的问题。

　　为什么要考虑产品方案?因为需求是持续产生的，而产品也就需要进行持续迭代。在这种情况下，如果一开始的产品方案没有经过严密的思考过程，而是过于随意的话，很可能到了产品迭代后期就无法继续下去了。因为系统变得非常臃肿和混乱，这也是为什么很多系统在经过一两年的发展就已经变得无法维护了，而系统重构就是在这样的背景下产生的。

　　也许大家会问，系统无法维护，这不应该是技术团队的责任吗?其实不然， 产品需求是源头，具体的产品需求已经在很大程度上决定了技术实现方案。如果产品方案和需求没有把控好，技术实现的混乱是不可你避免的。

　　废话不多说，我们直接拿案例说事。

　　交代一下背景：我们做的是车抵贷业务，由门店业务员对接借款者代为申请借款。现在有一新需求，业务员可能有自己的朋友也有这块的资源，可以介绍客户过来借款。而这种需求并不少，因此公司决定将其纳入正式业务范畴。为了提高业务效率，提出了让这些介绍人可以直接在手机APP上代为提交借款申请，申请成功后系统可以自动计算及结算提成的需求。

　　我们业务员使用的APP叫“单多多”，通常业务员接待借款客户时，使用这个APP进行申请信息录入工作。介绍人现在我们称之为“经纪人”，经纪人也需要在单多多上能录入自己客户的申请资料。业务部门希望能快速上线开展业务，经我们产品技术部门简单评估后提出以临时方案先行支持业务开展，正式方案的产研工作同步展开的建议。

　　那么对于临时方案，具体又该怎么做呢?

　　经过分析，我们得出此需求的核心要点有如下3点：

　　经纪人需要登录APP完成借款申请的工作;

　　在系统或订单上要体现出业务员和经纪间的邀请关系;

　　根据订单和邀请关系计算出经纪人和业务员在此业务上的提成。

　　进一步分析得出：

　　登录APP则需要建立与之相应的订单系统账号;

　　账号在订单系统中是存在组织机构层级关系的，需要一并设计和构建，而这点恰好可以用于记录邀请关系，似乎是可以利用的;

　　对于提成结算，因为是全新的逻辑，所以不管如何做都需要定制化开发。

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

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

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

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

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

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

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

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

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

　　我们能确定的是：

　　订单系统是基础业务系统;

　　经纪人与公司业务人员是两个体系;

　　经纪人这种属性对于系统业务流转不具有普遍性。

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

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

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

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

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

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

　　制定产品方案的整个过程，我们可以分为如下几个步骤进行：

　　罗列出所有可选的快速实现( 临时)方案。

　　分析实现成本、优缺点，并记录。

　　思考后续启动实现的正式方案。

　　还有没有更好的方案?(分析系统定位及职责，所添加的逻辑是否具有普适性?尽量避免特殊业务逻辑对基础业务系统的侵入。最终确定最佳的正式实现方案)

　　反推并敲定临时方案。(考虑前后方案的一致性及延续性，尽量少做没有价值的临时工作)

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