A clear, concise bug report, not attached to a refund request, is about the best thing that can happen to your development effort, no matter what format it arrives in. Free QA, dude! Why would you want to hinder that process by making the customer jump through hoops to learn your bug tracking interface? Even if they're also in the software industry, maybe they come from a Bugzilla shop instead of a Fogbugz shop...
First, make sure your tracking system is very user friendly.
It has to be easy to access. Does your client have to go to a web page to file a bug? Is the application buried deep in the sitemap? Nobody is going to open a browser, find your site and go through numerous links just to file a bug. This can be solved by putting a link in your application (again, it has to be easy to find; like Help > Report a bug). If your client has more then one application, make sure he is directed to correct page (or pre-fill the needed fields).
Next, do not require of your client to classify the bug (like severity and whether it is in fact a bug or a feature request). Also keep number of fields low. Description and a screenshot is plenty.
Make your controls easy to use. Nothing is more frustrating like having to wrestle a datetime picker with three drop-downs when you are trying to get some work done (and of course if you select day 31 and then April, day gets reset to blank value).
If you expect a screenshot, give your client a nice silverlight control, where he can just drop the file instead of searching it all over his disk.
When your bug filler is customized so your own mother can use it, you'll still have to push a bit. Try to "forget" about the email sometime and when the call comes act surprised and ensure your client that you received no bug report from him. Of course when he insists that he did send it to your email, have an "ah" moment and inform him your email is acting "strange" lately, then ask him to resend the email. Next bug report will be filled right.
I second the recommendation of FogBugz. Most bug tracking software is a nuisance (I'm looking at you Bugzilla). It's just too perceived as too difficult to learn / navigate by my clients.
FB lets you have a public submission page for submitting new bugs. This is a very simple page that your clients could learn easily.
FB also lets you receive e-mails directly into the bug tracking system. As the admin, you categorize / assign incoming e-mail. Then, your client could optionally be notified when the bug is fixed.
One last plug for FB: There is a bug submission tool which lets you send a screen shot from a machine along with a bug description. This has been handy for my clients as well.
The final advise is this: Stop fixing any bugs that are not in the bug tracker. Of course you will get push-back, but not as much as you might think. If you are responsive to bugs / feature requests that are entered in to the tracking system, your clients will begin to see value. But, like little kids, they will not change if they can still get what they want by just fussing a little.
IMHO I think it depends on what type of client it is, if you work as a freelancer for small companies then I think a excel spreadsheet filled by yourself is enough to use as a bug tracking system.
You probably need to point out the advantages of the bug tracking system for the customer like easier for them to see the status of the bug, prompts for mandatory information like version number etc.
Above all the argument that if they use the system their bugs will be processed faster usually does the trick.
You assert that your bug-tracking system is designed to be used by clients, yet clients won't use it. Could be something wrong with the clients, could be something wrong with the bug-tracking system.
I've always liked rt because it does have about the simplest, email-based user interface for clients.
However, I'm not suggesting that you change your bug-tracking system. What I would suggest is that you discuss the situation with some of your more friendly clients and see if you can figure out why they don't use it -- sure you've got a theory (some thoughts in your head) but do you have any data (some of the thoughts in their heads) ?
Then change to rt :-)
That last bit was a joke, what I should have written was -- then when you know what the problem really is, you can think about fixing it. Changing from system X to system Y without discussing the situation with your clients would be folly.
Even more foolish would be to start getting all snotty with your clients and bouncing back their bugs because they haven't filled out the right forms (as some have suggested). Unless that is, you are working in a secret orchard where paying clients are waiting to be plucked ripe from the tree.
If they're sending their bug reports to you by email instead of using the bug tracking system, give them the email address of the bug tracking system! Of course you would have to implement the feature but it would be novel to parse the email for inclusion.
If the email is in the wrong format the bug tracker will email them back with a template that contains the correct layout for them to fill in along with the original text they sent to cut and paste accordingly.
If they still send the email to you, forward it to the bug tracking system and when you get the reply with a template, forward that info back to the client and tell them the system won't accept it. This is still a bit of a manual process but you will be training the client at the same time on the medium they prefer and they're still doing the majority of the work.
采用 House MD 风格的方法：直接告诉他们您没有阅读任何有关错误报告的电子邮件，他们会直接进入垃圾邮件文件夹。然而，您已经有了这个用于记录错误的漂亮界面，并且通过使用它，他们可以确保您能够看到它们。
Go for a House M.D. style approach:tell them straight on that you're not reading any emails concerning bug reports, they go straight to Spam folder. You've got, however, this nifty interface for logging bugs, and by using that they're making sure that you'll get to see them.
发布评论
评论（10）
一份清晰、简洁的错误报告，不附加在退款请求上，对于您的开发工作来说是最好的事情，无论它以什么格式到达。免费的质量检查，伙计！为什么您要通过让客户跳过障碍来了解您的错误跟踪界面来阻碍这一过程？即使他们也在软件行业，也许他们来自 Bugzilla 商店而不是 Fogbugz 商店......
A clear, concise bug report, not attached to a refund request, is about the best thing that can happen to your development effort, no matter what format it arrives in. Free QA, dude! Why would you want to hinder that process by making the customer jump through hoops to learn your bug tracking interface? Even if they're also in the software industry, maybe they come from a Bugzilla shop instead of a Fogbugz shop...
首先，确保您的跟踪系统非常用户友好。
它必须易于访问。您的客户是否必须访问网页才能提交错误？应用程序是否深埋在站点地图中？没有人会打开浏览器，找到您的网站并浏览大量链接只是为了提交错误。这可以通过在应用程序中放置一个链接来解决（同样，它必须很容易找到；例如“帮助”>“报告错误”）。如果您的客户有多个申请，请确保他被引导至正确的页面（或预先填写所需字段）。
接下来，不要要求您的客户对错误进行分类（例如严重性以及它实际上是错误还是功能请求）。同时保持较低的字段数量。描述和屏幕截图就足够了。
让您的控件易于使用。当您试图完成一些工作时，没有什么比不得不与具有三个下拉菜单的日期时间选择器较量更令人沮丧的了（当然，如果您选择第 31 天，然后选择 4 月，则日期将重置为空白值）。
如果您需要屏幕截图，请为您的客户提供一个很好的 silverlight 控件，他可以直接删除文件，而不用在整个磁盘上搜索它。
当你的错误填充器被定制以便你自己的母亲可以使用它时，你仍然需要推动一点。有时尝试“忘记”这封电子邮件，当接到电话时表现出惊讶，并确保您的客户您没有收到他的错误报告。当然，当他坚持说他确实将其发送到您的电子邮件时，请“啊”一下并告诉他您的电子邮件最近表现“奇怪”，然后要求他重新发送电子邮件。下一个错误报告将被正确填写。
First, make sure your tracking system is very user friendly.
It has to be easy to access. Does your client have to go to a web page to file a bug? Is the application buried deep in the sitemap? Nobody is going to open a browser, find your site and go through numerous links just to file a bug. This can be solved by putting a link in your application (again, it has to be easy to find; like Help > Report a bug). If your client has more then one application, make sure he is directed to correct page (or pre-fill the needed fields).
Next, do not require of your client to classify the bug (like severity and whether it is in fact a bug or a feature request). Also keep number of fields low. Description and a screenshot is plenty.
Make your controls easy to use. Nothing is more frustrating like having to wrestle a datetime picker with three drop-downs when you are trying to get some work done (and of course if you select day 31 and then April, day gets reset to blank value).
If you expect a screenshot, give your client a nice silverlight control, where he can just drop the file instead of searching it all over his disk.
When your bug filler is customized so your own mother can use it, you'll still have to push a bit. Try to "forget" about the email sometime and when the call comes act surprised and ensure your client that you received no bug report from him. Of course when he insists that he did send it to your email, have an "ah" moment and inform him your email is acting "strange" lately, then ask him to resend the email. Next bug report will be filled right.
Fogbugz...我要求我的客户就他们的问题立案bug，然后我就开始研究它......它真的值得一试......
Fogbugz... I asked my clients to open a case about their bug and i then worked on it... Its really worth a try..
我赞同 FogBugz 的推荐。大多数错误跟踪软件都很麻烦（我在看你 Bugzilla）。我的客户认为它太难学习/导航。
FB 允许您拥有一个公开提交页面来提交新的错误。这是一个非常简单的页面，您的客户可以轻松学习。
FB 还允许您直接将电子邮件接收到错误跟踪系统中。作为管理员，您可以对收到的电子邮件进行分类/分配。然后，您的客户可以选择在错误修复后收到通知。
FB 的最后一个插件：有一个错误提交工具，可让您从计算机发送屏幕截图以及错误描述。这对我的客户来说也很方便。
最后的建议是：停止修复错误跟踪器中没有的任何错误。当然，你会受到阻力，但没有你想象的那么多。如果您对输入跟踪系统的错误/功能请求做出响应，您的客户将开始看到价值。但是，就像小孩子一样，如果他们只要稍微大惊小怪就能得到他们想要的东西，他们就不会改变。
I second the recommendation of FogBugz. Most bug tracking software is a nuisance (I'm looking at you Bugzilla). It's just too perceived as too difficult to learn / navigate by my clients.
FB lets you have a public submission page for submitting new bugs. This is a very simple page that your clients could learn easily.
FB also lets you receive e-mails directly into the bug tracking system. As the admin, you categorize / assign incoming e-mail. Then, your client could optionally be notified when the bug is fixed.
One last plug for FB: There is a bug submission tool which lets you send a screen shot from a machine along with a bug description. This has been handy for my clients as well.
The final advise is this: Stop fixing any bugs that are not in the bug tracker. Of course you will get push-back, but not as much as you might think. If you are responsive to bugs / feature requests that are entered in to the tracking system, your clients will begin to see value. But, like little kids, they will not change if they can still get what they want by just fussing a little.
恕我直言，我认为这取决于客户的类型，如果您作为小公司的自由职业者，那么我认为您自己填写的 Excel 电子表格足以用作错误跟踪系统。
IMHO I think it depends on what type of client it is, if you work as a freelancer for small companies then I think a excel spreadsheet filled by yourself is enough to use as a bug tracking system.
您可能需要向客户指出错误跟踪系统的优点，例如让他们更容易查看错误的状态、提示输入版本号等强制性信息。
最重要的是，如果他们使用该系统，他们的错误将更快地处理通常可以达到目的。
You probably need to point out the advantages of the bug tracking system for the customer like easier for them to see the status of the bug, prompts for mandatory information like version number etc.
Above all the argument that if they use the system their bugs will be processed faster usually does the trick.
设置您的电子邮件服务器以退回包含“bug”一词的电子邮件。让退回报告包含指向您的日志站点的链接。
（或者实际上，获取一个错误跟踪软件，允许通过“电子邮件”发送错误）。
Set up your email server to bounce emails with the word 'bug' in it. Have the bounce report contain a link to your logging site.
(Or in reality, get a bug tracking software that allows bugs to be 'emailed' in).
您声称您的错误跟踪系统是为客户使用而设计的，但客户不会使用它。可能是客户出了问题，也可能是错误跟踪系统出了问题。
我一直很喜欢 rt 因为它确实为客户提供了最简单的、基于电子邮件的用户界面。
但是，我并不是建议您更改错误跟踪系统。我建议你与一些更友好的客户讨论这种情况，看看你是否能找出他们不使用它的原因——当然你有一个理论（你脑子里有一些想法），但是你有任何数据（他们脑子里的一些想法）吗？
然后改成 rt :-)
最后一点是个笑话，我应该写的是——然后当你知道问题到底是什么时，你可以考虑修复它。在不与客户讨论情况的情况下从系统 X 更改为系统 Y 是愚蠢的。
更愚蠢的是开始对你的客户发脾气，并因为他们没有填写正确的表格（正如一些人建议的那样）而退回他们的错误。除非是这样，否则你就是在一个秘密果园工作，那里付费的客户正在等待从树上采摘成熟的果实。
You assert that your bug-tracking system is designed to be used by clients, yet clients won't use it. Could be something wrong with the clients, could be something wrong with the bug-tracking system.
I've always liked rt because it does have about the simplest, email-based user interface for clients.
However, I'm not suggesting that you change your bug-tracking system. What I would suggest is that you discuss the situation with some of your more friendly clients and see if you can figure out why they don't use it -- sure you've got a theory (some thoughts in your head) but do you have any data (some of the thoughts in their heads) ?
Then change to rt :-)
That last bit was a joke, what I should have written was -- then when you know what the problem really is, you can think about fixing it. Changing from system X to system Y without discussing the situation with your clients would be folly.
Even more foolish would be to start getting all snotty with your clients and bouncing back their bugs because they haven't filled out the right forms (as some have suggested). Unless that is, you are working in a secret orchard where paying clients are waiting to be plucked ripe from the tree.
如果他们通过电子邮件而不是使用错误跟踪系统向您发送错误报告，请向他们提供错误跟踪系统的电子邮件地址！当然，您必须实现该功能，但是解析电子邮件以进行包含会很新颖。
如果电子邮件的格式错误，错误跟踪器将通过电子邮件发回给他们一个模板，其中包含正确的布局供他们填写，以及他们发送的原始文本以进行相应的剪切和粘贴。
如果他们仍然向您发送电子邮件，请将其转发到错误跟踪系统，当您收到带有模板的回复时，将该信息转发回客户并告诉他们系统不会接受它。这仍然是一个手动过程，但您将同时使用客户喜欢的媒介对客户进行培训，并且他们仍在完成大部分工作。
自动返回电子邮件可能如下所示：
If they're sending their bug reports to you by email instead of using the bug tracking system, give them the email address of the bug tracking system! Of course you would have to implement the feature but it would be novel to parse the email for inclusion.
If the email is in the wrong format the bug tracker will email them back with a template that contains the correct layout for them to fill in along with the original text they sent to cut and paste accordingly.
If they still send the email to you, forward it to the bug tracking system and when you get the reply with a template, forward that info back to the client and tell them the system won't accept it. This is still a bit of a manual process but you will be training the client at the same time on the medium they prefer and they're still doing the majority of the work.
Automated Return email might look like:
采用 House MD 风格的方法：直接告诉他们您没有阅读任何有关错误报告的电子邮件，他们会直接进入垃圾邮件文件夹。然而，您已经有了这个用于记录错误的漂亮界面，并且通过使用它，他们可以确保您能够看到它们。
Go for a House M.D. style approach:tell them straight on that you're not reading any emails concerning bug reports, they go straight to Spam folder. You've got, however, this nifty interface for logging bugs, and by using that they're making sure that you'll get to see them.