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
1704233464
人人都是产品经理2.0：写给泛产品经理 [:1704229226]
1704233465
人人都是产品经理2.0：写给泛产品经理 6.3 把需求和功能管起来
1704233466
1704233467
该做哪些、做多少都想清楚了，MVP和产品架构图也确定了，接下来要扫个尾，把已经做了的、正在做的、还没做的需求和功能都管理起来。可以从以下两个维度进行管理。
1704233468
1704233469
6.3.1 空间维度：功能列表
1704233470
1704233471
空间维度的管理工具是“功能列表”，它表达了在某个时间切片，所有功能的状态。类似图6-18，每行是一个功能点，每列是功能的一种属性。读者如想进一步了解相关知识，请参阅拙作《人人都是产品经理（纪念版）》，书中有详细讲解。
1704233472
1704233473
1704233474
1704233475
1704233476
图6-18 功能列表示意
1704233477
1704233478
6.3.2 时间维度：需求流程
1704233479
1704233480
时间维度的管理工具是“需求流程”，它其实是从需求到功能的状态流转图。图6-19反映的就是从最初需求采集回来的待讨论状态开始，之后需求发生转化，流向开发环节，最后过渡到已发布状态的全流程。“需求流程”实际上是在管理某个需求到功能的完整生命周期。读者如想进一步了解，同样可以参阅《人人都是产品经理（纪念版）》一书。
1704233481
1704233482
值得一提的是，图6-19里的“暂缓”，在实际工作中已化身为“这个需求放二期”，成为产品经理拒绝需求的金句。用这招，不知道砍掉了多少功能，因为很多项目根本就没有二期。还有一些砍需求的金句，分享出来博读者一乐[6] 。
1704233483