用户是否应该实时查看自己的性能统计数据
我知道这个问题似乎非常开放。我会尝试缩小范围。
一段时间以来，我一直在努力在应用程序 GUI 中包含或排除实时用户性能统计数据。
有谁知道将这些统计数据包含在应用程序中的危害与收益的信息吗？
即回复的电子邮件数量、接听的客户电话数量、每个客户的平均时间等。
用户正在寻求有关其统计数据的更多信息，因为这是他们的评级方式。然而，有人担心，如果能够实时或接近实时地查看他们的表现，将会对他们的工作产生负面影响。
我可以将其等同于衡量我一天内编写了多少行代码。这是否可以帮助我提高工作效率，或者只是教我尽可能快地编写代码，并且很可能会犯很多错误。
在我的应用程序中，我可以想到这些场景，
即“坏”：“我发现我已经在这个问题上花了 10 分钟，我需要尽快完成它”
与
“好”：“我能够快速帮助该客户，我的生产力是今天好”
I know this questions seems extremely open ended. I will try to narrow scope.
I have been struggling for some time as to include or exclude real time user performance stats in an application gui.
Does anyone have any info on the harm vs gain in including these stats in an app?
i.e. number of emails answered, number of customer calls taken, average time per customer etc.
The users are begging for more info on their stats, as it is how they are rated. However there is concern that given access to see their performance real time or near real time it will negatively affect their work.
I can kind of equate it to being measured on how many lines of code I churned out in one day. Would this help me to be more productive or just teach me write code as fast as possible and most likely make a lot of mistakes.
In my application I can think of these scenario's
i.e. BAD: "I see I have spent 10 minutes on this issue already, I need to finish this up asap"
vs
i.e. GOOD: "I was able to help that customer quickly, My productivity is good today"
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我认为可能确实存在一种可以称为“Facebook 效应”的现象，即仅通过提供一个指标（例如，“朋友”数量、每次通话的分钟数），就暗示它很重要。但是，我认为这不是问题，因为很明显用户已经认为这些指标非常重要，否则他们不会向您乞求它们。
我相信大量的心理学研究表明，在指标上添加更快的反馈很可能会提高用户在该指标上的表现。此外，如果人们根据自己无法很好跟踪的指标进行评估，就会在情感上产生压力，而现在的情况似乎就是如此。
我说实时显示指标。管理层显然希望它们具有高性能，否则他们不会对用户进行评级。用户想要它，它会减轻他们的工作压力。对我来说听起来像是双赢。
当然，客户可能会遭受损失，因此存在一些道德困境。然而，如果这些指标存在问题，那么问题就出在公司政策上，而不是用户界面上。通过向用户显示指标，您将向管理者突出显示该策略的任何缺点。也许管理层会得到线索。
如果这是您职责的一部分，您可以提出客户满意度衡量标准（例如，呼叫后自动调查、人工随机跟踪调查），以便管理人员至少可以跟踪其政策的影响。假设他们关心（如何评估他们？）。
I think there may indeed be a phenomenon one could call “The Facebook Effect,” where by merely presenting a metric (e.g., number of “friends,” minutes per call), you imply that it’s important. However, I don’t think that’s an issue here because it’s clear that users already regard these metrics as very important, otherwise they wouldn’t be begging you for them.
I believe there is a wealth of psychology research showing that adding faster feedback on a metric will very likely improve user performance on that metric. Furthermore, it is emotionally stressful for people to be evaluated on a metric that they cannot track well themselves, which appears to be the case now.
I say show the metrics real time. Management obviously wants high performance on them otherwise they wouldn’t be rating the users on it. User want it, and it’ll reduce their job stress. Sounds like a win-win to me.
Of course, the customers probably lose out, so there’s a bit of an ethical dilemma. However, if these metrics are problem, then the problem lies in corporate policy, not in the user interface. By showing the metrics to the user, you will highlight whatever shortcomings this policy has to the managers. Maybe management will get a clue.
If it’s part of your role, you could propose measurements of customer satisfaction (e.g., after-call automated survey, random follow-up surveys by a human) so that managers can at least track the impacts of their policy. Assuming they care (how are they evaluated?).
KISS 原则，这些信息与用户将要做什么相关吗？
如果没有，则不添加。我喜欢网络应用程序的一件事是更新/提交某些内容（基本上是回发数据）后加载页面所需的时间。
这样我/用户就可以判断数据进入数据库是否存在问题或缓存问题。
例如，显示给客户的电话的问题是您的平均时间可能不如您希望的那么准确。您可能有一位客户喜欢聊天，或者遇到与您的业务无关但仍反映在您的应用程序中的技术问题。
由于这些类型的事情，这些数据不应该被信任。另一件事是，如果你开始显示通话时间，你最终会进行员工竞赛，看看谁能先挂断电话……那就是你开始更加伤害自己的时候……糟糕的客户服务。
一些知名人士过去常常根据通话量、平均通话时间等来评价员工。还记得戴尔试图将所有技术通话外包给印度吗？美国的客户感到沮丧，电话要么太长（不理解），要么太短（客户不想处理）。好吧，大佬们认为呼叫时间与我们的预测非常一致，而且我们的成本正在下降。但随着时间的推移，它跌入了谷底……
KISS principle, is this information pertinent to what the users will be doing?
If no, then no do not add it. One thing that I like on web apps is the time it takes for a page to load after updating / submitting something (basically posting back data).
That way I / a user can tell if there is an issue with data going to the database or a caching issue.
The problem with displaying say for instance calls to customers is your average times may not be as accurate as you'd hope. You may have a customer who likes to chat, or is having technical issues that are irrelevant to your business but yet get reflected in your apps.
This data shouldn't be trusted because of these types of things. Another thing is, if you start displaying call times you end up having employee competitions to see who can get off the phone first..that's when you start hurting yourself more..bad customer service.
A few big names used to rate employees based on things like call volume, average time on the call, etc. Remember when Dell tried to outsource all their technical calls to India? Customers here in the US were frustrated and calls were either too long (not understanding) or too short (Customers did not want to deal with it). Well the big shooters thought hey call times are pretty inline with what we had forecasted and our costs are going down. But it hit rock bottom as time went on...
您的应用程序作为传达此信息的工具非常有用，如果用户强烈要求其收集的数据具有更高的可见性和透明度，那么您绝对应该将其包含在内。然而，用户对信息的反应在很大程度上取决于组织文化已经如何处理这些信息。
例如，管理层是否积极鼓励用户缩短通话时间并与尽可能多的客户打交道，并解雇那些未达到配额的人？如果是这样，当用户发现自己的通话时间有点长时，将会引起同样强烈的反应，要求他们缩短通话时间。 （“呃-哦，我已经到了 2 分钟的时间了。我最好挂断电话并假装断开连接，以避免我的平均通话时间太长。”）
相反，如果管理层只是鼓励每个人都做好事工作并提供卓越的客户服务，这些信息可以由用户在这项工作的整体背景下综合。 （“我在这个客户身上花了很多时间——我应该看看是否可以尽快解决问题，或者如果我无法解决这个问题就向他升级。”）
Your application is useful as a tool to convey this information, and you should definitely include it if users are clamoring for more visibility and transparency into the data it collects. A user's response to the information, however, will largely depend on what the organizational culture already does with it.
For example, does management aggressively encourage users to keep calls short and deal with as many customers as possible, and fire those who don't meet quotas? If so, that's going to provoke an equally strong reaction from users to keep their calls short when they discover they've been a bit on the longer side. ("Uh-oh, I'm getting to the 2-minute mark. I'd better hang up and fake a disconnection to avoid getting my average call length too high.")
Conversely, if management simply encourages everyone to do a good job and provide excellent customer service, this information can be synthesized by users in the overall context of this work. ("I've spent a lot of time on this customer -- I should see if I can wrap things up shortly, or escalate him if I can't fix this problem.")