Canada's National Post has an article that won't surprise anyone who has worked on large projects. "people " challenges are often more difficult than technical ones.
It's just surprising that such basic mistakes are still being made.
- inadequate support from executives
- poor understanding of how the project fits in the business
- large requirements document up front that the developers are expected to interpret without further communication
- inadequate training
- no attempt to sell (never mind tailor) the system to the people who will use it
Those are basic, basic mistakes. I don't think you even need experience to understand why they are mistakes. The conclusion of the article is on target: avoiding people problems is a core job of management.
It becomes a major role of (management) to kind of herd the cats in and make them all line up in a reasonable way,said Barry Wilderman, an analyst at the Meta Group.That's why this stuff is so hard.
Uhm, yeah. Understanding people and organizations can be hard and getting them to work together smoothly is even harder.
However, I don't believe developers can afford to isolate themselves in a technical cocoon so one claim doesn't cut it with me. Developers are least qualified to validate a business requirement. They're either nerds and don't get it, or they're people in another culture altogether
. Listen, no outsider gets it
. I'm
not saying that every developer needs to be schmoozing with users
but every developer needs be aware. The relationship between the
developers and the people who will use the software matters. If
there are problems in that relationship, that's a huge risk that developers need to address.
In response to: "The relationship between the developers and the people who will use the software matters. If there are problems in that relationship, that's a huge risk that developers need to address."
I disagree. Someone wisely said, "It's good to have a reminder: people's motivations are rarely simple. Organizations are often not rational in the economic sense." Especially in larger organizations, it can be dangerous to assume that your job as a software developer is to satisfy the user.
Many large organizations intentionally construct barriers to assure that software developers and users don't get talking to each other. They have their reasons: economic, political, or whatever.
A developer certainly can ask questions of the management and make suggestions. But always remember: you're being paid to do what the company wants done, not necessarily what you think should be done. If you can't deal with what you're asked to do, say so. Maybe you can be put on another project, maybe you'll just have to leave. But don't subvert management's plans by doing what you in your infinite wisdom happen to think is best.
I basically agree with you, Doug. It's not for me as an individual developer to subvert management decisions. If I had raised the issue and I was not getting anywhere, I would have to see what my personal options were.