The challenge,
For analysts the major challenge is to make both 'business' and 'developers' happy. They deal with the people who want to stick with their guns and hard to change their opinions. Business just believe in getting whatever they want 'somehow' and Developer whatever they 'understand' to deliver is to deliver with the technology they know the best. The analysts have to master the art of communicating to both the groups in their own language.
What happens in the real world,
Analysts might come from one of two backgrounds; IT developers with strong communication and problem solving skills or Business people with strong management and understanding skills.
A successful analyst would be the person who attempts to see the picture from the other side.
Limiting the focus to the areas they know best do not deliver the results.
For instance, an analyst with background in business may attempt to force the development team to cut the crap ("methodology and processes") and deliver fast. On the other hand an analyst with expertise in IT may try to focus more on technical solution (tools and technology and methodology) than functional solution (the process and achieving the value), stressing the quality of the software.
recipe for success,
DOs
- Realistic
- Quality of software and processes does matter
- Business people needs solution to their business problems
- Developers want clarity so remove ambiguity from requirements as much as possible
- Business is more interested in functional solution then technical design so give them the only part they are interested in.
- Speedy communication is the key to success
- For everything, coming from developer or business, ask again and again 'Does it make sense?'
- Be flexible but Quality Does Matter!
- Learn how to understand people, deal with each person (technical or business) with the way they should be
- Understand the environment, the people, the context and the people. Every place is different so modify your approach but always make it goal driven.
- Be agile, embrace changes and updates
DON'Ts
- Avoid attempting to be 100% clear on requirements , business will never (and they can't) give you. Make assumptions, take decisions and move forward with an acceptable margin of error
- - Avoid stressing too much on technical quality when it will deliver no value, making process too difficult to follow and creating a pile of documentation which no one would be interested in reading.
- Don't rush to get something done with half cooked requirement. you might have to scrap the whole work and do it again. In IT delivering a software with 95% functionality working means having bugs around 5% mark, too high!.
- Get out of your shell, your background (IT or business) is your strength, don't make it a constraint
Just a link,
http://www.requirementssolutions.com/Business_Analysis_Skills_Test.html
