个人作业——软件评测

这个作业属于哪个课程	软件工程
这个作业要求在哪里	个人作业——软件测评
这个作业的目标	评测分析腾讯即时通信IM，采访潜在用户，对于即时通信SDK的建议和规划
作业正文	....
其他参考文献	....

---

一、调研评测

1.1 评测

针对本次作业我使用了ios端、web端还有微信小程序版本的Demo，同时为了测试的完整性和全面性，我邀请了一位朋友安装了Android端的Demo，这样可以在我们的对话使用上发现一些Bug并且可以得到安卓端Demo的一些功能问题。

1. 使用中

• ios端Demo

  

• web端Demo

  

  

• 微信小程序Demo

  

• Android端Demo

  

---

2. 功能性bug

（1）通讯录好友单向延迟

用户A添加用户B的时候若请求通过，正常情况下这样的双向好友申请个人信息是会出现在彼此的通讯录中，而在测试过程中发现，添加好友成功以后被添加的好友的通讯录中是不会存在发起添加好友请求的好友信息。当用户B重新搜索用户A添加的时候出现A的信息界面，与已经成为好友的情况的界面一样，只有音频通话按钮和发送消息按钮，并无添加按钮，证明A与B已成为好友。但是B的通讯录里却无A。

如下图，我在17:16分的时候添加了使用安卓Demo的朋友，在我的iosDemo通讯录中有显示我的朋友（越），而在安卓Demo上包括微信小程序和App端在通讯录里都不存在用户A（我）。

而在十分钟之后17:26，安卓的Demo通讯录里才出现了十分钟前加的好友（用户A）。证明被添加的好友消息同步延迟。

（2）群消息滞后

当安卓Demo用户注册后就被拉入云通信IM技术交流群3，在我的iosDemo中可以看到安卓用户的进群通知，而在安卓端却没有进群的提示，即消息栏并未出现该群的消息。直到五分钟才显示了进群的消息。因为当时没有反应过来做截图的证据，所以这里无截图。

（3）消息已读延迟

app端的Demo都具有消息已读和未读的功能，正常情况下在用户A给用户B成功发送消息后，在消息的角标显示“未读”，当用户B点开对话框后“未读”变成“已读”，所以若用户B回复消息，则用户A消息旁的”未读“一定变成“已读”。但是在测试的过程中发现，当我发消息给我的朋友（越）时且得到了回复，“未读”仍未改变。在过了一段时间之后，“未读”才变成“已读”。

（4）不同平台功能不同步

• app端不支持视频通话

正常情况下同一用户的聊天工具在微信小程序或是App端都是同步的，即消息同步、通讯录同步等。并且之间可以相互通信。在测试过程中发现视频通话只可以是小程序对小程序，在app端的话会显示[不支持的自定义消息]。同一软件不同平台功能不匹配的问题是比较严重的，无法保证对话双方的软件使用途径，所以很容易错失一些重要的信息，而且在发生不支持自定义消息的情况下，对话双方的设备上都没有显示具体的原因，拨打视频的一方仍可以通话等待，只是会一直没有应答。

• 小程序端不支持修改备注和添加好友

如图所示，SMG_YUE是原用户ID，“越”是我在app端设置的备注。备注是标识分辨一个人的重要依据，小程序不支持修改备注的话会导致聊天的盲目性，难以确定聊天对象。这个添加好友作为必备功能，如果小程序不支持的话就会基本阻隔用户的选择。

（5）ios端app消息不提醒（安卓端app随机提醒）

安卓端经过测试，提醒随机，即有的时候会提醒，有的时候不会。开启了声音提醒之后，在接受到消息之后并无声音提醒和消息栏通知。只有在点开app消息列表之后才可以看到消息未读的小红点。而通过对安卓app端的测试发现，在安卓系统中是有提示的。这个功能性bug也是比较严重的一个，没有消息提醒大大降低了平时的沟通效率，也就基本丧失了即时通信软件的意义。即时通信要求实时的接收发送消息，不提醒就会导致信息的忽略和慢反馈，对于一些紧急的消息来说，这个bug影响较大。

（6）好友信息延迟

用户换头像后，其好友不能在通讯录或聊天界面发现该用户头像发生改变。

15:13用户SMG_YUE更换头像，在我这端是看不见的。可能过了十几分钟在我的界面才看到其头像改变。

---

3.预测原因

