K米评测

调研，评测

1）评测

体验：

• 流畅度不足。

• 遥控按钮太过偏右，对大屏手机用户不够友好。

• ui风格不统一，矩形，圆角矩形，圆形混用，圆角矩形的圆角半径也不相同。
  
  
  
  
  
  

• 状态栏不是沉浸式的，观感较差，特别是白色正面的手机，中间出现一条黑色条很丑。

• 有几个图标错位了，明显太过靠近右侧，与上一个页面同样功能按键位置不同，甚至同一个页面应该在同一列的按键都错位了。（设置页面）
  
  
  
  

• 个人主页页面点开资料编辑页面，往下滑东的时候即使昵称没有离开当前页面也会在顶部显示，这样就会在同一个页面的顶部出现两个名字，而且，一个是黑色的一个是白色的。
  
  

• 各个界面切换非常生硬，而且主页面（k歌）页首和其他页面的页首是不一样的，切换的时候没有任何动画只是单纯的切换显得非常突兀。

• 遥控页面设计思路就是把传统遥控器搬到手机上，看似没有问题，但是网络等问题，导致多按，灯光音效等也没有状态提示，体验非常差劲，还不如使用包厢内的遥控

• 切换页面或者切出软件之后有可能会断开与包厢的连接，即使该软件的后台并没有被杀掉，而且没有快速的重新加入包厢的窗口，就要又扫一遍二维码。导致想要当遥控就要一直停留在这个软件上，耗电，手机使用不便。

bug：

• 发送弹幕时如果输入的是软件自带的emoji可以成功发送，但是如果使用的是输入法自带的的emoji会产生错误数据，即可以成功发送但是发轻松地表情并不会显示。
• 开发人员没有修改的原因有如下可能：1，测试的输入法没有包含我使用的讯飞。2，测试人员默认了用户不会使用输入法自带的emoji表情。
• 用户发的图片无论原本是什么形状什么比例全部都会被拉伸成同一个形状（正方形），导致图片严重失真。
• 开发人员没有修改的原因有如下可能：
• 默认用户发的图片多为接近正方形的表情
• 多种比例的图片大小不好确定优化不方便

2）采访

该没有用过类似软件，除了现有功能队其他功能没有需求。用户的评价如下：

• 选歌方便，歌的资源很多，挺便利的。

• 直播的页面经常卡顿，不是非常的流畅，除此之外直播的功能还是不错的。

用户使用过程中，用户问题解决了。

• 界面上暂时没发现缺点，布局也比较合理。
• 主要功能"k歌"功能上比较完善，特别是加入的直播功能，可以让没办法参与的朋友也加入进来，还能与陌生人分享k歌的乐趣。
• 准确度上看，手机控制反应非常慢，容易按过头，音效改变上也只有图标没有文字说明，不知所云。
• 上传歌曲后不会自动寻找匹配的歌词，也不能上传歌词。而且可以上传曲库内存在的歌曲而不会自动跳转或者提示用户。

改进建议是：

• 在控制上加入切换确认，在多段切换比如配乐声音大小直接用滑块或者数字更改。
• 优化直播功能，尽量优先满足视频的流畅程度。
• 加入上传歌曲自动查找自动匹配功能或者加入歌词上传，防止用户上传曲库中存在的歌曲但是不会显示歌词

综上，对于这软件，我的评论是，一般。

分析

模块

重要程度越高，数字越大

评分

• 用户体验：75/100

• UI美观程度:63/100

• 核心功能：78/100

建议和规划

• 如果你是项目经理，如何提高从而在竞争中胜出？

  首要的是增加更多的而合作商户

• 你要设计什么样的功能？

  K歌（控制台，点播器），调音器，

• 为何要做这个功能，而不是其他功能？

  K歌：便利用户使用
  
  调音器，为声音有不足的用户提升体验，如自动升降调

• 为什么用户会用你的产品/功能？

  让用户便利地K歌。

• 你的创新在哪里？可以用 NABCD 分析。

  N:有的用户高音上不去低音下不来
  
  A:提供算法添加调音功能并且由手机控制调音取向
  
  B:一个app可以完成点歌台的操作，方便使用，还可以便利歌唱的一般的用户。
  
  C:现在类似app几乎没有，没有大的竞争
  
  D:与尽可能多的ktv商家合作，收集反馈。

• 如果你的团队有5个人, 4个月的时间，你作为项目经理，应该如何配置角色（开发，测试，美工等等）？

  前3个月3开发1测试1美工，第4个月3开发2测试。

• 描述你的团队在16 周期间每周都要做什么，才能在第16周如期发布软件，大小里程碑绩点设定。

时间(第X周）	任务
1	需求分析，完成需求分析文档，确认原型，编写需求规格说明书
2	修改需求规格说明书，确认编码规范
3	制定开发计划,确认开发架构
4	部署开发环境，确认开发架构，进行ui设计
5	编码，阶段测试
6	编码，阶段测试
7	编码，阶段测试
8	内部测试
9	alpha测试
10	修改bug，必要时修改需求
11	修改bug，必要时修改需求
12	修改bug，必要时修改需求
13	beta测试
14	修改bug，必要时修改需求
15	整体功能测试，最终完成需求规格说明书
16	部署，发布产品