如何更有效地提升对支持部门的协助与支撑？-EnhancingSupportfortheSupportDepartment:StrategiesandBestPractices

5  

• Log as much detail about the environment in which you're executing as possible (probably on startup).

  记录有关您正在执行的环境的详细信息(可能在启动时)。

• Give exceptions meaningful names and messages. They may only appear in a stack trace, but that's still incredibly helpful.

  提供有意义的名称和消息。它们可能只出现在堆栈跟踪中,但这仍然非常有用。

• Allocate some time to writing tools for the support team. They will almost certainly have needs beyond either your users or the developers.

  分配一些时间为支持团队编写工具。他们几乎肯定会有超出您的用户或开发人员的需求。

• Sit with the support team for half a day to see what kind of thing they're having to do. Watch any repetitive tasks - they may not even consciously notice the repetition any more.

  与支持团队坐了半天,看看他们要做什么样的事情。观察任何重复的任务 - 他们甚至可能不会有意识地注意到重复。

• Meet up with the support team regularly - make sure they never resent you.

  定期与支持团队会面 - 确保他们永远不会怨恨你。

4  

If you have at least a part of your application running on your server, make sure you monitor logs for errors.

如果您的服务器上至少运行了一部分应用程序,请确保监视日志中是否存在错误。

When we first implemented daily script which greps for ERROR/Exception/FATAL and sends results per email, I was surprised how many issues (mostly tiny) we haven't noticed before.

当我们第一次实现每日脚本grery for ERROR / Exception / FATAL并发送每封电子邮件的结果时,我很惊讶我们之前没有注意到的许多问题(大多数是微小的)。

This will help in a way, that you notice some problems yourself before they are reported to support team.

这将有助于您在向支持团队报告之前自己发现一些问题。

4  

Technical features:

• In the error dialogue for a desktop app, include a clickable button that opens up and email, and attaches the stacktrace, and log, including system properties.

在桌面应用程序的错误对话框中,包括一个可打开和发送电子邮件的可单击按钮,并附加堆栈跟踪和日志,包括系统属性。

• On an error screen in a webapp, report a timestamp including nano-seconds and error code, pid, etc so server logs can be searched.

在webapp的错误屏幕上,报告包含纳秒和错误代码,pid等的时间戳,以便可以搜索服务器日志。

• Allow log levels to be dynamically changed at runtime. Having to restart your server to do this is a pain.

允许在运行时动态更改日志级别。必须重新启动服务器才能做到这一点很痛苦。

• Log as much detail about the environment in which you're executing as possible (probably on startup).

记录有关您正在执行的环境的详细信息(可能在启动时)。

Non-technical:

• Provide a known issues section in your documentation. If this is a web page, then this correspond to a triaged bug list from your bug tracker.

在文档中提供已知问题部分。如果这是一个网页,那么这对应于来自您的错误跟踪器的分类错误列表。

• Depending on your audience, expose some kind of interface to your issue tracking.

根据您的受众群体,为您的问题跟踪提供某种界面。

• Again, depending on audience, provide some forum for the users to help each other.

再次,根据受众,提供一些论坛,供用户互相帮助。

• Usability solves problems before they are a problem. Sensible, non-scary error messages often allow a user to find the solution to their own problem.

可用性在出现问题之前解决问题。明智的,非可怕的错误消息通常允许用户找到他们自己的问题的解决方案。

Process:

• watch your logs. For a server side product, regular reviews of logs will be a good early warning sign for impending trouble. Make sure support knows when you think there is trouble ahead.

看你的日志。对于服务器端产品,定期检查日志将是即将发生问题的良好预警信号。确保支持知道您认为未来出现问题的时间。

• allow time to write tools for the support department. These may start off as debugging tools for devs, become a window onto the internal state of the app for support, and even become power tools for future releases.

留出时间为支持部门编写工具。这些可以作为开发人员的调试工具开始,成为应用程序内部状态的窗口以获得支持,甚至成为未来版本的电动工具。

• allow some time for devs to spend with the support team; listening to customers on a support call, go out on site, etc. Make sure that the devs are not allowed to promise anything. Debrief the dev after doing this - there maybe feature ideas there.

允许开发人员花一些时间与支持团队一起度过;在支持电话上听客户,在现场外出等。确保开发者不被允许承诺任何事情。在做完这个之后汇报开发者 - 那里可能有一些特色。

• where appropriate provide user training. An impedence mismatch can cause the user to perceive problems with the software, rather than the user's mental model of the software.

适当时提供用户培训。阻抗不匹配可能导致用户感知软件问题,而不是用户的软件心理模型。