其中添加好友通讯录单向延迟、群消息延迟和已读消息延迟的原因可能都是网络延迟的原因，也有可能是系统内部的运算机制效率比较低的原因。当使用的用户数量巨大的时候，系统为了同步对话双方的消息和状态都需要大量的数据缓存机制，然后经过对比和不断的更新，实时显示消息的已读未读状况。假设该Demo的用户有10万人，如果做一张中间表保存用户是否对这些消息已读未读的话，就会变成每人只要接收到一条信息中间表立马产生10万条记录。发送的消息越多中间表记录成倍数增长。所以未读已读情况反馈到系统时就已经浪费了较长时间，所以产生延迟现象。

至于ios端的消息不提示bug，可能是ios系统迭代更新太快的原因？好吧我不知道。

1.2 采访

一、产品

​ 我想做一款具有模拟对话和资源汇总功能的即时聊天app。

以下所说的目标用户“追星族”指的不是狂热不顾一切的无脑粉丝形象，而是一群希望与偶像共同进步，产生灵魂上的共鸣，由此被激励的粉丝，是正能量的影响作用。

（1）主要功能

1. 具有即时聊天的所有基本功能

   可以添加好友，与现实中或者网络上的真人进行对话。支持群聊、视频语音通话、收发红包、个人账户钱包等功能。

2. 模拟对话

   可以设定你希望的对话对象。在产品中存有大部分的艺人的资料和图片，当用户选择已有艺人的信息时，可以变成一对一的模拟聊天。系统会根据艺人的爱好习惯来模拟与用户的对话，在聊天框中的功能选取还有此艺人的语音包，例如点击“唱歌”，系统则会随机搜索该艺人的主唱歌曲并发布对话，用户可点击收听。若艺人并无演唱歌曲则对话框中不具备该选项。当系统搜索到已被用户添加的艺人有新歌发布或者活动行程就会自动向用户发起对话通知用户。也可以设置成自己生活中认识的人，或者是已经离自己远去的家人朋友，这种情况需要填写这些人的信息（不是身份证号这类的重要保密信息），比如爱好习惯和口头禅，系统会进行分析从而尽量的进行模仿对话。

3. 资源动态

   该产品具有汇集被添加艺人资源的功能。将一个资源广场分为五个部分：单曲专区、影视剧专区、版权专区、综艺专区、动态专区。除了版权专区和动态专区每个专区都汇总了该艺人的大部分作品，汇集在一起方便“追星族”的阅览。版权专区存放一些我们平台所获取不到版权的艺人的作品的链接合集，通过链接用户可以很快速的进入另一个平台进行观看。动态专区汇集了艺人各个平台所发布的动态，例如微博、绿洲、instagram等。多数平台搞的用户手忙脚乱，汇总在一起就更加方便查看。

（二）面向用户

• who

  追星一族、有想要对话的离自己远去的想念的家人朋友的人、普通用户（只进行与朋友的即时聊天的人）

• when

  1. 对于追星一族来说，每天基本都是要登录该产品进行浏览的，除了吃饭睡觉可以说是无时无刻。

  2. 对于有“遗憾想念”的人来说，在夜深人静的时候，思绪最烦扰伤心的时候就是使用该产品最频繁时间。

  3. 普通用户在空闲的时候都有可能使用，也可以在工作学习中向同事同学发起讨论对话。

• where

  用户可以在任何地方使用该产品，只要想发起聊天的时候都可以。

• what

  我的产品是具有模拟对话和资源汇总功能的即时聊天app。

  用户的期待就是方便自己的追星之旅、得到对于人为遗憾的慰藉、简洁专注的即时聊天体验。

• why

  我的产品在市面上还并未发现类似的竞品。

  1. 对于追星族来说，在最快的时间内获取偶像的资源是比较重要的，而艺人的所有资源作品都是分散在不同平台的，这样的集体整合大大节约了时间提高了效率。并且模拟与自己的偶像聊天可以让自己获得从偶像那里来的正能量，拉近了彼此之间的距离，得到对于追星族来说最大的愉悦。
  2. 对于抱有遗憾的人来说，这里就是抚平伤口的疗愈基地，可能是有一句话曾经没有说出口，是离开才懂得珍惜的苦，还有可能是对于已逝之人的留恋，在这里可以得到心理上的慰藉。
  3. 对于不怎么喜欢看朋友圈也不喜欢发动态的人来说，该产品就是世外桃源，简洁的界面功能方便操作也不会被那些逼着你给他们点赞的人所“胁迫”，更不用为了完成老板发布的任务去发布违心的宣传动态。

