案例分析作业

这是现代软件工程课程案例分析作业,我分析的产品是 Microsoft Edge 写到一半时发现有几个让我气到跺脚的 bug 重现不出来了,尴尬 Skype for Business。

调研,评测

注册并使用 Skype for Business 的主要功能,按照描述的 bug 定义,找出几个功能性的比较严重的 bug。至少两个。用专业的语言描述(每个 bug 不少于 40 字),如有必要,可以配图。

我感觉对于文件存储、即时通讯等这种基础设施类应用,非常重要的一个评价标准就是它是否清晰地传达了它能提供的保证,以及这些保证是否符合用户需求。比如一个刚开始用微信的人很快就会从 UI 合理推断出:“只要我拉黑某人,他肯定不能再骚扰我”,以及“只要我发信息给某人,他肯定在下次检查消息时能看到”。如果应用没能提供足够多的保证,或者(更糟地)用 UI 暗示了保证却不能履行,就会失去用户的信任,用户会怀疑这个应用其他业务逻辑也是不靠谱的。Skype for Business 就很擅长破坏我对它的信任。

  • 一个较小的问题是我连它的主窗口在什么情况下显示都摸不清楚。我每次看到窗口时都把它关掉,但它总是能在我不注意的时候自己又弹出来,有时我还会看到它突然自行退出并重新启动,然后窗口就出现了。这很打扰用户,如果它明明能在窗口关闭时在托盘区正常运行,它就应当记住用户的偏好。
  • 一个较大的问题则是它不保证消息送达,尤其是在多设备登录时。它似乎会按照某种逻辑选择把消息送给某一台设备,但这个逻辑非常不直观,我身边没人搞明白(这种事情不该是用户做一番 research 才能搞明白的)。有时它压根不把消息送给任何一台设备,而是径直放进“错过的消息”中。更糟的是,如果它决定把一个图片消息送给 Mac 设备,Mac 客户端不支持图片,会直接丢弃消息!
  • 我身边多数人刚用 Skype for Business 时都以为 add to contacts 功能是单方面的,只是把对方添加到自己的列表里以方便联系,没想到这个操作其实会给对方发送一个“好友请求”,有时会让人挺尴尬的。开发者或许会抗辩说这不是 bug 而是 feature,但我认为如果说这个业务逻辑是 feature,那么就是 UI 有 bug。

另外,请你自己花几天时间时不时用一下 Skype for Bussiness,看看你有没有成为一个持续使用者。Skype for Bussiness 解决了你的什么问题?

我是持续使用者,但这是不得已而为之,只有它有公司内部通讯录。

相信每个同学的朋友中一定有人需要用这样的软件(例如你上课的同学),记载你对这位用户的采访。

“Skype for Business 的 bug 可多啦!” ——博杰

介绍采访对象的背景和需求(他们为何要用这个软件,有什么痛点,还有别的需求么)

同样因为在公司工作不得不用 Skype for Business,没啥别的需求,痛点就是这个软件不可靠。

描述用户使用这个产品的过程,用户的问题解决了么?软件在数据量/界面/功能/准确度上各有什么优缺点?用户体验方面有问题么?

Skype for Business 的 bug 多数都是随机性的,他和我都是单设备登录、短时间使用的话,没有什么问题,界面和功能也都一般,虽然不是非常好,但也没有毛病。

结论:经过这么多工作,你一定有充分的理由给这个软件下一个评价:

如果我在给自己的团队选择通讯录基础设施的话,我不会考虑 Skype for Business,我认为这是一个不负责、不可靠的产品。如果要打分的话,应该是不及格,因为它没有正确实现作为一个即时通讯工具(而且还是 for business)应有的最基础功能,其他方面没必要评价了。

分析

根据你对 Skype for Business 的了解,现在请估计这个软件做到这个程度大约需要多少时间(团队人数 6 人左右,计算机大学毕业生,并有专业 UI 支持)。

它除了聊天以外还是有很多别的复杂功能的,比如集成公司通讯录、集成日程等。很多它的其他功能我并不完全了解,就我所了解的功能子集而言,我认为两三个月可以做出能用的版本,半年到一年可以完善各平台客户端和周边功能,再考虑到完善的运维、技术支持、文档等的话,大约需要一年多可以较平稳地运营。

你在第一部分发现的 bug,为何软件团队不能在发布前修复?他们是不知道,还是有意不修复?你觉得是什么原因?

我认为他们知道,但是难以修复。这些 bug 一般来自于开发初期对整个系统的架构设计不合理(在消息投递逻辑和协议版本协商相关的部分),以至于后期遇到的一些问题只有大幅度调整架构才能从根本上解决(或者像很多服务最终采取了补丁套补丁的方法,虽然不需要重构,但增加了代码维护难度,还增加了故障的可能性)。另外,这并不是什么旗舰产品,市场可能也不是非常大/非常严苛?所以我猜测团队没有足够的意愿,也没有足够的人力物力资源去大幅度修改代码,只是在维持现状。其实很多二流、三流软件都处在这个境地(比如各种非互联网公司发布的手机 APP,或者各种银行和政府部门用的很多年前设计的网站系统),人们宁愿在客服上增加投入来解决问题,而不愿改代码,因为很贵而且风险较高,我觉得这是完全可以理解的。

