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

　　最近，我们组织了一次MVP项目实施。项目还在进行中，但我希望尽快跟大家分享一下相关情况。
　　一。
　　先描述一下项目背景。
　　我们是做汽配物流业务的，现在业务的大体流程是：汽配商将要配送的货物送到我们门店，我们的前台负责进行录单，将一个发车班次内多个汽配商的货需要配送到同一家汽修厂的需求合并为一个订单，然后我们的配送员根据订单信息进行逐个配送。
　　现在的主要问题是，因为要录单，我们需要安排至少3个录单员来负责，再加上我们目前需要进行货款垫付，现金收款，所以还有付银员和收银员。这样的结果是，我们门店产生了大量的外围服务人员，导致我们这项目业务的人力成本过高。
　　所以很明显，我们需要减人。
　　二。
　　我们调研过同行竞争对手，他们做了至少10年之久。他们一般是都是只配送部分区域，占据少量几条线路进行竞争。做为个体户，他们的业务流程很简单：汽配商将货物送到门店，1个前台收单（据），配送员到点后取单配送。没有录单，也没有系统。人员角色也只有1个前台和N个配送员。非常简单。
　　因此，我们提出一个假设，我们是否也可以让配送员见单就送？这个“见单就送”并不是说不要录单和系统了，是指能根据汽配商给的货品清单信息就能送达客户。
　　这里说要一下背景。虽说是配送，但跟其它物流和快递不一样的是，我们配送是没有客户地址的。汽配商送过来的货物清单上只有客户名称和电话号码，有的甚至连电话都没有。
　　我们一直以来的做法是，自己在系统中建立汽修厂的客户信息，如名称，电话，地址，位置定位等。在我们录单时，会将货物清单上的收货单位名称与我们系统中的汽修厂对应起来，这样配送员送货时其实拿到的是经过我们录单员“转换”过的客户信息进行配送，大大方便了配送员。看，我们毕竟是有着互联网基因的公司嘛
　　但现在的问题是，录单这个流程让我们产生了不少人力成本，而且产生了新的问题，比如有些收货单位只有名称，没有电话。而且在我们系统中是找不到对应数据的。这样的情况对于我们现有的流程是走不通的，然后录单员就要求汽配商确认好信息后再过来。这样汽配商对我们产生了极大的不满。因为别家都能收能送，但唯独我们不行。另外，送货高峰期集中录单也造成了排长队现象导致工作效率低下。
　　三。
　　面对这些问题，我们讨论出了新的运作思路。
　　录单由汽配商自助完成。类似顺丰的微信扫码填单。
　　录单时只是简单的记录信息，不再进行货单合并。即使是送到同一家汽修厂的多单货物，也同样单独视作为多单。
　　配送员根据原始货单进行送货，如果不知道地址的，自行通过电话联系汽配商或汽修厂进行确认。
　　如果上面的设想可行，那就解决了录单人力，排队问题，同时也解决客户信息不全无法送货的问题。
　　但新的问题来了：汽配商是否配合？毕竟竞争对手没有这样的要求。另外我们的配送员是否能够达成我们的要求？第一个问题，我们可以考虑上门注册这样的方式与汽配商进行沟通，告诉他们可以解决排队的问题。第二个问题，其实问题不大，内部人员，只要提出强制要求，肯定是可以推行的，主要考虑是否会有新的未能考虑的不好解决的问题出现。待正式推行时，我们需要提前做好准备。
　　老板觉得这个思路可行，开始干吧！然后提出了此新模式正式切换上线的时间点。
　　但这完全是设想，而且这么重大的调整，如果没有事先的验证就贸然开发上线，则可能会带来的不可预知的重大风险。这种后果是我们断然不能接受的。
　　于是，我们决定在正式上线前，做一个测试验证版，以MVP的方式实施。尽可能地降低业务风险。
　　四。
　　洋洋晒晒铺垫了这么一大段，终于进入正题。
　　要保证真正做好这个项目，需要我们对项目的整个环节进行层层把控。作为产品经理，首先我们得从产品层面进行把控。所以接下来就是本文的重点。
　　作为前提，我们要明确一个问题：我们是否真的需要通过产品开发的方式来验证我们的设想？
　　MVP项目的产出，并非一定是一个软件产品，它可以是一个不影响验证问题的任何东西。比如一张调查问卷，一个概念视频，一个公众号等等。如果以上这些可能已经能够满足这个要求，那我们为什么要去做产品开发？因此，在做产品开发之前要认真问问自己这个问题。
　　对于我们这个案例，则必须需要进行产品开发。因为所有的假设验证都基于线下业务运行在产品之上所产生。
　　当我们必须通过产品开发的方式来验证问题时，那我们就得切实做好如下几点：
　　1、与目标无关的需求点，如能以非产品方式解决，则可去除，极力缩小需求范围
　　我们的线下配送业务相对复杂，除了核心的业务流程之外，必然还存着很多相关的分支流程需要支撑。比如退货。而退货又分为两种，一是客户收货时当场要求退货，二是结单后发起退货。对于后者，因为这是跟我们核心业务流程不相关，所以是可以去除的，让线下团队用产品之外的方式先行解决。但对于前者，因为跟我们的主流程是一体的，必须要处理后才能完成整个配送环节，因此，我们还是需要进行支持。
　　还有就是汽配商付运费的情况。我们目前在当地的主流模式是汽修厂付运费，而我们的产品流程也是配合着这种方式进行设计的，因此让汽修厂在收货后进行货款和运费的合计支付是更为简单方便的。对于少数的汽配商自己付运费的情况，我们考虑是让线下运营团队自己处理，如收取汽配商付的运费后，给到配送员，汽修厂照常支付整个订单，然后配送员再返还汽配商预付的运费到汽修厂。这个环节虽然在线下执行时有一定的麻烦，但对于简化我们产品需求的复杂度是非常有利的。
　　2、允许“漏洞百出”的需求设计，只要关键业务流程能跑通即可
　　在这种项目阶段，我们不需要过多地考虑产品的完善性和严密性。我们在通常的产品设计中，会考虑在产品层面进行一定的逻辑条件约束，避免产生bug，这是应该做的。但在做MVP项目时，这个则不是必要的。
　　严密的逻辑条件约束，在最大的程度上避免了产品逻辑问题。但带来的则是复杂的需求分析和成倍开发工作量。这对于我们希望快速进行产品验证的目标是背离的。因此，我们需要在这个方面把握一个度。
　　对于简单的，基本的条件约束是必要的，不然可能造成产品流程的混乱。比如，货单被扫码装车后，状态变更为“已装车”，此时是不能再被其他人再次扫码装车的，否则两个人同时装了一单货，这完全是不合理的。这种情况在线下运作时是有可能发生的。而像其它的，如果发生的可能性不大，而且考虑进去入会变得相当复杂的情况时，则可以忽略它。要真是发生了怎么办？到时再说嘛！
　　3、实施时，挑选实施条件较好的，破除与核心目标无关的影响因素，创造条件保障目标验证的集中有效性
　　在进行产品设计之前，就要考虑到后面的实施环节中的问题。既然是验证，那就可以在小范围中进行，因此，我们准备挑选其中两条线路进行实施。
　　但挑选线路也是有讲究的。我们有些线路的单量比较大，但有些线路的单量还比较小，所以我们会优先选单量较小的进行。因为既然在验证过程中出现问题，也不至于影响太大。还有些线路因为配送线路过长，范围过大，所以进行了中转设置，而这就涉及到了中转流程。这样的线路运作流程就会复杂一些，因此我们会避开这种线路。没有了中转流程，我们的产品需求和开发都更加简单。
　　最后，我们选择了这样的两条线路进行测试：A线路单量少，首次测试时启用。B线路单量稍多些，作为后续平稳后进行加强测试时使用。两条线路均无中转设置，且两条线路的负责人均为老司机，与我们产品团队的接触较多，关系融洽。这样，完美的测试环境便完成搭建。
　　五。
　　作为产品经理，我们在日常的产品工作中，通常考虑的是如何把握用户需求进行产品设计，如何提高用户体验。但如果你身处创业公司或创业项目中，特别是前期，产品的工作核心可能完全不是这样。
　　在业务模式和商业模式确定下来之前，用户体验型的产品迭代都是毫无意义和不必要的。作为创业项目的产品负责人，你可能需要面对频繁调整的产品方向甚至是业务模式。不管如何，这都会对你的工作带来极大的不确定性甚至是麻烦。
　　身处创业公司，产品负责人应该最大化地理解老板的焦虑。产品方向和业务模式的调整是老板对项目认知不断迭代的一种表现。而我们要做的，便是义无反顾地顺应这种工作常态，并用合适的方式策略去支持这种变化。
　　这便是MVP，最小化可用产品。
　　MVP不是一个产品，它可以是一种任何可以验证疑问的方式方法。MVP的目的也并非是快速地开发产品，而是快速的建立起一套有效的业务运作模式或者是商业模式。
　　作为创业公司的产品负责人，首先要抛弃产品思维，不要处处以产品开发的角度考虑问题，而是要发散思维，以更经济更快捷有效的方式去获取产品实施前所要确定的答案。
　　在创业公司或者创业项目里，你应该掌握MVP，并频繁使用。老板们并不会告诉你某个项目需要以MVP的方式来做，只会告诉你什么时间点，他要什么。是否要考虑采用MVP项目实施策略，作为产品经理，你是第一责任人。
　　我们的老板对于这种方向性的调整，时间要求都比较急，都希望能尽快地知道思路是否可行，如果可行，希望能尽快全面转换，时间就是金钱。而对于属于重大业务调整的项目，本身就蕴含着巨大的风险，再加上时间紧追，最终就只会让这个项目充满了挑战和难度。
　　对于这样的项目状况，我们应对的策略便是采用MVP方式进行项目实施，以验证的思路进行展开。但时间紧，业务复杂都将极大地拉高了MVP项目实施的难度和成功概率，因此需要层层把控。