A Developer-Analyst Hybrid

Yesterday I had a discussion with my co-workers about developers, analysts and overlapping of their tasks (inspired by an article from Mr. Angry). We were not able to decide if it is worse to have:

• An analyst with no knowledge about programming or some other (corresponding) skill and knowledge or
• A developer with no will or interest for client’s requests

It’s really hard to tell. For example, I know an “analyst” who simply forwards all emails and notes from clients to developers, thinking, I guess, that her job is done. Maybe I’m wrong here, but I think I know a better way to do this. It’s called: automatic email forwarding. I mean, it’s:

• Free (doesn’t ask for salary and bonuses)
• More reliable than manual forwarding
• Fast
• Never sick or absent

This is an extreme example but I had to tell the story because it’s the truth (!).

It would be nice to have analyst and developer in one person. Often, for various reasons, it doesn’t work that way.
Nevertheless, there should always be a tendency not to have “pure” analysts and “pure” developers in the team/company. Here are (some of the) reasons why.


Main problems with developers detached from reality:

• Problem zero: communication overload. An analyst has to explain everything to the smallest detail about functionality that needs to be implemented. He has no confidence that any work will be done correctly without his supervision. I had a colleague that had to tell the developer that upper left corner is no place for a “Submit” button. I’m not kidding. Imagine the communication necessary to finish the job completely!
• Not learning business processes as they go along with development. Analysts will have much more work to do if a developer doesn’t learn the business processes. Every time some bug appears in the code which was written a month ago, analyst will have to explain all over again about things that need to be done. The reason is simple: if you really understand something, you remember it more easily even if some time has passed.
  

Main problems with analysts detached from technology:

• Promising wonders to end users. Analysts should know at least what information they should get from developers before they say it’s OK for something to be implemented.
• Not being familiar with data structures. If analyst doesn’t know enough about these, his job will be very difficult. Chances are that he will have to take one developer with him to each meeting with customers (which a waste of developer’s time in most cases).
• Leaving their problems to developers. If they do, it means a developer is doing a significant part analyst’s job. (Maybe developer should also get a part of analyst’s salary.)
  

Pushing developers to think like customers

Analysts should always encourage developers to learn the business processes and to learn why customer needs what he needs. If the developer refuses to listen and just wants detailed instructions, don’t give up and explain the processes to him/her when ever you get a chance.Team leaders should inform team members that a complete separation of development and analysis tasks is not acceptable because it adds effort to the project.

Pushing analysts to think like developers

This can be especially difficult because it might take months of even years for someone who is completely unfamiliar with the technology that is used. Of course, there are some people that work excellent with customers, and it would be a shame to lose their talent, but making analysts from them does not happen overnight. It takes companies time and analyst-to-be commitment. If either of those two things is missing, it will be very hard to get results.