一个ToB物流交易系统“从0到1”的四个故事

笔者在“A公司”设计了一套支撑定义为“大宗物料”运输业务的B2B交易平台，这个B2B平台有着伟大的规划：

• 出发点：和客户一起解决问题；

• 立场：客户；

• 目的：创造我们的价值。

那么这个物流交易平台“从0到1”发生了哪些故事，笔者将通过几个小故事娓娓道来。

故事一：“邪恶”王后的目标只有白雪公主之定位客户

王后的魔镜告诉了她，谁是世界上最漂亮的女人，现实世界可没有那么厉害的镜子，那么物流行业的用户只有通过物流行业这个大分类，来做精准定位了。

物流行业，如何定位客户？调研行业用户、演算服务用户成本、确认企业自身优势来抓去用户痛点，及企业自身优势能够给出的解决方案。

step1：了解定位客户群的方式

1. 汇集企业现有可用资源，列出企业可能服务的客户群；

2. 深入了解行业客户群的痛点，了解方式：

3. 摸索企业能够给客户群带去的痛点解决办法；

4. 精细演算能够从客户处取得的投资回报数据。

小结：收集资料后的简易适用的归纳用户群的方法，将出现率高的内容->统计求和->按求和数据从高到低排序。

step2：企业能力画像及用户画像分析

笔者的A公司，成立之初，技术团队仅10人，包含：老板、财务、UI、产品、技术经理、Java、iOS、Android、测试、web前端。

从人的角度切入行业，根据收集资料，分析数据，归纳了用户画像及用户的痛点。

企业能力画像：指企业能够提供的基本能力，也是吸引员工为之拼搏的唯一动力。

用户画像：基本属性+兴趣爱好+访问属性+使用竞品+意愿属性，实际为了解你所圈定用户的行为习惯及使用互联网产品的意愿。

小结：用户画像，被企业自身具备的能力所限制，比如：不熟悉冷链/零售，因此不会在冷链用户群体上花太多功夫，过多的研究与测算会耽搁一家企业进入市场的时机。

A公司主要服务用户一开始就已经定好为：代理人、供应商、3PL、无车承运人企业，司机等，收集资料并且分析数据仅为论证服务的方向是否在承受范围。

step3：用户痛点的解决方案

通过用户调研，形成用户画像的同时，归纳出用户想要解决的痛点，以及企业能够提供的解决方案。

小结：确认用户痛点后才能知道企业设计的产品，如何给用户赋能。按照调研归纳出痛点后，一定要给出自己团队能够做出的初步解决办法，才能在产品设计时有针对性的处理方案。

故事二：人人都是鲁班大师之产品设计

了解了用户痛点，做产品设计 ，这个环节最容易硝烟四起，A公司为了快速打入市场，只给了3个月的时间，实现上线推广。

那么，我们一步一步的来，首先要考虑要什么客户端？

step1：确定要通过平台完成的业务流程

经分析研究客户群体的线下业务，平台将提供两种业务模式的流程支撑用户：

1. 无车队合伙人模式：

2. 有车队合伙人模式：

step2：整理业务角色、及其要使用的功能

根据业务角色所需要的功能，结合用户痛点，结合业务分析，考虑通过业务系统PC端、司机端、运营PC端来实现支撑业务。

1. 业务系统PC端：

命名为XXTMS运输管理系统；

服务对象：发货人、承运人、收货人；

服务目的：达成用户对于用户、司机、车辆、组织架构及业务流程的管理，司机的跟踪、报表的管理等。

2. 司机端APP：

服务对象：个体司机和合伙人；

服务目的：达成个体司机承运、合伙人司机接单、分配司机、转账给司机等；

3. 运营PC端：

服务对象：公司内部员工，运营、产品等；

服务目的：管理TMS运输管理系统、司机端客户数据，便于企业研究分析用户行为。

考虑TMS运输管理系统，是给用户提供一套便于操作的后台，因涉及到大量业务流程管理实时处理、实时运费结算、用户管理、报表统计、数据查看、货物跟踪管理等功能操作，用PC端实现比移动端方便，实时性比H5稳定。

司机端的考虑，主要为优于小程序及H5的稳定性，尤其是涉及到收取运费、转账等功能。

运营端的考虑，主要是为了A公司维护用户资料，及做数据统计。

