views:

186

answers:

8

Our product design team has a very active imagination (not a bad thing), but they tend to want things that are one or more of the following:

  • Not possible
  • Not practical
  • Lack adherence to usability standards
  • Just plain stupid

I try my best to explain my case. Sometimes I win, sometimes I don't. How do you handle situations like this?

+2  A: 

give insane time estimates as far as how long it will take.

Sara Chipps
indeed. Make their head spin with $$ signs, i like that. I tend to overexplain things, this is much simpler.
mattlant
Exactly! If reasoning fails, estimate higher. However, be careful not to estimate higher than about twice the time you deem a reasonable estimation or else you will quickly lose credibility.
steffenj
If there is a problem with what is being asked of you, or if it's something that genuinely isn't possible, then you should be up-front about it. Don't just pad time estimates and put off your problems.
bhinks
A: 

I usually will find credible references on they web about why not to do what they want and forward the links to them + team lead. It works a good part of the time.

Gthompson83
A: 

The Agile concept works pretty well in cases like these. If I can oversimplify for a minute, you work with the product team to break their desired features down into "user stories" that will fit into a sentence or two on an index card. (For example, "I want to be able to save my document in XML format." or "Convert incoming fax to actual live elephant.") Your development team can quote each user story in terms of hours or days. Work with the product team to put these stories in a priority order of implementation, then work your way down the stack until the project is declared done.

(Agile people, yes, I'm aware I'm making this sound a lot simpler than it is.)

See if you can spend some time around an Extreme Programming or Scrum environment for a while and pick up what you can.

catfood
+3  A: 

If you know you're right, you really need to win those arguments. Politics is a huge part of being a successful programmer, like it or not. Brilliant engineers who can't win people over to their side end up wasting their time implementing garbage that eventually makes them look bad.

Then again, sometimes programmers get used to being right all the time and won't listen to innovative new ideas. Make sure you really think about what the designers want to do first, to make totally sure their ideas aren't actually cool ones before you embark on your mission to squash them.

Eric Z Beard
I consider myself pretty open minded. There have been times that what they've suggested actually worked out or even worked better than what I had in mind. Those times have been pretty scarce, though.
Jeremy Cantrell
+3  A: 

If you start with a criticism, the chance of you convincing someone goes down greatly.

Here are the key points to winning someone over to your point of view from Dale Carnegie's How to Win Friends and Influence People:

  1. The only way to get the best of an argument is to avoid it
  2. Show respect for the other person’s opinions. Never say, “You’re wrong.”
  3. If you are wrong, admit it quickly and emphatically
  4. Begin in a friendly way
  5. Get the other person saying “yes, yes” immediately
  6. Let the other person do a great deal of the talking
  7. Let the other person feel that the idea if his or hers
  8. Try honestly to see things from the other person’s point of view
  9. Be sympathetic with the other person’s ideas and desires
  10. Appeal to the nobler motives
  11. Dramatize your ideas
  12. Throw down a challenge

It's a great book and cheap: Amazon Link

Michael
+2  A: 

"Not possible"

Always tell your product team the truth! At the end of the day you are the one who has to implement the impossible features. And this will break your neck.

"Not practical" && "Lack adherence to usability standards"

If you have a more practical solution, then try to convince them. If they don't listen to you, go one step further (talk to your common boss).

"Just plain stupid"

Never argue that something is stupid (even if it is so)! Find good reasons and argue.

Note: Working in a team means that you always have to make agreements. If you have to agree too often to decisions you don't like, you probably haven't found the right team to go with.

koschi
I might be thinking "this is stupid", but I rarely word it as such :)
Jeremy Cantrell
+3  A: 

I have to argue the question, because I've been the one to say, "That's impossible!" and then turn around and write code that does just that. Really, it comes down to your ability to convey your needs and concerns. Like Sara said, give them a time table that makes it less appetizing and maybe they won't ask for it. However, they might find someone who at least says they can do it. At that point, your opinion probably won't matter because you'll be finding a new job. ;)

My experience is that if you explain why it isn't practical, possible, or just plain silly you are more likely to get a positive response. Now, working with designers you often have to use more common language which can be difficult for us programming types. You have to think about what you're going to say way before you say it, and that helps you to formulate why it really is wrong.

You win some, you lose some.

And, its funny you post this, I have a friend who does just that: Suggests crazy, outlandish things that are just plain inconceivable. Funny thing is, they always get done!

Abyss Knight
+1  A: 

One problem that crops up for me is when such ideas are floated in a meeting I would have to provide reasons on the spot. I can be combatitive spur of the moment but I cannot convey ideas that are based in my experiences without any forethought. Very few people can, that's why its usually a pissing match rather than a reasoned discussion.

So go back to your desk and write an essay. Get your thoughts straight, put together an argument and then cc everyone.

George Mauer