IT Employment

General discussion


bridging the analyst/developer gap

By mzii ·
how you you suggest i get the Analysts and Developers on my project team to speak the same language. As we all know, most Analysts speak Business and most developers speak in Code...i have this problem and i was wondering how i can get them to understand each other and their requirements.

what tools, processes or spftware can i have them use so that the expectations and requirements are clear cut

This conversation is currently closed to new comments.

Thread display: Collapse - | Expand +

All Comments

Collapse -

by Jaqui In reply to bridging the analyst/deve ...

lock one from each group into a room together. They are responsible for creating the expectations and requirements.
they cannot leave the room until they have gotten it finished, and you have a member of each group that can explain them to each group.

Collapse -

by Jaqui In reply to

James is right,
the best way is all should get together and go over what is wanted. with each having an opportunity to state thier concerns.

one person "chairing" the meeting to knock heads when the speaker starts the lingospeak that will just confuse the rest.

even the customer will use lingo for thier particular specialty and confuse everyone else.

it would be nice if there was someone working with you that could, as project team leader, understand all viewpoints, and make sure every part of the team knew exactly what was needed from them. unfortunately, such people are extremely rare, and even if there is one person on staff who can do it, they may not be available for the project.

Collapse -

by mzii In reply to bridging the analyst/deve ...

I might end up without a team at the end of
but honestly, i need these two 'factions' to speak the same lingo..and i need them to do so with a reasonable respect for each other. i do not want to create a utopia situation, but rather come up with a feasible solution. are there courses one can recommend i send them to help them understand easch other better?? or is there something i can do in the organisation to foster an understanding

Collapse -

by JamesRL In reply to bridging the analyst/deve ...

Well from my perspective, having worked both sides of the divide....

Business analysts should be translating the user's/stakeholders wants and desires into hard clearly stated requirements. Developers should be able to take these requirements and develop code, testers should be able to take these requirements and design at least high level test plans.

If the groups are communicating well or interacting well, perhaps its time they and you should re-examine the process - how do they communicate to each other.

I find written requirements insufficient in many cases. I prefer first a project kickoff meeting where the high level objectives(or high level requirements) are discussed early on. All parties should walk out of the meeting with a clear idea of why the project is going forward - not every developer should be there, but key ones should.

Then its a good idea to get key developers involved in the requirements gathering process. Have them attend some of the meetings with users. It will get them up to speed sooner.

If you must, hold a requirements review meeting(s) with users and developers. It would be lead by the BAs, but again the developers will learn from first hand experience.


Collapse -

by frostbite In reply to bridging the analyst/deve ...


there may be a perspective difference in each organization but in most organizations I worked with, Analysts are perceived to have better communication skills (verbal and written) and Developers better technical skills.

Usually, the burden of bridging the communication gap between the Business side (clients) and technical side (IT/development) falls on the analysts.

What you may need to do is review what is the underlying problem why they do not understand each other. Are the requirements documents produced by the analysts too ambiguous that the developers cannot understand them or is there really a gap with the comprehension skills of the developers?

Collapse -

by DC Guy In reply to bridging the analyst/deve ...

I agree with JP, and as a nearly 40-year member of the IT profession I can hardly be accused of bias in the other direction. It is less true today than it was in my day, but many people still choose this field precisely because their "people skills" are weak and working with technology is easier for them.

There's no quick fix. Send your developers to every communication/writing/getting along/touchie-feelie class that comes along. Make each one of them give presentations frequently even when they're not absolutely necessary. Make them do their own documentation and don't let them put it off. Drag them to the company Christmas party and make them dance with end users.

"Colocation" is a term that was in vogue about 20 years ago. The idea was that if you put the developers' desks in the end users' office space, they will pick up the skills naturally. The same way your puppies become housebroken more quickly if your house is full of adult dogs to imitate.

It works with dogs but it must not have worked with programmers because I haven't heard of it in a long time.

You will have to attend many meetings between the developers and analysts to be referee and translator, and to make sure nobody forgets who is there to serve whom. I assume that nobody told you your job was going to be easy. ^_^

Collapse -

by SridharPandu In reply to bridging the analyst/deve ...

Thats why we have visual modelling languages like UML and the IDEF(1 to 9)X series. IDEF1X is used for data modelling. Using visuals removes the communication gap. This should be the medium of communication, and not verbal like emails and documents.

Just to draw an anology, a music composer doesnt use verbal languages to communicate to the orchestra, he pens the note symbols on staves.

For that matter even traffic signs use visual notations!

Guess you should use Visual modelling. I would also like to add that initially the team will find it difficult to adjust to this new method but then over a period of time the team reaps the benefits of less communication overhead (that is otherwise present when people seek clarifications on verbal documents).

Ideally speaking software enginnering

Collapse -

by alxnsc In reply to bridging the analyst/deve ...

Dear Colleague,

May be, some solution of your problem is to adopt their lingo yourself or even better is to ask (not get...)them adopt yours... Making all speak same language may cause malicious decrease of creativity, as both logical systems will have to be reduced to unpredictably low levels... and even worse - picture yourself an excavation works engineer speaking surgeon's lingo or vice versa...
A real disaster, isn't it! Don't do it...

Collapse -

by Wayne M. In reply to bridging the analyst/deve ...

The answer to your question will depend a lot on your corporate organization and culture. How much direction can you give to each group?

First, forget about tools or software, this is a communication issue. Next, identify the key 1 or 2 people in each group. You want to pick the people who can influence the others; these may be those with the most senior titles, but not always.

Now, you just have to get 2-4 people talking. Call meeting of this group and express your concern with the two groups not working well together. Explain that to succeed, both groups need to pull together. Now turn the problem over to this group and run some form of brain storming session. Find a reference to brain storming if you haven't facilitated one before.

In a nutshell, break the situation down into a manageable number of people, then turn the problem over to them to solve. This will be more likely to succeed than if you try to solve the problem for them and then impose your solution.

P.S. If the two groups are carrying political baggage as well, I think this approach will still work, but you may need to generate a lot of status reports to keep everyone inline.

Collapse -

by Goodwisj In reply to bridging the analyst/deve ...

Hi Mzii,

part of the problem as I have seen it in the past is that the developers (and for that matter the analysts) do not actually live in the shoes of the end users....... So the analysts take real-life and convert it into analyst lingo which then needs to become developer lingo and then when the product is delivered it is not recognisable by the users who initiated the development n months/years earlier.

Ergo the problem is not the communications from the analysts to the developers (et v.v.). If you are to be successful consider working a team of analysts and developers together to elicit the requirements from the users in a format where the requirement, the rationale, the process, the success criteria and the method of testing are all agreed with the users up front.... try it; I am beginning to see this work......

Related Discussions

Related Forums