Search This Blog

Translate

Tuesday, November 20, 2012

Looking for a BA job

So, I'm continuing to look for a BA job, but one that's remote.  By "remote", I don't mean "field work", which involves travel.  "Remote" means "remote", like as in, not in an office, like working from home.  Why is this difficult to understand?

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:


  1. People don't  know what a Business Analyst does, and
  1. 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