关于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里面唱歌的时候，可以使用手机遥控，进行点歌等功能。
• 用户体验：
  • KT V的遥控功能不错，人手一台遥控。
  • 直播可以邀请远方的朋友一起加入。
• 用户意见：
  • 陌生人可以随意进入包厢，不喜欢这个功能，希望可以设置密码等。
  • 扫描二维码等待成功，需要的时间太久了，在信号不好的时候，扫描不出来。
  • 直播时候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 软件上线 发布产品
• 我的效益
  * 促进团队的沟通
  * 督促团队的进度
  * 给队员嘘寒问暖，端茶倒水