RFCs, test findings and socially disabled ICT people

[Mich the Tester]

Right then, here we are doing User Acceptance Testing. What tends to happen is that users find various issues, some of which are functional faults that have to be solved, some others to do with User friendliness and some which are ‘cosmetic issues’; those cosmetic issues, when piled up together can have a serious effect on the usefulness of the application. Some issues are actually ‘works as designed’, but it’s clear that there will need to be a change if the users are to successfully use the app.

So findings are noted, and as Test Manager I try to ensure we’ve separated issues from possible change requests and categorise everything correctly. Even so, whether something is a ‘request for change’ or a ‘bug’ always leads to discussions where smartypants ICT project manager/dev team leader maintains a position that it’s a ‘RFC’ and acceptant, who has the pot of money to pay for all this maintains ‘it’s a bug’. Some of these discussions actually cost more than just solving the issue. User notices that the sentence in a message box could be slightly more clear and asks for a change; about two minutes work for the dev team. But no, dev team would rather have a long, unfriendly e-mail discussion about the ‘point of principle’ that this is and RFC, and as such should not have been entered in the bug system!

I understand that when an external software builder is building to contract he wants to limit extra work, but in this case it's an internal dev club. Anyway, I see all this and think to myself ‘isn’t this all a bit sad?’ What’s the chance that said dev team leader would actually bother with this kind of discussion if he had a healthy sex life? Isn’t all this tosh just evidence of the lack of social skills and empathy that makes so many ICT people unable to comprehend what a user actually wants?

Oh well, shall send an invoice for telling my tester not to bother discussing the merits of a minor adjustment to a sentence.

[Zippy]

Been there, done that and you have my sympathies. On the whole, it's safer to call the bug system an issue management system but that doesn't always get you off the hook

[Mich the Tester]

Been there, done that and you have my sympathies. On the whole, it's safer to call the bug system an issue management system but that doesn't always get you off the hook

Yep, but when someone's gone and called it 'Bugpoint' that's a bit difficult.

[doodab]

Anyway, I see all this and think to myself ‘isn’t this all a bit sad?’ What’s the chance that said dev team leader would actually bother with this kind of discussion if he had a healthy sex life? Isn’t all this tosh just evidence of the lack of social skills and empathy that makes so many ICT people unable to comprehend what a user actually wants?

We know what users wants. Mostly, they want to do **** all and have us read their minds.

It often turns out that these are things that could have been spotted earlier and remedied fairly easily if the users had actually bothered to participate in the requirements & testing process when they were initially asked and for the full period instead of giving it two hours effort at the last possible moment.

Because of this, if you don't maintain a strict distinction between bugs and changes, you end up with more and more small changes classified as bugs, which eventually adds up quite a lot of work that has to be done twice, and the main reason it has to be done twice is because the users were too ******* lazy to get their arses in gear in the first place.

Understanding peoples needs and giving them what they want works both ways. If you make people's lives harder because you can't be bothered to do what they have asked you to do when they asked you to do it you can hardly complain when they return the favour.

(I feel much better now)

[Mich the Tester]

We know what users wants. Mostly, they want to do **** all and have us read their minds.

It often turns out that these are things that could have been spotted earlier and remedied fairly easily if the users had actually bothered to participate in the requirements & testing process when they were initially asked and for the full period instead of giving it two hours effort at the last possible moment.

Because of this, if you don't maintain a strict distinction between bugs and changes, you end up with more and more small changes classified as bugs, which eventually adds up quite a lot of work that has to be done twice, and the main reason it has to be done twice is because the users were too ******* lazy to get their arses in gear in the first place.

Understanding peoples needs and giving them what they want works both ways. If you make people's lives harder because you can't be bothered to do what they have asked you to do when they asked you to do it you can hardly complain when they return the favour.

(I feel much better now)

I'm glad you feel better; that's what a good rant is for. Sex is better though.

Anyway, I take your point and can recognise a lot of what you're saying. However, documenting user requirements and designing for ease of use is not simply about asking users to participate; a good designer will actually advise users on what is possible or workable on the basis of experience. In reality, the 'designer' is often a tool monkey or worse still a SAP/Siebel/Peoplesoft/Oracle/<insert other brandname> 'consultant' who can't picture the world in terms unknown within his narrow understanding of his chosen software package.

[Zippy]

Keep it up lads - this is like being at work. Now don't get me started on Bob ...

[doodab]

I'm glad you feel better; that's what a good rant is for. Sex is better though.

I prefer drinking to shagging when I'm in a bad mood, but each to their own.

[original PM]

ah yes - I spend a lot of time designing software etc for our internal developers and it is true that the users often put little to no effort in - but the thing is that is how it has always worked mainly because the users also have a day job - which normally takes up most of the time.

Rarely do you find users of a system have time to down tools and sit mulling over screen designs etc. Thing is I have never come across any business where user have any time and yet whenever you get new project manager bod in there seems to be some confusion over this.

Anyway to get to the point finally with our internal developers we make sure we deliver what is agreed initially and then if things need changing - well they get changed be it a cosmetic change which enhances useability or a changes reuqired to make the system work. Obviously we have a limit and do not go stupid on allowing all teeny tiny changes go through but in general we try and meet the users needs.

What does always confuse me is why as Mich says there seems to have to be big discsusions around whether it is a bug, change or whatever - the fact is the software is not meeting required standard so sort it out.

Obviously this wouild all work fine if it wasn't for pointless fu<kwits playing stupid games.

Probably won't work overly well with external developers either.

But hey so what

[SupremeSpod]

I'm glad you feel better; that's what a good rant is for. Sex is better though.

Anyway, I take your point and can recognise a lot of what you're saying. However, documenting user requirements and designing for ease of use is not simply about asking users to participate; a good designer will actually advise users on what is possible or workable on the basis of experience. In reality, the 'designer' is often a tool monkey or worse still a SAP/Siebel/Peoplesoft/Oracle/<insert other brandname> 'consultant' who can't picture the world in terms unknown within his narrow understanding of his chosen software package.

Don't confuse "Designers" with "Developers"...

[doodab]

What does always confuse me is why as Mich says there seems to have to be big discsusions around whether it is a bug, change or whatever - the fact is the software is not meeting required standard so sort it out.

Obviously this wouild all work fine if it wasn't for pointless fu<kwits playing stupid games.

Probably won't work overly well with external developers either.

Fixing stuff usually takes time and costs money, so it's a question of who gets blamed for the project being late and going over budget.