2  

Make sure your application can be deployed with automatic updates. One of the headaches of a support group is upgrading customers to the latest and greatest so that they can take advantage of bug fixes, new features, etc. If the upgrade process is seamless, stress can be relieved from the support group.

确保可以使用自动更新部署您的应用程序。支持小组的一个令人头疼的问题是将客户升级到最新和最好,以便他们可以利用错误修复,新功能等。如果升级过程是无缝的,那么可以从支持小组中解除压力。

1  

Similar to a combination of jamesh's answers, we do this for web apps

与jamesh的答案组合类似,我们为Web应用程序执行此操作

• Supply a "report a bug" link so that users can report bugs even when they don't generate error screens.

提供“报告错误”链接,以便用户即使在不生成错误屏幕时也可以报告错误。

• That link opens up a small dialog which in turn submits via Ajax to a processor on the server.

该链接打开一个小对话框,然后通过Ajax提交给服务器上的处理器。

• The processor associates the submission to the script being reported on and its PID, so that we can find the right log files (we organize ours by script/pid), and then sends e-mail to our bug tracking system.

处理器将提交与报告的脚本及其PID相关联,以便我们可以找到正确的日志文件(我们通过脚本/ pid组织我们的文件),然后将电子邮件发送到我们的错误跟踪系统。

1  

Provide a know issues document Give training on the application so they know how it should work Provide simple concise log lines that they will understand or create error codes with a corresponding document that describes the error

提供已知问题文档提供有关应用程序的培训,以便他们知道应该如何工作提供他们将理解的简单简洁日志行或使用描述错误的相应文档创建错误代码

1  

Some thoughts:

• Do your best to validate user input immediately.

尽力立即验证用户输入。

• Check for errors or exceptions as early and as often as possible. It's easier to trace and fix a problem just after it occurs, before it generates "ricochet" effects.

尽可能早地检查错误或异常。在问题发生之前,在它产生“弹跳”效果之前,更容易跟踪和修复问题。

• Whenever possible, describe how to correct the problem in your error message. The user isn't interested in what went wrong, only how to continue working:

  尽可能描述如何更正错误消息中的问题。用户对出了什么问题不感兴趣,只对如何继续工作感兴趣:

  BAD: Floating-point exception in vogon.c, line 42
  BETTER: Please enter a dollar amount greater than 0.

  BAD:vogon.c中的浮点异常,第42行更好:请输入大于0的美元金额。

• If you can't suggest a correction for the problem, tell the user what to do (or not to do) before calling tech support, such as: "Click Help->About to find the version/license number," or "Please leave this error message on the screen."

如果您无法建议更正问题,请在致电技术支持之前告知用户该做什么(或不做),例如:“单击帮助 - >关于查找版本/许可证号”或“请在屏幕上留下此错误消息。“

• Talk to your support staff. Ask about common problems and pet peeves. Have them answer this question!

与您的支持人员交谈。询问常见问题和烦恼。让他们回答这个问题!

• If you have a web site with a support section, provide a hyperlink or URL in the error message.

如果您的网站包含支持部分,请在错误消息中提供超链接或URL。

• Indicate whether the error is due to a temporary or permanent condition, so the user will know whether to try again.

指示错误是由临时或永久条件引起的,因此用户将知道是否再次尝试。

• Put your cell phone number in every error message, and identify yourself as the developer.

将您的手机号码放在每条错误消息中,并将自己标识为开发人员。

Ok, the last item probably isn't practical, but wouldn't it encourage better coding practices?

好吧,最后一项可能不实用,但它不会鼓励更好的编码实践吗?

1  

• Provide a mechanism for capturing what the user was doing when the problem happened, a logging or tracing capability that can help provide you and your colleagues with data (what exception was thrown, stack traces, program state, what the user had been doing, etc.) so that you can recreate the issue.

  提供一种机制,用于捕获用户在问题发生时正在执行的操作,日志记录或跟踪功能,可以帮助您和您的同事提供数据(抛出的异常,堆栈跟踪,程序状态,用户一直在做什么等等。)以便您可以重新创建问题。

• If you don't already incorporate developer automated testing in your product development, consider doing so.

  如果您尚未在产品开发中加入开发人员自动化测试,请考虑这样做。

1  

Have a mindset for improving things. Whenever you fix something, ask:

有改善事物的心态。每当你修理一下,问:

• How can I avoid a similar problem in the future?

如何在将来避免类似的问题?

Then try to find a way of solving that problem.

然后尝试找到解决该问题的方法。