I've been getting this question a lot recently- from friends, high school buddies and my mother. It comes in various forms:
Now I'm a Business Analyst.
Originally, Business Analysts analyzed economic trends, corporate maneuvers- bottom line sorta stuff with the bean counters in Finance.
About 20 years ago, computer people started realizing that all the cool stuff they were making either wasn't being used, was costing too much or didn't do what the business people thought the computer people told them it was going to do.
Think about the first time you moved from your first word processor to a new one. Remember how painful that was? Now think of that pain in terms of gobs of cash...yeah...that's what BAs were supposed to prevent.
So the first thing BAs do is make sure the computer people know what the business people said. And make sure the business people know what the computer people meant.
I usually say it this way: I make sure the propeller heads know what the suits said and vice-versa.
A close friend tells me potential employers may see this, so I'm not going to explain it the way I usually do.
Then a couple of guys said, "Let there be Requirements in the form of Use Cases and Business Rules."
And Project Managers saw it was good.
Use Cases and Business Rules are a way the business folks and the technical people can agree that this is what the thing is going to do, who's going to do it and how the heck do you figure out the Canadian Sales Taxes? Short simple sentences in active voice and a lot of step-action tables that nobody reads. Everybody looks at the color VISIO charts and ignores the data maps, development tests and other stuff that make everything work.
But the Project Managers didn't want to write them because they were way too busy trying to figure out this new Microsoft Project Server deal and why it won't show them dependencies (Scot has to do A before he can do B) in the color Gannt Charts?
So the BAs write them.
So, what we got now is translation duties and ownership of the documentation (at least all the docs now spell you're and it's correctly).
Then, ten other guys met on a mountain top somewhere East of Eden and came down with the Agile Manifesto (sounds like the Cold War started up again and the ten guys should have beards and be smoking Cuban cigars, doesn't it?).
The Manifesto says no documentation unless it's really, really, really necessary- Thou were filling up mine network shares with Word Documents no one read except for the embedded VISIO charts. So we BAs lost the documentation thing in favor of having developers actually talk to end users and stake holders. Clients or Subject Matter Experts or Stakeholders will write 2-3 sentence 'User Stories' and talk to the developer as the developer creates real code. Un-hunh. You ten cigar smokers think this is really going to happen, doncha?
Whoa, thar, big boy. You want a young person just out of C++ and/or Java School to talk to the senior managers and end-users about features? Without blood?
The high level lead and architects can and should be doing this...but what does a 23 year old know finding out how a 55 year veteran of the company does his job...with the knowledge that the new computer system will automate and thereby eliminate his job?
Scot? Can you grab those requirements for me?
And since the Manifesto says we do test-driven development and the client's way too busy, can you write up the technical specifications and the tests for us?
Oh, I forgot, since I'm only here two days a week for this project, can you prioritize the issues and features for me? We can plan a proposed list for the client next week.....
Add Alpha/Beta testing, setting up User Acceptance Testing (writing scripts for a lot of users to bang away on the system to find flaws), collating the results, mentoring junior BAs, helping Information Architects....you getting the picture?
That's why it's kind of hard to explain what I do.
I love doing it. I'm good at doing it. But nobody's been willing to pay me to do it since last October. Some company's going to get a bargain and I'm going to love them for it.
- What is it you do again?
- I'm not sure what you do but it sounds really dull.
- I thought you were a radio news guy.
- I thought you were a Folk Music D.J. who hated Bluegrass Music.
Now I'm a Business Analyst.
Originally, Business Analysts analyzed economic trends, corporate maneuvers- bottom line sorta stuff with the bean counters in Finance.
About 20 years ago, computer people started realizing that all the cool stuff they were making either wasn't being used, was costing too much or didn't do what the business people thought the computer people told them it was going to do.
Think about the first time you moved from your first word processor to a new one. Remember how painful that was? Now think of that pain in terms of gobs of cash...yeah...that's what BAs were supposed to prevent.
So the first thing BAs do is make sure the computer people know what the business people said. And make sure the business people know what the computer people meant.
I usually say it this way: I make sure the propeller heads know what the suits said and vice-versa.
A close friend tells me potential employers may see this, so I'm not going to explain it the way I usually do.
Then a couple of guys said, "Let there be Requirements in the form of Use Cases and Business Rules."
And Project Managers saw it was good.
Use Cases and Business Rules are a way the business folks and the technical people can agree that this is what the thing is going to do, who's going to do it and how the heck do you figure out the Canadian Sales Taxes? Short simple sentences in active voice and a lot of step-action tables that nobody reads. Everybody looks at the color VISIO charts and ignores the data maps, development tests and other stuff that make everything work.
But the Project Managers didn't want to write them because they were way too busy trying to figure out this new Microsoft Project Server deal and why it won't show them dependencies (Scot has to do A before he can do B) in the color Gannt Charts?
So the BAs write them.
So, what we got now is translation duties and ownership of the documentation (at least all the docs now spell you're and it's correctly).
Then, ten other guys met on a mountain top somewhere East of Eden and came down with the Agile Manifesto (sounds like the Cold War started up again and the ten guys should have beards and be smoking Cuban cigars, doesn't it?).
The Manifesto says no documentation unless it's really, really, really necessary- Thou were filling up mine network shares with Word Documents no one read except for the embedded VISIO charts. So we BAs lost the documentation thing in favor of having developers actually talk to end users and stake holders. Clients or Subject Matter Experts or Stakeholders will write 2-3 sentence 'User Stories' and talk to the developer as the developer creates real code. Un-hunh. You ten cigar smokers think this is really going to happen, doncha?
Whoa, thar, big boy. You want a young person just out of C++ and/or Java School to talk to the senior managers and end-users about features? Without blood?
The high level lead and architects can and should be doing this...but what does a 23 year old know finding out how a 55 year veteran of the company does his job...with the knowledge that the new computer system will automate and thereby eliminate his job?
Scot? Can you grab those requirements for me?
And since the Manifesto says we do test-driven development and the client's way too busy, can you write up the technical specifications and the tests for us?
Oh, I forgot, since I'm only here two days a week for this project, can you prioritize the issues and features for me? We can plan a proposed list for the client next week.....
Add Alpha/Beta testing, setting up User Acceptance Testing (writing scripts for a lot of users to bang away on the system to find flaws), collating the results, mentoring junior BAs, helping Information Architects....you getting the picture?
That's why it's kind of hard to explain what I do.
I love doing it. I'm good at doing it. But nobody's been willing to pay me to do it since last October. Some company's going to get a bargain and I'm going to love them for it.
Posts
No comments:
Post a Comment