1704233414
1704233415
1704233416
1704233417
1704233418
图6-16 No Waiting的产品架构图
1704233419
1704233420
图中有以下几个关键的功能点。
1704233421
1704233422
►公交实时到站查询： 让用户了解是否需要一路小跑去公交站，还是可以先去旁边的便利店买一瓶水。将来计划对接公交公司的数据、BI（Business Intelligence，商业智能）系统，还会对接地图应用。
1704233423
1704233424
►候车娱乐： 如果车还有很久才来，或者已经上车还没到站的时候，用户可以通过候车娱乐玩游戏。其亮点在于，玩的过程中不用再紧张地随时需要停下来抬头看看是否该上、下车了，系统里会有到站提醒。这一功能点将来可以用来承接广告，产生直接收入。
1704233425
1704233426
►叫车功能： 如果实在等不及，还可以唤起第三方的打车应用。
1704233427
1704233428
►到站提醒： 准备上车和准备下车的提醒，同样需要对接公交系统的数据。
1704233429
1704233430
►个人中心iBus： 建立用户数据库，让系统记录用户的家、公司等常去地点及乘车路线，将来也许可以做社交，比如：“本月你和小红已经在这路公交车上邂逅3次了，要不要打个招呼？”
1704233431
1704233432
天猫的产品架构图
1704233433
1704233434
图6.17.2010 年天猫（当时还叫淘宝商城）的真实产品架构图，供大家参考。
1704233435
1704233436
1704233437
1704233438
1704233439
图6.17.2010 年淘宝商城的产品架构图
1704233440
1704233441
根据表达的需要，产品架构图可以画成流程图、实体关系图、用例图等，各种类型的架构图都可以在网上找到相应的参考。
1704233442
1704233443
6.2.5 功能分分合合的本质
1704233444
1704233445
顺着产品架构的话题，再探讨一个产品形态的问题——不同的功能，到底应该做在一起，还是分开。举个例子：滴滴平台的顺风车，乘客和车主的功能在同一个客户端里，而其出租车，乘客和司机的功能分布于两个客户端。
1704233446
1704233447
其实这个问题背后的判断逻辑很简单，就是看不同用户角色背后的自然人重合度高不高 。如果高，则倾向于同一个端搞定，如果不高，则倾向于分离。
1704233448
1704233449
说一个淘宝的故事。
1704233450
1704233451
淘宝的买家和卖家，是典型的双边，他们都需要“商品类目”这个功能。一开始，淘宝试图用一套类目满足双方，但发现两者需求不同。买家通过类目来找商品，希望路径更短，更容易找到，为了不断优化路径，类目结构最好能随着季节、热点不停变换；卖家通过类目来发布商品，则希望其相对固定。
1704233452
1704233453
后来淘宝做了一个很大的项目，叫“前后台类目拆分”。简单地说就是，卖家通过后台类目发布商品，买家通过前台类目选择商品，用不同的产品来服务不同的用户。
1704233454
1704233455
这个项目体现的是互联网向传统行业学习的结果，我在《淘宝十年产品事》中有过仔细的描述，简单说就是电商向线下超市学习商品陈列。
1704233456
1704233457
大超市里的商品，在货架上的陈列方式是变来变去的，会随着季节、销售情况或特定事件经常调整。大超市还有一个重要的地方，就是仓库。仓库里的商品摆放相对固定，食品就在食品区，洗护用品就在洗护区。所以说，商品放在两个地方，对应的是两种分类方法：前台销售和后台存储。从这个例子可以看出，电子商务并不一定比传统商务先进，毕竟后者发展了数百年，一定有很多值得学习的东西。
1704233458
1704233459
如果把外部用户和公司员工视为广义的双边用户，那么，通常外部用户用的前台产品和员工用的后台系统，是两个独立的产品。所以，MVP阶段，就很可能需要做一个独立的后台，而这部分往往被新手产品经理忽略，特别提醒一下。
1704233460
1704233461
1704233462
1704233463