K米评测
关于K米的案例分析
第一部分 调研,评测
评测
-
第一次上手体验
首先,很遗憾的表示我没有接触过类似的软件,对于这类软件是一无所知。 接下来说说对他的第一印象吧,第一眼看到它的图标觉得不错,简洁明了,让人一眼就知道这个是K米软件。 然后,打开软件看看吧,跳到的是主页面,KTV点歌,让人顿时明白原来这个是KTV点歌的,只要扫描包厢上面的二维码就可以进行点歌功能。那么再看看别的页面吧,把每个页面都打开看看,发现每个页面的主要功能都是一眼就抓住人们的眼球,让人能够很快的知道这些页面都是用来做什么的。
-
大家一起找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里面唱歌的时候,可以使用手机遥控,进行点歌等功能。
- 用户体验:
- KT V的遥控功能不错,人手一台遥控。
- 直播可以邀请远方的朋友一起加入。
- 用户意见:
- 陌生人可以随意进入包厢,不喜欢这个功能,希望可以设置密码等。
- 扫描二维码等待成功,需要的时间太久了,在信号不好的时候,扫描不出来。
- 直播时候K米不能放在后台,一不小心就会自动退出。
- 社交圈好像都是陌生人,不会判断,可能认识的人。
- 结论:K米虽然可以在KTV里面使用,但是很多功能都还不够完善,界面方面也不够美观,加上我对这个软件的测评体验,我是不推荐这个软件,对于不常去KTV的人来说,这个软件根本没有什么用处。用户人群太局限。
- 用户反馈:
最喜欢什么功能?
手机遥控功能,可以掌控灯光,音效,点歌,切歌的感觉不赖。
会为哪些功能付费?
就目前K米提供的功能来说,会进行付费的功能可能就只有给主播送礼物这一功能。
第二部分:分析
-
工作的估计
团队6人,计算机毕业生,专业UI支持
这是我自己假定的几个可能性:
* 有过多次的项目经验
* 其中有人写过类似的K歌功能
* 编程水平普遍比一般人要高(大佬级别)
根据以上的假定,可以总结出,要想写出K米这个程度的项目,要花费的时间应该是比较久的,6个人应该是可以直接上手编码的,以下是我估计的时间:
功能 时间/天
需求分析 1
分工安排 0.5
KTV点歌 5
各类排行榜 2
附近动态 1.5
附近人 1.5
交友 1.5
KTV预订 1
系统设置 1
搜索功能 1
UI设计 2
合计 18
看完这个时间估计,自己都觉得可怕,开发一款软件好像被我想的太简单了,好吧,这可能是我脑中对大佬的印象吧,高不可及。 -
软件的优劣
优势
查找了一下手机里的应用商店,发现关于唱歌的软件更多的是全民K歌这种的手机版现场KTV直播,而K米是更适合在KTV包厢里面使用手机就可以进行的各种点歌功能。
劣势
核心功能要在KTV里面实现,线下根本没有什么用处,也不能录歌等功能,使用率降低,缺少竞争力。 -
团队提高
* 功能的完善:有些功能有显示在页面上,但是无法使用
* 软件测试:感觉测试不够,导致不同手机出现各种各样停止运行的错误。
* 注重细节上面的实现
* 提高用户体验 -
功能逻辑框图
-
模块分析
模块 重要度 完成度 出发点 效果
K歌 非常重要 85% 与KTV合作,与点歌台功能类似 连接过慢,网络配置要求高,用户体验一般
附近 重要 90% 增加社交功能,吸引用户 社交功能不错
聊天 非常重要 80 增加社交功能,吸引用户 界面混乱,聊天内容有限制,用户体验差
发现 重要 98% 增加社交功能,吸引用户 社交功能不错
遥控 非常重要 90% 满足KTV懒癌患者,使用手机就可以进行各种操作 按钮不灵敏,视频不可录制
个人主页 较为重要 100% 用户管理 一般 -
多维度评价
要对一个产品进行评价的话,首先,要确定从哪个角度出发,这次我是站在用户的角度出发来评价的。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上安排广告宣传
- 在电视节目里面植入广告。
- N(Need)
-
工作安排
- 任务分工
人数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 软件上线 发布产品
- 任务分工
-
我的效益
* 促进团队的沟通
* 督促团队的进度
* 给队员嘘寒问暖,端茶倒水