1704233350
图6-14 QQ邮箱的欢迎界面，介绍了最早的表情符号
1704233351
1704233352
最后，再提一下“优雅降级”这个概念。说的是，在思考这种“一大堆功能中选哪几个先做”的问题时，也可以用逆向思维。假设产品已经完全具备这些功能，但是因为流量太大，服务器撑不住了，必须要关掉某些功能以保证基础产品的可用性，你会留下哪些功能？
1704233353
1704233354
天猫双11时，在产品里就做了成百上千个这样的开关，以应对局部系统的压力过大。回到QQ的案例，你想保留的那些，就是应该最先做的。
1704233355
1704233356
综上所述，我认为应该最先做的几个特性是：3.6.10 ，最多再加一个1。
1704233357
1704233358
6.2.3 MVP的限制因素
1704233359
1704233360
现在，试着完整地回答如何打包功能和确定MVP这个问题。
1704233361
1704233362
不同功能不同对策
1704233363
1704233364
先回顾理想模型，结合相关原则和限制，按照性价比的评估和KANO模型的功能分类，最终结论可总结为：
1704233365
1704233366
►基础功能必做，要留足资源。
1704233367
1704233368
►在产品初创期，先实现个别低成本的亮点。
1704233369
1704233370
►对期望功能，先做性价比高的。
1704233371
1704233372
►无差别功能无须做，低成本验证出来即可。
1704233373
1704233374
►对反向功能，权衡各方利益后再决定。
1704233375
1704233376
考虑功能依赖关系
1704233377
1704233378
功能的内外部依赖关系，如合作伙伴和各种前置条件等，都需要事先考察。
1704233379
1704233380
例如，某个功能的实现有技术难点，在你的公司里只有某位技术大牛才能解决，而他短期内在另外一个项目里出不来；或者，你的海淘业务想做一个互动，能不能成功，取决于某个关键商品是否能拿到更好的价格，现在需要等待与供应商的谈判结果。功能的依赖关系，有点像产品概念筛选环节需要讨论的那些因素。只不过，这里需要考虑的因素更细节、更具体，并且是针对每一个具体功能点的。
1704233381
1704233382
考虑功能相似性
1704233383
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
[
上一页 ]
[ :1.70423335e+09 ]
[
下一页 ]