个人作业——关于K米的产品案例分析

Notice：本文所采用的K米版本为 Version:4.3.0 Release：20161014

第一部分 调研，评测

评测：

软件的bug，功能评测，黑箱测试

1、下载并使用，描述最简单直观的个人第一次上手体验

打开app首先进入的是“k歌”的主界面，由于k米主打线下ktv功能，因此"连接包厢"放在了最显眼的位置。连接包厢之后，可以进行一些点歌、遥控、直播、发弹幕之类的操作，将我们从传统的点歌台释放了出来，增加了趣味性和可玩性。除了“k歌”，还有“附近”、“聊天”、“发现“等功能，总的来说已经算是面面俱到了。

2、按照描述的bug定义，找出几个功能性的比较严重的bug（至少两个）。用专业的语言描述（每个bug 不少于 40字），如有必要，可以配图

（1）绑定时，没有验证手机号码的正确性

由于发布动态需要绑定手机号码，本着测试的原则，我输入了一个无效的手机号码 12345678910（据我所知，中国大陆目前还没有123号段的手机号），然而系统返回的却是该手机号已被绑定，不能重复绑定。我不知道该号码是如何被绑定的，但是起码可以知道，系统对于输入的手机号码没有检查其正确性，好歹也要用正则表达式进行校验一下（还是说系统用的正则比较弱？...）

（2）包厢人数“计数”有问题

那天去ktv测试的时候，我们队有6个人在场，虽然有一些围观群众会时不时进入到我们的包厢，但是人数不可能会达到15人之多，点击详情之后，按头像来算好像也就10个左右。个人的猜想是，已经退出包厢的人还会被计算在内。

（3）“重唱”、“视频录像”按钮无反应

在k歌的时候，点击“重唱”按钮无任何反应，也没有提示，而“视频录像”按钮则一直处于灰色状态。其中，“重唱”功能不能执行算是比较影响体验的一个点，若用户想要重唱只好得再返回点歌界面重新再点一遍。

