个人作业——软件评测

第一部分 调研，评测

以下使用方式一方式进行该模块：

• 下载并使用demo，对使用的不同demo，每种demo至少提供两张使用过程中的截图。
• 找出至少两个比较严重的功能性bug。（说明：操作不够人性化、没考虑到用户的xx需求等并不算严重的功能性bug）
• 请使用专业的语言描述（每个bug 不少于 40字），并配图说明。
• 你觉得为什么这个产品组的人没有发现这些bug??

使用demo版本为：iOS（ipad air 3)，Android（9），win10

使用过程中截图：（由于下面的BUG展示中已经至少包含了三种平台每种两个的图片展示，这里只展示略缩图以防止内容过多冗余影响阅读）

BUG1:

​ 描述：在ipad平台上执行IM iOS版软件时界面字体颜色异常，致使软件选项字体难以辨别，触摸对应选项时保持高亮效果，但同样难以辨别。

​ 猜测产品组为什么没有发现这个Bug:现在已知手机平台上（iPhone XR）的iOS并未有此现象，显示正常。猜测产品组也许在测试iOS平台时仅仅测试了手机平台的iOS系统，并未对苹果平板产品上iOS的进行测试，导致产品并未完全兼容。

BUG2:

​ 描述：IM发送图片时，选择图片的预览界面可以看到GIF动图效果，但是发送时仅仅是静态效果图，即使点开图片也依然保持静态图片状态，点击后也依然是静态状态（无法保存图片，无法进一步确认发送图片的格式）

​

​ 猜测产品组为什么没有发现这个Bug:产品组没有完整的预测发送图片功能，在开发中默认读取所有后缀的图片，但最后发送的时候只以一种方式发送，测试时也仅仅用静态图片测试后就不再进行测试，默认所有的图片都是静态格式，但却忘了自己在写程序的时候检测了所有的图片后缀。

BUG3:

​ 描述：用户在iOS平台以游客状态登陆后，如果再重新注册新的账号时，游客状态下发送的信息和群组都会被保留，而且个人信息页面仍然保持游客信息状态。（下图中欢迎的新成员即新建的账号，两次新建账号登入后仍然有游客状态下的信息）

​ 猜测产品组为什么没有发现这个Bug:测试程序时可能先测试了注册用户的使用，再测试了游客用户的使用（也有可能收到开发顺序限制），使得两个功能的测试完全独立，并没有在连接成一个完整程序后再进行测试。在开发时将游客的信息留存在了本地，使得注册后重新登陆仍然保持游客状态，但新用户信息发送到了服务端，使得看似用户登陆了新的账号，实则是在游客用户的视角看到了注册用户以一个“其他人”的方式进入了聊天区。

BUG4:

​ 描述：iOS和安卓都允许用户添加自己为好友，并且可以正常对话。但在安卓端的好友列表如果从会话栏且到好友栏，自己仍在通讯录中，若从个人页面切到通讯录中，自己就不在通讯录中了，再重新重复上述操作，自己会在通讯录中反复出现。如果在以上操作中，通讯录中没有显示自己（aassd123lowe）的情况下，添加其他用户（aassd123love）仍然可行，但试图加自己为好友，则会报错显示已经在好友列表中，即使通讯录中并未显示自己。

​ 猜测产品组为什么没有发现这个Bug:在进行开发的时候没有考虑到用户可能会加自己好友这一种情况，所以在测试通讯录的时候的测试用例没有添加自己的账号作为用例。在正常情况，即通讯录中没有自己时，会话栏、通讯录和个人页面的切换并不会出现问题，但正是因为这一个假象，导致当通讯录有自己时，产品组没能进行测试，也就没能发现这个BUG。

BUG5：

​ 描述：在web端中不允许加好友（这部分仅输入需求未能满足），但在其他端可以添加好友，加入黑名单，并且除去以上BUG4出现的情况，通讯录和黑名单状况都可以正常显示，其他端对黑名单的操作可以同步到web端，但其他端对通讯录的操作并不能同步到web端。

​ 猜测产品组为什么没有发现这个Bug:由于web端展示好友列表的方法和其他端展示的方法不同（代码层面上），所以未能进行复用，使得三个端的产品分开测试。由于web端主页面上没有添加好友的按钮，测试时可能是直接在本地数据库进行添加后测试的，也许当时可以正常显示。但在实际使用时，这个应用未能以一个“多平台”应用进行测试，使得其他端的信息未能同步到web端。

BUG6:

