1704233334
1704233335
第7个功能“聊天记录管理器”,早期并没有做。
1704233336
1704233337
仔细区分一下,聊天记录其实有两种,存储在客户端的本地聊天记录和存储在服务器端的漫游聊天记录。限于当时的网络带宽,下载漫游记录纯属奢望,只能考虑客户端聊天记录的备份和管理。但,那个时候很多用户都没有个人电脑,去网吧上网是常态。因为经常需要换电脑,保存本地聊天记录并无实质意义。更为甚者,当时很多用户聊一次QQ就重新注册一个QQ号,完全不理解“个人账号”的含义,以为和登录某些Web聊天室,进房间之前取个昵称是一样的,也就更不会有对备份“聊天记录”这种个人信息的强需求。
1704233338
1704233339
第8个“语音”、第9个“视频”和第11个“传文件功能”,都很类似,没有在早期做。
1704233340
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
[
上一页 ]
[ :1.704233334e+09 ]
[
下一页 ]