1704233384
功能相似才能保证我们做的是一个整体的项目，而不是一个小需求合集。本书提及的所有产品相关流程，更加适用于一个完整的可以实现用户价值的产品，而日常小修小补的需求合集，则可以做适当简化。一般来说，1.0.2 .0这种成熟的版本，基本上已经是一个完整的产品，而1.01.2 .1.3这样微小的版本升级，通常对应一个小需求的合集。
1704233385
1704233386
考虑非功能需求
1704233387
1704233388
最后，还要识别出一些“非功能需求”。由于非功能需求也是有成本的，所以要在项目实施之前应当一并考虑进去。如“论坛需要支持1000人同时在线”，这是一个性能需求；“系统功能升级，必须在发布2周以前完成对客服部门的培训”，这是一个培训需求；“如果硬件压力突增，应该有报警，具体细节是……”，这是一个运维部门的维护需求；“在用户数增加10倍的情况下，硬件投入必须小于2倍”，这是一个可扩展需求；“此功能的用户操作日志需要记录”，这是一个内部数据分析的需求。
1704233389
1704233390
功能打包好了，怎么来表达你的MVP呢？通常会画一张产品架构图。
1704233391
1704233392
6.2.4 MVP的表达，产品架构图
1704233393
1704233394
有一个段子说：
1704233395
1704233396
通过在公司里写的文档类型，就能看出地位高低。最底层的写Word，在细化一个具体的任务；高级一点的写Excel，给很多事情安排优先级；更高级的写PPT，需要向老板汇报；什么时候开始听PPT，就成老板了。
1704233397
1704233398
俗话说“字不如表，表不如图”，能用一张图来表达想要做的事情，通常说明是想得比较清楚了。产品架构图的形式不限，绘制工具不限，甚至手绘都可以，因为画得好不好根本不重要，关键是要能把事情表达清楚。
1704233399
1704233400
一起来看几个例子。
1704233401
1704233402
一本书的产品架构图
1704233403
1704233404
图6-15是用Visio画的，纯自由流，是《人人都是产品经理（纪念版）》一书的产品架构图，表达了每一章讲什么，主要有哪些话题。
1704233405
1704233406
1704233407
1704233408
1704233409
图6-15 《人人都是产品经理（纪念版）》的产品架构图
1704233410
1704233411
一个创业产品的架构图
1704233412
1704233413
再来一张，是我在某公司交流时指导学员画的。他们要做一个叫“No Waiting”的产品，切入点是解决“乘坐公共交通出行的人们在上车前和在车上的大量等待时间里感觉很无聊”这个问题。针对这一切入点，学员们以核心用户为中心，把关键功能依次展开，来完成这张产品架构图的绘制。
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