• how

  用户就是正常注册登录使用，支持手机号验证码登录和邮箱登录。之后可以选择添加好友或者模拟对象，然后展开聊天。资源广场也是一键直达，容易上手。

（三）NABCD分析

1. Need

一、对产品功能性的需求

1. 即时聊天的基本功能（直接沿用腾讯SDK）
2. 一个智能的对话系统，可以大数据分析被模仿者的说话方式性格习惯
3. 资源整合功能，可以将不同平台的同种资源放在一起
4. 自动搜索同步推送功能，针对某位艺人的实时活动进行更新，推送给订阅用户

二、对产品开发过程的需求

1. 与网络信息接轨，例如使用爬虫等程序
2. 大数据分析
3. 人工智能话的对话系统（适当考虑语音交互和语音合成）
4. 数据库的用户信息存储和艺人的相关信息存储，也可再有添加新模拟对象的信息的数据表

三、非功能性需求（服务质量需求）

1. 实时更新资源保证用户的信息获取速度
2. 界面的通用性，容易操作
3. 避免即时聊天的发送接收延迟
4. 模拟聊天内容的合理性

四、综合需求

1. 聊天版块
2. 资源板块
3. 个人信息版块

五、利益相关者的需求

​ 用户：

1. 资源更新的实时性
2. 产品使用起来快捷方便容易上手
3. 界面美观简洁
4. 模拟聊天的真实感

2. Approach

一、微博等资源较多的平台的使用体验

二、身边追星族的需求整合

三、对生活中潜在用户的发现和调研

3. Benefit

一、模拟聊天的新鲜感和愉悦感

二、不用担心人际关系的紧张感（发不自愿的动态或者进行不自愿的投票点赞）

三、资源大杂烩的方便性

4. Competitors

一、相对于竞品的优势

1. 模拟聊天智能化
2. 可以由模拟偶像一对一推送自己的作品
3. 不存在动态点赞欢迎程度的虚荣对比感
4. 没有已读未读功能，以免使得不爱回信息之人尴尬，聊天就更自如
5. 被添加艺人的各类资源条理整齐归类，节省了来回切换各种app的时间
6. 心灵上的安慰是别的产品给不了的

二、界面特点

1. 大众化的界面，即导航栏加内容框加底部切换按钮，更容易操作，功能位置刚开始上手也能大致了解
2. 白黑两种主体颜色可选，主打简约小清新风格
3. 内容框中可由底部切换按钮切换为资源广场、聊天、通讯录和我的信息。
4. 通讯录中在顶部会显示“我的偶像”、“我的XX“按钮，点击即可进入模拟好友列表，群聊和黑名单也在顶部显示。通讯录中部就是正常的按照好友备注首字母顺序排列的好友列表。

5. Delivery

​ 采用网站推广的形式，多在类似微博、instagram、网易云音乐等汇集了目标用户的地方购买广告位。也可以采用身边人推荐的方法，试用推广。

---

二、采访

此次采访使用深入面谈的用户调研方法，因为是疫情期间，所以将面谈改成了电话的详谈。

Q: 介绍采访对象的背景和需求

姓名	性别	学历	年龄	目标用户种类	需求
赵某	女	现大学第三年在读	21	有喜欢艺人的普通用户	汇集各大平台的艺人资源的App

Q: 让采访对象使用10-30分钟体验腾讯即时通信的demo

Q: 描述用户使用这个demo的过程, 用户的问题解决了么？

用户根据我提供的二维码下载了安卓app端的Demo和微信小程序端的Demo，并注册登录，加我为好友，与我进行平日的聊天测试。这个Demo还是普通的即时聊天软件，对于这样的功能，用户是不存在什么问题的。因为平日里的QQ、微信就已经足够满足用户的聊天需求了。

Q: 软件在数据量/界面/功能/准确度上各有什么优缺点？用户体验方面有问题么？

	优点	缺点
数据量	暂无	暂无
界面	简约	缺少基本功能的设置界面
功能	没有朋友圈的功能，可以专注聊天，比较高效；通讯录设置界面一目了然	app和微信小程序端消息不同步，容易耽误较紧急的事；缺少消息提醒的不同模式（震动和响铃）；没有群聊的介绍和单独消息提醒设置
准确度	暂无	暂无

