Professional developers: Do you get good requirements?

[Gunslinger08]

If you're a professional developer, you have a project manager sitting between you and the client. Do your project managers gather and give to you good requirements? Are they inadequate? Do they change after being signed off? Do they even exist?

 

[Cooler]

Most of my projects I play the dual role of Developer/project manager. I get the requirements directly form the client. It saves a lot of time this way. Also I have had clients that will change them on me when I am almost done.

 

[Markbnj]

Most people suck at gathering requirements, and even more suck at synthesizing a system definition from them once they are gathered.

So, no, I don't usually get good requirements. But that's great, because I am a consultant who partly specializes in helping clients recover from really terrible requirements.

 

[replicator]

Most project managers I've worked with live in the world of MS Project and don't play much of a role in developing requirements. Usually they ask some functional lead or analyst to come up with them, who in turn comes to me. Sometimes it is good, but most of the time it is just enough, and I need to fill in the gaps. I prefer it this way because I like to understand the business objective, and the underlying processes. I like to have a clear vision of what needs to be accomplished, which allows me to identify any risks early on.

So to answer your question from my experience, they are not usually good but adequate, and yes they change after being signed off. A good project manager will know how to deal with the users to limit scope creep but some others just don't have the back bone and the developer is the one who ends up working the long hours.....

 

[imported_Dhaval00]

We have to deal with constantly changing requirements... situation seems to be improving, but will have to wait and watch

 

[3NF]

Not really, so as a developer I find myself going to the customer and trying to understand what is they need. Many green PMs will just rehash what it is the customer said they wanted, and not understand why they wanted it, or the business workflows/practices that require it.

 

[KB]

I play a dual role, in that I gather the requirements, then develop for them. Clients change their mind/requirements often. Because I use a rapid prototyping strategy I can usually find out if the requirements were off before it goes too far in development.

 

[Drakkon]

I found even the most established PM's will only just get you very "general" requirements (i.e were developing a system that needs to train people how to sell shoes and it needs to run online and done in 2 months) then the back and forth begins, they will let a little slip as to what the client really wants, but they really want you to be the "idea" guy telling them what you can do so they can go back saying "the developer said they can only give you this" disappointing the customer in some way making the dev look bad.

 

[tfinch2]

In short, no.

 

[EagleKeeper]

Many times no.

If I can interact with the end-user, then requirements can be defined to impliment the project according to the clients needs.

When requirements are created by a group of people that have no concept on implimenting requirements, they are sparse, spotty and usually weak.

Every once in a while, they come back way to detailed

 

[brandonb]

Here is my experience with the jobs I've had

1) Gave good direction, but never explained business knowledge. Would just say "Do this, do that, write to that field in the db from this place on screen. Do this specific calculation." But never answered "Why?" I was S-O-L when he left company, luckily they paid him to come back (probably a huge sum)

2) Gave good direction and explained business knowledge. Only time we had problem is when the client changed things around before release. This was the best place I worked, always had documents and specs written and they made sense and fully explained business knowledge on why. Also the best paying and successful company I worked for.

3) Gave no direction. Would give me specs written by someone who spoke french (and their english sucked.) They used multiple words/terms for the same thing (one day it was contract, the next day campaign, never could figure out what they were saying), so I never knew exactly what I was doing. The boss would freak out with a beta release when it had a bug or didn't work out on first try... I hated this place, luckily they fired me for bad performance, and forced me to company #4.

4) Current place, give me decent initial specs when written up, but if I have a question, this is where they start to fail. I have to ask multiple times to get the correct answer from project manager. Literally, I have to ask a question in email, I get a response, they dont answer the question but tip toe around it, only to force me to ask the exact same question again the next day when I can think of a way to reword my question. This project manager is an idiot, loves to do development in the production environment and like today crashed the entire floor (100+ people) due to reindexing the DB in the middle of the day!

 

[Gunslinger08]

Originally posted by: brandonb
This project manager is an idiot, loves to do development in the production environment and like today crashed the entire floor (100+ people) due to reindexing the DB in the middle of the day!

This is why PMs shouldn't be doing real work.

 

[AlfB]

In a word no. You should always take into consideration who you are getting the information from. Ask pointed questions for details and those that really don't know what is needed will usually start babbling about things that are either not important or not on subject. When you start hearing something that you know is off base, take note to go deeper there and get the details from some that does know what they are talking about. In the end, you are the one that needs to find the requirements out to a satisfactory level for you to accomplish the job. You just need to find the source that can give you the information you need. As to changing requirements, I have yet to be involved in a project that did not change at least some. You should learn to expect it.

 

[RZaakir]

I'm saying, requirements change almost by definition. If you're building a new system for a client, chances are that they don't really know what they need when you are starting out. As things start to firm up, they will get an idea and that's when the requirements get modified. This is probably the catalyst for the whole Agile/XP movement - why spend a bunch of times writing specs and documentation for requirements that are going to be completely different in a month anyway?

With that said, the company that I work for has Information Architects and Business Analysts that generally do a pretty good job of hashing that stuff out - if the project budget allows them to participate.

 

[Apathetic]

If by "good" you mean complete and utter crap, then yes. I get those all the time.

Even if through blind, dumb luck they should happen to completely document what's supposed to happen when things work, they NEVER document what's supposed to happen when things fail.

Dave

 

[narcotic]

I managed several projects myself, and currently working under another project manager, most our projects are fairly big scale, thus requirements have to be throughly discussed prior to the actual beginning of development, though some do change while work is in progress.