如何在产品层面把控 MVP 项目实施

2017-11-14 10:09:00

最近，我们组织了一次MVP项目实施。项目还在进行中，但我希望尽快跟大家分享一下相关情况。

一.

先描述一下项目背景。

我们是做汽配物流业务的，现在业务的大体流程是：汽配商将要配送的货物送到我们门店，我们的前台负责进行录单，将一个发车班次内多个汽配商的货需要配送到同一家汽修厂的需求合并为一个订单，然后我们的配送员根据订单信息进行逐个配送。

现在的主要问题是，因为要录单，我们需要安排至少3个录单员来负责，再加上我们目前需要进行货款垫付，现金收款，所以还有付银员和收银员。这样的结果是，我们门店产生了大量的外围服务人员，导致我们这项目业务的人力成本过高。

所以很明显，我们需要减人。

二.

我们调研过同行竞争对手，他们做了至少10年之久。他们一般是都是只配送部分区域，占据少量几条线路进行竞争。做为个体户，他们的业务流程很简单：汽配商将货物送到门店，1个前台收单（据），配送员到点后取单配送。没有录单，也没有系统。人员角色也只有1个前台和N个配送员。非常简单。

因此，我们提出一个假设，我们是否也可以让配送员见单就送？这个“见单就送”并不是说不要录单和系统了，是指能根据汽配商给的货品清单信息就能送达客户。

这里说要一下背景。虽说是配送，但跟其它物流和快递不一样的是，我们配送是没有客户地址的。汽配商送过来的货物清单上只有客户名称和电话号码，有的甚至连电话都没有。

我们一直以来的做法是，自己在系统中建立汽修厂的客户信息，如名称，电话，地址，位置定位等。在我们录单时，会将货物清单上的收货单位名称与我们系统中的汽修厂对应起来，这样配送员送货时其实拿到的是经过我们录单员“转换”过的客户信息进行配送，大大方便了配送员。看，我们毕竟是有着互联网基因的公司嘛……

但现在的问题是，录单这个流程让我们产生了不少人力成本，而且产生了新的问题，比如有些收货单位只有名称，没有电话。而且在我们系统中是找不到对应数据的。这样的情况对于我们现有的流程是走不通的，然后录单员就要求汽配商确认好信息后再过来。这样汽配商对我们产生了极大的不满。因为别家都能收能送，但唯独我们不行。另外，送货高峰期集中录单也造成了排长队现象导致工作效率低下。

三 .

面对这些问题，我们讨论出了新的运作思路。

录单由汽配商自助完成。类似顺丰的微信扫码填单。
录单时只是简单的记录信息，不再进行货单合并。即使是送到同一家汽修厂的多单货物，也同样单独视作为多单。
配送员根据原始货单进行送货，如果不知道地址的，自行通过电话联系汽配商或汽修厂进行确认。

如果上面的设想可行，那就解决了录单人力，排队问题，同时也解决客户信息不全无法送货的问题。

但新的问题来了：汽配商是否配合？毕竟竞争对手没有这样的要求。另外我们的配送员是否能够达成我们的要求？第一个问题，我们可以考虑上门注册这样的方式与汽配商进行沟通，告诉他们可以解决排队的问题。第二个问题，其实问题不大，内部人员，只要提出强制要求，肯定是可以推行的，主要考虑是否会有新的未能考虑的不好解决的问题出现。待正式推行时，我们需要提前做好准备。

老板觉得这个思路可行，开始干吧！然后提出了此新模式正式切换上线的时间点。

但这完全是设想，而且这么重大的调整，如果没有事先的验证就贸然开发上线，则可能会带来的不可预知的重大风险。这种后果是我们断然不能接受的。

于是，我们决定在正式上线前，做一个测试验证版，以MVP的方式实施。尽可能地降低业务风险。

四.

洋洋晒晒铺垫了这么一大段，终于进入正题。

要保证真正做好这个项目，需要我们对项目的整个环节进行层层把控。作为产品经理，首先我们得从产品层面进行把控。所以接下来就是本文的重点。