（4）发布动态时，点击从相册添加图片后软件会崩溃(重现率接近100%）

3、你觉得为什么这个产品组的人没有发现这些bug？

（1）可能产品组的人认为大家都会自觉输入自己正确的手机号码，写的正则校验可能比较弱。（其实，我还是比较好奇12345678910这个号码是怎么被绑定的。。）
（2）也许“计数”是一个比较不太重要的功能，所以没有很好的去测试。
（3）我觉得这个可能是ktv的设备不支持重唱吧，导致软件上点“重唱”没任何反应。可能产品组的人没有很好考虑软硬件的兼容性，毕竟全国有这么多家ktv。
（4）测试的时候可能没有覆盖所有可能出现的情况，导致在某种条件下程序会崩溃。

采访：

1、介绍采访对象的背景和需求（他们有没有用过这个APP或类似的APP，除了现有的功能还有别的需求么）

• 背景：在校大学生，计算机专业，平时很少去KTV，没有使用过类似的app，一般通过点歌台点歌
• 需求：基本的点歌、K歌、遥控等功能

2、让采访对象使用10-30分钟K米的功能（请上传照片证明用户的确正在使用，远程采访的同学请让别人帮忙照相）

3、描述用户使用这个产品的过程, 用户的问题解决了么？软件在数据量/界面/功能/准确度上各有什么优缺点？用户体验方面有问题么？

用户的需求问题K米基本上都能够解决。在数据量上，常见歌曲基本上可以搜得到，但是曲库还不是特别丰富。界面UI还可以，上手简单，比较简洁美观。功能上，k歌的核心功能做的挺好，其次包厢直播，发动态，在线预定ktv都是挺实用的功能。准确度上，通过简拼搜索歌曲准确度不是很好。用户体验方面，由于试用时间比不长，没遇到什么大问题，总体上来说还算满意。

4、用户对产品有什么改进意见

• 希望增加通过歌词片段找歌的功能
• 界面UI交互有提升的空间
• 丰富首页的内容
• 增加曲库歌曲，歌单等
• 本地歌曲扫描、导入过慢

5、结论：经过这么多工作，你一定有充分的理由给这个软件下一个评价,请选择一个结论:

推荐。去KTV必备的“神器”，再也不用跑到点歌台去啦~

第二部分 分析

1、使用此软件的大部分功能，联系第二部分的分析，估计这个项目做到这个程度大约需要多少时间（团队人数6人左右，计算机大学毕业生，并有专业UI 支持）
大约需要25周左右，具体分析如下：

阶段	周数
开发前的计划	1
需求分析	2
生成设计文档	2
设计复审	1.5
代码规范	0.5
具体设计	3
具体编码	10
代码复审	2
测试	1
测试报告	0.5
计算工作量	0.5
事后总结、改进	1

2、分析这个软件目前的优劣（和类似软件相比），并推理出团队在软件工程方面可以提高的一个重要部分（具体建议）

优势：k米是星网视易公司点歌系统在互联网下的一个衍生品，因为其点歌设备在市场占有率较大（据官网介绍，其联网KTV市场占有率达到50%），所以有大量线下实体的ktv可以为k米带来可观的流量。
劣势：主要是UI、交互方面还有待改进。
建议：我觉得在软件工程方面可以提高的一个重要部分是“用户体验”部分。也就是说，软件开发者需要站在用户的角度上考虑问题，不单单只是实现了某项功能就行，还要考虑这个功能在实际使用中用户体验的问题。如果用户体验不好，再实用的功能用户也不会买账。

在这，我就举几个在使用k米软件时影响用户体验的地方：
（1）通过通讯录添加好友，右侧的索引栏过于密集

由于索引栏采用的不是传统的 A~Z 索引，而是采用姓氏来索引，如果通讯录中好友的姓氏种类比较多，那么右侧的索引栏将会非常的密集。

（2）手机传歌的过程非常慢

经测试，一首10M左右的歌曲，需要导入5~6分钟，这所花的时间超过了用户的预期。

（3）搜索本地歌曲没有缓存，每次都要重新搜索，且不能自定义文件夹

这个我觉得是最不能忍的，每次导入歌曲的时候，都得重新搜索一遍，而且还是全盘搜索特别慢，搜索也不能指定文件夹。

3、根据理解和体验，画出整个软件所有功能逻辑框图，根据重要度标识出各模块的重要度、完成度、出发点及效果

• K歌

• 重要度： 95%
• 完成度： 80%
• 出发点： 作为软件的主体功能，方便用户连接包厢、搜歌等
• 效果： 不错。基本上能够满足用户的需求，但是歌曲内容比较少，歌单好像也没经常更新

• 直播

• 重要度： 90%
• 完成度： 85%
• 出发点： 开直播与其他用户分享，互动
• 效果： 还行。虽然不能与专业的直播软件相比，但是已经足够了。其次，直播互动方面还有待改进

• 附近

• 重要度： 70%
• 完成度： 80%
• 出发点： 分享用户动态
• 效果： 一般。说是附近，但是基本上显示的都是距离几百公里之外的用户...

• 聊天

• 重要度： 80%
• 完成度： 90%
• 出发点： 方便用户之间交流，联系客服，以及获取系统消息
• 效果： 较好。聊天的功能基本上都达到了

• 发现

• 重要度： 70%
• 完成度： 90%
• 出发点： 方便在线预定ktv，发布一些话题，还可以找到附近的k歌达人等
• 效果： 一般。用户一般只关心其中“预定ktv”的功能

• 我

• 重要度： 95%
• 完成度： 90%
• 出发点： 每款软件都必不可少的部分
• 效果： 不错。栏目设置清晰合理，用户能够很快找到自己所关心的部分。

**4、针对不同的维度评分，对用户体验方面、UI界面美观度、核心功能，分别打分（总100分） **

维度	得分	理由
用户体验	80	前面我已经就影响用户体验方面举了几个例子，所以这块我打的分偏低一些
UI界面美观度	85	K米的界面给我感觉算比较简单朴素，有些地方只是简单的控件的堆叠，有些地方只是调用webview而没有进行UI的设计
核心功能	95	k米作为一款ktv软件，在点歌搜歌、连接包厢等核心功能方面还是做得不错的

第三部分 建议和规划

这个软件有很多可以提高的部分。

1、如果你是项目经理，如何提高从而在竞争中胜出？
根据《构建之法》8.5小节的内容，我觉得可以从以下几个方面提高：

2、目前市场上有什么样的产品了？

• 一起唱 [查看官网]

• 欢乐KTV [查看官网]

• 开唱KTV [查看官网]

3、你要设计什么样的功能？

• 多人微游戏

去ktv唱歌经常会有这样的场景，只有几个人在唱歌，其他人则在旁边无聊地刷着手机。为了活跃包厢气氛，促进大家的交流，连接包厢后，包厢成员可以通过k米发起微游戏。微游戏顾名思义是一些小游戏，特别是适合多人玩的小游戏，比如“你画我猜”，“谁是卧底”这种类型的游戏。

• K歌擂台赛

每周定期举行K歌擂台赛，在这段时间内，指定若干首歌曲可供打擂。每位用户只能在实体ktv中K歌才能参与此活动，由于k米支持歌曲打分系统，所以我们可以利用这个优势来进行打擂。一周结束之后，每首歌曲得分最高的用户可以获得一定虚拟（如k币）或实体（免ktv包厢费）等奖励。

4、为何要做这个功能，而不是其他功能？

这两个功能都是从实际需求出发，第一个功能在于促进包厢成员之间的交流，第二个功能则是增加app的活跃用户数。

5、为什么用户会用你的产品/功能？

首先，多人微游戏是有一定用户基础的，像“你画我猜”，“谁是卧底”这种微游戏上手快，同时又适合多人游戏，老少咸宜。一些微信公众号也提供类似的功能，现在我们把它整合到k米app中，减少了用户使用的成本，又能够在一定程度上活跃包厢的气氛。其次，对于K歌擂台赛，用户只需在KTV唱歌之余，对于自己感兴趣的歌曲，“顺手”参加一下，便有可能获得一定的奖励，何乐而不为呢。

6、你的创新在哪里？可以用 NABCD 分析

• N（Need，需求）: 用户希望在k歌之余，还有其他事情可做，最好是能够活跃包厢气氛的。同时，K歌如果可以获得一定的奖励，那么也是极好的。
• A（Approach，做法）: 在app内加入“多人微游戏”和“K歌擂台赛”这两个功能。多人微游戏的原型已经有很多，可以很方便地整合进去。K歌擂台赛需要有专人每周定时发布打擂歌曲，评分利用原有的K米评分系统即可，奖励部分可以和合作商家协商。
• B（Benefit，好处）: 对于用户来说最重要的是活跃气氛，同时还能够在k歌之余获得奖励。对于app开发者来说，可以增加app用户的粘性和活跃度。
• C（Competitors，竞争）: 这个目前来说竞争压力还比较小。虽然同款软件中，一起唱有实现一个叫“互动游戏”的功能模块，但是其中内容比较少，且娱乐性、互动性较差。欢乐KTV则实现了一个叫“斗歌”的功能模块，但是斗歌主要是用户之间，且没有奖励，用户使用程度不高。
• D（Delivery，推广）: 推广的话，主要可以利用线下合作的商家以及线上官网，app广告进行推广。比如可以线下张贴K歌擂台赛活动的海报，在用户绑定包厢之后，于点歌界面推荐本周的打擂歌曲。同时，进入包厢之后，还可以将多人微游戏置于醒目的位置，引导用户进行使用。

7、如果你来领导这个团队，会有什么不一样？

• UI界面应该会有比较大的提升
• 站在用户的角度考虑，注重用户体验
• 软件发布之前进行严格的测试

8、如果你的团队有5个人,4个月的时间，你作为项目经理，应该如何配置角色（开发，测试，美工等等）？

• 1个项目经理
• 1个美工
• 2个开发（兼测试）
• 1个文档

9、描述你的团队在16 周期间每周都要做什么，才能在第16周如期发布软件，大小里程碑绩点设定

周数	任务
1	需求分析，用户调研
2	需求复审，设计原型，编写软件规格需求说明书
3	搭建开发环境，确定编码规范，进行系统概要设计
4~5	进行系统的详细设计，包括系统的基本处理流程、组织结构、模块划分、功能分配、接口设计、运行设计等等
6~10	编码开发阶段，每个开发者根据设计要求分别实现各个模块的功能
11	测试阶段，对各功能模块进行单元测试和集成测试
12	发布alpha版本，进行小范围内测和实地测试
13~14	修复软件内测中发现的bug，并追踪是否有需求变更
15	撰写各项文档
16	发布正式版本，交付使用

• 小里程碑：第2周、第5周、第14周
• 中里程碑：第12周
• 大里程碑：第16周

10、作为用户，你或你们最喜欢K米中的什么功能？（列表123，最多选择三种，说明理由） 你或你们可能会为哪些功能付费？（说明理由）

序号	功能	理由	付费意愿	理由
1	包厢直播功能	现在处于网络“直播”时代，对ktv包厢进行直播，包厢里的小伙伴可以在直播间里尽情玩耍，没能到ktv现场的亲朋好友或者是围观群众也能感受到现场的气氛	愿意高	如果能够在当前直播功能的基础上，不断优化完善，丰富直播间的功能，我愿意为此付费
2	录制我的作品功能	能够将自己的“杰作”保存下来，发个动态炫耀一番	意愿一般	若今后能够对作品进行进一步的加工编辑美化，还是有付费的意愿
3	手机传歌功能	非常实用，如果自己喜爱的歌曲，K歌系统里恰好没有的话，便可以愉快的上传上去	意愿较低	目前手机传歌的用户体验还比较差，导入慢，搜索歌曲时间久，有些歌没有歌词，付费意愿不是很强烈