How to handle management trying to interfere with the project (including architecture decision) [closed]_问答_开发者

Closed. This question is opinion-based. It is not currently accepting answers.

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 3 years ago.

Improve this question

I feel this is not a very good question to post on SO, but I need some advice fro开发者_StackOverflow社区m experienced developers... (I'm a second year developer)

I guess this is a problem to many, many projects, but in our case, it is getting intense. There were very strong interference from the management, that our development was severely impacted.

Now we were happily producing results, but then I get a request for a "meeting".I have a friendly relationship with them, but I feel very daunted at the thought of talking about it all over again.

What would you do if you were in this situation?

There were so much interference from people that don't know a bit about software development,

While you claim may be true, when you say "(I'm a second year developer)" that indicates that, perhaps, you may have quite a bit to learn, also.

In particular, you should consider that they need to know if their money is being spent wisely.

Silence does not create confidence.

We had to literary escape to another location to get any useful job done.

And how did they people paying for your services feel about this? Did they feel confident in you?

Do they believe you know what you're talking about? Remember, you only have 2 years experience.
Do they believe you will get things done? Why do they believe this?
Do they understand you are actually getting things done? How will they know this if you won't talk to them? Remember, you only have 2 years experience.

It may be possible to spend more time providing information so that they have confidence in you. You have to build trust. Remember, you only have 2 years experience.

Sadly this can be a reality of the job. You must stay professional, but you may also have to be tough. In my experience, you must clearly state the effect of what someone above you is asking, then you must ask them directly if they want you to go ahead even if the result is detrimental development.

Management: "We need it to read minds"

You: "We can do that, but we'll have to rewrite x, y, and z. It will stall our project and add 3 years to development. Are you sure you want us to implement this?"

At this point if they say yes, it's off your back. If you think it will make you look bad if they say yes, then do it by email so there is a record.

Also, I believe if you are patient, non-technical people will understand more than you give them credit for. If you hide everything from them, then they can not make good decisions.

Maybe suggest weekly feedback meetings; or at even shorter intervals. At least that way you can have a continuous thought. Also the interaction should be limited to key people.

Meet with them, explain the situation (that either what they're asking for isn't feasible or otherwise insane), present options and your recommendation(s), and let/make them make the decision.

Keep in mind that you're only allowed to argue (professionally, mind you) before the decision is made. Once it's made - you're either expected to carry out that decision, die trying, or walk away. Unless you have an incredible amount of trust built-up (which it doesn't sound like you do), you really don't want to implement your own plan - there's no upside (no, being proven right isn't actually a positive in these situations), and a lot of potential downside.

As for the future - you really want to avoid getting into those situations to begin with. That means building trust from day 1 by always being professional and respecting the client's wishes and desires - while gently helping them to solve their problems. It also means you will need to turn down "problem" clients/bosses or projects, and learn to manage (and meet) expectations.

A manager wades in...

Managers aren't as irrational as many developers would have you believe. If the managers are questioning things then it's likely because they don't have confidence in how things are. To improve things for both groups - developers and managers - you need to work out what the real issue management have (I'm guessing lack of confidence in the way the project is progressing) and how best to address that issue at minimum cost to the developers. Providing information up to management is, however tedious you find it, part of a developers job. The trick is to find a mechanism that allows you to do so at minimum cost to you.

I'd also add that in many cases the manage is either the "client" or at least the client's representative and as such it is their right to change their mind and interfere. It may "damage" the project or lead to inefficiencies but better to change direction half way through than, for the sake of "the development" continue with something which no longer meets the business need.

I've spent a decade as a programmer and a decade as a team leader / manager and I can honestly say that most (not all) of the things management did which annoyed me as a programmer weren't unreasonable when viewed from the management perspective.

Organisations are large and messy and, even in software development houses, it's hard to set the whole thing up to produce an ideal set up for developers. Outside of software houses in organisations where producing code is a by-product of the business rather than the key aim, it's all but impossible as it will always be secondary to the key aims of the business.

It's irritating but there is a reason you're paid to go to work and ultimately it's because you're doing what someone else needs in the way someone else needs you to do it rather than what you want how you want.

The trick is to improve things where you can, and learn to live with the things you can't and not let it stress you out.