​ 描述：在iOS的手机端上，注册时显示注册失败，用户名已存在，但是在开发者群中已经将该用户名拉进群中。（cinian注册失败，于是尝试使用cinian123，两次注册都失败，但是在其他账号的视角看到了这两个账号加入群中）

​ 猜测产品组为什么没有发现这个Bug:在开发这一项功能时，可能在注册流程进行到某个程度时就会进行”将用户拉进群“这一操作。产品组在测试时，默认显示”注册失败“时账号即不存在，所以也没有关注该账号的具体问题，没有再登录进行确认是否注册成功。

采访

1.构思开发的产品

产品主要功能：进行工作或者学习协作。允许用户之间进行文字、语音、视频的交流。将文件集中在产品内的云空间进行存储。可以以”黑板通告“发布公告、甘特图等方式，统筹工作或者学习进度，方便成员交流工作与学习。

产品面向的用户：在职人员、中高校学生、中高校教师。

NABCD分析：

• N（Need）：

  • 当下的工作开发已经不再是以往的线下开会-工作-阶段性会议-工作-收工的形式了。线上的交流往往更加频繁，更加有即时性，能够让一个问题在产生的瞬间就被提出，然后被大家一起讨论解决。所以线上交流解决问题的效率更高于线下开会。再加上如今线下的疫情状况严峻，线上的交流和高效率的进程管理程序更被现在的工作和学习群众所需要。

• A（Approach）：

  • 通过现成的IM的SDK进行开发。
  • 结合周边管理或教师的长辈总结工作、学习流程，抽离出模式化结合到应用中。
  • 结合现有的多端SDK进行开发，形成一个跨平台的应用。
  • 通过类似百度云的形式，开放云空间以便各个团队储存独立式的文件数据。
  • 结合现有的画图插件进行甘特图等项目管理用图的绘制。

• B（Benefit）：

  • 更加即时性的工作/学习伙伴交流。
  • 更加便捷的交流，多平台允许用户在任何时间任何地点，用任意设备进行交流。
  • 管理者更加方便进行管理。
  • 团队方便进行流程和进度控制。
  • 方便团队资源的统一整理，不必因为一个人处在多个团队中而需要自行分类处理数据。

• C（Competitors）：

  • 钉钉：现在具有较大规模的受众，功能稳定方便，但只是单纯的交流工具，仍然无法避免传统的开会-工作形式。我的产品可以打破这种形式，将团队的协同工作流程控制也结合进来，将不必要的开会-交流转换成碎片的通知和流程控制，自动提醒用户。从而实现大事开会，小事流程控制通知，用户对工作的理解和执行可以并发进行。
  • 产品相比钉钉，交流方面会更弱化。钉钉的交流系统就算是和腾讯QQ相比也毫不逊色。但是我的产品更偏向团队工作管理，团队内的交流仅仅作为其中的一个部分功能，在交流功能上的强度会稍弱一些。
  • 钉钉目前无论在大公司还是小公司都受众广泛且稳定，基本属于垄断状态，产品起步难以快速吸引用户使用。
  • 简而言之，产品是一个通过线上交流以进行团队工作流程管理的应用。其重点是工作流程管理，这也是相比竞品的优点，但工作交流仅仅是一个进行流程管理的渠道，所以他更侧重“流程管理”，而非“工作”，这也是相比竞品的缺点。

• D（Delivery）：

  • 通过协助大学内创业竞赛，推荐学生使用我们的应用而逐步推广。
  • 通过向大学辅导员和教师推荐而推广我们的应用在学习方面的应用。
  • 通过举办用我们的产品进行流程管理打卡活动，设置奖品吸引新的用户加入。

采访对象提要

采访对象的背景：

​ 小梁，21岁，武汉民族大学金融系大二生。目前由于武汉疫情无法返校，每日还要进行本地的卫生检查，生活和学习的事务十分繁琐。

采访对象的需求：

​ 由于卫生上的繁琐要求比较多，经常导致小梁的学习往往和学校学习异步，比如：老师在10：00开始上课，但是小梁由于当地要求必须在10：00接受当地卫生院的检查，虽然老师上课有录屏，但是小梁总是因为生活学习矛盾太多而无法安排正常的学习。所以小梁需要一款应用来帮助自己了解到老师的教学流程与学习任务，方便在自己有空的时候按照老师的流程一步一步完成任务。

采访提要

用户使用过程中：

