关于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 软件上线 发布产品 我的效益
促进团队的沟通
督促团队的进度
给队员嘘寒问暖，端茶倒水
扫一扫
470
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
