And looking through all of the job postings...wow. It's like no one knows what a "BA" does. While we all might remember the A-Team, we're not talking about Mr. Barracus. We're talking Business Analysis. Some of us might like the thought of cutting an impressive figure, we're more critic than enforcer.
So, what is a BA?
Business Analysts
are not new to the software industry, though the term definitely has become
more popular since the formation of the International Institute for Business
Analysts (IIBA). You might know them as "Analysts"
or just "Requirements Managers" from the days of old.
So, what does a BA
do?
I think that the
term "Business Analyst" has led to a lot of confusion in the work
place about what it is that a BA does. A
"Requirements Manager" seems so much more straightforward. Uhm, you manage requirements and the
gathering of requirements through the project.
But over the past 10 years, I have seen a "Business Analyst"
equated to:
A
Project Manager: where you're supposed
to manage people and make budgets and other
project management stuff;
A
Economic Analyst: where you're supposed to forecast sales and marketing
efficacy (I know a couple of these and we're DEFINITELY NOT economic analysts);
A
Programmer: yes, believe it or not, some
jobs actually group "write code" with Business Analysis;
An
Architect: this one is actually a very fine line and I'm more understanding of
it since diagramming out a series of web pages or the system falls into the
requirements camp, but it's really more UI and Architecture;
User
Interface designer: Uhm,
programmer??? This job is programming
the UI of the website;
User
Experience Designer: again, more
understanding because diagramming those screens and flows and how all the
requirements fit on the page;
A
Quality Analyst, where you're supposed to test the software (don't get me
started on this last one. While a lot of
us BAs started out in the Quality field, it was all Quality Control, not
Quality Analysis- but that's a topic for a different blog)
I guess after
looking at all of these jobs, it seems to me that:
- People don't know what a Business Analyst does, and
- People don't realize that a good BA is really, REALLY hard to find. We're talking about someone who can listen to some vague, flufffy, completely stream-of-consciousness dreams of what needs to be done on a project and write out a series of "project must have X", "project must have Y", "would be great if project included Z" statements so that the project can get done. (yes, this is the waterfall format- just let me finish). My point is that an ANALYST is a great listener and able to immediately respond with a plan of action for taking a business vision or set of fluffy goals and turn them into the actual product. The Business Analysts are the dream interpreters, if you will, between the business and the technology team.
So, what does that
mean?
It doesn't mean that
BAs program.
It doesn't mean that
BAs do project management of people or budgets.
It means that we
listen, REALLY listen, and hang on every word that our business owner/product
owner/whomever is paying for this project has to say about what they want to
see for end-state. It means that we're
constantly incorporating all of the input and weighing that input against what
we already know about the project: the
current state, the technology that the _ARCHITECT_ has selected, the timeline
that the business has already established with the _PROJECT MANAGER. We're constantly asking questions about who
is your user? What do you actually want
to accomplish? BAs are the ones that
take the requirements and ask the question, "Doesn't this new requirement
directly undo what we've already done?"
We dive into the nitty-gritty details that no one really wants to think
about (except the Architects) and makes sure that the requirements can be
organized and accomplished.
And, no, it's not
easy to maintain all of those requirements.
Some meetings- man- they treat you like you should be the world's
greatest search engine and be able to recall every requirement in a two year
project off the top of your head, along with the state and planned
timeline. It's not easy. But if you're really a BA, it's what you do.
So, I guess my
advice to everyone out there who's looking for a good BA is this: If you find someone who keeps pestering you
about some little detail of a project not being in alignment or being vague-
KEEP THIS PERSON. LISTEN TO THIS
PERSON. This is your star BA. This person belongs on you’re A-Team. They may not have the best people skills, but
they really will prevent you from burying yourself into a project graveyard.
No comments:
Post a Comment