1. 使用DEMO中确实有文件上传，但是文件大小的限制十分影响使用，在一定程度上能满足他想要观看录屏的需求，但文件一股脑地上传，并无法分类，十分冗杂。
2. 能够满足用户基本的需求，获得文字、语音、视频，可以进行正常的学习。
3. 在使用过程中，轻易发现了WEB的通讯录无法添加好友，每一次都只能添加临时会话。
4. 界面上认为界面足够简洁，没有繁杂的内容，单就美化层面上尚可。
5. 功能上认为除了没法加好友外，其余的功能已经能够满足他的日常需求，但他不喜欢每次建号就会被无原因的拉进群组中。
6. 体验过程总体评价良好，该用户给出3.8/5分的评价。认为现有功能仍然不足，比如：没办法在群组中搜索用户，没法添加好友，没法本地上传图片，个人界面的选择项很好，没有朋友圈等等用户需求未被DEMO满足。

产品介绍：

​ 使用这个SDK开发一个类钉钉的团体内部交流应用，能够发布学习/工作流程，根据显示安排一步一步更新。开放面向团队的云空间，以存储相应的文件、视频等内容。用户能够对流程完成确认，团队队长也能够了解到流程完成情况。具体见上NABCD分析。

用户对腾讯IM SDK的意见：

1. 通讯录要能够做到多端更新。
2. web端应该允许添加好友和添加黑名单。
3. 点进别的用户应该可以看到信息并且允许对该用户操作。
4. 如果是作为某种社交程序的话，应该开放更多的社交功能。

用户对我开发的产品的意见：

1. 开发的产品更偏向管理类产品，可以弱化社交功能。
2. 对云空间表示忧虑，随着团队的增加云空间是否够大。
3. 流程管理等能够置顶或公告，防止用户每次都需要寻找。
4. 流程确认希望有一定的时限弹性，不要固定死，能够在流程结束DDL之前任何时间确认完成。
5. 有足够的提醒，防止用户不知道流程的DDL即将到达。
6. 应用的美术风格应该保持简洁。

给腾讯IM评价：

​ 一般。腾讯IM仅能完成基础的文字、语音、视频交流，如果仅仅是这样，用简单的控制台聊天也可完成。对于用户的主要需求了解程度和程序的后续维护和测试的强度仍然有很大的提升空间，如果相比其他的即时通信SDK，在没有资金限制的情况下我更愿意推荐其他的如云信、LeanCode等，如果只是想试用、了解，我可能会考虑腾讯IM。

分析

1. 估计时间：

   考虑条件：

   1. IM产品跨平台，分为windows,微信小程序，iOS和android，无法保证毕业大学生已经熟练掌握相关开发。
   2. 虽然前台程序不同，但是后台解析服务器数据基本类似，可以复用。
   3. 数据库使用同一个数据库，数据库时间可以压缩。
   4. 该SDK虽然能够满足基本交流，但是仍然存在许多BUG，说明测试时间并不长。
   5. 该SDK当前条件的标准为：可以进行交流，添加好友，拉黑，修改个人信息，传输文件、图片和语音。

   估计时间：

   ​ 学习基础时间1个月半+需求分析、数据库设计、基础框架搭建半个月+分组前后台并行开发四个月+测试1-2周=开发时间约六个半月。

2. 产品优劣

   腾讯云IM自身的缺点demo写的质量有点低。在短暂的半个小时使用期间就发现了许多的BUG，还存在许多平台兼容性的问题，还有不同平台出现的问题不尽相同，测试也做得不是很好，很基础的问题都没有思考到，很难想象这是一个团队做出来的产品，不同平台之间感觉有点分崩离析。优点在于免费的服务比较多，虽然本身的代码并不理想，但是开放的免费服务足以支撑一个小型应用。

   其他产品：

   ​ LeanCloud ：优点在于开发文档写的非常简洁，github上的开源代码十分规范，API也很好理解，提供的iOS的Demo也很便于使用，在短暂的使用期间并没有发现严重的问题。缺点在于对于初学者来说，上手难度和门槛有一点高，加上语言的壁垒，导致实际使用并不会像国内的产品那么便捷。虽然iOS的部分十分优秀，但是就个人使用时，android端的还是出现了一些延迟和问题。

   ​ 网易云信：优点提供的功能十分完善：包括语音、视频、教学白板、专线电话、地理信息等等。据说更加稳定（自己未能体会到）。缺点:试用有时限，后续需要收费，对于一般的非企业开发者不大友好。