作为前提，我们要明确一个问题：我们是否真的需要通过产品开发的方式来验证我们的设想？

MVP项目的产出，并非一定是一个软件产品，它可以是一个不影响验证问题的任何东西。比如一张调查问卷，一个概念视频，一个公众号等等。如果以上这些可能已经能够满足这个要求，那我们为什么要去做产品开发？因此，在做产品开发之前要认真问问自己这个问题。

对于我们这个案例，则必须需要进行产品开发。因为所有的假设验证都基于线下业务运行在产品之上所产生。

当我们必须通过产品开发的方式来验证问题时，那我们就得切实做好如下几点：

1、与目标无关的需求点，如能以非产品方式解决，则可去除，极力缩小需求范围

我们的线下配送业务相对复杂，除了核心的业务流程之外，必然还存着很多相关的分支流程需要支撑。比如退货。而退货又分为两种，一是客户收货时当场要求退货，二是结单后发起退货。对于后者，因为这是跟我们核心业务流程不相关，所以是可以去除的，让线下团队用产品之外的方式先行解决。但对于前者，因为跟我们的主流程是一体的，必须要处理后才能完成整个配送环节，因此，我们还是需要进行支持。

还有就是汽配商付运费的情况。我们目前在当地的主流模式是汽修厂付运费，而我们的产品流程也是配合着这种方式进行设计的，因此让汽修厂在收货后进行货款和运费的合计支付是更为简单方便的。对于少数的汽配商自己付运费的情况，我们考虑是让线下运营团队自己处理，如收取汽配商付的运费后，给到配送员，汽修厂照常支付整个订单，然后配送员再返还汽配商预付的运费到汽修厂。这个环节虽然在线下执行时有一定的麻烦，但对于简化我们产品需求的复杂度是非常有利的。

2、允许“漏洞百出”的需求设计，只要关键业务流程能跑通即可

在这种项目阶段，我们不需要过多地考虑产品的完善性和严密性。我们在通常的产品设计中，会考虑在产品层面进行一定的逻辑条件约束，避免产生bug，这是应该做的。但在做MVP项目时，这个则不是必要的。

严密的逻辑条件约束，在最大的程度上避免了产品逻辑问题。但带来的则是复杂的需求分析和成倍开发工作量。这对于我们希望快速进行产品验证的目标是背离的。因此，我们需要在这个方面把握一个度。

对于简单的，基本的条件约束是必要的，不然可能造成产品流程的混乱。比如，货单被扫码装车后，状态变更为“已装车”，此时是不能再被其他人再次扫码装车的，否则两个人同时装了一单货，这完全是不合理的。这种情况在线下运作时是有可能发生的。而像其它的，如果发生的可能性不大，而且考虑进去入会变得相当复杂的情况时，则可以忽略它。要真是发生了怎么办？到时再说嘛！

3、实施时，挑选实施条件较好的，破除与核心目标无关的影响因素，创造条件保障目标验证的集中有效性

在进行产品设计之前，就要考虑到后面的实施环节中的问题。既然是验证，那就可以在小范围中进行，因此，我们准备挑选其中两条线路进行实施。

但挑选线路也是有讲究的。我们有些线路的单量比较大，但有些线路的单量还比较小，所以我们会优先选单量较小的进行。因为既然在验证过程中出现问题，也不至于影响太大。还有些线路因为配送线路过长，范围过大，所以进行了中转设置，而这就涉及到了中转流程。这样的线路运作流程就会复杂一些，因此我们会避开这种线路。没有了中转流程，我们的产品需求和开发都更加简单。

最后，我们选择了这样的两条线路进行测试：A线路单量少，首次测试时启用。B线路单量稍多些，作为后续平稳后进行加强测试时使用。两条线路均无中转设置，且两条线路的负责人均为老司机，与我们产品团队的接触较多，关系融洽。这样，完美的测试环境便完成搭建。