用户体验方面的问题：微信小程序端每次重新进入都需要登录，导致时间的浪费，比较繁琐。聊天内容消息提醒不及时，影响沟通效率。

Q: 介绍你想用这个SDK开发怎样的产品？

在之前的产品分析中我已经做了描述，并将此口述给了我的用户。

Q: 用户对腾讯即时通信的功能有什么改进意见？

1. 安卓端的“我”设置增加消息提示、个人资料设置等和ios端一样的功能

   在采访之前我一直都是使用的ios端的Demo，所以不清楚安卓端的功能不一样的问题。如图：

   ios端的“我”设置界面：点击“我”——>“用户A”——>“个人信息”界面可以有这些功能：

   

   Android端的“我”界面

   安卓端只有这一个设置界面，并不能像ios一样设置自己的生日、性别、所在地。并且没有消息提醒的设置方法。

   

2. 增加群聊和好友信息的消息提示的分类

3. 头像换成可自定义的

4. 聊天增加添加保存表情的功能

5. 去掉已读未读功能

6. 解决微信小程序和App端信息、语音、视频不同步的问题

Q: 用户对你想开发的产品有哪些意见？

1. 增加投票打榜的专区，可以集合所有艺人有关作品的投票的链接。
2. 在艺人的作品下面增加该作品创作时不为人知的部分例如音乐的背后小故事，或者是初衷和原因。
3. 增加“时间点滴”版块，里面主要放置艺人所说过的一些富有哲理正能量可以激励到别人的话还有一些做过的暖心事件。
4. 在后期可以以偶像名义在软件上发起响应号召粉丝们加入公益活动，为社会做出贡献。

---

三、 结论

对于腾讯即时通信我的评价是一般。有好有坏吧。主要就是以上提到的bug都改完应该会好很多。

---

二、分析

1.工作估计

Q: 使用腾讯即时通信的所有功能，联系第二部分的分析，估计这个SDK做到这个程度大约需要多少时间？（团队人数大约6人左右，计算机大学毕业生）

​ 估计要三个月的时间。（参考后面的题目：五个人四个月）

2.分析优劣

和腾讯IM大致功能相似的还有腾讯，网易，环信，容能云等。

(1) 容能云

容能云是厦门容能科技有限公司开发的一款云通讯Paas服务平台。容能云即时通讯云服务SDK有通话服务、短信、流量、红包、IM服务、音视频、直播、用户托管、反垃圾、数据统计这些功能，直接接入一键解决问题。容能云的IM即时通信具有丰富的消息类型、完善的群组管理、资料关系链管理、优质的消息推送服务、信息托管服务、音视频红包集成，让APP快速拥有各种即时通讯能力。

对比：下载了容能云的Demo想为对比做试用，但是在手机号注册的时候出现了一些问题，如图：

所以我进入官网浏览了一下已有账号的界面显示，如图：

• 腾讯缺点

  相对于容能云而言，腾讯IM的即时通讯功能就较为精简。只看界面的话，腾讯云的界面就稍有逊色，容能云的排版布局和颜色都比较清新简洁，使用者的第一印象就比较好。在音视频方面容能云支持点对点视频/一对多视频/多方视频会议，对平台跨终端支持，而腾讯IM在app端并不支持视频通话，这点与腾讯IM相比更加完善健全。腾讯IM没有红包即没有用户账户的钱包功能，需要靠后期编程接入再去实现。腾讯IM在消息推送在ios端并无提示，这也就是之前的bug展示。容能云比腾讯云多了一个能力中心板块，可以支持视频会议和直播等热门功能，而腾讯云的功能较少，只专注于消息的互通。

• 腾讯优势

  如果这么一对比的话可能腾讯确实处于下风，不过对于黑名单这个功能，腾讯云是有涉及到的，并且放在了通讯录的位置，用户体验感较好，可以随时查看黑名单部分。因为有的时候拉黑一个人往往找不到查看的位置，想要再把他“放出来”就有些困难。如果说对比SDK代码部分的健壮性，那可能有的一比，只不过我这里只测试了现有的Demo部分，所以只从这个直观呈现上来对比。

(2) 网易云信

我去官网上找了一下Demo ios版，但是得到了客服拒绝的消息：

退一步，我就去使用了小程序版本的，还好可以免费使用。网易云信功能也比腾讯要多，是我对比了这三种Demo用户体验感最好的一个。