3. 团队软工提高：

   ​ 之前觉得收规范和测试是可有可无的细节工作，成大事者不拘小节，现在认为对于一个团队来说，规范和测试是十分重要的一个部分。在团队的开发中，应该指定足够严谨的规范用以规范团队的实际开发。一方面严谨的规范可以让团队在相同的约束下进行，使得团队开发出来的东西虽然是分开的，但是产出的形式大致相同，更便于开发完后的连接工作。另一方面，正确的规范也有助于后来者的理解，合理的规范和专业的注解可以提高代码的可读性，使得后来者对代码的维护能够更加顺畅，这样就算是前期的代码质量可能不尽人意，在后期不断的维护之下也能日趋完善。除此以外，测试也十分重要，正确完善的测试不仅保证的是代码功能的完成性，其更深层次的是对用户人机交互时体验的良好性进行完善。开发重要，收尾同样重要，提出建议如下：

     	1. 测试应该尽可能地完善，但首先应该保证单元测试和模块测试中，对应的部分的功能完全实现。
     	2. 在完成分离的测试后，应该进行完整的测试，不同的模块和功能一步一步连接，测试也应该相应的跟上，保证模块之间的交互不会出现问题，也为了避免因为连接而产生的问题太多而无法进行排查。
     	3. 后期的维护也应该跟上，虽然前期的开发很重要，但后期的维护并不亚于前期的开发，在第一次开发 完成后的第二次以致之后的维护都十分重要，我们不能保证第一次的开发一定满足需求，但一定要保证后续的维护能提高软件的质量。
     	4. 在进行团队开发时，对于不同的部分（如前后端）要有对应的统一规范，使对应部分的分团队严格执行。
   

建议与规划

• 如果你是项目经理，如何提高从而在竞争中胜出？
  • 要充分的调研市场和需求，在信息交流的功能上现有的已经有许多的应用程序，在众多巨头的环境下要能找到开发产品能独一无二的满足用户痛点的功能，通过市场调研和需求分析找到一个突破口，而不是单纯的将“在线交流”作为唯一的竞争力。
  • 文档的撰写要足够详细，能够准确的让每个开发、测试人员了解到用户的需求。详细准确的文档是一个产品将来可以茁壮发展的基础。
  • 腾讯IM的SDK质量并不上乘，需要团队内的程序员详细的了解文档和接口，尝试深入了解，进行一定代码上的改进。
  • 然而由于SDK本身并不稳固，就算深层次的理解和改进也并不能从根本上解决问题，只能缓解其带来的不便。所以主要开发的资源还是要放在除了此SDK的其他功能，比如流程控制的绘图功能、对小组的公告功能，使得在使用腾讯IM的SDK情况下，并不是完全依赖于这个功能，避免此SDK的弊端过多的暴露出来。
  • 对产品的流程控制要有计划，防止过多的投入到现有SDK的升级提升，要以模块的形式逐步保证开发流程，首先确保“聊天功能”正常进行，其次保证“传图功能”能够正常进行……，保证整个程序开发的流程不出现问题，也就是间接的保证了产品不会有太大的BUG。
  • 要足够重视规范和测试，程序本身就不可能没有BUG，再加上使用的第三方SDK的稳定性并没有保证，所以在代码前一定要有足够的规范制定，保证代码的可读性，在代码之后要有足够完善的测试。
  • 产品的宣传时，应该大力宣传除了该“交流功能“外的功能，扬长避短，正如上面几点所说的，应该尽量宣传我们优于他人的部分，而将该SDK的功能仅仅作为一个基础功能。
• 目前市场上有什么样的产品了？
  • 钉钉，作为一款公司管理软件是现在的主流使用软件，拥有广大的受众。但是仅作为”管理软件“，其核心思路还是通过个人交流等方式，进行管理，将团队流程和项目管理剥离了除去，成为了一个单纯的”人事管理“的工具，在项目上的管理仅限于”通过交流分配任务，接下来的任务流程都和钉钉无关“。
  • 看板工具，如TeamGit等开发流程控制程序。但这些程序着重于管理，只进行预测和任务发布，剩余的资源部份等由用户自行寻找。
• 你要设计什么样的功能？
  • 设计一个统一资源管理，能够进行流程管理和基础交流的工具。
  • 首先允许创建团队，团队可以有自己的云空间，其中上传某个项目的资源，将资源整合。
  • 可以进行流程和学习管控。比如定下作业/目标，团队成员可以在完成后上传，通过某种算法计算完成度和即时性，进行成员效率统计和任务完成度。
  • 可以进行正常的交流，但不作为社交工具，仅作为工作或者学习时特化的交流工具。
  • 可以绘制团队管理和流程管理图，如流程图、甘特图等利于PM进行管理的图。
  • 可以进行简单的数据统计，如日完成任务数等。
