Somewhere in the Becoming a Developer Starter Kit, there should be a section about consigning yourself to a lifetime of questions and bug fixing. Oh, you didn’t get your copy in the mail? Then you’ve probably learnt that lesson the hard way.
You could view ticket management as the irritating part of your job that hinders progress on more creative endeavours, or you could take a different view…
You see, it takes a lot of time and skill to work in your particular realm of the industry and as technology is, by nature, rapidly evolving, it’s difficult for non-specialists to tackle issues which might seem pretty basic to you.
In other words: You are the chosen one.
Most modern businesses rely heavily on their IT infrastructure, so if you’re the one they’re asking to keep it up and running, your expertise is pretty much invaluable. Great stuff. But to make the best use of your time – and help you hold onto your sanity – it’s important there’s a process behind that constant stream of tickets.
A process? Yup, a process. A way of making sure the tickets that land on your desk are clear, concise and actionable. The good news is, we’re here to help. We’ve put together some useful information you can share with your colleagues and clients, encouraging them to communicate clearly, avoid crossed wires and give you what you need to fix things fast.
Tickets to make your eyes twitch
Before we dive in though, we thought it might be a good idea to identify some repeat offenders – those types of ticket that really rub you up the wrong way…
- Finger-pointing tickets: You know, the kind that try to blame the dev team and imply you’re a bit rubbish. They probably get pushed to the bottom of the pile, right? Your colleagues need to know that being polite, descriptive and patient gets far better results. Especially when pretty often, someone just hasn’t switched something on properly.
- Duplicate tickets: These come from people who think that by raising several tickets, their issue will get seen to faster. Nope. They’re just adding to the backlog, creating confusion and slowing things down even more. They need to understand why it’s important to stick to one ticket per issue – and wait your turn.
- A ticket of epic proportions: While details are good and a step-by-step replay of the bug trigger can be super helpful, developers don’t have time to read lengthy tomes. Encourage people to make their reports short and to the point.
- Ambiguous tickets: Very often, the end-user might not have the right vocabulary or knowledge to describe their problem properly or in detail. This can leave you with vague tickets that don’t hold enough information for the programmer to quickly dive in and solve the issue. This type of ticket often gets pushed to the back of the queue.
It’s not hard to see how consistent abuse or misuse of the ticketing system creates an us-and-them vibe for many teams. When it’s your job to problem solve all day, a little help and clarity when it comes to bug reports goes a long way towards speeding up the fix.
So talk to your colleagues. They want bug-fixing to be as streamlined as possible, so help them understand that they’re part of that process too. Invest some time in walking them through the right way of reporting a problem, and you’ll be speeding things up further down the line – reducing friction, headaches and unnecessary delays.
So, what do perfect tickets look like?
Well, they won’t materialise overnight. People need to find their feet with any new process, and that includes understanding best practice for raising tickets. But, once you’ve got a solid template and system in place, things should run much more smoothly. Here’s our quick checklist for solid-gold ticket raising…
Bug reports need to include the following information:
- 1. A title (not a sarcastic or demanding one, just a succinct description of the bug)
- 2. Location of the bug (environment, the device used) and the necessary login details
- 3. The steps to take to reproduce the problem
- 4. What the user was doing when they hit the problem
- 5. What they expected to happen when they did this
- 6. What actually happened as a result of the bug
- 7. Supporting evidence like screenshots
- 8. The priority of the issue (high, medium, low)
- . Any extra information – including details which might make the issue clearer or contextualise it if there have been other problems in the past
Check and double check
Anyone who raises a ticket needs to know they’re creating work for someone else, and play their part in making that work easier. They need to appreciate how pressured bug-fixing is, especially with all the projects you’re putting aside to get new problems solved.
So, encourage them to take a moment and read back through their report, correcting mistakes and checking it makes sense. That way, they’ll be helping you get off to a flying start, rather than initiating a whole lot of back-and-forth by email or phone.
If people give you plenty of detail and stick to a sequence like we’ve done above, it can really help your team prioritise, blast through tickets and make things better. So explain it to them. They probably have no idea how you work, what you need, or how they can make things easier. And they’re probably more than happy to help.
Download our free bug report template
We’ve created a super-helpful bug-report template that you can share with your account managers, streamlining your ticketing and making sure you get the information you really need. You can download it for free, right here.
We’re not saying you won’t still get the odd eye-roll-inducing query, but just remember, when it comes down to it, we all know who the hero is.
Whatever you’re troubleshooting, if you’re with Nimbus Hosting, you’ve got a trusty sidekick to help along the way. We’re always ready to talk tech, unpick problems and generally make you happy, so drop us a line or give us a ring on 0203 005 9181. We’ve got your back.