• 腾讯缺点

  网易云信有讨论组和高级群的划分，并且也具备前面腾讯与容能云对比的黑名单优势，界面也很好看简约鲜明。并且还具备我的电脑功能，这对于上班上学的人来说是非常重要的功能，从手机传输数据到电脑是很方便的。腾讯的小程序并没有添加好友的功能，更不用说创建群组的功能和搜索群的功能。网易云信可以显示通讯录的好友状态，是锦上添花的功能，而腾讯并不能查看好友状态。最值得夸赞的是网易云信的随心所欲更换头像的功能，腾讯是不能更换自定义的头像的，而小程序连换头像都不行。网易云信的个人信息也有很多项，在查看好友信息的时候也会很明确。

• 腾讯优势

  网易云信的小程序端是没有消息未读已读功能的，消息的旁边不会显示接收信息。腾讯有已读未读显示，但这个功能还是处于争议的部分，因为总有大部分人不太希望别人知道自己已读不回的坏习惯。

3. 提高部分

1. 界面优化

界面决定了用户对于该软件的第一印象，相当于整个软件的门面。可能界面总是被程序员们忽视，觉得界面只是一些技术不行的人所做的边角料，顶多作为锦上添花而不是雪中送炭。但是我认为，界面虽然不如后端逻辑设计一样重要但也是不可或缺的。如果有一个软件的界面做的不好，大多数人往往会选择另一个功能相似的产品，而这时候后端的处理功能再怎么强大也不重要了。好的用户体验感就来自于清新整洁的界面，让人有舒适的感觉，从而延长对于软件的使用时间。就好比很多人总喜欢买一些好看而没有实际作用的东西来实现心里的愉悦。

在前面我对比了两个与腾讯即时通信相似的Demo，体验感都胜过腾讯。而导致我更喜欢更愿意把测试的时间花在另外两个“配角”的身上。不怎么吸引人的界面加上略有些卡顿延迟的bug那真的算是事故现场了。

具体建议：除非有着过人的设计天赋，界面还是设计成用户都熟悉的排版布局比较好。一是用户熟知容易上手，二是避免五花八门喧宾夺主。常见的app布局即为导航栏+内容框+底部选卡。在规则的布局中加一点独特的“小巧思”，例如导航栏选卡的图标，可以根据不同的软件风格来设计。颜色方面切忌跳色和多色，最好带有主题颜色，像腾讯这样的默认颜色白灰是不可取的。界面上的按钮可以设计成动画的形式，即按照用户的实际操作手势来制定相应的图标变化，是最简单的智能化。

2. 功能种类

功能的实现是不必过多强调的部分，因为每个项目的开发过程已经被突出惯了。所以功能的种类选取是需要提高的部分。功能不是越多越好，一个软件的功能都是依附于这个软件。而不常使用到的功能往往浪费了很多的资源和时间。例如之前测试的容能云Demo，其中有一个直播的功能，但是对于主打即时通信招牌的软件，直播就不太合适。即时通信主要针对办公和拥有具体事宜的情况，是多人之间的信息交流，是有来有往的，是可以实时得到反馈的。而直播大多用于娱乐消遣的情况，是一对多的情况，基本不能得到有效的实时反馈，这与即时通信的理念背道而驰。虽说功能多比较方便全面，总有一部分人愿意去使用一些额外的功能，但这毕竟是少数，软件当然是要将自己的主打功能炼精，接着由主打功能做延伸，延伸添加功能的时候受众是不会变的，使用该软件的目的也是不改变的，所以要避免过分拓展，造成丢了西瓜捡芝麻的悲剧。

具体建议：勿忘初心，时刻提醒团队这个软件开发的本来目的是什么，做好主要的功能之后再考虑研发新功能，开始就是要把一两种功能做精，做到独树一帜金鸡独立，在同类产品中有优势的时候，有一定忠实用户的时候再可以根据用户调研收集用户想要拓展的功能，再锦上添花，开发同类产品中没有的功能，吸引更多用户。每次添加的功能种类不能贪多，一次一两种就可以了。如果在用户调研中发现某拓展功能的使用率较低的时候，即可以考虑删除，减少后期维护的经济人力时间压力。

---

三、建议和规划

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

• 提高自己介绍产品的语言表达能力
• 加大推广力度（必要时可以加大宣传投资）
• 保证产品的美观
• 多用户测评产品不卡顿无bug
• 开发亮点功能

Q: 目前市场上有什么样的产品了？

