关于K米的案例分析
第一部分 调研，评测
评测
1.第一次上手体验
首先，很遗憾的表示我没有接触过类似的软件，对于这类软件是一无所知。
接下来说说对他的第一印象吧，第一眼看到它的图标觉得不错，简洁明了，让人一眼就知道这个是K米软件。
然后，打开软件看看吧，跳到的是主页面，KTV点歌，让人顿时明白原来这个是KTV点歌的，只要扫描包厢上面的二维码就可以进行点歌功能。那么再看看别的页面吧，把每个页面都打开看看，发现每个页面的主要功能都是一眼就抓住人们的眼球，让人能够很快的知道这些页面都是用来做什么的。
2.大家一起找bug
- 什么是bug？
通过《构建之法》的学习，bug言简意赅的说就是软件的缺陷，它包含了三个方面：
症状：从用户的角度看，软件出了什么问题
程序错误：从代码的角度看，代码的什么错误导致了软件的问题
根本原因：错误根源，也就是导致代码错误的根本原因
那么我们作为一个普通用户来测试这个软件，我们要找的bug当然是从它的症状方面入手。
- 找到bug
时间：2016年10月18日
地点：榕桥之声
人物：我说的都队
图片：测试的时候都忘记了拍照，what a pity！
- 本地传歌，搜索不到本地歌曲
测试传歌功能的时候，发现有的手机可以上传本地歌曲，有的手机无法搜索本地歌曲，在搜索过程中，只提醒来自酷狗、百度音乐、天天动听的的歌曲导入体验更佳，而没有说明不支持哪些app的歌曲导入。PS：使用网易云音乐的可以导入。
- 评分系统不专业
测试评分系统的时候，有人的评分开关没有反应。当开启评分系统之后，无论是有没有开原唱，有没有真人在唱，都没有影响他的评分，都是一如既往的高分，后来我们发现只要是有声音，他都能评分。
- 已点歌曲既刷新无反应也没法取消
使用手机遥控点歌之后，发现已点的歌曲刷新没有反应。错点的歌也没法取消，只能等待播放时切歌。点过的也唱过的歌曲记录为0，不是很懂是为什么？
- 快速点击发布，出现多个输入页面
当多次点击发布的时候就会发现，跳出多个输入框的页面，导致返回的时候要多次返回才能回到主页面。
- KTV预定，商家信息不真实
负责小组测评的KTV选择的时候，预定KTV，打电话过去预定的时候，发现有家KTV的电话不全，只有0591-，还有一家打电话过去，店家说人家开的KTV位置在日本，这都是些什么鬼？
这两家店铺都是排在商家列表的前几位。
- 产品组为什么不改bug？
我认为，可能有以下几点：
a:在这个app不断更新的时代，同类型app可能会有上百家公司都在研究这款，那么为了抓住这个机遇，往往不得不先上线，再不断修复bug。
b:一款产品是由多个人合作共同完成的，那么每个人都有负责相应的部分，你以为对方写的内容没有问题的时候，直接拿来使用，导致bug的迭代，看起来小小的bug不是那么容易修改的，以至于修改bug的周期就变的更长。
c:网络环境的多样性，客户端环境的多样性，导致开发/测试人员没有办法一一测试，导致了某些手机上面的bug发生。
采访
-
采访对象：数计学院大三某女生，该生喜欢唱歌，平时也会唱歌给我们听。
-
需求扩展：由于这个软件的主要是在KTV包厢使用，平时好像并没有什么能够用到的地方，她认为应该扩展一下评分功能（如唱吧）可以随时对自己的歌唱水平进行测试。
-
使用过程：在KTV里面唱歌的时候，可以使用手机遥控，进行点歌等功能。
-
用户体验：
KTV的遥控功能不错，人手一台遥控。
直播可以邀请远方的朋友一起加入。
- 用户意见：
陌生人可以随意进入包厢，不喜欢这个功能，希望可以设置密码等。
扫描二维码等待成功，需要的时间太久了，在信号不好的时候，扫描不出来。
直播时候K米不能放在后台，一不小心就会自动退出。
社交圈好像都是陌生人，不会判断，可能认识的人。
-
结论：K米虽然可以在KTV里面使用，但是很多功能都还不够完善，界面方面也不够美观，加上我对这个软件的测评体验，我是不推荐这个软件，对于不常去KTV的人来说，这个软件根本没有什么用处。用户人群太局限。
-
用户反馈：
最喜欢什么功能？
手机遥控功能，可以掌控灯光，音效，点歌，切歌的感觉不赖。
会为哪些功能付费？
就目前K米提供的功能来说，会进行付费的功能可能就只有给主播送礼物这一功能。
第二部分：分析
1.工作的估计
团队6人，计算机毕业生，专业UI支持
这是我自己假定的几个可能性：
有过多次的项目经验
其中有人写过类似的K歌功能
编程水平普遍比一般人要高（大佬级别）
根据以上的假定，可以总结出，要想写出K米这个程度的项目，要花费的时间应该是比较久的，6个人应该是可以直接上手编码的，以下是我估计的时间：
| 功能 | 时间/天 |
|---|---|
| 需求分析 | 1 |
| 分工安排 | 0.5 |
| KTV点歌 | 5 |
| 各类排行榜 | 2 |
| 附近动态 | 1.5 |
| 附近人 | 1.5 |
| 交友 | 1.5 |
| KTV预订 | 1 |
| 系统设置 | 1 |
| 搜索功能 | 1 |
| UI设计 | 2 |
| 合计 | 18 |
看完这个时间估计，自己都觉得可怕，开发一款软件好像被我想的太简单了，好吧，这可能是我脑中对大佬的印象吧，高不可及。
2.软件的优劣
优势
查找了一下手机里的应用商店，发现关于唱歌的软件更多的是全民K歌这种的手机版现场KTV直播，而K米是更适合在KTV包厢里面使用手机就可以进行的各种点歌功能。
劣势
核心功能要在KTV里面实现，线下根本没有什么用处，也不能录歌等功能，使用率降低，缺少竞争力。
3.团队提高
功能的完善：有些功能有显示在页面上，但是无法使用
软件测试：感觉测试不够，导致不同手机出现各种各样停止运行的错误。
注重细节上面的实现
提高用户体验
4.功能逻辑框图
5.模块分析
| 模块 | 重要度 | 完成度 | 出发点 | 效果 |
|---|---|---|---|---|
| K歌 | 非常重要 | 85% | 与KTV合作，与点歌台功能类似 | 连接过慢，网络配置要求高，用户体验一般 |
| 附近 | 重要 | 90% | 增加社交功能，吸引用户 | 社交功能不错 |
| 聊天 | 非常重要 | 80 | 增加社交功能，吸引用户 | 界面混乱，聊天内容有限制，用户体验差 |
| 发现 | 重要 | 98% | 增加社交功能，吸引用户 | 社交功能不错 |
| 遥控 | 非常重要 | 90% | 满足KTV懒癌患者，使用手机就可以进行各种操作 | 按钮不灵敏，视频不可录制 |
| 个人主页 | 较为重要 | 100% | 用户管理 | 一般 |
6.多维度评价
要对一个产品进行评价的话，首先，要确定从哪个角度出发，这次我是站在用户的角度出发来评价的。K米的主要用户是KTV常客
| 维度 | 说明 | 评分/十分制 |
|---|---|---|
| 用户体验 | KTV包厢使用的功能 | 9.5 |
| 交互视觉 | 用户能否很好的使用app功能 | 8 |
| 技术性能 | 用户想要的功能现有版本是否存在 | 8 |
| UI风格 | 视觉效果 | 8.5 |
| 便捷度 | 使用这个app是否方便了生活 | 9 |
| 与人分享 | 能否在朋友圈里面一同使用这个app | 7.5 |
第三部分：建议和规划
如果我是项目经理，我能够为项目做的是什么呢？
- 市场调研
手机应用商店里的手机KTV应用有唱吧，天籁K歌，全民K歌，这类产品更注重的是查找歌曲，根据歌曲的完成度评分。
- 提高竞争力
在K米注重的KTV点歌功能上，精益求精，扩展需求。
增加与KTV合作的数量，普及度不高
增加模块：如唱吧的核心功能
- 功能扩展
1.KTV包厢里面的人员可以和远程的人员对话（不是通过弹幕的形式）？
理由：发现进入同一个包厢的大部分都是认识的人，他们更想要的是可以实时的对话，而不是发弹幕在上面。
2.设置包厢密码
理由：当不想让陌生人员随意进入包厢，观看包厢视频的时候可以使用，保护用户的隐私。
3.增加合唱功能
理由：合唱在KTV里面是必不可少的额环节，而一个贴心的app怎么能缺少这一功能呢？
- 用户使用率
本款app面向的是那些喜欢去，经常去KTV的用户，使用这款app可以让他们感到更好的服务，可以随时的控制KTV包厢里面的设施：灯光，音效，点歌等等，而且还不缺少社交功能，富有趣味性。
- 需求分析
* N（Need）
KTV商家管理：为顾客提供服务，吸引客户
用户：更舒适的唱k环境
K米管理人员：对接KTV的硬件设施，提供软件的技术支持，既帮助KTV留住顾客，也留住自己常用用户
* A (Approach)
和商家合作，推出优惠活动
是否在现场都可进入包厢，观看包厢现场状况，如临其境
自带麦克风，随时随地可以唱歌
* B (Benefit)
KTV的商家：可以有增加途经推广自己的店铺，吸引客户，在市场竞争下，有了独特的竞争力。
用户：既享受更舒适的唱K环境，也不缺少和朋友的交流。做到和朋友随时随地去KTV唱歌的便利。
K米管理人员：可以进行广告竞标，获得营利点。
* C (Complete)
优势：主要功能在KTV里面使用，这是市场上其他商品所没有的地方，给顾客更舒适的唱K环境。
劣势：功能单一，社交圈有局限性，用户体验不佳。
* D (Deliver)
先跟商家合作，让商家帮忙推广给客户。
在各类使用范围广的app上安排广告宣传
在电视节目里面植入广告。
-
工作安排
-
任务分工
人数5人，时间：4个月
-
首先，了解一下5个人各自擅长的方面，选定一个为主力队员，负责项目的协调。
一个负责美工，两个负责开发，一个负责文档，一个负责测试，两个开发者如果实力不均，可以是厉害的带领另一个编码，而不是厉害的一个人把所有的全包了。
-
项目进度安排
周数 任务 说明 1 任务的分配 开发过程中组员的任务细化分配 需求说明书 根据需求，细化说明，编写需求说明书 思维导图 完成思维导图 2 原型设计 根据需求说明书完成原型设计 风格确定 美工的设计 3 编码规范 分析软件，编写编码规范 编码环境 确保团队的编码环境的统一 4 编码初期 正式进行编码，审查项目进展 5 编码中期 审查项目进展 6 Alapha版本发布 Alapha版本的完成 测试 查找不足点，更改需求等等 7 Alapha版本的完善 根据上周的审查，改进不足之处 细节 改善用户体验 8 继续完善 第一版本修改完毕 9 测试 对Alapha1版本的测试，提出要求 Alapha1版本的改善 进一步优化软件 10 美工上线 对软件进行美化 Alapha1继续改进 连续两周的持续改进 11 Alapha2版本发布 测试 继续测试软件的bug 12 Alapha2版本的改进 13 Beta版本的发布 修改需求说明书 查看和需求说明书的不同之处 14 补缺补漏 根据需求说明书补缺补漏 15 Beta1版本发布 用户初体验 测试软件的bug 16 软件上线 发布产品 -
我的效益
促进团队的沟通
督促团队的进度
给队员嘘寒问暖，端茶倒水