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歌系统里恰好没有的话，便可以愉快的上传上去 | 意愿较低 | 目前手机传歌的用户体验还比较差，导入慢，搜索歌曲时间久，有些歌没有歌词，付费意愿不是很强烈 |