• 爱豆聊天器

  根据功能介绍与我们产品的模拟聊天功能基本符合，但是并没有其余的拓展功能，并且已经下架。

• 叨叨记账

  叨叨记账是上海自古红蓝人工智能科技有限公司一款记账软件。主打聊天记账，根据角色设置及记账场景，触发不同的对话内容。但是不具有真人即时聊天的功能。

Q: 你要设计什么样的功能？

• 模拟聊天
• 红包收发以及账户钱包
• 资源整合

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

这些功能是市面上的即时聊天产品所不具有的。如果要结合即时聊天的功能的话，扩展模拟聊天功能是比较合适的，并且针对现在市场上对于偶像追寻的需求增多，我想做一个关于整合艺人作品的功能，还可以通过一对一私聊的方式让需求用户尽快得知有关新消息。这个追星族的需求是通过我身边的朋友总结出来的。模拟自己的朋友/亲人也是为了缓解目标用户的悲伤心理。在现今生活节奏越来越快，身体健康都难以保证的情况下人们的心理健康就更容易被忽视，这些积攒的情绪需要一个发泄口，而模拟会话就是一个不打扰身边人的最优“垃圾桶”和“避风港”。

账户钱包的功能我打算是用在给艺人打榜、购买专辑的方向，但是这作为还在考虑中的拓展功能。

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

1. 界面美观
2. 市面上没有存在的竞品
3. 案例调研，集成了目标用户希望的多数功能
4. 得到快乐和安慰和清净
5. 功能关联度较高，使用方便，”一顶多“

剩下的在之前已经说的很清楚了，可以去看之前我的竞品优势分析。

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

创新：

• Need

  1. 模拟对话
  2. 资源整合

• Approach

  1. 现有多个功能完备的软件可以结合参考
  2. 身边真实案例分析

• Benefit

  可以查看上文产品分析，创新点在多个地方重复了好几遍。

• Competitors

  可以查看上文产品分析，优势在多个地方重复了好几遍。

• Delivery

  目标用户聚集地做广告位推广

Q: 如果你来领导这个团队，会有什么不一样？

​ 我作为项目经理会较少参与到实际的编码中，所以我来说说平时的统筹工作。除了项目有关的正式工作，其余方面都是比较灵活随意的。我们团队是可以畅所欲言的，不论是谁对谁或者谁对什么事情方面有一些不满和问题都可以来找我反馈解决。我们每天的任务安排计划是明确的，只要在规定时间内完成进度就可以放飞自己了。在做完某一个主要功能的时候可以一起出去聚餐（最好可以申请到公费报销），参不参与都可以。会议不会常开，就算是开会也是类似于讨论会的轻松氛围。会议的召开模式依据于事件的重要紧急程度，当是紧急且重要的事情时，项目中的每个参与者都必须到位，而其余情况不强求事件无关人员必须参与。提案类的活动会给提出建议并被采纳的人加以奖励（奖金或是小礼品），从而提高参与度和积极性。如果发生项目进度拖沓，队员懒散的情况，严惩不贷。该严肃的时候严肃，其余时间嬉笑打闹都可以。

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

​ 需求分析和软件开发准备阶段需要所有人都参与进来，将用时最小化。在正式开发阶段，一个人负责Android前端，一个人负责Android后端，一个人负责ios前端，一个人负责ios后端，一个人负责美工UI。在测试阶段，可以让负责Android和ios的人员互换，互相测试彼此的功能，负责美工的人员可以两种系统兼顾，分别测试使用。后期主要开发的四人可以对于美工的界面设计提出建议和意见，完成最后的修改完善。（如果可以的话，我们只专注于一种系统的开发，就将Android和ios同端负责人合并，即两个人负责前端，两个人负责后端。）

Q: 描述你的团队在周期为16周，每周都要做什么，才能保证在第16周如期发布软件。

第一周：用户调查

第二周：产品需求分析

第三周：原型设计

第四到五周：系统结构设计、数据库设计、接口设计

第六到十二周：前后端同步开发

第十三到十五周：测试

第十六周：发布

Q: 项目发布后，有没有考虑过项目该怎么部署才能满足需求？

应用服务器配置：4核8G x 2
后端服务器配置：8核16G x 3
关系型数据库：MySql数量：3(读写分离、备份 x 1）
缓存数据库：Redis数量 ：2（主备）
网站安全性：WAF,DDOS