• 软件评测(腾讯即时通信IM)


    这个作业属于哪个课程 2020春|S班 (福州大学)
    这个作业要求在哪里 个人作业————软件评测
    这个作业的目标 1.腾讯即时通信IM demo案例分析
    2.构思产品并采访调研
    3.分析和规划产品
    作业正文 https://www.cnblogs.com/GaogaoBlog/p/12738782.html
    其他参考文献 腾讯计时通信IM
    邹欣老师的博客
    1.估计方法
    2.用户调研
    3.用户体验

    目录

    一.腾讯即时通信IM demo使用

    • web端
    • 小程序端
    • ios端

    二.腾讯即时通信IM demo评测

    1. bug:群名片
    • 描述:群名片修改后不能在对话中体现,在群聊天中,成员显示的是账号或昵称。修改的群名片只在 1)群名片设置 2)群成员 两处有体现。
    • 未发现原因:修改群名片后,只简单地查看群资料,确认信息修改成功,忽略了群名片在群内对话时的应用。
    1. bug:群消息提示类型
    • 描述:在群消息提示类型中设置接收消息但不提示后,仍然有气泡消息提示。
    • 未发现原因:忽略了这一功能。(不然这是什么憨憨bug)
    1. bug:管理群成员
    • 描述:ios端中,点击管理-删除成员后,跳转到删除联系人页面。只有当管理员添加待删除成员为联系人后才能删除该成员。
    • 未发现原因:开发时接口的设计不完善,似乎是复用了联系人管理的模块。
    1. bug:邀请群成员
    • 描述:这个功能似乎形同虚设,不论是群主还是管理员都无法主动添加群成员,并提示权限问题。
    • 未发现原因:功能等待进一步的开发或已废弃。

    三.产品构思

    1. 产品功能

     书友群聊以书籍为单位,用户搜索书名通过简单验证即可进入交流群,可以选择匿名或昵称。可以在群内结识书友,加为好友。

    1. 目标人群————网络文学爱好者

     这一群体的特点是阅读速度,阅读感受,阅读的书籍特别是阅读方式都更新得极快,因此读者都较为分散。但是目前的文学网站读者的交流大多止于评论区,及时性不强且不够便捷,也不能满足大部分读者的需要。
     松散的群聊和好友制度,以及马甲制度,让产品从单一的社交功能中脱离出来,集中于对内容的讨论,用户们可以畅所欲言。

    四.采访

    1. 采访对象情况

     初中学生,文学爱好者,涉猎广泛。学业之余,常以电子书方式阅读。课余时间不多,但又希望自己的爱好不只是自娱自乐,想要与同好交流。

    1. 照片

     采访对象他害羞

    1. 使用情况

     下载了ios端企业内测版,简易注册后即登陆使用。

    1. 采访

     Q:你对腾讯即时通信IM的第一印象如何?

     A:界面还挺简洁大方的。第一次做这样的产品试用,很新奇。

     Q:你认为腾讯即时通信IM有什么功能是适合产品的呢?或者说让产品体验更好。

     A:emmm黑名单吧。我听你的介绍说这个产品是可以直接向对方发起对话的,黑名单功能可以避免一些不必要的冲突。(笑)毕竟这个也不是拿来吵架的。

     Q:我倒是没想到这个。看来这方面还可以设计一番。还有吗?

     A:emm还有这个这个是可以直接发送文档,还挺好。

     Q:那你认为这个腾讯即时通信IM有什么可以改进的地方吗?

     A:头像头像!每个人都长着一个头像,居然还只能改成随机的头像,这个一定要改改。

     Q:还有吗?软件在数据量/界面/功能/准确度上各有什么优缺点?

     A:这个我也说不上来。

     Q:那你对于我想开发的这个产品有什么意见吗?

     A:还挺有意思的。不过这么多书,你准备怎么建群?管得过来吗?

     Q:(会心一击)这个都是后话了。那你认为这个腾讯即时通信IM可以用在我的产品里吗?

     A:要是能改改这些有的没的,还是可以的。

    1. 结论————推荐

    五.分析

    • 估计6人毕业生团队大概需要18到20周的时间完成。
    • 腾讯云相比网易云信等在即时通信软件方面有大量用户群体,可以说在国内的即时通信方面是首屈一指,更易获得用户的青睐。
    • 这个SDK还是存在较多bug,团队应在测试维护方面多下心思。由于开发团队人员不多,为了更好的改进,发布初期可以开设bug投诉通道,根据用户的反馈及时完善。

    六.产品建议和规划

    1. 类似产品

     各类文学网站,豆瓣,百度贴吧等。

    1. NABCD模型
    • Need 需求
      目标人群是网络文学的爱好者。这一群体的特点是阅读速度,阅读感受,阅读的书籍特别是阅读方式都更新得极快,甚至阅读的时期也不同。因此读者都较为分散。比如同一本书,有的读者是在网站A阅读,有的读者是在电子书上阅读。但目前的文学网站读者的交流大多止于评论区,及时性不强且不够便捷,也不能满足大部分读者的需要。

    • Approach 做法
       针对大量的网文读者,符合网络文学快节奏,阅读爱好私人化的特点。让用户在一个群组内,以阅读的书籍为一个单位展开讨论。
       根据用户的个人意愿选择是否结交书友,或者屏蔽恶意用户。由于匿名特性,可能会出现一些恶劣用户,考虑采用一些举报机制来限制用户行为。
       轻量级,快节奏,个性化是软件的特点。

    • Benefit 好处
       满足网络文学爱好者的交流需要,创建一个积极和谐的同好交流环境。

    • Competitors 竞争
       相对于资历深的文学网站,还有各类论坛,产品还需要做出努力吸引用户。但产品针对性强,定位新颖是吸引用户的一大亮点。

    • Delivery 推广
       可以在目标群体大量活跃的论坛,贴吧,微博等平台进行推广。

    1. 我的领导取向

     如果由我来领导团队,我会在前期的需求分析以及用户调研上多下一些功夫,同时产品推广也很重要。

     由于这个产品量级较轻,实现的时间可能不会很长,那么在工作开始前期,我会希望更多的团队成员都尽可能多的参与到用户体验中来,致力于开发更人性化的产品。

     在开展工作前,先设计一个开发周期计划的安排表,随具体进度适时地调整,务必按时按质交付。

     在工作周期中,团队成员应每周汇报工作进度,一方面是促进开发的进程,一方面也可以更好地协调多方合作。

    1. 人员分派(5人)

     3人产品及测试,1人后端,1人前端和美工

    1. 16周安排
    时间 计划
    第1-4周 进行需求分析市场调研并完成原型设计
    第3-4周 系统结构设计及数据库设计
    第5-8周 前后端合作基本实现项目功能,测试与开发同步进行
    第9-10周 项目1.0测试,并完善项目
    第11周 初期推广,寻找真实用户测试,收集项目存在的问题
    第12-14周 根据用户的反馈改进项目,完成项目的最终版本
    第15周 编写使用说明书,发布项目
    第15-16周 项目推广,文档修订
    1. 项目部署

     服务器:一个动态,一个静态,8核32G
     带宽:100M级别
     关系型数据库:3台(读写分离2,备份1)
     缓存数据库:2台
     网站安全性:WAF、DDOS

  • 相关阅读:
    lda spark 代码官方文档
    4.17 斐波那契数列 K维斐波那契数列 矩阵乘法 构造
    CF R 635 div1 C Kaavi and Magic Spell 区间dp
    CF R 635 div2 1337D Xenia and Colorful Gems 贪心 二分 双指针
    luogu P5043 【模板】树同构 hash 最小表示法
    CF R 633 div 1 1338 C. Perfect Triples 打表找规律
    CF 633 div1 1338 B. Edge Weight Assignment 构造
    4.15 省选模拟赛 哈密顿回路 折半搜索 双指针
    4.15 省选模拟赛 编码 trie树 前缀和优化建图 2-sat
    4.13 省选模拟赛 守卫 点分治 虚树
  • 原文地址:https://www.cnblogs.com/GaogaoBlog/p/12738782.html
Copyright © 2020-2023  润新知