设计产品方案，是一个非常有趣的过程，要完美地设计出某个东西，你就必须先熟悉它，真正了解它，这需要投入很大时间和精力，需要反复咀嚼回味，而不只是囫囵吞枣，一旦缺少投入的体验，设计的过程便会少很多乐趣。
01
国际物流中，卡车转运是很常见的运输模式，很多电商公司通常会把买家的碎片化订单，通过海运/空运的方式，把货物整合运输到目的国港口，完成清关缴税后，再通过卡车或尾程快递的，发往目的地。
这样的过程链路很长，涉及的角色众多，派送给消费者的路上也有很多不确定性，所以能做到所有链路都把控的公司很少，大多都会选择与承运商合作，各自完成自己擅长的事情。如卡车公司，海外仓，尾程快递/邮局（如皇家邮政）等，组合一起来完成派送，这样最高效。
（英国机场）
如上述英国四个机场中，我们的仓库在希思罗机场（Heathrow）附近（伦敦左侧），因为航司不同，货物散落在不同的港口，为了把货都提到仓库，就需要统计不同港口的货量，预估需要的卡车数量和车型，并根据预计到岗时间和卡车路途时间，提前预约卡车，分配卡车让他们按时间提货，并在这个过程中做到成本、时效最优。
简单来说，就是既要便宜还要快，比如货物到了Heathrow港口后，能上午拉回来就不会拖到晚上，能一趟车拉回来，就不会定两台车。毕竟英国一辆普通小卡车跑一趟的费用高达 200 英镑。而产品经理的职责之一，就是搭建系统，帮助业务角色高效完成这些动作，并且协同仓库和卡车供应商，做好数据交互以及费用结算。
以往做类似的方案时，第一件事情是找到关键人员调研：找清关经理和调度人员了解业务流程，梳理他们的卡点，明确方案目的等。但近期在做这个方案的时候，即便做好了上述三个环节，方案依然会被业务吐槽：太想当然了~
02
有一次开会展示方案，我说达曼彻斯特（英国北部机场）距离仓库 330 英里，如果明天 16：00要提货，系统可提前创建提货任务，通知业务人员，今天要预订卡车去机场提货。
但业务质疑我说，因为路途堵车或者提货点拥堵的情况，曼彻斯特机场的货，一旦超过 12 点到港，当天就不能够在仓库关门前，把货提回来，得安排后天大清早的卡车，而且，这还是港口不拥堵的情况的保守估计。
我没有去过英国，没有亲身实际的感受当地运输货物的情况，容易把流程都当做是理所应当地发生，所以被吐槽之后的第一感受是，借此机会跟着业务走一遍流程。
于是静下心来，在谷歌地图上把英国港口都标记了下来，看看他们的位置，并在不同时间段，看看仓库到港口之间的卡车耗时（谷歌地图会显示拥堵情况），并根据业务提供的货量用表格统计卡车数量，按照实际操作的步骤分配车辆，线下发邮件预约卡车，并跟进从预约到提货到仓的时间。
(实操一遍)
有了这样的过程，脑海中开始对卡车路径有了点轮廓，而且还收获了很多的乐趣，比如要从不同港口提货到 LHR 仓库，MAN（英国北部机场）和STN（伦敦东北部机场）的时间都是14:00，这样既能大概率提货到仓，还不会产生高额的等待费。
后来方案修改通过后，回家路上突然想到Shopify产品总监的一句话，大致意思是优秀的 PM 面对问题时都会说我知道用户需要这个，而不是等我调研一下先。
但产品经理做出这样判断，往往很难，就像开头说的那句话一样：我们大多数时候都会想着优先解决问题，而不是花时间体验，投入地感受事情本身。且能否花时间感受事情本身，跟能力没有太大关系，而是跟我们工作、创造的环境有关。
因为环境会塑造出共识，会影响人的行为，而背后的塑造过程，更是跟直属团队及共事的人有直接关联。我发现，如果在一个注重体验，注重产品创新的团队氛围中工作，人往往更容易去感知业务/用户现状，共同探讨方案，会自发地收集市场的反馈。因为很多方案的灵感，往往源自于对事情本身的理解和还原，是对事情原貌的窥探，而不是过多的设计。
而这样摸索的过程，也是产品经理设计解决方案的乐趣之一。
本文来源@Leam ，未经许可，禁止转载。
| 
发表于 2024-9-7 09:36:15