从各方面的问题,推理出这个软件团队在软件工程方面可以提高的一个重要方面(具体建议)。

我不知道……我觉得如果我能想出什么好建议的话,他们也早该想到并且这么做了。这是一个困境,没什么很好的改变局面的方法。我觉得应该集中人力物力,好好改一下代码,把一些硬伤修复掉,但这需要不少支出,而且我并不确定能否产生足够的回报——只要修掉硬伤,产品的市场占有率就能翻倍了吗?这是很多因素一起决定的,不太可能做一件事就有很大的变化。另外,如果真的要集中资源做一件事,应该先好好调研一下做什么事最有价值。虽然我认为业务逻辑的这些 bug 很严重,但别人不一定都这么认为,应该通过调查问卷或者遥测数据来确定。但加一套遥测系统也是花费不菲的,我还是推荐先做一做市场调研和用户问卷,来调查用户最主要的意见集中在哪里,然后如果有资源的话,把相应问题优先解决。

建议和规划

首先,市场有多大?全中国 IT 专业的学生和职业人士都可以是用户,总共有多少人?

市场理论上确实不小,因为任何团队或者创业公司都是潜在用户,在最理想的情况下,每个白领可能都需要这种产品来进行协作。

目前市场上有什么样的产品了,它们的优势劣势在哪里?和它直接竞争的产品在那里?这个领域是处于(萌芽 / 成长 / 风口 / 平台 / 下降)阶段?

我还不是很了解企业级即时通讯这个市场,但我的印象中钉钉、企业微信、阿里郎等应该是这类软件中较有名的,另外还有更多我没听说过的选择(我第一次见到广告密度如此之高并且如此硬的知乎问题)。这个领域应该处于平台期,用户的选择也很稳定了,并且比起软件的质量本身,用户应该会更在意周边生态环境,这是竞争的核心点。如果一个软件本身很好,却不能集成我的团队现有的日程系统和通讯录,我肯定不愿意选择它。对于我个人而言,我还很在意是否存在和 Windows 客户端同样质量的 Linux 客户端——如果我的团队仅仅为了即时通讯不得不装双系统/虚拟机,听起来可不妙。

作为新的项目经理,这个产品的核心用户群是什么样的人,典型用户长什么样?学历,年龄,专业,爱好,收入,表面需求,潜在需求都是什么?

这种基础设施的用户面很广,不同学历、专业、爱好、收入的白领都有查询公司通讯录和内部即时通讯的需求,有的人的通讯需求可能比较简单,限于发送文字和图片,有的人则可能较复杂,需要多分支会话、协作编辑、带版本管理的共享目录等,他们需要类似于 Teams 的系统。

你要设计什么样的功能?为何要做这个功能,而不是其他功能?为什么用户会用你的产品/功能?你的创新在哪里?可以用 NABCD 分析。

我认为首要的还是要确保各种消息(文字、图片、文件、语音等)都及时、可靠地送达,并且有好用的存档和检索功能,这才能满足企业的基本需求。在此基础上,我更倾向于做好周边生态环境,充分和其他系统结合,如通讯录、日程、文档、邮件等,寻求机会让这个工具成为一个整合各种事务的 hub。(再加上多分支会话、标签等功能,我的这个目标不就是 Teams 嘛……)

如果你有钱可以招聘 6 个人,有 4 个月的时间,你作为项目经理,应该如何配置角色(开发,测试,美工等等)?
描述你的团队在 16 周期间每周都要做什么,才能在第 16 周如期发布软件的改进版本,并取得预想中的成绩。

如果寻求短期努力立刻获得回报的话,认真修改代码架构不是一个划算的选择,我会采用补丁套补丁的策略 get things done。我需要一个人做市场调研和分析,用有效的手段收集用户需求和意见汇报给我,并和我选定需要优先解决的问题。几乎可以肯定有的意见涉及到界面或交互逻辑,所以我需要一个人做用户体验设计。剩下的四个人中,两个人开发,另外两个人做文档、测试、运维、工具链管理等工作(如果一定要现在分好的话,测试和运维等这些关于运行和部署的问题交给一个人,文档和工具链管理等这些关于开发工作流的问题交给另一个人)。整个团队基本上是按照外科医生模式设计的,希望这样会比较高效。

16 周我希望能解决大概 3 个问题或实现 3 个功能需求。前 2 到 4 周一边调研,一边熟悉现有代码和工具链,可以尝试从修复消息投递混乱的问题,或者 Mac 不支持图片的问题入手开始工作。之后按调研结果决定问题的优先级,依次解决。每个问题解决、测试无误、文档更新后,再一起开始处理下一个问题,以避免大家步调不一致降低效率。

转载于:https://www.cnblogs.com/SmartHypercube/p/9940983.html

你可能感兴趣的:(案例分析作业)