Frustrating Software Fix or Change Requests
Every now and then, a huge groan can be heard from the normally almost silent room that is home to our team of software developers. The cause is usually a poorly worded fix or change request. An unclear request makes it difficult to effect a fix and results in fixes taking longer than they should, leading to frustration on both sides. For example:
“Tags show GYYV is available on this site but won’t allow GYYV as an option”
The first question is what is GYYV? And “this site” – which site? 
“Bring FG through on current plan”
What is FG and are you both looking at the same ‘current plan’? What is meant by ‘bring through’?
If you do come across a bug in a piece of software, or want to change the way something works, providing a good fix request will make your developer’s life much easier and help them to provide you with that fix much more quickly.
So, what are the golden rules of fix and change requests?
1. Always include important and descriptive information.
It is wise to assume that the software developer who receives your request is not familiar with your specific software functionality and knows nothing about the nature of your business. Tell them who you are, which piece of software you are referring to, what it does, which site it is on – anything, in fact, that will make life easier.
2. Provide detailed steps that will allow the developer to replicate what you have done to reveal the error.
Where did you start in the system and what did you click on / select to get to the point where something didn’t work.
3. Screenshots.
When sending your request, attach screenshots of what is wrong. And screenshot the whole screen, not just a tiny section that doesn’t provide the whole context (yep, we’ve had those kind of screenshots before now!). Also, it is better not to paste these screenshots into another programme (Word is just – and only just – about OK but don’t even think about putting them into Excel).
4. Don’t use acronyms.
Do you know what GYYV or FG mean? Nope, me neither – I made them up in case anyone did know what the original acronyms meant and I was giving too much away! Just by way of illustration, did you know that DM can mean data mining but can also mean direct message; IM is instant messaging, internet marketing or input method; PM could be project manager, program manager, product manager or preventative maintenance? I’m not saying type everything out in full every time, but indicate your meaning clearly the first time you use the acronym at least: eg We need to look at the Program Manager (PM).
5. Remove all ambiguity.
If there is even a suggestion that, for example, there could be two different systems or locations, make sure you specify which one. Read back your report and ask yourself: “If I didn’t have the error or what I want to change in front of me, would I be able to find it again from what I have written there?”
Taking a little time to send a well worded, detailed fix or change request will pay dividends and ensure that your team of developers aren’t groaning and scratching their heads at the other end of the computer. If you have software that isn’t working for you, our team of developers can help. Roar Software specialise in bespoke software (including mobile App development), legacy systems support and systems integration.
