这是现代软件工程课程案例分析作业，我分析的产品是 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 不支持图片的问题入手开始工作。之后按调研结果决定问题的优先级，依次解决。每个问题解决、测试无误、文档更新后，再一起开始处理下一个问题，以避免大家步调不一致降低效率。