以终为始：如何一步步制定产品方案

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

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

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

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

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

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

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

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

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

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

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

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

进一步分析得出：

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

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

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

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

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

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