December 8, 2009 at 8:55 pm
Comments posted to this topic are about the item It's about Perception
December 9, 2009 at 6:55 am
Very good one. One that I forgot a little too frequently. For whatever reason, there's an almost automatic assumption that when there's an error in an app, it's the database. I get extremely frustrated collecting data, over & over, to show that it isn't. Instead of frutstration, I really do need to find a way to change perceptions. Just not quite sure how to go about it.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
December 9, 2009 at 7:12 am
Totally agree with the basic premise of the article. That's why my prefered method of development involves LOTS of user-interaction during the design and building.
- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread
"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon
December 9, 2009 at 7:25 am
I do agree with the editorial, but I would add two things.
1. You also need to sell something new. No one likes change, and to help get that buy in from the user, provide them with as much documentation and help as they can take. We would never do something to make something more difficult. Ultimately it will help the person you are giving it to in the end. Sell sell sell.
2. As people in IT, we tend to like to build things. We are engineers we tend to see a goal and build towards that. Unfortunately, along the way it is easy to forget there may be other ways of doing things. As creators we need a nemesis, a destroyer. Someone who can look at something and break it. We can take this persons views into account in development and then we don't get any surprises when users do something different to "the way it was made to work".
Just my thoughts anyway..
LF
December 9, 2009 at 8:16 am
lfallis (12/9/2009)
I do agree with the editorial, but I would add two things.1. You also need to sell something new. No one likes change, and to help get that buy in from the user, provide them with as much documentation and help as they can take. We would never do something to make something more difficult. Ultimately it will help the person you are giving it to in the end. Sell sell sell.
2. As people in IT, we tend to like to build things. We are engineers we tend to see a goal and build towards that. Unfortunately, along the way it is easy to forget there may be other ways of doing things. As creators we need a nemesis, a destroyer. Someone who can look at something and break it. We can take this persons views into account in development and then we don't get any surprises when users do something different to "the way it was made to work".
Just my thoughts anyway..
LF
I disagree with your first point. I think it's up to the user to request change. We can let them know what's out there and encourage them towards the new but it's ultimately up to them to want it. If the users get the hard sellfrom I.T., they might not want anything.
December 9, 2009 at 8:21 am
I'm forcibly reminded of the recent Verizon Fios commercial, with the Cable guy asking at the focus group:
"I'm curious why we're listening to customers. That seems dumb."
December 9, 2009 at 8:23 am
skjoldtc (12/9/2009)
lfallis (12/9/2009)
I do agree with the editorial, but I would add two things.1. You also need to sell something new. No one likes change, and to help get that buy in from the user, provide them with as much documentation and help as they can take. We would never do something to make something more difficult. Ultimately it will help the person you are giving it to in the end. Sell sell sell.
2. As people in IT, we tend to like to build things. We are engineers we tend to see a goal and build towards that. Unfortunately, along the way it is easy to forget there may be other ways of doing things. As creators we need a nemesis, a destroyer. Someone who can look at something and break it. We can take this persons views into account in development and then we don't get any surprises when users do something different to "the way it was made to work".
Just my thoughts anyway..
LF
I disagree with your first point. I think it's up to the user to request change. We can let them know what's out there and encourage them towards the new but it's ultimately up to them to want it. If the users get the hard sellfrom I.T., they might not want anything.
I also disagree with the first point. Working in a company where the business firmly believes that technology can solve the problem, when they don't even know what the problem even IS much less a good solution, I've found that change can only come when the business is ready for it, all the selling in the world won't force them to accept change their not ready for.
On the other side of the coin, I've found far too many developers today both SQL and other languages, who have gotten out of the habit of asking questions about what they've been tasked with doing. Maybe this comes from the "contractor" mindset where whatever the customer wants goes, but too many times when you deliver exactly what was asked for, the users realize that it's not really what they wanted, or they didn't ask those "what if?" questions to ferret out all of the functionality that isn't on the "happy path" of business process. Being involved in the business, knowing what they are trying to accomplish goes a long way towards being able to ask those what-if questions and manage perception.
December 9, 2009 at 8:26 am
Mmm, I understand where you are coming from. It is partly the culture I have worked in I guess.
The business requests a change. We implement the request based on their requirements. We rollout after testing, but who does it lie with to tell the end user this is coming? IT or the people requesting the change?
Unfortunately where I have worked in the past, IT are the people responsible for informing the user. I guess it's a "rock and a hard place". A business wants benefits of IT improvement, but a user doesn't want change. You have to get their buy in or the project will ultimately fail.
December 9, 2009 at 8:34 am
I think it's a bit of both. IT should look for ways to improve things, and suggest them to users. Let them know that you see a possibility about how to improve a process. That's a bit of selling. However the user has to buy in, or they have to ask for changes.
It's hard when someone forces a change on others. If that happens and you have to tell the end-user, then it helps to let them know who initiated the change and why. If you believe in it, you can try to sell them on it, but don't think that's your job if you don't believe in the chance. If the users better understand how things get into production, they can try to influence them early on.
December 9, 2009 at 9:48 am
When I started work 25+ years ago user requirements and involvement were the norm. It was handled by Systems Analysts. Where are they now? It's all about maximising profit in the short term nowadays and tying users into an expensive maintenance contract
December 9, 2009 at 12:27 pm
Here is a 'truism' that an old mainframer taught to me almost 3 decades ago:
One "awe sh#t" ruins ten thousand "atta boys" every time !
RegardsRudy KomacsarSenior Database Administrator"Ave Caesar! - Morituri te salutamus."
December 9, 2009 at 12:38 pm
Two things always stand out to me.
1. Engaging the users in design and testing. Not everyone has interest or a flair for this but if you are lucky or just plain manipulative, you can convince mgrs that though Bob is a great guy, Cindy might be a better choice to be involved on the project. Cindy will test and give the app a workout. Lets face it, Bob will not even go through the motions (but be the first to complain).
2. A little more work on the design side has great benefits in terms of perception. I'm thinking essentially data entry apps here as an example. The app should flow along with the end user process. To many times I've seen artificial designs that are basically a screen per database table. Ouch. Also, a little attention to detail is key. Who knew how important tab order is? 😛 If the users aren't complaining to management about using the new / improved app, then the perception is that the project/upgrade is successful.
Accuracy of the data and performance are the easy part.
M
December 9, 2009 at 1:02 pm
Many times, the word "perception" is used as a kind of smokescreen to really mean that the (not so smart) users just don't really understand what a great system (or product) we have given them. When used this way, I think there is a lot of Denial going on, where the technologists still are not really admitting that the system/product isn't doing what it needs to do.
Of course there may be some exceptions such as an unusually demanding or grumpy or critical user/customer, but most of the time it's smarter to listen very carefully to user/customer complaints or suggestions - and do something about them.
Technology for technology's sake isn't going to cut it anymore. Many technologists seem to forget that.
The technology needs to support the business - which means it has to help make the business people more effective in their work. If their "perception" is that the technology isn't so helpful to them, they are (almost always) right.
December 9, 2009 at 1:11 pm
joan.skinner (12/9/2009)
When I started work 25+ years ago user requirements and involvement were the norm. It was handled by Systems Analysts. Where are they now?
They are us. No more specs handed down from on high, carved on clay tablets by the high priests. They often didn't make any sense because the systems analysts were out of the technology loop. Now we get to/have to learn the customers business process and figure out what in our tool set can help them.
December 9, 2009 at 1:13 pm
GSquared
That's why my preferred method of development involves LOTS of user-interaction during the design and building
Expanding on GSauared's comment .. Sociology has studied small groups (generally a minimum of 3 people and a maximum of approximately 15), and has developed what is now known as the "Small Group Theory". A short and sweet abridgement of the total theory is basically small groups naturally develop a leader. An individual who members of the group turn to with questions / suggestions. It may or may not be the formal appointed leader (manager/lead DBA). This is the individual that as GSquared said you involve with LOTS of interaction. And when interacting with the leader and that individual comes up with an idea do not answer by saying "I can do that", rather reply with
WE can do that. Make that individual part owner of whatever it is your developing. I have practiced this approach and have found that the group leader can then sell the usefulness / advantages of your work to even the most recalcitrant member of the group. If and when the application hits a glitch I have found that the small group leader is most likely going to tell you WE have a problem, and then help you by explaining it and working with you to fix it.
Viewing 15 posts - 1 through 15 (of 24 total)
You must be logged in to reply to this topic. Login to reply