划清楚了业务系统边界，这个时候就可以考虑整体的功能架构设计了！

step3：功能架构划分

列具体功能之前，同研发人员一起先确定企业能够搭建的通用架构，可复用的基础结构，便于日后的架构扩展。如下图所示：

TMS运输管理系统功能划分：

做功能划分时使用用户操作路径的方式排列，主要实现用户痛点之一的：单据管理、调度车辆；监控车辆；报表管理；

司机端功能划分：司机接单、收款；

运营端功能划分：

各个端的产品功能已经梳理了出来，但是3个月能一起设计出来吗？即使通宵加班加点，也需要一个理智的产品经理来定义一个最小MVP，满足系统准时交付的同时又满足BOSS和市场同事推广后能够让用户跑通业务流程。

那么在从0到1的过程中，笔者使用排优先级的方式划分一期（MVP）；二期、三期迭代的功能。个人习惯，可以参考。

• P0级功能：主要是实现业务流通打通，解决主要用户痛点。MVP的原则就是可以人肉去做的事情，都先不做系统支持。

• P1级功能：主要解决支撑特殊业务的需求，如线上支付、线上签署合同、财务对账、核销、开票等

• P2级功能：着重介入风险管控，前期实现业务流程时不会考虑运营，在有了前期业务数据的支撑下再来考虑运营介入，对于产品发展来说是利好。报表的功能也可以在此结算着手，毕竟有着数据基础。

step4：原型及交互设计

本节中，笔者仅举例TMS部分功能及司机端部分功能设计：

1. TMS中最重要的一个功能【create order】

物流行业中，开单的工作是至关重要的一个环节，开单的快慢，能够简介影响物流运输的时效，那么物流系统中常见的创建订单/运单功能设计又有什么特别需要注意的呢？

针对进行开单工作的开单员要求：开单速度要快、开单正确性。

平台如何满足开单员的要求：功能结构上，对缺乏用户需求支撑且造成干扰的功能进行整合删除；交互层面上，屏幕显示尽量调整为一屏，减短用户行为路径；视觉上，优化图标和文字，优化颜色，让用户不视觉疲劳。

下图中分别为两个创建订单页面设计对比：

（1）左图长屏显示，右图一屏幕就可以显示完成，减少开单员开单拖动滚动条才能看到更多内容的时间。

（2）可以作为配置项的条目，让用户多通过快捷键操作，减少用户填写时间。

（3）交互层面上，多级内容尽可能调整在一个页面上，更好的体验产品的人性化。

2. TMS中车辆监控功能

车辆监控在物流行业是作为长期规划的重要功能，设计时实现用户重要优先需求即可。

A公司面对市场用户需求，要实现重点功能：

（1）需要做到货物位置、轨迹实时查看及回放。（现实场景：司机结算完成运输任务，报销时会查看轨迹，才会给与报销结算；司机排长队等着工作人员看轨迹，再给钱。轨迹有问题还会压钱。耽误司机运输任务及增加工作人员时间成本。）

（2）监控看板让货物运输状况一览无余。（现实场景：司机拉着货，在休息区休息娱乐了，时效控制差。）

（3）现场照片实时上传，实现无纸化管理。（现实场景：A公司经常让司机将装卸、车况、路况及货损货差通过拍照并且立即发群留证，容易导致留证照片混乱，不知道是哪笔运单的问题，造成工作人员大量繁琐统计工作）。

3. 司机端

司机端规划的功能以注册认证、接单、上传回单、收钱重点。

举例：司机注册认证

注册认证设计注意点：操作简单、路径短、认证审核快。用市面已有产品做一个对比，如下图所示：

左图为研究市场某产品司机注册，优点：不会让用户二次提交资料；缺点：提交资料重点不明显、注册之后还是会有重新审核认证过程；且需要手动填写的内容过多，容易引起用户体验不适。

右图为A公司调研市面招募司机提交简易资料而做的产品设计，设计目的：注册提交简易资料，用户可进入系统看产品提供基础功能；需要操作更多功能时必须提交认证，可以确保司机是真实用户。

step5：需求文档撰写

3个月的时间，留给产品的并不多，从产品逻辑梳理到原型设计，再到给业务方、BOSS过。有一句打忽悠的话：“过产品方案除了20%的能力，还得靠80%的运气。”

产品方案过了就是最重要的写需求环节，也同时是可以进入UI、UE设计环节。