• 为何要做这个功能，而不是其他功能？
  • 这次疫情暴露了如果公司/学校缺乏线下聚会就难以进行流程管理的事实，所以需要一个工具能在线上统筹但也不会影响到团队成员正常生活的方法。比如，线下的家长为了跟上自己孩子的学习，加了许多老师的微信，还加了不同的班级群，在自己的微信上不仅要进行日常与家人朋友的交流，还要和学生的老师同学交流，将自己的生活和学生的学习糅合在了一起。
  • 流程管理不应该作为一个独立的功能，流程管理往往联系着效绩考察、工作交流和资源共享。尽管三个程序一起使用可以满足这种需求，那为什么不直接用一个程序满足这些需求呢？
• 为什么用户会用你的产品/功能？
  • 我的产品将流程管理的从前到后都包揽了。用户在我的产品上进行流程管理，如果学习工作流程中出现了问题，就在我的产品上继续交流，不影响到自己私人的生活，管理层也可以通过我的产品了解到效率数据，再通过团队云空间提供一个项目的所有云资源，使得整个学习/工作流程的监控都通过这一个产品完成，而不需要其他的冗余，同时，产品也仅局限于工作和学习的交流，不会涉及到其他多余的社交功能，作为一个管理产品更加纯粹。
• 你的创新在哪里？可以用 NABCD 分析。
  • NABCD见上文NABCD分析。
• 如果你来领导这个团队，会有什么不一样？
  • 我的开发进度会变成android平台->iOS平台->PC平台。不进行多平台的并行开发，使用同一个团队进行一个平台的开发后再进入下一个平台的开发，每个人负责相同的功能，保证功能与风格的统一性，如果某个端出现问题，再找到其他端的问题也更加容易。
  • 需求分析会更加丰满。虽说这次作业只是使用DEMO查看BUG，但是显而易见的，除去功能BUG的不友好，这个DEMO也没有满足用户的一些需求，如：WINDOWS上的IM端并没有添加好友功能，但是其他端有，且WINDOWS端上的通讯录并不同步更新。这些问题都会影响到用户的使用体验，团队应该做更加充足的需求分析。
  • 开发前提前制定规范，防止每个人自己写自己的代码，给后来的维护者带来很大的困难；开发后也写一份尽量详尽的文档。这些措施是为了提高程序的可维护性，如果后来的维护者文档看的一塌糊涂，看代码也因为每个成员的风格而晕头转向，这个程序的可维护性必定不会好。
  • 开发完成后进行足够的测试，对程序每个模块，模块连接后的功能，功能连接后的整体都要进行测试，防止使用时的”分离感“，足够的测试不仅仅要保证产品能够正常运行不产生BUG，还要保证用户有更加良好的人机交互体验。
  • 测试完成产品发布时应该先在小范围内使用，保证小范围人群的使用几乎没有问题时，再进行推广，如果有问题则回溯查看维护文档，寻找功能对应人员进行维护，直到小范围试用内不会出现问题。
• 如果你的团队有5个人, 4个月的时间，你作为项目经理，应该如何配置角色（开发，测试，美工等等）？
  • （如果需求分析未完成，则由我完成需求分析文档撰写）
  • 项目前期阶段
    • A：美工设计，B：数据库设计，C：数据库设计，D：系统结构设计，E：系统结构设计
  • 项目开启阶段
    • 全员开发，根据功能模块分工，如交流模块、文件传输模块、绘图等，根据需求分析具体分工。
  • 项目收尾阶段
    • A：测试，B：测试，C：开发与接口文档撰写，D：开发与接口文档撰写，E：测试。
  • 项目结束阶段
    • C、D：项目维护，保留开发人员联系方式与开发文档。
• 描述你的团队在周期为16周，每周都要做什么，才能保证在第16周如期发布软件。
  • 以下团队规划甘特图时间从4/16-8/16，以周为单位，不包含周六周日双休日，具体工作的分工见上。
  • 
• 项目发布后，有没有考虑过项目该怎么部署才能满足需求？

（没找到相应的绘图软件，直接就手绘了，简单理解一下）

DMZ区：用以帮助外网访问内部服务器。可以直接公网访问，也可以 与App Core区互通，但不能直接与DB Core区互通，通过Niginx反向代理服务器。

App Core区：能与DMZ区、DB Core区互通，但是无法直接从公网访问，放置静态资源服务器和动态访问应用服务器。

DB区： 仅与App Core区互通，进行数据的沟通。

成本：JBoss、MySql、Nginx、Apache等开源成熟产品，减小成本。硬件负载均衡很可能会超出预算，如果成本不够可以选择域名解析DNS轮询。

数据库：如果使用人数过多，导致本地硬件数据库难以支撑，可以考虑将数据移交云端保存。