当用户从不使用他们要求的功能时

作者:糖果
发布时间:2025-04-28 05:17:21 (14天前)
来源:featurestheywanted.html

在用户研究中众所周知，如果您询问用户是否需要新功能，他们通常会尖叫“是”。毕竟为什么有人不想要更多功能？尽管他们可能不会实际使用它。你可能不知道，直到它发布之后。
这是一个关于我完全按照开发人员告诉我他们想要的东西构建的故事，然后他们没有使用它。但这一次没那么简单。我有很多证据表明需要这些功能。那他们为什么不使用它？！

##### 追逐梦想
有一天在微软工作是我的梦想。二十年前，我第一次使用 Visual Studio 进行编程。我从 Visual Basic 6 开始，然后转向 Visual C++ 6，然后是 Visual C# 2008。在我早期的一项软件工作中，我的经理在我的绩效评估会议上问我：“你更愿意在哪里工作而不是在这里？” 我说微软。
在读研究生期间，我看到微软在我所在的领域发表了很多优秀的论文。似乎所有著名教授都至少在那里度过了一个夏天的实习生。我不知道如何进入他们的领域。我在会议上与微软研究人员进行了几次对话，但我仍然没有被他们关注。
所以有一天晚上，在一次叛逆的时候，我向两个我想与之合作的小组发送了冷邮件。几天后我进行了第一次视频采访，接下来的一周又进行了几次。
我在微软获得了研究实习机会。
该职位是与研究人员和开发工具团队合作的混合角色。具体而言，致力于开发用于在公司内部进行代码审查的内部工具和服务。每周大约有 30,000 人使用该工具。
我最初花了很多时间来理解代码审查过程。我在开发人员执行代码审查时跟踪他们，分析来自代码审查 Web 服务的遥测数据，在开发人员执行代码审查时记录他们的屏幕，并就代码审查采访了开发人员。事实上，在我开始实习之前，我什至对有关代码审查的研究论文进行了文献审查，以便我可以在第一天准备好去。
现在我只需要构建一个工具来解决我们确信他们拥有的问题。

##### 我们建造了他们所要求的
目标是创建一个自动代码审查器，在代码审查中提供程序分析反馈。这样整个团队都可以看到反馈，而不仅仅是代码更改的作者，他们可以将时间花在设计讨论上，而不是表面上的吹毛求疵。此外，它还可以简化请求构建、运行程序分析器和运行测试的过程，这些过程可能需要花费数小时，而且对于某些团队来说，这一切都在审查过程中很晚才完成。自动审阅者将参与整个审阅过程并自动更新反馈。
构建初始原型所花费的时间比我们原先预期的要长得多。我应该使用一些现有的基础设施作为基础，并为我们的用例做一些调整。最多需要两周时间，或者我们是这么认为的。结果出现了一些小问题：参与我们想要使用的那个项目的每个人都离开了公司，我们不知道如何构建源代码，它有大约 500,000 行代码，而我们找到的一个人知道关于该项目的任何事情都提前了 13 小时，并停止回复我们的电子邮件。
嗯。猜猜我正在从头开始重写我们需要的东西。我的实习周已经倒计时了。
一个月后，我向几位经理和开发人员演示了我们自动化代码审查器的原型。他们给出了积极的反馈并同意让我们在他们的团队中试用该工具。我写了一个关于如何使用它的简短教程并将其发送给团队。我花了周末修复错误并将其设置为“现实世界”使用。
我们部署了我们的工具。
几乎没有人使用它。少数确实使用过它，使用过一两次，几乎没有与之互动。几天后，零人在使用它。
为什么他们告诉我他们想要这些功能？！？！

##### 用户研究没有终点
我感到很失败。我的夏天很快就过去了。该项目在此过程中已经遇到了十几个不同的障碍。我准备认输。但至少我现在必须把微软放在我的简历上，对吧？
我请了周末假。我试着不去想它。
然后动机就来了。就像那天晚上，我首先发送了冷邮件以获得实习机会。所以我周一早上 6 点到办公室（从中央时区搬到西海岸有其优势）并开始制定计划。当我的导师到达时，我告诉他们给我一周的时间。我想弄清楚这一点。
这不是用户的错。他们没有骗我。他们确实有这个问题，他们确实想要一个解决方案。我只是错过了一些东西。我所要做的就是回去观察它们。答案就在那里！
我进行了一项小型实验室研究，以再次了解人们如何进行代码审查。但我也要求他们使用我的工具进行代码审查。我几乎没有给他们任何关于如何使用它的说明。我是一步一步看的。
我通过电子邮件向最初使用我的工具的少数开发人员发送电子邮件，试图开始讨论他们对该工具的看法。

