1704233341
以当时的网络速度，这些功能就算实现了也不会有很好的用户体验，要等到宽带普及才有必要考虑。
1704233342
1704233343
第12个功能“QQ表情”，因为满足这个需求有可替代的现行途径，所以也可以先搁置。
1704233344
1704233345
当时，很多人都已经知道有一种东西叫颜文字，可以用标点符号及英文表示一些十分简单的面部图案。比如用冒号+不同方向的括号就可以代表笑脸和哭脸，如图6-14所示。所以，解决情绪表达的需求暂时不急。
1704233346
1704233347
1704233348
1704233349
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呢？通常会画一张产品架构图。