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

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

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

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

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

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

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

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

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

  1. 经纪人需要登录APP完成借款申请的工作;
  2. 在系统或订单上要体现出业务员和经纪间的邀请关系;
  3. 根据订单和邀请关系计算出经纪人和业务员在此业务上的提成。

进一步分析得出:

  1. 登录APP则需要建立与之相应的订单系统账号;
  2. 账号在订单系统中是存在组织机构层级关系的,需要一并设计和构建,而这点恰好可以用于记录邀请关系,似乎是可以利用的;
  3. 对于提成结算,因为是全新的逻辑,所以不管如何做都需要定制化开发。

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


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

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

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

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

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

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

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

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

我们能确定的是:

  1. 订单系统是基础业务系统;
  2. 经纪人与公司业务人员是两个体系;
  3. 经纪人这种属性对于系统业务流转不具有普遍性。

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

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

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

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

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

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

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

  1. 罗列出所有可选的快速实现( 临时)方案。
  2. 分析实现成本、优缺点,并记录。
  3. 思考后续启动实现的正式方案。
  4. 还有没有更好的方案?(分析系统定位及职责,所添加的逻辑是否具有普适性?尽量避免特殊业务逻辑对基础业务系统的侵入。最终确定最佳的正式实现方案)
  5. 反推并敲定临时方案。(考虑前后方案的一致性及延续性,尽量少做没有价值的临时工作)

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

作者:星思维

来源:人人都是产品经理

本文链接: http://www.yixieshi.com/121456.html 转载请保留