PC端分为两种：一种是店铺端（也就是商家后台），这是为加盟商户准备的，类似于淘宝店铺；另一种是管理端（也就是运营后台），这是为运营部门准备的，也就是淘宝官方。由于两者的功能大同小异，仅是部分权限的不同，所以这里展示的是管理端的原型。

认养

虽然认养活动的组织是由运营后台执行的，但具体的认养活动功能只能由商家后台发布，并通过管理后台的审核，只有审核通过的认养活动才会进入消费者的视野。所以，管理端是没有添加或发布认养活动按钮的：

某个认养活动的详情：

前些年出现了一种叫做 认养一头牛 的新型生鲜预售模式。所以，同为生鲜农产品电商的业务方也希望借鉴这一模式，只不过这里是把“牛”换成了果树和羊。

认养功能

当浏览小程序首页时，会看到带有 认养 字样的商品：

因为这是一款C2C应用，所以也就不用区分所谓用户端和商户端了。

比较遗憾的是，由于某些客观原因，该应用的原型已经遗失，就只好拿切出的高保真图片代替原型了。

该应用的主要功能包括：

• 用户发布需求并指定时限和酬劳；

• 接单者可以在指定范围内查找有效订单，并决定是否接单；

• 轻社交的吐槽功能，主要是为了发现并满足潜在需求；

• 当交易双方出现矛盾时，任何一方都可以发起仲裁，仲裁会显示交易双方的原始需求、交易金额及利益冲突点，仲裁结果由所有围观群众投票决定，APP不会干预，但APP最终会把交易金额全部转给得票数多的一方：如果是接单者则获得全部酬劳，如果是发单者则可返还全部佣金。

曾经有一段时间，跑腿、代买、代购非常流行，在这种背景下，公司也接到了这样的 软件外包 开发需求：开发出一款基于C2C模式的同城快递应用，自然地，就由我来负责该应用的主要研发工作。

该应用较为特殊的一点是既没有物联终端，也没有Web前端，纯粹就是个人用户的APP移动端和服务后台。其业务架构如图所示：

这款APP基于LBS定位，上线初期定位于大学生群体，连接校园个人供需信息并撮合线上交易。学生党们可以在APP上发布任何的需求或者自己可以分享的物品、技能，系统根据需求的类型与周边相符的其他用户进行智能匹配，当用户建立起联系后，由APP撮合双方完成交易。

相比于移动端APP，本产品初期研发的大部分精力都是放在了商户PC端上的，因为如果仅有用户的话，整个业务是运转不起来的。

商户PC端的功能较为复杂，分为工作台、交易管理、商品与服务、营销中心、会员中心、财务管理、货源中心、人员管理、店铺管理和系统管理这十大功能模块，每个大功能模块下面又有若干子功能。其整体流程图为：

由于到涉及好几百个Web页面，如果全都列举出来实在是费力不讨好，也没有必要，所以就拿交易管理、营销中心和会员中心这三个较为核心的大模块来举例。

商户端APP

由于受业务形态的限制，所有的商户能提供的服务都是在线下的店铺内完成的。所以，除了老板可能需要远程了解一下经营状态之外，其他与店铺端服务相关的角色对于移动端APP应用都没有任何需求。

基于以上情况，本产品从一开就没有将精力投入到商户端APP的开发中，仅仅对需求做了一些简单规划，如下图所示：

用户端APP

用户端APP的功能共分为四个部分：【服务】、【出行】、【爱车】和【我的】，其中：

• 服务：聚合了周边商家所能提供的产品或服务，用户可在此下单购买所需；

• 出行：包括地图、寻车、天气信息、行车记录仪监控视频（OBD配套产品）等功能；

• 爱车：包括车辆信息、车况信息、保养记录和报警记录等功能；

• 我的：包括车主信息、车库、订单、行程、钱包、收藏、消息通知等功能。

不同业务环境和功能决定了不同的产品形态：对于可穿戴设备来说，人们可以完全自由地操控它，不存在什么限制。但是对于车载用品来说，首先需要保证的是行车安全，其次才是便捷耐用。因此大部分车载用品，尤其是OBD，都是不需要人为干预就能自动工作的，所以它就根本不需要有什么显示屏、按键或开关之类的部件，如图所示：

这是我主导研发的另一款智能硬件产品，它与智能穿戴产品类似，将公司自主研发的的车机OBD硬件作为数据采集终端，采集车辆行驶中的各项数据，如 里程、时速、位置、进气温度、燃油压力、发动机转速、剩余油量、油耗 等数据上报到服务端，再由移动端APP主动拉取或服务端推送这些数据，最终形成车辆行驶过程中的监测报告，并向车主展示。

同时，与我们合作的 汽车后市场服务供应商（所谓汽车后市场，指的是车辆维修、保养、零部件更换、改装、美容等业务的泛称）也会收到已注册的车辆里程数据（当然，这些数据需要脱敏处理，服务商只知道车辆型号和已行驶里程数，并不知道车主、牌照等其他信息）。

首先说明，所有Web网页功能均是我基于一款开源的Java服务端应用实现的二次开发，且全部的服务端及Web页面核心代码、业务功能代码都由我一人独立完成。

在公司初创时，由于全部的研发力量都集中到智能硬件和APP上，而由于我本人又投入部分精力到Android原生应用的开发上，因此无暇顾及服务端Web页面的开发工作。但是当APP应用已经初具雏形，且所有的硬件采集和APP展示数据都需要通过后台中转，并需要能在网页上展现的时候，就必须要有一套能适应公司业务发展的后台应用了。

因为时间较为紧迫，而且在已经有了一套现成的开源后台的前提下，就没有画任何的原型图，直接在已有的后台功能代码上修改，实现我们自己需要的业务功能。另外，这套开源后台已经有了配套的JSP页面，无需再单独开发前端页面。

APP的作用有这么几个。

• 获取服务端的佩戴者数据，而这些数据是通过手表采集的。因为手表资源有限，所以注入心率和运动数据也仅仅是展示当前的测量值，而历史记录则都存储在了服务器中。例如，佩戴者自己想知道过去一段时间的运动量或心率波动情况，就可以通过APP从服务器中获取。

• 佩戴者的亲友想知道当前佩戴者的位置，可以通过APP给手表发送定位指令。这些指令都是从APP发出，然后经过服务器中转后，再发给手表的，APP与手表除了蓝牙连接之外，是无法直接通信的。

• 可以将佩戴者的数据与正常数据进行比对，发现健康风险或异常状况，起到一个参照作用，同时还可以给出一些有用的建议。

• APP可以作为联系佩戴者亲友的一种备用手段。