##### 转折点
一个问题变得很明显。我一直在看错地方！它甚至与我们的工具提供的功能无关。这是该工具如何适应他们的工作流程。或者在这种情况下，该工具如何需要对其工作流程进行微小但显式的更改才能开始。许多开发人员甚至不知道我们的工具存在。我从未想过这会成为一个问题。我们以前从未讨论过。只是假设......我的意思是，他们还会如何使用我们的工具？
在与我的导师进行头脑风暴后，他们很快就想出了一个解决方案。我们将工具的一部分从桌面应用程序转移到侦听代码审查的 Web 服务，然后它会在没有任何明确命令的情况下自动启动我们的功能。这样开发人员的工作流程就完全没有改变！哦，默认选项的力量。
我们的时间很短，但是创建一个 Web 服务来完成这项任务是一项相当小的任务。有一个现有的 API 来处理困难的部分。
这次我们希望在部署时更加小心。开发人员可能会给我们第二次机会，但我怀疑他们会给我们第三次机会。我们的计划是部署到一个与我们位于同一栋楼的小团队中，并迅速从他们那里获得反馈。我们向他们明确表示，他们是我们的重中之重，我们都听从了他们对该工具的看法。
他们使用了它。但这让他们很沮丧。它给他们带来了过多的信息并妨碍了他们。我收到了一两封愤怒的电子邮件。根据我们在开发期间测试的用例，我们不可能看到这种情况的发生。但如果我们更接近我们的客户，我们就会这样做。我应该已经看到了这一点。另一个教训。
我们在我们的工具中加入了一些严格的限制，这样它就不能用信息轰炸任何更多的代码审查。我们过滤掉可能不太相关或低优先级的分析警告，汇总重复出现的警告，并设置将显示的警告数量的最大限制。我们还添加了来自自动审核器的状态更新，以便用户确切地知道系统处于什么状态。事后看来，开发人员想要的一切都是完全合理和合乎逻辑的。甚至明显。
是时候重新部署到最初同意使用我们工具的所有团队了。
我们四重检查一切是否准备就绪。并再次进行四重检查。我们向经理发送了一封电子邮件，告诉他们我们将默认为他们所有的代码审查启用我们的工具。

##### 最后的尝试
我点击了一个按钮来部署它。
我的实习只剩下一个多星期了。如果事情再次恶化，就没有时间调整了。我真的只有时间来修复小错误，收集更多定性数据，并向更多团队展示我的项目。计划是在我回到大学后收集几个月的使用数据，然后在某处提交论文。
该工具帮助开发人员在很长一段时间内进行代码审查。
快进几个月后，我们遇到了另一个问题。分析使用数据并不像我们希望的那样直接。我们对记录的数据做了一些错误的假设。而且由于我不再是 Microsoft 的员工，我不得不通过电子邮件编写数据库查询，并等到有人有空闲时间运行它们并将匿名的汇总结果发回给我。
人们确实使用了它！我们在 15 周内将其部署给了三个团队的 98 名软件工程师。它被 41 位不同的作者和 883 位独特的审阅者用于 354 次代码审查。它在代码审查中发布了 149 条分析评论（以及来自构建和测试框架的状态更新）。它会发布更多的评论，但特定的分析警告可以被团队压制。
“有一些评论有助于开始直到最后一刻可能会错过的对话，所以他们的加入是一个积极的因素。”
通过分析使用数据并通过电子邮件发送调查，我们发现有证据表明我们的工具提高了沟通、生产力和评论质量。用户报告了压倒性的赞誉，以及可以改进的功能请求和场景。
最后，我们在顶级会议上发表了一篇精彩的论文。不仅如此，微软的几个团队还与我联系以了解该工具的设计原理，因为他们想为自己的组织重新创建它。

1 条回复

动动手指，沙发就是你的了！

登录后才能参与评论