April 27, 2012 at 2:20 pm
Hello,
I find myself in a situation where the business users that I am working with to create an application solution for them, are driving me crazy because they refuse to want to (or are incapable of) understand the complexities of the requirements that are needed on the programming side. They say things like "all you have to do is this" when what they want me to do circumvents and brakes other things they are pushing to have completed. They can't see the puzzle and it's 1000 pieces. They seem to think that everything happens in isolation and that you can program that way. When I try to elaborate on things they just look at me like I am crazy as if I don't understand what they want, as if thinking "Why the Hell doesn't he just do it!"
Have other people ran into this type of thing and how on earth did you make things work out?
Frustratedly yours,
Sean
A clever person solves a problem. A wise person avoids it. ~ Einstein
select cast (0x5365616E204465596F756E67 as varchar(128))
April 27, 2012 at 2:28 pm
Such is the complication of IT people everywhere. "Normal" people think about what software could/should do and have concept of programming. The challenge is to take incredibly vague and often contradicting requirements and make software that can do it. What you have to learn to do is to keep the complexity to yourself. They don't understand, they don't want to understand. That is why we get paid well. We are like the modern day Merlin. We do magic stuff with 1s and 0s. It is often frustrating and always challenging, of course that is why most of got into this line of work in the first place.
_______________________________________________________________
Need help? Help us help you.
Read the article at http://www.sqlservercentral.com/articles/Best+Practices/61537/ for best practices on asking questions.
Need to split a string? Try Jeff Modens splitter http://www.sqlservercentral.com/articles/Tally+Table/72993/.
Cross Tabs and Pivots, Part 1 – Converting Rows to Columns - http://www.sqlservercentral.com/articles/T-SQL/63681/
Cross Tabs and Pivots, Part 2 - Dynamic Cross Tabs - http://www.sqlservercentral.com/articles/Crosstab/65048/
Understanding and Using APPLY (Part 1) - http://www.sqlservercentral.com/articles/APPLY/69953/
Understanding and Using APPLY (Part 2) - http://www.sqlservercentral.com/articles/APPLY/69954/
April 27, 2012 at 2:36 pm
Yes, and what makes you think we made things work out?
It is frustrating. One question, when you are trying to explain the why not's are you talking techno-babel or in their language? It may help to find one person who is willing to listen and help bridge the gap. The key thing is to learn their language, not force them to understand your language.
Small steps.
April 27, 2012 at 2:43 pm
That is the rosey side of it. But what do you do when their business requirements contradic themselves? When they refuse to see that they do and the next week they change them again and state they hadn't changed them at all. I have always loved a challenge and that is why I got into the field as well.
I could spend 40 hours a week just diagramming processes to them and then giving them examples to prove this through the data. My obstacle is that the business user I am doing this for is my Supervisor and she is antiquated in her knowledge of the data and the the processes, but believes she is the ultimate and complete authority on the subject.
Sean Lange (4/27/2012)
Such is the complication of IT people everywhere. "Normal" people think about what software could/should do and have concept of programming. The challenge is to take incredibly vague and often contradicting requirements and make software that can do it. What you have to learn to do is to keep the complexity to yourself. They don't understand, they don't want to understand. That is why we get paid well. We are like the modern day Merlin. We do magic stuff with 1s and 0s. It is often frustrating and always challenging, of course that is why most of got into this line of work in the first place.
A clever person solves a problem. A wise person avoids it. ~ Einstein
select cast (0x5365616E204465596F756E67 as varchar(128))
April 27, 2012 at 2:51 pm
TeraByteMe (4/27/2012)
That is the rosey side of it. But what do you do when their business requirements contradic themselves? When they refuse to see that they do and the next week they change them again and state they hadn't changed them at all. I have always loved a challenge and that is why I got into the field as well.I could spend 40 hours a week just diagramming processes to them and then giving them examples to prove this through the data. My obstacle is that the business user I am doing this for is my Supervisor and she is antiquated in her knowledge of the data and the the processes, but believes she is the ultimate and complete authority on the subject.
Sean Lange (4/27/2012)
Such is the complication of IT people everywhere. "Normal" people think about what software could/should do and have concept of programming. The challenge is to take incredibly vague and often contradicting requirements and make software that can do it. What you have to learn to do is to keep the complexity to yourself. They don't understand, they don't want to understand. That is why we get paid well. We are like the modern day Merlin. We do magic stuff with 1s and 0s. It is often frustrating and always challenging, of course that is why most of got into this line of work in the first place.
First, all of this is documented, correct? Now, the wrong thing to do is to throw that right back in their face. What type of development methodology are you using currently?
April 27, 2012 at 2:56 pm
That can be complicated for sure. I have been in that situation and the way I handled it was to make the process a little more formal. After meetings I would write follow up minutes and share them with everyone involved. Then write up formal specs for approval. When the specs change in a couple weeks you now have concrete evidence of what it was in the past. The best approach is to keep it very objective. When the next meeting produces new rules that contradict last weeks decision you just write that into the minutes/specs. All specs should include an assumptions section and a challenges section in addition to the definition. This gives you a nice area to layout the challenges (read that as contradicting garbage that requires a decision above your pay grade). Then make is clear that you are happy to make it work one way or the other. It doesn't matter which way it will work but it can't be both.
Keep in mind that many of these decisions are probably not thought through to anything resembling the level required by you to implement them. They are usually the result of a light bulb turning on during a meeting and stated as new rules a few seconds later. Often times when reflecting on these thing it becomes more obvious about how that won't work quite exactly as specified. Your success at this point is based on how you handle it. If you get frustrated and say "that won't work" you will continue to be frustrated.
My approach to these situations is to ignore it. Then when I am driving home with some killer tunes on I toss the idea around in my head. I am glad I drive home on backwoods roads or people would think I am crazy because I talk to myself constantly while driving to/from work. I do however spend this time to come up with solutions for these types of things. The point I am making is that it is far better to bring up these types of things and offer suggestions for ways to work around the technical challenges presented by conflicting business rules instead of just saying it can't be done.
_______________________________________________________________
Need help? Help us help you.
Read the article at http://www.sqlservercentral.com/articles/Best+Practices/61537/ for best practices on asking questions.
Need to split a string? Try Jeff Modens splitter http://www.sqlservercentral.com/articles/Tally+Table/72993/.
Cross Tabs and Pivots, Part 1 – Converting Rows to Columns - http://www.sqlservercentral.com/articles/T-SQL/63681/
Cross Tabs and Pivots, Part 2 - Dynamic Cross Tabs - http://www.sqlservercentral.com/articles/Crosstab/65048/
Understanding and Using APPLY (Part 1) - http://www.sqlservercentral.com/articles/APPLY/69953/
Understanding and Using APPLY (Part 2) - http://www.sqlservercentral.com/articles/APPLY/69954/
April 27, 2012 at 3:00 pm
Sean Lange (4/27/2012)
That can be complicated for sure. I have been in that situation and the way I handled it was to make the process a little more formal. After meetings I would write follow up minutes and share them with everyone involved. Then write up formal specs for approval. When the specs change in a couple weeks you now have concrete evidence of what it was in the past. The best approach is to keep it very objective. When the next meeting produces new rules that contradict last weeks decision you just write that into the minutes/specs. All specs should include an assumptions section and a challenges section in addition to the definition. This gives you a nice area to layout the challenges (read that as contradicting garbage that requires a decision above your pay grade). Then make is clear that you are happy to make it work one way or the other. It doesn't matter which way it will work but it can't be both.Keep in mind that many of these decisions are probably not thought through to anything resembling the level required by you to implement them. They are usually the result of a light bulb turning on during a meeting and stated as new rules a few seconds later. Often times when reflecting on these thing it becomes more obvious about how that won't work quite exactly as specified. Your success at this point is based on how you handle it. If you get frustrated and say "that won't work" you will continue to be frustrated.
My approach to these situations is to ignore it. Then when I am driving home with some killer tunes on I toss the idea around in my head. I am glad I drive home on backwoods roads or people would think I am crazy because I talk to myself constantly while driving to/from work. I do however spend this time to come up with solutions for these types of things. The point I am making is that it is far better to bring up these types of things and offer suggestions for ways to work around the technical challenges presented by conflicting business rules instead of just saying it can't be done.
You're not crazy because you are talking to yourself, and it is okay to answer yourself. I do it too. The problem arises when you say "huh, what did I say?" 😉
April 27, 2012 at 3:04 pm
I hate it most when I lose the arguments. :Wow:
_______________________________________________________________
Need help? Help us help you.
Read the article at http://www.sqlservercentral.com/articles/Best+Practices/61537/ for best practices on asking questions.
Need to split a string? Try Jeff Modens splitter http://www.sqlservercentral.com/articles/Tally+Table/72993/.
Cross Tabs and Pivots, Part 1 – Converting Rows to Columns - http://www.sqlservercentral.com/articles/T-SQL/63681/
Cross Tabs and Pivots, Part 2 - Dynamic Cross Tabs - http://www.sqlservercentral.com/articles/Crosstab/65048/
Understanding and Using APPLY (Part 1) - http://www.sqlservercentral.com/articles/APPLY/69953/
Understanding and Using APPLY (Part 2) - http://www.sqlservercentral.com/articles/APPLY/69954/
April 27, 2012 at 3:12 pm
Actually none of this is documented. They are unable to give me documentation at all on the processes other then high level business processes that were created years ago. They have been band-aiding and workarounding the system sense. Seventy percent of the time data standards are enforced and the remainder they have manual processes that are incorporate. I haven't seen on a business requirement doc sense I have been here the last 3 months. I am reverse engineering everything.
Here is an example. I am told to parse filenames to get the GroupID of the file, which is then input into a table with the other information about the file. The standard is that the first 4 characters of the name will contain the groupid. Easy enough use a substring function. Here are examples of filenames that I am to parse (as we receive it from the customer):
EDIG264504272012.txt.pgp
C349804272012EDI.txt
EDI2484.txt
3584EDI.txt
EDIdocument.txt
One example of one file type (EDI). Now compound this by a couple thousand groups with many different file types. Granted like I said, 70% of the files may meet the standard but it is purely at the whim of the customer to what they name the file. Their expectation is that I can program around this situation to extract the correct GroupID.
Lynn Pettis (4/27/2012)
TeraByteMe (4/27/2012)
That is the rosey side of it. But what do you do when their business requirements contradic themselves? When they refuse to see that they do and the next week they change them again and state they hadn't changed them at all. I have always loved a challenge and that is why I got into the field as well.I could spend 40 hours a week just diagramming processes to them and then giving them examples to prove this through the data. My obstacle is that the business user I am doing this for is my Supervisor and she is antiquated in her knowledge of the data and the the processes, but believes she is the ultimate and complete authority on the subject.
Sean Lange (4/27/2012)
Such is the complication of IT people everywhere. "Normal" people think about what software could/should do and have concept of programming. The challenge is to take incredibly vague and often contradicting requirements and make software that can do it. What you have to learn to do is to keep the complexity to yourself. They don't understand, they don't want to understand. That is why we get paid well. We are like the modern day Merlin. We do magic stuff with 1s and 0s. It is often frustrating and always challenging, of course that is why most of got into this line of work in the first place.First, all of this is documented, correct? Now, the wrong thing to do is to throw that right back in their face. What type of development methodology are you using currently?
A clever person solves a problem. A wise person avoids it. ~ Einstein
select cast (0x5365616E204465596F756E67 as varchar(128))
April 27, 2012 at 3:19 pm
TeraByteMe (4/27/2012)
That is the rosey side of it. But what do you do when their business requirements contradic themselves? When they refuse to see that they do and the next week they change them again and state they hadn't changed them at all. I have always loved a challenge and that is why I got into the field as well.I could spend 40 hours a week just diagramming processes to them and then giving them examples to prove this through the data. My obstacle is that the business user I am doing this for is my Supervisor and she is antiquated in her knowledge of the data and the the processes, but believes she is the ultimate and complete authority on the subject.
There are two things that have worked for me when dealing with these types of people... which happens all too often in our line of work:
First, instead of constantly telling them why they can't do the things they can't do, tell them what they need to do and why. For example, if someone tells me to do two things that contradict each other, instead of saying "X and Y contradict each other" I'll tell them "We need to do X... and since we're doing X, we need to do Y because..." - Make them be the one to argue the illogical and there is a better (note, better, not at all certain) chance that a lightbulb will come on in their heads and they'll see why they're being illogical.
Second, whenever one of these discussions takes place, document it. Use email. And again, don't take the "we can't do that" stance - explain in your documentation what needs to be done, and why it needs to be done that way. If someone disagrees with you, discuss it - but again, from the positive "We need to do X because..." perspective instead of the negative "we can't do that" perspective.
We've all had that supervisor who knows everything that was relevant twenty years ago. And like the rest of them, yours isn't going to change. But what I have found is that if you approach arguments constructively and force them to be the one to deconstruct your argument, you are far more likely to get through to them. Especially if they're having to defend their deconstructions to an entire team.
Viewing 10 posts - 1 through 9 (of 9 total)
You must be logged in to reply to this topic. Login to reply