立场：后端、测试、前端、甚至运营；

目的：写详细的需求文档，让你所面对的立场用户能够快速进入启动工作状态；

那么你的需求要写的多详细？

1. 修订记录，每一次修改都要做好记录，方便举证。那么如何记录，举个例子：

2. 项目背景说明

BOSS告诉我，今天要做个小功能，为什么要做这样的功能就必须让BOSS讲出来来龙去脉，如果是他觉得应该这么加个功能，你也要怀抱十万个为什么的心态。当然，适当挑战老板。

研发面对我们是一样的道理，你的需求文档需要告诉研发，这个项目的背景，产品设计时为什么出现这个模块，为了解决什么？

3. 动态结构

模拟用户在页面上的操作路径，让开发测试人员能够直观了解页面功能组成，直接上个示例图：

4. 详细需求文档

详细需求文档，每个企业的产品文化导致需求文档有不同的写作方法，比如：就在原型旁边注释；用Word编写；等，笔者举个直接在原型上注释的例图：

登录：用户使用手机号+验证码方式

5. 需求完成及时安排需求评审，及时完善修正各部门同事对于需求评审时提出的问题。

6. 正式进入研发阶段，产品经理（项目经理）要进行工期排期，不过A公司给的时间只有3个月。

笔者与各个部门负责人将工作原本长达3个月的工期，拆分成了3个月开发、测试3个小迭代，最后在统一上线，可以各部门人员饱满工作时间，敏捷开发也是最高效的工作方式。

下图举例其中一个小迭代的安排：

7. 产品验收

产品上线前的验收，也是产品经理要做的重要工作之一。

验收注意点：

（1）系统全流程是否通过，逻辑是否正确

（2）用户体验是否友好

（3）功能点是否设计完整

（4）UI

（5）交互功能是否正常

（6）各业务角色功能是否配合流程完整。来个图例，验收纪要：

小结：故事二对于产品经理的工作流程做了一个简要梳理，这也是初次接触产品经理岗位的小白可以参考的工作点。

故事三：王婆卖瓜自卖自夸之运营推广

王婆不夸自己的瓜，买家就不知道瓜甜。

产品经理不需要做运营推广的具体工作，但一定要有自己的一套产品运营思维，针对A公司的这一套物流业务系统，笔者是如何做的运营方案：根据用户群，设计运营方案。

面向的用户群体归类仅为两类：货主、司机。

那么对于货主群体如何设计运营方案？

司机群体如何设计运营方案？

小结：运营方案的制定简单，但实时操作及后续会产生的问题多样，笔者将在未来的更新中将本文中所涉及运营中建立渠道、积分体系以及为什么笔者的运营方案中没有出现SEO/SEM等线上推广方式，笔者将做详细的独立篇章介绍。

故事四：蜀道难，难于上青天之产品roadmap

川蜀地区山多路弯，要向前走，要向上去，要看更好的风景就要经过这些艰难。

每一个产品在推出的时候，一定是符合当前业务模式及满足技术能力的。但是技术会不断进步，用户的需求也在不断更新，品牌也会随着市场而扩展。

产品的roadmap实际在项目规划初期就会确定，笔者之所有放在最后描述，主要原因归属于产品的迭代路径会随着用户需求，市场的趋势而做调整。

举例如何规划roadmap：

首先：同BOSS、业务一同确认经过验证的业务地图，如下图所示：

其次：根据业务地图，确认实现支撑各个业务阶段的功能地图，如下图所示：

小结：产品的迭代路径，切记要根据企业的业务规划来做具体规划，面向B端的业务系统与面向C端的产品不同点，就在于B端业务系统多数由用户更高的需求及市场的趋势决定，而不仅仅是由用户体验所决定。

总结

产品经理从得到一个项目创意，再到这个创意落地会经历几个阶段：

第一阶段：分析并摘选符合该创意的用户群。

第二阶段：分析并验证该项目是否可以赋能用户，是否有利于企业自身的发展。

第三阶段：分析所属用户群体的真实痛点（一个业务系统给用户赋能的特点）、业务逻辑、束流系统的功能特点。

第四阶段：产品设计。

第五阶段：运营推广。

第六阶段：产品的迭代规划及后续维护。

这几个阶段都是一个独立的但又承上启下密不可分的精彩充满了创意、创造力、活力的故事。